August 03, 2009
The Role of a Chief Technology Officer
Please note that contributed articles, blog entries, and comments posted on are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Jack Horgan - Contributing Editor

by Jack Horgan - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

One of the goals of these product families is to find problems as early as possible and hopefully by a designer rather than a verification engineer. The earlier these bugs are found, the earlier also the turn around of debugging and fixing of these errors. That being said, tools like PureTime and Meridian also have application in downstream abstraction levels, the gate level for example, after the timing constraints and timing specifications have been fixed. PureTime can also be used at the gate level. Ascent and Meridian can also be used with simulators at the full-chip level.

What is new with these three product families?
Ascent, the functional verification tool, is being augmented with comprehensive linting. Linting is a first line of defense in design verification. A lot of design companies have started enforcing design rules or design policies to make sure that all designers are on the same page in terms design styles and accepted idioms. STARC and VMM are examples of such policies. What we are doing is to understand these policies and to build in the checking of the design based on these policies into our tools. Such a tool makes it easy to enforce these polices across a large and distributed design team. That is one of our most important introductions at DAC. We have STARC, PVD and RMM policies. Also the linting tool will help in policies related to System Verilog migration.

EDITOR:The Semiconductor Technology Academic Research Center, STARC, is a research consortium co-founded by major Japanese semiconductor companies in December 1995. STARC's mission is to contribute the growth of the Japanese semiconductor industry by developing leading-edge SoC design technologies.

Carol Hallett:
Real Intent always had linting capability. We had it in the reporting section, kind of under the covers. Our customers asked us to bring that upfront so that they could actually use the lint tool. We did that in a version around a year and half ago. Since then, more people realized that we have lint capability and have come to us and said "Since you have lint, why not support these industry policies?" We always react as best we can to customer requests. We decided to develop these policies like STARC. We are not doing VMM just RFM because VMM has test benches and our product works before test benches are developed.

We went one step further. You can just run our default lint, if that is all that you need. It doesn't have much noise and you can easily fix the errors that pop up. Or you can select an industry policy that your company requires. And/or you can pick rules from different policies, add some of your own company policies and changes some of the parameters so that you have your own company lint check run automatically with Ascent.

Pranav Ashar: The second new feature of Ascent is SimPortal. The basic underlying techniques in our tools have been mostly formal thus far. What SimPortal dies is create a link or a hook into simulation for these same checks. This allows us to do a couple of things. In many cases, where formal capabilities are unable to handle the design complexity, it allows us to perform simulation. As a result, this enables a smoother tradeoff between complexity and the checks. Another thing SimPortal allows us to do is to create a seamless verification flow from the block level all the way to the chip level. Many times it happens that the designer will start checking the design at the block level, say a FIFO. By performing these checks, a designer would have to make some assumptions in terms of how this blocks fits into the rest of the environment, the scaffolding if you will and the constraints that the scaffold imposes on the block. Imposing these constraints is cumbersome and imprecise. While the check at the block level is extremely useful in that bugs are found, it still requires that the designer to ensure that the bugs that are found are correct by also performing the same checks at the chip level.

Formal analysis at the chip level is still a work in progress. As you know, what really works at the chip level is simulation. SimPortal enables us to extend the block level checking to the chip level and in some sense validates the checking that happened at the block level.

The third addition to Ascent is the so-called PBV, path-based verification. One of the areas has to do with checking the design in the context of Xs. This is interesting in the sense that there is disagreement in the industry about whether X's in simulation are good for design and verification or not and what they are supposed to mean. What we heard from customers is that it is important to check the generation of X's and propagation of X's in the design during simulation. We believe that a precise and formal methodology that is able to detect the generation and propagation of X's and to verify their soundness is required. This is a brand new capability that we are introducing. We believe that this will be extremely useful to the design community.

