Cadence Blogs

SKILL for the Skilled: The Partial Predicate Problem

Team SKILL — Wed, 19 Jun 2013 14:07:00 GMT

The partial predicate problem describes the type of problem encountered when a function needs to usually return a computed value, but also may need to return a special value indicating that the computation failed. Specifically, the problem arises if the caller cannot distinguish this special value from a successfully calculated value. In this posting of SKILL for the Skilled, we look at several ways to attach this problem in SKILL.

Approach 1: Returning nil to indicate failure

A very common way a SKILL function indicates to its caller that it failed to do what was requested is to return nil. For example, the SKILL function nthelem returns the Nth element of a given list, given an integer N. If the list has less than N elements, it returns nil. For example (nthelem 2 '(10 20 30)) returns 20, but (nthelem 4 '(10 20 30)) returns nil.

A limitation of this approach is that (nthelem 2 '(t nil t)) also returns nil, because nil is the second element. The caller can only trust nil to be the failure case if he knows that nil is not an element of the list.

Here is an implementation of a find function which returns the first element of a given list which matches a given predicate. Note that this example (and most of the examples in this article) only work in Scheme/Skill++ mode.

(defun find_A (predicate data)
  (car (exists x data
         (predicate x))))

Here are some examples of how it works.

(find_A oddp '(2 4 5 6 7 9))
==> 5

(find_A stringp '(this is 1 "list" of stuff))
==> "list"

(find_A numberp '(this is a list of symbols))
==> nil

(find_A listp '(t t t nil t t))
==> nil

Notice that the find_A function returns nil in two cases:

if there is no element in the given list which matches the predicate
if nil is explicitly in the given list and matches the predicate

Thus if find_A returns nil you don't know whether it found something or not.

Approach 2: Returning a given default value on failure

The following implementation of find_B attempts to settle the ambiguity by allowing the caller to specify the return value on the so-called failure case.

(defun find_B (predicate data @key default)
  (let ((tail (exists x data
                (predicate x))))
    (if tail
        (car tail)
        default)))

(find_B stringp '(this is 1 "list" of stuff) ?default 'notfound)
==> "list"

(find_B listp '(t t t nil t t) ?default 'notfound)
==> nil

(find_B numberp '(this is a list of symbols) ?default 'notfound)
==> notfound

A disadvantage of this case is that the caller might find it clumsy at the call-site to provide a value which the given function call would otherwise never return.

Approach 3: Wrapping the return value on success

Another common way is to return a wrapped value. I.e., don't return the value found/computed, but rather return a list whose first element is that computed value. The SKILL member function does just this. (member 5 '(1 2 3 4)) returns nil because the given list does not contain 5; whereas (member 3 '(1 2 3 4) returns a list (3 4). Thus the only time member returns nil is when it didn't find the value being sought.

Another function which uses this approach is errset, which returns nil if the given form to evaluated triggered an error. Otherwise, errset returns a singleton list whose first (and only) element is the value calculated. Thus (errset 6/4) returns (3), while (errset 6/0) returns nil.

An obvious advantage of this wrapping approach is that the failure condition can always be distinguished from the success case. A disadvantage is that the caller who wants to use the calculated value must unwrap the value with an additional call to car, probably after testing whether the value is nil.

Here is an implementation of find_C which wraps its return value. It only returns nil if no element of the list matches the predicate. But the caller must call car to unwrap the value.

(defun find_C (predicate data)
  (let ((tail (exists x data
                (predicate x))))
    (when tail
      (ncons (car tail)))))

(find_C stringp '(this is 1 "list" of stuff) ?default 'notfound)
==> ("list")

(find_C listp '(t t t nil t t) ?default 'notfound)
==> (nil)

(find_C numberp '(this is a list of symbols) ?default 'notfound)
==> nil

Another disadvantage of this approach is that find_C always allocates memory if it successfully finds what its looking for.

Approach 4: Continuation passing

Still another way to solve this problem in SKILL++ is by passing a continuation. This involves organizing your code a bit differently, but in the end allows a lot of flexibility. The idea is to pass an extra argument which is itself a function to call with the computed value if successful.

(defun find_D (predicate data @key (if_found (lambda (x) x)))
  (let ((tail (exists x data
                (predicate x))))
    (when tail
      (if_found (car tail)))))

The find_D function searches the given list for an element matching the condition. If successful, calls the given function, if_found and returns the value it returns. Otherwise it omits calling the if_found and simply returns nil.

Continuation passing is a generalization

As you can see from the examples below, the function find_D is actually a generalization of find_A, find_B, and find_C.

These examples work like find_A.

(find_D stringp '(this is 1 "list" of stuff))
==> "list"

(find_D listp '(t t t nil t t))
==> nil

(find_D numberp '(this is a list of symbols))
==> nil

These examples work like find_B.

(find_D stringp '(this is 1 "list" of stuff) ?if_found (lambda (x) 'notfound))
==> "list"

(find_D listp '(t t t nil t t) ?if_found (lambda (x) 'notfound))
==> notfound

(find_D numberp '(this is a list of symbols) ?if_found (lambda (x) 'notfound))
==> notfound

These examples work like find_C.

(find_D stringp '(this is 1 "list" of stuff) ?if_found ncons)
==> ("list")

(find_D listp '(t t t nil t t) ?if_found ncons)
==> (nil)

(find_D numberp '(this is a list of symbols) ?if_found ncons)
==> nil

An initial reaction of this type of coding might be that it looks more complicated. But in fact, it is often less complicated when you actually try to use it. Why is this? It is because the code at the call-site usually needs to (1) do something with the calculated value. In addition, there must be program logic, to (2) test whether the value corresponds to the success case or the failure case.

The way find_D is intended to be used, the code for case (1) goes inside the function being passed as the ?if_found argument, and the code for case (2) is already inside the find_D implementation. This is shown in the following examples.

Example using continuation passing

Assume we have a function, is_metal_shape?, which figures out whether a given shape is on a metal layer, presumably by looking at the layer name of the shape and looking in the tech file to see whether that layer has "metal" function. Here is an example of how to use find_B and find_D to add such a shape to a particular db-group.

(let ((shape (find_B is_metal_shape? cv~>shapes
                 ?default 'notfound))
   (unless (shape == 'notfound)
     (dbAddObjectToGroup dbGroup shape)))

Notice that the call to find_D is actually simpler.

(find_D is_metal_shape? cv~>shapes
    ?if_found (lambda (shape)
                (dbAddObjectToGroup dbGroup shape)))

This approach has certain advantages over all the alternatives shown above. The most obvious advantage is that there is no ambiguity at the call-site. The caller does not have to tend with the failure condition. In fact it is the function find_D itself which knows whether the sought element was found and deals with it appropriately.

Handling the found and not-found cases separately

One might also write a version of function find_D with an additional if_not_found keyword argument to handle the other case that the call-site wants to do something different if such an element is not found--for example to trigger an error.

(defun find_E (predicate data @key 
                                (if_found (lambda (x) x))
                                (if_not_found (lambda (_x) nil)))
  (let ((tail (exists x data
                (predicate x))))
    (if tail
        (if_found (car tail))
        (if_not_found))))

Summary

In the above paragraphs, we saw several common ways of dealing with the so-called partial predicate problem in SKILL.

Return nil to indicate failure
Return a given default value to indicate failure
Wrap the return value
Pass a continuation to call on success.

In general continuation passing can indeed be very complicated, but there are certainly cases such as the example shown here, where the style is simple to use and eliminates complexity from your code with no added overhead.

A UPF User Perspective on the Evolution of Power Standards

rgoering — Wed, 19 Jun 2013 13:00:00 GMT

With the recent release of the IEEE 1801-2013 (UPF 2.1) power intent format standard, prospects for "methodology convergence" between the Unified Power Format (UPF) and Common Power Format (CPF) are looking good. One company that has used both formats and is following the evolution of power standards is STMicroelectronics.

Fellow Cadence blogger Adam Sherer and I recently spoke with David Vincenzoni, who works in the Industrial and Power Conversion Division of STMicroelectronics. His group develops large, complex industrial ASICs with embedded processors, including mixed-signal ASICs and SoC power line modems. Low power design is key, and many chips have two, three, or more power domains that can be switched on or off or carry different power levels. "It is vital to have a proven, low-power flow that goes from RTL to signoff," Vincenzoni said.

According to Vincenzoni, key challenges in low-power design include the following:

Designers need to anticipate bad connections that could occur during RTL design. "This means that we have to simulate the power domains in the RTL using the power description that will be used in the next steps of the implementation phase."
The need for a language that can describe high-level power intent at the RTL stage, and also has the constructs to describe power intent at the physical level.
Developing formal checks between the power-off and isolation cells.

The last SoC developed by Vincenzoni's group had two power domains with three power modes. There were also several level shifters between the core logic and the I/Os. A separate power domain was represented by an analog front end. Engineers used CPF for verification and UPF for implementation, and also used equivalence checking for the power intent.

Using IEEE 1801 UPF

For a recent IP development, Vincenzoni's group used IEEE 1801 UPF along with verification from the Cadence Incisive simulator. The block has two power domains and three possible power modes. A block diagram of the IP block is below.

Vincenzoni explained: "Through Specman and the UPF 1801 description of the power intent, we simulated the power modes of this IP. The implementation engineer used the same UPF 1801 description during the synthesis and equivalence checks. This IP can be delivered with the UPF 1801 description file, which can be included with the power intent of the SoC that will integrate it."

According to Vincenzoni, the older Accellera UPF 1.0 standard could be good enough for a power intent description at the implementation level, but it is too detailed for an RTL description. IEEE 1801-2013, on the other hand, inherits several CPF constructs that allow a high-level description of the power modes of the design, and it also supports low-level descriptions for the back-end flow.

Advice for UPF Users

By leveraging CPF constructs and deprecating some of the older UPF 1.0 commands, IEEE 1801-2013 opens the door to methodology convergence between UPF and CPF. Power format convergence is the "right way," Vincenzoni said. "For the designers, it is essential to have a language that is supported by all the tools of the ASIC design flow."

At present, STMicroelectronics uses the IEEE 1801-2009 (UPF 2.0) standard, and expects to stick with that through the next few projects. Vincenzoni said his group is "interested" in IEEE 1801-2013 but has to take tool support into account.

Vincenzoni's advice to UPF users: "Start to use UPF 1801-2009 and follow the evolution of the standard. Start now with UPF 2.0, and when the tools support UPF 2.1 it will be easy to switch."

Richard Goering

Related Blog Post

A CPF User Perspective on IEEE 1801 (UPF) "Methodology Convergence"

Developing the Skill Set Required for SystemC TLM-Based Hardware Design and Verification

Jack Erickson — Tue, 18 Jun 2013 19:15:00 GMT

I've written a lot about the benefits of moving hardware design and verification up in abstraction from RTL to SystemC with transaction-level models (TLM). We have seen many customers speed their overall design and verification turnaround by 2x. A recent article described Fujitsu Semiconductor's experience -- 35% better performance, 35% smaller area, 51% less power and faster turnaround time. The benefits of moving up in abstraction are summarized by the following graph, which shows the leaps...(read more)

What's Good About Allegro PCB Editor Net Groups? See for Yourself in 16.6!

Jerry GenPart — Tue, 18 Jun 2013 08:15:00 GMT

Just a brief blog today about a new feature in Allegro PCB Editor.

A new net grouping mechanism has been added in Allegro PCB Editor 16.6 called ‘NET_GROUPS’. Essentially, the Net Group replaces the bus object.

A Net Group is a collection of net objects. Different types of net objects, such as nets, buses, differential pairs, and XNets can be added as members of a Net Group. A net object can be a member of one Net Group only.

A Net Group can be constructed in the Constraint Manager.

If constraints are defined on a Net Group, the constraints are applicable to all members of the Net Group. With the introduction of Net Groups, user-defined collections of net objects are now composed as a Net Group instead of a bus.

The Object Type for the Net Group is 'NGrp':

Please share your usage of Net Groups in Allegro PCB Editor.

Jerry "GenPart" Grzenia

What the Evatronix IP Acquisition Brings to Cadence

rgoering — Mon, 17 Jun 2013 04:00:00 GMT

On June 13, 2013, Cadence announced it had completed the acquisition of the semiconductor IP business of Evatronix SA SKA. So who is Evatronix, and what does their IP business include? At the recent Design Automation Conference (DAC 2013), a Cadence Theater presentation by Jacek Duda, marketing manager at Evatronix, answered those questions.

Based in Poland, Evatronix is a provider of USB, MIPI, display, and storage controller IP, as well as quite a few industry-standard microcontrollers - 8051, 68000, and 80186. Evatronix peripheral controllers, combined with PHYs from Cadence, promise complete interface IP solutions that include controller, PHY, verification IP, and integration kits. Cadence announced its intention to purchase Evatronix's IP business in May 2013.

As Jacek noted, Evatronix was founded in 1991 and sold its first IP - an 8051 controller - in 1995. The company has around 60 employees, mostly engineers. The company has sold over 700 licenses, and 90% of its business is in the ASIC market. Evatronix also offers design services.

Jacek's presentation highlighted the following offerings from the Evatronix IP portfolio.

USB Solutions

Evatronix has staked out a strong position in USB-IF certified IP. Offerings include a USB-IF certified USB 3.0 (SuperSpeed) device controller and a SuperSpeed USB 3.0 hub, as well as USB-IF certified USB 2.0 controllers for device, hub, and OTG (On The Go). Silicon success for their USB High-Speed Inter-Chip (USB HSIC) solution goes down to 28nm. Evatronix provides software stacks and class libraries with its USB offerings.

NAND Flash IP

Evatronix provides NAND Flash controller IP that comes with a soft PHY or an SDLL PHY and with software drivers. Jacek showed the following diagram of the Evatronix NAND Flash controller. "We decided to keep the data buffers outside the controller," he remarked. "It is, therefore, really small, so it's got a lot of benefits for mobile applications."

Evatronix NAND Flash controller

Features of the NAND Flash controller include:

Support of memories from all major manufacturers (Toshiba, Micron, Samsung)
Legacy asynchronous mode
Synchronous mode support ONFi up to 3.0 (400MT/s) and Toggle Mode 2.0
Raw NAND and Clear NAND support
Error correction code (ECC) support for the BCH algorithm up to 128 bits
Support for small and large block NAND Flash devices

The NAND Flash IP can be customized in a number of ways, including custom sets of programmable error corrections, number of devices per bank, generic command sequence, support for small-block NAND Flash devices, and optional features including bad block management support.

SD Host 4.0

Secure Digital (SD) host IP supports the eMMC 4.51 specification, SD Host Specification version 4.0, the SD Physical Layer Specification 4.0, and the UHS-II Addendum 1.0. Features include a selectable, integrated DMA controller, support for single or multiple SD memory card slots, and UHS-II speed support.

MIPI SLIMbus IP

Evatronix has been providing MIPI SLIMbus IP solutions since 2006, and its Manager and Device controllers are now in their sixth generation, according to Jacek. The architecture for the SLIMbus Device IP (shown below) implements Interface, Generic Device and, optionally, Framer Device classes. The SLIMbus Manager IP implements Interface and Manager classes, with Framer and Generic Device class support being extra features. The Manager also supports message channel monitoring.

Evatronix Slimbus Device IP architecture

8051 Controller IP

Evatronix started its IP business with 8051 controllers and that's still a very strong market, according to Jacek. Three options are available - a configurable 8051, a fast 32-bit 80251, and a small 8051 that takes only 3,000 gates. The company also developed its own proprietary 8051 debugging environment.

Value Proposition

Jacek ended his talk by noting the following advantages of Evatronix IP:

Full compliance with the relevant specifications
Many successful customer designs
Silicon-proven IPs that are shipping in mass production
High configurability
Complete solutions with controller, PHY, and software (where applicable)
Support for industry-standard interfaces such as AXI, AHB, OCP

In my opinion, this IP will be a worthy addition to the Cadence family. It will complement IP previously acquired from Denali, Tensilica, and Cosmic Circuits, and allow Cadence to provide an even more comprehensive SoC design solution. Welcome Evatronix!

Richard Goering

We Need to Move "Past EDA": Tensilica Founder Rowen

Brian Fuller — Fri, 14 Jun 2013 21:24:00 GMT

AUSTIN, Texas—The EDA industry needs to move beyond EDA.

Sound counterintuitive? Not so much when the words come from the lips of Chris Rowen, the founder and CTO of Tensilica, and a guy I consider one of the most articulate observers of our industry.

And while it's counterintuitive, it's in fact not even at odds with EDA's traditional bread-and-butter proposition: tools to solve complex design problems.

Rowen, to be sure, has a unique seat from which to offer his views. Tensilica has been a longtime provider of data-plane processors in the IP space, where hardware meets software, where architects grapple with so many integration and design issues. Rowen sees Moore's law and its effect on SoC design (see embedded video outtake below) continuing to force specialization into and around that device. But as that happens in near real time, we can get lost in the weeds if we're not careful.

"I would put it in crude terms of moving past EDA, past the focus of ‘this is how you do it' much more to today ‘this is what you should do.' Meaning, (EDA) is a lot more central to defining, architecting, building, programming these silicon platforms. And (it's) less about taking the architect's conception of it and doing the back-end implementation."

Up and Away

Over time, everybody in the electronics ecosystem moves up the abstraction ladder. For example, a systems company that started out supplying routers for a network becomes the network provider over time; its engineers increasingly focus on the network architecture and software layer and software services that run on their hardware. At that point, semiconductor vendors begin moving up to build systems and subsystems on silicon and help out those systems engineers with their hardware challenges.

That has implications a rung or two down the ladder.

Said Rowen, as we chatted during a quiet moment at the 50^th Design Automation Conference:

"I do believe as the semiconductor guys have to move up and up in abstraction—they really are building the cell phones, they really are building the networks, the server farms, they're building things way up in that hierarchy—the question of the chip architecture can and should be left more and more to efficient suppliers who are able to fill in the holes."

"Where exactly that line gets drawn between what the SoC architect at Intel, Qualcomm, Marvell, a HiSilicon does and what we as suppliers of infrastructure into their product is drawn, I don't know. It changes over time."

In those little vacuums, IP providers and EDA vendors will find enormous opportunity, Rowen believes.

He added:

"Not only are people going to be interested in subsystems, they're going to be interested in how the methodology wrapped around the subsystems becomes the methodology for the integration of the subsystems and therefore becomes the method by which you define, architect, program, build the chip."

At a busy DAC, his first since Cadence acquired Tensilica, that was what was on the mind of one of the industry's great technologist-poets. Rowen's not suggesting EDA abandon its core business, of course, but it never hurts to be reminded that in a relentlessly changing electronics world, rethinking one's strengths and opportunities should be just as relentless.

Here's a snippet from that conversation:

Brian Fuller

Gary Smith at DAC 2013 - the $170M SoC Design is a "Myth"

NI CEO Sounds Call for Platform-based Design at DAC 2013

Cadence CEO at DAC 2013: 'I've Doubled, Tripled Down on Semiconductor Investment'

Freescale CEO at DAC 2013: "Internet of Things" Brings Opportunities, Challenges

Samsung DAC 2013 Keynote: EDA, Semis "Not Well Prepared" for Next Mobile Revolution

Virtuosity: 10 Things I Learned in May by Browsing Cadence Online Support

stacyw — Fri, 14 Jun 2013 17:02:00 GMT

May was a big month for new videos. It was also a month that saw the release of Virtuoso IC6.1.6, with lots of great new features and the rollout of new enhancements to the Cadence Online Support website.

Videos

1. DMS Basics Series

This is a great series of 10 videos covering various topics in mixed-signal verification, real number modeling, and mixed-signal connectivity. You'll also notice all 10 videos referenced together in sequence as a single "playlist" so you know what order to watch them in.

2. Enter Points

Demonstrates some enhancements in IC6.1.6 whereby the user can enter coordinates for commands using a form instead of pointing in the layout canvas.

3. IC6.1.6 Ruler

Demonstrates several enhancements to the ruler command in IC6.1.6.

4. Palette—IC6.1.6 Enhancement

This video discusses new modes available to invoke Palette, bindkeys, synchronization/desynchronization, editing LayerSets, and editing validity status of LPP. Some of these topics are also discussed in the solution: Palette—How to encapsulate the Layers, Objects, and Grids panels into a single assistant when undocked outside the layout window?

5. Virtuoso Parameterized Layout Generators—VPLGen

VPLGen is a new feature in 616. This video describes setting up VPLGen and generating VPLGen Pcells.

6. Toolbar Manager

This video demonstrates the new features in IC6.1.6, which allow you to easily customize the content and display of existing toolbars and to create your own toolbars.

Product Information

7. Product Documentation for IC6.1.6

As you have probably gathered from the precediing items, the initial release of Virtuoso IC6.1.6 occurred in May. A good place to start learning about new features would be the Virtuoso Platform What's New document.

8. Cadence Online Support Release Highlights

You may have also noticed several changes to the http://support.cadence.com website interface. The Highlights document summarizes what's new.

Solutions

9. How to create a single inverter symbol to represent multiple models and pass LVS

A worked example (with database) showing you how to create a parameterized inverter symbol that can represent, for example, multiple voltages, via an inherited model name.

10. Path to access MMSIM products has changed to [installation_directory]/bin in 12.1.1

The path to access the MMSIM products has been changed from <installation>/tools/bin/ or <installation>/tools.<platform>/bin/ directory to the <installation>/bin/ directory.

DAC 2013 Panel – Can Better Organization Solve the Verification Crisis?

rgoering — Thu, 13 Jun 2013 08:45:00 GMT

Automated tools and standardized methodologies have made functional verification easier, but verification is still arguably the biggest bottleneck in getting chips out the door. The good news, according to panelists at the recent Design Automation Conference (DAC 2013), is that organizational and management changes can ease the verification crisis.

The not-so-good news is that architects, design engineers, and verification engineers will have to step out of the comfort of their "silos" and work much more collaboratively than they have in the past. And companies must foster a culture in which verification engineers are valued.

The panel, held at the DAC Pavilion June 4, was titled "Organizational and Management Solutions to the Verification Crisis." It was moderated by Mike Stellfox, Cadence fellow. Panelists were as follows, shown left to right after Stellfox (far left) in the photo below:

Scott Runner, vice president of advanced methodologies and low power design, Qualcomm (San Diego)
Neeta Ganguly, validation manager, Intel (Austin)
Alan Hunter, verification architect, ARM (Austin) and chair of the Accellera Unified Coverage Interoperability Standard (UCIS) committee

Here are some of the key takeaways from the panel.

1. It's hard to find qualified verification engineers

Stellfox: One of the biggest issues I'm seeing is the lack of verification engineers and expertise in the industry now.

Runner: Certainly verification resources are a critical constraint, and I think all of us are looking at a variety of solutions to address that. One approach is for people who already have the requisite skills to come into a company. Another is to train people to develop verification skills.

Hunter: Here in Austin, it can be difficult getting well qualified people. We are starting to see some graduate courses now, but it is still a challenge.

Ganguly: I notice there's not enough verification talent for the amount of work that needs to get done. In Austin it is very tough to find people with the right kinds of skills.

Runner: I'm from San Diego. I'll add San Diego to that list. And folks in the [San Francisco] Bay Area would say it's hard to find DV [design verification] folks. It's a collective problem overall.

2. Verification must include power and performance

Runner: Not only does lack of verification impact quality, it impacts power. If a power feature is insufficiently verified and doesn't work, it affects the power budget and impacts performance. Performance validation is another critical issue.

Ganguly: Just knowing one particular area isn't good enough. The verification engineer really needs to know, from front to back, where the power is going, and what gates get turned off to enable power management functions.

3. Companies must foster a good verification "culture"

Stellfox: I've seen companies that have a good verification culture, and I've seen companies that don't even have a career track for verification engineers.

Runner: One of the challenges is that verification engineers don't feel appreciated, or don't feel they're on par with design. You need to hold verification on par with design and say both are responsible for verification milestones. For example, if the verification guy finds a bug and the designer has to debug it, whose test plan will be used? It's a joint test planning activity.

Hunter: We try to foster a community around verification. We have a verification conference once a year and we've invited designers as well.

Ganguly: The end result is a joint effort between architecture, design, and verification teams. All of them have to be responsible for the design. I think that at Intel, verification people are treated on par with RTL designers.

4. Designers should be more involved with verification...within limits

Hunter: We try to get designers to think about interface constraints from day one, rather than trying to do it piecemeal after the fact, which just never works, to be honest. We have a good buy-in from the designers.

Runner: In the past we've tried to force the issue that designers should also be DV engineers, in addition to micro-architectural design, RTL coding, timing analysis, synthesis, and documentation. It's not very feasible. But clearly, having designers participate in test planning is very critical. Design for verification is another key area. The problem is to figure out the right roles and responsibilities for the team rather than force designers to do verification.

5. Verification engineers can help the design effort

Ganguly: We were trying to define an architectural protocol, and we had architects, designers, and verification people all in the same room going through that protocol. The verification engineers actually had a lot of perspective and they could point out holes as the architecture was being defined. This cleaned up a lot of problems before they got coded in.

6. Specialized verification engineers need to step out of their silos

Stellfox: Verification is not just simulation. You've got virtual platform teams, software integration teams, emulation teams, simulation teams, post-silicon environments -these groups tend to be working in silos in the company, because they're specialists.

Ganguly: This verification continuum is, I think, the biggest challenge out there. Because of the complexity of our designs we can't do it all in pre-silicon, or emulation, or virtual platforms - we have to have all these working together in order to verify.

Runner: When you have completely independent organizations that don't interact, things become more skewed. If you have disciplined interactions like joint reviews, I think you start to coalesce.

7. Don't try to change too much at once

Runner: When you come in and try to throw a new methodology over the wall to people who have been there 10 or 15 years, it's tough. It's better to align yourself with people who get it and maybe try an initial project. Don't try to do too much.

Ganguly: You might want to start with a joint team including architecture, design, and verification. Once they have proven that it works, you can get more buy-in from the rest of the company.

Conclusion

All in all, this was a very thought-provoking panel that delved into a topic we don't hear much about - how company culture, organization, and management can ease the verification crisis. This discussion was long overdue.

Richard Goering

Note: Scott Runner was also a speaker at the Designer Keynote at DAC. For a report on that keynote, click here.

What's Good About RF PCB and Agilent ADS Via Exchange? 16.6 Has Many New Enhancements!

Jerry GenPart — Tue, 11 Jun 2013 14:46:00 GMT

The 16.6 Allegro PCB Editor and the Agilent Advanced Design System (ADS) interface have several new enhancements with respect to padstacks and vias.I will cover the Allegro generic via padstack that exports to ADS, and also the enhancements for existing layout IFF interface (import and export) to support the generic via exchange.

Layer-to-layer via structures are almost always used in PCB designs. These common structures are not standardized in ADS -- they are represented in several ways. These include instances of via models such as the microstrip VIA2 and as layout-only footprints that define the catch pads and drill holes with simple polygons.

The disconnection between the capabilities of PCB tool via structures, and the equivalent objects in ADS, makes design transfer difficult. A PCB tool via structure must be flattened to simple polygons for transfer to ADS, losing most of the information contained in the original PCB via. Likewise, those simple polygons can be transferred back to the PCB tool, but are not identified as a via structure and not treated as a layer-to-layer connection. ADS does not have the PCB compatible via library, which means there is no padstack definition for a generic PCB via.

To solve the problem, Cadence and Agilent developed a solution -- you can export Allegro generic via padstacks first from the PCB Editor, and then ADS will build a PCB-style via library with the pcbViaLib utility offered in ADS2011.10. Agilent has provided the pcbViaLib design kit, which provides via import utilities and a new ADS component, the pcbVia. This design kit defines a data file format that holds the definition of a PCB-tool style via structure, which is read by the pcbVia component and used with a layout macro to render exactly the same layout footprint in ADS as in the PCB tool.

When you export an Allegro layout design with generic vias to ADS by IFF, you can select export vias as components so all generic vias will be mapped to ADS via components. You can also use the via components in ADS layout and then export the ADS design with the kind of via components by IFF. When importing the design into PCB Editor by IFF, the I/F will automatically map back the ADS via components to Allegro generic via padstacks.

Here is the flow for via management between Allegro PCB Editor and ADS:

Read on for more details …

Export Allegro Generic Via Padstacks to ADS

There is a utility under the RF-PCB to export generic vias for ADS via component creation. You can click RF-PCB > Export Padstacks to ADS:

All vias used in the design will be listed and then you can select some/all vias to export. Please notice only vias in the layout will be listed on the form, so if you want to export a via padstack, you have to place the via into a design. The via group name is for ADS usage. Once you create the via components on the ADS side, you can place a via component in ADS layout from the specific via group.

Note: It’s best to use a unique group name for each design so that ADS will not get confused. The exporting for via padstacks is not based on IFF format but AEL.

Constructing ADS Via Components

You can only get the required utility in ADS2011.10 or later. If you installed the specific design kit (you need to ask for it from Agilent), you will see this menu in ADS layout:

In ADS layout, click PCB Via Utilities > Import Via/Padstack Group… Browse to the proper .ael file exported from Allegro PCB Editor, then you will create the via components:

Export Allegro Design with Generic Vias to ADS by IFF

For a design with generic vias in PCB Editor like the following:

Click RF-PCB > IFF Interface > Export… to get the following dialog:

You can click the More options button, then you can see the Vias tab. Two options are available for via transfer mode. By default, all vias will be considered as components to export. You can still change it to Shape for the exporting as before. You can also RMB click on the header bar to select Change all to components as below:

If you export all vias as components, then all selected generic vias will be written out as via components in IFF file so that ADS can recognize them.

Import Layout IFF with Mapped Via Components into ADS

Make a new workspace in ADS and make sure the PCBVIALIB design kit is in current workspace. To import the design into ADS via IFF, click File > Import… in ADS layout, and then select the Cadence/PCB option, and browse the proper folder for the source files:

You will get the ADS layout will all generic vias converted into ADS via components:

If you double click a via in ADS layout, you will see the details for the via component:

Use Via Components in ADS

Once the via components created in ADS, you can export a layout design with generic vias from Allegro PCB Editor and then import the design into ADS by IFF. The Allegro generic vias can be replaced by ADS via components. Also you may directly use those via components in ADS side. Before you add a via component into the design, you need to know which vias are available. You can click PCB Via Utilities > List Via Groups, all available via names and via groups will be listed:

To add a via component into ADS layout, you can directly enter pcbVia at the following field:

The following dialog will appear:

You may need to change the viaGroupName and viaName and also padTypes. You can get the viaGroupName and viaName by clicking PCB Via Utilities > List Via Groups. For padTypes, you need to manually specify the value.

The meaning of the padTypes is to specify the pad usage on each layer. On each layer there will be a figure (range: 0-7) to indicate the pad usage on the layer. For example, 2 means the pad on this layer is for anti-pad usage. 4 means the pad on this layer is used as regular pad.

The details of the definition for the padTypes are as following:

So when you use the via components in ADS, you need to know the layer number of the original via in Allegro design (when you export the padstack from Allegro).

Export Layout IFF with Via Components from ADS

Export a design from ADS layout by click File >Export…, and select the Cadence/PCB option form drop-down list:

Import IFF with Via Components into Allegro

In PCB Editor, click RF-PCB > IFF Interface > Import…, browse to the proper layout.iff file:

All via components in the IFF file will be mapped back to Allegro generic vias:

I look forward to your comments!

Jerry "GenPart" Grzenia

DAC 2013: Qualcomm, TI Keynoters Present Mobile SoC Design Challenges and Solutions

rgoering — Tue, 11 Jun 2013 08:50:00 GMT

Keynote speeches at electronic design conferences tend to focus on high-level industry issues. The "Designer Keynote," part of the Designer Track at the recent Design Automation Conference (DAC 2013), was different. In engineer-to-engineer talks, design managers from Qualcomm and Texas Instruments discussed challenges and solutions for designing mobile communications systems-on-chip (SoCs).

The first speaker was Scott Runner (right), vice president of advanced methodologies and low-power design at Qualcomm. He spoke about SoC design for mobile applications, particularly smartphones. The second speaker was Sanjive Agarwala, TI fellow and director of worldwide silicon development at Texas Instruments. He focused on the design of mobile infrastructure processing systems from a base station point of view.

Both reached essentially the same conclusion - whether it's an SoC for a cell phone or a base station, it's a system-level problem that needs system-level solutions.

Mobile SoC Processor Challenges

Runner started his talk by pointing to the complexity of smartphones today. Far more than phones, they are "integrated platforms for providing seemingly disparate technologies that have come together to provide a new user experience." What is required to create such a device? "The heart of it is a mobile SoC processor that must be married together with power management ICs, with RF, sensors, display, and battery, into a small form factor that has to be light and low cost," Runner said.

Runner identified three key challenges in smartphone design - low power, verification/validation, and hardware/software co-design. Illustrating the power challenge, he showed a plot of the relative performance increase of the CPU, GPU, and memory bandwidth over time, compared to the power savings provided by process node shrinks. Conclusion: "Process scaling is insufficient to support the increase in performance that's required to enable all these exciting new applications."

Runner noted that there's a tremendous amount of "feature growth" in smartphones today, translating into a demand for performance and memory. And yet, designers have a thermal envelope with a limitation of 4 or 5 watts (compared to about 20 watts for a laptop). Battery technology is not keeping up with the increasing demand for power consumption.

DAC chair Yervant Zorian (right) presents Scott Runner with an appreciation certificate following Runner's talk.

How can we solve the power problem? "First and foremost, we must realize this is a system design problem," Runner said. That requires an awareness of system architecture, workload partitioning, hardware/software partitioning, and power modeling and optimization. Also, there's a need for effective power management strategies - such as dynamic CPU and GPU control, dynamic voltage and clock scaling, and power gating. Designers need to determine where return on investment is best.

Complex Verification Task

Runner's second challenge was verification and validation, and he noted the difficulty of validating complex system-level scenarios. And it's not just a matter of finding functional errors. "I have to pay attention to performance and security validation, power validation, regulation and conformance testing, interoperability and field testing, compliance and qualification testing, and user interface testing," he said. And to top it all off, process variability is on the rise.

The solution, again, is working at the system level. That means validating the architecture at a high level of abstraction, and re-using verification and validation throughout the flow. It also calls for a variety of engines including simulation, formal verification, acceleration, and emulation, since all have different performances and timeline requirements.

The third challenge, hardware/software co-design, is driven by a realization that "software is growing faster than hardware" and is experiencing a state space explosion of its own. Runner takes a realistic view: "Do I expect hardware and software teams to use the same tools, to be on the same design timelines, to use just one model abstraction? No. I see collaboration between hardware and software teams in terms of documentation and specifications and the overall platform."

Challenges of the Infrastructure

To use mobile communications devices, you have to have an infrastructure that supports them, and that's what Agarwala (left) oversees. He first noted the complexity of embedded systems such as base stations and the myriad of requirements they must meet - not only power and performance, but also safety and reliability. "Putting all this together is the crux of being able to grow in this industry," he said.

Agarwala noted that there are about 6 billion mobile subscriptions today, growing to 9.1 billion in 2018, and about one billion smartphones, growing to 4.5 billion in 2018. "What this means for networks," he said, "is that the expected growth of network capacity in five years is expected to be 12X over what you have today, and 46% of that will be mobile traffic."

Certainly there has been progress in the past 10 years. Today, Agarwala noted, a two-chip solution can implement an entire multi-standard base station. While a typical IC in 2000 had 40-50 million transistors, today we're planning designs with 3 billion transistors. A number of different types of cores are being pulled into systems, increasing bandwidth requirements. No wonder building a platform such as TI's KeyStone can be a $100 million investment.

Agarwala noted the following "complexities" in mobile infrastructure SoC design:

Semiconductor IP. "An industry ecosystem needs to come together for us, and the key challenge for the industry is how to make IP easy to use, integrate and deploy."
Power Management. Whether static or dynamic, this is a huge issue. "Don't just think from a device or block level - think of it from a system and board level."
System Management. To build asynchronous systems, designers must be aware of reset, clocking, design for test (DFT), interrupts, and interconnect fabric.
Board-level Integration. Power management and integration of devices at the board level continue to be big challenges.

"Systems knowledge is key" is the primary lesson learned, Agarwala said. "Think back to the $100 million investment required," he said. "You have to figure out where to spend dollars and time in terms of optimization. Don't just optimize at the individual entity level - focus on the system. Are you optimizing the part or are you optimizing the whole?"

Richard Goering

Related Blog Posts

Gary Smith at DAC 2013 - the $170M SoC Design is a "Myth"

NI CEO Sounds Call for Platform-based Design at DAC 2013

Cadence CEO at DAC 2013: 'I've Doubled, Tripled Down on Semiconductor Investment'

Freescale CEO at DAC 2013: "Internet of Things" Brings Opportunities, Challenges

Samsung DAC 2013 Keynote: EDA, Semis "Not Well Prepared" for Next Mobile Revolution