Custom IC Design

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

2012-02-10T14:00:00Z

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

2012-02-09T20:56:00Z

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

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

2012-01-26T17:26:00Z

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

Improved IDF Tool Automatically Fixes Design Rule Violations in Virtuoso

2011-12-13T19:00:00Z

Although many automatic layout generation tools are available to automate design creation, the layout modification/correction step (fixing design rule violations) is not automated very well. Consequently, design modification including error correction typically needs to be done manually. A good solution to automate the layout modification/correction step can be provided by a layout optimization tool that optimizes the areas containing design rule violations in a layout, and fixes the violations automatically. Such a capability is provided by the Interactive Design violation Fixing (IDF) tool that was first provided in the Virtuoso IC6.1.4 release.

The primary advantages of IDF are:

1. Only required areas are modified and corrected (nothing will be changed outside of the selected areas.)

2. It can be called any time in any design phase (even if the layout has not been finalized.)

3. Quality of the modified layout is stable (the results won't vary according to engineers' experience or design manner.)

As the first step to realize the above requirements, IDF was implemented in our IC6.1.4 software release by freezing (not changing) details outside of specified areas. (Fig 1)

Fig 1. IDF- IC6.1.4 (freeze outside of the area to be optimized)

Although the IDF in IC6.1.4 worked very well, freezing areas around the area to be optimized had the following two limitations:

1. It takes long time when a design is big because the entire layout data needs to be loaded on the dynamic memory.

2. When multiple areas are selected, one optimization failure ("infeasible") causes the optimization failure of all selected areas. (All areas must be optimized at the same time since optimizing a design means generating a result that satisfies all requirements simultaneously.)

Therefore, IDF needed to be enhanced so that automated layout modification/correction worked regardless of the design size, and without infeasible results interrupting the flow. In the latest release, IC6.1.5, the IDF has successfully been enhanced to realize the above requirements.The solution to the problem is applying the automated correction (IDF) only to the affected region. The areas to be optimized from a design are extracted. Then, the extracted areas are sent to the IDF engine one by one (Fig. 2)

Fig 2. IDF in IC6.1.5

IDF works very fast in most cases because the size of the data is very small. The following table compares benchmark results of IDF in IC6.1.4 and in IC6.1.5. IDF in IC6.1.5 finishes all error fixing within 1 minute.

Table 1. Runtime comparison (Frozen Donut Area vs. Area Segmenting Method)

Unit [h:m:s]

Design	Size (um x um)	# of Design Rule Errors	IDF in IC6.1.4	IDF in IC6.1.5
Stdcell MX2X1	2.61x2.61	1	3s	1s
Stdcell DLY1X4	4.06x2.61	1	2s	0.5s
Stdcell ADDFX1	7.54x2.61	2	2s	0.5s
CustomDigital 1	15 x 15	7	3min 52s	4s
Analog 2	4.5 x 6.5	8	4s	1s
Analog PLL	650 x 550	30	> 2hours ^*1)	30s ^*2)

Note:

*1) Job was terminated during constraint generation phase.
*2) 2 Infeasible results were reported.

Runtime (User time) was measured.
Test Machine:
VMWare Virtual Machine
Redhat Linux 4
RAM: 1 GB

Physical Machine:
Dell Laptop PC M65
CPU :Intel Core 2 CPU 2.16GHz
RAM : 3.25 GB
OS Windows XP SP3

Figure 3 shows the biggest design used for this benchmark test.

Fig. 3 Analog PLL design 650um X 550um（# of DRC Errors 30 -> 2 : runtime = 30sec)

This approach (loading only the specified area) allows the following benefits:

No design size limitations
Very fast
Non-stop optimization despite some infeasible results

IDF in IC6.1.5 works effectively for medium / large designs. It can also handle designs of chip-level complexity. Because each optimization task is discrete, the flow does not become interrupted by an infeasible result error. Also, the runtime is very fast, since the size of each extracted cell tends to be small.

Actually, IDF in IC6.1.5 consists of multiple small IDF fixes in IC6.1.4. Because a huge amount of design time is wasted on inefficient manual modifications, IDF in IC6.1.5 is a great solution to correct errors. IDF in IC6.1.5 is the answer to industry’s demand for automatic error correction.

Hiroshi Ishikawa

Sr. Engineering Manager, Physical Design
San Jose R&D, Custom IC, Silicon Realization Group

Cadence is the OpenText Connectivity Partner of the Year

2011-11-28T22:00:00Z

Cadence is pleased to be honored by the OpenText Global Partners Program as their 2011 Connectivity Partner of the Year. The award is a reflection of the close working relationship that we have had with OpenText over the past several years, providing our mutual customers with the best experiences when using Cadence Virtuoso tool suite with OpenText's ExceedOn Demand product line, which provides remote access to Virtuoso. We have done a number of webinars and joint papers to describe how best for our customers to set up both tools to maximize the benefits, particularly when working in a globalized work environment. Once again, on behalf of Cadence, I'd like to thank OpenText for their generous acknowledgment.

The following resources provide more information about OpenText and ExceedOn Demand.

Blog Post

http://www.cadence.com/Community/blogs/ii/archive/2011/07/28/q-amp-a-how-opentext-provides-remote-access-to-virtuoso.aspx

Whitepaper

http://connectivity.opentext.com/resource-centre/whitepapers/achieving-optimal-performance-with-cadence-virtuoso.aspx

Video

http://www10.edacafe.com/video/Get-free-evaluation-OpenText-Exceed-onDemand-OpenText-Remote-Connectivity-Cadence-Virtuoso-Stephen-Lewis/35159/media.html

Webinar

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

Steve Lewis

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

2011-11-14T15:00:00Z

In several previous postings we introduced the problem of solving the sudoku puzzle.

In Part 1, we saw the rules of sudoku and a brief introduction to the SKILL++ Object System.
In Part 2, we started solving the problem top-down by implementing the top level function SkuSolve and agreeing to fill in all the missing pieces incrementally until the program was complete. We also saw how to use hierarchical class definitions to represent the components representing rows, columns and 3x3 blocks.
In Part 3, we saw how to create and initialize non-trivial instances of SKILL++ classes, and used these techniques to initialize the sudoku board with a given partial solution, ready for solving.
In this posting, Part 4, we'll finally show one possible definition of function SkuFindSolution.

Just for a reminder, here is the definition of the top level function, SkuSolve.

(defun SkuSolve (partial_solution)
  (let ((sudoku (SkuInitialize (SkuNew) partial_solution)))
    (printf "starting with: \n%s\n"
            (SkuPrint sudoku))
    (printf "\nfound solution:\n%s\n"
            (SkuPrint (SkuFindSolution sudoku)))))

We have already seen the definitions of SkuNew, SkuInitialize, and SkuPrint. Now we can take a look at the implementation of SkuFindSolution, the function which actually searches for the sudoku solution.

Solving the sudoku puzzle

The function SkuFindSolution takes an instance of class SkuSudoku (created by SkuNew, and populated by SkuInitialize) and modifies it to find a solution of the sudoku puzzle, assuming one exists.

How does it work?

It basically brute forces its way through the cells in the board, trying every possibility for each cell, from 1 to 9, which does not present an immediate conflict. If no solution exists for a particular cell (i.e., if each choice from 1 to 9 inflicts a conflict), the algorithm backtracks and tries a different guess, until it guesses correctly.

The local function conflict? asks "Does the given digit already exist in the row, column, or 3x3 block which contains the cell?" If not, it is a potentially valid guess. The local function solve_cells takes a list of all the remaining cells which have not yet been visited. Each digit that does not create a conflict is tried. There are three cases in the (cond ...):

If there are no more cells to consider, then we're done; we've found a solution! In this case we don't return from solve_cells, but rather return from (SkuFindSolution ...) thanks to prog/return.
If the cell already has a value in it, skip it because it was given in the puzzle partial solution. Note that this second case refuses to recure if a conflict is found. This means the puzzle has no solution, and recursion terminates, causing SkuFindSolution to return nil.
Otherwise, try all possibilities 1 through 9, skipping conflicts. If the (for ...) loop completes, that means we didn't find a solution for this cell. This happens if we've made an invalid guess in a previous iteration. So we set the cell back to the unsolved state (nil), and backtrack.

