Cadence Community

SKILL for the Skilled: Introduction to Classes -- Part 5

Team SKILL — Fri, 10 Feb 2012 14:00:00 GMT

In the previous SKILL for the Skilled postings, we looked at a pretty good algorithm for solving the Sudoku puzzle. This algorithm is able to find at least one solution of the puzzle if one exists, and is able to detect that no solution exists if that is in fact the case. In this article we look at a particularly difficult case which the algorithm we have chosen performs poorly.

What about a difficult puzzle?

In his article Solving Every Sudoku Puzzle, Peter Norvig suggests a puzzle which is pretty difficult. In fact it is the worse case for the algorithm he proposes in the article.

Sudoku puzzle 5-1
(SkuSolve '((? ? ? ? ? 6 ? ? ?) (? 5 9 ? ? ? ? ? 8) (2 ? ? ? ? 8 ? ? ?) (? 4 5 ? ? ? ? ? ?) (? ? 3 ? ? ? ? ? ?) (? ? 6 ? ? 3 ? 5 4) (? ? ? 3 2 5 ? ? 6) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?)))

The algorithm implemented in SkuFindSolution does in fact solve this puzzle but considerably slower than the other examples shown above. On the particular machine I'm using, all the puzzles described in the previous posting are solved in less than 1/10 of a second. This problematic puzzle takes more than 25 seconds to solve.

starting with: 
+-----+-----+-----+
| | | | | |6| | | |
| |5|9| | | | | |8|
|2| | | | |8| | | |
| |4|5| | | | | | |
| | |3| | | | | | |
| | |6| | |3| |5|4|
| | | |3|2|5| | |6|
| | | | | | | | | |
| | | | | | | | | |
+-----+-----+-----+


found solution:
+-----+-----+-----+
|8|3|4|9|7|6|5|1|2|
|6|5|9|2|3|1|7|4|8|
|2|7|1|4|5|8|6|9|3|
|1|4|5|8|6|2|3|7|9|
|7|2|3|5|4|9|8|6|1|
|9|8|6|7|1|3|2|5|4|
|4|1|7|3|2|5|9|8|6|
|5|9|2|6|8|4|1|3|7|
|3|6|8|1|9|7|4|2|5|
+-----+-----+-----+

A different algorithm

The version of SkuFindSolution shown in SKILL for the Skilled: Part 4 iterates over the cells in the board simply in the order they appear in the list. The following improved version of SkuFindSolution first sorts the cells into order of increasing possibility. Cells which have few possibilities are moved to the beginning of the list, and cells with more possibilities are moved to the end of the list.

The changes in the function are to introduce the local function count_possibilities into the (labels ...),

(count_possibilities (cell)
  (let ((c 0))
    (for i 1 9
      (unless (conflict? i cell)
        c++))
     c))

and to insert a call to (sort ... (genCmpFunction...))

sudoku->cells = (sort sudoku->cells
                      (genCmpFunction ?key count_possibilities))

before calling solve_cell.

Recall the functions genCmpFunction and identity from a previous blog posting.

(defun genCmpFunction (@key (test lessp)
                            (key  identity))
  (lambda (A B)
    (test (key A)
          (key B))))

(defun identity (x)
  x)

The genCmpFunction generates a function which can be used as the second argument of sort. In this case genCmpFunction returns a function which will cause sort to order the cells in increasing order according to the return value of count_possibilities.

The local function count_possibilities returns the integer corresponding to how many of the number in the set {1 2 3 4 5 6 7 8 9} are conflict-free when placed in the given cell.

New version of SkuFindSolution

(defun SkuFindSolution (sudoku)
  (prog ()       
    (labels ((count_possibilities (cell)
               (let ((c 0))
                 (for i 1 9
                   (unless (conflict? i cell)
                     c++))
                 c))
             (conflict? (solution cell)
               (exists group '(column row b3x3)
                 (exists c (slotValue cell group)->cells
                   (and (neq c cell)
                        (eqv solution c->value)))))
             (solve_cells (cells)
               (cond
                 ((null cells)
                  (return sudoku))
                 (((car cells)->value)
                  (and (not (conflict? (car cells)->value
                                       (car cells)))
                       (solve_cells (cdr cells))))
                 (t
                  (let ((cell (car cells)))
                    (for solution 1 9
                      (unless (conflict? solution cell)
                        cell->value = solution
                        (solve_cells (cdr cells))))
                    cell->value = nil)))))
      
      sudoku->cells = (sort sudoku->cells
                            (genCmpFunction ?key count_possibilities))
      
      (solve_cells sudoku->cells))))

What about the performance?

I ran the new algorithm and the old algorithm on four examples, three from the previous posting 4-1, 4-2, and 4-3, and also on 5-1 above. It turns out that the old algorithm performs 2x to 8x faster than the new for the cases it handles well. In particular, for cases for which the old algorithm solves the puzzle in less than 1/10 of a second, the new algorithm works slower but still solves in less than 1/10 of a second. On the other hand, on the extreme case where old algorithm handles poorly, where the old algorithm requires half a minute to solve the puzzle, the new algorithm is 12x faster.

Performance Measurements
Puzzle	Algorithm 1 (seconds)	Algorithm 2 (seconds)	Comparison < 1.0 is bad (More is Better)
4-1	0.0420	0.0669	1 / 1.59 degradation
4-2	0.0230	0.0830	1 / 3.61 degradation
4-3	0.0030	0.0220	1 / 7.35 degradation
5-1	25.22	2.075	12.154 improvement

Summary

In this series of 5 postings (first four listed below) we've used the SKILL++ Object System to implement a sudoku puzzle solver.

I hope you will find the examples in these posting useful.

Jim Newton

SKILL for the Skilled: Introduction to Classes - Part 1
SKILL for the Skilled: Introduction to Classes - Part 2
SKILL for the Skilled: Introduction to Classes - Part 3
SKILL for the Skilled: Introduction to Classes - Part 4

Things You Didn't Know About Virtuoso: Measurements Across Corners

stacyw — Thu, 09 Feb 2012 20:56:00 GMT

In Virtuoso IC 6.1.5 ISR6, we released a new feature in ADE XL, which had been requested by many customers--the ability to define a measurement expression which operates on the results of another measurement expression across corners. For example, I can create an expression to measure, say, a delay. Call it "myDelay". Now I can create another expression which calculates, for example, the maximum value of "myDelay" over all the corners I ran.

To do this, I simply add an expression in the ADE XL Outputs Setup pane, give it a name (optional), and set the cyclic in the "EvalType" column (you were wondering what that new column was for, weren't you?) to "corners". The line will now be highlighted in blue to distinguish it from regular waveform and scalar expressions. Now create your expression. If you use the functions ymax, ymin, average, peakToPeak or stddev, the argument "?overall t" will automatically be added to the function to ensure the values are treated by the function as discrete, rather than continuous points.

It should be fairly obvious what the above functions do--you run a simulation over corners and you can find the max, min, average, spread (peakToPeak), and stddev of any scalar measurement over those corners.

ymax(myDelay)
ymin(myDelay)
average(myDelay)
peakToPeak(myDelay)
stddev(myDelay)

Perhaps not so obvious is the fact that you can use other functions to measure across corners as well. For example, if you create a set of corners as a temperature sweep (remember, the definition of corners in ADE XL isn't restricted to PVT--you can create a variable out of pretty much anything and then sweep it in the Corners form), you can create a MAC expression using the cross() function to find the temperature at which an expression reaches a certain value:

cross(myDelay 200n 1 "either" nil nil)

Or you can use the value() function to find the value of an expression at an interpolated temperature value (or whatever variable you swept in your corners run):

value(myDelay 65)

MAC expressions are also supported for Monte Carlo analysis and Local and Global Optimization.

I'm sure you'll find this new feature useful. As always, comments and feedback are welcome!

Stacy Whiteman

Digital and Analog Verification – Round Peg in a Square Hole?

rgoering — Thu, 09 Feb 2012 15:00:00 GMT

Recently I wrote about a panel discussion that looked at ways of bridging the gap between analog and digital design. This blog post resulted in a lengthy discussion in a LinkedIn group that brought up the topic of verification. One commentator noted that analog and digital designers have very different interpretations of "verification," and concluded that "people have been trying for years to squeeze the round analog peg into the square digital hole."

This comment was a response to a panel discussion in which panelists were asked the following question: "In the digital world we talk about how 70% of the effort is spent in verification. How much time is spent in analog verification?"

Panelist Navraj Nandra (Synopsys) replied that the 70% estimate "is not far off but the color of verification is different." He explained that customers in the analog world are looking for things like IV numbers, and they expect silicon characterization.

Panelist Mladen Nizic (Cadence) noted that we need to distinguish functional verification from signoff verification. "If we talk about digital, it's usually just functional verification," he said. "We need to invest more in analog/mixed-signal functional verification. I see more and more adoption of digital techniques like coverage driven verification and random stimulus. This combination is really needed." For signoff verification, he said, a hierarchical approach can alleviate the need for heavy SPICE simulation runs.

Analog "Verification" is Part of Design

The LinkedIn commentator noted that there may be a more fundamental difference. While digital engineers view "verification" as a separate step, analog designers simply see it as part of the design process. The analog engineer develops an architecture, runs simulation to see if the architecture meets the specs, modifies the architecture if not, and runs the simulation again. Thus, verification is an iterative process, not something handed off to someone else.

If verification is part of the design process in a pure analog world, this could explain why we don't see separate verification teams for analog, as we do for digital. But wait a minute. The world is no longer pure analog or pure digital -- it is increasingly mixed-signal. Even "analog" IP blocks are likely to have some digital control logic, and nearly all "digital" systems-on-chip (SoCs) contain some "analog" (and mixed-signal) IP blocks.

It is at this intersection of analog and digital that a new verification paradigm is emerging -- at least, new for the analog folks. Techniques such as verification planning, random test generation, coverage, metric-driven verification, and assertions are in use today in mixed-signal settings, and they are working. Proof of this came in a Design Automation Conference 2011 panel that I moderated (photo below) at the Cadence booth in which engineers from Qualcomm, NXP Semiconductors, and LSI described how their companies are bringing digital verification techniques into the analog/mixed-signal world.

DAC 2011 mixed-signal panel (photo by Joe Hupcey III)

Among other topics, the engineers discussed real number (wreal) modeling, which allows ranges of analog values to be represented in digital simulation environments; the need for separate analog verification teams; the use of verification planning, analog coverage, and analog assertions; mixed-signal design with the Universal Verification Methodology (UVM); and the need for analog/mixed-signal language extensions to SystemC, SystemVerilog and UVM. You can read my report of the discussion here.

SPICE Forever?

Of course, SPICE simulation is still needed at the analog block level, and probably will be needed for many years in the future. Multi-core implementations of SPICE, like the Virtuoso Accelerated Parallel Simulator (APS), can be of great help in this regard. What is needed is a range of analog/mixed-signal modeling and simulation techniques, from SPICE to Verilog-AMS to real number modeling, so engineers can make the proper tradeoffs between speed and accuracy (below).

When it comes to mixed-signal SoCs, a separation between "analog" and "digital" is no longer relevant, and no IP block should be treated as a black box to be thrown over the wall to the other side. The interaction between analog and digital circuitry is one of the greatest sources of errors, and when you add low-power design techniques to the mix, it's even more hazardous. Thus, a thorough mixed-signal verification is essential, and it must be completed in a reasonable period of time.

How can this be done? What is needed is an integrated mixed-signal design and verification environment that combines the best of both analog and digital worlds, preferably using a common database such as OpenAccess. And digital techniques such as executable verification planning, assertions, and metric-driven verification must come along with this environment, along with wreal modeling at digital simulation speeds. This is how we get away from the "round peg into the square hole" problem. A point tool approach won't do it.

But even as analog and digital worlds become increasingly intertwined, we need to remember that words like "verification" can carry very different meanings in our respective worlds. In addition to adopting the right tools and methodologies, we need to learn to speak a common language, or at least begin to understand each other's dialects.

Richard Goering

Note: The recently published book Advanced Verification Topics has a detailed chapter on using metric-driven verification and UVM-MS (UVM with mixed-signal extensions) for analog/mixed signal design. You can read my review of the book here.

Five-Minute Tutorial: Change The Background Color Of EDI

Kari — Wed, 08 Feb 2012 16:39:00 GMT

Today's tutorial could probably be called a One-Minute Tutorial, since it's so quick. This is something that came across our internal expert alias, and I figured it's something that most people may not know about. Did you know that you can change the background color of your Encounter Digital Implementation (EDI) design window?

Here's how. In your EDI session, enter the following command:

   setLayerPreference bg -color {<color_name>|color_value}

For example:

   setLayerPreference bg -color white

To set it back to the default, use:

   setLayerPreference bg -color black

You can also use color values, like #000000 (black), #ffffff (white), #ff0000 (red), etc.

If you prefer to use color names, like I do, how do you know what names are legal? You can find a list in a file called rgb.txt, which for sun4v machines, should be in the /usr/X/lib/X11 directory, and for lnx86 machines, should be in the /usr/X11R6/lib/X11 directory. Ask your favorite IT person if you need help finding this file. I found mine to have some color names to rival that of the local paint store. (Papaya Whip, anyone?)

Why would you want to change the background color of EDI? Well, although most people are used to the black background, some folks might be used to a white background based on other tools they have used, or a white background might be better for printing out a snapshot of the design, depending on how you print or plot. And some folks just like to be unique and have colors different than everyone else. To those people, I say: don't ever change. You are the ones who make the world interesting and fun!

Thanks to Susan Zhao for the original Cadence Online Support solution.

- Kari Summers

The Zynq Virtual Platform: Not Just for Pre-Silicon

jasona — Wed, 08 Feb 2012 04:29:00 GMT

One of the biggest misconceptions about Virtual Platforms is that they are only useful for pre-silicon software development, and once a chip and board is ready they are quickly discarded. Even after boards are available, Virtual Platforms are valuable for software development. Last week I was talking with an engineer at a company that is working on a new system design and has started Virtual Platform development. He told me that one of the software engineers was working on a demo to showcase their...(read more)

What's Good About Property Changes in DEHDL? The Secret's in the 16.5 Release!

Jerry GenPart — Tue, 07 Feb 2012 16:30:00 GMT

In the 16.5 release, all connectivity changes are stored in the hierarchical block directly in Design Entry HDL (DEHDL). Connectivity changes are basically additions or modifications of components, nets, and pin-net connections. The behavior remains the same as in the pre-16.5 release.

Property changes can be stored directly in the hierarchical block on which the object exists, or at the root (top) level design in context of which the block has been instantiated. Essentially, we’ve simplified the approach for adding properties within and across hierarchical blocks.

Read on for more details…

With the 16.5 release, the Occurrence Edit mode no longer exists and the opf file information is no longer generated. This portion of the DEHDL 16.5 release is the most important change. It is important to understand the concept thoroughly.

When a designer stores a property in a hierarchical block, it is visible in all the instances of the block and any change to the property in the block is propagated to all the instances of the block. In pre-16.5 releases, the designer was able to do this only in Hierarchy mode.

When the designer wants to store a property change only on a particular instance or occurrence of a block, the property needs to be stored in the root (top) level design. In pre-16.5 releases, this level of change was stored in the opf file in the Occurrence Edit mode. In the 16.5 release, this property is stored on the instance in context of the root (top) level design.

Important: With the 16.5 release, Design Entry HDL does a property check of all Cadence properties, to check if any values are incorrectly set in the schematic. Therefore, it is possible that you may get some warning or error messages.

In the 16.5 release, as there is only a single mode of operation, property changes are supported and you have the flexibility of selecting the location for storing property changes. The location where the property is stored is known as the "Source" of the property and it is visible in the attribute form. A new column, Source, has been added to the attribute form. Source displays the name of the block where the property is stored:

When a property is added, the default source for that block/root property is selected. This default is selected based on the type of the block being added (flat, non-replicated, or replicated). At the same time, you can change the source by clicking on the drop down list and selecting another source block/root. Depending on the source, properties are called Occurrence properties or Block level properties.

Now that we are getting the feel of the property changes, let us look at the type of property changes that can be done in the 16.5.

Master Property Change

The Master Property Changes are the changes in the property value that is stored in the block directly. These changes are visible at all instances of the block. This is same as adding the properties in Hierarchy mode operation in pre-16.5 releases.

In-Context Property Change

The In-context property changes are changes in the property value that is stored in the root (top) level design. The property is added on a specific instance (occurrence) of the block and is visible only on this instance of the block. This is same as adding properties in the Occurrence Edit mode in pre-16.5 releases.

The next section covers the different types of designs and the default options that are provided for the source while adding a property.

Adding Properties to a Flat Design or Root (Top) Level Design

Any property that you add in a flat design or root (top) level design is saved as a Block (Master) property by default. As there is only one design level, the property is stored in that design only. Here, you do not have an option to save the property as an Occurrence property.

In the following figure, a new property FOO is added with BLOCK as the value. It is saved with Source as PROCESSOR (i.e. as a Block property). The Source column drop down has only one value, PROCESSOR:

Adding Properties in Non-Replicated Designs

A non-replicated design is a design which contains only one instance of each of the hierarchical blocks used at the top level.

When you add a property to an instance in the non-replicated block, the property is saved as a Master property by default. Since there is only one instance of the block, storing the property as Master or In-context is the same. Hence, the property value is stored directly in the block by default.

It is possible that you would like to add this property only on this instance (occurrence) of the block, while working further in the design you might have to add more instances of this block and you would like to keep the property specific only to this instance of the block. To facilitate this, the designer is provided the flexibility to change the source of the property from the default value of Master to In-context. This can easily be done by changing the default Source from the block name to the root (top) level design name. The drop down list for the Source column provides all the possible design names where the property can be stored:

In the above picture, the GEP is the hierarchical block and DDR is the top (root) level design name. By default, the NEW_PROP will have the source set as GEP, but the designer can change the source to DDR to make this as an In-Context property.

Adding Properties in Replicated Designs

A replicated design contains hierarchical blocks which are instantiated more than once at the top level. When you add a property to an instance in a replicated block, it is added as an In-Context (Occurrence) property by default. This means that the newly added property will have its source set to the root (top) level design. Since there are multiple instances of the block, the property being added is considered to be specific for the instance (occurrence) of the block. Hence, the property value is stored in the root (top) design by default. This property would be available only on this instance of the block and not on the other instances.

Note: When you add an occurrence property on a vectored pin or aliased bus, the property will not be visible in the attribute form. It will only be visible on individual bits of the pin or bus by selecting the show index checkbox.

It is possible that you would like to add this property to all the instances of the block. To facilitate this, you have the flexibility to change the source of the property from the default value of In-context (Occurrence) to Master (block level). This can easily be done by changing the default Source from the root (top) level design name to the block name. The drop down for the Source column provides all the possible design names where the property can be stored:

The following table provides a quick summary of how you can save properties now:

Design	Default property selected	Options to save
Flat Design	Block Level property	Block Level
Non-Replicated design	Block Level property	Block Level or Occurrence Level
Replicated design	Occurrence (In-Context) property	Block Level or Occurrence Level

Editing Existing Properties

When you edit an existing property value, the source with which the property was added is retained. When a Block level property is edited, it is saved as a Block level property. An occurrence property is edited and saved as an Occurrence property.

While editing properties, if you want to change the source of a Block level property to Context property, you can only change it if you have edited or changed the value. If the value is same, the property is considered a block level property. This is applicable for all components, pins, and net properties.

All packaging properties are edited as Occurrence properties as per property changes in the 16.5 release, When a bus property is added to a whole bus in the Constraint Manager (CM) database, it gets added to the bus object. Editing the property on individual bits or partial bus would apply the change to the complete bus.

If a property is applied to a partial bus, it is applied to individual bits in the Constraint Manager database. If you need to change a property value on certain bits of a bus, then it would need to be done as overrides on bus bits. A voltage property can only be edited in the block that it is added for global nets. In case you want to edit the voltage property in some other block, you can set the visibility to value and then edit the property.

Editing Existing Component Properties

On editing an existing property value, the source with which the property was added is retained. When a Block level property is edited, it is saved as a Block level property. When an Occurrence property is edited, it is saved as an Occurrence property. The designer can also change the source of the property by making the change in the block name displayed in the Source column.

Editing Existing Signal Properties

The designer can capture properties on different signals in the design. The signals in a design can be confined to one single level of hierarchy, i.e. the signals are local to the design. Some of the signals go across the deign hierarchy. These signals are interfaces at one level of hierarchy and become block ports at a higher level of hierarchy. Broadly, we’ll refer to such signals as interface signals. There’s another category of signals, which are available across the design and they are not passed around using the block interfaces. These signals are the global signals which exist at all levels of the design. In the following section, we would see how the addition of properties to these different types of signals works in the 16.5 release.

Editing Existing Signal Properties Locally to a block

In a design block, a same signal can exist at multiple places on a single page, or on multiple pages. The signal can also be aliased to some other signal in the design. In each of these cases, there could be one single physical net, which can exist on one or more pages of the schematic block. This single physical net would be containing all the properties for the signal and in pre-16.5 releases, all these properties would be visible only in the Occurrence Edit Mode. In the 16.5 release, there properties would be visible at all times on all the instances of the signal.

If you add a property on a signal on one page and save that page and now go to the next page and check the properties on the same signal there, the newly added property would be visible there. You would also be able to edit this property and modify it to some new value. And on saving this schematic page, the modified value would be available in the attribute form of the signal on any other page of the design.

Adding properties to signals in a hierarchical non-replicated design

In case of hierarchical designs, a signal could be flowing across multiple hierarchical blocks. This signal would have a single physical net name and can be identified by the same name all across the hierarchy. The properties on signals in hierarchical designs would work similar to how they used to operate in the single level of hierarchy. The only difference would come up in cases when there are multiple instances / occurrences of the hierarchal block. In such a case, for each of the hierarchal blocks, the signal would have a unique physical net name and hence properties which are specific to that instance or occurrence of the signal can be different. There could also be some properties captured on the signal as the block level properties, and these properties would be available on the signal in all instances or occurrences of the hierarchical block.

Deleting Properties

All Block level or Occurrence properties are deleted from the source. But, in a scenario where you have both an Occurrence and Block level property on a component, pin or net, and you delete the Occurrence property, the row from the attribute form does not get deleted. The Block level property is rippled to that row. At the same time if you want to delete the block level property, you cannot delete it immediately because the delete button is deactivated. You need to press OK and save the design. After saving the design, if you reopen the Attribute form, the delete button is enabled and you can delete the Block Level property.

Please share your feedback using this significant new working model in DEHDL.

Jerry "GenPart" Grzenia

Customer, Partner DFM Concerns Spur New Methodologies

rgoering — Tue, 07 Feb 2012 14:00:00 GMT

Design for manufacturing (DFM) may not be as "hot" a topic as it was a few years ago - when there were many independent DFM companies - but foundries and chip design companies are in fact very concerned about DFM at 28nm and below. Some of those concerns have given rise to new technologies and methodologies that will be revealed next week (Feb. 12-16, 2012) in Cadence/customer co-authored papers at the SPIE Advanced Lithography conference in San Jose, California.

Philippe Hurat, product engineering director at Cadence, is the co-author of several "design side" DFM papers that will be given at SPIE. All describe engagements that Cadence has had with customers or partners. I talked to Hurat recently to learn more about these engagements and also about advanced-node DFM concerns in general. You can see a list of all Cadence co-authored SPIE 2012 papers (four of which concern computational lithography) in my previous blog post.

Customer Concerns

I asked Hurat what customers and partners are most concerned about at 28nm and below. "It depends on who they are," he replied. "Foundries are generally worried about printability, because a DRC-clean design that doesn't print still produces a bad yield. So most of the time, our work with foundries starts with printability or hotspot detection."

IC design houses, in contrast, are struggling with the integration of lithography or CMP checks into the design flow. A top priority, Hurat said, "is to make them more designer friendly. For the designer, having to run a DFM tool is a burden. So the easier you make it, the faster it is and the more automated, the less disruptive it is."

Moreover, he noted, variability has a big impact. At 28nm and even more so at 20nm, stress can cause significant timing variability, and layout dependent effects (LDE) become critical - that is, transistor performance will vary according to what is placed near it in the layout. Custom designers, library developers and chip designers must analyze and mitigate the impact on timing.

The Design House View

One of the SPIE DFM papers, In-design hierarchical DFM closure for DFM-clean IP, describes work that Cadence did with Freescale on manufacturability checks for litho and CMP at 28nm. "When you develop an IP block you want to make sure it is litho and CMP clean," Hurat said. "So we worked with Freescale to develop IP integration that fits their needs, and the paper will explain those requirements and how we achieved them for both litho and CMP." He explained that "CMP clean" is a tough requirement because CMP, unlike litho, has an effect over a large area that might go beyond the IP itself.

A second Cadence-Freescale paper is titled Analysis of layout-dependent context effects on timing and leakage at 28nm. This paper notes that at 28nm, the context - the layout surrounding a cell - impacts the timing and leakage of a cell due to stress and other LDE. It is one of several SPIE papers that describe the use of the Cadence Litho Electrical Analyzer (LEA) to analyze variability.

Another paper that discusses LEA and LDE is co-authored with Cambridge Silicon Radio and is titled Analysis, quantification, and mitigation of electrical variability due to layout-dependent effects in SoC designs. While the Freescale LDE paper is more focused on leakage and silicon results, the Cambridge Silicon Radio paper is primarily concerned with delay and mitigation strategies.

The Foundry View

Cadence and Samsung are presenting a paper titled In-design process hotspot repair by pattern matching. This paper demonstrates a pattern-based approach for hotspot repair developed by Samsung that is much faster than traditional lithography simulation. Hurat noted that Cadence provided the entire flow, from pattern creation to pattern detection and hotspot fixing in place and route. (Note: The Cadence-Samsung partnership in DFM is further described in a Feb. 6 press release).

Finally, Cadence and GLOBALFOUNDRIES co-authored a paper titled Electrical design for manufacturability and layout-dependent variability hotspot detection flows at 28nm and 20nm. This paper is aimed at custom/analog design with the Cadence Virtuoso platform, and it shows that lithography as well as stress is a major source of LDE variability.

For more information about the Cadence co-authored papers, click here. A complete SPIE program is located here.

On the Manufacturing Side

In addition to these DFM papers, the above links will show you four papers that describe work that Cadence has done with partners on the "manufacturing" side of DFM (or, "computational lithography"). As Hurat noted, this is originally what SPIE was all about - design-side DFM was only added recently. Topics of the computational lithography papers include model calibration, source-mask optimization, self-aligned double patterning, and lithography target optimization.

If you're interested in DFM from any angle -- design or manufacturing, foundry or design house, custom/analog or digital -- SPIE 2012 is the place to be next week.

Richard Goering

Does Substrate Biasing Have a Future?

Pete Hardee — Mon, 06 Feb 2012 23:06:00 GMT

At Cadence, we often get asked about various low-power design techniques: how well they work, what are the implementation and verification issues associated with them, and how effective they are at various process nodes. As a general trend we see aggressive power reduction techniques being adopted more widely as many designs, and by no means only mobile designs, become increasingly power-sensitive. But while many advanced techniques (which we take to be the ones applied to power domains, such as power shut-off, as opposed to well-established optimizations like clock gating) are clearly growing rapidly in adoption, some less well-known techniques only seem to find favor with a few, and it's less clear whether adoption is increasing.

In particular, it's widely believed that substrate biasing (AKA body biasing) gives a lesser return in more advanced process nodes (45/40, 32/28 and beyond). What's the latest we're hearing about this?

First the stats...

When we delivered live full-day low-power "Tech on Tour" symposiums around the world in late 2010 and early 2011, we met with over 500 designers interested in low power design. That gave us a great opportunity to survey them. Here's what we found for the adoption of low power technqiues: Biasing is currently used by 5% of our sample of designers, and expected near-future use is 17%. In comparison, for power shut-off, we found the technique in use by 51% currently and 68% in the near future. That would certainly imply the technique's adoption is growing.

Now the anecdotal evidence...

Here's what has been heard by a few of our low power experts worldwide when discussing biasing with customers:

The top two reasons against using substrate biasing are bias supply routing congestion (which increases at more advanced nodes); and difficulty of generating all the bias supplies.
Mobile device SoC's at advanced nodes need all the low-power techniques at the designer's disposal, including biasing, according to one major mobile SoC platform provider. Another provider sees their ability to widely-apply substrate biasing in their libraries and process as a significant differentiator.
Some customers who do not apply biasing to the whole chip below 45/40nm instead apply the technique in conjunction with low voltage standby modes, especially in memories.
At least one customer who used biasing successfully in a 90nm chip is applying biasing successfully to their next generation at 45nm, while another company using forward and reverse biasing in volume at 90nm struggled to meet timing in the next generation at 65nm.

Future of substrate biasing:

Substrate biasing is useful primarily to control leakage at near-threshold voltage in planar CMOS. When FinFET becomes the norm (already used in some 22/20nm processes and will become commonplace for the 14nm node), leakage is better controlled by the gate's 3-D topology and many experts believe use of substrate biasing is unlikely to offer further benefit.

Current support for substrate biasing in the Cadence Low-Power Solution:

Regardless of whether you believe substrate biasing is worth the effort, be assured that the technique is fully supported in Encounter Digital Implementation System and Conformal Low Power. However, please ensure it is also supported by your library provider and foundry.

If you have any experiences to share about substrate biasing or any thoughts on its future, we'd be happy to hear them!

Pete Hardee

Webinar Report: New Methodology Revs Up Code Coverage Analysis

rgoering — Mon, 06 Feb 2012 14:00:00 GMT

Most IC verification teams use code coverage as signoff criteria, but they often have limited information about unreachable code. A new "case-splitting" methodology, described in a recently archived webinar, shows how a technique based on formal analysis provides new insight into coverage holes -- while requiring no understanding of formal analysis.

The webinar is titled "Simplifying Code Coverage Analysis: Automatically Separating the Wheat from the Chaff." It was presented by Joe Hupcey, Cadence product marketing director, and Jose Barandiaran, senior member of consulting staff.

Barandiaran began the webinar by talking about the "dead code challenge." There are two causes of unreachability, he noted. One is that the code is "illegal" in the sense that it was never intended to execute - perhaps the code came with externally acquired IP and the system doesn't use that particular functionality. That's generally okay. The other cause is that the code is supposed to be functional, but it's unreachable. That is not okay.

Are Coverage Holes Reachable?

However, it is often difficult to determine whether coverage holes are unreachable. That's where the case-splitting technique comes in. It leverages formal analysis (using Incisive Formal Verifier or Incisive Enterprise Verifier) "under the hood" to determine if holes are reachable. It's an automated flow in which properties are automatically generated, and no knowledge of formal analysis is required.

The diagram below shows how it works. You pass a simulation coverage database to the formal engine, along with a reused, or newly created, simulation snapshot. You select either module or instance-level analysis, and identify the code coverage targets for the formal engine to analyze. The formal tool generates the properties and runs them. The tool then reports unreachable holes, and back-annotates them into the coverage database so you can go into a reporting tool later and analyze each one, determining whether they represent code that's supposed to be functional and thus needs to be fixed.

Barandiaran noted that there are some performance tradeoffs to consider. Out of the box, this flow will run without any constraints, and it will run uninitialized. That's the fastest approach but it may also miss some unreachable coverage holes. You can dial up the constraints and/or initialization and run more slowly, but hit more unreachable holes.

In one customer example shared during the webinar, an uninitialized run on a design with 40K state bits uncovered 773 coverage holes in 2.8 hours, with 7.6% of the holes unreachable. An initialized run found more unreachable holes (10% of 773), and ran for 35 hours. However, this run time was cut to 5 hours because the flow was distributed over a CPU network.

This example, and others presented during the webinar, shows that this case-splitting methodology is in use today by customers. "This has been exercised in the field. It's not just some lab experiment. It really works quickly and cleanly, and you get the data in a very straightforward manner," Hupcey said.

The webinar also included a demo, in which it took only a few minutes to find 33 coverage holes, of which 9 were unreachable. "If you have the tools already, this is really a no-brainer," Barandiaran said.

The webinar is available to Cadence Community members here (quick and easy free registration if you're not a member). If you already have the Incisive Enterprise Verifier, see chapter 5 of the user guide for an explanation of the case-splitting technique.

For those who want to know more, a paper from CDNLive! India 2011 details Freescale's experience with the case-splitting technique. It is available to Cadence Community members here. Look for session 1.6 under track 1, Silicon Realization: Functional Verification.

Richard Goering

Panelists: Bridging the Gap Between Analog and Digital Design

rgoering — Thu, 02 Feb 2012 00:00:00 GMT

Analog and digital designers have lived in separate worlds for a long, long time. They use different methodologies and tools, and while digital design is heavily automated, analog design is not. But mixed-signal integration will force this gap to narrow, opening the door to new methodologies and better collaboration, according to panelists at the DesignCon conference Jan. 31.

The panel was provocatively titled "Is it Time for an Analog Comeback?" and was moderated by Brian Bailey (right), contributing editor at EDN. Panelists were as follows:

Harold Joseph, director of PSoC analog, Cypress Semiconductor
Jeff Miller, director of product management, Tanner EDA
Navraj Nandra, director of marketing for analog/mixed-signal IP, Synopsys
Mladen Nizic, engineering director for mixed signal, Cadence
Warren Savage, CEO, IPextreme

Bailey opened the discussion by describing the status quo. "In the past analog and digital were really kept separate," he said. "It really was an oil and water situation." There are many differences between the two worlds - digital design is top-down, analog is bottom-up; digital is automated, analog is primarily manual. "There are so many areas of conflict between [analog and digital] that they are almost antagonistic to each other, especially when put in the proximity of a chip," Bailey said.

He noted, however, that 70% of IC designs today are mixed-signal, and that figure is increasing. "We have to start thinking about how we play together as a team rather than as pieces that are forced to come together," Bailey said. And that challenge set the stage for the following discussion.

Why Hasn't Analog Kept Up?

In his opening remarks, Miller (Tanner EDA) asked, "why hasn't analog design kept pace? The main thing is that the process for analog design is totally different from digital, and there has been no significant automation such as the place and route technology that has revolutionized digital." Miller said, however, that he sees a "bright future" for mixed-signal design in two respects - integration into large SoCs, and the addition of digital content to traditional "analog only" chips.

Nandra (Synopsys) spoke of some of the challenges that analog IP developers are encountering, such as the need to integrate analog components onto chips at advanced process nodes. For example, restricted design rules at these nodes limit the way full-custom devices can be placed and routed. He also noted that some system specs don't change with scaling - USB still requires a 5V signal to charge the battery, a challenge for advanced-node SoCs.

Nizic (Cadence) observed that some design teams are seeking to "economically" design mixed-signal SoCs at advanced process nodes, while others are working to bring more digital functionality, such as microcontrollers, into "mainstream" analog ICs at mature process nodes. Previously, he noted, analog circuitry might have taken 15-20% of the area of an SoC; today, at advanced nodes, it's likely to be 50%. And most of those SoCs use low-power design techniques, making things even more challenging.

"Many different skills are required to realize a design in silicon, and it is important that people with these skills work as a team," Nizic said. "Does it mean everybody has to become a mixed-signal designer? Certainly not." He noted that "we are striving to bring more unified technologies and highly integrated tools to enable that cooperation."

While other panelists talked about increasing mixed-signal integration, Savage (IPextreme) observed that many analog functions are still implemented off-chip, and he said he's seeing a trend towards "separation" of analog and digital. "Ten years ago we were talking about integrating everything into an SoC. That's true to an extent but I'm also seeing companies that are re-segregating." Savage said that 3D-ICs will offer the "best of both worlds" by integrating digital SoCs with optimized analog dies.

Following are answers to several questions posed to panelists.

Q: Do We Have Enough Analog Designers?

Miller: "There is great difficulty in training analog designers. It's not like digital where you learn the tools and you're sort of set. There's a lot of art in creating an analog cell."

Nizic: "We do have to nurture that [analog] skill. It does require more understanding of device physics to design good circuits. We need tools to make it easier. Reuse is very important as well."

Nandra: (Describing the design of PHY IP in 50 different process nodes) "It doesn't require genius engineers. What it requires is more like a factory to be able to stick to the same specs, but to design that [PHY] in different process nodes."

Q: Is There Any Hope for Analog Automation?

Nandra: "When building baseline transistor cells, we hide a lot of the process effects from engineers...In advanced nodes, we get a lot of EM problems because metal lines are thinner. Somehow we have to figure out how much current goes through these metal lines. That's a technique that can be automated."

Miller: "Selling automation to an analog design team is very difficult. You really need to give them control and try not to take too many pieces away."

Nizic: "Traditionally we assumed that analog is bottom up and digital is top down, but we are looking at mixed-signal systems now, so we really have to combine these approaches...We do have a lot of automation in our tools."

Savage: "Analog is an old school discipline...it is very hard for EDA companies to make tools that replicate the expert engineer, like we did 15 years ago with digital synthesis."

Q: In the Digital World We Talk about Verification Taking 70% of the Effort - Is This True in Analog?

Nandra: "It's not far off in that perspective, but the color of verification is different...our customers want to see the silicon characterization."

Nizic: "We need to distinguish functional verification from signoff verification. We need to invest more in analog/mixed-signal functional verification. I see more and more adoption of digital techniques like coverage driven verification and random stimulus. This combination is really needed."

Conclusion: Is it Time for an Analog Comeback?

Nandra: "Analog never disappeared. I disagree with Warren's comment about the ‘old school of analog.' I think there is a very exciting new school of analog that's a lot more interesting than some innovations in digital."

Joseph: "We're starting to see SoCs address some issues, but we've never seen analog go away."

Savage: "Analog never really went away. One big change today compared to when I was a younger engineer is that analog is sexy now."

Miller: "There have been historical shifts. I do think the pendulum will swing back a bit and we'll try to do things in analog if at all possible."

Nizic: "Analog never really went away. SoCs have more and more mixed signal content. This is a window of opportunity for better methodologies."

Bailey: "I conclude that analog is a place for renewed innovation and renewed differentiation, and it's sexy again."

Richard Goering

What's Good About PCB SI Signal Integrity Application Mode? It’s in the 16.5 Release!

Jerry GenPart — Tue, 31 Jan 2012 16:00:00 GMT

In release 16.0, the concept of Application Modes was introduced. These application modes are used to set up the tool for specific tasks. The existing applications are General Edit, Etch Edit, and Placement. In 16.5, the Signal Integrity (SI) application mode has been added to be used for high-speed related tasks.

An Application Mode is a “super command” telling Allegro the general function area the user will be working in, and includes the following related functionality:
•    Highlighting objects on hover
•    Context sensitive RMB menus
•    Auto-execution of default commands on double-click or drag of an object
•    A limited Find Filter

Read on for more details …

There are six different methods for accessing App Modes.

One is through the User Preferences Editor (Setup > User Preferences). This sets the App Mode to start when an Allegro editor opens:

The other five are all accessible from within the canvas and impact the current session:

The SI application mode behaves in a manner similar to other application modes, but is only available when an SI license is available while in Allegro PCB Editor. If you are currently using Allegro PCB GXL and then select the SI app mode, the tool will stay in the same editor and the SI license will be checked out only when an SI feature is used.

This feature is defined mostly in context sensitive menus in order to perform SI specific tasks but can also be seen in different datatips content by default and double click command on certain objects.

The following picture shows the Right Mouse Menu in SI application mode when invoked from the empty canvas:

Quick Utilities

The Quick Utilities sub-menu is shown below:

Context Sensitive Menus

In the SI Application mode, when you right click on an object, the content of the menu is adapted to the object and what you most likely want to do.
The following context sensitive menu are displayed on the right mouse button (RMB) menu for the listed objects:

Automatic execution of commands

In addition to the context right mouse button menu, the application mode sets up commands that are automatically executed on certain objects (actions are with the left mouse button):

The three items in bold italics under the Double-Click column are unique to the SI App mode. The rest overlap with other App Modes.

Please share your experience with this new capability.

Jerry "GenPart" Grzenia

Whitepaper: Verification Performance is More Than Raw Simulation Speed

rgoering — Tue, 31 Jan 2012 14:00:00 GMT

RTL and gate-level simulation have been the workhorses of the IC verification environment for 25 years, and they're orders of magnitude faster than they used to be. But as chip complexity skyrockets and process nodes shrink, a continuous cry arises from verification teams - "make it faster, please!" As a recently published Cadence whitepaper shows, verification turn-around time does require faster simulation engines, but it involves much more than that.

The whitepaper is titled "Hardware Simulator Performance Scaling to Meet Advanced Node SoC Verification Requirements." It shows what is necessary to improve verification productivity for advanced-node chips, and notes recent improvements in the Incisive Enterprise Simulator that are aimed at performance scaling. The paper advocates a project-specific, "systematic" approach in which users first analyze the design and verification requirements to identify possible improvements. With significant testbench or design changes, a detailed profile is necessary to identify performance bottlenecks.

The whitepaper notes briefly that one way to increase verification turn-around time is to move to a higher level of abstraction, such as transaction-level modeling (TLM). There are also mentions of formal verification, acceleration, and emulation as productivity boosters. But for the most part the whitepaper focuses on how to get better and faster results with RTL and gate-level simulation.

Speeding Up the Core Simulator

What can be done to speed up the core simulator? Quite a lot, actually. The whitepaper describes some improvements made to the Incisive Enterprise Simulator during 2011, including:

Assertion-based verification - A single finish for each cover property, optimizations focused on SystemVerilog assertions (SVA) sequence operators, and performance controls speed both subsystem and full SoC verification.
Gate-level simulation - Complex expressions in timing outputs have been optimized.
Coverage - Optimizations for mixed-language dumping, dynamic SystemVerilog objects, and toggle coverage contribute to runtime improvements; other optimizations minimize memory usage.
Power-aware design - A native low-power solution has marginal overhead during both elaboration and run time.

The whitepaper shows how to configure a simulator for speed by arriving at the best tradeoff between performance and debug access. By default, Incisive runs in a fast mode with minimal debugging capability. Some debug options should be applied selectively rather than locally, or should not be used for regression.

The whitepaper also notes how CPU, cache, memory, storage, network, and operating system affect performance. (Note: I wrote recently about how Cadence IT experts are helping customers with these kinds of issues). The whitepaper recommends that project teams profile the simulation environment regularly, and shows how this is done.

Advanced Node Verification Requirements

While tuning the simulation engine can provide single-digit performance multiples, the whitepaper notes, advanced-node teams really need to focus on turn-around time at each stage of verification. Quite often the elaboration phase consumes significant time. Incremental elaboration is an Incisive feature that can help.

Turnaround time affects each verification stage for advanced node SoCs

The whitepaper also shows how dynamic reseeding saves regression time. It notes how multi-core operation speeds regression runs. It concludes with a discussion of the productivity gains provided by formal verification and hardware-based acceleration.

In short, this whitepaper is a great read for anyone who wants a more productive verification environment. Turn-around time, adequate coverage, and quality of results are the real goals - and "wall clock" time on a simulator is a means to get there, but is by no means the entire picture.

For further perspectives, see Adam Sherer's recent blog post.

Richard Goering

System-Level Design and the Waves of EDA

fschirrmeister — Mon, 30 Jan 2012 17:00:00 GMT

Before January comes to an end it is time for my annual flashback and brief reflection on where we are in system-level design, and a look at how the state of today compares to the predictions we made 10 years ago. 2011 was an interesting year for system-level design. In May Cadence announced its participation in the system-level domain with the System Development Suite. The year before, in 2010, we had seen consolidation in the virtual platform space with Synopsys picking up VaST, CoWare and Synfora...(read more)

Incisive Performance Scales to Meet Advanced Node SoC Verification Requirements

Adam Sherilog — Mon, 30 Jan 2012 14:00:00 GMT

Its’ all about RTL simulation. I mean gates. I mean turn-around-time. Project-level productivity. Mixed-signal. Low-power. UVM. And. And. And. … And the reality is that advanced node SoCs are so complex that it is truly about all of these. Our new white paper details a systematic approach to verification performance you can use immediately at all levels from core simulation to advanced technologies and methodologies.

For certain, the most common use of simulation is RTL and gate-level simulation. During 25 years since the start of the RTL era, Moore’s law has held true as designs have doubled every 24 months. While the design work is still all done in IEEE 1076 and 1364 (+1800 since 2005 and now some 1666), verification productivity, predictability, and quality is now derived from an ever-increasing suite of standard languages and methodologies. The result is that the typical simulation run today employs a wide range of features beyond RTL and gate.

That history lesson is probably common knowledge, but how to deal with the performance requirements of advanced node SoCs isn’t. Because of all the complexity, the simulator has to be measured in multiple ways to build-in the best performance. That will give us a fast simulator, but if we run that simulator using the golden scripts we created years ago the effect on this fast engine is akin to strapping model-T tires on an F1 car. After we’ve got all the elements of our simulation balanced for performance, it’s time to dig deeper into the code we’re running on the engine. Sure, that code is running accurately, but is it running efficiently? The simulator is just going to execute the code we provide, so we need to profile our code and find algorithms that get the same task done but do it faster. We introduce this last concept in the white paper, but that’s a teaser for a DVCon 2012 SystemVerilog performance paper. Stepping back from profiling, keep watching this blog stream for application notes that will help you implement the ideas in this core simulation section of the white paper.

Now that your simulations are running fast, where do you go to get even more performance? The “Advanced Node SoC Verification Requirements” section of the white paper introduces several technologies and methodologies that, with varying degrees of investment, can provide substantial improvements in performance and productivity. If you are at or below 40nm, or planning to go there, pay careful attention to this section and the Advanced Verification Topics book to understand the options you have for further performance improvements.

When Cadence pioneered commercial simulation with Verilog-XL 25 years ago, life was simple. Chips were designed in schematics, and RTL and gate simulation was all we needed. Simulation has come a long way from those days and is even more relevant in today’s complex chips. This white paper will help you understand how the Incisive Enterprise Simulator has adapted to today’s advanced node SoCs and how it will continue to scale for tomorrow.

=Adam Sherer

Interested in Low Power, Mixed Signal, SystemC Verification? Here’s What to See at DVCon

rgoering — Mon, 30 Jan 2012 14:00:00 GMT

DVCon, the premier conference for IC and systems verification, will be held Feb. 27- March 2 at the Doubletree Hotel in San Jose, California. This year's conference makes it clear that functional verification isn't just about digital RTL anymore. In fact, there's quite a bit of content in three increasingly critical areas for system-on-chip (SoC) design - low power, mixed signal, and the move to a higher abstraction level with SystemC.

Following are some suggested events in each of the three areas noted above. This is not a complete conference schedule - for that, see the DVCon web site. That is also where you'll find registration information. In addition to the paid conference passes you can get a free Exhibits Only pass that includes both of the scheduled panels and the keynote speech.

Transaction Level Modeling, SystemC, and HW/SW Co-Verification

North American SystemC Users Group 17^th meeting - Monday Feb. 27, 8:30 am - 12:00 pm. Speakers from Texas Instruments, Doulos, University of Paderborn, Cadence, University of Pennsylvania, Duolog. FREE registration at http://www.nascug.org/.

Town Hall Lunch with Accellera Systems Initiative - Monday 12:00 pm - 1:00 pm. Stan Krolikoski of Cadence, Accellera Systems Initiative secretary, will host this open meeting to answer the question, "What will success for the Accellera Systems Initiative look like?"

Last year's Accellera - OSCI "Town Hall" meeting at DVCon

Tutorial: An Introduction to IEEE 1666-2011, the New SystemC Standard - Monday 1:30 pm - 5:00 pm. John Aynsley of Doulos gives a detailed view of the revised standard.

Co-located Meeting: Hardware/Software Co-Design from a Software Perspective -- Monday 6:00 - 8:30 pm. Sponsored by EDAC Emerging Companies Committee.

Session 3: SystemC and Beyond - Tuesday 9:30 am - 11:00 am. Papers from University of Paderborn, PMC-Sierra, and Paneve LLC.

Session 7: Verification and Debugging Tips - Wednesday 8:00 am - 10:00 am. Includes Cadence paper on memory debugging of virtual platforms with TLM 2.0.

Panel: Build or Buy - Which is the Best Practice for Hardware-Assisted Verification? Wednesday 3:30 pm - 4:30 pm. Brian Bailey moderates this panel on emulation and FPGA-based prototyping. Panelists from Qualcomm, ARM, SpringSoft, Xilinx and Cadence discuss the tradeoffs between these solutions and the pros and cons of purchasing versus building in-house.

Low-Power Design and Verification

Session 1: Low Power Techniques - Tuesday 9:30 am-11:00 am. Charles Dawson of Cadence moderates the first conference session with presentations from Mentor Graphics, Cadence and Synopsys. Cadence paper focuses on low-power equivalence checking.

Cadence Sponsored Lunch - Earn Your Degree in the Low-Power Arts and Sciences. Tuesday 12:30 pm - 2:00 pm. Cadence and user experts will lead verification engineers and managers in a lively low-power discussion.

Mixed-Signal Verification

Poster Session 1 - Tuesday 10:30 am - See Cadence papers on "PSL/SVA assertions in SPICE" and "New challenges in verification of mixed-signal IP and SoC design."

Session 6: Mixed-Signal Verification - Tuesday 11:00 am - 12:30 pm. Papers from Maxim/Cadence, Infineon, Mentor Graphics. Maxim paper provides a case study of applying UVM-MS to a complex mixed-signal SoC design.

Session 8: Getting to Coverage Closure - Wednesday 8:00 am - 10:00 am. Includes Cadence paper on "Bringing continuous domain into SystemVerilog covergroups."

And Wait - There's More

More traditional verification topics (I'm including "formal" in this category) will also get thorough coverage at DVCon. Here is what you can expect.

Monday Feb. 27 features a full day of Universal Verification Methodology (UVM) tutorials, an introduction to the Unified Coverage Interoperability Standard (UCIS), and a tutorial on verification automation using IP-XACT.

Tuesday Feb. 28 includes sessions on UVM Techniques, Verification Benchmarking, and Formal Techniques. Exhibits run 3:30 - 6:30 pm. Speakers for a "Big Wigs" panel at 2:30 pm had not been publicized at the time of this writing (check back here).

Wednesday March 1 includes sessions on Verification and Debugging Tips, Coverage Closure, UVM in a Multi-Platform World, UVM Stimulus Generation, Verification Case Studies, and SystemVerilog Tips and Techniques. The keynote address will be given by Aart de Geus, Synopsys CEO. Exhibits run 4:30 - 7:00 pm.

Thursday March 2 concludes the conference with half-day tutorials on formal analysis "apps" (sponsored by Cadence), verification of multi-core SoCs, leveraging formal verification throughout the design cycle, and verification IP productivity.

See you at DVCon!

Richard Goering

Things You Didn't Know About Virtuoso: We've Got You Cornered

stacyw — Thu, 26 Jan 2012 17:26:00 GMT

One of the big buzzwords around the EDA world these days is "variation." Don't you just love buzzwords? Take a perfectly normal, slightly ambiguous word, capitalize it, add a another slightly ambiguous hyphenated suffix, and suddenly you've just solved a new problem for your customers. "Interface-driven'' "user-centric'', "platform-based" and "variation-aware."

Well, I'm not here to sling buzzwords. I'm here to help you find ways to make better use of our software so you can deal with the actual situations you have to face every day. And, of course, "variation" does exist. It exists in all sorts of forms in all parts of the design process. So today, let's talk about one of the most basic forms of variation you've been dealing with in design for years. Corners.

Specifically, I'd like to cover some of the features in Virtuoso IC6.1.5 which help you set up and run the massive number of corner combinations you have to define to verify your designs today.

First, it helps to realize that our definition of a "corner" can encompass any sort of variation you can define in ADE XL. It's not just limited to your classic PVT. You can create corners using any design variables, device parameters (to be the subject of a future article), or combination thereof. You can even create statistical corners based on sample points from Monte Carlo analysis (yet another future article).

The ability to create corners in many different ways opens the door to lots of efficient methods of circuit analysis.

But first, you've got to set them up.

If you're using IC6.1.5, you'll have noticed that we redesigned the Corners Setup UI. The basics of using the new form are covered in this video and this video. (And, of course, in the documentation.) The videos explain how to create corners, model groups and corner groups, as well as how to copy corners and enable or disable individual corners and corner groups for each simulation testbench.

Instead of repeating those topics here (you can always just watch the videos), I'll introduce some new features that have been added in recent ISR releases of IC6.1.5. Everything described here is available in ISR6 (released in Sept. 2011) or later.

Selective Corner Group Expansion

Rather than just expanding a group of corners completely, such that each column contains only one combination of values, you can now expand a corner group based on one or more selected parameters. There are 2 options for this. The first is similar to the original full corner group expansion, only you use just a selected set of parameters. Those parameters will be combinatorially expanded. The rest will remain as they were.

For a simple example, if I start with Temperature=0,100 and VDD=1.7,1.9 (a group of 4) and I select to expand based on VDD, I'll get one group with Temperature=0,100 and VDD=1.7 and a 2nd group with Temperature=0,100 and VDD=1.9.

The 2nd option is what we call a parametric set (ParamSet) expansion. For this case, each selected parameter must have the same number of values, then the corner group is expanded using the 1st value of each parameter, the 2nd value of each, and so on. Other values remained grouped as they were.

Using the same simple example, if I start with Temperature=0,100 and VDD=1.7,1.9 (a group of 4) and I select both Temperature and VDD for ParamSet expansion, I'll get one corner with Temperature=0 and VDD=1.7 and a 2nd group with Temperature=100 and VDD=1.9.

Bonus Tip: Once you've set up a lot of corners and corners groups, you can select their columns in the Corners Setup form and choose RMB->Create Corner Group. The tool will collapse the columns down, combining common variable values, into the smallest possible number of corner groups. This makes your corners setup much easier to manage.

Extra Bonus Tip: After you've gone through all this great work, you'll probably want to reuse these corner definitions for other designs. Simply use the Save icon at the top of the Corner Setup form to save them to a file. You can use the Load icon to load them in the next design, or use the cdsenv variable:

envSetVal( "adexl.gui" "defaultCorners" 'string "myDefaultCorners.sdb" )

in your .cdsinit file to have the same corners setup every time you create a new ADE XL view.

The ability to create, group and expand corners to suit different design needs makes it much easier to perform all your circuit verification and analysis.

Stacy Whiteman

Video Killed The Reference Manual Star

TeamVerify — Thu, 26 Jan 2012 14:00:00 GMT

[Preface: recall the melody of the Buggles' 1979 hit "Video Killed the Radio Star" as you read the following]

Q: What is your favorite pastime?

A: Reading reference manuals!

No? Really?

OK -- with all due respect to our Tech Pubs team, virtually no one wants to sit down and read reference manuals if they can help it. And in a perfect world, it should not be required in the first place. Alas, our world is not perfect, but that should not preclude us from striving toward Nirvana.

And thus, I assert that for many, a good picture says more than a thousand words. It is a cliché, but it is true. However, even the most complete infographic might not always be sufficient to convey a concept or feature - particularly if you do not have someone providing verbal context to the picture. Thus, moving pictures -- videos -- can convey certain concepts more effectively and will have a longer lasting (memorization) effect than a reference manual.

Hence, Team Verify has produced the following series of short, focused videos on various aspects of formal and ABV techniques. All of them are short (around 5 minutes) and focused -- we've posted the "Introduction to Assertion-Driven Simulation" to give you an exact idea of what you can expect. The rest of the videos require a Support login ID only.

Assertion Driven Simulation
Introduction to Assertion-Driven Simulation (YouTube-based sample)
Soft Constraints in Assertion-Driven Simulation
Dead Ends in Assertion-Driven Simulation
Seeds in Assertion-Driven Simulation

Tool Basics
Introduction to Interactive Properties
Local Property Distribution
Property Distribution using LSF
Engine Distribution
Introduction to Cutpoints
Introduction to Initialization
Localization Abstraction & Halo

Concepts
Introduction to Cranks

Methodology and Flows
Introduction to Formal Scoreboarding
Introduction to the Coverage Unreachability flow

Enjoy!

Axel Scherer
Solution Architect
For Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

UVM: "Everything that Can be Invented Has Been Invented" Not True!

Adam Sherilog — Thu, 26 Jan 2012 14:00:00 GMT

Much like Charles Duell's famous 1899 quote**, the notion that the Universal Verification Methodology (UVM) is the be-all and end-all of verification methodology is an urban legend. The new Advanced Verification Topics book dispells this myth with five topics that describe methodology layers that build on the UVM to serve the requirements of advanced node SoCs.

The Accellera Systems Initiative UVM is gaining great momentum in the industry. From the Cadence perspective, our customers starting new SystemVerilog projects are doing so with UVM, and those starting new e projects are doing so with our e-based equivalent. Those customers are enjoying the reuse that is built into the UVM and the Cadence differentiators that work with the UVM like verification IP and debug. But the wise verification lead faced with low-power, massive designs, multi-language IP, and more challenges that seem to be prevalent at 40nm and below is asking -- what's next?

The Advanced Verification Topics book describes what's next. The five chapters, expertly described by Richard Goering in his blog, introduce methodologies that will improve productivity, predictability, and quality building on the UVM methodology base. Verification engineers reading this book will gain an appreciation for the work that needs to be done to implement these methodologies and the potential gains they represent.

In stark contrast to Mr. Duell's quote, Cadence has only just begun. Watch us in 2012 as we introduce several other topics and expand the languages used in our examples. We have a bigger boast for verification -- everything that can be invented WILL be invented and quite likely it will be from the engineers at Cadence.

=Adam Sherer, MS EE, BS EE, BA CS

** Note: Dennis Crouch's research suggests the quote actually comes from a 1899 humor magazine that described a fictitious exchange between a genius and a young lad at the patent office.

SPIE Papers Showcase DFM and Lithography R&D

rgoering — Thu, 26 Jan 2012 14:00:00 GMT

Ten Cadence papers planned for the upcoming SPIE Advanced Lithography conference, set for Feb. 12-16 in San Jose, California, demonstrate recent R&D developments in both "design side" design for manufacturing (DFM) and the computational lithography that takes place during the manufacturing phase. The papers will be given Feb. 14-16 and are all co-authored with customers or partners.

According to Manoj Chacko, product marketing director at Cadence, "design side" DFM includes such topics as layout-dependent effects (LDE) and electrical variability for custom and digital designs, pattern matching based in-design DFM signoff, in-design litho hotspot repair, in-design chemical mechanical polishing (CMP) analysis, and hierarchical closure for IP blocks.

As reflected in the SPIE 2012 papers, Cadence R&D efforts in DFM have focused on quantifying the impact and minimizing the differences caused by LDE, building the yield detractor pattern infrastructure for leveraging pattern matching for litho signoff, estimating CMP effects for IP blocks, and allowing signoff-quality analysis during the design phase (see my earlier post on in-design DFM signoff here).

Computational lithography, which takes place after design rule checking (DRC), includes double patterning, source-mask optimization, and optical proximity correction (OPC) including OPC verification. Chacko said that Cadence is using "third generation" inverse lithography techniques to boost OPC, providing high-capacity full-chip dense OPC verification, and offering accurate model calibration. Cadence also does source and mask optimization concurrently.

The ten Cadence co-authored papers are listed below. Note that SPIE is organized into different "conferences" in such areas as extreme ultraviolet lithography (EUV), metrology, advanced lithography, DFM, and advanced etch technology. A complete SPIE program is located here. To read abstracts of these papers, click here.

SPIE Papers - Design Side DFM

Analysis, quantification, and mitigation of electrical variability due to layout-dependent effects in SOC designs
Paper 8327-14 of Conference 8327
Date: Wednesday, 15 February 2012
Authors from Cadence, University of Southampton, and Cambridge Silicon Radio

Electrical design for manufacturability and layout-dependent variability hotspot detection flows at 28 nm and 20 nm
Paper 8327-40 of Conference 8327
Date: Wednesday, 15 February 2012
Authors from Cadence and GLOBALFOUNDRIES Singapore

Analysis of layout-dependent context effects on timing and leakage in 28 nm
Paper 8327-17 of Conference 8327
Date: Wednesday, 15 February 2012
Authors from Cadence and Freescale

CMP effect due to perimeter: a perimeter drive dummy fill optimization approach
Paper 8327-37 of Conference 8327
Date: Wednesday, 15 February 2012
Authors from Cadence and Samsung

In-design hierarchical DFM closure for DFM-clean IP
Paper 8327-31 of Conference 8327
Date: Wednesday, 15 February 2012
Authors from Cadence and Freescale

In-design process hotspot repair by pattern matching
Paper 8327-27 of Conference 8327
Date: Thursday, 16 February 2012
Authors from Cadence and Samsung

SPIE Papers - Computational Lithography

Model calibration and full-mask process and proximity correction for extreme-ultraviolet lithography
Paper 8322-55 of Conference 8322
Date: Thursday, 16 February 2012
Authors from Cadence and Applied Materials

Self-aligned double patterning (SADP) compliant design flow
Paper 8327-5 of Conference 8327
Date: Wednesday, 15 February 2012
Authors from Cadence and GLOBALFOUNDRIES

Free form source and mask optimization for negative-tone resist development for 22nm node contact holes
Paper 8326-31 of Conference 8326
Date: Wednesday, 15 February 2012
Authors from Cadence, Applied Materials, and FUJIFILM Electronic Materials)

Lithography target optimization with source-mask optimization
Paper 8326-100 of Conference 8326
Date: Wednesday, 15 February 2012
Authors from Cadence and GLOBALFOUNDRIES

Cadence will be holding private briefings and demonstrating DFM and lithography solutions Feb. 14 and 15 for advanced-node ICs using custom/analog (Virtuoso) and digital (Encounter) environments. Further information is located here.

Richard Goering

Five-Minute Tutorial: Multiple View-Only Windows In EDI

Kari — Wed, 25 Jan 2012 16:09:00 GMT

Have you ever had a situation where you want to compare two (or more) different areas of a design, so you end up zooming in to one area, then to the other area, then back and forth as you look at various objects and layers, trying to recall the differences? Have you ever brought up two separate Encounter Digital Implementation (EDI) sessions to make this easier? Then today's tutorial is for you!

There is a way to bring up multiple view-only windows of your design during your current EDI session. Under the Tools menu, click on Design Viewer. A new view-only window will come up with your design in it. You can start as many Design Viewer windows as you like to make your task easier. You can place them side-by-side and compare different areas of the design quickly and easily.

Now, the most common thing to do when looking over a design is to turn various layers and objects on and off. You will notice that it's a pain to go back to your main EDI window to use the Layer Control panel, so it's worth reminding everyone that the Layer Control Panel can be undocked! Just put your mouse on the Layer Control bar, left-click, and drag the panel outside of the EDI window. Now you can place it wherever you like on your desktop and more easily use your view-only windows.

Like the Design Viewer? You may also be interested in this:

Five-Minute Tutorial: The Encounter Digital Implementation Cell Viewer

- Kari Summers

Webinar Report: Power-Aware Mixed-Signal Verification

rgoering — Wed, 25 Jan 2012 14:00:00 GMT

Most of the discussion about low-power design techniques has focused on digital circuits. However, nearly all systems-on-chip (SoCs) are mixed-signal, and the way in which analog and digital circuitry interact has a huge impact on overall power consumption. Thus, low power (or "power aware") verification must encompass both analog and digital - but how?

A recently archived Cadence webinar has some answers. Titled "Advanced Technology to Verify Complex Mixed-Signal Designs," the webinar was presented by Prabal Bhattacharya, simulation architect at Cadence. The webinar covered advanced mixed-signal verification topics including parasitic simulation, assertions, and low power. A recent blog post summarized the first part of this webinar; this post focuses on the last portion, which described power-aware mixed-signal verification using the Common Power Format (CPF).

Bhattacharya started this portion of the webinar by reviewing some basic concepts and showing how they apply to mixed-signal circuits. These concepts included power domains, state loss, isolation, power shutoff, and multiple supply voltage (MSV). In the latter case, he noted, supply voltage may vary from 1.2V to 1.8V or higher based on whether various conditions are true or false. This means the operating voltage of the block is dynamically changing during simulation.

"I think the primary challenge is that you have to do the conversion of the circuit's signal and low-power information," Bhattacharya said. "It is not enough to take an analog signal and bring it to the digital level, or a digital signal to the analog level. You have to think of the low power intent of that analog or digital block."

So how to do that? Earlier in the webinar, Bhattacharya introduced the concept of logic-to-electrical and electrical-to-logic "connect modules" that are automatically inserted by the simulator. In discussing low power, he introduced "power aware" connect modules. Shown below is a power-aware connect module (CM) that does a logic-to-electrical conversion using the power intent information in a CPF file. In this example a digital driver in a power domain (PD1) is driving an analog block in another power domain (PD2). The connect module takes power into account as it does the value conversion for the analog block.

Bhattacharya also talked about dynamic macro-model verification. A macro-model is typically a black box with no information about what's inside it. Thus, a chip-level verification engineer will focus on its boundary. However, he or she may need to verify that the analog value on an output port, as specified by CPF, matches the value that SPICE sees from the inside of the port. Bhattacharya showed how engineers can write a Property Specification Language (PSL) assertion to verify that the output voltage is within a desired range of tolerance.

"The main thing we want to emphasize is that the connect modules need to be power aware," Bhattacharya concluded. "You should be able to keep reusing your CPF specification even though some blocks are analog. You can do dynamic verification or assertion-based verification at the boundary to verify your low power intent."

You can access the archived webinar here. It's available free to members of the Cadence Community - quick and easy signup if you're not.

Richard Goering

Event Report: Club Formal UK – Cache Coherency, UVM for ABV, and Brainstorming with R&D

TeamVerify — Tue, 24 Jan 2012 19:56:00 GMT

Right before the December holidays it was my privilege to host the first "Club Formal" here in the U.K. My colleagues and I welcomed over 20 power users from 8 different companies, providing an exciting diversity of ideas and applications. We also took the opportunity to sneak preview some new technologies, share our product roadmap, and discuss new requirements from the attendees to better align our R&D development with their needs.

(If the image gallery doesn't open, click here.)

Here are some specific highlights of the event:

Customer Presentation: Finding A Cache Coherency bug with formal
In a very motivating talk, engineer David Lewsey shared how he was able unearth a nasty cache controller bug -- something engineers had not been able to detect with simulation -- via a clever combination of optimizing the design and applying abstraction methodologies. Specifically, putting some parameters in the code can really reduce the size of the design that the tool "sees." Plus, you can avoid modifying the RTL with concurrent, judicious applications of cut points, forces, and init commands in TCL scripts. In roughly the same amount of time it would have taken just setup a block level test bench, they were able to uncover the root cause of a complex bug that had eluded detection for some time.

Presentation: UVM with ABV
In this talk and supporting demo, Kong Woei Susanto showed how the basic principles of the popular Universal Verification Methodology ("UVM") can be readily extended to the formal and assertion-based verification (ABV) space. In the context of an easy to understand router example, Kong showed how simple reuse techniques/templates, and coverage-driven driven verification methodologies so common in the dynamic simulation world map directly to ABV and how the strengths of formal techniques can be used to compliment weaknesses in a pure simulation flow.

Keynote speech on "Verifying Memory Coherency"
Continuing on the cache coherency theme, it was a real treat to introduce R&D Fellow Bob Kurshan, a true pioneer in the field of formal analysis (remember the ground breaking "Formal Check" tool?), to present a deep dive on the challenges and pitfalls of cache and memory coherency verification.

Panel Discussion
Yours truly was honored to lead the panel discussion with Solutions Architect Joerg Muller, and our AE speaker Kong Woei Susanto to brainstorm with the audience on a wide variety of topics. Allow me to publicly thank the attendees again for being so generous with their thoughts and recommendations, which was to the benefit of all!

Training, Roadmaps and new Product Previews
Allow me to again thank the attendees for their warm reception of our product roadmap, and being generous with comments about where you'd like to see more attention. This feedback is invaluable to R&D, and as you saw we were all taking careful notes. In addition, the attention paid to the coverage unreachability and formal scoreboarding reviews made it clear these were areas of high interest for everyone.

Lunch, Snacks, and Happy hour!
Last but not least, the intermissions and social segments of the day were of high value as well. Whether it was the casual lunchtime discussions, or informal Q&A at the pub, truly these venues -- comfortable, community settings where users get to swap stories with other users to brainstorm solutions and share tips and tricks -- were some of the best parts of the day.

Bottom-line: an engaging, informative time was had by all, and I believe I speak for everyone in looking forward to the next event later in 2012!

Until the next Club Formal, happy verifying!

Vincent Reynolds
Application Engineering Leader
Bracknell, UK
for Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

P.S. Team Verify is working on the 2012 event calendar now. Hence, this the perfect time to let us know If you would like to see a Club Formal in your area! Simply jump to the Team Verify home page and "send Team Verify a private message".

P.S.S. In case you are unable to attend a Club Formal near you, be sure to check out our archive of free, technical webinars:
http://www.cadence.com/Community/blogs/fv/archive/2011/12/27/free-formal-amp-abv-webinar-recordings-from-2011-online-now.aspx?postID=1306428

What’s Next in Low Power?

QiWang — Tue, 24 Jan 2012 19:00:00 GMT

Low power has become a major consideration in chip design in almost all applications. One major achievement of the industry over the past a few years is the alignment on the low power design methodology, which was considered as the biggest hurdle to automate advanced low power design techniques. No matter whether you are using the Common Power Format (CPF) or Unified Power Format (UPF), the methodology is the same -- it uses a power format file to capture the designers’ power intent to drive the RTL-to-GDSII flow. The recent announcement of 100+ low power design tape-outs from Global Unichip (GUC), along with many other customers who have successfully adopted the Cadence CPF enabled low power solution, indicates the maturity of the methodology in real designs. So, what’s next?

One trend I see is that the concept of low power design is starting to penetrate into every corner of the IC design community. Traditionally, only a handful of projects in a company, or a small group of implementation experts, needed to worry about low power designs. Nowadays, almost every new design start is low power, and every designer, no matter what functionality he or she designs or verifies, needs to understand low power requirements and do something about them. To facilitate such a transition, EDA companies and chip design companies need to collaborate on educating the design community for the new era of low power everywhere.

The recent release of the book Advanced Verification Topics is a good step forward to expand low power design concepts to core verification engineers. Verification experts applauded the release of UVM standard, but how to leverage the new standard for low power design verification is still new to most designers. The book includes a dedicated chapter on low-power verification, with an in-depth discussion on power-aware verification planning and how to configure a power-aware UVM environment.

By bringing together two hot design topics, advanced verification and low power, the book provides unique value for verification engineers who want to apply latest verification technology on complex low power designs. I am sure there will be more such education materials in the future to help the general design community embrace low power design concepts.

Qi Wang

What's Good About APD’s Die Abstract Libraries? You’ll Need the 16.5 Release to See!

Jerry GenPart — Tue, 24 Jan 2012 18:00:00 GMT

In System in Package (SiP) 16.3, the co-design die flow introduced the distributed co-design flow concept, where there is no direct interaction with I/O Planner. Die information flowing between Encounter and SiP Layout is done via a die abstract. In flows up through 16.3, you first need to load the LEF files for the cell library used by the IC design into the LEF Library Manager and create the Condensed Macro Library (CML) files. The CML files would need to be updated anytime the LEF files changed.

In the flow for Allegro Package Designer (APD) 16.5, Encounter will generate die abstracts including information for all layers for each pin of each I/O cell macro that is used in the die. The intent of the 16.3 distributed co-design flow using the die abstract was to provide the necessary library information inside the die abstract to allow us to eliminate the use of LEF/CML files in the co-design flow. However, there was no mechanism provided in that flow for the user to identify the die pins and connection pins, so LEF files were still needed.

In 16.5 we support the distributed co-design flow allowing the user to choose to continue to load LEF/CML, create CML based on die abstract file, or not create CML at all. Not requiring creation of CML files would be the default mechanism.

Read on for more details …

Flow Impact

The intent of this feature is to provide IC library manager capabilities needed to support a new distributed co-design flow option. The only difference from a current distributed co-design flow is that by default no additional library information other than provided in die abstract file is needed, and no IC Library Manager user interface options are needed. If the user chooses, they can also either create a CML file based on die abstract file, which again is a new capability, or use the same 16.3 based flow of creating a CML file based on LEF library.

Use Models:

Add Co-design Die from Die Abstract file
(simple mode without IC Library Manager UI)
•        The Add Co-design Die command is invoked.
•        The New Design from Die Abstract file tab is selected.
•        User enters or browses to point to a Die Abstract file.
•        The design name (read from the Die Abstract file, and becomes the component name) appears on the form.
•        User presses OK button to add the die to the drawing, or Cancel to abort command.
•       The die placement form appears, an image of the die appears on the cursor and the user can place the die into the SiP design.

Add Co-design Die from Die Abstract file
(cml file to be created based on Die Abstract file)
•        The Add Co-design Die command is invoked.
•        The New Design from Die Abstract file tab is selected.
•        User enters or browses to point to a Die Abstract file.
•       Press Library Manager Button to invoke IC Library Manager.
•       By default the same Die Abstract file will be selected in the IC Library Manager, as the file was just browsed to.
•       User selects options to use for IC library processing, and cml file is created. The name of the file is the same as die abstract file name with .cml extension. The Auto create button needs to be pressed in order to create the .cml file and attach it to the database. The Auto-create button will be disabled until the user has actually opened the Options form and pressed OK.
•       If CML file is created by mistake, press Remove CML button to remove CML file. By removing it and not creating another CML, or going to LEF option, user is back to default behavior.
•        The design name (read from the Die Abstract file, and becomes the component name) appears on the form.
•        User presses OK button to add the die to the drawing, or Cancel to abort command.
•       The die placement form appears, an image of the die appears on the cursor and the user can place the die into the SiP design.

Add Co-design Die from Die Abstract file
(cml files to be created based on .ldf file, this is the 16.3 flow)
•        The Add Co-design Die command is invoked.
•        The New Design from Die Abstract file tab is selected.
•        User enters or browses to point to a Die Abstract file.
•       Press Library Manager Button to invoke IC Library Manager.
•       By default the same Die Abstract file will be selected in the IC Library Manager, as the file was just browsed to. Select option .ldf file. Browse to ldf file.
•       Use IC Library Manager the same way as it was used prior to 16.5. Exit library manager.
•        The design name (read from the Die Abstract file, and becomes the component name) appears on the form.
•        User presses OK button to add the die to the drawing, or Cancel to abort command.
•       The die placement form appears, an image of the die appears on the cursor and the user can place the die into the SiP design.

Update Co-design Die from Die Abstract File
•       The user must first invoke the Die Editor command.
•       When the Die Editor launches on the Component Selection form if a co-design component with Die Abstract co-design source is selected, a type in field or browse button can be used to select the new Die Abstract file from disk. If new file is not selected by default the method that was used previously to add or update the die will be used. If new die abstract file is selected, default would be to use simple case, as described above in Add Co-design. If user chooses to use IC Library Manager, press Library Manager Button.
•       Note that updating a co-design die from a new Die Abstract file will replace the existing die layout with exactly what is in the Die Abstract file. Thus any changes that were made to the die in SiP Layout, but not incorporated in the new Die Abstract file imported to update the die will be lost. Also note that the abstract is not incremental, and must include complete information about the die.
•       Offer options to compare the new Die Abstract only, without updating the die, update the die only without reporting changes, or update the die and report changes via Component Compare report. The default is to update the die from the Die Abstract file without reporting changes.
•       The form will include a note to the user informing him that updating the die from the Die Abstract file will replace the die layout with what is in the file, even if changes have been made to the die in SiP Layout that are not included in the Die Abstract file.

Menu and Command Line Access

The access to these commands is the same as in previous releases. The Add functionality can be launched by typing “add co-design die” in the command-line window, or through the “Add Co-design Die…” option of the Add menu. The Die Editor is invoked by typing “die editor” in the command-line window, or through the “Die” option of the “Edit” menu. On the add co-design form and on update die “Library Manager” button will be available, which will invoke IC Library Manager. To invoke ICLM from command line, “lef lib” should be typed (the same as in 16.3) or “ic lib” will also invoke library manager.

Note that the IC Library Manager in LEF library only mode is still available via the menu and command line. It will remain exactly the same as it was in 16.3.

Graphical User Interface

Add Co-design Die

As mentioned before, the default behavior for the add co-design die from Die Abstract would be adding library information stored in the Die Abstract itself without using IC Library Manager. There is no visual difference to the form for the add co-design die. The main difference is in when OK button becomes enabled:

The OK Button allows the adding of the die to proceed. This button is grayed out (disabled) until the following conditions are true -- a) The Die Abstract file has been read successfully; b) there is a valid Design Name present; c) the die component does not already exist.

In prior releases OK button was disabled until the LEF Library manager has been configured with an appropriate LDF file and Library. This is no longer the case. By default, the Library information used is the information stored directly in Die Abstract file. The methodology used to determine die pins and RDL connection points.

As in the prior releases Library Manager Button is available to allow user to configure the IC Library Manager, if the user chooses to do so.

Die Editor Capability to Update Die from New Die Abstract

If you invoke the Die Editor command and select a co-design die to edit that has a Die Abstract file as its co-design source, the Die Editor Component Selection form appears as in Figure 1. This form shows that the co-design source is a Die Abstract file currently stored in the database. There is also a file browse button, with label (…), to select a new Die Abstract file from disk that contains an ECO from the IC tools. Selecting a new file in this way will update the die from that new Die Abstract file. This is all the same as it was in 16.3. New for 16.5 is that a Library Manager Button has been added to allow users to select the way they want to use library information:

The Die Editor Component Selection form shows the Co-Design Source as Die Abstract, with a browser button to select a new die abstract to use to update the die from an IC ECO, and Library Manager Button to allow user to configure IC Library Manager.

Co-Design Source

Die Abstract – Type in field that by default shows the current Die Abstract file is the <Current in Database>. This is a typable field where you can type in the name of a new Die Abstract file containing an ECO from the IC tool, which would then be used to update the die before launching the Die Editor. If you keep the default, <Current in Database>, when the Die Editor is launched after pressing the Next button, it loads the I/O driver cell information from the existing Die Abstract file contained in the database, rather than allowing update from a new Die Abstract. This is the same as in 16.3.

… button – Opens a file browser to allow the user to browse for a new Die Abstract file, containing an ECO from the IC tool, from which to update the co-design die.
Library Manager button - Allows user to configure the IC Library Manager.

When the Next button is subsequently pressed, the ECO Die Abstract file will be read and the die updated from it before launching the Die Editor.

IC Library Manager (iclm)

Other than the new radio button at the top, when LEF Library is chosen, the rest of the fields on the form behave exactly as in 16.3.

The Library settings section, including the LEF files list, of the form will be disabled when the Die Abstract option is chosen. Only the CML settings section will be enabled.

Browse… button – Opens a file browser to allow the user to browse for a new Die Abstract file, containing an ECO from the IC tool, from which to update the co-design die. Once a new die abstract is selected like this, it will be passed back to the Edit Die form to update that form so the newly selected file will be read to replace the previous version of the die.

The CML settings behave exactly the same when the Die Abstract option is chosen as they did in 16.3 (and when the LEF Library option is chosen). The only difference is that only a single .cml file will be created, and it will be retained within the .sip database for future use when processing the die abstract.

Remove button -- Visible and active only if CML file is created and attached to the database. Press the button to remove CML as database attachment. By doing so, the library manager will process the die abstract using default algorithm. If using LEF/CML files option is the choice, select LEF Library radio button.

Please share your findings with this capability.

Jerry "GenPart" Grzenia

Q&A: Frank Schirrmeister Updates Status of System-Level Design

rgoering — Mon, 23 Jan 2012 05:00:00 GMT

Frank Schirrmeister, group director of product marketing for the Cadence System and Software Realization Group, has been managing and marketing system-level design technology for over 15 years. He's a widely published and respected author on the topic, with a monthly blog at the Chip Design Magazine site, a column in Electronic Design, and regular contributions to the Cadence System Design & Verification blog.

In this Q&A interview he discusses how he got into system-level design, the pace of adoption today, the promises and challenges of virtual prototypes, the progress of high-level synthesis, and the range of prototypes needed for hardware/software integration.

Q: Frank, what does your job at Cadence involve?

A: I'm responsible for product management of the System Development Suite, which includes virtual prototyping, RTL simulation, emulation, and rapid prototyping. I started in August [2011] but it's not the first time I've been at Cadence. Cadence recruited me and brought me to the U.S. in 1997 to run the Felix [system level design] initiative.

Q: How long have you been working with system-level design, and how did you get drawn into it?

A: I'm in my 15^th year. I was a chip designer originally. In 1993, I designed an HDTV encoding system for Deutsche Telekom [German telecommunications provider]. It had 6 or 7 chips and they were very complex for the time. I was involved in the architectural aspects, and I was fascinated with how these motion estimation chips fit into a systems context.

Prior to that time, I was an EE student at the Technical University in Berlin. I did some embedded software development for musical instruments to finance my time at the university. I studied what they called Technical Computer Science, and microelectronics was one of my focus majors. So, I started on the software side and then I did the hardware side as well. I even did full custom layout for one of the [HDTV] chips.

Cadence recruited me in 1997 because they were looking for people who had chip design and software development experience.

Q: How do you define system-level design or ESL [electronic system level]? Are these still useful terms?

A: I think they are useful terms to describe the portion of the design flow before you get to verified RTL. Because we have been talking about it for so long, ESL has a little bit of a negative connotation today, so I refer to it as system-level design. To make the term useful, the key question is what you define as a system. You need to define the boundary of what you mean by "system" carefully. The designer's system - like a system on chip [SoC] - becomes just a component of the phone, which is a component of the network.

Q: System-level design, or ESL, was certainly slow going for a number of years. Are you seeing more interest and adoption today?

A: I certainly do. When I started in this area in 1997, leading edge customers were looking at it as something they thought they would have to resolve, but you could really only get into the leading edge customers. This has changed. About five years ago people started to resonate with it more. Today when we go to a customer, he no longer has to be convinced he has a problem. The question becomes, how can Cadence help?

System-level design is still far away from mainstream, however. I would say it's still in early stages with lots of room for growth.

Q: Are virtual prototypes (or virtual platforms) coming into more widespread use? What obstacles are standing in the way to broader adoption?

A: Adoption is growing, and we have more and more people considering it, but I wouldn't call it mainstream yet. Most projects are still running without virtual platforms. One obstacle is that the people who have all the information to build the platform are hardware people, but the software developers are the users who get most of the value. It's kind of like doing something so your neighbor's life is easier.

Another obstacle is that existing methods for software development haven't totally failed yet. It's hard to develop on a board, and the boards are latest in the development cycle, but people try to get by with traditional techniques because the cost to build the virtual platform is still pretty high. It's expensive today because it's not a by-product of the traditional design flow.

Q: Both virtual prototypes and high-level synthesis use SystemC transaction-level modeling (TLM), but the models for high-level synthesis require much more detail. Can we bridge the gap and connect virtual prototypes to the implementation flow?

A: That's the next step that we're eager to get to. We want to enable a flow that takes the same architectural intent and leads into both software enablement and hardware implementation with high-level synthesis. Virtual platforms are expensive today because it's hard to build new models, and there is a lack of existing models for the re-used IP. If high-level synthesis could create, as a by-product, descriptions of new blocks that can be used for software development, that would be great. Then, if every IP provider would provide models, the problem would become mostly a TLM IP assembly issue.

Q: What are you seeing in terms of adoption for high-level synthesis?

A: What I find impressive about high-level synthesis is that it is silently being adopted by more and more customers, which means that vendors have to be involved in fewer of the projects directly. It's really in production. We have customers who are approaching or have 50 or more tapeouts with it. Datapath is the traditional sweet spot, but they're also using it for control. High-level synthesis is not only for datapath any more.

Q: What's the role of verification in facilitating the move from RTL to TLM?

A: Verification is a key driver in bringing about a jump to the next level of design entry. If you can verify at a higher level of abstraction, you can run more cycles and also different verification tasks - like application verification -- because execution is faster, albeit with less detail. It's kind of comparable to what happened with the move from gate-level to RTL simulation.

Today we're seeing a lot more people using TLM verification, and they're also bringing in software. There are two trends. First, a lot of testbenches themselves run at a high level of abstraction, and customers verify at the TLM level first and then add more detail. Secondly, people are using embedded software-driven verification, where their testbench is actually embedded software running on a processor they would have in the system. So they're running directed tests in software but the intent is to verify the hardware.

Q: Besides virtual prototypes, what kinds of prototypes are needed for hardware/software integration?

A: As I wrote in a recent EE Times article, you need prototyping throughout the flow at different stages. With virtual prototypes you get good speed for software debugging, but you don't get the accuracy you need for hardware verification. So you first bring in RTL simulation, which is in a sense a prototype, but it doesn't execute software very well. That's when you bring in emulation. Now higher-speed software development and execution become feasible, you have better debug on the software side, and you still have good debug insight into hardware.

But at some point that is still too slow as well, so you may want to bring in an FPGA-based prototype where you have even more speed. But what you have to take into account for FPGA-based prototypes is that every change you make on the hardware side takes longer. So you want to use it at a more stable phase of the RTL. At Cadence, we provide technology that allows you to reuse what you've done in the Palladium emulator to make the FPGA-based prototype bring-up easier.

Q: How does the Cadence System Development Suite address the challenges of hardware/software integration?

A: The idea behind the suite is that you can connect the different [prototyping] engines and enable an easy transition between the engines. For example, the Incisive RTL verification environment and the Virtual System Platform are based on the same technology, so bringing together RTL models and virtual prototypes is a very natural undertaking. The same is true with Palladium XP emulation and the Rapid Prototyping Platform, where we are using the same front end and the same flow. To validate that the final FPGA prototyping netlist is functionally correct was traditionally a time-consuming issue. In the System Development Suite you can bring the netlist back to Palladium for verification where you have great debugging.

Q: Finally, any predictions for 2012? Is this the year of the move from RTL to TLM?

A: In 2012 I think we will make significant steps towards that. We are working towards using the same architectural intent for implementation and software enablement and verification. I think we'll see more hybrid approaches where hardware-accurate RTL in an emulator or rapid prototyping system is executed along with TLM models. Will we completely get there [TLM] in 2012 and be done with it? Probably not, but I think we will make significant progress.

Richard Goering

Webinar Report – New Approaches to Mixed-Signal Verification and Assertions

rgoering — Thu, 19 Jan 2012 14:00:00 GMT

Nearly all systems-on-chip (SoCs) are mixed-signal, and as complexity grows, new verification techniques are needed. No longer is it sufficient to use traditional analog and digital simulation in isolation - instead, information must flow freely between analog and digital domains to allow a true mixed-signal simulation. A recently archived Cadence webinar showed how this can be done using a mixed-signal parasitic flow, assertions, and low-power verification.

The webinar, titled "Advanced Technology to Verify Complex Mixed-Signal Designs," was presented by Prabal Bhattacharya, simulation architect at Cadence. It was so full of information that I'll save an overview of power-aware mixed-signal simulation for a follow-up blog post. (Separately, Bhattacharya co-authored a detailed article about mixed-signal assertions for EE Times last year).

Introducing the webinar, Bhattacharya noted that traditional verification approaches based on SPICE and Verilog resulted in "limited channels of communication" between analog and digital teams. "Mixed signal has evolved to the point where you have continuous time domain and discrete time domain objects that interact with and influence each other," he said. He pointed to a simple model in which a voltage equation is driven by a variable that is set by a logic event. A true mixed-signal simulator must "play across" analog and digital domains, he said.

Bhattacharya showed the mixed-signal functional verification "landscape" shown below. On the left side, in the Cadence Virtuoso custom/analog environment, users design schematics, write analog behavioral models and wreal models, and create analog-centric testbenches. On the right side, users of the Cadence Incisive verification platform use methodologies such as metric-driven verification (MDV) and the Universal Verification Methodology (UVM) to provide chip-level verification. "You want to reuse all the things you've done in your Virtuoso environment and hand these off to Incisive by making minimal changes," he noted.

Next Bhattacharya discussed a mixed-signal parasitic flow. Following a top-level simulation in Virtuoso AMS Designer, the analog designers create blocks with schematics, run layout and extraction, and generate Standard Parasitic Exchange Format (SDEF) and/or Detailed Standard Parasitic Format (DSPF) files. Digital block creation, on the other hand, uses RTL coding and generates Standard Delay Format (SDF) files. Bhattacharya showed how analog and digital domains come together through logic-to-electrical and electrical-to-logic "connect modules" that are automatically inserted by the simulator. Then AMS Designer can run a mixed-signal parasitic simulation.

Using Analog/Mixed-Signal Assertions

Assertion-based verification is very familiar in the digital world, but not among analog designers, Bhattacharya said. But wait - analog designers may not use the word "assertion," but they do some things that are similar. These include HSPICE .measure statements, Spectre assert device statements, UltraSim device checks, and behavioral monitoring code in Verilog-AMS. These are all fine at the pure analog block level, but they don't convey meaningful information to digital verification teams.

What's better, Bhattacharya said, is a standard language such as Property Specification Language (PSL) that can be used in both the analog and digital domains. While PSL has primarily been applied to digital logic, he showed how it can be extended to cover mixed-signal expressions with voltage and current. For example, you could write an assertion that says that at the next clock cycle, voltage must be positive at the positive edge of the clock. "When I ship a block to the digital integrator, there is a person there who also uses PSL and can see what I was doing in my pure analog world," Bhattacharya said.

What about System Verilog assertions? There is currently no SystemVerilog-AMS specification, but you can bring real number values into SystemVerilog assertions, Bhattacharya noted. A DAC output could go through an electrical-to-real conversion and come into a SystemVerilog testbench as a real number. Further, an "analog value fetch" capability can be used with Verilog, SystemVerilog or VHDL, among other languages, to bring in analog quantities including voltage, current, power, and device and netlist parameters as real number values.

Bhattacharya concluded this portion of the webinar by showing an assertion browser and comparing it to a waveform display. "You be the judge in whether you want to do this [assertions] or go back to eyeballing waveforms," he said.

You can access the archived webinar here. It's available free to members of the Cadence Community -- quick and easy signup if you're not.

Richard Goering

What's Good About Allegro GRE Constraint Region Support? It’s in the 16.5 Release!

Jerry GenPart — Wed, 18 Jan 2012 19:00:00 GMT

The 16.5 Global Route Environment (GRE) now allows or prohibits tuning in constraint regions.

This functionality was designed to help PCB designers prevent delay routing in constraint regions. This is generally desirable as the space is so tight in the BGA via field that there is little room and what little there is -- is needed for routing. In addition to a space problem, the vias break up the plane with a lot of voids that allow the routing to 'leak' EMT through these holes or allow the routes to 'de-reference' from the plane which just increases a routes ability to radiate.

But, this functionality can also be used in free areas of the design to 'prevent' delay routing in constraint areas. In other words, if you have a constraint region and routes pass over it on an adjacent layer, you could reduce the amount of coupling by using a constraint region with 'standard' PCB level rules.

Read on for more details…

Process

There are several ways to control this behavior
- at the global level in Design Parameters, or
- at the Bundle level on its own properties.

Setup> Design Parameters> Flow Planning> Routing Controls
Chose 'Allow in constraint areas' either Yes or No

Another method:

RMB on the bundle and select 'Bundle Properties':

Tuning Allowed in Constraint Area:

Tuning not allowed in Constraint Area:

Check out the Video of this capability

As always, I welcome your feedback on this new 16.5 feature.

Jerry “GenPart” Grzenia

Five-Minute Tutorial: Avoid SI Problems With Better Pin Placement In Encounter Digital Implementation (EDI)

Kari — Wed, 18 Jan 2012 15:09:00 GMT

I know we're over halfway through January already (where does the time go?), but Happy New Year everyone! I hope 2012 is a good one for your business and your chip designs, and let's hope the Mayans just ran out of ink when they were finishing the calendar for this year.

Today I'd like to highlight an option of the assignPtnPin command that was added in Encounter Digital Implementation System (EDI) 10.1. This option is called -improveSI. Sounds intriguing and helpful, right? Let's see how it works:

If you use the command assignPtnPin -improveSI, then the pin assignment will attempt to place pins such that pins on the same layer are not on adjacent tracks. Also the pin assignment will attempt to place pins such that you don't have pins on top of each other in consecutive preferred-direction layers.

For example, if one pin is placed in M4, then the -improveSI option will attempt not to place another M4 pin on the closest track to either side of the first pin, and will also attempt not to place an M6 or M2 pin in the same spot as the original M4 pin.

I keep saying "attempt" because I'm guessing that legal placement will trump -improveSI, so if you have lots of pins on a small block, or have strict limits on pin layers, following the -improveSI rules may not always be possible.

I have not used this option myself yet, so give it a try and report back how you like it!

Here are some other tips to avoid SI problems:

Five-Minute Tutorial: Fixing SI Victim Nets

Five-Minute Tutorial: Setting Up Clock Routing Rules

- Kari Summers

2012 CES: Top 3 Trends Impacting EDA This Year

jvh3 — Tue, 17 Jan 2012 22:00:00 GMT

For years now consumer electronics have driven (nay, saved) the EDA industry. Hence, many events at last week's annual Consumer Electronics Show (CES) in Las Vegas can be extrapolated as leading indicators for the EDA business. While I couldn't personally attend CES this year, I had two trusted agents (specifically, Unified Communications (UC) expert David Danto of Dimension Data, and Joseph Hupcey Jr., video & communications systems architect and father of yours truly) on the ground to field check the myriad of reports streaming in from legacy and new media. Thus, allow me to highlight the following three trends from CES 2012 that I suggest will have a big impact on EDA this year.

1. TV's rapid evolution: ahead of the equally dramatic and lucrative transition from feature phones to smart phones, virtually all TVs shown at CES were "smart." Specifically, as the EDA360 vision paper foretold, it's not enough for TVs to support passive visual entertainment. Instead, the TV of today must support a library of interactive apps, coupled with some sort of digital video recording (DVR) solution to be viable in all but the most niche markets. That said, EE's and physicists alike should take comfort that raw hardware can still deliver its own differentiating punch: my agents reported several very good, "no glasses" 3-dimsenional displays, where the best of show was LG's prototype OLED 3D display. Quoting David Danto's eyewitness account:

"Hands down - no contest, my pick hit of the show is LG's new 55 inch OLED 3D display. ... I've been evaluating displays for most of my 30 year career and I've never seen anything that looked as good as this. First of all, it uses LGs passive glasses technology. No electronic shutters, no charging, no feeling like a reject from Tron. Then, the actual images sacrifice nothing to achieve the 3D effect - bright, vivid, lifelike colors, deep blacks, true whites. Then, to top it all off, it is so thin that from the side the thing is practically invisible."

(Note: from my experience, I agree that no picture or contemporary video can do a well sourced OLED justice -- to give you some idea of the bold visual character of an OLED's imagery, try to imagine a living magazine animated with rich, saturated colors like you get from the best dye sub printers.)

So what's the bottom-line for EDA for all this TV innovation? In a word, growth. How? This new generation of TVs deliver a visibly different experience than the best "dumb" TVs of even a few years ago -- they will inspire new sales / upgrades. Granted, you might be able to extend the "useful" life of a good-yet-dumb screen via web enabled boxes like TiVo DVRs and BlueRay players (like I'm doing with my 4 year old Sony Bravia LCD). But either way -- via new TVs or new set top boxes -- many more SoC's and peripheral IC's will be shipped.

2. ARM vs. Intel competition: While ARM is justifiably proud of the plethora of sockets they supported across the show floor, Intel fired a substantial broadside with the announcement they would be sourcing Atom architecture processors for Motorola Mobility (read, "soon to be Google", and all the Android market reach that implies) and Lenovo (read, "China and rest-of-world!"). In a provocative article "How Intel's Medfield Will Dismantle ARM", author Sebastian Anthony asserts that these announcements are only the opening salvo, and that Intel will be able to leverage their research and manufacturing strength to "physically" outpace competitors stuck on bigger nodes. Indeed, while ARM has a lot of momentum to say the least, Intel's tantalizing hints last December that they have 14 nm devices working in the lab gives credence to Anthony's aggressive theories. As for myself, I'll make the oh-so-daring prediction that whoever can deliver the best MIPS/watt by a >= 50% margin will be the ultimate victor.

3. The future of CES itself, and lessons for DAC: despite record breaking attendance, my agents confirm that there was palpable undercurrent of dissent -- fed by Microsoft's announcement that this was their last CES -- that the value of CES has diminished and/or is not aligned with the needs of the industry. This expression of frustration about misalignment between show management and attendees triggered a personal flashback to the very last COMDEX (despite it being a very productive show for my company, where we sold hundreds of eyemodules in the temporary Handspring store between the exhibit halls).

Suffice to say there has been a lot of punditry about the future of the Design Automation Conference (DAC) over the past several years. Aside from concerns about maintaining a forum for startups to introduce themselves, what seems to be missing are customers coming forward en-masse demanding that the show must go on. To wit, in past years major semiconductor and systems houses would send dozens of front line engineering managers and developers, CAD staffers, and R&D executives. Now you are lucky to see those same companies send a lone VP accompanied by 1-2 CAD managers. And from the vendors' point of view, is it all worth it, in terms of marcom dollars ROI, or from the more abstract "branding" value? Time will tell ...

Joe Hupcey III

On Twitter: http://twitter.com/jhupcey

P.S. Speaking of trade shows, in the verification space the annual DVCon's clear focus on functional verification technology and methodology has made it a growing, high value technical and trade forum. Hence, my colleagues and fellow bloggers will be there in force! In particular I welcome you to join me at the tutorial I'm hosting, entitled "Using "Apps" to Take Formal Analysis Mainstream", on Thursday March 1 from 8:30am-Noon (includes coffee & lunch) Register today!

“Advanced Verification” Book Brings UVM to Mixed Signal, Low Power, Multi-Language

rgoering — Tue, 17 Jan 2012 14:00:00 GMT

The Accellera Systems Initiative Universal Verification Methodology (UVM) standard is helping design and verification engineers build efficient, reusable test environments. But the current standard doesn't cover everything that verification teams will encounter at advanced nodes. Thus, a new book authored primarily by Cadence R&D experts, titled Advanced Verification Topics, shows how to use metric-driven verification (MDV) and UVM with mixed-signal and low-power designs as well as multi-language verification environments and acceleration.

In 2010 Cadence published A Practical Guide to Adopting the Universal Verification Methodology (UVM), a comprehensive guidebook to UVM. So why write an "advanced topics" book now? Adam Sherer, product marketing director at Cadence and author of the new book's preface, told me that "as we dive below 40nm and into advanced nodes, it's not just a digital world any more. Customers have mixed-signal in there, they need to move up to TLM to handle complexity, and they need MDV." Further, as he pointedly noted, customers need to do some advanced power management at advanced nodes or the silicon will melt.

"The book is for advanced verification engineers and engineering managers who are trying to decide what to tackle next, and want to know how they can improve their productivity by taking a step beyond UVM," Sherer said. He noted that the new book assumes some knowledge of UVM, and if readers don't have that, A Practical Guide to Adopting the Universal Verification Methodology is a great place to start.

The new book discusses extensions to UVM, or "specializations," that are not yet part of the Accellera Systems Initiative standard. As the preface notes, UVM provides a "foundation for specialization," such as extensions needed to support acceleration. But it also notes that specializations built on standards must use open source code and open documentation. That's been done with Advanced Verification Topics.

Metric-Driven Verification and UVM

The first chapter of the book provides a basic overview of MDV, which uses verification planning and coverage metrics to evaluate and guide the verification process. It's a natural complement to UVM, Sherer noted. While UVM helps engineers build reusable tests and test sequences, it can't assess the value of the tests with respect to the verification plan and verification closure. That's where MDV comes in. It helps ensure adequate coverage, measures progress against the verification plan, and ultimately provides meaningful answers to the biggest of all verification questions, "am I done yet?" Other chapters in Advanced Verification Topics are as follows:

UVM and Metric-Driven Verification for Mixed-Signal. This chapter explains why MDV should be used for analog, discusses analog verification planning, and shows how to construct a UVM-MS (UVM-Mixed Signal) verification environment. It describes coverage, assertions, analog model creation, and using UVM-MS verification blocks.
Low Power Verification with the UVM. This chapter presents low-power verification challenges, describes power-aware verification planning, and shows how to configure a power-aware UVM environment.
Multi-Language UVM. This chapter shows how to create UVM Verification Components, called UVCs, that work in environments with more than one language. It provides details about the use of UVM SystemVerilog with the e language and SystemC.
Developing Acceleratable UVCs. Standard UVCs are not architected for acceleration. This chapter presents an approach to UVCs that reuses the stimulus defined in the UVM simulation environment, communicates using the Accellera Systems Initiative SCE-MI standard, and supplies data for MDV.

Advanced Verification Topics is co-authored by Bishnupriya Bhattacharya, John Decker, Gary Hall, Nick Heaton, Yaron Kashai, Neyaz Khan, Zeev Kirshenbaum, and Efrat Shneydor. All work for Cadence except Neyaz Khan, senior scientist at Maxim Integrated Products. The book is available from Amazon. Further information and a preview are available at the Cadence web site.

Richard Goering

SpectreRF AppNotes and Tutorials....Still One of our Best Kept Secrets!

Tawna — Mon, 16 Jan 2012 23:25:00 GMT

Some of you may remember the blog written several years ago " Shhhhh...SpectreRF Tutorials and AppNotes - One of Our Best Kept Secrets ". Well, the more things change...the more things stay the same! The location of these tutorials and appNotes still seems to be one of our best kept secrets! So, I am disclosing (once again) the location of our SpectreRF Tutorials, Appnotes, and Workshops hidden in the MMSIM 11.1 hierarchy.... If you 'cd' to your <MMSIM11.1>/tools/spectre/examples...(read more)

Update on OrCAD Free and Paid “Apps” – What is Available Now

rgoering — Mon, 16 Jan 2012 14:00:00 GMT

Last year Cadence announced the OrCAD Capture Marketplace, a web-based capability within the OrCAD Capture environment that provides an on-line store with free and paid plug-in tools, or "apps." Since then the list of available apps for OrCAD Capture and OrCAD PCB Editor has grown to 22, and a free trial period is available for most of the paid apps.

Apps provide a new way to bring new functionality to PCB designers. They're available instantly -- no need to wait for the next software release. You select only the features you need, and you don't have to pay for new capabilities you don't need. And, over time, a community will emerge in which apps will come from a variety of sources.

Accessing an app is as easy as buying or downloading any on-line product (see below). Most paid apps, such as SymbolGen shown below, let you either buy the app outright or click "trial" to give it a test drive for free. If you decide to purchase the app after the trial period, a new app installer is downloaded to turn the app on permanently.

A recent blog post by Jerry Grzenia provides a step-by-step guide on how to access apps from the OrCAD Capture environment. Below is a list of free and paid apps, with free trial periods noted for the paid apps. You need OrCAD version 16.5 or above to use them.

Free Capture Apps

Capture Cached Object Reporting -- Reports out-of-date cached objects in the active Capture design
Capture INI Manager -- Framework for manipulating the Capture INI file
CIPinCIS -- Instant access to search and download component data for millions of parts without having to leave OrCAD Capture
Customize Page on Creation -- Pre-defines automatic callback procedures to customize schematic page creation and attribute
Extended Preferences Dialog -- Provides a GUI for modifying several additional application settings available in OrCAD Capture
Find and Replace Text -- Searches for and replaces text globally in a Capture design
Intelligent PDF -- Shares design intent with intelligent PDF generation for OrCAD
Locked Object Reporter -- Identifies and reports locked objects in the currently active Capture design
Show Open Libraries and Designs -- Lists all open libraries and designs currently active in Capture

Paid Capture Apps

CircuitFit ($499 - free 15 day trial) -- Performs early fit studies at the schematic level before you commit to placement
CIS Quick Start ($99 - no trial) -- Creates a shared, searchable component database for OrCAD Capture CIS in minutes, including a 1000 part starter library
Find in Design ($99 -free 15 day trial) -- Quickly search for common values, like part numbers, across multiple schematics and projects
Status Display Highlight Property ($99 -free 15 day trial) - Helps avoid errors with fully customizable visual indicators of part properties like production status and value
SymbolGen ($999 - free 7 day trial) -- Automated symbol generation tool using advanced PDF datasheet extraction technology
Testpoint Annotation ($99 - free 15 day trial) - Enables synchronization of test points placed in the PCB to nets in the Schematic

Free PCB Editor App

nsWare ShapeUtils -- Free utility to help with shape creation and editing in PCB Editor

Paid PCB Editor Apps

FloWare Cross Section ($980 - free 15 day trial) -- Creates a dynamic table of the design stackup
FloWare LabelTune ($980 - free 30 day trial) -- Automatically adjusts PCB Editor RefDes labels to match part orientation and size
FloWare PCB Panelization ($3500 - free 10 day trial) -- FloWare Module for Cadence Allegro and OrCAD PCB Editor to generate a fabrication panel
nsWare Automatic Artwork Film Setup ($100 - no trial) -- Create artwork (Gerber) film setup in seconds
nsWare PDF Generator ($250 - no trial) -- Create a complete PDF document set for your PCB Design in just seconds
nsWare Planar transformer Generator ($250 - no trial) -- Dramatically decrease the time to create planar transformers in PCB Editor

That's quite a list, and it will only grow over time. Happy designing!

Richard Goering

CDNLive! Silicon Valley – Agenda Set, Registration Open, $99 Deal

rgoering — Thu, 12 Jan 2012 14:00:00 GMT

CDNLive! Silicon Valley, the Cadence user conference for the U.S., is set for San Jose, California March 13-14 at the DoubleTree Hotel. An agenda and registration information are now available on line, and there's a special "early bird" $99 registration deal if you sign up before January 27.

So why attend CDNLive!? Because whatever design and verification work you do, CDNLive! Silicon Valley will help you do it better. This year's conference features over 60 papers that detail user experiences and offer helpful design tips. It also includes interactive "techtorials," a keynote speaker to be identified later, and a Designer Expo showcasing a number of partner providers. There will be many opportunities for networking with peers.

The first day of the conference, Tuesday March 13, features 40 papers divided into 8 tracks, including mixed-signal/low power, custom, verification, SoC/IP, system/software, system verification, and high performance. Of these papers, 32 will be given by user companies or ecosystem partners, and 8 by Cadence. Detailed abstracts for most of these papers are available on line. The day will end with a partner reception and expo.

Wednesday, March 14 is a longer day with 52 papers, of which 34 come from users or partners. Wednesday's tracks are mixed-signal/low power, custom, verification, PCB, system/software, system verification, and "special topics."

Registration gets you attendance at keynotes, access to Cadence R&D and technology experts, entry to all technical sessions, access to the Designer Expo, lunches and coffee breaks, and validated self-parking at the DoubleTree. The conference fee is $199 after the "early bird" special expires January 27.

Meanwhile, CDNLive! EMEA will be held in Munich, Germany May 14-16. Further information is available here.

Richard Goering

Webinar Report: Solving Mixed-Signal Power Grid Challenges

rgoering — Wed, 11 Jan 2012 14:00:00 GMT

Complex analog/mixed-signal ICs pose many power grid design and analysis challenges. Unanticipated IR drop and electromigration problems are commonplace, and they significantly impact circuit behavior. But as a recently archived webinar shows, there are a number of ways to minimize these problems, even for advanced-node, mixed-signal systems on chip (SoCs) with hundreds of millions of transistors.

The webinar is titled "Power Integrity Challenges in Mixed-Signal Designs," and is presented by Harish Kriplani, R&D group director at Cadence. Topics include static and dynamic estimation, simulation methodologies, electromigration rules, hierarchical analysis, "what if" rail analysis, and IC chip/package co-design.

Kriplani started by noting the complexity of advanced-node chips that may have hundreds of millions of transistors and multiple power domains. This, he said, creates a need for hierarchical design, in which you analyze a block and create an abstracted view to use at the next level. He also stressed the importance of early power planning, allowing designers to make "aggressive changes" as early as possible.

A mixed-signal, IR drop and electromigration flow is shown at right. Based on the Cadence Virtuoso platform, this flow includes layout-versus-schematic (LVS) and the extraction of signal and power rail parasitics. It includes SPICE or Fast SPICE circuit simulation and analysis, and makes it possible to graphically display results for easier debugging. Finally, it can create an abstract model with a "power grid view" for analysis at the next level of hierarchy.

Following are some of the issues addressed in the webinar.

Static and Dynamic Estimation

Most webinar attendees were probably familiar with dynamic current estimation, which is really just time-domain analysis in SPICE or Fast SPICE. Static estimation, while much faster, is not as widely known in the analog/mixed-signal world. Here, you partition a circuit and identify logic gates or cells based on pattern recognition. You propagate switching activity through the circuit, or a user-specified power-per-cell, to capture an average switching rate. Using both of these methods can be very powerful - and the static approach may be the only choice for large designs.

Simulate Netlist and P/G Parasitics Together - or Separately?

For IR drop/electromigration analysis, the most accurate approach is to simulate the netlist and the power/ground parasitics together in SPICE or Fast SPICE. This is slow. An alternative is a two-part methodology in which you first simulate the netlist assuming ideal power/ground nets, and then solve the power and ground grids with a separate solver. Kriplani showed how to use these approaches and noted that results from both methods correlate to within 10 percent.

Using Block Abstractions with Power Grid Views

From a hierarchical perspective, you want to analyze a block and create an abstract model of the block that can be brought into full-chip power integrity simulation. Kriplani showed how do this by creating a "power grid view" that includes interfaces and ports, internal transistors, decoupling capacitors, and static or dynamic current distributions. The result: "when you solve the system you are essentially doing a flat analysis."

IR Drop Impact on Circuit Behavior

IR drop can affect circuit behavior significantly. In a digital design, this can be understood by bringing IR drop information into a digital timing tool. For small custom designs, you can simulate the netlist with the power grid parasitics. For larger designers, you can estimate block boundary conditions from a full chip simulation run, and resimulate selected blocks with netlist and grid parasitics.

"What If" Rail Analysis

What-if analysis can be employed for any design that has not gone through full optimization. What-if sensitivity analysis highlights areas where the power grid can be optimized for IR drop. What-if analyses can be used for scaling resistance, capacitance, and currents to understand impacts on IR drop.

Chip-Package Co-Design

If you combine a package with high inductance, a chip with high capacitance, and a power grid designed for low resistance, oscillation may result. Thus, a chip-package resonance analysis is needed. I/O noise analysis is also important.

Cadence Power Integrity Analysis Solution

Only at the end of the webinar did Kriplani provide details about the Cadence power integrity analysis solution. On the digital (Encounter) side, it includes the Encounter Power System (EPS), which can provide full-chip static and dynamic analysis. On the custom/analog (Virtuoso) side, it includes the Virtuoso Power System (VPS), which provides static and dynamic transistor-level analysis.

In a demo, product engineer Rose Li showed how engineers can use VPS to simulate and analyze a custom/analog block and generate a power grid view. She showed how this view can be brought into EPS for a full-chip analysis.

For more details, you'll need to view the webinar yourself. It's available free to members of the Cadence Community - quick and easy signup if you're not. You can see a list of all archived Cadence webinars here.

Richard Goering

What's Good About Allegro PCB Router Inset Vias? See for yourself in 16.5!

Jerry GenPart — Tue, 10 Jan 2012 15:24:00 GMT

Another high density interconnect (HDI) technology that has gained popularity is inset vias. The 16.5 release has provided new commands added in Allegro PCB Router to support inset vias.

Via in Pad pattern has been very popular due to its clear advantage of offering lower parasitics as compared to other fan-out patterns like dog bone patterns. But, it may pose a challenge for the assembler to deal with the trapped air, especially under the BGA balls. Inset patterns solve this and also provide the advantage of reduced parasitics as compared to dog bone pattern.
Inset pattern consists of two vias connected to each other by overlapping their pads:

The amount of overlap is constrained by samenet clearance between net based hold and pads of bbvias forming inset construction.

Read on for more details ...

Notice the changes in the clearance descriptor syntax, especially the tangency and inset rules at bottom:

For details on this syntax please refer the Allegro PCB Router command reference manual.

Translating Inset rule from PCB Editor / SPIF Changes

BBVia inset configuration in Allegro PCB Designer is recognized like bbvia to bbvia samenet clearance value specified to -1. The rule is accounted in via configuration creation where even samenet DRC checker is turned off, and both core bbvia and microvia types are affected. SPIF will replace -1 clearance values for this type with specific keyword “inset” that inform SPECCTRA about inset configuration on all hierarchy levels.

Example:

The following sets a rule at design level which specifies the inset rule between bbvia and bbvia -
rule PCB (clearance inset (type bbvia_bbvia))

The following sets a rule for net D0 which specifies inset rule -
rule D0 (clearance inset (bbvia_microvia))

Highlight Inset Vias

You can now highlight the inset vias by using the highlight command in SPECCTRA.

highlight via_inset on

This will highlight the inset vias as shown below:

highlight via_inset off

This will remove the highlight of inset vias.

I look forward to your comments about this capability.

Jerry "GenPart" Grzenia

Open NAND Flash Interface (ONFi 3.0) – Faster Throughput for SoC Designs

rgoering — Mon, 09 Jan 2012 14:00:00 GMT

Memory is an important part of virtually every electronic system, yet it's increasingly becoming a performance bottleneck. The latest ONFi 3.0 (Open NAND Flash Interface) specification promises to ease this bottleneck for nonvolatile memory. But silicon IP support is needed to facilitate adoption, and Cadence is stepping forward today (Jan. 9, 2012) with the first integrated ONFi 3.0 controller and PHY IP solution. Here's some background on ONFi 3.0 and its importance to system-on-chip (SoC) designers.

While NAND flash is increasingly important in consumer and computing applications, before 2006 there was no standard to help designers integrate NAND flash components with SoC designs. Bob Pierce, senior technical marketing manager at Cadence, noted that SoC designers used asynchronous interfaces with proprietary timing. In 2006 the ONFi working group formed and developed ONFi 1.0, which was basically an asynchronous interface with standardized timing.

In 2008 the working group published ONFi 2.0, which is a dual data rate (DDR) synchronous interface. It delivers speeds up to 200 MT/second. The ONFi 2.1 specification, which followed in 2009, added some new features, and later that year came ONFi 2.2, which allowed more efficient operation with logic unit number (LUN) reset and enhanced page register clear. This is the version most manufacturers are shipping today. You can read a detailed specification history and download the specifications from the ONFi web site.

Boosting Performance

The big difference with ONFi 3.0, published March 2011, is performance - it pushes data transfer rates to 400 MT/second, doubling that of ONFi 2.2. This speed is made possible by a bidirectional source-synchronous DQS and scalable I/O interface. In addition to getting better performance, designers can reduce the number of channels.

The following chart provides other comparisons between ONFi 3.0 and ONFi 2.2. In ONFi 3.0, the 1.8 I/O voltage and the on-die termination both help reduce power. Volume addressing is a virtual addressing scheme that can reduce the number of chip enable pins. A recent ONFi 2.3 spec also includes this scheme.

ONFi 3.0 provides backwards compatibility to previous specifications, and does not require any re-qualification of drivers. As Pierce noted, ONFi 3.0 will be especially attractive for designs that use multiple channels.

Integrated IP

Denali Software, acquired by Cadence in 2010, was the first IP provider to support ONFi 1.0. Now, Pierce observed, Cadence is the first provider to offer an integrated solution with the controller IP, PHY IP, firmware, memory models, and verification IP. An integrated controller and PHY solution are important because the interaction between the two is extremely complex, he noted. The Cadence NAND solution for ONFi 3.0 is shown below.

The Cadence ONFi 3.0 solution includes chip-enable interleaving, configurable error correction, hardware acceleration of key features, and LUN and chip enable operation. It also supports Toggle 2.0, an alternative specification that provides a "non-clocked" DDR capability by doing transfers on strobes. Additionally, the Cadence solution supports ONFi 2.3 and is backward-compatible with all previous ONFi and Toggle specifications.

Significantly, the announcement is taking place this week at the Storage Visions conference in Las Vegas, where Cadence, for the first time, is a conference sponsor. It's more evidence of the increasing emphasis that Cadence is placing on memory IP.

For further insights into ONFi 3.0, see Steve Leibson's Denali Memory Report blog.

Richard Goering

Creating the Zynq Virtual Platform, Including Errata

jasona — Fri, 06 Jan 2012 17:00:00 GMT

Although I have never contributed any code to the Linux kernel, the headline We are all Linux developers now on linux today caught my eye. One of the things that amazes me is how many embedded products use Linux and how they deal with all of the complexity. Nearly every product has similar but different hardware, and keeping it all straight and shipping a product with working software in the dynamic world of Linux is impressive. As a virtual platform developer these details hit me every so often...(read more)

The Denali Memory Report has Returned!

rgoering — Thu, 05 Jan 2012 23:00:00 GMT

For more than a decade, the Denali Memory Report has been an authoritative source of information about business and technology trends in semiconductor memory and storage. The report was published by Denali Software, which was acquired by Cadence in 2010. Now the report has returned as the Denali Memory Report by Cadence, a blog authored by Steve Leibson, marketing director at Cadence.

The report will cover memory market news, market trends, products and product strategies of memory vendors, and alliances and industry consortia. The first posting, dated Jan. 5, reports an announcement by Elpida that it has started shipping samples of 4GBit SDRAMs with both wide I/O and LPDDR3 interfaces. Both types of interfaces are expected to have a strong impact on the DRAM market this year, and the Elpida announcement will help push things forward.

Steve will continue to write EDA Insider, a blog he started in 2010. EDA Insider had over 500 posts last year. A Jan. 3 posting lists the 13 most popular EDA Insider blogs of 2011.

In my view, the return of the Denali Memory Report is one more indication of the strong focus that Cadence is placing on the memory market. Last year Cadence rolled out an IP strategy in which memory (DRAM) and storage (NAND flash) controller IP takes center stage. Also last year, Cadence announced the first DDR4 IP solution (including controller, PHY, and memory models) and the first wide I/O memory controller IP. Next week Cadence will exhibit at the Storage Visions conference in Las Vegas and will be, for the first time, a sponsor.

Memory is a vital part of any electronic system architecture, and it must be considered early and often by designers. If you're involved in the design of ICs or SoCs that have interfaces to memory, or simply want to keep up with trends in memory and storage, don't forget to read the Denali Memory Report by Cadence.

Richard Goering

Video: Bob Kurshan, Cadence Fellow and Incisive Formal R&D Leader, talks about Formal Engine Tech

TeamVerify — Thu, 05 Jan 2012 21:00:00 GMT

Continuing the series of introducing you to the people that create the tools you use every day, in this video I ask Bob Kurshan, Cadence Fellow and R&D leader of the Incisive Formal Verifier ("IFV") "Engines Team," about the challenges and/or tradeoffs in creating a formal engine, how to avoid gotchas in tricky problems like cache coherency verification, and how formal technology might evolve over the next 5 years.

If the embedded video doesn't play, click here.

Please feel free to ask Bob questions via the comments below; or jump to the Team Verify home page to "send Team Verify a private message" for forwarding to him offline.

Joe Hupcey III
for Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

Reference links to prior R&D interviews:
Distinguished Engineer Alok Jain

Incisive Formal R&D team leader Deepak Pant

Incisive Enterprise Verifier R&D Architect Vinaya Singh

Incisive Formal Verifier R&D leader Pradeep Goyal

User View: “Multi-Mode” Synthesis Approach Includes Power Optimization

rgoering — Thu, 05 Jan 2012 14:00:00 GMT

Logic synthesis is an indispensible IC design tool, but its value has a lot to do with how it's used. At a recent Synthesis Community Event at Cadence Dec. 8, Laszlo Borbely-Bartis, staff design engineer at Micron, described a concurrent multi-mode and low-power optimization synthesis flow using the Common Power Format (CPF). The new flow provides many advantages compared to the traditional bottom-up, single-mode synthesis approach.

This was one of three user presentations at the event, which also featured a panel session involving the presenters. All of the user presentations focused on low-power design, and power was a prominent topic at the panel discussion. A previous blog post includes a report of the panel.

In a memory controller, Borbely-Bartis noted, sub-modules may have different timing requirements, and there could be multiple power domains. With bottom-up synthesis, however, sub-module I/O delay is budgeted for the worse case, and as a result some paths are over-constrained. Single-mode synthesis constrains the top level in order to satisfy the worst-case mode. Power structures including isolation cells (ISO) are added later, power shutoff (PSO) simulation is delayed until the netlist is available, and design for test (DFT) structures are also added late in the flow.

The traditional flow looks like this, where A1 and A2 are sub-modules and LEC is logic equivalence checking:

The new, multi-mode flow (below) starts with a CPF file that describes power intent and a power-aware simulation. Top-down synthesis makes module-level standard delay format (SDF) files unnecessary. The top level is constrained for each mode, and power structures and DFT are added during synthesis. "We provide multiple SDC [standard design constraint] files for the different modes," Borbely-Bartis said.

Borbely-Bartis showed how the CPF file defines libraries and cells, creates power domains and modes, establishes isolation rules, and specifies power management cells including those for ISO and PSO. He noted that the CPF file allows for RTL PSO simulation, permitting early detection of possible power problems. When a PSO signal is asserted, the signals inside a shut-off domain are automatically forced to "X" (unknown) states. Thus, no testbench modification is needed for PSO support.

Each functional mode is described in a separate SDC file. There are also dedicated modes for scan and memory built-in self test (BIST).

As a result of the new flow, the design is not over-constrained, and ISO and PSO cells are automatically inserted. The final LEC is automated and driven by the CPF file, making LEC power-aware. In the old flow, Borbely-Bartis noted, die size may increase and overall timing may suffer.

Borbely-Bartis uses tools including the Cadence Encounter RTL Compiler, Conformal LEC, Conformal LP, Incisive simulation, and the Encounter Digital Implementation System. All these tools read CPF. PSO simulation with RTL, he noted, "allows early detection of most power issues. It also allows us to do more testing. Whatever you find, fixing RTL is much easier than reporting ECOs later."

Richard Goering

What's Good About Allegro Differential Pair Updates? Look to SPB16.5 and See!

Jerry GenPart — Wed, 04 Jan 2012 15:57:00 GMT

The 16.5 Allegro PCB Editor release adds differential pair phase tuning as an alternative to using the mouse guided delay tune command, and also quality improvements for transitions at region boundaries.

I’m providing a quick summary this week of these enhancements.

Differential Pair phase tuning

Phase Tuning is an alternative to using the mouse guided delay tune command and offers the precision of finite length adjustment to differential signals that are length/phase constrained. It is especially effective on static or dynamic phase-constrained Differential Pairs where iterative etch compensation may be required at various points along the path of either member of the pair. Simply make a mouse click at any point on the cline path to add in a single-parameterized phase bump.

The command is located in the Route Menu of the PCB Editor. When invoked, parameters can be set in the Options panel form. Select a style of Line or Arc then define its respective length/size parameters. The form will compute the added compensation for each bump before applying it:

Differential Pair phase tuning

Quality improvements have been made to both Add Connect and Slide in the area of Constraint Region transitions. They include:
•    Symmetrical gathering of Diff Pairs at the boundary when crossed orthogonally or at 45 degrees.
•    Maintain Diff Pair line width and gap during slide or from being shoved.
•    Remove the hinge effect at the region boundary.

Please share your experiences with this new 16.5 capability.

Jerry "GenPart" Grzenia

All Things Analog – Video Interviews with Experts

rgoering — Wed, 04 Jan 2012 14:00:00 GMT

John Pierce, product marketing director at Cadence, recently sat down with several analog/mixed-signal design and verification experts for "All Things Analog" video interviews. These short (8-11 minute) video clips offer some good insights into analog verification and simulation, PLL design, low-power design, and mixed-signal systems-on-chip (SoCs). All are now available for viewing on the Cadence Design Systems YouTube channel, as noted below.

In the first interview below, Pierce talked to Ken Kundert, president of Designer's Guide Consulting, and Henry Chang, vice-president at the same company. Kundert and Chang both previously worked at Cadence, and they talked about their move to analog/mixed-signal verification consulting. Chang, who wrote a book on digital verification, noted that the techniques he described in the 1990s are "now becoming applicable in the analog world." Kundert and Chang talked about the challenges of simulating circuits such as audio codecs and sigma-delta converters.

To view the video, open the icon below or click here.

In the second All Things Analog video, Pierce talked to Nandu Bhagwan, president and CEO of GHz Circuits Inc. This interview focuses on the challenges of PLL design and simulation. Bhagwan described how he uses abstraction to run simulations in a reasonable period of time.

To view the video, open the icon below or click here.

In the third video, Pierce talked to Dave Stone, vice president of marketing and sales at Triune Systems, and Ross Teggatz, president and founder of Triune Systems. This company is a fabless semiconductor supplier focusing on "green" solutions, so this conversation naturally turned to low-power design. Stone and Teggatz also discussed the complexity of mixed-signal SoCs compared to older analog designs.

To view the video, open the icon below or click here.

For more information about Triune and a solar power management chip they developed, see my previous blog post or check out a Cadence webinar that described the design challenges behind this innovative chip.

Analog/mixed-signal design and verification is sure to be a big topic in 2012. These videos offer some food for thought to help get the discussion going.

Richard Goering

Nport Application Note has been Updated and Re-Released

Tawna — Tue, 03 Jan 2012 14:00:00 GMT

Happy New Year! After many requests, I set aside some time and updated the Using the nport in Spectre and SpectreRF Simulations appNote for MMSIM 11.1. You may download the appNote on Cadence Online Support . More nport enhancements are planned, so stay tuned! If you have any comments or questions, please feel free to contact me via Cadence Online Support by logging a Service Request. Best regards, Tawna Wilsey...(read more)

Ubuntu Updates for 2012

jasona — Mon, 02 Jan 2012 17:00:00 GMT

I'm overdue to provide an update on how to run Virtual System Platform (VSP) and Incisive on the latest version of Ubuntu . My last article was very helpful to many people and users provided additional insight about what worked for them. Just before the holiday break we delivered our latest version of the Zynq Virtual Platform to some early beta users. One of the delivery options we have been using is to deliver a Virtual Machine with all of the software pre-installed and configured so it's...(read more)

TLM: The Year in Review, and Trends for 2012

Jack Erickson — Mon, 02 Jan 2012 14:00:00 GMT

2011 was my first full year in the land of Transaction-Level Modeling (TLM) design and verification, after spending my entire career to that point in RTL. I made my move upward in abstraction level in mid-2010 because it seemed like the time had finally come for this methodology to start becoming mainstream, delivering the benefits that have been sought for years. Has this methodology started to become mainstream? I think it's safe to say that it has started. We have been working with some large...(read more)

Free Formal and ABV Webinar Recordings from 2011 Online Now!

TeamVerify — Tue, 27 Dec 2011 14:00:00 GMT

In case you missed any of the 5 free webinars Team Verify presented in 2011, you're in luck: all of them have been recorded and posted for you to review at your leisure. Take your pick from the following - or pop a bucket of popcorn and a family sized bag of chips and watch them all at once!

----------

How to Completely Eliminate SoC Connectivity Bugs - Really!

http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=516

Bugs from incorrect connectivity -- whether they're misconnected IP blocks inside an SoC or erroneous muxing of pad rings -- can kill a chip just easily as more sophisticated functional bugs. With internal connection points surpassing hundreds of thousands of nodes, the traditional approach of assigning detail-oriented summer interns to spot-check connectivity with dynamic simulations is rapidly losing effectiveness. How do you ensure that two versions of your design are equivalent (e.g., the design before power techniques and after)?

In this technical webinar, we'll show you how to apply formal verification technology to exhaustively prove with 100% mathematical certainty that all of your SoC's internal and external pad ring connections are completely correct. An included demonstration (recorded live) reinforces the concepts presented.

----------

Verification 1-2-3 with Assertion-Driven Simulation

http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=518

This is it: a simple, straightforward methodology that increases bug detection and produces much cleaner RTL. Totally revolutionary "assertion-driven simulation" leverages easy constraint and assertion properties to simulate, visualize, and debug your design -- plus drive coverage collection.

----------

Automate Assertion Generation for Simulation, Formal and Emulation Flows

http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=557

Assertion-based verification (ABV) helps design and verification teams using simulation, formal analysis, and emulation methodologies accelerate verification signoff by enhancing the RTL and test specifications to include assertions and functional coverage properties, which are logic statements that define the intended behavior of signals in the design.

The emergence of "assertion synthesis" allows for true proliferation of ABV by automating the often painful manual process of creating meaningful white-box assertions and functional coverage properties with sufficient capacity to handle complex SoC designs. Without writing any additional code, stimulus generation and additional tests will find additional bugs and improve functional coverage, integrating into your metric-driven verification (MDV) flow.

In this webinar, Cadence and NextOp Software show how assertion synthesis enables a progressive, targeted verification process, allowing design and verification teams to more easily uncover corner-case bugs, expose functional coverage holes, and increase verification observability. The included demonstration (recorded live) reinforces the concepts presented during the session.

----------

Quickly Find Data Transport Bugs with Formal Scoreboarding

http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=560

"Scoreboards" have been used in advanced simulation testbench environments for years. In this webinar we will show how this same concept can be implemented with formal verification tools. Consequently, you will see how to benefit from powerful formal analysis algorithms to automatically test data integrity and root out the spectrum of simple problems to extreme corner cases.

The formal scoreboarding methodology is flexible and extendable such that it can be applied to various data transport blocks including bridges, switches, routers, matrices, memory controllers, DMA controllers, and buffers. Its value to the user is a significant reduction in simulation runtime and the ability to find bugs faster with less effort. This is an exciting topic for anyone in the functional verification space.

----------

Simplifying Code Coverage Analysis: Automatically Separating the Wheat from the Chaff

http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=562

Code coverage is a popular methodology let alone a signoff criterion for many companies. Unfortunately, code coverage can produce an enormous number of objects, where analysis of even a small number of coverage holes can be very tedious and time consuming. Of course, completely ignoring those holes can introduce risk that might not be acceptable.

In this webinar, we show how new automation and a revolutionary "case-splitting" methodology can help you separate the wheat from the chaff -- the "reachable" versus the "unreachable" code coverage holes. While formal analysis engines (and the mathematical certainty they offer) are used under the hood, perhaps the best part of the new case-splitting approach is that the flow does not require any understanding of formal analysis and is accessible to anyone familiar with simulation. This is an exciting topic for anyone in the functional verification space. The included demonstration (recorded live) reinforces the concepts presented in the lecture portion of the presentation.

----------

Happy learning and Happy New Year!

Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

Low Power Design in 2011 and Predictions for 2012

Pete Hardee — Thu, 22 Dec 2011 17:12:00 GMT

It's that time of year again - winding down towards the end of the year, taking some time with the family, and looking forward to returning refreshed for a new year. So what was the big news for low power in 2011 and what do we have to look forward to in 2012?

It's sometimes humbling to look at one's own technology predictions and see how things fared a year or so further on. Sometime in 2010, I forget exactly when, I was on a "virtual panel" on an on-line technology conference. One of the questions was to comment on developments for future technologies in low power design. I offered the following three points:

20nm node probably marks the end for continuing Moore's law on planar CMOS because process variability and leakage gets further out of control. What will emerge to enable 16/14nm node and keep Moore going? Will it be 3-D transistors, will SOI finally become economically viable, or will something else emerge?
Software is more and more influential on system power and we've got to move up the abstraction level to cope with that. New techniques in ESL power estimation and modeling will emerge
As application demands increase for mobile devices, and leakage becomes more of an issue even in standby modes, we will see the emergence of some energy harvesting techniques to compensate

Note that I was not necessarily saying we'd see all these within a year, but none-the-less, how did these predictions fare?

The end-of-the-line prediction for planar CMOS beyond 20nm was pretty good, as it turns out. What's even better news is that the leading emergent technology, fabricating transistors in 3-D which seems to be most popularly named FinFETs, looks like being very workable. So much so that Intel didn't wait for the 14/16nm node, but is already deploying the technology at 22nm (ref: http://www.nytimes.com/2011/05/05/science/05chip.html). Expected to be widely used at 14nm, FinFETs increase switching performance at reduced leakage, compared with planar CMOS, in a marvel of process technology engineering. This looks like it will have relatively little disruption on the current design tool flow, or current low power design techniques. Moore's Law looks good for a while yet.
As far as software's influence on power is concerned, real developments in ESL tools seemed few and far between. That's yet to happen and maybe we'll see progress in 2012. However, here at Cadence, we are witnessing greatly increasing usage of our Palladium Verification Computing Platform, with CPF support and the Dynamic Power Analysis (DPA) option, for executing the complete chip pre-silicon with software to both test the correct execution of power management (CPF) and estimate power in various real system modes (DPA). Not truly ESL you may argue, but getting the job done.
For energy harvesting, I thought we'd see much cleverer application of solar, thermal and mechanical harvesting in a wider range of mobile devices by now. Maybe we have been too good at deploying existing power management techniques to stretch battery life to at least a full day, to make the inclusion of such technologies in the device economically viable. We should start to see these emerging in the next few years, if not 2012, surely.

There you have it -- for what it's worth. I should mention that these predictions come with a money-back guarantee. If they fail to emerge as stated, I will happily refund exactly what you paid for them! Best wishes to you and yours for the Holidays and a happy and prosperous 2012.

Pete Hardee

2011 EDA Standards Update and 2012 Forecast

rgoering — Wed, 21 Dec 2011 14:00:00 GMT

As system complexity grows and semiconductor process nodes shrink, EDA industry standards are more important than ever. With today's time-to-market pressures, the last thing you'd want to do is waste time due to incompatible formats, tools or methodologies. Fortunately, 2011 was a productive year for EDA standards developments and 2012 is looking promising as well. This blog post summarizes some key developments.

Perhaps the biggest standards news of the year was the merger of Accellera and the Open SystemC Initiative (OSCI) into the Accellera Systems Initiative, completed Dec. 5, 2011. This follows the 2010 merger of the SPIRIT Consortium into Accellera. As I noted in a blog post earlier this month, the stage is now set for a unified, front-end EDA standards effort that cuts across multiple levels of abstraction. Looking forward to 2012, there are many opportunities for convergence among standards efforts such as Accellera's Universal Verification Methodology (UVM), IP-XACT from the SPIRIT Consortium, and OSCI SystemC and Transaction-Level Modeling (TLM-2.0).

While the Accellera Systems Initiative concentrates on front-end standards, the Silicon Integration Initiative (Si2) is traditionally focused more on the back end. A major Si2 development in 2011 was the release of Common Power Format (CPF) 2.0, an update that facilitates interoperability between CPF and the IEEE 1801 Unified Power Format (UPF), and the contribution of CPF 2.0 to IEEE 1801. Cadence, the originator of CPF, is now actively participating in IEEE 1801. An October blog post has further information about Si2's work in power standards.

Here are updates on some other key standards efforts (not necessarily in order of importance). Cadence is placing a strong priority on standards and is actively involved in most of the efforts listed below. Thanks to various committee chairpersons for helping with these updates.

ACCELLERA SYSTEMS INITIATIVE

UVM - On Feb. 18, 2011, Accellera approved the long-awaited UVM 1.0 as a new industry standard. Currently based on SystemVerilog, UVM provides a standard methodology so that verification IP and testbenches can be reusable and interoperable in different simulation environments. A bug fix release, UVM 1.1, was subsequently issued, and a more substantial new release, UVM 1.2, is expected in 2012.

SystemC - Before the merger with Accellera, OSCI working groups made continued progress in 2011 in defining a synthesis subset, analog/mixed-signal extensions, and model configuration and control. While the SystemC language itself is now under IEEE 1666, OSCI worked on a proof-of-concept reference model. Six OSCI SystemC working groups are now part of the Accellera Systems Initiative.

Unified Coverage Interoperability Standard (UCIS) - In 2011, the UCIS committee completed the technical work for a version 1.0 draft of a standard that will foster interoperability between verification coverage metrics from different sources. The standard is heading for approval in early 2012.

Standard Co-Emulation Modeling Interface (SCE-MI) - Accellera released version 2.1 of the SCE-MI standard, which added a "pipes" interface to the previous methods of communicating between software execution and hardware acceleration. Additional capabilities are planned for 2012 including SystemC and SystemVerilog interfaces.

IP-XACT - This standard provides metadata that documents the characteristics of silicon IP. In 2011 the working group captured new requirements and defined a process for the release of standard extensions.

IEEE WORKING GROUPS

IEEE 1666 (SystemC) - The first IEEE revision of SystemC in six years, IEEE 1666-2011, was released in November. The language reference manual includes the TLM modeling specifications from OSCI; it also adds process control statements, based on technology developed by Cadence.

IEEE 1800 (SystemVerilog) - A new version of the SystemVerilog standard is expected in 2012.

IEEE 1801 (Unified Power Format) - As noted above, Cadence has joined this working group, which now has access to CPF 2.0. A new revision, IEEE1801-2012, is planned for 2012. Looking further out, a "UPF 3.0" release is expected to include concepts from OpenLPM and CPF.

IEEE 1647 (e language) - IEEE 1647-2011 was published in August 2011 with a number of language updates. The working group is awaiting feedback on the standard and will start an open period for new contributions in mid-2012.

IEEE 1734 (IP quality) - The IEEE approved IEEE 1734-2011, a standard for IP quality, in June and released it in September 2011. The group is looking for industry feedback before undertaking any revisions or enhancements.

SILICON INTEGRATION INITIATIVE

OpenAccess Coalition - In 2011, a new OpenAccess release included support for 28nm constraints and compressed databases. OpenAccess scripting language bindings were released. A 2012 OpenAccess release will include scratch designs and other functionality and performance improvements.

DFM Coalition - The OpenDFM 1.1 physical verification standard was released in 2011, including electro-static discharge checks, latch-up checks, edge checks, and new targeting functions for manufacturability. In 2012, OpenDFM 2.x will include DRC+ and other enhancements.

OpenPDK (Process Design Kits) - Work has started on the Open Process Specification, which will include a symbol standard, a design parameter standard, a callback standard, and other design rules.

Low Power Coalition (LPC) - CPF 2.0, released in 2011, facilitates interoperability with IEEE 1801. Updated power modeling standards are expected in 2012.

Open3D (3D-ICs) - This new effort formed working groups in 2011 and is expected to release standards in 2012 defining power distribution network across the die of a 3D stack, thermal design and analysis of an entire 3D stack, and expression of design constraints into and out of the pathfinding and floorplanning phases of the design process.

It's a long list and it's not a complete list - many EDA standards efforts are ongoing. Here's a big end-of-year "thank you" to all those individuals who are donating their time to making these standards happen.

Richard Goering

One Oil Change and Update my Car to the Latest Software Patch, Please!

fschirrmeister — Tue, 20 Dec 2011 19:00:00 GMT

Since the IEEE Spectrum article "This Car Runs on Code" back in February 2009, my interest in the requirements for software and system-level development in automotive applications has grown quite a bit. And after recently having reviewed in previous blog posts requirements for wireless and industrial applications, automotive seems to be a great next topic. According to market data provided by dataBeans in July this year, the automotive segment is actually expected to be in 2011 the smallest...(read more)

Cadence Community

SKILL for the Skilled: Introduction to Classes -- Part 5

Things You Didn't Know About Virtuoso: Measurements Across Corners

Digital and Analog Verification – Round Peg in a Square Hole?

Five-Minute Tutorial: Change The Background Color Of EDI

The Zynq Virtual Platform: Not Just for Pre-Silicon

What's Good About Property Changes in DEHDL? The Secret's in the 16.5 Release!

Customer, Partner DFM Concerns Spur New Methodologies

Does Substrate Biasing Have a Future?

Webinar Report: New Methodology Revs Up Code Coverage Analysis

Panelists: Bridging the Gap Between Analog and Digital Design

What's Good About PCB SI Signal Integrity Application Mode? It’s in the 16.5 Release!

Whitepaper: Verification Performance is More Than Raw Simulation Speed

System-Level Design and the Waves of EDA

Incisive Performance Scales to Meet Advanced Node SoC Verification Requirements

Interested in Low Power, Mixed Signal, SystemC Verification? Here’s What to See at DVCon

Things You Didn't Know About Virtuoso: We've Got You Cornered

Video Killed The Reference Manual Star

UVM: "Everything that Can be Invented Has Been Invented" Not True!

SPIE Papers Showcase DFM and Lithography R&D

Five-Minute Tutorial: Multiple View-Only Windows In EDI

Webinar Report: Power-Aware Mixed-Signal Verification

Event Report: Club Formal UK – Cache Coherency, UVM for ABV, and Brainstorming with R&D

What’s Next in Low Power?

What's Good About APD’s Die Abstract Libraries? You’ll Need the 16.5 Release to See!

Q&A: Frank Schirrmeister Updates Status of System-Level Design

Webinar Report – New Approaches to Mixed-Signal Verification and Assertions

What's Good About Allegro GRE Constraint Region Support? It’s in the 16.5 Release!

Five-Minute Tutorial: Avoid SI Problems With Better Pin Placement In Encounter Digital Implementation (EDI)

2012 CES: Top 3 Trends Impacting EDA This Year

“Advanced Verification” Book Brings UVM to Mixed Signal, Low Power, Multi-Language

SpectreRF AppNotes and Tutorials....Still One of our Best Kept Secrets!

Update on OrCAD Free and Paid “Apps” – What is Available Now

CDNLive! Silicon Valley – Agenda Set, Registration Open, $99 Deal

Webinar Report: Solving Mixed-Signal Power Grid Challenges

What's Good About Allegro PCB Router Inset Vias? See for yourself in 16.5!

Open NAND Flash Interface (ONFi 3.0) – Faster Throughput for SoC Designs

Creating the Zynq Virtual Platform, Including Errata

The Denali Memory Report has Returned!

Video: Bob Kurshan, Cadence Fellow and Incisive Formal R&D Leader, talks about Formal Engine Tech

User View: “Multi-Mode” Synthesis Approach Includes Power Optimization

What's Good About Allegro Differential Pair Updates? Look to SPB16.5 and See!

All Things Analog – Video Interviews with Experts

Nport Application Note has been Updated and Re-Released

Ubuntu Updates for 2012

TLM: The Year in Review, and Trends for 2012

Top Ten Cadence Community Blog Posts of 2011

Free Formal and ABV Webinar Recordings from 2011 Online Now!

Low Power Design in 2011 and Predictions for 2012

2011 EDA Standards Update and 2012 Forecast

One Oil Change and Update my Car to the Latest Software Patch, Please!