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.
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.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Jack Horgan, EDACafe.com Contributing Editor.