Editor: Explicit and implicit X sources (X assignments in RTL and non-resettable flops, respectively) in the designs can lead to many challenging issues for design verification, such as masking real design errors and causing RTL-to-netlist simulation mismatches. Depending on coding styles, simulation results can be X-pessimistic which lead to unnecessary unknown values; or X-optimistic which results in known values when they should have been unknown. Design and verification teams write properties to trap Xs or instrument 2-value simulation with random initialization to avoid X ambiguity in order to detect design errors. However, these approaches take considerable amount of manual and computational resources without offering the complete confidence of X robustness.

What is new with Meridian? Isn't SimPortal part of Meridian?
One of the additions to Meridian is SimPortal. It is similar to Ascent SimPortal in that it provides simulation hooks for the checks normally performed structurally or through formal methods. It allows us to do the checking at the chip level and with test benches in simulation in situations where the formal methods are not able to meet the requirement. Basically, the combination of SimPortal and formal methods and structural analysis provides a very complete and comprehensive approach to the checking of the functionality and clock domain crossing issues. With this combination we can cover all the bases.

The second addition to Meridian is hierarchical analysis. We want to be able to provide a methodology that goes from the block level all the way to the chip level. Many times, in the context of clock domain crossing checks, you might perform a check at the block level, say for a FIFO. Once you have done that, you don't have to check that again. What we are providing is a mechanism to create a shell model of the blocks that you have checked already and then to allow the abstracted versions of these blocks to be used at the chip level with the understanding that the internals of these shell models have already been checked. The nice thing about it, is that the clock setup and structural analysis that happened in the context of the block is still used at the chip level.

A third new aspect of Meridian that we are introducing is something called free running clocks. As we discussed, clock domain crossing checks are required because the clocks associated with communicating blocks are relatively asynchronous. The checking of these crossings is most precise when you build the relative asynchrony of these clocks into formal analysis. What the free running clock aspect of Meridian does is that it allows formal analysis to treat the different clocks completely asynchronously with respect to each other. It does not place any constraints between the relative times at which the clock edges from various source arrive.

What is new in PureTime?
A very important new feature in PureTime is the ability to check the constraints that are provided by the user before any formal analysis of the constraints on the design is performed. The reason for having a constraint validation front-end is that these constraints tend to come from multiple design groups. Many times these constraints can, in fact, conflict with one another. Also the constraints may be incorrect in the context of what is actually present in the design. What constraint validation does is to catch these errors in the specification of the constraints very early on so that the constraints that are actually given to static timing analysis or to the formal analysis in PureTime are, in fact, meaningful. In addition, the formal analysis of timing exceptions in PureTime has been enhanced quite a bit and can handle much larger designs than before.

« Previous Page 1 | 2 | 3 | 4  Next Page »

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Jack Horgan, Contributing Editor.

Review Article Be the first to review this article

 True Circuits: Ultra PLL

Featured Video
Latest Blog Posts
Anupam BakshiAgnisys Automation Review
by Anupam Bakshi
Automation of the UVM Register Abstraction Layer
Bob Smith, Executive DirectorBridging the Frontier
by Bob Smith, Executive Director
Virtual 2020 CEO Outlook Set for June 17
Colin WallsEmbedded Software
by Colin Walls
Multiple constructors in C++
Senior Layout Engineer for EDA Careers at EAST COAST, California
Software Engineer for EDA Careers at RTP, North Carolina
Senior Analog Design Engineers #5337 for EDA Careers at EAST COAST, California
Senior Application Engineer Formal Verification for EDA Careers at San Jose and Austin, California
Upcoming Events
Sensors Expo & Conference at McEnery Convention Center 150 W. San Carlos Street SAN JOSE CA - Jun 22 - 24, 2020
Nanotech 2020 Conference and Expo at National Harbor MD - Jun 29 - 1, 2020
IEEE Computer Society Annual Symposium on VLSI (ISVLSI) 2020 at Limassol Hotel, Amathus Area, Pareklisia Cyprus - Jul 6 - 8, 2020
57th Design Automation Conference 2020 at San Francisco CA - Jul 19 - 23, 2020

© 2020 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise