<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
See the discussion of "Races and Event Orders" in NC-Verilog vs. Verilog-XL,
near the end.
<p>Shalom
<br>
<p>http://www.cadence.com/newsletters/talk_verification1100.html>
<pre>--
**************************************************************************
</x-html>
<TITLE>Talk Verification</TITLE>
<!--last changed 11/08/00 by Benster-->
<LINK REL="stylesheet" HREF="/cadencestyle.css" TYPE="text/css">
<p></HEAD>
<!-- Begin
</SCRIPT>
<p><TABLE BORDER="0" WIDTH="558">
<h2>November 2000<br>
<!--Enter Sub-Nav elements in cell below -->
<TR>
<a name="top">INSIDE THIS ISSUE</a></P>
<ul>
<H3><a name="commentary">Commentary</a></H3>
<p><I>By Rahul Razdan, Corporate Vice President</I></p>
<p>Welcome to the third issue of Talk Verification. Talk Verification is a newsletter that is written to foster discussion and give solutions to problems in the areas of functional and implementation verification.</p>
<p>In this issue we are announcing a new feature for the IP Model Packager scheduled for the 4Q'00 release. This new C/C++ feature provides a new packaging capability. Specifically, it lets one use a standard methodology for integrating models into HDL simulation environments such as NC-SIM. The article describes the integration and the many benefits that result; for example, eliminating the months of effort that are now required to integrate a C/C++ model with a simulator.</p>
<p>The article on library verification shows how to ensure that the simulation library and the transistor library have the same functionality. The article presents a solution to this library verification problem using the Transistor Logic Abstracter (TLA). Specifically, TLA performs a functional analysis of the transistor-level cell and models its functionality in Verilog.</p>
<p>In June 2000, Cadence introduced its new HTML-based online documentation system. For those of you who use Cadence products, this is a significant improvement in accessing product information. The article on the new documentation system describes the system and shows how it is used and can be customized. I invite you to read and enjoy this issue of Talk Verification.</p>
<p align="center">Return to Table of Contents</p>
<h3><a name="functional_coverage">Functional Coverage -What is it and how can I use it? </a></h3>
<p><I>By Leonard Drucker, Verification Product Engineer</I></p>
<p>Functional errors cause 82% of the problems that verification engineers find in ASIC and system design.<sup style="font-size: 10px;">1</sup> Because of the magnitude of the problem, functional verification and a concept called functional coverage are important topics for verification engineers. The integrated suite of tools and technology that comprise the Cadence® Verification Cockpit (VC) were designed to help combat this problem. The suite consists of: Advanced Analysis Environment (AAE), which performs code coverage and lint checking; TestBuilder, which is a C++ based test authoring system; NC-Sim, the premier mixed language simulator; and Transaction Explorer (TE) technology, which performs transaction analysis and functional coverage exploration. In this article, I focus on functional coverage and the Transaction Explorer software technology of the VC.</p>
<h3>What is Functional Coverage?</h3>
<p>Zeev Kirshenbaum provided a good working definition for functional coverage in an Internet discussion group when he wrote:</p>
<p>"In general, the difference between code coverage and functional coverage is whether you take an internal/white box/micro view, or whether you take an external/black-or-gray-box/macro view of coverage. Code coverage is the first, it looks at your HDL code and tells you what you haven't exercised at the level of lines of code. Functional coverage looks at coverage from the system or user view. Have you covered all of your typical scenarios? Error cases? Corner cases? Protocols? Functional coverage also allows relationships?ok, I've covered every state in my state machine, but did I ever have an interrupt at the same time? When the input buffer was full, did I have all types of packets injected?"<sup style="font-size: 10px;">2</sup></p>
<p>Steve Cox supplemented his basic idea in the discussion when he wrote:</p>
<p>"Functional coverage tends to be viewed as accumulating statistics for things (or combination of things) that occur over time (e.g. transactions, state machine sequence, etc.), and then presenting summaries about those statistics..."</p>
<p>"If you combine these concepts with the thought that coverage measurement is merely a question (really, set of questions) posed of simulation results from a regression run, you find that <a href="#footer3">what you need is an effective way to ask specific, customized coverage
<p>You can ask coverage questions more effectively by defining those questions at different stages of your verification process. Therefore the tools used to define your coverage questions should give you the flexibility to define them:</p>
<ol>
<li><b>After simulation</b><br>
<li><b>Interactively from simulation results.</b><br>
<p>For large simulations, functional coverage is usually most convenient if it post-processes the simulation results. This technique has several benefits:</p>
<ol>
<h3>How Can I Use Functional Coverage in My Verification Flow?</h3>
<p>The functional coverage flow in a verification cycle is as follows:</p>
<ol>
<p>For example, you can apply this flow to a multi-port communications switch, as follows:</p>
<p>1.<i> Create coverage queries from the specification.</i></p>
<p>The architectural specification for the switch defines the following functionality:</p>
<ol type="A" start="1">
<p>You need to create a test plan from the architectural specification and then create coverage to prove that the simulations exercised functional requirements A, B, and C.</p>
<p>Did we verify that every input port can send packets to every output port?</p>
<p>You use C++4 or HDL (Verilog or VHDL) to create random tests to drive this design. You then define queries in the VC via TE technology to determine whether or not a simulation exercises all the permutations of input port to output port packet transmission. The query, using TE technology, that checks whether input port 0 sends packets to output port 2 is similar to the following:</p>
<p style="text-decoration: underline;">Query 1:</p>
<pre>
<p>This query looks for all of the transactions on interface (thread) input port 0 (line 3) that have a transaction type send_packet (line 4) and a value of property dest* (destination) in the range of output port 2 (line 5 & 6). The cnt variable in the Tcl query (line 8) counts the number of times that the simulation exercises the functional requirement. The verification engineer sets the goal (line 13) as a minimum required count. The design requires the testbench to verify that the output packet arrives and that its contents match the expected results.</p>
<p>Since you store transactions in the simulation database, along with links to related transactions, you can refine the above coverage question as follows:</p>
<p style="text-decoration: underline;">Query 2:</p>
<pre>
<p>This coverage query looks for transactions that occur on input port 0 that have a related transaction on output port 2. You need two transactions for the query to increment the count, the input transaction and the output transaction. This contrasts with Query 1 which only needs to find an input transaction to meet its criteria.</p>
<p>Since transactions can have a built-in relationship in the database, as defined by the test, you do not need to rely on explicit time values or check different property values, such as address and data, to correlate transactions.</p>
<p>2.<i> Apply the coverage queries to your simulation and determine your coverage metric.</i></p>
<p>Now that you have developed all of your coverage queries for the switch, you can apply them to the simulation results of all of your tests. You then extract from your design the coverage information. If the tests do not meet all of your coverage requirements for all of the coverage queries in the design, continue to step 3. If the tests meet the requirements, you should perform additional analysis to try to determine if the test plan, and therefore the coverage queries, are complete. If you find gaps in your coverage, continue to step 4.</p>
<p><b>Note:</b> the coverage queries only check that your tests exercise certain functionality. The tests themselves must prove that the simulations worked correctly, possibly with a self-checking test bench.</p>
<p>3.<i> If your tests do not meet your coverage requirements, adjust the tests.</i></p>
<p>The goal of Query 1 is to have 5 packets transmitted from input port 0 to output port 2. If the tests do not meet this goal, you can add additional tests to send packets as required.</p>
<p>4.<i> If you detected gaps in your coverage, fill in the gaps.</i></p>
<p>Once all of your tests pass and you meet the coverage goals for all queries, you can add more complicated tests and queries. In the communications switch example, you can add tests to explore the switch behavior when multiple ports are driven at the same time. The goal is to uncover unwarranted dependencies between different interfaces.</p>
<p>In our example, adding these tests cause errors to occur in several simulations. Upon investigation, we determine that the system is re-ordering packets. This is due to an arbitration scheme in the output ports that the designers added to the implementation. The design applies the arbitration scheme when an output port receives multiple packets in the same clock cycle. This behavior is not specified in any coverage queries. Therefore there is a gap in the coverage queries that we need to fill.</p>
<p>To answer this coverage question, you must define a query for each output port. The query for output port 3 is:</p>
<pre>
<p>The explanation of the above Tcl query is as follows:</p>
<p>Line 4: Look at all of the transactions that have occurred on any input port thread. Think of a thread as an interface into the DUV (Device Under Verification).</p>
<p>Line 5: Look at all of the transactions of type <i>send_packet</i>.</p>
<p>Line 6: If the destination address is in the range of output port 3, perform the following operations:</p>
<p>Line 8: Get the start time of the current transaction from the property <i>begin_time</i></P>
<p>Line 9: If the start time of this transaction is the same as the start time of the previous transaction, then:</p>
<p>Line 10-14: Keep the first transaction in the sequence, saved in line 18, for further processing; increment a counter (variable cnt) to indicate that the test met the query.</p>
<p>Line 15: Keep the current transaction, for further processing. The <i>accept</i> command stores the transaction in a list.</p>
<p>Line 17 and 18: Since this transaction has a different start time then the last transaction, reset the following parameters: Set the current transaction start time equal to the new start time; Store the transaction as the first in the sequence.</p>
<p>Line 24: Set the coverage goal to be greater then or equal to 1, indicating this criteria has been met at least once in the test.</p>
<p>Notice the ease of identifying particular features in this query, such as thread, trans_type, and begin_time.</p>
<p>Using TE technology of the VC, it is also easy to highlight the outputs that are associated with these input transactions. Since you can store transactions in the simulation database with links to other related transactions, it is easy to add highlights to appropriate outputs. You can retrieve the relationships between transactions with TE technology commands such as: <i>children</i>, <i>predecessor</i>, <i>related</i>, and <i>successor</i>. To enhance the previous query you can add the following command between line 11 and line 12:</p>
<p><i>accept [related $first_trans_in_seq]</i></p>
<p>This adds all of the transactions that are related to the first-transaction-in-the-sequence to the list of transactions that you can identify on the waveform viewer. The related transactions are the output transactions that are associated with the input packets.</p>
<p>Once you define this new coverage query, you must apply it to all our your simulations. Since TE technology operates on the simulation results database, you can apply the coverage to all of the results databases without re-simulating the design.</p>
<p>5.<i> Iterate through steps 2 - 4.</i></p>
<p>You can apply the new coverage to the existing simulation results to see if your tests meet their goals. If so, the verification is done; if not, keep iterating.</p>
<h3>Additional Uses of Functional Coverage</h3>
<p>Functional coverage questions can be useful beyond the initial verification cycle. Some possible uses are:</p>
<ol>
<li><b>Performing regression suite refinement</b><br>
<h3>Conclusions</h3>
<p>Functional coverage metrics are important in determining the functional requirements of the design that you have exercised. The tools used to define coverage queries that comprise the functional coverage metrics, must be very flexible. They need the capability to define and apply queries:</p>
<ol>
<p>The VC's Transaction Explorer technology provides the flexibility defined above, as shown in the "How Can I Use Functional Coverage in My Verification Cycle?" section of this article. Furthermore, the ability to process queries at a transaction level, coupled with a linkage to the simulation waveform tool, gives you the ability to use TE technology as a debugging tool.</p>
<p align="center">Return to Table of Contents</p>
<a name="ip_model"><h3>IP Model Packager Has a New C/C++ Packaging Feature</h3></a>
<p><I>By John Emmitt, Verification Marketing Manager</I></p>
<p>The next release of the Cadence IP Model Packager (Q4 2000) includes a new C/C++ packaging feature. This feature provides a standard methodology for integrating C/C++ models in HDL simulation environments, such as NC-Sim. Rather than spending time writing PLI code, a user can use the IP Model Packager to handle the bulk of the model integration task. The C/C++ packager can easily be used to integrate Instruction Set Simulator (ISS) models and other C reference models with a HDL simulator.</p>
<p>The C/C++ packager leverages the OMI model manager technology in the current HDL packager product. Open Model Interface (OMI) is the IEEE Standard (1499) Interface for Hardware Description Models of Electronic Components. OMI was developed as a high performance, language-neutral model interface to hardware and system simulation environments. The OMI specification defines two complementary software components. Each component provides a set of routines to the other, and each component calls the routines according to the OMI protocol. The simulator implements the application interface component, commonly called an OMI socket. The other component, called the OMI model manager, is delivered as part of a packaged design.</p>
<p>The model manager handles all of the communication and synchronization between a packaged design and the host simulator. In the case of a packaged HDL design, the model manager handles synchronization between the NC simulator engine, which is part of the delivered model, and the host simulator. For packaged C/C++ designs, the design must handle its own timing and scheduling functions. The model manager handles communication with the host simulator, including callback registration, error detection, and error and log file output.</p>
<p>The C/C++ model packager eliminates the many months of effort that users currently require to integrate a C/C++ model with a simulator. The C/C++ packager provides a generic model manager that supplies implementations for all of the required OMI model manager functions. The C/C++ packager also provides a new utility called amprep, which generates model integration template files, a Makefile, and a README file that shows model providers how to customize the model templates for their specific design. The amprep utility automates most of the (OMI) model interface tasks, so that the model provider can focus on the design-specific integration issues, such as synchronization and data conversion. The model provider uses the Makefile to build the model binary files that will be delivered as part of the packaged design.</p>
<p>Like the HDL packager, the C/C++ packager creates a tar file that contains the compiled model and all of the software and documentation that a model consumer needs to easily integrate the model into their simulation environment. The tar file includes an installation utility called aminstall, as well as the Verilog and VHDL shells for integration into an HDL simulator. The tar file also includes the OMI Adapter, which lets the model consumer integrate the packaged model into a simulator that has a PLI 1.0 interface, but not an OMI socket.</p>
<p>The new C/C++ packaging capability of the IP Model Packager provides a number of benefits. It minimizes the effort required to interface a C/C++ design to a host simulator and provides you with a proven model delivery flow, based on the existing HDL packager. The C/C++ feature uses the simulator-independent IEEE standard OMI interface for high performance and, the model consumer does not need a Cadence license to run the packaged model in their host simulation environment.</p>
<p align="center">Return to Table of Contents</p>
<a name="transistor_logic"><h3>Enabling Library Verification with Transistor Logic Abstracter</h3></a>
<p><i>By Axel Scherer, Senior Member of Technical Staff</i></p>
<h3>The Library Verification Problem</h3>
<p>Whether developing a new cell library (ASIC vendors or COT houses) or porting an existing library to a new technology, one faces the same problem: How does one ensure that the library developed for simulation and the transistor-level or physical libraries have the same functionality?</p>
<p>This problem is particularly difficult to solve because these three representations: simulation, transistor-level, and physical, are stored in different formats and at different levels of abstraction, respectively.</p>
<p>The Transistor Logic Abstracter (TLA) addresses this problem. TLA performs a functional analysis of the transistor-level cell and models the cell's functionality in Verilog, thereby overcoming the difference in format and level of abstraction.</p>
<h3>Simulation-Based Solution</h3>
<p>A HDL model that is derived from the transistor level enables an automated library verification solution.</p>
<p>One can apply an ATPG tool to the Verilog simulation library to generate a test for each cell. This test can be used for a comparative simulation between the Verilog simulation library and the model generated by TLA.</p>
<p>Schematic or transistor-level representation and a layout or physical representation can be verified using this approach. One can generate a SPICE or SPECTRE netlist with a schematic entry tool. This netlist can then be used as input into TLA.</p>
<p>Alternatively one can generate a transistor netlist with an extraction tool and input this netlist into TLA. This ensures that potential problems from the extraction process are caught.</p>
<p align="center"><img src="/newsletters/images/tla1.gif" border="0" width="267" height="239" alt="Simulation-Based Solution"></p>
<p>Customers that use this approach can incorporate a flow that lets them automatically verify the functionality of their library implementation in a very short amount of time when compared to SPICE-level simulation. This reduction in time is crucial because the number and complexity of cells within a library tend to grow significantly with lower feature sizes. Such an automated solution can verify over a thousand cells in about an hour.</p>
<h3>Equivalence Checking-Based Flow Solution</h3>
<p>Although the simulation-based approach works well and several of our customers are successfully using it, it can be improved upon by introducing an equivalence checker (such as the Cadence® Equivalence Checker Heck). This leads to a simplified solution.</p>
<p align="center"><img src="/newsletters/images/tla_heck.gif" border="0" width="267" height="181" alt="Equivalence Checking-Based Flow Solution"></p>
<p>Heck performs a functional comparison of two design representations in HDL format. This process eliminates the need for a testbench and the use of an ATPG tool to generate that test.</p>
<h3>Summary</h3>
<p>Introducing TLA to your library verification flow gives enormous productivity gains. It lets you build a fully-automated solution for functional verification of your cell library. Several of our customers use a simulation-based solution already. An equivalence checking-based solution will be available from Cadence early in 2001.</p>
<p align="center">Return to Table of Contents</p>
<a name="cds"><h3>The Cadence Documentation System</h3></a>
<p><i>By Barbara Heninger, Sr. Technical Pubs Consultant</i></p>
<p>In June 2000, Cadence introduced its new new HTML-based online documentation system. The new system consists of :</p>
<ul>
<p><b>Document Library Window</b> The new Cadence documentation window displays a list of the documents that are installed for a release. From this window, you can open books from different installed hierarchies, automatically starting your web browser if necessary.</p>
<p><b>HTML Documents</b> Each HTML-based document has both hyperlinked cross- references and a built-in toolbar. The toolbar lets you move through chapters, display the hypertexted Table of Contents, open the full- text search page, or open a PDF file for printing. You can also use the toolbar to send an e-mail directly to Cadence publications with comments about a document.</p>
<p>Because documents are viewed in a web browser, books can include links to other Cadence sites on the Internet, such as SourceLink or Cadence's corporate web page.</p>
<ul>
<p><b>Printing Documents</b> The new system provides print files in Portable Document Format (PDF) that you can open with Adobe Acrobat® Reader. You can print an entire document, or print a section of the document by specifying a range of page numbers.</p>
<p>A clickable list of contents is available for navigating each PDF document online. Hypertext cross-reference links from the HTML version are reformatted to include page numbers in the printed copy, so that readers who use the printed version can find the referenced page.</p>
<p><b>Customizing the System</b> You can display your own documents in the Cadence system. By adding four <META> tags to your documents, your manuals will appear in the documentation window. You can also add hypertext links between your documents and the Cadence manuals. The online user guide explains how to add your documents.</p>
<p><b>The Document Library Window and a Sample Document Loaded into Netscape</b></p>
<p align="center"><img src="/newsletters/images/doc_lib_window.gif" border="0" width="400" height="550" alt="Document Library Windows"></p>
<p align="center"><img src="/newsletters/images/sample_doc_netscape.gif" border="0" width="400" height="550" alt="Sample Document Loaded in Netscape"></p>
<p align="center">Return to Table of Contents</p>
<a name="ncverilog_verilogxl"><h3>Differences between the Cadence NC-Verilog and Verilog-XL Simulators</h3></a>
<ul>
<p>This article will look at the differences by classifying them according to the phase of simulation in which they occur; e.g., compilation, SDF backannotation, etc.</p>
<h3>Differences in Compilation</h3>
<p>Compiler directives are a powerful feature of the Verilog language that helps designers in a variety of ways. These ways include ensuring source consistency, compactness of design representation, etc. NC-Verilog supports a directive called <b>'undefineall</b> (in addition to those already specified in the IEEE 1364), which undefines all the macros defined via <b>'define</b> directives up till the occurrence of the <b>'undefineall</b> in the Verilog source. The following fragment of Verilog code shows how this feature of NC-Verilog can be used in conjunc-tion with a <b>'define</b> that identifies the underlying simulator (since Verilog-XL does not support this feature) -</p>
<pre>
<p>Judicious use of this directive can ensure that you do not inadvertently define a pre-preprocessor symbol or macro in the following Verilog source to enable un-intended model behavior.</p>
<p>Verilog-XL requires you to drive all output ports, referred to in specify blocks, by pre-defined gates. In the following module comparison, the Verilog-XL version of the model has a set of buffers that have been inserted between the RTL portion of the cell and the final output only to satisfy this restric-tion. Conversely, NC-Verilog does not have this restriction. As a result, the same model can be coded much more efficiently for simulation using NC-Verilog.</p>
<p align="center"><img src="/newsletters/images/compare_verilog.gif" border="0" width="469" height="281" alt="Comparison of NC-Verilog and Verilog-XL"></p>
<h3>Differences in Backannotation</h3>
<p>SDF backannotation in Verilog-XL simulator has the following restrictions:</p>
<ul>
<p>NC-Verilog does not have any of the above restrictions. Hence its backannotation is more robust and complete. In addition, the compiled SDF backannotation facility provided by it gives a big backannotation performance boost as compared to backannotation in Verilog-XL.</p>
<h3>Differences in Interactive Debugging</h3>
<h3>Differences in PLI Support</h3>
<p>Both Verilog-XL and NC-Verilog support the industry standard PLI 1.0 and the PLI 2.0 (also called VPI) interfaces that are specified in the IEEE 1364 specification. However, the following functions are not yet supported in NC-Verilog -</p>
<ul>
<h3>Differences in Simulation</h3>
<p>NC-Verilog supports the full complement of 12 delays (i.e. all transitions of 0, 1, x & z states) whereas Verilog-XL supports only 6 delays (i.e. all transitions of 0, 1 & X).</p>
<p>In a design that has annotated interconnect delays, displaying the effects of these is difficult when using Verilog-XL because the annotated interconnect delay gets lumped into the next gate driven by the input port. NC-Verilog simulates the interconnect delays by delaying the appearance of the value on the input port by the annotated delay) hence simplifying the visualization of the effect of these delays.</p>
<p>Verilog-XL cannot simulate recursive Verilog functions correctly because it has no function calling stack. NC-Verilog can handle recursive functions correctly.</p>
<p>The results from Verilog-XL and NC-Verilog may differ at the start of simulation because Verilog-XL does not treat the initializations per-formed at time step zero as events. Consequently the objects/events along the fanout of the objects initialized are not triggered/scheduled in Verilog-XL. NC-Verilog treats all initialized values as events and schedules an update for all objects along the fanouts of these objects. For example, simulation of the following Verilog description :</p>
<b><pre>
<p>would produce no output in Verilog-XL whereas NC-Verilog's output would show one line.</p>
<p>There are some differences in the way the simulators handle device delays. When propagating a glitch (two events a smaller time apart than the device delay) through a pre-defined gate, Verilog-XL cannot unschedule the previously scheduled event. The simulator simply changes the value of the scheduled event to the final value after the glitch. NC-Verilog unschedules the event and then re-schedules it using the correct delay. The approach of NC-Verilog obviously is more correct.</p>
<h3>Differences due to Races and Event Orders</h3>
<p>Sections 5.4 and 5.5 of the IEEE 1364 standard state clearly that a simulator may choose to pro-cess the active events in the queue in any order. Since NC-Verilog is structured differently than Verilog-XL, the order of active events processed would also most likely be different between them. If such event order differ-ences can cause simulation results (at primary outputs of the device under test) to differ, the design is said to contain races. Having races in your design is not good. This section will outline some techniques for identifying and fixing them.
<b><pre>
<p>In NC-Verilog, no distinction is made between an RTL statement or a gate level statement. Its delta cycle treats both uniformly. As a result, a single delta of simulation in NC-Verilog proceeds in a substantially simpler way as follows -</p>
<b><pre>
<p>As a result of these differences, a chain of events, which contain a mix of RTL and gate events, would lead to different event orders in Verilog-XL and NC-Verilog. Consider the following set of events (each arrow emanates from a causing event and points to the event caused) -</p>
<p>We refer to an RTL event as a non-XL event in the figure below.</p>
<p align="center"><img src="/newsletters/images/rtl_event.gif" border="0" width="330" height="59" alt="RTL and gate events"></p>
<p>In NC-Verilog simulation, the order of events will be A, followed by B or C in some order and followed by D and E in some order. This event order is intuitively implied by the causal relationships shown in the figure above.</p>
<p>However, in Verilog-XL simulation, the order of events is: A followed by C followed by E followed by B followed by D. The reason for this can be found in the description of the Verilog-XL's delta cycle above. All active XL events are exhausted before the active non-XL events are evaluated.</p>
<p>It is important to understand that both simulators are correct since the IEEE 1364 standard allows simulators to evaluate active events in any order. However, the difference in the delta cycles above would cause different event ordering in the two simulators for the same model.
<b><pre>
<p>An event on net a causes the two always blocks to be entered into the list of active events. Net a has a list of fanouts containing these two always blocks which are processed as follows -</p>
<b><pre>
<p>It is easy to see that the order of events in this case depends upon the order in which the two always blocks were inserted in the fanout list of net a. NC-Verilog and Verilog-XL might have different ordering of this fanout lists leading to different event ordering between them.</p>
<p>Even the way you write the model can cause potential for races. In general, you create a potential for races if the model changes state asynchronously. The following example shows one such case -</p>
<b><pre>
<p>Imagine the situation in which in one simulator {<b>a</b>, <b>b</b>} changes from 2'b00 to 2'b01 to 2'b11. In another simulator, {<b>a</b>, <b>b</b>} changes from 2'b00 to 2'b10 to 2'b11. Because of the way in which this block has been coded, in the first simulator, the variable state will have a value of 2'b11 and in the second simulator, it will have a value of 2'b00 at the end of these set of input changes. This model is said to have a race between signals <b>a</b> and <b>b</b>. The results of simulation are unpredictable here.</p>
<p>Most races are variations of the above i.e. the result of asynchronous state changes within the model. The simulation results from these models always depend upon the order of events processed in the simulator. Such models are unlikely to show same results across a variety of simulators. Obviously, in order to remove the race from this model, it could be modified to change states synchronously e.g. on the positive edge of a clock.</p>
<p>Running HAL (HDL Analyzer and Lint) software, a part of the Verification Cockpit Product, can help identify cases in the model where the state changes asynchronously. Thus, a design that goes through HAL without issuing such warnings is unlikely to contain races.</p>
<h3>Summary</h3>
<p>This article has documented the main differences between the NC-Verilog and Verilog-XL simulators. These differences were categorized with respect to compilation, backannotation, interactive debugging, PLI support, simulation, and races and event orders. Most of the differences occur as a natural consequence of the improvements built into NC-Verilog relative to the Verilog-XL simulator. Finally, as one can see, though differences exist, they are small, and the migration from Verilog-XL to NC-Verilog is quite staightforward for "clean" race-free designs.</p>
<h3>Footnotes</h3>
</TD>
</BODY>
</x-html>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:15 PDT
and
Shalom Bresticker Shalom_Bresticker-R50386@email.mot.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890
<A HREF="http://www.motorola-semi.co.il/"><a href="http://www.motorola-semi.co.il/">http://www.motorola-semi.co.il/>>
**************************************************************************</pre>
</html>
<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Final//EN">
<HTML>
<HEAD>
<BODY link="#003399" vlink="#003399" ALINK="#003399" topmargin="0" leftmargin="0" marginheight="0" marginwidth="0">
<!--put the header include here-->
<SCRIPT LANGUAGE="JavaScript">
function formHandler(){
var URL = document.mainmenu.site.options[document.mainmenu.site.selectedIndex].value;
window.location.href = URL;
}
// End -->
<TABLE BORDER="0" WIDTH="558" CELLSPACING="0" CELLPADDING="0" BGCOLOR="#FF0000">
<TR>
<TD>
<BR><IMG SRC="/images/slicing/dream.gif" ALT="Dream" WIDTH="246" HEIGHT="26" BORDER="0"></TD>
<TD ALIGN="right">
</TD>
</TR>
<TR>
<TD COLSPAN="2">
<A HREF="/company/" NAME="info" ><IMG SRC="/images/slicing/companyinfo.gif" ALT="info" WIDTH="86" HEIGHT="18" BORDER="0"></A><A HREF="/design_services/index.html" NAME="design services" ><IMG SRC="/images/slicing/design.gif" ALT="design info" WIDTH="95" HEIGHT="18" BORDER="0"></A><A HREF="/eda_solutions/index.html" NAME="eda" ><IMG SRC="/images/slicing/eda.gif" ALT="EDA solutions" WIDTH="88" HEIGHT="18" BORDER="0"></A><A HREF="/methodology_services/index.html" NAME="idesign methodology services" ><IMG SRC="/images/slicing/methodology.gif" ALT="methodology" WIDTH="162" HEIGHT="18" BORDER="0"></A><A HREF="/contact.html" NAME="contact" ><IMG SRC="/images/slicing/contact.gif" ALT="Contact us" WIDTH="76" HEIGHT="18" BORDER="0"></A></TD>
</TR>
<TR>
<TD COLSPAN="2">
<TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="558" BACKGROUND="/images/slicing/bgheader.gif">
<TR >
<FORM ACTION="" NAME="mainmenu">
<TH CLASS="pad" HEIGHT="30">
<SELECT NAME="site" SIZE="1" ONCHANGE="formHandler()">
<OPTION SELECTED>Select a Product Category
<OPTION VALUE="/eda_solutions/flv_fveimc_l3_index.html">Advanced Verification Cockpit
<OPTION VALUE="http://pcb.cadence.com/">Allegro
<OPTION VALUE="/eda_solutions/dic_synth_l3_index.html">Ambit BuildGates
<OPTION VALUE="/eda_solutions/cic_ams_rfsim_l3_index.html">Analog Artist
<OPTION VALUE="/datasheets/assura_drc.html">Assura Design Rule Checker
<OPTION VALUE="/datasheets/assura_lvs.html">Assura Layout vs. Schematic Verifier
<OPTION VALUE="/datasheets/assura_parasitic_extract.html">Assura Parasitic Extractor
<OPTION VALUE="/datasheets/assura_phys_verif_tools.html">Assura Physical Verification Tools
<OPTION VALUE="/eda_solutions/cic_ams_rfsim_l3_index.html">ATS
<OPTION VALUE="/eda_solutions/flv_ehs_l3_index.html">Cobalt
<OPTION VALUE="http://pcb.cadence.com/">Concept HDL
<OPTION VALUE="/eda_solutions/dic_pv_index.html">Diva
<OPTION VALUE="/eda_solutions/dic_pv_index.html">Dracula
<OPTION VALUE="/eda_solutions/flv_fveimc_l3_index.html">FormalCheck
<OPTION VALUE="/eda_solutions/flv_svgctn_l3_index.html">HECK
<OPTION VALUE="/eda_solutions/hcv_l3_index.html">HW/SW Verifier
<OPTION VALUE="/eda_solutions/flv_ehs_l3_index.html">Mercury
<OPTION VALUE="/eda_solutions/flv_ver_vhdl_sim_l3_index.html">NC-Sim
<OPTION VALUE="/eda_solutions/flv_ver_vhdl_sim_l3_index.html">NC-Verilog
<OPTION VALUE="/eda_solutions/flv_ver_vhdl_sim_l3_index.html">NC-VHDL
<OPTION VALUE="http://pcb.cadence.com/">Orcad Capture
<OPTION VALUE="http://pcb.cadence.com/">Orcad Layout
<OPTION VALUE="http://pcb.cadence.com/">Orcad-family PCB Solutions
<OPTION VALUE="http://pcb.cadence.com">PCB Solutions
<OPTION VALUE="/eda_solutions/dic_spr_l3_index.html">PKS
<OPTION VALUE="/eda_solutions/flv_ehs_l3_index.html">Powersuite
<OPTION VALUE="http://pcb.cadence.com/">PSpice
<OPTION VALUE="/eda_solutions/flv_ehs_l3_index.html">Radium
<OPTION VALUE="/eda_solutions/dic_spr_l3_index.html">SE-PKS
<OPTION VALUE="/eda_solutions/flv_ehs_l3_index.html">SimServer
<OPTION VALUE="http://pcb.cadence.com/">SPECCTRA
<OPTION VALUE="http://pcb.cadence.com/">SPECCTRAQuest
<OPTION VALUE="/eda_solutions/cic_ams_rfsim_l3_index.html">Spectre
<OPTION VALUE="/eda_solutions/cic_ams_rfsim_l3_index.html">Spectre RF
<OPTION VALUE="/eda_solutions/flv_ehs_l3_index.html">Speedsim
<OPTION VALUE="/eda_solutions/sld_spdv_l3_index.html">SPW
<OPTION VALUE="/eda_solutions/flv_svgctn_l3_index.html">TLA
<OPTION VALUE="/eda_solutions/dic_pv_index.html">Vampire
<OPTION VALUE="/eda_solutions/hcd_l3_index.html">VCC
<OPTION VALUE="/eda_solutions/flv_ver_vhdl_sim_l3_index.html">Verifault-XL
<OPTION VALUE="/eda_solutions/flv_fveimc_l3_index.html">Verification Cockpit
<OPTION VALUE="/eda_solutions/flv_ver_vhdl_sim_l3_index.html">Verilog-XL
<OPTION VALUE="/datasheets/compactor.html">Virtuoso Compactor
<OPTION VALUE="/datasheets/virtuoso_cd.html">Virtuoso Custom Designer
<OPTION VALUE="/datasheets/virtuoso_layout_editor.html">Virtuoso Layout Editor
<OPTION VALUE="/datasheets/virtuoso_xl_layout_ed.html">Virtuoso XL Layout Edior
<OPTION VALUE="/datasheets/vcr.html">Virtuoso Custom Router
</SELECT>
</TH>
<TH WIDTH="35" CLASS="pad" ALIGN="left">
</TH>
</FORM>
<FORM ACTION="/search.asp" method="GET">
<TH ALIGN="right" WIDTH="80" HEIGHT="24">
<IMG SRC="/images/slicing/search.gif" ALT="search" WIDTH="43" HEIGHT="16" BORDER="0"></TH>
<TH>
<INPUT TYPE="text" NAME="qu" VALUE="" SIZE="20" MAXLENGTH="30"></TH>
<TH WIDTH="39" CLASS="rightpad">
<input type="hidden" name="ct" value="cadence">
<input type="image" src="/images/slicing/go.gif" BORDER="0" name="Search" value="search">
</TH></FORM></TR>
</TABLE>
</TD>
</TR>
<TR>
<TD COLSPAN="2"><IMG SRC="/images/slicing/bottomshadow.gif" ALT="" WIDTH="558" HEIGHT="13" BORDER="0"></TD>
</TR>
</TABLE>
<TR>
<!--Enter Title and Headline in cell below -->
<TD WIDTH="423" VALIGN="top">
<H1>Talk Verification</H1>
Volume 5, Issue 3</h2></TD>
<TD width ="130" valign="top" align="right">
</TD>
</TR>
<!--Enter CONTENT in cell below -->
<TD colspan="2" WIDTH="558" valign="top">
<li>Commentary</li>
<li>Functional Coverage - What is it and how can I use it?</li>
<li>IP Model Packager Has a New C/C++ Packaging Feature</li>
<li>Enabling Library Verification with Transitor Logic Abstracter</li>
<li>Cadence Documentation System</li>
<li>Differences Between NC-Verilog and Verilog-XL</li>
</ul>
<p>In this issue of Talk Verification, our focus is mainly on technical topics. These topics include an in-depth examination of implementing functional coverage and the differences between the Cadence® NC-Verilog and Cadence® Verilog-XL simulators. A third technical article focuses on enabling library verification with the Cadence® Transistor Logic Abstracter. Rounding out this issue are two update articles. One describes new enhancements to the Cadence documentation system and the other describes a new feature in the next release of the Cadence® IP Model Packager.</p>
<p>We have previously used the term functional verification convergence to describe a successful test plan that executes standard tests, tests for corner cases, code coverage, functional coverage, and quality requirements. One of the key tests listed above is functional coverage; that is tests that measure coverage from the system or user point of view. Our first article goes into detail on how one can use functional coverage in the verification cycle. The article illustrates how to develop queries in detail. The article also examines additional uses of functional coverage beyond the initial verification cycle.</p>
<p>The other detailed article covers a topic that has generated a lot of interest, the differences between the NC-Verilog and Verilog-XL simulators. The differences result from either one of the two simulators not supporting a particular feature, or different behavior of a feature, or races in Verilog simulation. The bottom line, as the article shows, is that the NC-Verilog simulator has solved a lot of the limitations that had existed in the Verilog-XL simulator and, in addition, is compliant with the IEEE 1364 specification.</p>
questions of the simulation results database."</a><sup style="font-size: 10px;">3</sup></p>
<h3>What is an effective way to ask coverage questions of a simulation database?</h3>
<li><b>Prior to simulation</b><br>
You create questions from the architectural and/or implementation specification of your design.</li><br><br>
You create questions when you debug failed simulations. For example, if you are concerned about correct behavior when the design is stressed under particular circumstances, you can create a coverage query to verify that this experiment was simulated in your test suite.</li><br><br>
You create questions to explore unexpected behavior in a design. For example, the system may move into an abstract state (such as starvation or underflow), or the original design specification may be incomplete or elusive.
In these cases, you may need to closely examine the behavior of various blocks in the simulation before creating coverage queries.</li><br><br>
</ol>
<li>You can ask additional coverage questions without re-simulating the design, which saves time.</li>
<li>When creating new coverage questions, you can explore the simulation results to better understand the exact requirements of the new queries.</li>
<li>You can create questions in parallel with simulation. You can therefore start a simulation before your coverage questions are complete.</li>
</ol>
<li><i>Create coverage queries from a specification. You can do this before, during or after a simulation.</i></li>
<li><i>Apply the coverage queries to the simulation database and determine the coverage metric.</i></li>
<li><i>If your tests do not meet your coverage goals, adjust your tests.</i></li>
<li><i>If you detected gaps in your coverage, create additional queries to fill the gaps.</i></li>
<li><i>Iterate through steps 2 - 4 until you meet your coverage goals.</i></li>
</ol>
<li>Every input port must be able to send packets to every output port.</li>
<li>Every input port must be able to transmit packets of different lengths, as defined by the ethernet specification.</li>
<li>The switch must create a Cyclic Redundancy Check (CRC) for every incoming packet, and each CRC that the switch creates must match the CRC that its incoming packet defined.</li>
</ol>
<p>For example, you can implement a query for requirement A using the Transaction Explorer technology of the VC. The coverage question for requirement A is:</p>
1. init {set cnt 0}
2. apply {
3. thread "input_port0" {
4. trans_type "send_packet" {
5. if {([property "dest*"] >= "0x200000000000")&&
6. ([property "dest*"] <= "0x2FFFFFFFFFFF")}{
7. accept
8. incr cnt
9. }
10. }
11. }
12. }
13. exit { goal [expr $cnt >5] $cnt 5}
</pre>
1. init{set cnt 0}
2. apply {
3. thread ";input_port0"; {
4. trans_type "send_packet" {
5. # "related" = list of related transactions in db
6. foreach tx [related] {
7. if {[property "thread " $tx] == "output_port2"}{
8. accept
9. incr cnt
10. break
11. }
12. }
13. }
14. }
15. }
16. exit {goal [expr $cnt > 5] $cnt 5}
</pre>
<p><b>Note:</b><i>sometimes the verification engineer misreads the specification and it is the coverage goals, rather then the tests, that he/she need to adjust.</i></p>
<p>The appropriate coverage question to test this functionality is:
Are there multiple input ports that drive a packet to the same output port in the same clock cycle?</p>
1. init {set cur_trans_time 0;set cnt 0
2. set first_trans_in_seq 0}
3. apply {
4. thread "input_port*" {
5. trans_type "send_packet" {
6. if {([property "dest*"] >= "0x300000000000") &&
7. ([property "dest*"] <= "0x3FFFFFFFFFF")} {
8. set new_trans_time [property "begin_time"]
9. if {$new_trans_time == $cur_trans_time} {
10. if {$first_trans_in_seq != 0} {
11. accept $first_trans_in_seq
12. set first_trans_in_seq 0
13. incr cnt
14. }
15. accept
16. } else {
17. set cur_trans_time $new_trans_time
18. set first_transaction_in_seq [transaction]
19. }
20. }
21. }
22. }
23. }
24. exit { goal [expr $cnt >= 1] $cnt 1}
</pre>
<p>Not only can you use this query to gather coverage statistics, but you can also use it to debug. TE technology links the transactions that you store with the <i>accept</i> command (lines 11 & 15) back to the waveforms. As a result, you can highlight the transactions that the query identifies in the waveform display. This capability makes it easy for you to use the query results to find the area of simulation that needs detailed study.</p>
<li><b>Debugging a problem with first pass silicon.</b><br>
If first pass silicon exhibits a problem, you can use TE technology to explore simulation results to find out if any of the simulations contain the same conditions as the problem. Once you know that a simulation contains the same conditions, you can use the transaction debug capabilities to debug the problem.</li><br><br>
You may think of additional coverage questions after you complete all of your simulations. It may be quicker to explore simulation results using TE technology to see if you already covered any additional questions then to re-run all of the simulations with the new queries.</li><br><br>
</ol>
<li>Prior to simulation.</li>
<li>After simulation (applied to the simulation results).</li>
<li>Interactively created when the verification engineer does not know how to best implement the model, or even what is required in a query.</li>
</ol>
<p>The Cadence IP Model Packager is included, at no extra charge, with each of the Cadence NC simulator products (NC-Verilog, NC-VHDL and NC-Sim). Both HDL and C/C++ packaging are included in the end of year release of the Cadence IP Model Packager.</p>
<p>This simplification leads to a more direct verification flow and a higher performance solution. This solution with Heck is currently under development and will be ready in the first quarter of next year.</p>
<li>A library window that lets you find and open any of the books that are shipped with the products you ordered.</li>
<li>Web-ready manuals in HTML format.</li>
<li>A print-ready Portable Document Format (PDF) file for each manual.</li>
</ul>
<p><b>Searching Documents</b> The built-in Verity web search server lets you search all of your installed manuals, books about specific products or product families, or one or more specific books. The Search tool lets you:</p>
<li>Find text phrases or exact words.</li>
<li>Use Boolean AND, OR, or NOT operators.</li>
<li>Use wildcard characters (* or ?) for substitution.</li>
<li>Use special Verity operators such as CASE (for case-sensitive searches) or NEAR (to search for words that are near each other).</li>
</ul>
<p><i>by Nitin Chowdhary, Technical Marketing Manager</i></p>
<p>This article elaborates on the differences between the NC-Verilog and Verilog-XL simulators. Most of these differences can be attributed to features inserted into NC-Verilog to help it rapidly replace Verilog-XL in the marketplace. The principle differences between NC-Verilog and Verilog-XL include:</p>
<li>NC-Verilog is an average 8X faster for RTL simulations and about 6X faster at gate level</li>
<li>NC-Verilog has several utilities such as:
<ul>
<li>ncverilog: Essentially a drop in replacement for Verilog-XL. It maintains the standard Verilog-XL invocation mechanism and invokes NC-Verilog underneath</li>
<li>ncprep: A utility that helps migrate Verilog-XL environments quickly to an equivalent NC-Verilog three step process; i.e., compile, elaborate, and simulate.</li>
</ul>
</li>
<li>NC-Verilog is compliant with the IEEE 1364 specification
<ul>
<li>It is important to note that Verilog as a language has evolved significantly since the days when the Verilog-XL simulator itself was the accepted language reference. Now, through the efforts of the EDA community, there is a formal IEEE specification (1364) that defines the Verilog language and provides guidelines for simulator behavior. While the IEEE 1364 group borrowed heavily from the Verilog-XL's definition of the Verilog language, it also made certain clarifications and enhancements.</li>
</ul>
</li>
<li>The architecture of NC-Verilog is substantially better than that of Verilog-XL's and corrects many quirks of the older tool.
<ul>
<li>For instance, Verilog-XL has essentially two simulation engines inside, one is the behavioral engine and the other is the gate level engine (also called XL). NC-Verilog on the other hand has a single engine for the simulation of both behavioral and gate level Verilog descriptions. Use of a single engine substantially increases simulation performance and makes the event processing more intuitive.</li>
</ul>
</li>
</ul>
'ifdef INCA
'undefineall
'endif
</pre>
<li>The references to bits of vectors in the SDF file must match those within the corresponding specify block exactly.</li>
<li>You cannot specify part selects of a vector in the SDF file.</li>
<li>If a specify block contains a reference to an entire vector port and the SDF file contains refer-ences to the bits of the same vector port, you must use the commandline option +expand_specify_vectors.</li>
<li>The simulator treats a <b>$setuphold</b> check as two check. Thus separate checks by default i.e. a <b>$setup</b> check and a <b>$hold</b>, a <b>SETUPHOLD</b> SDF construct will not match a <b>$setuphold</b> in the Verilog source. In such a case, you must specify separate <b>SETUP</b> and <b>HOLD</b> constructs in the SDF file.</li>
</ul>
<p>In Verilog-XL simulation, the interactive mode commands are a subset of the Verilog language. The NC-Verilog interactive mode on the other hand supports the industry standard TCL command language with a host of intuitive commands that enable debug and stimulus creation.</p>
<li>tf_nextlongtime()</li>
<li>acc_fetch_paramval_mtm()</li>
<li>acc_handle_interactive_scope()</li>
<li>acc_next_topudp()</li>
<li>acc_set_interactive_scope()</li>
<li>acc_stability()</li>
</ul>
module top;
wire a;
always @a
$display($time,,,,"executed a = %b " ,a );
endmodule
</pre></b>
One reason for these differences in event ordering between the two simulators is the difference in the core simulation cycles of each simulator. As discussed earlier, Verilog-XL has two simulation engines. One called <b><i>wavefronts</i></b>, executes all the behavioural/RTL statements within the model. The other, called <b><i>XL</i></b>, processes all the gate level statements in the model. A single delta of simulation in Verilog-XL would proceed as follows:</p>
while (events exist at this time in wavefront or XL) loop)
for each event in wavefront list loop
Process event: If this event's fanout events
are behavioural, put them at the end of the
wavefront list else if they are gate elements,
put them at the end of the XL list.
end loop
for each event in XL list loop
Process event: If this event's fanout events
are behavioural, put them at the end of the
wavefront list else if they are gate elements,
put them at the end of the XL list.
end loop
end loop
</pre></b>
while (events exist at current time in the scheduler) loop
Process event: Put the event's fanout at the end
of the current event's list in the scheduler.
end loop
</pre></b>
Another reason for event order differences is different orders of fanout processing. This situation is best illustrated with a small example. Consider the following Verilog description -</p>
always @(a)
y1 = ~y1;
always @(a)
y2 = ~y2;
</pre></b>
if (a has an event) then
for each item in the fanout list of a loop
Put this item in the active event list.
end loop
endif
</pre></b>
always @(a or b)
begin
case ({a,b,state})
4'b0100 : state = 2'b01;
4'b1000 : state = 2'b10;
4'b1101 : state = 2'b11;
4'b1110 : state = 2'b00;
default : state = 2'bxx;
end case
end
</pre></b>
<ol style="font-size: 12px;">
<a name="footer1"><li>A Quantitative Perspective on IC Design Verification Productivity in the Era of SoC. Ron Collett. Collett International Inc. Santa Clara, CA, August 1999</li></a>
<a name="footer2"><li>Kirshenbaum, Zeev, "Functional Coverage Demystified", Verification Guild, vol. 1, no.10, item 4, http://janick.bergeron.com/guild/></li></a>
<a name="footer3"><li>Cox, Steve, "Functional Coverage Demystified", Verification Guild, vol. 1, no.11, item 6, http://janick.bergeron.com/guild/></li></a>
<a name="footer4"><li>Verification Cockpit - TestBuilder, a test bench authoring system from Cadence Design Systems that lets you create tests in C++ to drive simulation. You can write tests at the transaction level in C++, with functional coverage provided by TE technology.</li></a>
</ol>
</TR>
<TR>
<!--Enter Bottom Navigation in cell below -->
<TD colspan="2" WIDTH="558">
<P align="center" CLASS="foot">
<A HREF="http://www.cadence.com/">Home</A> |
<A HREF="/company/">Company Info</A> |
<A HREF="/design_services/">Design Services</A> |
<A HREF="/eda_solutions/">EDA Solutions</A> |
<br>iDesign Methodology Services |
<A HREF="/company/contact.html">Contact us</A>
</P>
<P align="center" style="font-size: 8pt; font-family: arial, sans-serif; text-align: center; margin-left: 10px;">Copyright© 2000 Cadence Design Systems,Inc. Corporate Marketing</P>
</TD>
</TR>
</TABLE>
</HTML>
sponsored by Boyd Technology, Inc.