(defun SkuFindSolution (partial)
  (prog ()
    (labels ((conflict? (digit cell)
               (exists group '(column row b3x3)
                 (exists c (slotValue cell group)->cells
                   (and (neq c cell)
                        (eqv digit 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)))))
      (solve_cells sudoku->cells))))

Testing the program

Now you can test the program by copying the following into the CIWindow which comes from the Sudoku Wikipedia entry.

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

You should get the following result if you entered the code correctly.

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

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

If you notice, this algorithm only finds one solution of the sudoku puzzle. In some cases there are multiple solutions, but this algorithm won't find them. For example, the empty puzzle has lots of solutions.

Sudoku puzzle 4-2
(SkuSolve '((? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?) (? ? ? ? ? ? ? ? ?)))

starting with: 
+-----------------+
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
+-----------------+

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

What if there is no solution?

The SkuSolve function is good at detecting that no solution exists for a particular puzzle.

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

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


no solution

Summary

In this posting, we have seen a fairly straightforward approach to solving the sudoku puzzle. The solution algorithm is pretty easy because the data structures representing the structure of the board make it easy to ask the questions we need to ask, such as:

Is there a conflict putting a digit into a cell?
Which row, column, and 3x3 block is a given cell in?
Is a given cell pending resolution?

The particular implementation of SkuFindSolution also shows an example of how to use SKILL++ local functions. This usage avoids polluting the global function space.

Preview

In the next posting of SKILL for the Skilled we'll take a look at some shortcomings of this algorithm, particularly in regard to performance.

Jim Newton

A Moment to Mourn -- John McCarthy, Father of Lisp

2011-10-31T18:00:00Z

Here lies a Lisper
Uninterned from this mortal package
Yet not gc'd
While we retain pointers to his memory

[Author unknown]

Last week (October 23rd, 2011 or 24th depending on which source you read) we lost Dr. John McCarthy, one of the great contributors to the field of computer science. I'd like to send my condolences and best wishes to friends and family he left behind.

John McCarthy was the 1971 recipient of the Turing Award for his contributions to the field of artificial intelligence. But the reason we remember him and pay tribute to him today is because he is generally acknowledged as being the Father of Lisp which in some sense also makes him the grandfather of SKILL.

In 1960 McCarthy published a paper entitled Recursive Functions of Symbolic Expressions and Their Computation by Machine (Part 1). In this paper (part 2 of which was never published) he introduced a system he called LISP in which he was able to represent algorithms and mathematical logic in terms of what he called m-expressions and s-expressions. In fact, many of the names of the primitive objects and operators in the SKILL programming language were first mentioned from that paper, including: car, caar, cadar, cdr, assoc, atom, nil, null, eq, cons, lambda, quote, and list.

From the stories I've been told, McCarthy originally did not intend Lisp to become an actual language. Rather he simply illustrated it as a discussion exercise to his students. He used an M-expression notation such as F[G[a,b]] to expression function calling syntax. Some of his ambitious students were determined that they could create actual implementation on their IBM 704 mainframes based on McCarthy's theoretical concepts.

The students used an easier to parse s-expression syntax such as (F (G A B)). McCarthy hoped they'd eventually implement a better surface syntax. However, his students were initially more interested in how the language worked than the syntax. Meanwhile they also learned to love this internal (((syntax))). Eventually a student did manage to implement the m-expression syntax as originally conceived by McCarthy, but by that time none of the students wanted to use it.

Lisp is truly a great contribution to the world of computer science and software development in general.

Thanks John McCarthy. Rest in Peace.

Jim Newton

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

2011-10-17T13:00:00Z

In the previous posting Introduction to Classes -- Part 2 we saw the high level function for initializing, solving, and displaying the sudoku puzzle.

(defun SkuSolve (partial_solution)
  (let ((sudoku (SkuInitialize (SkuNew) partial_solution)))
    (printf "starting with: \n%s\n"
            (SkuPrint sudoku))
    (printf "\nfound solution:\n%s\n"
            (SkuPrint (SkuFindSolution sudoku)))))

In this posting we'll look at the definition of the SkuSudoku class as well as the definitions of the functions SkuNew, SkuInitialize, and SkuPrint. We leave the function SkuFindSolution until next posting.

In this posting, you'll see some examples of non-trivial class and instance manipulation which completely avoid the topic of methods. Although the SKILL++ object system provides a powerful method manipulation capability, you are not required to understand anything about methods to implement applications that operate on classes.

Non-trivial slot initialization

In the previous posting we saw how to use @initform to initialize instance slots to constant/default values. But the @initform can do more than provide constant defaults. The expression provided by @initform is actually SKILL++ code which runs every time an instance is created with makeInstance. The code in this SKILL++ expression is allowed to reference any global or local function or variable, such as functions defined within an labels as shown in the example below.

The SkuSudoku class defined below represents the sudoku board itself. It has a list of 81 cells, a list of 9 columns, a list of 9 rows, and a list of 9 3x3 blocks. Notice that the class SkuSudoku is defined inside a (labels ...) which defines a local function named repeat, and that local function is referenced inside the @initform expression.

In particular, in the class definition, the three slots (rows, columns, and b3x3s) each have a different @initform expression which each reference the local function repeat.

(labels ((repeat (n unary "xU")
          ;; call the given function N number of times,
          ;; collecting the return values.
          (when (plusp n)
            (cons (unary (sub1 n))
                  (repeat (sub1 n) unary)))))
  (defclass SkuSudoku ()
     ((cells   @initform nil)
      (rows    @initform (repeat 9 (lambda (n)
                                     (makeInstance 'SkuRow    ?index n))))
      (columns @initform (repeat 9 (lambda (n) 
                                     (makeInstance 'SkuColumn ?index n))))
      (b3x3s   @initform (repeat 9 (lambda (n) 
                                     (makeInstance 'SkuB3x3   ?index n)))))))

A call to the SKILL primitive makeInstance such as an evaluation of the expression (makeInstance 'SkuSudoku) will create an instance of the class and will initialize the 4 slots by evaluating the 4 respective @initform expressions. Furthermore, the expressions will be evaluated such that the local function repeat is defined.

Encapsulation through lexical scoping

Note that the feature of encapsulation (the ability to limit the visibility of functions like repeat) is provided by SKILL++ lexical scoping. This is different from the C++/Java paradigm which forces you to use the object system to implement encapsulation. In SKILL++, encapsulation works with or without the object system, so all SKILL++ programs can take advantage of it, not just object-oriented programs.

Initialization using a factory function

There is a limit to how much initialization is possible from the @initform expressions. In particular the @initform expressions are not allowed to reference each other. Furthermore, you have no guarantee in which order the initialization expressions will evaluate. This lack of guarantee is especially important when define classes using single inheritance, and even more important in the case of multiple inheritance. All @initform expressions need to be mutually independent expressions which only depend on the environment of the defclass and not on each other.

Skill++ programs typically create instances of classes in one of two ways: either by a direct call to makeInstance or by a call to an intermediate function which calls makeInstance. Such an intermediate function is called a factory function. A benefit of a factory function is that the function may also preform any additional initialization as necessary for the correct behavior of the program.

There is still another advantage to using a factory function rather than a direct call to makeInstance. The function can initialize slots so that their initial values depend on each other. In the case of a properly initialized sudoku board, the cells, rows, columns, and 3x3 blocks all depend on each other in a particular way. There is a list of 81 cells cells slot, and each of these cell objects is in the correct row, column, and 3x3 block. The sudoku board cannot be initialized simply by the @initform expressions. The job of SkuNew is to assure that the cells, rows, columns, and 3x3 blocks reference each other properly.

A factory function typically does the following:

Allocates an instance
Initializes the slots of the instance, potentially according to the arguments of the factory function itself
Returns the initialized instance.

Creating a structurally correct sudoku board

We want to define such a factory function named SkuNew which allocates, initializes, and returns an instance of the SkuSudoku class.

The function, SkuNew, does the actual allocation via a call to makeInstance as well as setting up the structure of the board independent of the actual content of the particular sudoku solution. In particular SkuNew assures that each cell can easily access its row, column, and 3x3 block and that each row, column, and 3x3 block can easily access its cells.

(defun SkuNew ()
  ;; allocate a blank-slate instance of SkuSudoku representing an empty
  ;; sudoku board
  (let ((sudoku (makeInstance 'SkuSudoku)))
    (let ((index 0))
      (foreach row sudoku->rows
        (foreach col sudoku->columns
          (let ((cell (makeInstance 'SkuCell ?index index++))
                (b3x3 (nth (xplus (xtimes 3
                                        (xquotient row->index 3))
                                 (xquotient col->index 3))
                            sudoku->b3x3s)))
             ;; add the cell to the list of sudoku cells.
             sudoku->cells = (cons cell sudoku->cells)
 
             ;; tell the cell which row, column
             ;; and 3x3 block it belongs to.
             cell->row    = row
             cell->column = col
             cell->b3x3   = b3x3
             
             ;; tell the row, col, and 3x3 block
             ;; that this cell belongs to it.
             row->cells  = (cons cell row->cells)
             col->cells  = (cons cell col->cells)
             b3x3->cells = (cons cell b3x3->cells)))
    ;; return the new instance.
    sudoku))

Feeding in the partial solution

Finally, given an initialized and consistent object which represents the sudoku board, it is necessary to feed in a given partial solution in preparation for running the solution algorithm, SkuFindSolution. The function SkuInitialize iterates through the rows and columns of a given SkuSudoku instance, filling some of the cells with a number from 0 to 9 as per the given partial solution.

(defun SkuInitialize (sudoku partial_solution)
  ;; feed in the partial solution
  (foreach (sudoku_row solution_row) sudoku->rows partial_solution
    (foreach (cell solution) sudoku_row->cells solution_row
      (when (numberp solution)
        cell->value = solution)))
  sudoku)

The sudoku instance initialization protocol

The two functions together form the sudoku initialization protocol:

SkuNew Create a newly allocated, structurally correct sudoku board, complete with cross-references which allow for effeciently search. SkuInitialize Feed a given partial solution into a given structurally correct sudoku board. Now you may experiment with the functions, SkuInitialize, and SkuNew by evaluating an expression such as the following in the CIWindow.

(SkuInitialize (SkuNew)
               '((5 3 ?  ? 7 ?  ? ? ?)
                 (6 ? ?  1 9 5  ? ? ?)
                 (? 9 8  ? ? ?  ? 6 ?)

                 (8 ? ?  ? 6 ?  ? ? 3)
                 (4 ? ?  8 ? 3  ? ? 1)
                 (7 ? ?  ? 2 ?  ? ? 6)

                 (? 6 ?  ? ? ?  2 8 ?)
                 (? ? ?  4 1 9  ? ? 5)
                 (? ? ?  ? 8 ?  ? 7 9)))

==>
stdobj@0x1d454234

The printed object such as stdobj@0x1d454234 is how an instance of a SKILL++ class is printed.

Displaying an instance

The default way an instance of a SKILL++ class prints is not very informative. We need to write a special purpose function, SkuPrint to display the partial (or full) state of the sudoku board.

The following function SkuPrint generates a string representing the ASCII representation of the sudoku board. The string contains \n characters so you'll have to use (printf "%s" ...) or a similar function to print it so it is human readable.

(defun SkuPrint (sudoku)
  (let ((divider "+-----------------+\n"))
    (strcat divider
            (buildString (foreach mapcar row sudoku->rows
                           (strcat "|"
                                   (buildString (foreach mapcar cell row->cells
                                                  (if cell->value
                                                      (sprintf nil "%d" cell->value)
                                                      " "))
                                                ;; separate the cells with |
                                                "|")
                                   "|"))
                         ;; separate the lines with \n
                         "\n")
            "\n"
            divider)))

You may now print the object with a call to printf as follows.

(printf "%s\n"
        (SkuPrint (SkuInitialize (SkuNew)
                                 '((5 3 ?  ? 7 ?  ? ? ?)
                                   (6 ? ?  1 9 5  ? ? ?)
                                   (? 9 8  ? ? ?  ? 6 ?)

                                   (8 ? ?  ? 6 ?  ? ? 3)
                                   (4 ? ?  8 ? 3  ? ? 1)
                                   (7 ? ?  ? 2 ?  ? ? 6)

                                   (? 6 ?  ? ? ?  2 8 ?)
                                   (? ? ?  4 1 9  ? ? 5)
                                   (? ? ?  ? 8 ?  ? 7 9)))))
==>
+-----+-----+-----+
|5|3| | |7| | | | |
|6| | |1|9|5| | | |
| |9|8| | | | |6| |
|8| | | |6| | | |3|
|4| | |8| |3| | |1|
|7| | | |2| | | |6|
| |6| | | | |2|8| |
| | | |4|1|9| | |5|
| | | | |8| | |7|9|
+-----+-----+-----+

Enhancements in IC615

The approach and the actual code shown here works in versions of SKILL++ using IC5033, IC5141, and IC61 up to and including IC615. However, there are some new features in IC615 which make initialization and presentation of SKILL++ objects easier and more flexible. To completely understand these and other new features, you'll need to understand something about generic functions and methods, which SKILL for the Skilled has not addressed yet, but here is a little taste.

There is a new generic function defined called printself. Virtuoso calls printself on SKILL++ instances when printing them into the CIWindow, stacktraces, or as a result of (printf ... "%L"). You may provide a method of printself specializing on your class which provides a string for the SKILL++ implementation to use as the printed representation of your object.
In IC615 makeInstance calls the generic function initializeInstance on a SKILL++ instance before returning it. You are allowed to provide what is called an @after method on initializeInstance specializing on your SKILL++ class to initialize it. This means that any application which makes an instance of your class will automatically call your initialization code without having to know the name of your factory function.
In IC615 defclass allows you to define classes which inherit from multiple potentially independent or interrelated superclasses called mix-in classes. In this case the various methods on initializeInstance are even more important as each such method is able to initialize the slots of an instance it is responsible for.

Review

In this posting you have seen some examples of non-trivial SKILL++ class allocation and initialization using both @initform and by a factory function. You've also seen a way to present SKILL++ objects in human readable form depending on the semantics of your particular class.

Preview

In the next posting of SKILL for the Skilled we'll finally look at how to implement the function SkuFindSolution which is the last function needed to complete the implementation of SkuSolve function.

Jim Newton

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

2011-09-06T04:00:00Z

In the previous posting Introduction to Classes -- Part 1 we introduced the problem of solving the Sudoku puzzle. I want to show a solution to this puzzle in SKILL++. Doing so, I'll break the problem up roughly into four parts.

Represent the structure of the data
Initializing
Displaying the state
Searching for a solution

High Level View

Here is a top-down view of the solution algorithm.

(defun SkuSolve (partial_solution)
  (let ((sudoku (SkuInitialize (SkuNew) partial_solution)))
    (printf "starting with: \n%s\n"
            (SkuPrint sudoku))
    (printf "\nfound solution:\n%s\n"
            (SkuPrint (SkuFindSolution sudoku)))))

In the upcoming postings I'll define the following functions used in SkuSolve. SkuNew Allocate a new sudoku board, creating rows, columns and 3x3 grids which appropriate links to enable fast searching. SkuInitiailize Fill in the empty board with an initial partial solution. SkuPrint Print the current state of the board with either a number or white space in each cell. SkuFindSolution Assign the appropriate numbers to the empty cells so as to solve the sudoku puzzle.

In this posting, let's look at how to represent the structure of the sudoku puzzle using SKILL++ classes.

Defining a class

A sudoku board has 9 rows, 9 columns, and 9 3x3 blocks of cells. Each row, column and 3x3 block has 9 individual cells. Each individual cell contains a single value which is a digit between 1 and 9 inclusive. We can represent a cell in SKILL++ with the following class definition. As shown on line 1.1, we define a class with defclass. Each instance of an SkuCell has several slots which can be accessed by name.

an index, (line 1.2) which is a number between 0 and 80 inclusive. There are 81 (9x9) cells in the sudoku board. The index uniquely identifies the cell.
a value, (line 1.3) which is an integer in the set {1, 2, 3, 4, 5, 6, 7, 8, 9}.
row, (line 1.4) an instance of SKILL++ class SkuRow indicating that this cell is an element of that row in the sudoku board.
column, (line 1.5) an instance of SKILL++ class SkuColumn indicating that this cell is an element of that column in the sudoku board.
b3x3, (line 1.6) an instance of SKILL++ class SkuB3x3 indicating that this cell is an element of that 3x3 block in the sudoku board.

(defclass SkuCell ()      ; 1.1
  ((index @initarg index) ; 1.2
   (value @initform nil)  ; 1.3
   (row)                  ; 1.4
   (column)               ; 1.5
   (b3x3)))               ; 1.6

Creating instances of a class

You can use makeInstance to create an instance of the class: (makeInstance 'SkuCell). Because the slot index is defined containing @initarg index (line 1.2), you can optionally specify the ?index keyword in the makeInstance call. E.g., (makeInstance 'SkuCell ?index 42), this will provide an initial value of 42 as for slot index. The slot value is defined with @initform nil (line 1.3) which provides an initial value of nil this slot.

Accessing slots of an instance of a class

The slots defined on lines 1.4, 1.5, and 1.6 have no @initarg nor @initform, but you can access these slot values using the handy-dandy -> operator as shown on lines 2.3, 2.4, 2.6 and 2.7.

cell1 = (makeInstance 'SkuCell ?index 42) ; 2.1
cell2 = (makeInstance 'SkuCell ?index 43) ; 2.2
(assert cell1->index == 42)               ; 2.3
(assert cell2->index == 43)               ; 2.4
                                          ; 2.5
cell1->row    = nil                       ; 2.6
(assert cell1->row == nil)                ; 2.7

Using classes to share structure

The rows, columns, and 3x3 blocks (b3x3's) are represented respectively by the classes SkuRow, SkuColumn, and SkuB3x3. But each of these shares some structure. Each has an index, rows are numbered 0 through 8, columns are also numbered 0 through 8 (likewise for 3x3 blocks). Furthermore, rows, columns, and 3x3 blocks have a list of cells (9 instances of class SkuCell). This shared structure is represented by the class SkuGroup from which SkuRow, SkuColumn, and SkuB3x3 each inherit. Note in the example 3 that the second argument of defclass may be nil indicating that the direct super-class is the default one provided by SKILL++, or the second argument may be a list of class names. Actually in 6.1.5 the list of class names is fully supported. Prior to 6.1.5, classes were only allowed one direct super-class. In example 3, the three sub-classes (SkuRow, SkuColumn, and SkuB3x3) of SkuGroup all have slots named index and cells.

(defclass SkuGroup ()
  ((index @initarg index)
   (cells @initform nil)))

(defclass SkuRow (SkuGroup)
  ())

(defclass SkuColumn (SkuGroup)
  ())

(defclass SkuB3x3 (SkuGroup)
  ())

Review

In this posting we looked at the plan for solving the sudoku puzzle, and the first step we used class inheritance define some simple classes which represent the state of the board. This includes simple uses of @initarg, @initform, and makeInstance

Preview

In the upcoming postings we'll continue by looking at some slightly more advanced ways to use defclass and encapsulation. We'll also continue the development of sudoku by printing the board and solving the puzzle.

Jim Newton

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

2011-08-15T19:00:00Z

In the previous couple of SKILL for the Skilled postings, we looked at some of the features of SKILL++. In fact, we saw local functions, higher-order functions, and lexical scoping. Still another set of features of SKILL++ is called the SKILL++ Object System. This system provides a standardized way of implementing object oriented SKILL applications.

Object Orientation

An Object System is a programming language feature which allows the programmer to control the characteristics and behavior of groups of objects in an organized and coherent way -- in effect making certain types of problems easier to solve.

If you are familiar with C++, Java, or similar programming languages, you might think that Object Orientation is that thing which C++/Java does. I would suggest to abandon that restrictive misconception. One of the first languages to introduce the concepts of object orientation was lisp during the 1970s, long before C++ or Java existed. The SKILL++ object system is based on this lisp approach. I hope the upcoming series of articles begins to peek your interest in this powerful and elegant subset of the SKILL language.

The SKILL++ Object System

SKILL++ strives to make the object system dynamic and reflective. This means you can create classes, and methods on the fly, inspect and debug them, and edit and redefine them in the same VM image. As you learn more about SKILL++ you should be pleasantly surprised at the power of a dynamic object oriented language.

In a nutshell the SKILL++ Object System allows the SKILL programmer to define classes of objects which share (some) structure definition and have similar behavior. Classes define how instances are structured. On the other hand methods on generic functions define how those instances of those classes behave and interact.

The SKILL++ object system provides the capabilities of classes and methods in such a way that they can be used independently or together as the programmer chooses. The means you don't need to understand generic functions and methods to understand classes and instances. In the upcoming series of articles we will look at classes as a tool for solving the Sudoku puzzle.

The Sudoku puzzle

First, what is a Sudoku puzzle? The Sudoku puzzle is a grid divided into nine horizontal rows, nine vertical columns, and nine so-called 3x3 blocks. To solve a sudoku puzzle, you must fill in each blank entry with an appropriately chosen digit from the set {1, 2, 3, 4, 5, 6, 7, 8, 9} such that the rows, columns, and 3x3 blocks each contain all of the numbers from 1 through 9. An implication of this requirement is that each digit must appear exactly once in each row, exactly once in each column, and exactly once in each 3x3 block.

Sudoku in SKILL++

I'd like to implement a SKILL function, SkuSolve, which will work like the following example. The actual example comes from the Sudoku Wikipedia entry.

After we have implemented SkuSolve and its support functions, we should be able to solve any valid Sudoku puzzle as follows.

(SkuSolve '((5 3 ?   ? 7 ?   ? ? ?)
            (6 ? ?   1 9 5   ? ? ?)
            (? 9 8   ? ? ?   ? 6 ?)
 
            (8 ? ?   ? 6 ?   ? ? 3)
            (4 ? ?   8 ? 3   ? ? 1)
            (7 ? ?   ? 2 ?   ? ? 6)

            (? 6 ?   ? ? ?   2 8 ?)
            (? ? ?   4 1 9   ? ? 5)
            (? ? ?   ? 8 ?   ? 7 9)))

This call should print something like the following:

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

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

Preview

In the upcoming series we'll look at the following:

Defining a class including with inheritance
Constructing instances of a class
Manipulating instances at run-time
Examining the content of an instance

Stay tuned for more to come. Please send submit your questions or comments in the comment section below.

Jim Newton

See Also:

Virtuoso Analog Design Environment XL – Data Everywhere, But You Have a Review in 10 minutes, Now What?

2011-07-29T13:00:00Z

In my previous blogs, I talked about productivity enhancing features of Virtuoso Analog Design Environment XL and how designers can take advantage of these capabilities to design complex custom analog ICs. The Virtuoso Analog Design Environment XL multi-test bench environment, specification compliance and statistical analysis tools allow designers to cover the design space in a fast and efficient manner. Compiling and documenting all these results and performance metrics for a speedy design review is just as important as generating them.

Rapid growth in the IP development cost (as a percentage of IC development cost) and the fact that majority of the designs are derivative designs in some shape or form means IP reuse is becoming a critical factor in determining the success of many projects. One of the important aspects of IP reuse is the ability to compile design information and tie it electronically to the IP to ensure accurate and consistent information for reference and reuse.

Using Datasheets

This is where Virtuoso Analog Design Environment XL datasheets come in handy. Virtuoso Analog Design Environment XL datasheets allow designers to specify information (variables, specifications, corners, results waveforms, etc.) that need to be captured, enabling designers to create datasheets with a single click. These HTML datasheets allow users to quickly review designs and share them with other team members and design partners.

The Virtuoso Analog Design Environment XL history assistant allows designers to save results of up to 10 previous history items. This, combined with the ability to easily generate HTML datasheets, saves a significant amount of designer's time while allowing designers to explore different topologies and design variations for optimum performance. Designers can electronically tie documentation to the IP for efficient review and validation by team members and design partners who might be located in different geographical locations.

Design managers can refer to the datasheets, using them as a means to quickly decide if all or some parts of IP could be reused in a new project. Users can combine and store other documents such as Excel spread sheets, PDF documents, and schematic screenshots along with the datasheets in "ADE XL view" enabling comprehensive design information in a single location. This enables seamless knowledge transfer across the design organizations. Such a methodology of keeping all the information in one location goes a long way in conducting efficient design reviews and helping design teams meet shorter design cycles.

Taking Snapshots

The Virtuoso Schematic Editor XL HTML publisher allows designers to take static snapshots of schematics and include them with verification results and design documentation, enabling designers to review schematics without the need to bring up Virtuoso Schematic Editor and tie up licenses that could be better used by other designers.

With the explosive growth of verification coverage, documenting results is becoming crucial to ensure that designers do not duplicate the efforts of fellow team members or waste their precious time rerunning same simulations because they failed to document results in the first place. Virtuoso Analog Design Environment XL datasheets allow designers to avoid such pitfalls by providing them with an easy to use, efficient mechanism to generate datasheets with a single click, allowing them to focus their energies on more important issues - such as designing the custom analog ICs.

Here are the links to some of the Virtuoso Analog Design Environment XL videos.

Note: You need a COS (Cadence Online Support) account to access these videos.

Creating Datasheets in Virtuoso Analog Design Environment XL

Virtuoso Visualization & Analysis (ViVA) Analog Design Environment XL Integration

Rama Jupalli

Things You Didn't Know About Virtuoso: Viva ViVA!

2011-07-08T16:00:00Z

I realize that I have been quite remiss in that I have not yet blogged about the new all-singing all-dancing ViVA waveform viewer which was released in IC6.1.5 back in January. All right, it doesn't really sing and dance -- but would you really want it to? Really? Submit an enhancement request and we'll see what we can do...

In the meantime, I can tell you that ViVA (oh, that's Virtuoso Visualization and Analysis for the acronymically challenged) -- the waveform viewer used in the Analog Design Environment L/XL/GXL -- has been rewritten from the ground up with the objectives of providing excellent performance, capacity and usability for all manner of waveform viewing and analysis tasks. Feedback from customers so far is that we have largely achieved those objectives.

So go ahead and give it a spin and see what you think. As with other Virtuoso IC6.1 applications, when in doubt, RMB (for those who haven't been following along, that means try clicking the right mouse button). ViVA also allows drag-and-drop (DnD) operations on waveforms for many tasks.

Scroll down to the bottom of this post for links to a whole host of video demos to show you many of the new features. You can view these on the web or download them to post for your colleagues to access as well.

Some things that may not be so obvious in the tool are the wide variety of bindkeys and keyboard shortcuts available to perform common actions. So, voila! Here you have the coveted secret decoder ring for ViVA bindkeys, shortcuts and icons. Print it out, keep it handy, make copies for your friends. I'm sure you could even have it printed on your coffee mug for a nominal fee...

ViVA video demos available on COS:

Using Subwindows in Qt Graph

Using Strip Charts in Qt Graph

Using Calculator Buffer New Features

Building Dependent Expressions Using Expression Editor

Virtuoso Visualization & Analysis (ViVA) Zooming and Panning

Virtuoso Visualization & Analysis (ViVA) Markers

Virtuoso Visualization & Analysis (ViVA) Working with Mixed Signal Data

Virtuoso Visualization & Analysis (ViVA) ADE XL Integration

Stacy Whiteman

Virtuoso Analog Design Environment XL – Make Friends with Variation

2011-06-16T13:00:00Z

In my last blog, Virtuoso Analog Design Environment XL - Embrace the Productivity, I wrote about Virtuoso Analog Design Environment XL's multi-test bench environment and how design teams can make use of this feature to increase productivity and use hardware resources efficiently. In this blog, I will focus on advanced Virtuoso Analog Design Environment XL features like corners analysis and Monte Carlo analysis.

Corners Analysis

Decreasing geometries, along with increasing design complexity in an era of short time-to-market windows, are making the task of designing custom analog ICs very difficult. Add to this the task of designing and verifying designs for a large number of PVT (Process, Voltage & Temperature) corners, and it is easy to understand the designer's need for efficient tools that make their lives easier. Corners analysis in Virtuoso Analog Design Environment XL is one such capability that enablez designers overcome such challenges.

Using the new and improved corners analysis tool available in the Virtuoso Analog Design Environment XL, designers can perform comprehensive analysis and verification across multiple corners to ensure design specification compliance. Apart from predefined PVT corners, designers can also create corners on various design parameters to increase the design space coverage and to ensure that their design meets the performance requirements over a wide range of operating conditions. A color coded display of spec-compliant corners analysis results in Virtuoso Analog Design Environment XL, combined with an easy to use debug mechanism, makes it easy for the designer to quickly get to the results they are interested in and to identify underlying issues that might be causing design spec violations. Virtuoso Analog Design Environment XL provides designers with the ability to run just the failed corner cases with a single click of a button and quickly identify problem areas.

Note: In Virtuoso 6.1.5, as part of "Worst Case Corners" tool, users can take advantage of efficient algorithms to create worst case corners and reduce the number of corners to simulate from 100s to single digits. "Worst Case Corners" is a Virtuoso Analog Design Environment GXL feature and you can find out more about worst case corners and other Virtuoso Analog Design Environment GXL features here.

Monte Carlo Analysis

Just as corners analysis is needed to verify design performance across PVT corners, Monte Carlo analysis is becoming critical for designers to better understand design performance with respect to statistical variations. Monte Carlo analysis in Virtuoso Analog Design Environment XL allows designers to analyze deign performance against statistical variations and take corrective actions where needed to increase the yield. Designers can selectively enable/disable Monte Carlo analysis on a complete design, or just parts of it, to study the effects of statistical variation.

The in-memory integration of Virtuoso Analog Design Environment XL's Monte Carlo analysis with Cadence MMSIM tools provides faster and efficient simulations by removing the overhead encountered with Monte Carlo tools offered by 3^rd party vendors. Apart from a close integration with MMSIM tools, Virtuoso Analog Design Environment XL's Monte Carlo analysis also provides advanced algorithms to effectively reduce number of trials needed to cover the entire design space. The ability to plot histograms and scatter plots in Virtuoso Visualization & Analysis (ViVA), Cadence's latest waveform display tool, combined with the Virtuoso Analog Design Environment XL's debug environment (users can open a Virtuoso Analog Design Environment L session on failed simulations with all the variable settings used in that particular Monte Carlo trial), allows designers to analyze results and help identify underlying reasons for failed simulations.

Note: It is a well known fact that regular Monte Carlo analysis is very expensive (in terms of number of simulations needed) to predict high-sigma yield. In such cases, you can use High-Sigma yield analysis. High-Sigma analysis enables designers to predict yield up to 6 sigma, i.e. 3.4 ppm failures with fewest possible number simulations. This is a Virtuoso Analog Design Environment GXL feature and you can find out more about High-Sigma yield analysis and other Virtuoso Analog Design Environment GXL features here.

Here are the links to some of the Virtuoso Analog Design Environment XL videos. Note: You need a COS (Cadence Online Support) account to access these videos.

Setting up & Simulating Corners in Virtuoso Analog Design Environment XL

Using the New Corners Setup Form in Virtuoso Analog Design Environment XL (IC 6.1.5)

Incremental Resimulation in Virtuoso Analog Design Environment XL

Debugging Points of Simulation Results in Virtuoso Analog Design Environment XL

Monte Carlo Analysis in Virtuoso Analog Design Environment XL

Rama Jupalli

SKILL for the Skilled: Virtuoso Applications of SKILL++

2011-05-31T17:00:00Z

In this posting, I continue looking at applications of SKILL++. In particular, I'll also discuss how to create functions that hold onto their state. I'll use these functions to implement multiple-criteria (cascading) sort predicates. I'll look at ways to sort layout pins counter-clockwise around the center point of the design.

Quick Review

In the previous posting we looked at an implementation of genCmpFunction which I'll repeat here.

;; Example 5.11
(defun genCmpFunction (@key (test lessp)
                            (key  identity)) ;; see example 5.10
   (lambda (A B)
      (test (key A)
            (key B))))

The value passed as ?key is a function, which given the sort candidate, retrieves the value to be compared. Thus if we wish to sort a list of db-instances by name, we need to pass as ?key a function that given a db-instance will return its name. In example 5.15, we did just that; we passed ?key 'name (lambda (i) i->name).

The getter function

This idiom is actually common enough that we can introducing a new SKILL++ function, named getter, which generates a read-accessor to access a given property name.

;; Example 5.16
(defun getter (propertyName)
  (lambda (object)
    (get object propertyName)))

The function getter takes a property name as its argument and returns a newly generated unary function which will retrieve the value of that property name from its argument. For example given the symbol name, it will return turn a unary function which will retrieve the value of the property name.

(funcall (getter 'name)
db_inst)

is the same as db_inst->name. Of course this is not very interesting used by itself, but is useful in conjunction with other functions like genCmpFunction and genCascadeCmpFunction which will be seen later.

Example 5.17 shows the code example 5.15 but using the getter function rather than lambda.

;; Example 5.17
(sort (geGetEditCellView)->instances
      (genCmpFunction ?test alphalessp
                      ?key (getter 'name)))

What's a closure?

Functions such as genCmpFunction from example 5.11, and getter from example 5.17 are subtly different than functions available in traditional SKILL++. Notice that genCmpFunction returns an on-the-fly function created by (lambda ...). The code within the lambda found in genCmpFunction references two free variables, test and key. These free variables are not declared by or inside the lambda. Likewise, in the function getter, the lambda expression references but does not define propertyName. Functions which extend the life-time of variables defined elsewhere and hold on to these closed-over variables in this way are referred to as closures. In example 5.17, the sort function is called only after genCmpFunction returns. Nevertheless, the closure returned from genCmpFunction holds onto the local variables of genCmpFunction, namely test and key.

Many other Lisp dialects as well as some other programming languages (such as ML, SmallTalk, and JavaScript) implement and support closures. You can find out more about closures on wikipedia.

Sorting pins in a layout cellView

Example 5.18 shows a function which sorts the pin figures in a given layout cellView into counter-clockwise order around the center of the cellView.

;; Example 5.18
(defun sortPinFigs (cv)
  (let ((cv_center (centerBox cv->bBox))
        (cv_pin_figs (foreach mapcan term cv->terminals
                       (foreach mapcan pin term->pins
                         pin->figs))))
    (sort cv_pin_figs
          (genCmpFunction
            ?key (lambda (fig)
                   (let ((fig_center (centerBox fig->bBox)))
                      (atan2 (yCoord cv_center) - (yCoord fig_center)
                             (xCoord cv_center) - (xCoord fig_center))))))))

Note that the function sortPinFigs in example 5.18 assumes there is no pin whose center is in the cellView center, because in that case atan2 would fail.

Cascading sort

Another limitation of sortPinFigs as implemented in example 5.18 is that two different pin figures might be at the same angle. It would be great if the sortPinFigs function would sort pins deterministically. We need a secondary sort criteria. For example, if two figures appear at the same angle, then sort by their distance from the center. But there might actually be some overlapping pins which have the same center, in which case a third criteria is needed, such as sort by layer name (or terminal name, or pin name, or left edge).

In general, whenever sorting objects based not on their identity but on some attribute, it might happen that two different objects share a value of that attribute. As in the example above, when sorting file names according to file sizes, it might of course happen that two different files have the same size. Example 5.19 shows a function genCascadeCmpFunction which is more general than genCmpFunction. The genCascadeCmpFunction function generates a compare predicate based on a sequence of cascading key/test pairs.

;; Example 5.19
(defun genCascadeCmpFunction (key lessp @rest others)
  (lambda (a b)
    (labels ((cascade (key lessp others "UUl")
               (cond
                 ((lessp (key a) (key b)))
                 ((lessp (key b) (key a))
                  nil)
                 (others
                  (cascade (car others) (cadr others) (cddr others))))))
      (cascade key lessp others))))

Sorting strings by cascading criteria

To sort a list of strings proceed first by string-length, then (if they have the same string-length) alphabetically.

;; Example 5.20
(sort (list "c" "abc" "jkl" "b" "hello" "d" "world" "xyz")
      (genCascadeCmpFunction strlen lessp
                             identity alphalessp))

===> ("b" "c" "d" "abc" "jkl" "xyz" "hello" "world")

Sorting file names by cascading criteria

To sort a list of file names first by file length, then alphabetically according to name, you can use the following.

;; Example 5.21
(sort (getDirFiles ".")
      (genCascadeCmpFunction fileLength lessp
                             identity alphalessp))

Sorting db-shapes by cascading criteria

To sort a list of db-shapes, first according to their layer name, then layer-purpose, then left-to-right by left edge, then right-to-left right edge, then top-to-bottom top edge, then bottom-to-top bottom edge, use the following.

;; Example 5.22
(sort list_of_shapes
      (genCascadeCmpFunction (lambda (obj) obj->layerName) alphalessp
                             (lambda (obj) obj->purpose) alphalessp
                             leftEdge lessp
                             rightEdge greaterp
                             topEdge greaterp
                             bottomEdge lessp))

We can rewrite the call above to something simpler using the getter function defined in example 5.16.

;; Example 5.23
(sort list_of_shapes
      (genCascadeCmpFunction (getter 'layerName) alphalessp
                             (getter 'purpose)   alphalessp
                             leftEdge   lessp
                             rightEdge  greaterp
                             topEdge    greaterp
                             bottomEdge lessp))

Summary

The examples shown above illustrate a interesting and powerful feature of SKILL++, closures. You might also find some of the examples useful to simply copy and paste into your programs. Remember to use the .ils extension.

See also

Jim Newton

Virtuoso Analog Design Environment XL – Embrace the Productivity

2011-05-06T13:00:00Z

In my last blog, Virtuoso IC 5.1.41 was Good but Virtuoso IC6.1 is Better, I wrote about the improvements in Open Access, SKILL and Virtuoso Schematic Editor in Virtuoso IC 6.1. In this blog, I am going to focus on Virtuoso Analog Design Environment, mainly on Virtuoso Analog Design Environment XL, its design analysis and verification capabilities, and how design teams can take advantage of these features to increase productivity.

The Virtuoso Analog Design Environment offers comprehensive set of capabilities required to fully explore, analyze, and verify a design against the design's specifications. The tiered product structure of the Virtuoso Analog Design Environment provides designers with the flexibility to select the tier that meets their design needs, enabling efficient use of EDA tools.

Virtuoso Analog Design Environment L

Virtuoso Analog Design Environment L provides a quick entry into the analysis process with easy execution of simulations. Virtuoso IC 6.1 Analog Design Environment L provides users with a short learning curve and easy transition from previous versions of Virtuoso. Apart from maintaining the same use model, Virtuoso Analog Design Environment L has many new features to enable efficient design analysis and simulation, including:

Configurable assistants and toolbars for optimum display of relevant data and design setup customization
Availability of Analog Design Environment L toolbar and post-processing toolbars in Virtuoso Schematic Editor L / XL for reduced mouse miles
Ability to launch Analog Design Environment XL/GXL directly from Analog Design Environment L. All information from Analog Design Environment L is pre-populated into Analog Design Environment XL, providing users with easily transition.

To know more about Virtuoso Analog Design Environment L, click here

Virtuoso Analog Design Environment XL

Virtuoso Analog Design Environment XL is an advanced tier that extends the L tier capabilities, providing a multiple test bench environment; analysis over sweeps, corners, and Monte Carlo analysis; and easy reviewing of results and generation of spec comparison sheets and datasheets as needed.

One of the important features of Virtuoso Analog Design Environment XL is its multi-test bench environment. Historically, custom/analog designers are used to setting up one test bench at a time, run simulation(s), analyze results, improve the design to meet design specifications, and then move on to the next test bench or next stage of the design. This methodology was necessitated not only because of hardware limitations but also because of limitations of available EDA tools.

However, with powerful hardware resources now being made available to designers, analyzing one test bench at a time not only is inefficient but also limits the designer's ability to simultaneously analyze different design architectures and test benches, and quickly settle on designs that meet the requirements. Virtuoso Analog Design Environment XL was designed and developed to overcome this shortcoming in existing tools.

The multi-test bench environment of Virtuoso Analog Design Environment XL allows designers to simultaneously run multiple test benches and efficiently analyze design specification compliance. Designers can analyze multiple test benches of the same design (with a different setup) or multiple test benches on different designs, using the same setup to enable optimum use of design infrastructure.

Some of our major customers who have adopted Virtuoso Analog Design Environment XL in their design flow are making use of this methodology to comprehensively analyze vast design spaces by running hundreds of simulations on multiple test benches, and by farming out these simulations onto larges farm of hardware resources. During a recent customer visit, I found out that designers are taking advantage of the "test specific job policy" to quickly get to the results of the simulations they are interested in while other simulations are still going on. Making use of a test specific job policy in conjunction with the multi-test bench environment is a clever way of using different hardware farms that are available to designers.

Designers can sweep design variables across multiple test benches to perform extensive design analysis and verification. The ability to enable/disable sweeps for each test gives designers the flexibility to customize analysis and verification plans to meet design requirements. An easy to use design debug environment allows designers to quickly access the required information of failed simulations, allowing designers to analyze issues that are causing design performance issues.

Apart from sweeps, designers can also perform corners analysis and Monte Carlo simulations across these test benches in the same setup. I will be covering these topics in my upcoming blog. Finally, designers can make use of Analog Design Environment XL setup for pre and post-layout simulations to analyze layout parasitic effects

In summary, whereas Virtuoso Analog Design Environment L provides designers with the same use model as the one designers are used to with previous versions of Virtuoso ADE (such as analyzing one test bench at a time), Virtuoso Analog Design Environment XL provides designers with the powerful multi-test bench environment, resulting in increased designer productivity, the efficient use of design infrastructure, and comprehensive design analysis and verification.

To get more details about Virtuoso Analog Design Environment XL and find out how design teams can adopt Virtuoso Analog Design Environment XL in their design flow to take advantage of the productivity enhancing features mentioned in this blog, please contact your Cadence Application Engineer.

Here are the links to some of the Virtuoso Analog Design Environment XL videos.

Note: You need a COS (Cadence Online Support) account to access these videos.

Creating new Analog Design Environment XL view from Analog Design Environment L and Opening existing Analog Design Environment XL view in Analog Design Environment L

Setting up multiple tests in Virtuoso Analog Design Environment XL

Setting specifications & running simulations in Virtuoso Analog Design Environment XL

Variable & parameter sweeps in Virtuoso Analog Design Environment XL

Virtuoso Analog Design Environment XL Debug Environment

Rama Jupalli

SKILL for the Skilled: Sorting With SKILL++

2011-05-03T19:00:00Z

In the previous couple of SKILL for the Skilled postings we looked at some of the features of SKILL++. In fact, we saw local functions, higher-order functions, and lexical scoping. In this episode of SKILL for the Skilled I would like to show a few more practical examples of these concepts.

Functions are first class

In the SKILL language, functions are themselves first class objects. They can be created dynamically, and they can be passed around as arguments to other functions. We'll see in the examples how to write functions that generate functions, and why you might want to do that.

Review of the SKILL sort function

The SKILL primitive sort function, takes two arguments. The first is the list to be sorted, and the second is a function designator indicating a compare predicate. A predicate is a function whose return value is to be interpreted as TRUE or FALSE. A compliant compare predicate (for sort) promises to accept two arguments and return a boolean value indicating whether the two arguments given are in order in some appropriate sense. Often there is already a built-in SKILL function which does the type of comparison needed, and sometimes an on-the-fly function does the trick. The code in example 5.1 uses a pre-existing function, alphalessp as a compare predicate. In this case, the sort function reorders the list of strings alphabetically.

Sorting with built-in sort predicates

;; Example 5.1
(sort (list "this" "is" "a" "list" "of" "words")
      'alphalessp)
  ==> ("a" "is" "list" "of" "this" "words")

As seen previously, if your code is in SKILL++, you can simply reference the global variable whose name is the same as the function name: alphalessp.

;; Example 5.2
(inScheme
  (sort (list "this" "is" "a" "list" "of" "words")
        alphalessp))
  ==> ("a" "is" "list" "of" "this" "words")

For the rest of this article, please assume all top level SKILL expressions reside in a (inScheme ...) form.

Implementing SKILL++ sort predicates

The compare predicate of sort may actually be any callable object. Several types of objects are callable in SKILL. Symbols such as alphalessp are callable if they name existing functions or are somehow auto-loadable. Function objects created by lambda are also callable.

Global functions get created and named when you use procedure or defun. As we saw previously functions can also be created and named locally using flet and labels. But you can also create nameless functions with lambda.

The code in example 5.3 creates a function named fileLengthLessp.

;; Example 5.3
(defun fileLengthLessp (f1 f2)
  (lessp (fileLength f1)
         (fileLength f2)))

The code in example 5.4 creates an equivalent function, i.e., a function that does the same thing as fileLengthLessp when called, but which has no name. You have to store the value in a variable or pass the value directly to a function, such as to the sort function.

;; Example 5.4
(lambda (f1 f2)
  (lessp (fileLength f1)
         (fileLength f2)))

In the following examples (5.5, 5.6, and 5.7) we want to sort a list of file names (strings) according to the file size (in bytes). There are several ways to do this. There is a SKILL built-in function to return the file size, but there is no built-in SKILL function which compares file sizes. However Example 5.3 above implements one named fileLengthLessp. We can use that function as an argument to sort.

;; Example 5.5
(sort (getDirFiles ".")
      fileLengthLessp)

You can also build the function on-the-fly without a name as in Example 5.6.

;; Example 5.6
(sort (getDirFiles ".")
      (lambda (f1 f2)
         (lessp (fileLength f1)
                (fileLength f2))))

You can also do this using flet as in example 5.7.

;; Example 5.7
(flet ((lesspFileLength (f1 f2)
         (lessp (fileLength f1)
                (fileLength f2))))
  (sort (getDirFiles ".")
        lesspFileLength))

Reversing the sort order

Two more examples are seen in examples 5.8 and 5.9. Example 5.8 shows how to sort a list of strings in decreasing order according to (string) length; i.e., longest string first.

;; Example 5.8
(sort list_of_strings
      (lambda (a b)
         (greaterp (strlen a)
                   (strlen b))))

Example 5.9 shows how to sort a list of sub-lists by decreasing order according to (list) length.

;; Example 5.9
(sort list_of_lists
      (lambda (a b)
         (greaterp (length a)
                   (length b))))

Components of the sort predicate

Notice the similar code structure in examples 5.6, 5.8, and 5.9. There are a couple characteristics of the compare function which we can factor out.

test: the kind of relation function, numerical relation such as greater (greaterp) than or less than (lessp), or an alphabetic type of relation such as alphalessp.
key: the kind of attribute we want to compare such as length, strlen, fileLength, or identity.

The identity function

It will simplify a few things later if we first define a very simple function called identity to be a unary function which returns its argument. The identity function defined in example 5.10 is to function application, as zero is to addition, and 1 is to numerical multiplication.

;; Example 5.10

(defun identity (x)
  x)

Higher order functions -- calculating a sort predicate

We can use SKILL++ to calculate the compare function to pass to sort. Writing functions that generate functions is an easy thing to do in SKILL++.

;; Example 5.11
(defun genCmpFunction (@key (test lessp)
                            (key  identity)) ;; see example 5.10
   (lambda (A B)
      (test (key A)
            (key B))))

The function, genCmpFunction defined in Example 5.11, can be called with keyword arguments ?test and ?key and returns a function which is compatible with sort; i.e., it returns a binary function which can be used as a sort predicate. The names test, and key are somewhat standard names--even if a bit confusing. Usage examples are shown in example 5.12. The key defaults to the identity function, and the test defaults to the lessp function.

Using the higher order function

Now, the SKILL sort can be used in a more generalized way. We can rewrite the code examples in 5.5, 5.6, and 5.7.

;; Example 5.12

;; reimplementation of example 5.6
;; sort a list of file names by increasing file size
(sort (getDirFiles ".")
      (genCmpFunction ?key fileLength))

;; reimplementation of example 5.8
;; sort a list of strings by decreasing string length
(sort list_of_strings
      (genCmpFunction ?key strlen
                      ?test greaterp))

;; reimplementation of example 5.9
;; sort a list of sub-lists by decreasing list length
(sort list_of_lists
      (genCmpFunction ?key length
                      ?test greaterp))

Reimplementing the sortcar function

Notice that if the built-in function sortcar did not exist in SKILL, we could implement it using sort as shown in example 5.13.

;; Example 5.13
(defun sortcar (list predicate)
  (sort list
        (genCmpFunction ?test predicate
                        ?key car)))

Sorting objects from the Cadence Database

The genCmpFunction can generate useful sort predicates for sorting data base objects under various criteria. Example 5.14 shows how to sort shapes in a Virtuoso layout from top-to-bottom according to top edge.

;; Example 5.14
(sort (geGetEditCellView)->shapes
      (genCmpFunction ?test greaterp
                      ?key  topEdge))

Example 5.15 shows how to sort the db-instances in a schematic alphabetically according to instance name. In this example, we pass ?key as a function which will retrieve value of the name property from a db-instance.

;; Example 5.15
(sort (geGetEditCellView)->instances
      (genCmpFunction ?test alphalessp
                      ?key (lambda (i) i->name)))

Review

In this posting we looked at the following concepts.

The SKILL built-in sort function
Sorting list of string alphabetically (examples 5.1, 5.2)
Sorting file name by file size (examples 5.5, 5.6, 5.7)
Calculating sort predicates programmatically (example 5.11)
Reimplementing sortcar based on a generalized sort predicate
Using higher-order function in conjunction with sorting strings and db-objects.

To Be Continued

In the next posting we'll see more examples of how to use these types of higher order functions with virtuoso, for example to sort pin figures clockwise around the boundary of the cellView. In addition we'll generalize the genCmpFunction further to allow for secondary and ternary sorting criteria.

Jim Newton

Previous Posts

SKILL for the Skilled: Continued Introduction to SKILL++

SKILL for the Skilled: What is SKILL++?

SKILL for the Skilled: Rule of English Translation

SKILL for the Skilled: Making Programs Clear and Concise

Thing You Didn't Know About Virtuoso: Redux

2011-04-27T23:00:00Z

After a long break, I'm going to try to venture back into the blogosphere, starting off nice and easy--by cheating...

You see, Virtuoso IC 6.1.5 came out at the end of January, and one of the changes made to the Schematic Editor is that many of the handy dockable assistants featured in IC 6.1 are now available at the basic L tier of software. If you don't know what that means, don't worry, because what I'm trying to say is that now, everybody can use these features!

And since I have already blogged about these assistants, I get to write a new article that pretty much consists of nothing but a bunch of links to those previous posts. So here goes...

The assistants that are now available in VSE L are:

Navigator Assistant

Since I wrote the initial post, the Navigator now enables you to add probes using the RMB (remember that "right mouse button"?) on instances, nets or nets and connected instances. You can choose what color probe to create and the probes get highlighted with that color in the schematic and the Navigator all the way down the hierarchy. There is also a search field at the top of the assistant and a new filter to display only probed objects.

Property Editor Assistant

I am still surprised when I sit and work with customers and they are constantly popping up that gigantic bindkey "q" property editor form over and over again. Especially now in IC 6.1.5. You've selected the instance(s). Just look in the lower left corner of your window. The information you're looking for is already displayed right there in front of you. Get your finger off of that "q" key!

Search Assistant

Now you can also use the Search Assistant to find bindkey definitions and CDS environment variables.

World View Assistant

Another woefully underused assistant. With this assistant, coupled with the new Magnifier in IC 6.1.5, you need never zoom in or out again. Yes, I said "Magnifier". Try "View->Magnifier" (or bindkey ".") in the schematic window (use Options->Magnifer to adjust).

Also check out the articles on the general usage of Assistants and Workspaces.

So before you straightaway go for the little "x" button to close those assistants, do a little homework and maybe you'll find something you like!

Stacy Whiteman

Analog IP Verification - A Reference Guide to Practices Used

2011-04-18T17:00:00Z

I have had a lot of discussions recently around improving the final integration of analog IP. There has been a lot of material published over the years to aid in this task, and I wanted to point to some of my favorites while talking about what has and has not changed.

There is a lot to be learned from digital verification methodologies applied to "big A" mixed signal designs, and the first is leveraging a systematic approach to functional verification in order to continually converge on your specification. Applying this approach enables the design team to avoid connectivity issues and expand coverage of more complex analog/mixed-signal systems.The following papers provide a good guide to the growth of mixed signal verification and its future direction with some good examples.

Although the first paper is relatively old, the goal and details outlined by the author are very clear, making this a good foundation to build upon. Here our author, Jonathan David, takes us through a programmable approach to functional verification on a 10/100 Ethernet Phy. Best Practices and Methods for Mixed-Signal Verification

Designer’s Guide outlines a very good methodology for a similar concept with mixed signal verification in their paper, Designer’s Guide Consulting Introduction to Analog Verification. This paper starts to take into consideration the power of abstracting your analog blocks upwards for functional verification.

I cannot forget to mention my friends at Triune Systems and the webinar we put together late last year where they described how they used the top down design methodology approach to converge on design feasibility for power management: Are You Ready for Your Next-Generation Analog/Mixed-Signal Product?

What about the direction that mixed-signal verification and analog functional verification are going and what can be accomplished today? For presentations on Mixed-Signal Approaches in Assertion-Based Verification, and Verification Solutions for Digitally Calibrated Analog Design, see the ARM Tech Conference 2010 proceedings, ARM Tech Conference 2010 Day 1, ATC-122 and ATC-124.

I will leave you with my most recent favorite: William Dunham's webinar with EETimes, Efficient Functional Verification for Mixed Signal IP. There are a lot of opportunities to improve analog verification and the tools are here today to help companies make significant impacts. I hope you all enjoy the material referenced as much as I have, and more importantly can take something away from it to improve your productivity and quality of your silicon.

John Pierce

Will Evolving Language Standards Address Mixed-Signal Verification Problems?

2011-04-18T16:00:00Z

Mixed-signal verification has been one of the hottest topics in the past year, and it was very evident in DVCon 2011, looking at the number of technical papers submitted on this topic. Engineers are looking for solutions to solve tough problems in this space, and the creativity put into developing custom solutions is mind blowing. We are at an interesting stage where engineer's minds are racing past the capabilities of EDA tools and the lack of standard languages to find their own innovative solutions.

First generation standards such as Verilog-AMS and Verilog-A introduced behavioral modeling to the analog world. But the complexity of mixed-signal designs have grown exponentially, and this begs for the evolution of next generation standards. Some of the successful methodologies adopted for digital SoC verification need to be extended to the analog/mixed-signal world. Extraordinary work is being done developing these new standards under the leadership of Scott Little from Freescale Semiconductor, chair of the IEEE SystemVerilog Discrete Real Modeling Committee (SV-DC) and Analog SystemVerilog Assertion (A-SVA) committees. Scott was grateful to address some of my questions on the progress of these standards committees.

What is the charter of SV-DC? How can one participate or contribute to this effort?

SV-DC intends to provide capabilities in SystemVerilog to support efficient modeling of analog/mixed-signal circuit components. These models are to be simulated by the event-driven simulation engine and should, therefore, exhibit simulation performance comparable to digital models and be suitable for system level simulation. The new modeling capabilities will be achieved by natural extensions to the existing SystemVerilog language; no analog solvers or netlist manipulations will be required. [Note: This is the Executive Summary from the SV-DC roadmap. The entire roadmap can be found at http://bit.ly/apjS6s]

SV-DC is a technical subcommittee of the IEEE P1800 (SystemVerilog) Working Group. The participation rules for this group have recently changed. The current rules state that IEEE SA Advanced and Basic members can participate as observers. For a list of IEEE SA members please see http://standards.ieee.org/develop/corpchan/mbrs1.html. For active participation IEEE-SA advanced member companies need to join the P1800 Working Group which requires an additional fee. Information regarding those fees can be obtained from the P1800 Working Group chair, Karen Pieper (karen_l_pieper@yahoo.com).

What applications do you see for the SV-DC functionality?

The primary application that I see for the functionality being developed in SV-DC is the modeling of AMS circuits. Modeling experts and SoC verification engineers have an increasing need for efficient, abstract models for AMS components. The features being discussed in SV-DC will help them fill this need.

Can you tell us about the progress rate of SV-DC? When can we expect a final standard?

The SV-DC committee is currently in the process of refining a proposal that adds user-defined nets and resolution functions to the SystemVerilog language. We believe this proposal provides a core set of real-valued modeling features in SystemVerilog. For example, using these features a user can create a single net containing two real values, one representing voltage and the other representing resistance. In cases where there are multiple drivers on a net of this type the user-defined resolution function will be used to determine the resolved value of the net.

We are on schedule to vote on a final version of that proposal in early May. After that proposal is complete, we have until October 1, 2011 to address additional items. The next item on our agenda is not currently set.

This work is expected to be in the next revision of SystemVerilog which is currently scheduled to be released in the middle of 2012.

Why was this done in IEEE Vs Accellera?

The user community wanted a real-valued modeling solution in the SystemVerilog language, and SystemVerilog work is done in IEEE. It may have been possible to add these features to SystemVerilog through the SystemVerilog/Verilog-AMS (SV-AMS) merger, but it was felt that the majority of the desired features are not present in the current Verilog-AMS standard and would require significant changes to the core SystemVerilog functionality. Based on that analysis, it was decided to add these features directly to the SystemVerilog standard while managing any potential compatibility issues with Verilog-AMS wreal.

Will SV-DC make SV-AMS irrelevant? What things should SV-AMS deliver that SV-DC cannot?

No, SV-DC will not make SV-AMS irrelevant. SV-AMS brings the promise of being able to mix Verilog-AMS constructs with SystemVerilog constructs. For example, using SV-AMS I could access electrical quantities or analog events in an assertion. I could connect a driver to an AMS DUT using an interface. These constructs provide tremendous value and are clearly outside the SV-DC charter.

What is the charter of A-SVA? How can one participate or contribute to this effort?

A-SVA is a subcommittee of Verilog-AMS that is charged with studying language features necessary for AMS assertions. To participate one only needs to begin attending the meetings or participating on the e-mail reflector. Instructions for joining the e-mail reflector can be found on the ASVA web page at http://www.eda.org/twiki/bin/view.cgi/VerilogAMS/AmsAssertions

Where does A-SVA fit in? Is it designed to be part of SV-AMS?

A-SVA fits best into SV-AMS. The A-SVA committee spent a number of months trying to fit the A-SVA requirements into Verilog-AMS or SystemVerilog alone. The eventual conclusion was that the full power of SV-VAMS is needed to properly support A-SVA. The committee is currently investigating the addition of unclocked LTL operators into SVAs as well as the addition of SVAs to Verilog-AMS. Both of these efforts are useful, but they will not provide the full power of A-SVA originally envisioned by the committee.

What are the technical challenges extending assertions from digital to analog/mixed-signal?

One of the primary challenges in extending assertions from digital to AMS is efficiently managing the notion of dense time. The assertion evaluation engine will not be efficient if it checks the property at every point of time. However, it must check often enough to accurately measure the property.

Another key difficulty is defining the syntax and semantics for an assertion language that allows the free intermingling of realtime and clocked sequences and properties. We believe this is a key feature of a user friendly AMS assertion language, but it is a difficult problem to solve.

What is the value add of assertions for verifying analog designs?

The value added by assertions when verifying analog designs is very similar to the value added by assertions when verifying digital designs. Assertions enable designers and verification engineers to encode assumptions and specifications in an unambiguous manner. Assertions also enable efficient debugging by identifying errors when and where they occur.

What needs to happen for engineers to adopt such a methodology?

I believe the primary thing that needs to happen for adoption of an AMS assertion-based verification methodology is tool support. Right now, I am seeing some adoption of the methodology even with the convoluted ways we are forced to use it today. I expect increased adoption when the flow becomes easier to use. Increasing adoption of these methods isn't difficult when you can demonstrate that it finds bugs and improves quality.

Do you think a "metric driven verification" methodology can increase the overall productivity of analog designs? Why?

I hesitate to say that metric driven verification will increase the productivity of analog designs. I would rather focus on how it can improve the quality of analog design. Metric driven verification is focused on quantifying what has been verified and what still needs to be verified. I believe that adding this additional structure into the traditional AMS verification process will improve the overall quality of AMS designs.

What are the main drivers for adoption of such a methodology?

The main driver is avoiding the dreaded re-spin. AMS circuits are becoming more complicated along several different axes. Two of the most notable drivers of metric driven verification are the addition of complicated digital control and low power features. Traditional analog verification methods do a good job of getting the analog content functioning properly, but they often fall short in dealing with problems related to integration and low power features. I have seen a metric driven methodology improve the ability for AMS designers to identify and fix integration and low power issues.

Srikanth V Raghavan

Virtuoso IC 5.1.41 Was Good but Virtuoso IC 6.1 is Better

2011-04-13T13:00:00Z

With the recent release of unified custom/analog flow that is based on the latest version of the Virtuoso IC 6.1.5 technologies (see Virtuoso IC 6.1.5 press release here), it is time to revisit the strengths of Virtuoso IC 6.1 platform and find out how new capabilities enable designers with the productivity gains they have been clamoring for.

Open Access and SKILL

One of the major changes in Virtuoso IC 6.1 is the database. For the last 20 years, the Cadence Data Base (CDB) has been used. However, starting from IC 6.1, keeping pace with the "open source" movement and the Cadence goal of an open environment, we have started using the Open Access (OA) database. This allows custom/analog teams to save the data in a format that can be accessed by applications from different EDA vendors without the need for translation.

The OA database was built by Cadence and was donated to Silicon Integration Initiative (Si2) to encourage the adoption of it by other EDA vendors. The OA database was architected and developed to handle larger designs, offer faster response and enable easier implementation. Cadence works closely with customers who are migrating to Virtuoso IC 6.1 technology by providing technical help and application resources to make the migration as seamless as possible.

Cadence users know that the SKILL language plays a central role in our technologies. All the PDK and GUI development is done in SKILL and many tools that integrate into Virtuoso technologies do so using SKILL. SKILL is ubiquitous in PDK development with each and every major foundry supplying SKILL PCells as part of their PDKs.

In Virtuoso IC 6.1, we greatly improved the functionality of SKILL. Cadence recognizes that a new crop of CAD engineers and software developers are more in-tune with object oriented programming concepts. To let engineers take advantage of these techniques in customizing their design flows, Cadence has made SKILL++ available to developers. Like other object oriented programming languages, SKILL++ lets CAD teams take advantage of latest developments in software programming in customizing their design flows and methodologies.

Virtuoso Schematic Editor

The Industry leading Cadence Virtuoso Schematic Editor provides custom/analog engineers with an easy to use design entry tool with various capabilities to enable fast, intuitive, and comprehensive schematic capture. To ensure a smooth and easy transition to Virtuoso IC 6.1, the same look and feel and a similar use model was maintained, at the same time providing engineers with features and capabilities to increase the productivity in their day-to-day design activities. Features include:

Easy-to-use, lockable Navigator, Property Editor, Search, Annotation Browser, World View assistants, etc... to increase designer efficiency
On-canvas editing capability to edit, modify object properties without the need to open multiple forms
Multi-window multi-tabbed schematic canvas, bookmarks, and history provide an intuitive editing environment, allowing designers to open multiple schematics, or different views of the same design, consequently enabling effective design management
A magnifier to explore and enlarge an area under the mouse cursor, read and edit labels and save zoom-in/out commands
HTML publisher for schematics - Create multi-frame HTML/XML document, with all top-to-bottom schematic views, an index and hyperlinks, to walk through the design with the preferred browser
Power Intent Export Assistant and Common Power Format (CPF) file creation capability to set power domains in a hierarchical schematic

Virtuoso IC 6.1 is the first release to enable constraint-driven design. Constraints are design rules that allow design teams to maintain design intent throughout the design cycle. Instead of relying on schematic notes, emails and various other documents, constraints provide a systemic methodology to maintain consistent information between front-end designers and back-end physical implementation teams. Easy-to use constraint entry mechanism and constraint notes in Virtuoso IC 6.1 allows for formal communication mechanism across the team members.

To know more about Virtuoso Schematic Editor, click here

In the next few blogs, I will showcase the Virtuoso Analog Design Environment and give you detailed look at its capabilities so that users can find out how the new and improved Virtuoso Analog Design Environment enables designer productivity.

Rama Jupalli

Related Blog Posts

Rapid Analog Prototyping - Handcrafted Layout Gets a Needed Productivity Boost

Early Analysis is Key - Parasitic-Aware Design

Virtuoso IC6.1.5: Software and Fine Red Wine

How Parasitic-Aware Design Flow Improves Custom/Analog Productivity

Rapid Analog Prototyping - Handcrafted Layout Gets a Needed Productivity Boost

2011-03-17T22:00:00Z

As more and more custom/analog designs migrate to advanced process nodes (<65nm), design teams are being confronted with an ever-increasing need to better manage the impact of parasitics throughout the entire custom/analog design flow. In addition, more and more layout design teams are finding themselves drawn into the front-end design team's simulation flow and their path to parasitic closure.

But why is a new approach needed, when many custom/analog methodologies today already incorporate estimated layout dependent effects in PCell device models, device callbacks, and in estimated wire models? At advanced process nodes, layout-dependent effects increasingly not only have to take into account separate device and wire effects, but also the effects of devices and wires related to their surrounding environments,. Anywhere from 20-30% of a circuit's performance can be attributed to the effects of the surrounding environment.

Layout-Dependent Effects

Two such layout dependent effects are shallow trench isolation (STI) and well proximity effect (WPE). STI effects for a device must take into account the distance of a gate to each edge of the diffusion, gate to gate separation, and the overall length of the diffusion. As such, any handcrafting of devices or groups of devices -- including any folding, merging, abutting, and dummy insertion -- all impact STI effects and a consequently a device's performance.

Figure 1 -- STI Illustration

WPE effects must take into account the distance or proximity of a device to the edge of the well, and in turn a device's performance is directly correlated to this distance. This effect can only be accurately determined after placement and any handcrafting, including any merging of multiple devices into common wells.

Continuing with inaccurate parasitic estimation methodologies or inserting time-consuming handcrafted layouts in the midst of highly iterative front-end simulation flows would not only have a negative impact on the productivity of both the front-end design team and layout team, but would increase overall risk in the success of a product.

Thus, new custom/analog design flow methodologies that provide more accurate parasitic estimates faster and sooner in the design flow are needed for advanced node designs.

The Virtuoso parasitic-aware design flow provides parasitic closure faster and in fewer design iterations, without sacrificing design performance on advanced node designs. The Virtuoso parasitic-aware design flow spans the design, verification and implementation phases of custom/analog design. For an overview of the entire Virtuoso parasitic-aware design flow, please see Richard Goering's blog, and for details on the design and verification phases, please see Rama Jupalli's blog. The remainder of this blog will focus on the physical implementation or layout phase, and specifically how Rapid Analog Prototyping delivers more accurate parasitic estimates faster.

Better Productivity for Managing Parasitics

Rapid Analog Prototyping brings handcrafted layout a needed boost in productivity required for managing parasitics in advanced node designs. It does this by selectively automating key aspects of custom/analog layout, providing direct access to advanced automated technologies from the familiar industry-standard Virtuoso layout cockpit, all integrated on a common Open Access database.

By allowing layout designers to selectively automate key aspects of custom/analog layout, they can rapidly create layout prototypes with more accurate parasitics for front-end designers, while focusing their creativity on precision hand crafting final layouts.

There are three key Rapid Analog Prototyping tasks in the physical implementation or layout phase of the Virtuoso parasitic-aware design flow:

Module Generation
Device Placement
Net Routing

Virtuoso's advanced module generators are built on SKILL PCells to automatically assist a layout designer in generating complex, highly matched, structured arrays of devices for common analog subcircuits like differential pairs, current mirrors, and more. A layout designer can selectively automate merging, abutting, and interdigitating multiple devices, as well as inserting dummies and guardrings. The module generators rapidly create DRC and LVS correct layout ready for parasitic extraction while accurately reflecting layout dependent effects such as STI effects.

Virtuoso's advanced custom/analog device placement is capable of rapid constraint driven placement of SKILL PCells and module generators. A layout designer can selectively create rapid placement prototypes in three increasing modes of automation: quick placement for quick area estimation, quick placement based on device positioning in the schematic, and fully automated placement that minimizes area and overall wire length and automatically places similar devices in clusters and merges common wells. The rapid analog placements are DRC and LVS correct layouts ready for parasitic extraction, while accurately reflecting layout dependent effects such as WPE effects.

Virtuoso's advanced custom/analog net routing is provided by the Space-Based Router technology. A layout designer can selectively complete net routing in increasing modes of automation - interactive wire editing, assisted autorouting and fully automated routing. All net routing is DRC and LVS correct layout ready for parasitic extraction, while more accurately reflecting layout dependent effects of wires.

Rapid Analog Prototyping and the Virtuoso parasitic-aware design flow are part of a recently announced Cadence Silicon Realization custom/analog flow focused on unified intent, abstraction, and convergence. This flow leverages the breadth, depth, and integration of Virtuoso Schematic Editor, Virtuoso Analog Design Environment, Virtuoso MMSIM, Virtuoso Layout Suite, and in-design manufacturing Virtuoso DFM.

Please send me your comments on what issues you see with parasitics, how you manage those today in your design flows, and what improvements you would like to see.

Michael Kelly

Early Analysis is Key – Parasitic-Aware Design

2011-03-16T13:00:00Z

Decreasing geometries and increasing design complexity are making the task of designing custom ICs very difficult (not that it was easy before). One of the main issues designers grapple with is the issue of parasitics and their effect on design specifications and yield estimates. With increasing cost pressures and decreasing ASPs, meeting yield targets could decide the commercial success of the chip.

In an era of ever shortening design cycles, waiting for layout engineers to provide designers with a complete, optimized layout and then perform post-layout verification is not always preferable, and in many cases it's inefficient. Having a methodology to consider the effects of parasitics in the early stages of design cycle is crucial to the success of the project. This is precisely where a parasitic-aware design flow comes to the help of designers. Parasitic-aware design is a design methodology that allows designers to understand and analyze the effect of parasitics and help take corrective actions.

There are two aspects to parasitic-aware design flow. One part of parasitic-aware design deals with the front-end design, and the other with the physical implementation (see parasitic-aware design flow diagram here). In this blog we will focus on design and verification phases of design, cover important features of parasitic-aware design flow, and show how these features add value to designers in their day-to-day design activities.

In the front-end, the industry leading tools such as the Virtuoso Schematic Editor and Virtuoso Analog Design Environment allow designers to capture design intent and characterize the design for a multitude of operating conditions. A schematic editor with features like Canvas Magnifier, Custom Checks Creator, and HTML Publisher for Schematics will ensure reduced mouse clicks and increased productivity. Analog Design Environment XL’s Multi-Test environment has statistical analysis (Corners, Monte Carlo) capabilities that allow designers to use hardware resources efficiently, and comprehensively verify the design.

Native RelXpert integration with Analog Design Environment XL will enable designers to perform reliability analysis and better understand age and stress related effects on their designs. Design documentation capabilities provide designers with a simple but powerful way to capture all the necessary information and electronically tie this information to the IP for improved intra- and inter- design team communication.

Parasitic estimation and parasitic stitching to incorporate parasitics in early stages of the design are key steps in the parasitic-aware design flow. These techniques enable designers to leverage the prior knowledge and experience they have about parasitics on similar designs, and to incorporate this knowledge into the design they are working on. Analog Design Environment GXL provides designers with an easy to use GUI to accomplish this task. Designers can estimate parasitics by manually adding R, C, L and K to the schematic, such that the estimated parasitics are representative of those coming from the final layout.

Alternatively, users can stitch parasitics from previously designed modules into the design they are working on. Since the majority of the designs are reused in one form or another, parasitic stitching could be a more accurate form of parasitic estimation. Designers can then use Analog Design Environment XL to simulate and compare results with schematic design to analyze and understand parasitic effects. Designers can subsequently filter, refine, and customize these parasitics to meet their design specific needs and analyze their effects on various figures of merit.

Designers can iterate through this process multiple times to clearly understand parasitic effects in the early stages of design cycle, and do so without a final layout. The availability of various Cadence simulators (such as Spectre, SpectreRF, UltraSim, Accelerated Parallel Simulator, AMS Designer), all using common device models, seamlessly integrated into a single GUI, give designers freedom to choose simulation tools that meet their accuracy, capacity and performance needs. Finally, designers can take advantage of Analog Design Environment GXL optimization to take corrective action and optimize their designs to mitigate parasitic effects.

NOTE: To access “Quick Start” videos that show step-by-step instructions on how to accomplish various tasks outlined above, please contact your local AE or Sales Engineer.

In summary, the parasitic-aware design flow is not a panacea for all the parasitic issues that are plaguing your design, nor is it a single tool that is going to perform miracles. Parasitic-aware design, on the other hand, is a design methodology that allows designers to systematically analyze and understand effects of parasitics during early stages of design cycle and help take corrective actions.

Since designers know more about their designs than anyone else, parasitic-aware design provides a consistent methodology to capture this knowledge in a systematic way, helping designers to maintain design intent throughout the design process. By providing designers with a faster and better way to bring parasitics back into the design, parasitic-aware design allows designers to avoid over-designing and instead focus their energies on fine tuning their design to increase the yield.

Rama Jupalli

Virtuoso IC6.1.5: Software and Fine Red Wine

2011-03-14T12:00:00Z

Software, like fine red wine, can get better with age as well -- but it requires constant advancements to remain a vibrant contributor. Such is the case with the Virtuoso IC6.1.5 custom/analog technology release, which delivers on the promise of Silicon Realization with capabilities that maintain design intent throughout the custom/analog flow, simplify the abstraction of analog information to provide high-performance verification capability, and lead to design convergence by providing a common cockpit for in-design signoff technology and support for the Cadence Low-Power Solution.

The enhanced Virtuoso-based custom/analog flow spans design, implementation and verification. The amount of individual tool updates are too numerous to blog about, so I encourage our users to spend a bit of time with the What's New document that is available from Cadence Online Support. Instead, I want to highlight and provide more details on the three larger elements that are encapsulated in the IC6.1.5 release.

Support for Globalized Teams: A variety of new publishing features within the schematic, analysis environment, and waveform window allow for the easy exchange of information across the web. We realize that many of our customers work on a 24-hour clock, and the ability to exchange accurate information at each hand-off point is crucial to keeping a design on track. In previous versions of our software, we have given our customers the ability to closely monitor the design and the implementation of their circuits by using Cadence's design constraint technology. You can learn more about this technology by viewing the Constraint Webinar if you wish.

With this release of Virtuoso, our users can create hyperlinked schematics and datasheets that can be put together instantly, and enable design review at any moment. There is no need to fumble around anymore looking for that particular document that is stored somewhere that makes no sense! Instead, the documentation is stored with the design, and becomes a managed "cellview" just like the schematic or the layout. Archiving is a snap since all the data you will ever need is now located exactly where it should be -- with the design. You really can maintain the intent of your custom/analog design whether it is around the room or around the globe.

New Design Methodologies: Understanding the "impact" of the analog portion of any design is crucial to the success of on-time arrival for your chip. In some cases, it is the parasitics and signal integrity of the analog portion that goes awry. In other cases, it is the integration of the analog into a larger SoC where the problems begin. In either case, Cadence provides solutions to these problems.

For troublesome analog, we offer the parasitic-aware design flow, which allows users to determine the impact of design choices much sooner in the design process. Users can easily include previous knowledge of topologies within the design flow, using these parasitic "estimates" to quickly assess design impact, and then use a combination of constraints and automated layout features to prototype blocks that can be fully extracted and analyzed. These loops are very short and can provide the designer with a much better sense of the design long before any formal layout is fully committed to paper.

Once the prototyping is done, the implementation engineer will also have a better direction to take the lead to a faster "ultimate" solution. They can see the critical design choices and have the tools they are using to implement the design respond to those critical decisions, thus supplementing their own knowledge to create an environment that employs best practices of the manual and automated design flow. If using design constraints, they can be easily checked to see if they were achieved or not, and if not, a notation can be made as to why not. If the implementation engineers discover that important implementation choices need to be made, they can add information (constraints) and back-annotate these to the schematic to act as the golden reference.

In the case of analog abstraction, the new features for Virtuoso IC6.1.5 include the automatic creation of a Common Power Format file from an analog schematic to test the effects of turning on/off different regions of the chip during its operation. Through a simple GUI, the analog engineer defines the power needs for his block, and that information along with the schematic generates the proper CPF file. This file is now used as part of the Cadence Low-Power Solution. This enables the Cadence Low-Power Solution to extend to the ever increasing number mixed-signal designs.

And lastly, with IC6.1.5 we give you the ability to make your existing methodologies new again with the addition of our next generation Accelerated Parallel Simulator and new waveform technology. We continue to expand our simulation technology to take advantage of the latest hardware configurations that are available. We see our customers paying attention not only to their software requirements, but also their capital budgets to make the best choices when it comes to spending for new hardware.

For customers who invest in multi-core machines, Cadence wants to make sure that you are able to exploit that technology as efficiently as possible. To that end we are introducing our APS in a "Distributed" mode. We have been offering our customers speed on single core and multi-core compute platforms. Now we allow you the power to harness multiple, multi-core compute platforms for your most demanding transient simulations to realize peak performance when you need it, particularly at design sign-off time. And don't worry if those transient files that are produced are tens to hundreds of Gigabytes in size. Our completely new an upgraded waveform window technology has been tuned with our simulators to provide performance that is unmatched within the EDA industry for large databases. Combined with its new measurement and extended mixed-signal analysis capabilities, we look forward to you being pleasantly delighted with the new Virtuoso Visualization and Analysis window that comes standard with our Analog Design Environment product line.

In-Design Signoff: Cadence recognizes the fact that traditional signoff is accomplished today by using expensive tools and the end of an expensive design process to find problems that are now really expensive to fix! Anyone see a problem with that? ...anyone?? Clearly this is NOT the way to approach daily design. Instead Cadence allows its signoff technology under the Virtuoso layout user interface to be accessible at any time during the implementation of the design. For instance, let's say you want to check to see if the IR drop across your power rails was going to be severe enough to miss the power specification. Or, perhaps the electromigration that is expected in this technology is going to cause a hotspot or a short somewhere in your design. Or finally, you may be working with sub-45nm technology which you can almost guarantee won't manufacture a proper mask without intervention and compensation during the design phase.

In the past, a user would leave their layout window, run tools on the outside on the database, and then view the results in a third-party display with the translation and fixing left to user to remember. That's a completely error prone way to design and has no place anymore in sophisticated design methodologies. An engineer should be able to see critical problem directly on their layout within the context of the tool that they will use to either fix the problem, or verify the problem was fixed using some sort of automation. Now you have a real design flow that creates productivity instead of frustration. Cadence allows our advanced technology such as Virtuoso Power System, Cadence Litho Electrical Analyzer and Physical Analyzer and our pattern matching DRC technology from the Cadence Physical Verification System all to be used within the cockpit of the Virtuoso Layout Suite. Find, fix and verify all the time in one location. You can save your expensive verification tools to simply be a signoff that Cadence was right all along.

Cadence is pleased that our customers, most recently Wolfson, have joined a growing list of public supporters for the expanded Virtuoso custom/analog flow, finding productivity improvements across the board and providing them with a 25-30% time saving for their designs. For the last 20 years, Cadence has constantly innovated and led the way in solving the complexities of custom/analog design, implementation, and verification. We look forward to serving your design needs into the future, and sharing a glass of wine as friends when we can.

I encourage you to read the press release, What's New document, other collateral covering the new release of Virtuoso, and discuss your thoughts with me. Are the enhancements what you deem as essential in making you more productive? What do you see out there that you think we should know about?

Steve Lewis

Q&A: IBM Modeling Team Describes Advanced SOI Qualification Flow In Cadence MMSIM Platform

2011-02-23T19:00:00Z

Circuits implemented using sub-micron technologies require designers to meet tighter and tighter specifications despite increasing statistical variation and complexity. High correlations between actual silicon and circuit verification using advanced SPICE models are therefore a must to ensure first pass design success. This characterization requires a high degree of cooperation and integration between modeling engineers and circuit simulation providers.

In this interview, members of the IBM modeling team talk about the verification effort that was initiated and completed last year between Cadence and IBM using silicon on insulator (SOI) advanced process nodes as a pilot. The goal between the two teams was to generate a robust, exhaustive and efficient model qualification flow using Cadence SPICE simulators (Spectre, Ultrasim, APS) specifically for IBM SOI process nodes. This SPICE verification flow was successfully implemented in MMSIM 10.1 and above.

The people involved in this work are:

Radhika Allamraju, IBM, started working with IBM's bulk models in 2003 and moved over to SOI a couple of years ago.
Carl Wermer, IBM, has been supporting design customers using IBM's SOI models. Previously he worked in process engineering and characterization.
Joe Watts is a senior technical staff member at IBM and currently provides guidance to compact model groups in SOI and bulk. He is also chair of the Compact Model Council (CMC).
Helene Thibieroz is a staff application engineer in Cadence Customer support and has been supporting Cadence customers for analog/mixed-signal products for 10 years.
Jushan Xie is a Cadence engineering director responsible for a simulation infrastructure that includes device modeling, simulation front end (SFE), MDL, and reliability simulation.
Natarajan Krishnan is a Cadence staff product verification engineer, leading product validation teams of MMSIM and AMS simulation products.

Q: Carl, Joe, can you please give us some background about modeling qualification at IBM and the flows and procedures you are using?

Carl: FET device modeling qualification at IBM starts from a new release of a compact model, such as BSIMSOI4.31 from U.C. Berkeley. Senior device modelers at IBM are part of the CMC [Compact Model Council] which supports the industry review, testing and adoption of a new compact model code. IBM and Cadence are both part of the CMC, and we started working together as part of this organization.

After a new and/or updated compact model is accepted by the CMC, it is implemented by IBM in our internal simulator, and the model is fit to proprietary device data or targets. It is also implemented in the Cadence common model interface and used by all MMSIM simulators including APS [Advanced Parallel Simulator], Spectre, and Ultrasim.

Engineers use both internal and vendor tools to extract the fitting parameters that support matching between the compact model and silicon.

After the model is built, testing over a range of conditions is done to confirm the fit is correct and self consistent.

Joe: For C based models we have learned there is a need to test the analytic derivatives from the model against finite difference derivatives calculated from the primary outputs of current and charge. For BSIMSOI, we put a great deal of effort into this and fixed a large number of errors.

In a Verilog-A model the compiler generates the derivatives automatically, so this is not necessary. In general the CMC requires verification to make sure that a new model or new features in an old model can match hardware measurements, and that it runs and converges for some sample circuits and gives reasonable circuit results. IBM does such tests for enhancements we request, and other companies do them for enhancements they request. Normally the circuits are not shared with the CMC because of IP contained in the circuits.

Q: What simulation challenges are device/modeling engineers facing with BSIMSOI, especially when dealing with advanced process nodes?

Carl: We have internal and external customers who use Spectre and other commercial simulators. So, after a model is generated for a given technology, we still need to check that the model implementation and results are consistent across many vendor simulators.

To ensure consistency between simulators, we run an exhaustive suite of DC netlists. The goal is to monitor multiple outputs (such as Ids, QG, cgg, gds) while varying process, temperature and voltage biases. We also check simple circuit delay measurements at PVT corners.

In addition, we also have implemented a large number of features within the compact models to support parameter variability (process statistics) and allow designer and developers to predict process sensitivity. Those features need frequent updates and changes as more complex solutions are required to model the increased complexity caused by smaller and smaller process dimensions. The same effort is also applied in Verilog-A for the passive models.

We use different Cadence simulators. We first run Spectre to compare graphical outputs and check basic functionality. We then take advantage of Spectremdl scripts for more complex simulations (such as Monte Carlo, corners) and measurement capability. Spectre has proven to be extremely efficient in parsing all the model code we use and giving good run times, particularly for large Monte Carlo simulations.

Last, we compare a large set of outputs to ensure consistent implementation of our models across several commercial simulators (including Spectre) using Perl scripts and an internal IBM tool.

Q: Based on your experience, what are the simulation challenges that design engineers are facing with BSIMSOI?

Carl: I have seen the same pattern with a number of IBM customers making the transition from bulk to SOI. There is confusion over what to do with floating body nodes and concerns over slower run times and some extra convergence challenges. The structures for body contacted models are also an initial hurdle.

That being said, we now have a large number of design teams have cleared these early hurdles and are designing successfully in SOI. For convergence questions, we first look for problems with the compact models and the customer set-up, and then rely on the Cadence customer support team to take over.

Joe: For C based models we need to test the analytic derivatives from the model against finite difference derivatives calculated from the primary outputs of current and charge. BSIMSOI 4.0-4.2 had serious convergence issues because of the derivative errors mentioned previously. BSIMSOI 4.3 had much better derivatives and at least in our tests convergence improved. Another hurdle for logic design teams moving to SOI is the history effect. New teams need help understanding the effect and learning to design to accommodate it.

Q: What was the triggering factor that started this collaboration?

Carl: I have been working with Cadence on compact models on and off and since 1998. Regarding SOI, significant work investment did not start until 2000. Customers who had been using Spectre with bulk models moved to SOI and wanted to continue to work with the Cadence Spectre simulator.

Along the way, we have dealt with a number of different issues related to different implementation of the UCB compact model updates in different simulators. These would typically be caught by our regression tests performed for each simulator.

One recent problem we addressed with the Cadence team started when a third party customer asked them for a bug fix of the Berkeley BSIMSOI compact model that we also used. Ideally, Cadence would have been able to just integrate a new release from Berkeley, with a new version identifier, including the fix, and the customer could have moved to that version. However, the update from Berkeley was many months off, and also included other code updates not everyone was ready to work with.

The follow-up meetings between Cadence and IBM tackled the obvious problem on how a vendor can securely and rapidly provide fixes in a code that is version controlled by another organization, while also allowing users to either apply the fix, or stay with the code they have already qualified.

After some review, Cadence proposed an elegant solution, where they now support an additional parameter in the model cards that allows us to include or exclude different bug fixes in the code from UCB. If a value was not assigned, it would just default to the original code, so there are no unexpected results and back compatibility is fully preserved.

This collaboration work also revealed that the regression testing done by Cadence did not fully match IBM set of regression tests. Cadence therefore initiated the effort of aligning their regression tests and verification procedures to match with IBM ones and worked closely with us to close the gap.

Q: Can you describe the different steps that IBM and Cadence took jointly to define a model qualification specifically for IBM SOI process nodes?

Carl: In response to the problem where our testing flagged an unexpected change in Berkeley BSIMSOI code, the Cadence team stepped up and scheduled meetings to work with us and make sure their regression testing was updated to reflect our needs. During those meetings, both parties identified an exhaustive set of regression tests that would be used by both Cadence and IBM.

We then identified an IBM SOI process node technology file that could be used by Cadence R&D to ensure all parameters extracted by IBM are tested. We last identified how often those regression tests should be performed and how they would be communicated to IBM. One of the key issue was to make sure our large suite of model output measures for device current and charge, along with derivatives like the related capacitance and outputs like gm/gds, would be fully tested by Cadence. As a result, Cadence added more regression tests to fully match with IBM model validation.

Q: Can you describe the outcome and results? What was achieved through this model qualification process?

Carl: We sometimes work on very tight schedules, where features in the latest compact model qualified by the CMC are required in the device models we give to our customers. Since we need to distribute these models for multiple simulators, this puts pressure on the vendors we work with. Knowing that Cadence regression tests now fully integrate our areas of concern is a big positive and significantly reduces overall SOI model validation cycle time.

Q: How is this qualification process going to improve IBM productivity and SOI process node accuracy?

Carl: There will be a reduction in the exposure that we would have with customers waiting for the latest model release, and not being able to work with it because not all the simulators properly support it.

Q: How do you think this is going to have a positive impact for designers? Which Berkeley version would you recommend to use?

Radhika: We are moving or have moved to using BSIMSOI4.31 for SOI 22nm and 32nm nodes.

Q: What was your overall experience working with Cadence team? Would you agree this team was awesome?

Carl: While not everyone can be awesome, we are fortunate that Cadence has its share of people who are awesome; very insightful, quick to help us when we need advice/guidance using Cadence tools, and also quick to recognize and respond when there are problems that requires changes at their end.

Q: How do you see this collaboration in the future? What would be the next step?

Radhika: Going into the next process node, we will be working with BSIMSOI4.4 and either bsim-img and /or bsim-mg. There are significant changes in the multigate models and what we have learned working together in BSIMSOI2 through 4.31 will benefit both teams. We are also looking at moving to APS, as IBM and the IBM design teams we work with have already benefited from this simulator.

Helene Thibieroz

Analog Assertion Based Verification Methodology – Reality or a Dream? (Part 2)

2011-02-09T22:00:00Z

The design and verification methodology for analog circuits has not changed much over the past decade. But the complexity of analog designs has grown exponentially. Analog parts are not just on the peripherals of SoCs any more. It is very common to have complex analog IP in applications such as communications, transportation and bio-medical devices. So it is not enough to just verify analog designs in isolation.

There is an added emphasis on two major concepts:

1) Verify the analog design in isolation thoroughly for functional correctness. This is very similar to having a thorough block-level verification methodology in the digital world. The block handed over to the SoC integration team needs to be bug free. The statement that "debugging issues at the block level is much easier than debugging them at the SoC level" applies to all the analog blocks that become part of the mixed-signal SoC. This process demands an advanced methodology that can build significant automation into the verification of analog designs.

2) The advanced methodology needs to align itself with the SoC verification methodology. What this means is that the pre-verified analog blocks should be delivered to the SoC integration team in an easily consumable manner. At the simplest level it could mean delivering a high performance behavioral model that is functionally equivalent to the analog design. At the next level it could mean a set of assertions (that goes with the behavioral model) that the SoC verification engineer could turn on for the analog blocks to get visibility into the functionality for debugging purposes or metric collection purposes.

There are three important ideas that resonate with assertions: Observability, Controllability and Reuse. Put them all together and it simply means increased productivity. Assertions can describe design functionality in succinct statements. Some common properties could be

Looking for a certain value on a signal under given conditions at a given time
Looking for a logical combination of values on certain signals under given conditions at a given time
Looking for a sequential relationship between multiple signals over a period of time

One of the key value-adds of assertions is the ease of debugging. The visual inspection of waveforms (a very common practice still in the analog world) to make sure that a design is behaving correctly is very inefficient. It is extremely time consuming and error-prone, not to mention the length of analog simulations adding to the burden of analysis. Also the engineer has to wait for the end of simulation to find out about real design issues, or many times, just simple user setup issues.

By capturing the main design functionality and the input assumptions as part of assertions, the verification environment becomes extremely interactive. Assertions fire error messages as soon as a property is violated, and the user can stop the simulation right away. Once the simulation is stopped, the user is taken to the time stamp at which the error was fired. Our friends in the digital world have perfected the debugging of assertions and we can leverage it right away.

There are multiple standard assertion languages that digital verification engineers use extensively. Property Specification Language (PSL) and SystemVerilog Assertions (SVA) are the most popular ones. Cadence has worked vigorously in extending these languages to support assertion based verification for analog designs. These techniques are discussed in an excellent paper presented by my colleagues recently at ARM Technology Conference 2010 (click on Day 1 and scroll down to ATC-122).

In general the standard assertion languages depend on discrete events that are clocked to build meaningful sequences. Since analog values are continuous, the standard languages need to find a way to handle these. While several ad-hoc methodologies exist today, it is important to standardize this flow. I sincerely urge the analog design community to participate in the Accellera standardization process to find a solution that is practical and portable across all phases of design and verification cycle.

In conclusion, when I try to compare the evolution of assertion-based verification on the digital side to what is happening now on the analog side, I see the exact same problems. The lack of standard languages and methodology, the lack of consistent tool support, the lack of training and use cases and the lack of availability of IP are all not new to the design community. But the demand for all the above has been clearly established by the complexity of mixed signal SoC realization, and Cadence has taken a leadership role on delivering these solutions to our customers.

Srikanth V Raghavan

Analog Assertion Based Verification Methodology – Reality or a Dream? (Part 1)

SKILL for the Skilled: Continued Introduction to SKILL++

2011-01-25T17:00:00Z

In my previous posting, which provided an introduction to SKILL++, I showed a simple but powerful design hierarchy descent function that has various potential uses. The function is called walkCvHier. As a reminder, here is the SKILL++ code again.

1.1: (defun walkCvHier (cv consume)
1.2:   (foreach inst cv~>instances
1.3:     (walkCvHier inst~>master consume))
1.4:   (consume cv))

Just to reiterate: this function is naive for demonstration purposes. You can easily imagine ways of enhancing or generalizing this function to be more robust and handle more complicated hierarchy descent. I encourage the reader to experiment with such enhancements, and feel free to post your suggestions, or questions in the comment section of this blog.

In the following paragraphs, I'll show more advanced uses of the walkCvHier function. Please assume that all the code in this article is SKILL++ which means it is defined in a source file with a .ils extension.

Local (private) function

In the previous article I showed how to implement the reportCvHier by writing a private, global function _reportCv. It turns out there are better ways of doing this in SKILL++ which don't require polluting the global function name space. It is not necessary to make this client function visible to the world simply to pass it as a parameter to walkCvHier.

If you are using IC 6.1.5, a more explicit way of defining and referencing private (local) functions is to use the newly available macro flet.

4.1: (defun reportCvHier (top_cv)
4.2:   (flet ((reportCv (cv)
4.3:           (println (list cv~>libName
4.4:                          cv~>cellName
4.5:                          cv~>viewName))))
4.6:     (walkCvHier top_cv reportCv)))

The flet macro may be used to define one or more local functions which are thereafter available for reference by name inside the body of the flet. Such a by-name reference is shown on line 4.6 in the example above, where the local function named reportCv is only visible and callable within the body of the flet form (i.e., within the matching parentheses which surround flet). This local function has a single required argument named cv. Since this is SKILL++, we are free to use function names (global or local) as if they were variable names, as on line 4.6.

One power of local functions over global functions is their ability to securely reference other lexical variables which are in scope. For example, it would be possible for the local function reportCv to reference the variable top_cv if necessary. Because reportCv lies textually within the matching parentheses of the (defun reportCvHier ...) form, it is free to use all the local variables which that form binds, including the formal parameter of top_cv. Other examples of these are shown on lines 6.4 and 7.4 below.

If you don't have access to IC 6.1.5, you may use the following construct. In this case we simply create a function on-the-fly without a name, and pass it directly to reportCvHier.

5.1: (defun reportCvHier (cv)
5.2:   (walkCvHier cv (lambda (cv)
5.3:                    (println (list cv~>libName
5.4:                                   cv~>cellName
5.5:                                   cv~>viewName)))))

Functions that manipulate state

In the next example (lines 6.1-6.5) I'd like to use walkCvHier to count the number of cellViews in the hierarchy, and in (7.1-7.5) build a table mapping each cellView to the number of times it occurs in the hierarchy. In this case the consumer function passed to walkCvHier needs to modify some state (such as, a counter or a hash table) within the calling function.

How would you attack this with traditional SKILL? With traditional SKILL the consumer function would probably need to modify a global variable to maintain the count, introducing two immediately apparent problems. 1) the function would probably not be non-reentrant.That is, you may not be able to pass in consumer function which itself calls walkCvHier. 2) If the consumer function encounters an error, this global variable could be left in an incomplete state, which would confuse subsequent calls.

SKILL++ and state manipulation

Why do these problems vanish with the SKILL++ approach? Because there is no need for the global variable. The variable can remain local and lexical as seen on lines 6.2 and 7.2.

This function countCvHier passes a function to walkCvHier which increments a variable, occurrences, at each step in the hierarchy. Note that the walkCvHier knows absolutely nothing about the local variable occurrences. Moreover, even if walkCvHier were implemented having a local variable of the same name it would not have any ill effect on countCvHier.

6.1: (defun countCvHier (cv)
6.2:   (let ((occurrences 0))
6.3:     (walkCvHier cv (lambda (cv)
6.4:                      occurrences++))
6.5:     occurrences))

In the function occureHier, we use the same technique to pass a function to walkCvHier which modifies a hash table referenced by the local variable, occurrences.

7.1: (defun occureHier (cv)
7.2:   (let ((occurrences (makeTable 'occur 0)))
7.3:     (walkCvHier cv (lambda (cv)
7.4:                      occurrences[cv] = (add1 occurrences[cv])))
7.5:     occurrences))

It is perhaps worth emphasizing that if you were using traditional SKILL rather than SKILL++, this technique would fail for several reasons. These problems boil down in the end to differences between dynamic and global variables. While dynamic variables are interesting and have powerful uses, this is not one such place to use them. Without giving a detailed explanation of subtle errors some of the problems are the following:

You'd have to be sure to use a variable on lines 6.2, 6.4, 6.5, 7.2, 7.4, and 7.5 which were NOT also defined in the walkCvHier function.
If the consumer function being passed to walkCvHier actually made an explicit call to walkCvHier with a different consumer function, they would not both be able to use the same variable name.
You would not be able to know that without access to the source code for walkCvHier, which you might not have.

Purging the hierarchy

If you want to purge all cellViews in a design hierarchy you might think of evaluating something like (walkCvHier cv dbPurge), but that probably wouldn't be a good idea. Why? Well for one reason, the same cellView might (and probably does) occur multiple times. You don't want cellViews being purged while they are still needed for traversal. We need to call dbPurge iteratively over a list of cellViews where each cellView occurs only once and children always precede parents. Here is a function which will do that.

8.1: (defun purgeCvHier (cv)
8.2:   (let ((visited nil))
8.3:     (walkCvHier cv (lambda (cv)
8.4:                      (unless (memq cv visited)
8.5:                        (push cv visited))))
8.6:     (mapc dbPurge (reverse visited))))

How does it work? Neither the consumer function nor consequently the traversal function walkCvHier actually purge anything, but rather the consumer function collects a list of cellViews that are visited. Since the walkCvHier is written such that it descends into children cellViews before applying the consumer function to the parent, purgeCvHier simply uses the SKILL push macro to build a list in reverse order, so that parents come before children -- a small problem that is easily resolved with a call to reverse.

A more robust traversal implementation of walkCvHier function could of course allow two consumer functions to be used -- one which is applied before traversing into children cellViews, and a second to be called after each step of the descent is finished. You, the reader, might consider implementing a function. Alternatively, you could provide an optional argument to walkCvHier which specifies whether the consumer function will be called before or after the descent.

More about flet

There is one important restriction on local functions defined with flet: they are not allowed to call themselves recursively, and if you define more than one local function in a single flet, they are not allowed to call each other. You might initially think this is a limitation, but actually it turns out to be a powerful feature which we can look at in a future posting. If anyone is interested, please ask in the comment section of this blog.

If you really need to call a local function recursively, or you need to write several local functions, some of which call other ones, you can use labels instead. Its syntax is exactly the same as flet, but its scoping rules are different.

Some other Lisp dialects provide implementations of flet and labels. The ones I'm aware of are Common Lisp and Emacs Lisp.

Summary

What you've seen above are some basics and a few more advanced features of SKILL++. Using local functions makes your SKILL++ code more self-contained without sacrificing modularity. And it's pretty easy to use SKILL++ on practical, easy to understand problems.

We'll look at some more examples in future articles.

See Also:

Lexical vs. dynamic scoping
flet and labels in Common Lisp and Emacs Lisp.

Jim Newton

Analog Assertion Based Verification Methodology – Reality or a Dream? (Part 1)

2011-01-24T23:00:00Z

There is no doubt in my mind that assertions will play a significant role in analog verification, be it verifying individual analog blocks or a complete mixed-signal SoC in the near future. So yes, it is for real and it is here to stay. I hope to convince you in this blog that you should take a closer look at adopting assertion based verification (ABV) for your next mixed-signal design. I have worked on assertions extensively over the past several years and still remember very well the resistance I faced from customers in early 2004 when ABV was making its official debut into the digital world. I see similarities in the barriers faced in both the analog (today) and digital (a few years back) worlds for wide adoption of this powerful verification technique.

Let's go back to year 2004 for a moment:

Digital engineers have been using procedural languages such as Verilog and VHDL for a very long time to design and verify their chips. Advanced verification languages such as Specman e, VERA, and C++ opened up new dimensions to traditional verification methodologies. Metric driven verification (MDV) improved the productivity of verification engineers by allowing them to test designs exhaustively, using random stimulus and at the same time finding bugs earlier in the verification cycle. SystemVerilog was evolving as the new standard language.

Around the same time formal verification was also catching up. Formal tools worked on proving design properties. Properties describe the design functionality in an easily readable format called assertions. The formal tools drive the design into numerous states exhaustively, and prove that the properties will always hold true or that the design state relevant to the property can never be reached, hence increasing the confidence of the verification engineer. It did not take the methodology leaders very long to leverage the power of assertions in a constrained-random verification environment. The exhaustiveness of the random simulations made assertions a perfect fit for MDV. Assertions once written hang around forever no matter what the status of the verification cycle. It is like a 24 hour security guard that is continuously looking to spot problems.

So assertions were adopted overnight by all digital verification teams across the globe, right? Wrong. Let's look at the barriers faced by assertions in the digital world.

1) Remember Verilog was/is still king. So it was no surprise that a declarative and abstract language feature such as assertions spooked the engineers in the beginning. The advantages of a declarative language over a procedural language are obvious by now but it is worth mentioning them one more time.

Verilog is verbose and it becomes difficult to read and maintain code for complex verification environments.
Verilog is not well suited for testing parallel events and if not written carefully it can miss capturing certain triggered events.
Verilog does not have built-in mechanism to provide functional coverage.

Assertions, on the other hand, are succinct, easily readable and maintainable, support spawning off multiple threads (parallel events) and have built-in mechanisms to collect coverage.

2) Who should be writing the assertions? The designer or the verification engineer? This is an ongoing debate. The logic is very clear but the logistics (such as resources) make these decisions in our extremely time constrained world. At the block level the individual designer must write the assertions. It is a great way to document the design functionality before handing the block over to the verification team. The verification engineers will write the interface level and system level assertions.

3) Which assertion language should I use? The existence of multiple flavors of assertion languages such as OVL, PSL, OVA, SVA and several other proprietary languages used by individual semiconductor companies left the EDA vendors and chip companies confused. As the dust settled and some standards evolved there was still resistance for wide adoption. Why?

Lack of re-usable assertion IP and real world examples.
Lack of a well defined ABV methodology.
Lack of sophisticated assertion debugging methodologies.

But as tools matured over time ABV has found its home in the mainstream functional verification methodology and is an integral part of every SoC verification environment today.

Now let us come back to 2011:

The complexity of SoCs has made analog mixed-signal verification a must (Applying Digital-Centric Verification Methodologies to Analog). Excellent progress has been made in the evolution of new language extensions catering to mixed signal verification. The first and the biggest challenge in verifying these complex SoCs is performance, and the introduction of analog behavioral modeling has proved to be a viable solution. Replacing the transistor level analog circuits with functional behavioral models have allowed the SoC integration and verification engineers to get their job done in a reasonable time.

Now that we have the analog blocks represented in the top level SoC, are we done? Is it enough to just verify the interface between the analog and digital blocks? No. Absolutely not. We have an opportunity to enhance the entire SoC verification environment by bringing in the functionality of the analog blocks as part of the MDV environment. Wouldn't it be great if the analog blocks contributed to the overall coverage closure of the verification plan? Wouldn't it be great if the analog blocks get verified in the context of the complete SoC verification environment for their core functionality? And what better way to accomplish this than analog ABV?

Like most complex methodologies it is easier said than done. In part 2 of this blog I will discuss the barriers for the adoption of ABV in the analog world, the solutions available today from Cadence and where the industry is headed.

Srikanth V Raghavan

SKILL for the Skilled: What is SKILL++?

2011-01-04T18:00:00Z

The way SKILL++ deals with functions is a bit different than the way traditional SKILL deals with them. In this posting I'd like to show how to implement a design hierarchy traversal engine in SKILL++ and use it as an introduction to SKILL++.

What is SKILL++?

SKILL++ is a subset of the SKILL language, not a separate language as one might suppose. The term SKILL++ refers to a small but powerful set of extensions that were made to the core SKILL language in the mid 1990s and are now available for use in many Cadence tools. In fact, any Cadence tool that is extensible by loading and executing SKILL programs is a candidate for using SKILL++, including: Virtuoso, VirtuosoXL, pipo, Assura, Dracula, PVS, Allegro-PCB, cdnsip and probably a few more that I'm forgetting.

Basically the language features are:

Lexically scoped variables
Single function/variable name space (sometimes called Lisp-1)
An object system based on the Common Lisp Object System

By contrast, traditional SKILL offers dynamically scoped variables and separate names spaces (sometimes called Lisp-2) for functions and variables. Dynamic and lexical variables are both useful for different purposes.

What are dynamic and lexical variables?

These two kinds of variables differ semantically but not syntactically. All variables appearing in SKILL++ code are considered lexical while all variables appearing in traditional SKILL code are dynamic.

If you are wondering what the semantic difference is:

Dynamic variables allow SKILL expressions to control particular values during a dynamic extent; i.e., while a function and its children functions are pending evaluation. During this time of pending evaluation, dynamic variables are visible globally unless explicitly shadowed by another enclosed binding of the same name.
Lexical variables allow functions to isolate visibility of objects so that only a fixed set of expressions have access to the value by name, but extend that access indefinitely -- even after the dynamic extent of pending evaluation.

Perceptions of SKILL++

In this article, we'll ignore the SKILL++ object system and concentrate on the first two of these capabilities -- sometimes referred to jointly as the SKILL++ Scheme Dialect. Unfortunately, the other dialect which lives alongside Scheme has no official marketing name. For lack of a better name, we'll call it traditional SKILL. Hereafter, I'll just use the term SKILL++ rather than the SKILL++ Scheme Dialect.

If you haven't started using SKILL++ yet, the basics are simpler than you might think. If you are completely new to SKILL, you'll find SKILL++ easy and intuitive. If you're a long time SKILL programmer, you'll do things in SKILL++ pretty much the way you would have wanted to 25 years ago when you started learning SKILL. That is, you've already learned the hard way; now you can take a look at the easy way.

How to create SKILL++ code

There are several ways to indicate to the SKILL interpreter that you want to use SKILL++ rather than traditional SKILL. One way is to end your file names with the .ils extension for SKILL++ and .il for traditional SKILL; file.ils is SKILL++; file.il is traditional SKILL.

Please assume all the functions in the remainder of this article are SKILL++.

SKILL++ by example

The first example function, walkCvHier, is an ultra-simple design hierarchy traversal engine. It won't work for all purposes you might need but is good for the purpose of the examples below.

1.1: (defun walkCvHier (cv consume)
1.2:   (foreach inst cv~>instances
1.3:     (walkCvHier inst~>master consume))
1.4:   (consume cv))

This function is a type of higher-order function, because it takes a function as one of its arguments. It is also possible with SKILL++ for functions to compute and create other functions at run time according to their given arguments -- more about this in a future article. Although it is sometimes possible to use traditional SKILL to create higher-order functions with limited capability, my advice is that you always use SKILL++ if you need this abstraction.

How does it work? The function, walkCvHier, steps through the explicit cellView hierarchy such as a layout, assuming you always want to descend into the instance master. At each step of the hierarchy, a given function is applied. You can pass in any function as long as that function can take a cellView as its only argument. The function, walkCvHier, will happily call that function for you at each cellView found of the hierarchy, every time that cellView occurs.

Saving the hierarchy?

Here's an example of how to use walkCvHier. The function saveCvHier asks walkCvHier to call dbSave on each cellView in the hierarchy.

2.1: (defun saveCvHier (cv)
2.2:   (walkCvHier cv dbSave))

The function walkCvHier has a local variable consume, declared on line 1.1, which it uses on line 1.4 in the function call position (consume cv). Because this is SKILL++, consume does not refer to the global function of that name, but since there is a local variable of that name, that variable is used instead. The value of that variable better be a function, else an error will occur at run-time. On line 2.2, the saveCvHier function calls dbSave as this second argument. There are several important things to note here:

The reference to dbSave on line 2.2 is NOT QUOTED. Why? Because in SKILL++ names of global functions can be referenced exactly as variables.
The consume function is called on line 1.4 with normal function calling syntax. Why? Because in SKILL++ you are allowed to call global functions and local functions with the exact same syntax.
The name consume does not need to start with a capital letter or an underscore. It need only obey the naming rules for local variables.

Reporting the hierarchy

Suppose that rather than calling dbSave on the hierarchy, you'd like to do something for which there is no built-in function. For example, suppose you want to descend a design hierarchy and report which cellViews are found. You'll need to provide a function which will do the reporting for one cellView. One alternative is to define a function for this purpose, such as _reportCv.

3.1: (defun _reportCv (cv)
3.2:   (println (list cv~>libName
3.3:                  cv~>cellName
3.4:                  cv~>viewName)))
3.5:
3.6: (defun reportCvHier (cv)
3.7:   (walkCvHier cv _reportCv))

The intent here is that _reportCv be private and only be used in this one place. However, because it is defined with defun (the same would be true if it were defined with procedure) it is actually available globally. Its private status cannot be enforced. In the past, privacy has been implemented in traditional SKILL using naming conventions and documentation. SKILL++ provides better fixes this problem by providing ways systematic ways for hiding data.

...to be continued...

What's next?

In the next posting we'll look at local functions, closures (functions with state), and a few slightly more advanced examples using the walkCvHier function.

Jim Newton

On-Demand Webinar: Parasitic-Aware Design Part 3 -- Managing Parasitics in Back End

2010-12-28T14:00:00Z

If you were not able to attend this recent live webinar, or were able to and would like to share the content of this webinar with colleagues, you can find an on-demand recording by clicking and registering here:

Managing parasitics in the back end

In this third of a three part webinar series on parasitic aware design, Jeremiah Cessna and Sravasti Nair present an overview and demonstration of a back end analog IC design flow that allows you to effectively manage variability and uncertainty related to parasitics throughout the implementation phase of design. Jeremiah discusses a new approach to rapid analog prototyping which enables early, efficient and accurate generation of parasitic design data.

Please let us know what you think, and if would like to see more webinars like this.

Mike Kelly

On-Demand Webinar: Parasitic-Aware Design Part 2 -- Managing Parasitics in Front End

2010-12-21T14:00:00Z

Managing parasitics in front end

In this second of a three part webinar series on parasitic aware design, Nigel Bleasdale and Stacy Whiteman present an overview and demonstration of a front end analog IC design flow that allows you to effectively manage variability and uncertainty related to parasitics throughout the design and verification phases of design. Nigel discusses a new approach to early pre-layout exploration of parasitic effects as well as rapidly converging on post-layout verification with parasitics.

Please let us know what you think, and if would like to see more webinars like this.

Mike Kelly

On-Demand Webinar: Parasitic-Aware Design Part1 -- A Complete Analog Design Flow

2010-12-17T14:00:00Z

Parasitic Aware Design - A Complete Analog Design Flow

In this first of a three part webinar series on parasitic aware design, John Stabenow presents a high level overview of an end-to-end analog IC design flow that allows you to effectively manage variability and uncertainty related to parasitics throughout the design, verification and implementation phases of design.

Please let us know what you think, and if would like to see more webinars like this.

Mike Kelly

Making Friends With Parasitic Effects

2010-12-14T01:00:00Z

OK, so the title is perhaps a little optimistic but I'm playing off the saying "keep your friends close, but your enemies closer" (The Godfather Part II: Francis Ford Coppola and Mario Puza). The corollary in custom design is to bring the understanding of parasitic effects as early as possible in the design flow, so there is less chance of surprises later.

In custom design there are a few ways to bring your parasitic effects "closer." They are as follows:

1. The first is perhaps the most painful. It's where parasitic Rs and Cs are manually added directly on the schematic in the hope they are representative enough to cover the layout. So a duplicate of the design is created to protect the original.

2. Some companies have created scripts that will add a default parasitic capacitance to every net in the design to at least push the design closer to the final result. This can be done during the netlisting phase to avoid editing the schematic.

3. Other companies have gone a step further and added in a level of structure recognition, so the guesstimated parasitic elements are closer to what a layout would likely produce. The estimates are programmed in, based on prior experience.

4. Since designs are typically 80% reused, it makes sense to try and leverage the 80% of parasitic information you have from the previous designs. There are a number of ways designers will do this, and depends on how much information is wanted. Again some scripts are often developed to help.

5. Lastly is the prototype route, where the design is actually constructed very quickly to get access to extracted results. This depends on a high level of automation in the layout generation to make it worthwhile.

Below is a flow that I want to present that covers the last three points and is based on the Parasitic Aware Design (PAD) capabilities of Virtuoso ADE GXL. The six steps are:

1. Create the parasitic estimates

2. Explore their effects and make adjustments to the design

3. Complete the layout and extraction as before

4. Run the verification simulations

5. Analyze the pre/post layout impact on performance and recalibrate the estimates from the real extracted results

6. Reuse the parasitic estimates in subsequent designs as the parasitic estimates are saved as constraints and travel with the design.

PAD Flow

The key challenge to any pre-layout parasitic analysis is getting the estimates in the first place -- and the best estimates are going to be those derived from real data. As I mentioned, some customers have developed the ability to add parasitics based on some heuristics they developed over time and scaled by the rules of the target process. With PAD, these can be included into the flow using the SKILL interface. The advantage is you gain access to all the other capabilities of PAD in ADE XL and GXL for analysis with these effects.

The alternative is to create a prototype of the layout and collect the extracted results directly. With the constraint-driven flow from Virtuoso Schematic Editor XL to Virtuoso Layout Suite XL/GXL, a prototype can be created quickly. Use QRC to extract and you can run verification, then either stitch parasitic networks of interest directly to your pre-layout design or recalibrate any estimated parasitic.

With PAD, you have the most flexibility in incorporating the strategy that makes the most sense to you. With reuse built in, it is now more possible than ever to reduce or even eliminate the iterations back and forth between design and implementation.

What strategy do you use?

Nigel Bleasdale

SKILL for the Skilled: Rule of English Translation

2010-12-06T17:00:00Z

An obvious criticism of my previous post SKILL for the Skilled: Making Programs Clear and Concise is that clarity is subjective. What is clear to one person may be confusing to someone else, especially to someone who is accustomed to doing things the hard way.

I'd also suggest the converse is also true. If you are accustomed to using a programming language that encourages an imperative style, you may become convinced that more confusing code is clear.

Several readers of this blog referred me back to an iconic author in the field of computer science, Peter Norvig. The book Paradigms of Artificial Intelligence Programming is a good resource as a survey of many different non-trivial but easy to understand programming problems. The book is almost 1,000 pages and belongs on every SKILL programmer's bookshelf. The name of the book is generally agreed to be misleading as it turns out not to be much about artificial intelligence, but rather about programming style.

Norvig also presents a nice test for clarity in his presentation called a Tutorial on Good Lisp Programming Style. The rule can be found on pages 53 and 54 of that set of slides.

Rule of English Translation

Start with an English description of the algorithm.
Write the code from the description.
Translate the code back into English.
Compare 3 to 1.

From this description the implication seems to be that the smaller the difference detected when comparing 1 and 3, the better job you have done at writing a clear and concise program.

Let's use SKILL as an example rather than Common Lisp as Norvig does. Suppose we want to write a SKILL program to do some analysis of the instances in a layout cellView.

Start with an English description of the algorithm

Given a list of shapes and a layer name, find the subset of shapes on that layer.

First attempted implementation

The following implementation is an imperative approach. The reader sees how the calculation occurs but has to think a while to figure out exactly what is being calculated.

(defun shapes_on_layer (shapes layerName)
  (let (stack)
    (foreach shape shapes
      (when (shape~>layerName == layerName)
        (push shape stack)))
    stack))

Translate the code back into English

Given a list of shapes and a layer name, start by initializing an empty stack, iterate over the shapes. If the shape is on the given layer, push it onto a stack; when finished iterating return the elements on the stack.

More clear and concise implementation

This implementation reads very easily, and it is clear to the reader what is being calculated.

(defun shapes_on_layer (shapes layerName)
  (setof shape shapes
    (shape~>layerName == layerName)))

Translate the code back into English

Given a list of shapes and a layer name, return the set of shapes which are on the given layer.

We can see that when translated back to English, the second of the two implementations looks much more like the original problem statement.

Exceptions

Of course there are exceptions to every rule (except perhaps this one). Sometimes we must sacrifice clarity for efficiency--particularly if the programming language is not as high level as SKILL. If you find the programming language you are using tends to more often force you to write code in the style of the first two examples, rather than the second, you should conclude that the strength of your programming language is NOT its clarity and expressiveness.

Incidentally, I tested the two implementations above on my Linux laptop to see which one is actually faster. I tested both the imperative and functional style implementations on a cellView containing 32,768 shapes, 20,480 of which are on "Poly" layer. The more concise functional style implementation found the "Poly" subset about 7% faster than the imperative style implementation. In this case there was no run time performance penalty for clarity.

The SKILL programming language allows you to write very expressive code.

Video Demo -- Increase Simulation Accuracy and Efficiency With SpectreMDL

2010-11-24T16:00:00Z

MDL is an immensely powerful feature in our simulators that allows designers to run better simulations quicker. Below is a quick demo to get you started -- and be sure to try out the workshop in your hierarchy under <MMSIM_installation>/tools/spectre/examples/MDL_workshop.

If video fails to play click here.

Below are some solid SpectreMDL examples and tips from our Support knowledgebase that show what else it is capable of:

How to calculate unity gain bandwidth, phase and gain margin using SpectreMDL

SpectreMDL example to measure maximum gm vs. drain current for a MOS device

Optimize MDL performance using the Spectre "save=nooutput" option

Samir Jafferali

Video Demo -- Increase Simulation Accuracy and Efficiency With SpectreMDL

2010-11-24T00:10:00Z

Measurement Description Language (MDL) is an immensely powerful feature in our simulators that is frequently overlooked. MDL gives the designer advanced control of our simulators allowing them to run better simulations quicker. Below is a quick demo to get you started. Also, be sure to try out the workshop in your hierarchy under <MMSIM_installation>/tools/spectre/examples/MDL_workshop.

If video fails to play click here.

Here is some information that covers other examples and tips:

How to calculate unity gain bandwidth, phase and gain margin using SpectreMDL

SpectreMDL example to measure maximum gm vs. drain current for a MOS device

Optimize MDL performance using the Spectre "save=nooutput" option

Samir Jafferali

SKILL for the Skilled: Making Programs Clear and Concise

2010-11-08T14:00:00Z

The SKILL programming language augments Cadence core tool functionality for Virtuoso and Allegro customers. It is also an important development tool for internal Cadence services organizations as well as Cadence product development groups. We see the value, power, flexibility, and elegance of the language as an enabling tool for customizing and enhancing design environments. These capabilities are made possible by the tight integration of the SKILL programming language into the Cadence platform.

This post introduces an upcoming series of articles, SKILL for the Skilled, which will attempt to better enable users to exploit the power and elegance of this fun and interesting programming language.

WARNING: What you are about to read is HIGHLY OPINIONATED!

SKILL Functions: Short and Clear

SKILL programs are usually made up of functions. A function should be short, clear, and express intent. Some programming languages force the programmer to transform the software problem into what the language can express, rather than allowing the programmer to transform the language to fit the problem at hand. The unfortunate result is often that the SKILL program looks like a C program, and is twice to ten times as long as it needs to be. We'll look at this ability to transform the language in upcoming articles.

Example Program

To illustrate the idea that functions should be short and clear, here are two different implementations of the same conceptual function. The confusing one (#1) uses an imperative style. Avoid this style. The second one (#2) uses a functional style. Without sacrificing clarity, it expresses in two lines what the imperative style expresses in nine lines. It is clearer, probably easier to debug, most certainly more efficient computation-wise, and scales better to larger programs.

Implementation #1 -- needlessly confusing

procedure( abs_less_than_100(x)
  prog( (value)
    value = abs(x)
    if( value < 100
      then return(t)
      else return(nil)
    ) ; if
  ) ; prog
) ; procedure

Implementation #2 -- clear and simple

(procedure (abs_less_than_100 x)
  (abs x) < 100)

What were the programmers thinking?

What are the problems of Implementation #1? What was programmer #1's thought process? He was probably trying to think like a Von Neumann machine -- in terms of an arithmetic unit and moving values around between registers until the goal is achieved. Programmer #2 was probably trying to express a mathematical expression.

A more natural way to think

I claim that the mathematical evaluation model is an easier, more natural way for humans to think than trying awkwardly to think like a machine that's moving data between registers. Don't try to make the problem harder than it is.

Some mistakes to avoid

Aside from the two very different ways of thinking, there are several other issues I have with implementation #1.

It declares the useless variable: value. There is normally no need to declare a value which is used only once.
It unnecessarily uses prog/return. There is no need to use prog/return if you want to return the value that is already in the tail position.
It unnecessarily uses if/then/else. There is no need to test an expression for TRUE/FALSE, and thereafter produce the same TRUE/FALSE using if/then/else.
It fills up half the screen space with lines containing only close parentheses. There is no need to put parentheses on separate lines. Rather use an editor which enforces indentation.
Its only comments are redundant; and worse, they will probably be out of date as soon as someone edits the function and forgets to check all the comments.

SKILL is easy, flexible, powerful, and elegant

The SKILL language is on the one hand easy to learn and easy to use for simple use-once-and-discard scripting tasks. On the other hand the power and flexibility of the language is evident when experienced programmers develop well designed, high quality SKILL based software applications. The elegance of the SKILL language is often underestimated. A well written SKILL program is easy to understand, takes fewer lines of code to implement, and incurs shorter development times than with most other language alternatives, assuming the developers understand the tools they are using.

Until now, it has been somewhat difficult to find insightful articles written about SKILL and how to apply it to day to day problems. I hope this series of articles enables you to get more benefit and enjoyment out of the SKILL programming language.

Jim Newton

Things You Didn't Know About Virtuoso: ADE XL--Take This Job and...Run It!

2010-10-06T21:00:00Z

Sometimes these articles just write themselves...

Last week, 3 different people asked me questions about the ADE XL Run Options form. Sadly, the odds that 3 people in the same week would ask a question to which I actually knew the answer are vanishingly slim, so that meant I needed to do some research. And, in the course of that research, I discovered why there were so many questions about this topic. It is quite confusing and the documentation seems to make sense only after you thoroughly understand the subject.

Sounds like something that needs to be blogged -- if only so I have a place I can go to look up the answer the next time someone asks me that question.

So, here we go. We're talking about 2 forms here. The first, the Job Policy Setup form, is accessed by selecting Options->Job Setup from the ADE XL window. The second, where most of the confusion seems to come in, is the Run Options form, accessed by selecting Options->Run Options. Here they are for reference...

The upper part of the Job Policy Setup form concerns how you want to distribute your simulation runs in ADE XL. This will vary depending on what type of job distribution system your company uses (LSF, SGE, etc.). We'll take that up another time. For now, let's just assume you have some sort of system that lets you fire off simulations onto a farm of machines.

Now we need to define some terms:

A "run" in ADE XL = pressing the green Run button in the UI. Each "run" could be a single simulation or it could be 100 corner simulations...
A "job" in ADE XL = a remote job that is started for a run.

The way ADE XL works is that each run starts a number of jobs (actually the process is called "ICRP") on whatever machines you tell it to use (local, SGE, LSF, etc). It uses the "Max. Jobs" field on the Job Policy Setup form to determine the maximum number of those jobs to start.

Those processes stay alive for some "linger time" so that ADE XL can more efficiently start new simulations as needed. So it will start by sending out a simulation to each job, and then as each simulation completes, it will send that job a new simulation until all simulations in the run are completed.

Remember that. A "job" is assigned to a particular "run" and will likely receive a series of simulations to perform (assuming the "run" involves more than a single simulation).

Let's skip to the Run Options form now.

The default in the Run Options form is Serial - i.e. if you hit the green Run button twice, the second run will not use any jobs until the first run completes.

If you set this to Parallel, if you hit the green Run button twice, the runs will start in parallel. They will either share resources equally (which means if Max Jobs = 10, each run will use 5 jobs). Or you can specify - something like 3 jobs per run.

This applies to all run modes--corners, sweeps, Monte Carlo, optimization, etc.

So - for any given run, all jobs run in parallel. However multiple runs in ADE XL are serial by default and can be made parallel.

Now, what about the fields at the bottom of the Job Policy Setup form--For Multiple Runs (reassign immediately or wait until currently running points complete)?

Let's say your setup is:

Run in parallel
Share resources equally
Max jobs = 10.

You start a run and the simulations are going to take 10 minutes. All ten jobs start running the simulations.

Now you start another run after making some changes to the setup.

So -- the question is -- do you want to immediately kill five of the current jobs and re-assign them to the second run or do you want to wait until the first five currently running simulations finish before re-assigning the jobs to the second run.

(Don't worry, the simulations that were killed will be assigned to re-run on one of the (now) five jobs assigned to the first run)

It's an efficiency issue. Do you want to waste the progress already made by the jobs on a simulation or do you want to make sure the subsequent run(s) start right away?

I hope this is a bit enlightening. You may need to read the above a couple of times until it becomes clear (I know I did).

Stacy Whiteman

Now Playing: Custom IC Videos-to-Go

2010-09-27T13:00:00Z

I wanted to take a brief detour from my usual postings to point out a couple of new delivery mechanisms we're trying out for distributing video collateral -- making better use of some of those toobz on the interwebs.

First, we've made some of the videos in the CIC Video Library at http://support.cadence.com/ available for download. This way all the users at your site can access the videos at your convenience without having to be logged into Cadence Online Support.

Here's a list of what's available:

Release (valid from)	Video Topic	Software Area
IC 6.1.4	Constraint Driven Flow in Virtuoso (15 mins)	VSE-XL, VLS-XL, and VLS-GXL
IC 6.1.4	Using Context-Sensitive RMB Menus (9 mins)	Virtuoso Layout Suite XL
IC 6.1.0	The World View Assistant in VSE XL (1 min)	VSE XL
IC 6.1.0	User Interface Configurations in VSE XL (3 mins)	VSE XL
IC 6.1.4	The Stretch command in VSE L (5 mins)	VSE L
IC 6.1.0	The Search Toolbar and Assistant in VSE XL (3 mins)	VSE XL
IC 6.1.0	The Property Editor Assistant in VSE XL (2 mins)	VSE XL
IC 6.1.4	Direct Text Editing in VSE L (1 min)	VSE L
IC 6.1.4	Dynamic Net Highlighting and Probing in VSE L (1 min)	VSE L
IC 6.1.4	The Navigator Assistant in VSE XL (2 mins)	VSE XL
IC 6.1.4	Design Data Access in VSE L (4 mins)	VSE L
IC 6.1.3	Variable and Parameter Sweeps in ADE XL (1 min)	ADE XL
IC 6.1.4	Spec Comparisons in ADE XL (3 mins)	ADE XL
IC 6.1.4	Setting Specifications and Running Simulations in ADE XL (3 mins)	ADE XL
IC 6.1.4	Setting up Multiple Tests in ADE XL (3 mins)	ADE XL
IC 6.1.4	Results Panel Views in ADE XL (1 min)	ADE XL
IC 6.1.4	Incremental Resimulation in ADE XL (2 mins)	ADE XL
IC 6.1.4	Device Instance Parameterization in ADE XL (2 mins)	ADE XL
IC 6.1.4	Monte Carlo Analysis in ADE XL (3 mins)	ADE XL
IC 6.1.4	Creating Datasheets in ADE XL (1 min)	ADE XL
IC 6.1.4	Setting Up and Simulating Corners in ADE XL (4 mins)	ADE XL
IC 6.1.4	ViVA Calculator Integration in ADE XL (1 min)	ADE XL
IC 6.1.4	User Interface Configuration and Advanced Expression Support in ADE L (3 mins)	ADE L
IC 6.1.4	Dependent Expressions in ADE L (5 mins)	ADE L

As if that isn't enough to keep you busy, we've also posted some of the videos on YouTube. That's right, Cadence has its own YouTube Channel. Hit the Subscribe button, so the next time you're standing in line at the DMV and feel a sudden need to know how to set up specifications in ADE XL, just pull out that smart phone and take a look.

Stacy Whiteman

Things You Didn't Know About Virtuoso: ADE XL -- Where Did My Data Go?

2010-09-22T00:00:00Z

Last week I got to attend a "Social Media Summit" here at Cadence. Jeepers, a "summit." I feel so important. Anyway, being the kind of person I am, one of the things that stuck in my mind was that they told us not to "tweet aggressively." Got it. Should I ever decide to "tweet", I promise to do so in a completely non-threatening manner. Seriously though (since it's quite likely our summit leaders are reading this) there was loads of great content in the meeting. Thanks folks! Hopefully I can make good use of some of the tips.

On to today's ADE XL topic. This article is concerned more with nuts-and-bolts and less with flashy user interfaces than usual, but hey, we're engineers, right? We like to know how things are put together. So, let's talk about what kinds of data ADE XL stores, where it keeps it and how you can control it.

3 types of data

ADE XL divides the data it deals with into 3 categories.

Setup

This is the information you put into ADE XL.
In the past several posts, I've told you how to set up tests and create output expressions. These simulation setups are stored in the adexl view in a subdirectory called "test_states", similar in structure to the ADE states directories you're already familiar with.
I haven't written anything here about specifications. I think I'll leave that as an exercise for the reader. (Hint: In the Outputs Setup pane, next to one of your expressions, double-click in the column labeled "Spec".) Specifications, along with variables, parameters, sweeps and corners (each to be the subject of future articles) are collectively referred to as the Setup DB. This is stored in the adexl view you created when you selected Launch->ADE XL.

Waveforms and netlists

You know what this is -- the output generated by the simulator. PSF, SST2, PSF XL, etc.

Results

The ADE XL Results DB contains the values for all your output expressions -- essentially everything that gets evaluated after the simulation is finished. It's organized in a format to easily generate those big tables you see when you run sweeps and corners.

Environment Variables

The locations for storing the waveform files and the Results DB are controlled by 3 environment variables. (I'll use the syntax you'd need for setting these in your .cdsinit file.)

projectDir envSetVal("asimenv.startup" "projectDir" ‘string "<path>")

You may already be using this variable. This is the same way you set the location for the simulation output in ADE L. This defaults to $HOME/simulation.

saveResDir envSetVal("adexl.results" "saveResDir" ‘string "<path>")

If specified, this controls where the waveforms and netlist directories get saved.

saveDir envSetVal("adexl.results" "saveDir" ‘string "<path>")

If specified, this controls where the ADE XL Results DB gets saved. This defaults to a subdirectory called, appropriately enough, "results" in the adexl view.

That said, here's a handy little table illustrating where things get saved when any of these variables are set.

saveDir	saveResDir	Results DB	Waveforms/Netlists
not set	not set	adexl view	projectDir
not set	set	adexl view	saveResDir
set	not set	saveDir	saveDir
set	set	saveDir	saveResDir

(If you are working with an adexl view in read-only mode, and you don't set the saveDir variable, the Results DB will be saved to the projectDir).

Interactive Control

In ADE XL, the Options->Save... dialog has section at the bottom where you can specify where you want to save the Simulation Results (Waveforms) and the ADE XL Results Database.

Bonus Tip: Copying ADE XL Views

Use the Library Manager to copy adexl views (or cells or libraries which contain adexl views). Set the following in your .cdsinit file in order to make the copy work correctly:

envSetVal("ddserv.lib" "enableCopyInDFII" ‘boolean t)

envSetVal("cdsLibManager.copyGlobals" "mpsRadio" ‘toggle t)

Then, if you want to copy just the Setup DB, just do a regular copy in the Library Manager.

If you want to copy both the Setup DB and the Results DB, select Update Instances->Of New Copies Only when you do the copy.

If you want to copy all 3 types of data (Setup DB, Results DB and Waveforms), set the additional variable: envSetVal("adexl.cpupdtr" "copyResultsData" ‘boolean t) and copy as in the previous example.

That's all for now. Hopefully I haven't confused anyone too much. If I have, leave a comment and we'll try to sort it out...

Stacy Whiteman

Things You Didn't Know About Virtuoso: Outputs Setup in ADE XL

2010-08-25T20:00:00Z

Continuing on our exploration of ADE XL (see here and here for previous articles), today let's take a look at the Outputs area in the center of the screen.

Any output signals or expressions which appear in the ADE XL Test Editor (or the ADE L window if you created the setup in there) will show up automatically in the Outputs Setup tab. You can still work with them the same way you always have by bringing up the Test Editor (RMB on the test name in the Data View Assistant and select Open Test Editor...).

But I'm not here to tell you how to do things the same way you've always done them...

Let's start by taking a look at the row of icons at the top of the Outputs Setup tab. The first one on the left is a pulldown that allows you to add various types of outputs and measurements to each test. So if you want to add an expression, select the appropriate test and choose "Expression". A new blank line of type "expr" will show up at the bottom of the pane. Now, double-click in the field under the column "Expression/Signal/File." You'll be able to type into the field, and you'll also see 2 cryptically labelled buttons.

Just an aside here...whenever you see a button, icon or even a piece of text that you don't understand in Virtuoso, try hovering your mouse over it for a second. Hopefully, you will be rewarded with a pink box containing a tooltip telling you what that button does. We'd like these tooltips to be helpful and usually they are. But sometimes the tooltips are missing and sometimes they're downright silly. Let us know about those, so we can fix them...or at least share a good laugh...

Anyway, back to adding an expression. In case you didn't catch the hint, hover your mouse over the 2 buttons in the "Expression/Signal/File" field to see what they do. Now, use one of them (hint: "...") to open the calculator.

I'm not going to get into how to use the calculator in this article. I did an article on it late last year and I'll probably fill up one or two more later this year as well.

Let's fast forward to the part where you've got an expression in the calculator buffer that you want to get it back into ADE XL. Go back to the ADE XL window and click on the other mysterious icon in the "Expression/Signal/File" field (hint: "<") to pull the contents of the calculator buffer into the field.

Tip: There's another way to do this if you've already got the calculator open. To save yourself some window hopping, verify that the test name showing in the "Test" pulldown at the top of the calculator is the one you want to work with, then select Tools->Send to ADE XL Test from the calculator banner menu. This automatically creates a new expression for that test in the Outputs Setup tab and sends the contents of the calculator buffer to populate it.

Dependent Expressions

Earlier this year I wrote about the exciting news that dependent expressions are now supported in IC 6.1.4 for ADE L. Well, that goes for ADE XL as well. If you want to build an expression which is built from other expressions, all you have to do is use the name of the expression (which, of course, you can assign in the Name column of the Outputs Setup panel) and off you go.

This works for creating multiple expressions within the same test. To build expressions using results from multiple tests, you use what we refer to as...

Combinatorial Expressions

To create an output expression using results from multiple tests, just drag the desired expressions (one at a time) starting from any field in the line containing that expression in the Outputs Setup pane and drop them into the calculator buffer. When you drop in an expression, you'll see that it has morphed into a different syntax: calcVal("expression_name" "test_name"). You can use the calculator as usual to build the expression and then use either of the 2 methods described above to get it back into ADE XL.

Bonus Tip: You can create combinatorial expressions for variables in the same way, by dragging from the Outputs Setup pane into the desired Value field in the Global Variables or Design Variables sections of the Data View or Variables and Parameters Assistants (we'll talk more about variables in a future article).
In this way, you can set a design variable value, such as a voltage or current source based on results from another test.
Obviously, you'll need to avoid creating a cyclic dependency when you do this (a variable value which depends on results from a test which uses that variable). ADE XL will scold you if you try.

Quick ways to create more output expressions

Sometimes you might need to use the same (or similar) expressions in several tests. To do this, simply RMB over the expression you want to use in another test, select Copy to Test and choose the test(s) you want to copy it to. You can also use Ctrl-Select or Shift-Select to grab multiple expressions and copy them all to another test. Of course you can edit them as desired after you copy them.

Tip: Double-click on an expression in the Outputs Setup pane and click that "..." icon I mentioned above to push the expression into the calculator buffer if you want to edit it more easily.

Ctrl-C and Ctrl-V also work to copy just the contents of a particular field from one place to another.

Well, I thought I'd have time for a lot more in this article, but it'll have to wait until next time. As always, leave a comment if you find any tips of your own to share or if there are any topics you'd like to see discussed further.

Stacy

Analog Design vs. Automation -- Why Are They At Odds?

2010-08-17T23:00:00Z

Back in 2002 and 2003 there was a lot of talk about analog synthesis being the "next new thing" to close the productivity gap between analog and digital designers. Well, I hope you didn't hold your breath for this!

That promise failed mostly because analog design was still a custom design challenge, relying on innovation to provide differentiation in the final application. Standardizing analog design, or constraining the design to a fixed set of rules, never worked in reality, and innovation was squashed in the process.

Also, new designs are typically bigger, better and faster than previous generations, and a fully automated solution provides little more than derivatives of what already exists (assuming these derivatives work).

However, the challenge never went away, and over the past seven years there have been a number of different approaches to try and move analog design out of the critical path. These seem to focus mostly on offering premade IP or speeding up the core verification tools used, such as simulation, extraction and DRC/LVS.

For custom design to be truly effective and productive, these improvements are certainly needed, but a number of additional capabilities are necessary to facilitate the innovation of the designer. The answer lies in "Assisted Design," which I like to think of as analogous to adding power steering to your design flow. The designer is left in control, but the effort to move a design from point A to point B is reduced. Here, automation has a part to play and can be used to augment the flow, without replacing it.

There are a number of capabilities that fit into this space that support the "power assisted" flow, some of which you may already be using. I'll introduce them here and in future blogs I'll go into more detail. If there is a topic in this area you want covered, let me know.

Sweeps and Tuning

This is a commonly used tool that can simply vary the design, assess the impact on the design goals, and manually find the optimum solution.

Feasibility Analysis

Early in the design creation process, feasibility analysis can be used to quickly see if a design has potential before more extensive investment in simulation is made.

Sensitivity Analysis

For any design solution, it's possible to quickly explore the design's sensitivity to processing variability and environmental conditions and even the sizes of the devices used in the design.

Design Finishing

This involves pulling a design into compliance over all the required conditions, and can be quite time consuming where a large numbers of corners are concerned.

Yield Improvement

Understanding the manufacturing margin is becoming more critical as greater performance is being demanded from existing foundry processes. For some applications, high-yielding designs up to six sigma margins are required.

Parasitic Analysis

The performance of the final implementation can be quite different from the idealized view presented in a schematic. The earlier the layout effects can be assessed, the less iterations are needed between the electrical designer and layout designer.

Design Constraints (not to be confused with Design Rules)

As we know them, design rules are actually process rules and can also be sometimes called constraints. Here, I am referring to the implementation requirements that are specific to a design's configuration.

Self Documentation

Documentation is often left until the last minute, but is still required to sign off a design.

Automation in the custom design flow often leaves designers worried over loss of control or concerned over wasting a lot of time. Future blogs will explore how automation technology can be embraced in a practical flow that supports the designer's creative process and assists in meeting productivity goals.

--Nigel Bleasdale

Things You Didn't Know About Virtuoso: ADE XL Test Setup

2010-08-06T00:00:00Z

In my last post, I left you in suspense, with your mouse hovering over the words "Click to add test" in ADE XL. Clicking on this button will bring up the ADE XL Test Editor window (which should look suspiciously familiar) and a dialog asking you to point to the design you want to use. This design does not have to be the same cellview as the adexl view you're working with. It can be any design you want to simulate.

ADE XL Test Editor

Now take a look at the ADE XL Test Editor. DON'T PANIC. It's exactly the same as the good old friendly ADE L window. You set up your test in exactly the same way you do it in ADE L. If you have an existing state, load it here. If not, use the Setup, Analyses, Variables and Outputs menus to create your simulation setup.

The ADE XL Test Editor also includes all the features and enhancements discussed in my previous posts (here and here).

Tip: If you put the following in your .cdsinit file, the Test Editor window will also include the Run button, so you can test out your setup without stepping out of your comfort zone--

envSetVal("adexl.testEditor" "showAllMenus" 'boolean t)

Ok, let's step out of that comfort zone, shall we? Why do you want that extra window anyway? Close it and let's move along.

You don't need the Test Editor

Back in ADE XL, you'll see the test you just added in the Tests section of the Data View Assistant (upper left corner of the main window). By default, the test will be named something like myLib:myCell:1. The :1 suffix will increment if you add other tests with the same library and cell name.

Tip: I don't know about you, but I usually find the default test names to be annoyingly long, so I like to rename them to something more meaningful to me. To do this, we'll employ a technique I'll call "edit in place". First, click on the name of the test in the Data View Assistant. It will look like it's selected. Now click again and you'll be in edit mode. Note I didn't say "double-click" (That would open the Test Editor window and we're done with that...). Just click and then click again--there's a difference.

You can see lots of information about the test right in the Data View Assistant. By expanding the tree, you can see the simulator, the analyses and the design variables for each test. Hover over the test name and you'll get a gigantic tooltip which will show you the lib/cell/view for that test (among other things). Click the RMB (right mouse button) and you'll be able to directly access pretty much every element of the test setup (temperature, model libraries, options, etc.).

Information about the outputs from the test can be seen and modified in the Outputs Setup pane (the big area in the middle of the window). RMB in that area and you'll see all the entries relating to setting up outputs to be saved and plotted, adding expressions as well as access to the "Save All" and "Printing/Plotting Options" dialogs. We'll talk more about this area in detail in a later article.

There's no need to open the Test Editor window again. Really. Why do you need another window?

Dude, where's my schematic?

RMB on the test name in the Data View Assistant and select "Open Design in Tab" to do just that (open the design corresponding to that test in a new tab).

Tip: By default, the design will be opened in "read" mode. To open automatically in edit mode, put the following line in your .cdsinit file:

envSetVal("adexl.gui" "openDesignAccessMode" 'cyclic "w")

By the way, ADE XL is pretty smart about opening the schematic when you need it. Executing any command that needs you to point to something on the schematic will automatically open it (outputs to be plotted, initial conditions, etc.). Not only that, but it pays attention to which test your mouse was pointing to when the command was invoked and opens the correct schematic for that test.

Multi-Test Setup

Now that we've got one test set up, why not add more? Surely you do more than one simulation? This is where ADE XL really starts to shine.

Tip: If you want to use the same schematic with a different ADE state, RMB over the test name corresponding to that schematic and select Create Test Copy. You'll get a duplicate copy of the test for which you can load a new state or edit as desired.

A single ADE XL view can contain any number of tests for different schematics using different sub-blocks and different simulators. The checkboxes in the Data View Assistant can be used to enable/disable each test. Even if you think you're totally finished with one testbench, just disable it. Guess what, you'll probably end up needing to run it again eventually when you get that email letting you know that a new model file has just been released. It sure would be handy not to have to go digging through the Library Manager to find all the tests you ran on that block 3 weeks ago.

Tip: Using multiple tests in ADE XL also enables you to share variables (so they only need to be changed in one place), copy output expressions from one test to another (RMB->Copy to Test... in the Outputs Setup pane) and even (spoiler alert) create expressions which combine results from more than one test (more on that next time).

Stacy Whiteman

Things You Didn't Know About Virtuoso: ADE XL

2010-07-28T04:00:00Z

I know, it's been a long time since my last post. You see, we've finally arrived at a topic near and dear to my heart -- ADE XL. The reason for my hesitation in approaching this topic is not that it's difficult, but rather that there's so much to talk about that it's hard to know where to start. It's a bit like trying to write a guidebook for the Louvre. The place is enormous. Do you describe the building itself? The Antiquities? the Renaissance? That crazy looking glass pyramid?

I plan this to be a series of articles on all the great features of ADE XL. There's plenty to write about, but for those of you already familiar with the subject, please use the comments to give me feedback on any aspects of ADE XL you'd like to know more about and I'll be sure to include any "things you didn't know" that I can think of.

Well, I guess the guidebook won't make any sense unless you know what the Louvre is, so it's probably best to start with the basics. (BTW, I'm really not trying to compare ADE XL to the Louvre. That would be silly. Besides, you don't have to wait in line nearly as long to use ADE XL -- nor do you have to wear comfortable shoes.)

What's in it for me? Glad you asked...

During the design of a circuit block, you may have a half dozen testbenches, each with several different measurements. Then you need to run each of those over dozens or hundreds of corner conditions and parametric sweeps. And don't forget Monte Carlo, which is a common requirement for most designers today. Once you've run all those hundreds of simulations, you could be looking at an enormous, complex snarl of data.

Not only do you as a designer need to sort through and evaluate all that data, but you also need to present it to your manager in a coherent format he or she can easily understand (and, of course, be duly impressed by your superhuman circuit design skills). Then, heaven forbid, a device model or circuit spec changes and you have to do the whole thing over again. Are you confused yet?

I like to think of ADE XL as a means to reach the optimum place on the information/confusion curve. You know that place where you've got plenty of information to solve your problem, but not so much that you can no longer remember what the problem was.

First, a few basic definitions

ADE XL is centered around the concept of tests. A test is something that you are already using every day. It's nothing more than a circuit schematic that you're using to do some sort of simulation. A typical use for ADE XL is to group together all the simulations (or "tests") you need to do on a particular circuit block. Or you could use ADE XL to group a bunch of (possibly similar) simulations for different sub-blocks in your design. Or (and this is probably the most common usage of ADE XL today -- if only because it is the closest thing to The Way We've Always Done It) you can use it for just one test (simulation) that you want to run over corners and Monte Carlo. In any case, you know best how you want to organize your work.

ADE XL stores its information just as other Virtuoso applications -- in a particular type of cellview. An adexl view can be created under any cell and contain any number of tests which reference that cell and/or other cells. It can be seen in the Library Manager and can be managed like any other cellview.

Just as in ADE L, you can create and use design variables in ADE XL. These variables can be shared globally among all your tests, or they can be unique to an individual test. In addition to the types of variables you're used to using (i.e. using a variable name in the property value of a schematic instance), don't forget the new VAR() syntax which allows you to parameterize pretty much anything in the simulation environment such as model file name/section or transient stop time.

In addition to variables, as defined above, ADE XL allows you to create parameters, in which you can directly change the values of schematic instance properties without having to edit the schematic. This is done using the Variables and Parameters Assistant. I'll discuss this capability in detail in a later article, so just file this definition away for future reference.

Variables and parameters are what you use in ADE XL to run sweeps (sometimes referred to as point sweeps). Sweeps are most simply defined as lists (2,4,6) or min:step:max ranges (1u:1u:20u), but more complex sweep ranges can also be defined (center/span%, log steps etc.). These sweep ranges are also basic elements in running more advanced analyses like sensitivity and optimization (more on that in later articles).

I'm sure you're all familiar with running simulations over corners. However, it's interesting that every customer I visit seems to have a different definition of what constitutes a "corner" for their particular design flow. So in ADE XL, we've got a pretty broad definition of corners. Corners can include not only temperature, supply voltage and process model, but also any combination of design variables and parameters (as defined above).

The mechanisms for setting up and viewing simulation outputs and measurements in ADE XL is very similar to that of ADE L (with a few extra features we'll talk about later). Additionally, in ADE XL, you can apply a specification to any scalar output (an output expression that evaluates to a single number). This is a numerical target value, range or tolerance, to which the simulation results will be compared. Specifications are useful not only for quick visualization of design performance, but also used for optimization and yield analysis.

Enough with the glossary, how do I start the darn thing?

I suppose I probably should at least tell you that. Just open a schematic and select Launch->ADE XL. You'll feast your eyes on the "Welcome to ADE XL" home screen, which is intended to guide you through what you need to do next (hint: "To define Tests, click here").

Also note the assistant in the upper left, called "Data View". We'll be using this a lot.

I think I'll leave you in suspense for now, but you can watch some introductory videos on ADE XL here and here.

So watch this spot over the next few posts, and as always, feel free to comment on things you'd like to see discussed, or things you've found that others can benefit from.

Stacy

ARM And Cadence Get To The “Core” Of Mixed-Signal Design

2010-06-09T01:00:00Z

An increasing number of analog and mixed-signal designs in automotive, power management, wireless, medical, and industrial applications require digital control. But designing a state machine, and integrating the increasing amount of logic gates that implements it, has been challenging for analog designers. They often start implementing some digital functionality using a custom methodology, but soon the growing gate count becomes overwhelming and requires digital skills.

Analog designers then find they need a more complete digital flow for the digital block design. This flow must work smoothly in conjunction with an analog-centric flow for top-level design and full-chip integration. The increasing size of digital logic requires formal verification, test insertion, and automation for low power techniques. The amount of digital logic might increase to the point that a digital-centric methodology is more suitable for full-chip integration, with analog functionality designed separately and integrated as black boxes.

Integrating a core processor within analog and mixed-signal designs is an attractive alternative for digital control. The processor architecture offers a high level of flexibility through programmability and scalability, thus realizing more advanced designs and meeting more complex specs. The benefits outweigh an initial investment in architectural development and a design methodology shift.

Cortex-M0 Targets Mixed-Signal Applications

ARM recently released the Cortex-M0 processor core targeting mixed-signal applications. It has a 32-bit architecture, compact instruction set, very small silicon footprint (base configuration is just about 12K gates) and is power efficient. In a typical application it is accompanied by a memory block, memory bus interface, peripheral interfaces (GPIO, I²C, UART, SPI, USB) and standard analog/mixed-signal IP (PLL, ADC, DAC). As such it is suitable for integration within analog sensors, RF transceivers, power regulators, LED drivers, barcode scanners, motor controllers, or similar applications.

At the end of last month, ARM organized a Cortex-M0 workshop in Paris, France, and invited Cadence to present design solutions. Judging by number of attendees and their strong interest, the future of analog and mixed-signal design lies in its integration with processor cores. Almost thirty companies from the region came to learn how to design mixed-signal applications with the Cortex-M0 processor core.

The Cadence mixed-signal solution spans different design styles and supports diverse applications while leveraging common technologies. For example, verification of the mixed-signal designs with embedded Cortex-M0 core can be done from either the schematic driven Virtuoso-ADE environment or the command-driven Incisive environment. Both use the same high performance, tightly integrated simulation engines including those for SPICE, RF, behavioral, RTL and gate-level simulation. This ensures consistency of results while analog and digital designers work in their preferred use models.

Similarly, physical implementation and signoff for analog-centric designs is done in Virtuoso for the high level of control required in crafting analog circuits, with a seamless integration to the Encounter Digital Implementation System for digital block implementation. If a design requires a digital-centric environment, Encounter offers the full strength of digital design automation and low power design techniques, with the ability to integrate analog blocks previously done in Virtuoso as hard macros. Both analog and digital centric design environments leverage Virtuoso-Encounter interoperability based on industry standard OpenAccess (OA) for sharing design data and constraints. The implementation solution extends to IC/package co-design through Virtuoso and an interoperable flow with the Allegro package and board design environment.

Bringing Digital Capabilities to Analog Designers

Many analog/mixed-signal design teams are facing the need for digital design capabilities for the first time. They might be intimidated by complexity and price of digital design tools they need to apply for a relatively small logic gate count, as compared to mainstream digital. Cadence has conveniently packaged digital capabilities for Virtuoso users who need a digital solution for limited-size digital block implementation.

The Virtuoso Digital Implementation package contains logic synthesis, placement, clock tree synthesis, timing optimization, routing, extraction and static timing analysis. This is the same Encounter technology but is limited to 50K instances, sufficient for most mixed-signal designs with Cortex-M0. Moreover, two Virtuoso Digital Implementation licenses can be combined to double the capacity, and there's a smooth path to the full Encounter configuration if digital design needs increase.

In addition to flows, Cadence offers highly experienced mixed-signal methodology and design services, and a complete ecosystem from IP providers to foundries.

With Cortex-M0, ARM has offered a simple but powerful processor core for mixed-signal applications. The Cadence mixed-signal solution enables designers to smoothly realize designs in silicon, with high design productivity, schedule predictability and project profitability. Offerings from both companies lower the barrier for adoption of processor cores in analog and mixed-signal applications, and I believe many designers will take advantage of them.

Note: The ARM workshop in Paris was first in serious of similar workshops. The next one is planned for middle of July in Zurich. Please contact your local ARM or Cadence representative for this or possible future workshop in your region.

Mladen Nizic

Things You Didn't Know About Virtuoso: It's Video Time!

2010-04-01T13:00:00Z

Just a quick post to let you know that there have recently been a whole truckload of videos added to the Cadence Online Support Video Library. (Some shameless self-promotion here--I created many of them...). Simply go to http://support.cadence.com (registration required) and choose Resources->Video Library. You may want to set up your product preferences to only view those product areas you're interested in. And be sure to sign up for email notifications for your favorite products so you can get all the latest solutions and updates sent to you right away.

Many thanks to our Tech Pubs and CS folks for getting these posted for all to see.

There are videos on how to use many of the features in ADE XL (Analog Design Environment), VSE L and XL (Virtuoso Schematic Editor). Here is just a sampling. There are many more. Also check out Samir's excellent new video on how to get started using OCEAN.

VSE: Design Data Access

Bookmarks, tabs, recently-opened files list, Go toolbar, double-click hierarchy navigation, Library Manager customization, thumbnails

ADE XL: Setting Specifications & Running Simulations

Specification types, Run toolbar, viewing specs in Results panel, output formatting (digits, units, notation--IC 614), using the Evaluate button

ADE XL: Setting Up & Simulating Corners

Creating temp. & voltage corners, creating and using model groups, running corners & sweeps, working with simulation history results, viewing corners results, plotting waveforms from individual corners

ADE XL: Spec Comparison

Comparing 2 corners runs after a change in the circuit, comparing results from 2 swept parameter values across corners

ADE XL: Incremental Resimulation

Add a value to a parameter sweep without rerunning original values, rerun only failed corners

ADE XL: Monte Carlo Analysis

Monte Carlo options, specify DUT, Yield view, histograms, scatter plots, Detail view, print stat. params., create stat. corner

So grab some popcorn, put your feet up, relax and enjoy the show!

--Stacy

Video Demo: Your Maiden Voyage Across OCEAN

2010-03-29T20:30:00Z

I still remember my first encounter with OCEAN. It was 2002 and my co-worker had asked me to run a simple test for him. I sat in my cube, ruffling through our user guides, trying to quickly learn just enough to do the task at hand. The story ended happily, but I sure would have saved some time and frustration had I seen the following video. So for you OCEAN neophytes out there, here’s a nutshell video to get you out of the gates running. I cover the basics of OCEAN and OCEAN-XL and walk through some examples.

If video fails to play click here.

Some additional points:

1. You aren’t required to run a simulation in OCEAN. You can use it to only perform automated netlisting or carry out measurements on existing results.
2. The standalone ocean session equivalent of the .cdsinit is the .oceanrc, so be ready to copy your .cdsinit.

And here are two more excellent solutions that demonstrate some of OCEAN’s capabilities:

How to run parametric analysis over corners using Ocean?
How to print and plot gds after a DC Sweep?

Samir Jafferali

Exceed On Demand And Virtuoso IC6.1

2010-03-22T18:35:00Z

Many of our customers use our Virtuoso software in combination with the windows emulation product from OpenText named "Exceed on Demand". To maximize performance between the two tools, we have some recommendations:

For IC6.1.4 and Exceed on Demand 7, these setting will cause problems between the two programs. You should change the settings to the following:

Steve Lewis

Things You Didn't Know About Virtuoso: IC 6.1.4 ADE Enhancements

2010-03-10T14:00:00Z

I'm not going to beat around the bush here. I could tell you about all the things that are new in ADE (Analog Design Environment) in IC 6.1.4. I could tell you about the fact that the individual subwindows are now resizeable, rearrangeable (is that a word?), undockable and tabbable (I know that's not a word, but it's fun to say) just like the assistants in the main Virtuoso window. I could tell you that the Parametric Analysis UI has been redesigned. I could also remind you to read my earlier post about all the new features added to ADE in previous IC 6.1 releases.

But I won't. Why? Because there is one new feature in ADE in IC 6.1.4 that tops all the others in terms of fulfilling widespread long-awaited user requests. Dependent expressions. Being able to use the name of one expression in others expressions based on it instead of having to repeat the entire definition of the first expression. No longer do you have to go cross-eyed trying to parse enormous paragraph-long expressions. Break them up into smaller, more sensible expressions and build from there. It's logical, it's intuitive and it's here today in IC 6.1.4.

There is a great video available here in the Cadence Online Support Video Library showing you how this works. I have a favorite example I use in demos. The original expression (which was created in IC 6.1.3) looks like:

((1 - (average((VT("/OUTM") - VT("/INM"))) / ((value((VT("/OUTM") - VT("/INM")) 4.3e-09) + value((VT("/OUTM") - VT("/INM")) 1.23e-08) + value((VT("/OUTM") - VT("/INM")) 2.03e-08) + value((VT("/OUTM") - VT("/INM")) 2.83e-08) + value((VT("/OUTM") - VT("/INM")) 3.63e-08) + value((VT("/OUTM") - VT("/INM")) 4.43e-08)) / 6))) * 100)

Egads! That 33 sets of parentheses (hopefully in the right places), and 7 repetitions of the expression (VT("/OUTM") - VT("/INM")). Not to mention I'm also interested in the values of several of the subexpressions individually (so those will have to be repeated again on their own).

So now in IC 6.1.4 that above expression can be created as:

((1 - (GainDiffAvg / GainDiffErr6Avg)) * 100)

where:

GainDiffAvg = average(GainDiff)
GainDiff = (VT("/OUTM") - VT("/INM"))
GainDiffErr6Avg = ((GainDiff_4p3 + GainDiff_12p3 + GainDiff_20p3 + GainDiff_28p3 + GainDiff_36p3 + GainDiff_44p3) / 6)
GainDiff_4p3 = value(GainDiff 4.3e-09), etc.

Granted, it's still pretty involved, but by breaking up the expression into more manageable bits, it's a whole lot easier to see what's going on (and to make sure you've got it right).

Expressions can be added in any order and can be based on any number of other expressions. No cyclic dependencies, please.

Hopefully, this improvement will help make it a bit easier to create the measurements your really interested in.

Stacy Whiteman

Things You Didn't Know About Virtuoso: Thumbnails

2010-03-03T14:00:00Z

Boy, you must think we're a few sandwiches short of a picnic over here at Cadence.

A couple of months ago we came out with this great new Virtuoso software release (IC 6.1.4). So, despite my best efforts to get you to use the recently-opened files list or to create bookmarks, the first thing you did after starting virtuoso was open the Library Manager. (Don't try to deny it, I know you did...).

So there's the Library Manager with your libraries all neatly grouped and color-coordinated, and down in the lower right corner of the window, there's now a little black square. You say to yourself, "Wow, that's the one new feature I was hoping for in this new release...a little black square in the corner of the Library Manager. Thanks, Cadence!". (Actually, you probably thought something not so suitable for a family-friendly blog such as this.)

Well, before you run off and start tweeting all your friends about how Cadence has had another brain fart, read on a bit and let me tell you how to unlock the magic of that little black box.

Thumbnails, my friends. Thumbnails are the wave of the future. And thumbnails are what that little black box is for. But first you've got to create them and that's why the box is empty right now.

So, to create thumbnails for the cellviews in your library, just RMB over a library name or a cell name or a schematic, symbol or layout view name and select "Update Thumbnails" (or select Edit->Update Thumbnails from the main menu).

Now the little box will contain a small image of the cellview so you'll know it's the right one without having to open it. These thumbnails will also appear when you use the File->Open... form to browse for a cellview.

So, now that we've begun exploring the wondrous diminuitive world of thumbnails, leave a comment to let us know where else you think thumbnails might be useful in the future...

Stacy Whiteman

Analog Behavioral Modeling - What Language Do You Speak?

2010-03-02T14:00:00Z

An increasing number of mixed-signal design teams are contemplating adding analog behavioral modeling to their repertoire in order to achieve reasonable simulation speeds. Utilizing analog behavioral models can yield simulation performance improvements that can make full chip verification a reality. This approach can be several magnitudes faster than transistor-level; however, the actual performance improvement is greatly dependent on the level of detail in the model, as well as, the language of choice. Analog behavioral models are generally written in one of the languages below:

Verilog-AMS – A derivative of Verilog, it includes analog and mixed-signal extensions in order to define the behavior of analog and mixed-signal systems, providing both continuous-time and event-driven modeling

Wreal – An extension of the Verilog-AMS modeling language allowing analog block operation as a real data flow model

Verilog-A – An extension of Verilog to describe analog and non-electrical behavior as a continuous-time subset

VHDL-AMS (IEEE1076.1) – similar in concept to Verilog-AMS, providing analog and mixed-signal extensions in order to define the behavior of analog and mixed-signal systems

One of the biggest challenges in the creation of analog behavioral models is; whose job is it? The analog designer is the most familiar with the circuit performance and specific behaviors, however, many analog designers typically are not programmers and familiar with the languages mentioned above. The digital designer, who also tends to be the full chip verification engineer, is most familiar with programming languages, but lacks the analog specific circuit knowledge. Therefore, a blend of both skill sets is required or a conscience effort for both designers to work together. One must continually make the tradeoff of effort versus benefit when deciding to create an analog behavioral model. Some of the questions that come to mind are: Can I re-use it? How long will it take me to create a high quality model? What performance gains can I expect?

Finally, as you consider adding analog behavioral modeling to your design repertoire; consider your modeling goals and language. A performance model needs to capture specific circuit behavior and can affect your effort versus benefit equation, while a functional model requires you to only capture the 1^st order effects that are needed to verify the circuit functionality. Model On!

Greg Curtis