• Concept/Purpose
• Usage
  • Create Configuration View
  • Open Configuration View
  • Set Bindings in the Hierarchy Editor
  • Browse Design Hierarchies in the Hierarcy Editor

Concept/Purpose

The Hierarchy Editor window has been introduced in the Laker™ Advanced Design Platform (ADP) to allow easy switching among view types for netlists. Users can create the configuration to specify the binding view for each cell/instance and then review the binding for the whole design on the cell level, instance level or each level through the entire hierarchy via the Table View or the hierarchy Tree View. The binding configuration is saved as a config view in ADP.

Back to top

Usage

Create Configuration View

In the ADP main window, invoke the File > Open command to open the Open Cell form. Select a mapped library in the Library field, and then select a top cell that you would like to create a configuration view for. The New Cell View form opens after you right-click on the selected cell and then select the New command from the right mouse button command menu. Click the View Type selection field to see that the Configuration view type is available. Choose this option and click OK to generate a configuration view for the selected cell.

Figure 1: Create New configuration View via New Cell View Form

Alternatively, you can select the library and cell in the Open Cell form, and simply enter the string config in the View text field and then click OK to create the configuration view.

Figure 2: Create New Configuration View via Open Cell Form

After creating the configuration view, a New Configuration form will be opened for you to specify the global binding rule. The library and cell can also be changed in this form if needed.

Figure 3: Specify Global Binding Rules

The pre-defined templates in ADP can be applied for the global binding rule. Click the Template button to open the Use Template form and then select the template in the Name selection field or specify a template file path in the From File text field. Currently ADP provides 6 templates: AMS, eldo, hspice, smartspice, spectre, and verilog.

Figure 4: Specify Pre-defined Templates

Back to top

Open Configuration View

After a configuration view has been created, you can see the configuration view (config) will be available in the View field of the Open Cell form (invoked from the File > Open command in the ADP main window).

Figure 5: Open Created Configuration View

When opening a created configuration view, an Open Configuration or Top Cell dialog window will be opened to ask which view you would like to open. Select yes on the Configuration option to open the Hierarchy Editor window (refer to Figure 13) for browsing the design hierarchically and defining binding rules. Select yes on the Top Cell option to open the Schematic Editor window (refer to Figure 7) for showing the design schematics.

Figure 6: Open Configuration or Top Cell Dialog Window

If the Schematic Editor window is opened in this way, a special icon will be shown on the design hierarchy top to indicate the design has been configured.

Figure 7: Schematic Editor Window

Back to top

Set Bindings in the Hierarcy Editor

There are three levels of bindings that can be set in the Hierarchy Editor window to assist in cell view switching:  

• Global Bindings: bindings at the global level. The View List information of global bindings will be inherited by cell and instance bindings as the Inherited View List. The Stop List information of global bindings will also be referenced by cell binding and instance binding. When a cell or instance is bound to a cell view and the bound cell view is in the Stop List, the cell or instance will be treated as a leaf cell and stop expanding to next hierarchy. 
• Cell Bindings: bindings at the cell level. Cell bindings are effective on all instances which reference the same master cell.  
• Instance Bindings: bindings at the instance level. This is only effective on the instance.

At any node of a design hierarchy (e.g. an instance or a cell) the View Found information shows the binding cell view of the instance or the cell. The View Found information can be set by one of the following three methods:

1. Directly enter the view name in the View to Use field.
2. Select the view type under the Set Cell View command (invoked by right-clicking in the targeted cell row in the Cell Bindings section on the Table View tab) or select the view type under the Set Instance View command (invoked by right-clicking in the targeted instance row in the Instance Bindings section of the Table View or Tree View tabs).
3. The first view found in the search to the Inherited View List.

Except for the Stop List in the Global Bindings pane, a stop point can also be set manually by selecting the Add Stop Point command from the right mouse button command menu, invoked by right-clicking in the targeted cell row in the Cell Bindings section of the Table View tab or by right-clicking in the targeted instance row in the Instance Bindings section of the Table View or Tree View tabs. The Remove Stop Point command can remove the stop point added by the Add Stop Point command.

Figure 8: Add Stop Point

You will need to re-compute the whole hierarchy by clicking the Update toolbar icon when modifying global, cell or instance bindings. The Update Needed toolbar icon will be highlighted in red automatically if re-computing is needed.

Figure 9: Set Global Bindings

To set cell bindings, you can right-click in the row of the Cell Bindings field under the Table View tab, and select the desired view type under the Set Cell View command. After clicking the Update Needed icon, the binding will be set and reflected to the design throughout the entire hierarchy. You can see the change when clicking the Tree View tab to see the instance hierarchy.

Figure 10: Set Cell Bindings

To set instance bindings, you can right-click in the row of the Instance Bindings field under the Table View tab (if the option Show Instance Bindings option has been turned on), and select the desired view type under the Set Instance View command.

Figure 11: Set Instance Bindings in Table View

Alternatively, you can select the Tree View tab to view the complete instance hierarchy, and then right-click on the instance node to set the view type under the Set Instance View command.

Figure 12: Set Instance Bindings in Tree View

For both Cell Bindings and Instance Bindings, if the view type string is marked as blue then it means the view type is set by users in the View to Use field; if the view type is marked as black then it means the view type is inherited from the Inherited View List; if the view type is marked as red then it means the view type cannot be found. The priority of the binding is: Instance Bindings > Cell Bindings > Global Bindings.

 After all bindings are set, select the command Cell > Save in the Hierarchy Editor window or click the Save toolbar icon to save the configuration. All changes and bindings will be saved to the opened config view.

Back to top

Browse Design Hierarchies in the Hierarchy Editor

The Hierarchy Editor window will be opened if you open the configuration view. In the Hierarchy Editor window, select the Table View tab to view all cells which have been used in the specified Top Cell throughout the entire hierarchy in a table view. Each row shows the Library name, Cell name, View Found, View to Use, and the Inherited View List.  The View Found column shows the view type that has been actually used in this cell; the View to Use column is for users to enter the view name manually; the Inherited View List column shows the view list which was set by users or inherited from the View List of the Global Bindings.

Enable the Show Instance Bindings option at the bottom of the window to expand the window with an extra table, which lists all instances under the selected cell in the Cell Bindings table.

Figure 13: Hierarchy Editor Window - Table View

Select the Tree View tab of the Hierarchy Editor window to browse the instance based hierarchy of the cell, which shows all instances which have been used under the top cell and their hierarchies. Click on the + icon or – icon on the hierarchy to expand or collapse the node.

Figure 14: Hierarchy Editor Window - Tree View

Back to top

The Siloti™ Visibility Automation System (part of the Novas Verification Enhancement Solutions) needs to perform Behavior Analysis on the related design scopes when the Data Expansion command is used for the first time. When this happens, users need to wait for the Behavior Analysis process to finish. The waiting period makes the usage of the Data Expansion command difficult.

Now users can save the results of Behavior Analysis to the Behavior Database (BDB) using the batch mode utility bacom. Then, when the BDB is loaded into the Novas solution, the lag caused by Behavior Analysis is greatly reduced.

Here is an example of the recommended flow with the Siloti system:

1. Compile the design to a library.
   > vericom -f run.f
2. Indicate bacom should flatten all array signals.
   > setenv FLAT_ALL_ARRAYS 1
3. Use bacom to run Behavior Analysis and generate the BDB.     
   > bacom –lib work –top system
4. Perform Essential Signal Analysis while loading the work.bdb BDB file.
   > esa –lib work –bdb_load work.lib++/work.bdb –db es
   where the –bdb_load option is for specifying the BDB.
5. Run the simulation and generate the ES Dump (ESD) file es.fsdb.
   > simv +vcs+lic+wait +fsdb+esdb="es"
6. Invoke the Siloti system while loading the ESD file, and the BDB file.
   > siloti -top system -lib work –esAuto -ssf es.fsdb -bdb_load work.lib++/work.bdb

where the –esAuto option can enable automatic Behavior Analysis and/or Data Expansion according to the Essential Signal Tag in the FSDB.

Now with the BDB loaded from the command line, the overhead of Behavior Analysis no longer exists. As a result, you can debug smoothly with full visibility.

One important goal of the Certitude development team is to continually improve the quality of the results presented to the user for analysis.  By quality, we mean relevance to “big problems” in the user’s verification environment and uniqueness – the likelihood that any given non-detected (ND) fault from a particular iteration of the tool points to a problem that is different than the other ND faults.  A related goal is efficiency – the quick isolation of a few important problems that should be investigated and fixed before continuing.  One of the processes that greatly improves both quality of results and efficiency is fault dropping.

Concept & Benefit
The motivation for fault dropping is the idea that if a particular fault cannot be detected (i.e., is ND), then many related faults will not be detected for the same reason (e.g., missing or weak checker in the verification environment).  Thus, if we can find a good definition for “related faults”, then we can present the user with a single ND that, if addressed, is likely to fix many other potential ND faults.  The benefits to the user are significantly reduced analysis and debug overhead and overall faster qualification of the verification environment.  For example, instead of sorting through and investigating 20 ND faults that together point to the same five checker weaknesses in the user’s verification environment the user is presented with one ND for each of the five unique weaknesses. 

Finding Related Faults:  Logic Cones
One reasonable way to identify related faults is to group faults based on their proximity from a logical perspective.  More to the point, faults in the combinational cloud of logic that impact (feed into the data input of) the same register or set of registers can be said in some ways to be in “close proximity” to one another and therefore related.  Of course, this is not a perfect measure, but in practice it turns out to be highly relevant, at least from a qualification standpoint.  In Certitude, the cone of logic is first calculated forward from the fault to the impacted registers, and then back through the logic to the previous rank of driving registers.  Figure 1 illustrates this concept.

Figure 1:  Logic cones in Certitude

Applying Fault Dropping for Higher Quality Results & More Efficient Operation
In Certitude, the task of grouping faults by cone falls to the Optimizer, a process that runs during the model phase and performs a static analysis of the design.  The Optimizer tags faults that are in the same logic cone.  Later, during the detect phase, when Certitude finds an ND fault, it uses the information from the Optimizer to drop the related faults.  In this case, “drop” simply means “defer the qualification of these faults until later”, with “later” being after the user fixes the verification environment and qualifies the initial ND.  After the original ND is qualified and detected (D), Certitude will attempt the qualify the previously-dropped faults.  In the typical case, many of these faults will now be found to be D due to the same fix.  Using this technique, Certitude enables finding and fixing important problems quickly with a minimum of simulation and analysis time.

The Power Map window can be used to visualize power intent in a schematic view. Refer to the following figure for an example of the window.

The schematic view shows the structure of the loaded UPF/CPF power design where the  icon represents an Isolation command, the  icon represents a Level-shifter command, and the  icon represents a power switch cell.

To invoke the view, you need to set the environment variable NOVAS_POWER_BETA to 1 as the feature is currently considered beta. For example:

> setenv NOVAS_POWER_BETA 1

Then select the Tools > Power Map command (from nSchema or the Power Manager window) to open the Power Map window (UPF/CPF should be imported first).

You can use the window to understand the structure of the power design. Drag any isolation, level-shifter, or switch cell icons (, , or ) to the Power Manager window to jump to the definition of the related rules. Similarly, drag any power domain from the Power Map window to the Power Manager window to jump to the power domain’s definition.

To check the related signals of an isolation or level-shifter rule, select the related icon, then select the Schematic > Impacted Power Signals command to bring up a form summarizing the impacted signals of the selected rule. See the following figure for an example.

The Power Map window can validate whether all signals between power domains are guarded with isolation rules if a possibility exists that the domain a signal is coming from (‘from’ domain) is off while the domain the signal is going to (‘to’ domain) is not. If this is the case, unexpected results could propagate through such signals from the ‘from’ domain to the ‘to’ domain. Similarly, signals are suggested to be guarded with level-shifter rules if the signals’ ‘from’ and ‘to’ domains are both ‘on’/‘standby’ states but the domains’ voltages are different.

The checking is performed when the Power Map window is first invoked or when the related checking options (View > Check non-cover Signals > Check Isolation Signals, View > Check non-cover Signals > Check Level-shifter Signals; both default to on) are turned on. The results will be shown as non-covered nets (shown by dotted lines). A non-covered net contains all non-covered signals on the path from domain X to domain Y. The red dotted lines represent the non-covered isolation nets (it is suggested to apply isolation rules); the green dotted lines represent the non-covered level-shifter nets (it is suggested to apply level-shifter rules). Refer to the following.

Chances are, if you are the one doing the digital blocks in a “big A , little D” (primarily Analog) environment, you are either handcrafting the digital design from a schematic, or – for larger blocks – sending it out to a megabucks digital place and route tool, and then modifying it afterwards. Either way, you know the pitfalls of these approaches first hand – especially at advanced nodes.

But what if you could get both environments in one system? (Hint: you can.)

In 2010 SpringSoft launched two new controllable automation engines – the Laker Custom Row Placer and the Laker Custom Digital Router – to enable a faster, more efficient custom digital design flow.  Both tools run completely within the Laker™ Custom Layout Automation System.  If you can imagine a digital place and route tool with all of the ability of a high-end layout editor built in, then you get the idea.

How does that work? Very well, actually! The Laker Custom Digital Place and Route tools have been very well received and are in daily production use for designs down to 28nm at a number of major semiconductor companies.  The flexibility to automatically or incrementally build up a high-performance custom digital block using standard cells and to do as much or as little of the job as you want to by hand is the perfect combination for many of you.

Let’s begin at the beginning: Regardless of whether you are working with a SPICE (transistor-level) or digital (gate-level) netlist, the Laker system can auto-generate a corresponding schematic for you in the Laker schematic-driven layout (SDL) environment. The schematic and hierarchy views appear in the Laker layout window as in analog design.

Prior to placing any cells, you can use the Custom Row Placer’s floorplanning capabilities to query the design data and estimate the area needed to create a right-sized block, or you can simply draw any orthogonal-shaped area (or areas) in which to locate the digital cells. The resulting block may be queried for the utilization rate to assure successful placement and routing before you start. In today’s mixed-signal designs where dozens of small digital components may be mixed into an analog block, the convenience of in situ digital block generation is quite attractive. However, when the exact shape of the digital block is not as critical, you can also specify any number of variables from utilization rate to height or width dimensions and let the placer automatically define the actual block size. It doesn’t get any easier than that!

Next, you can use automated Power and Ground (PG) routing to create the PG rails around the periphery of the block and again, you have the option to tweak them by hand.

Because Laker knows the desired connectivity from the schematic, it can automatically generate the pins associated with the digital block in the row placement area. Of course, in this custom environment you have the freedom to just move them wherever you want them if you so choose.

Placing:  With the placement area defined, you could just let the placer place the entire design. But that’s probably not as “custom” as you want, so you have the option of using Laker’s SDL capabilities to drag critical cells from the schematic and hand-place them into the digital block. When a cell is hand-placed in this manner, you will have flight lines to the pins and previously placed cells to help guide your placement. In addition, when placing the cell, it will automatically snap to a legal placement in the relevant row. Even better, as a cell is dragged up or down across rows, it automatically flips back and forth to match that row's power and ground signals.

After you are done placing the critical cells, you can select the remaining cells in the schematic and instruct the Laker Custom Row Placer to automatically place them, which it will do following all design rules and constraints while minimizing wire length. The Custom Row Placer works with the Custom Digital Router to minimize congestion and assure a routable and DRC-clean placement. It will perform incremental selection and placement, as well as internal iterations to pack the placement area.

The Laker Custom Digital Row Placer

But this is only the start: You can use all of the Laker layout system’s normal editing functions to move cells, or hand-route critical nets, for example. Or, if you subsequently import a modified netlist for a digital block, the Laker system’s ECO capabilities will automatically identify any changes and assist in placing only those portions of the design. Similarly, if you place a new cell or cells into a previously placed area, the system can automatically legalize these cells and shift surrounding cells around to make room.

While performing its tasks, the Custom Row Placer is constantly aware of routing issues. If you request a congestion map, the Custom Digital Router will determine which areas will be difficult to route and highlight those areas. This gives you the opportunity to use the Laker layout capabilities to move things around, create blockages and/or routing channels, and to re-check for potential congestion. This is the kind of interactive, controllable automation needed for high-productivity custom digital layout.

Congestion maps check routability

When the placement is done: The Custom Digital Router performs routing directly in the Laker database – or in OpenAccess – and is fully supported with LEF/DEF import and export capabilities. It is a hybrid router that can employ both grid- and shape-based routing technologies. The grid-based router is used for initial routing to provide better performance (speed), and then the shape-based router takes over to address off-track pin connections and any remaining design rule violations. The router employs a full suite of DRC avoidance utilities – such as support for advanced end-of-line spacing, min-edge/min-area, and enclosure edge rules – and offers post-route yield optimization to remove small notches and jogs and add redundant vias where possible. Routing is DRC clean down to 28nm.

The Laker Custom Digital Router

What’s custom about this router? With placement complete, you can tell the router to route the entire design automatically, but a custom digital block typically requires some amount of customization or it wouldn’t be custom, right? Because the Custom Digital Router is incremental and interactive, you can use the various built-in routers in the Laker Layout system to hand-route critical nets and then complete all or some of the remaining routing automatically using the Custom Digital Router. At any point in this process, you can run a global route and review the congestion map to ensure a successful completion.

The Custom Digital Router also takes design changes in its stride. Before now, changes to the digital design made after the design was routed often required a complete rip-up and re-route, causing all of the painstakingly hand-drawn routes to be lost. Our router will recognize both floating and added connections and make the necessary corrections without disturbing existing connected routes. Throughout the process, the seamless integration of built-in Laker Layout features and Custom Digital Router features work together to create a far more efficient flow.

Summary:  The Laker Custom Row Placer and Laker Custom Digital Router work in conjunction with each other to minimize wire lengths and assure routable placements. These new custom place and routing technologies allow you to work in a single comprehensive design environment for maximum productivity and achieve high quality of results (QoR) in a fraction of the time it would take to place and route the digital blocks by hand. For the first time, there truly is a "mixed” design flow for mixed-signal design that can improve quality, increase productivity, and accelerate time to market and time to profit.

The waveform view (nWave window) in the Verdi™ Automated Debug System provides the capability to attach an alias to the waveform value which gives a better way to visualize the waveform. Now the capability has been further improved for adding conditions, so that the tool can automatically determine which alias table (when there are multiple tables) should be applied based on user-defined conditions. The conditions can be created by one-bit signals or logical expressions which are combined by several signals. The following steps demonstrate how to create a condition for applying multiple alias tables:

1. In the nWave window, invoke the Waveform > Signal Value Radix > Edit Alias command to open the Alias Editor form. On the Alias tab of the Alias Editor form, create several alias tables and specify an alias name for each table.

2. Click the Conditional Alias/Slice tab of the Alias Editor form. Create a Condition Table and then specify the condition in the Condition column to identify which alias table should be applied under that condition in the Alias/Slice column.

3. The condition can be built by dragging and dropping one-bit signals from the nWave window  or by logical expressions which combine several signals. Clicking the Logical Expression button of the Alias Editor form will open the Logical Operation form for users to create logical expressions. Click the Add to Wave button in the Logical Expressions form to add to the waveform view after the logical expression is created.

4. The created logical expression can be added into the Alias Editor form by dragging and dropping from the nWave window to the Conditions column. After all conditions are specified, click the Apply button in the Alias Editor form and the alias table will be applied to the waveform view based on the given condition.

The Laker™ Advanced Design Platform (ADP) unites the full-featured Laker schematic editor, open Simulation Console and LakerWave™ waveform analyzer to create a complete circuit design environment. It works seamlessly with SpringSoft’s award-winning Laker Custom IC Layout system and all of the popular analog simulators to provide a complete solution for the rapid design of your analog, mixed-signal, memory, and custom digital IC designs.

In the 2010.11 release of Laker ADP, the Simulation Console which enables the user to set up and execute most major simulation tools from within the Laker ADP environment has been completely revamped. The Simulation Console (invoked by selecting the Tools → Simulation command in the Schematic Editor window or clicking the Simulation toolbar icon in the Schematic Editor window) has been redesigned to enable better third-party tool integration, and the GUI and use models were restructured and improved to add features that further enhance the Simulation Console’s ease-of-use.

The Simulation Console window consists of the Simulator Setting and Simulation Tree Browser panes.

Simulation Console Window

The new Simulation Tree Browser was added for convenient manipulation of the Environment Setting; Model and Include Files; Temperature; Design Variables; Analyses; Options; Output/Probing; and Others statements.

Simulation Tree Browser Pane

Key highlights of the new Simulation Console include:

•  
  • New improved QT-based GUI
  • New Simulation Tree Browser
  • Support for Spectre® RF analyses such as PSS, PAC, PNoise, Noise, STB, XF, and SP
  • A new pick-up operation used to select an instance, net, or port from the Schematic Editor window and then add the selected instance, net, or port to the Output/Probing table. Objects that will be selectable will vary depending on which analysis types and values are selected.
  • The ability to extract design variables from the open schematic view when the Extract from Design option is turned on
  • The Simulation View: Now simulation settings can be saved or opened as a simulation view (Laker ADP now supports four new views including simulation, Verilog, Veriloga, and SPICE views). The Simulation Console will be invoked when simulation view is selected in the Open Cell GUI.

Open Cell GUI Supports 4 New Views

The simulation settlings used with the previous Simulation Console cannot be used in the new Simulation Console because the storage model had to be changed. In order to reuse settings from previous revisions of Laker ADP, it is necessary to save the simulation settings again in the new Simulation Console. However, the original Simulation Console can still be invoked by designating a keyword InvokeLegacySim in the [SimCon] section of the laker.rc resource file. For example:

[SimCon] InvokingLegacySim = TRUE

For more details, please refer to the Simulation Console chapter of the Command Reference Manual. We think that you will find the new Laker ADP Simulation Console more productive and easier to use than ever.

Laker and LakerWave are trademarks of SpringSoft, Inc.  All other trademarks or registered trademarks are the property of their respective owners.

The Verdi™ Automated Debug System with the nAnalyzer™ Design Analysis module provides full functions for extracting clock trees and qualifying CTS (Clock Tree Synthesis) settings. However, the clock tree extraction has to be processed in the Verdi system with the nAnalyzer module so the debug time may be occupied especially if the gate level netlist is vast.

To reduce the effort of extracting clock trees every time (especially when there aren’t any changes to the design), the Verdi system provides a batch mode utility nClockTree to do the clock tree extraction in batch mode and save the results in a loadable file. With this one-time effort, users can load the extraction results and all settings into the Verdi system with nAnalyzer for further CTS qualification.

The following steps demonstrate how to extract clock trees, save the extracted results as a loadable database (or an Astro format ASCII report), and then load the loadable database into the Verdi system for further qualifications:

1.     Execute the nClockTree utility to extract clock trees:

Use the utility nClockTree under <Novas_install>/bin to read the design and generate the clock tree extraction results. SDC and CTS settings can also be imported and converted to nAnalyzer settings, just like importing these settings in the Verdi system with the nAnalyzer module.

a. To extract clock trees and save the results as a loadable database execute the following example:

% nClockTree -f run.f -sdcFile sdc_system.sdc -outputFormat Database -output CTS.db

b. To extract clock trees and save the results as an Astro format file execute the following example:

% nClockTree -f run.f -sdcFile sdc_system.sdc -outputFormat Astro -output CTS.astro

2.     Load the extraction results into the Verdi system for further qualification:

The extraction results and settings can be loaded into the Verdi system through the Save As form. The form can be invoked in one of three ways:

a.     In nTrace, invoke the File > Load Clock Tree Data Base command.
b.    In nSchema, invoke the File > Load Clock Tree Data Base command.
c.     In the Clock Tree Browser, invoke the File > Load Clock Tree Data Base command.

3.     Save the clock tree extraction and settings to a loadable database from within the Verdi system:

You may make modifications or add more settings for the clock trees after qualifying the extracted clock tree, and then save all of these modifications and settings into the database again. In the Clock Tree Browser window, invoke the File > Save Clock Tree > Save Clock Tree Database command and then specify a file name for saving another ASCII file. A <filename>.log will be automatically generated and all CTS settings are stored in this file. The command File > Save Clock Tree > Save as Astro Format is also available in the Clock Tree Browser window for saving the clock tree as an Astro format in the ASCII file.

If you are a Certitude user, you know that non-detected (ND) faults are the typical starting points for the results analysis process. An ND fault indicates that Certitude has propagated the effect (incorrect operation) of an injected fault to the boundary (outputs) of the design, but the verification environment (VE) does not detect it. This typically indicates some deficiency in the VE's checking infrastructure – perhaps an incomplete or altogether missing checker that can let RTL bugs escape the verification process undetected. This article considers two important issues to consider when investigating an ND fault: The "size" of the design change implied by the fault and the origin of the problem that led to the VE weakness.

Size of Implied Design Change
It's possible for any given ND fault to seem unimportant on first inspection. The deviation of the outputs from the golden reference results may be small or it may be assumed that the related functionality will be tested by others at a later stage of the verification process. However, before relegating an ND to the "don't care" bucket, it's important to consider the magnitude of the design change implied by the related fault and whether lack of sensitivity to the change is really acceptable at the current stage. Consider an output stuck-at fault that disconnects and ties a given output to a constant value. The implication is that all of the logic that uniquely drives this output is removed from the design during verification. If the resulting ND fault is a "don't care", then why is this logic present? Can it really be removed from the production design with no impact on functionality and proper operation? Similar situations exist for reset condition "true" and synchronous control flow faults. The former causes an individual process in the design to be "stuck" in reset mode, essentially removing it during verification. The latter forces the control flow of an if/else block to always take the "true" or "false" branch, effectively removing the other branch. If Certitude finds the related fault to be ND, then one must ask whether it's reasonable to fabricate and ship the design with the related logic removed. If the answer to this question is "no", then there is most likely something to diagnose and fix in the VE checking infrastructure.

Origin of the Problem
Diagnosing and fixing the VE weakness – adding a missing checker, making an existing checker more robust, fixing the VE scripting infrastructure to be more sensitive to testcases that should be flagged as failing, etc – is critical. Only when the fix is made and checked into the regression environment can the VE be made stronger and able to catch more RTL bugs. At least as important, however, is taking a step back to consider why the problem was present in the first place. Was the design specification unclear, causing the author of the test plan to miss or incorrectly implement a critical check? Was the testplan simply somehow incomplete, even though the design specification clearly laid out all functionality that needed testing? Was there a process problem – for example, a checker that was turned off at some point to enable further testing while a design issue was resolved but was never re-enabled? Fixing a checker will resolve the problem in the current VE, but identifying and fixing the original cause of the problem –through additional clarity in design specifications, enhanced review of testplans, or implementation of checks on the process itself – will maximize the benefit of the functional qualification process and improve the quality of future designs.

When the RTL design is converted to a gate-level design, part of the power intent defined in CPF(CommonPower Format )/UPF(UPF - the IEEE 1801-2009 standard) power files is 'synthesized' either by a synthesis tool or by the designers manually. For example, the isolation, level-shifter and retention rules are implemented by inserting isolation, level-shifters and retention cells during the conversion from RTL to gate level design. Along with the conversion, the content of the CPF/UPF files should be refined by the tool or designers respectively to reflect the changes. For the previously mentioned example, the related isolation/level-shifters/retention power rules should be removed from theCPF/UPF files since they are replaced by the isolation/level-shifters/retention cells respectively (refer to the following figure).

The refined CPF/UPF(CPF'/UPF') files and the gate level design needs to be verified to confirm equal functionality to the original CPF/UPF files plus the RTL design. The Verdi™ Automated Debug system provides exactly the same power-aware debug capability as in the RTL stage so that users can debug inconsistencies (between RTL and gate level) in the same Verdi environment.

Additionally, the Verdi system can recognize and highlight power cells which are unique to the gate level. The Verdi system can import the power cell information from the Synopsys Liberty files, UPF files (power cell commands) and the Library CPF commands. The power cells can be highlighted which help users to compare the inserted power cells and its related logic with the mapping part in the RTL design. For example, users can inspect whether the location and direction of isolation, switch, or level shifter cells is consistent with the related power rules defined in the RTL stage. Or, users can check whether the inserted retention cells are placed in the right scope and the connection is correct (equivalent to the related rule).

Refer to the following for an example of the highlight and annotation of an isolation cell in the nTrace window.

Many Laker customers are familiar with the Laker-T1 TCD (Test Chip Development) platform. After all, it has been used by many of the world's top foundries and fabs for automated test line and test chip development. The simple GUI interfaces in Laker-T1 allow process development engineers with little or no layout experience to develop comprehensive parameterized test suites.

The Parameterized Test Structures built using the Laker T1 GUI are process-independent and can be re-used over and over again. The benefits of this methodology include the ability to create a far more comprehensive suite of tests in much less time, thereby gathering a more statistically significant sample. Additional time savings come from automated documentation generation because documentation typically lags far behind the rest of the process development cycle.

Figure 1. Automated gate measurement documentation

So it was little surprise when customers began to use LakerT1 to generate DRC validation test structures for advanced process nodes. Today, some of the world's top semiconductor companies are among the users of Laker-T1 for DRC validation.

DRC validation issues

During process development, when design rules are still evolving, a fully parameterized DRC validation library can be invaluable in validating the constantly changing design rule deck and can help to minimize the perturbation to cell library and IP development occurring in parallel. Even if evolving design rules are not a problem, some analog companies have literally hundreds of processes, and face similar challenges in keeping up with the DRC validation process.

Fabless companies and IP developers that are on the leading-edge of technology cannot wait for final DRC decks from the foundries and have to - or prefer to - develop their own DRC decks. "Fab-lite" and other companies that design using different layers and methodologies than the foundry design rule manual calls for the need to make their own DRC decks. Some companies even create compromise design rules that can be used in more than one fab so they too have to make their own rule decks.

For these companies and almost any company that writes or modifies DRC decks, the ability to rapidly create a comprehensive validation test suite can be very beneficial.

How Laker-T1 can help

In a simple case, Laker-T1 users can create checks for width and space for every layer and most conditions by drawing a single rectangle or L-shape in the GUI (See Figure 2.) and parameterizing it. The variable parameters can be set from a spread sheet in the GUI or an external CSV (comma-separated-variable) file from a spreadsheet program to create as many variations and combinations as necessary.

In a 30-layer process, to check a set of simple width and space rules for nominal, nominal minus one grid, and nominal plus one grid would require 180 drawn structures or individually parameterized PCells that somebody has to code. If fat metal rules, corner-to-corner checks, and parallel run length rules are

Figure 2. Simple widthand space test structure

added - all incremented above and below nominal by only one grid – it could easily require 500 or more patterns.

All of this can be done simply and automatically in Laker-T1. Users can automatically create arrays of validation structures in such a way that the known-good and known bad structures give a quick visual indication of whether the deck is catching known errors, creating false-positives etc.

During validation, stepping through the DRC flags with any of the DRC tools integrated into the Laker Custom Layout system (and therefore Laker-T1) will provide quick analysis due to the ability to provide parameterized, polygonal labels to every structure and/or test line that denote the intended result. In addition, the automatically generated documentation will help describe the rule and location in question.

Figure 3. Transistor structure can be used to validate numerous gate-related DRC checks

Using the Laker-T1 Test Chip Development platform for DRC validation checks is one more reason to take a look at Laker products.

Verdi supports the export of the Signal RC file for recording signals which have been loaded into nWave, and the rc file can be loaded back for the next debug session. In previous versions the signal rc file could also be applied to the FSDB file which contains the same scope. Starting from Novas 2010.10 onward, a new option has been added when exporting the signal rc file, so that users can re-use the saved Signal RC file and apply it to an FSDB file which has a different scope.

Below is a scenario which demonstrates the usage of how to re-use the Signal RC file, when two design teams are debugging the same design but with different scopes:

 Scenario: Assuming Team 1 is debugging a CPU module and the scope is “system/CPU”, where Team 2 would like to re-use Team 1’s Signal RC file but the scope is “CPU”. These two teams can follow the steps below to re-use the Signal RC file.

 1.     Team 1 can invoke the File > Save Signal command in nWave to open the Save Signal form, and click the Option button to open the Save Signal RC Attributes form. Then, turn on the last option, Save Scope with Macro and drag and drop the signal (under /system/i_cpu scope) from nWave to the text box. Click OK and then export the Signal RC file.

 2.     The first several lines of the Signal RC file will look like the following:

Revision 2010.10
waveDefine RE_TOP  "/system/i_cpu“
addSignal -h 15 ${RE_TOP}/En_A
addSignal -h 15 ${RE_TOP}/i_ALUB/i_alu/cin

 3.     Team 2 can now modify the line “waveDefine RE_TOP  "/system/i_cpu”” to “waveDefine RE_TOP  "/CPU”” since their top scope is “/CPU”. The modified Signal RC file can now be applied to Team 2’s design.

The Verdi system supports the folding of source codes such as statements, port lists, and comments automatically. Users can enable the folding capability to fold the source code on nTrace, so that they can just focus on their area of interest. Starting from Novas 2010.10 onward, this capability has been further improved, and divided into three options for users to fold different types of source codes.

To enable the folding capability, users can go the Source Code > Code Folding page in the Preferences form (which can be invoked from the Tools > Preferences command). There are three options on this page: Automatic Statement Folding, Automatic Comment Folding, and Automatic Port List Folding. Three kinds of source codes can be selectively folded by enabling these three options.

After enabling the option in the Preferences form, a “+” or “-” icon will be added to the left side of the source code. Clicking the “+” icon will expand the source code and clicking the “-” icon will collapse it again.

At the same time, some additional menu commands will also appear after turning on the preference setting, to allow users to expand or collapse different kinds of source codes. See the figure below for these menu commands.

During simulation runtime, some non-essential signals may be dynamically driven (forced) by Specman, UCLI, or PLI. These “force signals” should be included in the Essential Signal (ES) list or dumped to an ES FSDB dump file such that full visibility can be achieved when Data Expansion (DE) is performed in the Siloti™ Visibility Automation System.

 For VCS, the Siloti system can automatically dump the “force signals” to a separate “force” FSDB file which accompanies the Essential Signal Dump (ESD) FSDB file. Then the Siloti system can perform Data Expansion upon the union of the ESD FSDB file and the accompanying “force” FSDB file to achieve full visibility.

 Here are the steps to achieve this.

• You need to compile the design and link a new object file “novas_dll_injection.o” located in the <NOVAS_INST_DIR>/share/PLI/VCS/<PLATFORM> directory. When the object file is linked, the FSDB dumper will dump related signals (forced signals and their equivalent nets). For example,

%> vcs –f run.v –P novas.tab novas.a novas_dll_injection.o +vcsd +vpi …
%> simv

•  The “force” FSDB file is named <Name of ESD file>_forced.fsdb. For example, if the name of ESD FSDB is “esd.fsdb”, then the “force” FSDB file name is “esd_forced.fsdb”. The “force” FSDB file name can be configured by setting the environment variable FSB_FORCED_FSDB_FILE. For example:

 %> setenv FSDB_FORCED_FSDB_FILE my_force.fsdb

• You will also need to set the following environment variable to enable the Data Expansion support before invoking the Siloti system:

 %> setenv NOVAS_DE_EXT_FORCED_FSDB_BETA 1

• To include the “force” FSDB file as an input for Data Expansion, "-extForcedFSDB forced_FSDB_file_name" should be specified in the “-DE” option on the Siloti command line. For example,

%> siloti -ba -DE "-extForcedFSDB novas_forced.fsdb"
-top meu -bas meu -nologo –ssf verilog.fsdb

The most important step in running the Certitude™ Functional Qualification System is analyzing the results to identify problems in the verification environment that must be fixed to avoid allowing RTL bugs to slip through the process unnoticed.  The Certitude Report Viewer provides a number of ways to view, sort, and produce detailed information about faults and fault status, with particular attention to non-detected (ND) faults that relate directly to likely verification environment weaknesses.  A number of recent improvements – available in version 2010.07 and later – aim to make the analysis process even more efficient.  This article summarizes a few of the most important improvements.  Please see the product release notes and reference manual for more detailed information.

Support for Manipulation of Multiple Selected Faults
Users can easily select and operate on multiple faults during analysis – enabling, disabling, and adding/deleting comments associated with several faults with a few mouse clicks.  This makes it much easier to perform common actions on a related group of faults quickly and with minimal effort.

Button to Generate Waveforms for Fault/Test Pairs
The fault detail window includes a button to generate Verdi™ waveforms for individual fault/test pairs.  This is in addition to the existing command-line capability and allows users to stay in the report viewer window when requesting waveform details for interesting faults.

Page with Links to all Available Waveform Information
A new “waveform page” provides links to all available reference and faulty waveform data for ND, non-propagated (NP), and detected (D) faults.  This page consolidates and provides easy access to previously-generated waveforms during the analysis process.

Report Generation for Specific List of Faults
Users can now generate a report for a specific list of faults.  The resulting report only lists details and statistics related to those faults, providing a convenient way to reduce clutter and focus a given analysis session on the current faults of interest.

The FSDB dumper shipped in the Novas 2009.10 release included many improvements, one of the most important being the new multi-threaded architecture.  This allows FSDB dumping to be done more efficiently in a parallel fashion when enabled.  Parallel FSDB dumping was designed to reduce dumping runtime and we’ve collected data over the past few months as evidence of its success.

With examples from all 3 major simulators, the parallel dumping mode took up to 50% less time compared to normal non-parallel dumping.  Even in cases where the time for dumping time was relatively small compared to the total simulation time (< 10%) leaving little to improve upon, the multi-threaded dumper reduced runtime by a noticeable amount.  These cases demonstrate that the multi-threaded algorithm has relatively low performance over-head.

There are many factors that influence FSDB dumping performance including design size, design structure, number of signal dumped, type of dumping tasks, etc.  Our data indicates that the larger the dump size and the more time that is spent on FSDB dumping, the more parallel dumping improves performance.

Because of the great improvement in runtime and the lack of negative performance or other side-effects, we strongly recommend using the multi-threaded dumper for all runs.  The only prerequisites are to use the updated dumper with the parallel mode enabled and to run the simulation on a machine with more than one processor (dual and multi-core systems are also good).

To enable parallel dumping mode, add the following option to the simulator command-line:

            +fsdb+parallel=on

or, to enable this for all future simulations runs, set the following environment variable, NOVAS_FSDB_PARALLEL, to 1. 

For example in a UNIX c-shell of similar environment, set the following before starting simulation:

• setenv NOVAS_FSDB_PARALLEL 1

To add an alias to waveform, you can edit an alias table in the nWave window of the Verdi™ Automated Debug System to define a set of values (or value ranges) and their associated alias names. Then apply this table to the selected bus signals.

To create and add an alias table, the steps are:

1. Select the Waveform > Signal Value Radix > Edit Alias menu command in nWave to invoke the Alias Editor form.
2. Enter as many records of value, alias name and background color as you want.
3. When done, click the Save As button to save the table to an alias file for later use. (You can edit and save more than one alias table in the form.)
   The content of the saved alias file will be similar to the following.
   
4. Select the bus signals that you wish to apply aliases on, and then select the Waveform > Signal Value Radix > Add Alias from File command to load the saved alias file.
   
   The first table defined in the alias file will be applied to the selected signals.
   
   All the loaded alias tables can be found in the menu (see below). You can apply an alias to more signals by selecting the target table from the menu.

Alternatively, you can write a c or Perl program that accepts a number and prints out the string corresponding to that number. nWave calls this program to obtain the alias string for display.
NOTE: Background color is not supported using this method and the nWave drawing performance will be impacted as the program will be executed whenever a bus value needs to be drawn.

To add an alias from program, the steps are:

1. Edit a c or Perl program. A Perl example is shown below:

#!/usr/local/bin/perl
select(STDOUT);
while (<>)
{
if ($_ == 0){
$|=1; print "zero\n";
} elsif ($_ == 1) {
$|=1; print "one\n";
} elsif ($_ == 10) {
$|=1; print "two\n";
} elsif ($_ == 11) {
$|=1; print "three\n";
} elsif ($_ == 100) {
$|=1; print "four\n";
}else {
$|=1; print "O.K\n";
}
open(txt,">>ab");
$|=1;
print txt "$_";
close(txt);
}

2. Select the Waveform > Signal Value Radix > Add Alias from Program menu command in nWave to load the Perl grogram.

The aliases printed from the program will be applied to the selected signals.

For complete details on the usage of aliases, refer to the Signal Value Radix section in the nWave: Waveform Commands chapter of the Verdi and Siloti Command Reference Manual (<NOVAS_INST_DIR>/doc/novas.pdf).

Using the powerful database and GUI of the Laker Custom Layout Automation System, Spectral Design and Test Inc has created a new software application called MemoryCanvas that eliminates the need to write code to implement a memory compiler or a complex memory instance. MemoryCanvas uses a unique approach involving the definition of a graphical floorplan to convey assembly instructions. Any memory type from SRAM, ROM, CAM, Cache or FLASH can be defined in MemoryCanvas. It provides complete assembly and netlist generation and incorporates full compiler parameterization as needed.  The efficient Laker database enables MemoryCanvas to produce a fully expanded schematic of memory instances. These schematics are functional for netlist generation and are used in LVS and simulation as well as providing useful guidance to layout designers to see signal flow and leaf cell adjacencies at the schematic level.  Other commercial compiler tool offerings do not support this capability. The floorplan and full schematic instances also serve to document the design and compiler together in one context.

Sample MemoryCanvas floorplan showing floorplan blocks with associated leaf cells

MemoryCanvas provides critical netlists used for Memory characterization and timing view generation. It supports automatic creation of “donut” or “ringed” arrays that can be used to reduce the device count significantly for timing verification or characterization. It also supports the automatic reduction of Pi -networks to even more dramatically reduce the device count for efficient and accurate timing and power simulations. There are several controls for users to define the paths that are selected as critical for simulations and yet minimimizes netlist size.

Support and maintenance of memories becomes much easier using MemoryCanvas as the graphical nature of the tool provides immediate feedback to developers about how the memory is constructed and what the design dependencies are.  MemoryCanvas floorplans are fully process-independent such that migration of a memory to a new process will not incur any additional effort for assembly. 

Using the powerful database and rich interface feature set provided by the Laker Custom Layout Automation System, it was very straightforward to implement the highly productive user paradigm employed in MemoryCanvas. 

For more information about MemoryCanvas or Spectral Design and Test Inc., contact: sales@spectral-dt.com or visit the Spectral website at www.spectral-dt.com

Tcl is a general purpose programming language which is widely used in EDA tools. With Tcl scripts you can extend and customize a tool’s capability, to make your design flow to be more efficient. The Verdi™ Automated Debug System has embedded the Tcl interpreter so that users can easily execute their own Tcl scripts in the Verdi system. There are various ways to execute the Tcl script in the Verdi system. Following are some examples demonstrating how to run the Tcl script in Verdi:

 To run the Tcl script from the Verdi command line:

Use the –play command line option to replay your Tcl script, for example:

Verdi –play your_script.tcl &

All your actions in the Verdi GUI will be saved as a Tcl file in ./VerdiLog/Verdi.cmd, and you can use the –play option to replay this Tcl file in command line when invoking the Verdi system.

To run Tcl command or script in the Verdi GUI:

In the Verdi GUI, open the Preferences form using the Tools > Preferences command. Go to the General folder and enable the Enable TCL Command Entry Form option. The Command Entry form will be opened. The setting will be saved in the novas.rc resource file and the Command Entry form will be opened automatically next time you invoke the Verdi system. Type Tcl commands in this Command Entry form to execute it, and use “source” command to execute an existing Tcl script.

To source the Tcl script automatically when invoking the Verdi GUI:

There are several ways to source the Tcl script and execute it automatically when invoking the Verdi system:

1. Set the NOVAS_AUTO_SOURCE environment variable and specify the Tcl script before invoking the Verdi system. For example:

% setenv NOVAS_AUTO_SOURCE your_script.tcl
% verdi &

2. Modify the novas.rc resource file in your working directory. Search for the TclAutoSource tag in the [General] section of the novas.rc resource file, and specify your Tcl script for the TclAutoSource tag. For example:

[General]
TclAutoSource = MyTclScript.tcl

3. In the Verdi GUI, open the Preferences form using the Tools > Preferences command. Go to the Auto Source folder and click the Browse button to specify your Tcl script file. The script will be executed automatically the next time you invoke the Verdi system.

To register a callback to a specific Verdi action and execute the script when triggering that action:

You can use the embedded Tcl command AddEventCallback to register a callback on a specific Verdi REASON with a Tcl procedure. The Tcl procedure will be executed when the specified REASON is triggered. For example, if you have created a Tcl procedure and want to execute it automatically when some action happens in the Verdi system, add the following Tcl code into your Tcl script and source the script when invoking the Verdi system:

AddEventCallback [tk appname] AutoLoadSignal wvCreateWindow 1

In the above example, the procedure AutoLoadSIgnal will be executed automatically every time a waveform window is created, where wvCreateWindow is an available REASON in the Verdi system. You can refer to the <Verdi_install>/doc/tcl.pdf document for all available REASON to register your Tcl procedure to a specific Verdi action.

The Certitude™ Functional Qualification System identifies holes and weaknesses in the verification environment that can let RTL bugs slip through the process undetected.  Although you can apply Certitude at many different points throughout the verification process, experience has shown that an incremental approach beginning in the early stages is often best – providing immediate value and improving the verification environment over time while balancing resources vs. other verification activities.

When Should I Start Running Functional Qualification?
Functional Qualification requires a reasonably complete and functional RTL description and a set of simulation tests that exercise the RTL to verify that it conforms to the functional specification of the design.  However, this should not be interpreted as a requirement that “all” simulation tests must be available before functional qualification can begin.  In fact, users can gain valuable insight into the verification environment when only a small number of tests are available.  Consider, for example, the set of output stuck-at faults injected by Certitude in the early stages of qualification using its default class-based fault prioritization algorithm.  A verification environment with a small set of functional tests and the most basic checkers and assertions in place should probably detect these types of gross errors, even if tests that exercise the more complex and subtle aspects of the design are yet to be written.  An environment that doesn’t detect these faults is certainly more likely to let serious RTL bugs slip through the process unnoticed.

So, I’ve Qualified the Basic Aspects of My Environment – What’s Next?
As more tests are written, qualification can proceed incrementally.  For example, the completion and use of a “smoke suite” of tests – a set that exercises the major functional aspects of the design and is used as a first-level sign-off before significant RTL changes are checked into the design database – argues for expanded use of functional qualification to provide a more comprehensive measure of verification environment quality and identify holes and weaknesses that themselves invalidate the purpose of the “smoke suite”.  Again, Certitude’s automated fault prioritization process can be applied to guide the qualification at this stage with an expanded set of faults that stress-test the maturing verification environment.

Good News:  Incremental Qualification Accumulates Results Over Time
Functional qualification with Certitude is a cumulative process.  As you improve your verification environment, Certitude ensures that previously undetected faults are detected and then delves deeper into its prioritized fault list to qualify the more subtle aspects of your environment.  As a user, you get the benefits of early feedback on your environment – allowing you to find and fix problems to ensure that your environment is robust – and accumulation of qualification results over time to provide a complete assessment of the quality of your verification environment.

Beginning in Q3, 2010, the OpenAccess version of Laker Custom Layout System will enable the use of interoperable PyCells™ with the popular Laker transistor-level floor planning tools, Matching Device Creator and Stick Diagram window. Previously this unique technology was only available for use with our patented Laker MCells™. WithPyCell "stretch handle" and auto-abut capabilities enabled, PyCell placement results can be optimized in the same way as when using MCells; you no longer have to select and place each PyCell manually.

Following is an example of using PyCells in the Matching Device Creator with a user-defined matching pattern:

1. In the Design Browser window of Laker, select the matching transistors and click the Match Device Creator icon.

A window like the one below will appear.

2. Modify the floorplan as desired; you can enable OD sharing if your PyCells support auto-abutment.

3. The Matching Device Router also works with PyCell devices in the Matching Device Creator

To use PyCells in theStick Diagram window, proceed as you would if you were using MCells. The following example uses an existing cell template:

1. In the Design Browser window, select transistors and click the Create icon to bring up the Stick Diagram window.

The features: Merge (for abutable PyCells), swap, split and align work well when using either MCell or PyCell devices.

2. With PyCell stretch handles enabled, designers can align the transistor gates to minimize wiring jogs.

Figure: Translstor floorplan after Split Gate and Align Gate

3. As always, you can preview the result in the preview window before instantiating.

When two MCell transistors are abutted and then the gates stretched apart, the contacts will automatically be centered between the gates. Therefore, when using the Stick Diagram and Matching Device Creator the diffusion contacts will remain centered for abutted transistors as the gates are stretched apart for alignment. As you can see in the picture above, this is not an automatic behavior of PyCells. If you want the same contact centering behavior when using PyCells, the PyCells will have to be configured to center the diffusion contacts.

The Matching Device Creator and Stick Diagram placement results from both examples are shown below.The yellow diamonds in the layout represent the stretch handles for thePyCells.

Using PyCells with the core Laker Stick Diagram and Matching Device Creator features will give designers more layout flexibility by offering both Laker MCells and interoperable PyCells from the foundry iPDK. This will open up the unique automation of the Laker Custom Layout system to users who want unparalleled interoperability in custom IC design.

In the 6.14 release of the Virtuoso® Layout and Schematic Editor from Cadence Design Systems, the library definition map file, lib.defs, has been replaced by the Cadence® native library definition map file, cds.lib; therefore, the lib.defs file is no longer valid for Cadence IC6.14 or later releases. This creates problems when a user mixes OpenAccess tools from other vendors.

The good news is that Cadence Design Systems offers a download on their website of a free cdsLib plugin for use with non-Cadence OpenAccess tools. Customers can also use the same cdsLib plugin to read the library definition instead of writing their own cds.lib parser. The link to the plugin is:

http://www.cadence.com/webforms/Pages/cdslibplugin.aspx

The cdsLib plugin package redefines the plugin file: oaLibDefSystem.plg to read another plugin file, cdsLib.plg. To ensure your OpenAccess tool can get the correct laLibDefSystem.plg, you have to be careful about the sequence assigned to the UNIX environment variable: OA_PLUGIN_PATH. The cdsLib plugin should be defined at the beginning of the search path of OA_PLUGIN_PATH.

With the Cadence cdsLib plugin, there is no need to develop a cds.lib parser. Because Cadence IC6.14 only recognizes the new cds.lib file, the workaround solution is to use the UNIX symbolic link method to link the cds.lib file to the lib.defs file which allows different OpenAccess tools to use the same library definition file.

%   ln  -s  cds.lib  lib.defs

To maintain interoperability with the Cadence environment, OpenAccess tools can be extended to recognize either cds.lib or lib.defs.

For more details on downloading, installing and verifying the cdsLib plugin, refer to the “Using the cdsLib Plugin” application note (KB#2864) located in the knowledge base of the SpringSoft support website (support.springsoft.com).

The Verdi™ Automated Debug system supports thestandard power formats, Common Power Format (CPF) and Unified Power Format(UPF), as well as the related power-aware debugging capability. This was initially introduced in the 2009.10 newsletter.

To help users debugunknowns and rule out signal unknowns (X value) that are affected by their own power domain being switched off (such unknowns are correct) and focus onunknowns which may be real issues, you can use the Tools > List Power Related X command in nWave. The command will highlight the unknowns which may be realissues (either affected by incorrect HDL or power code) in yellow. The power files must be imported into the Verdi system before this command is accessible.

To use the command,you can select several signals in the nWave signal pane first, click the right mouse button and select the Power > List Power Related X command. The command will analyze and list all X values of the selected signals in the opened List Power Related X form (refer to Figure 1). The rows that are in yellow are theunknowns which may be real issues.

You can continue totrace these issues by selecting any yellow row and clicking the Trace Active X button. Click the Yes, OK and Trace buttons onthe following forms, and then the trace results will be shown in the Trace Active X Results form. See Figure 2 for an example of the trace results. The result concludes that the unknown is caused by a power off from another power domain.

Figure 1: List Power Related X Form

Figure 2: Trace Active X Results Form

For complete details on the usage of the Power Manager window, refer to the Power Manager chapter of the Verdi and Siloti Command Reference Manual (<NOVAS_INST_DIR>/doc/novas.pdf). For more detailed Power Aware Debug commands and usage, please refer to the "Power Aware Debug" application note (KB#8192-2) located in the knowledge base of the SpringSoft support website (support.springsoft.com).

The Verdi™ Automated Debug system supports the standard power formats, Common Power Format (CPF) and Unified Power Format (UPF), as well as the related power-aware debugging capability. This was initially introduced in the 2009.10 newsletter.

Typically, designers for CPF/UPF power intent files and designers of HDL are not the same. To help HDL designers quickly grasp which signals are impacted by the power intent, a Tools > Report Impacted Signals command is provided in the Power Manager window (invoked via the File > Import CPF/UPF Files command in nTrace). When the Tools > Report Impacted Signals command is executed, the Report Power Impacted Signals form will open. The form lists all signals which are impacted by the power intent (imported from the UPF/CPF files). See the following figure for an example of the form.

A new breed of FSDB dumper has been provided since Novas 2009.10. Different from previous FSDB dumpers, the new dumper is unified to support a broader range of simulators andversions. Currently, the new dumper can support Cadence IUS 6.2, Synopsys VCS2006.06, Mentor Graphics ModelSim 6.4b and their later versions. This topic was originally introduced in the 2010.02 newsletter.

Upgrading to the new dumper (this is recommended if you are using Novas 2010 or later versions) has the following advantages:

• Supportfor the latest versions of simulators
• Simplified list of dumping tasks, command-line options, and environment variables
  • Tasks/options/environmentvariables are now shared across all simulators (Cadence, Mentor, Synopsys)
  • Consolidated items and functionality
• Increased dumping performance with multi-threaded architecture
  • Takes advantage of multi-core or multi-CPU systems
• Simplified dumper library naming; simulator version no longer required
  • No needto update invocation scripts with new simulator versions
• Simplified support for multiple FSDB files
  • Specify the FSDB file as an option to the $fsdbDumpvars command
• Added Siloti ESA and enhanced Siloti ES dumping flows

For an overview ofthe new dumper, refer to the "New Unified FSDB Dumper" application note locatedin the knowledge base (KB#8192-18) of the SpringSoft support website (support.springsoft.com).For complete details on the using the new dumpers, refer to the Linking Novas Files with Simulators andEnabling FSDB Dumping (<NOVAS_INST_DIR>/doc/linking_dumping.pdf) manual.

The Laker^TM Advanced Design Platform (ADP) unites the full-featured Laker schematic editor, open simulation console and waveform analyzer to provide a complete solution for the rapid design of your analog, mixed-signal, memory, and custom digital IC designs.

Laker ADP provides the unique Auto Create Wire function that enables you to automatically create wire segments for floating pins of the selected (or all) instances in the Schematic Editor window. Therefore, you don't have to select each floating pin and then create a wire segment for each of them manually. Wire names can be auto-assigned by the tool, the same as the pin name or created based on a user-specified name pattern (consisting of the Laker ADP predefined variables).

For example, to create a user-defined pattern, turn on the User-defined option on the Auto Create Wire form (invoked by Create > Auto Create Wire) in the Schematic Editor window. Then use the three Laker ADP predefined variables: i, p, aw (case insensitive) to edit the new net name pattern; the variable i represents the instance name, the variable p represents the port name, and the variable aw represents the value resolved from the preserved Symbol/Instance parameters aw_L, aw_B, aw_R, aw_T and aw_A. The aw_L, aw_B, aw_R and aw_T (case insensitive) parameters represent the net name for Left, Bottom, Right, and Top pins respectively. aw_A is the global naming rule for pins in any direction if aw_L, aw_B, aw_R, aw_T are not specified particularly.

Here is an example of automatically creating wires for the selected instance with a user defined net name pattern:

1. In the Schematic Editor window, invoke Create > Auto Create Wire to open the Auto Create Wire form, and turn on the User-defined option.
2. Enter the net name pattern "${I}_${P}${aw}" in the text field next to the User-defined option.
3. Select the instance i1. Then invoke Query > Attribute to open the instance's Attribute form.
4. In the Parameter tab of the Attribute form, add aw_A and aw_L parameters, and enter the value "_all" and "_Left" respectively. Then click the Apply button,
5. Go back to the Auto Create Wire form, click the OK button.
6. Four wire segments are automatically created and connected to the four floating pins of the instance i1.

• On pin A which is on the left of the instance, the new wire name is assigned "i1_A_Left". Where "i1" is the instance name, "A" is the port name and "_Left" is the value of the parameter aw_L.
• On pin en_b which is on the top of the instance, the new wire name is assigned "i1_en_b_all". Where "i1" is the instance name, "en_b" is the port name and "_all" is the value of the parameter aw_A. Actually, the aw variable should take the value of aw_T first. However, in this case, the aw_T parameter is not defined. As a result, it takes the value of aw_A (_all) instead.
• Similar to pin en_b, the new wire segment created for the floating pins en and Y are i1_en_all and i1_Y_all.

The Verdi system provides a batch mode utility fsdbreport to write out specific signal transitions in a specific time range. However, sometimes it would be more convenient to generate this report from the GUI - since you can view and select signals you would like to report from the intuitive waveform view interactively. Starting from Verdi 2010.04 onward, a GUI command File > Report Selected Signals is provided in the waveform view. You can select desired signals in the waveform view, and then invoke the command to open the form as shown below to generate an ASCII report for signal transitions.

With this command the Verdi system generates an ASCII report for your selected signals within the specified time range. All options in the fsdbreport utility can also be specified in this form in the Options text field.

 The Verdi system provides a way to only load partial designs from a compiled library using the command line option -impConf. To use this option, you can create a configuration file which includes one or more scopes to be loaded. For example, the configuration file content could contain the following:

[Partial_load]
System.i_cpu

If you create a configuration file like above and import it with the command line option -impConf, you will find that only the scope System.i_cpu and all its sub-scopes has been loaded. Other scopes in this case will be treated and marked as undefined objects in the Verdi system.

Starting from Verdi 2010.04 onward, the configuration file has been extended to let you specify sub-scopes to exclude or modules under the partial loaded scope. For example you can specify a configuration file as below:

[Partial_load]
System.i_cpu
[Exclude]
CCU

After you load the design with -impConf option, you will find that the CCU module has been marked as undefined even though it's under the partial loaded scope. The following figure demonstrates how it will be shown in the Verdi system.

Note that both instance names and module names are supported for excluding - if a module name was specified then all its instantiations will be treated as undefined.

SpringSoft would like to thank all of those that participated in our annual Customer Satisfaction Survey. The survey was conducted by a third-party research firm for objective measurement. The identities of the survey participants have not been shared with SpringSoft.

As you'll see from the results, our overall web site (external and support) had a relatively low satisfaction rating.  We have currently put plans in place to upgrade our external and support web site to be more user friendly.

See results here.

Have you been paying attention to the new and exciting EDA solutions that SpringSoft has been announcing in 2010?

Read the news by clicking here.

You can also download and see all the news here.

By now, you may know that the IPL (Interoperable PDK Libraries) Alliance has released the first interoperable PCell standard. What you may not know is that SpringSoft is a founding member of the IPL. The release of the Standard is the culmination of more than two years of effort by the founders and members of the IPL. You can see and download this new Standard on the IPL web site at www.iplnow.com. The download includes a generic 90nm interoperable process design kit (iPDK), reference design, sample PyCell^TM library (including PyCell source code), User's Guide, and a Developer's Guide that includes information about how to create PCells that are interoperable with most major EDA tools running on OpenAccess.

IPL iPDKs are based on the OpenAccess database and API from Silicon Integration Initiative (Si2), the free Ciranova PyCell Studio^TM software/API, and use standard scripting languages such as Tcl and Python that enable advanced PCell functionality and unparalleled interoperability.

Today there are more than 20 IPL members, including founding members AWR, Ciranova, SpringSoft, Synopsys and foundries L-foundry, Tower-Jazz and TSMC. The up to date member list is available on the web site. Companies may join at no cost by applying on the site. Members enjoy access to additional technical details of the Standard.

The IPL Alliance, an industry-wide collaborative effort to create and promote standards for interoperable PDKs was announced in April 2007 with the release of the first interoperable PyCell library. Since that time, this sample library has been downloaded more than 1,000 times, which tells us that we were on the right track. By DAC in 2008, TSMC had joined the IPL and the first multi-vendor interoperable PCell-based design was demonstrated by passing design and layout data back and forth among 8 tools from 5 different EDA vendors. This was done in real time, and without any data translation from a single disk file. At DAC in 2009, TSMC announced the world's first commercial iPDK, a comprehensive interoperable 65nm MS/RF PCell library which uses the IPL technology. Support for the TSMC iPDK was announced by every major EDA vendor including SpringSoft, one of the iPDK validation partners. With the release of IPL Standard 1.0, the same capability is now available to everybody who wants to create or use interoperable PDKs.

The IPL interoperable PyCells are written in the open Python scripting language using the free Ciranova PyCell Studio which includes extensive PCell-specific extensions, an interactive environment for PyCell development and the OpenAccess-compatible API. PyCells can enable stretch handles and autoabut capability and all of the most advanced PCell features. Users tell us that PyCells have significantly fewer lines of code, and execute more quickly than comparable PCells in common use today.

Tools based on OpenAccess, like the SpringSoft Laker Custom Layout System are able to open, read, and modify schematics and layout for IPL-compatible PyCells that are implemented by the tools of other vendors. Changes implemented in one tool will be reflected in the next tool in the flow because the format has been agreed to by all members.

Besides PyCells, the IPL standard includes syntax and methodologies for writing interoperable properties and parameters - often referred to as iCDF (interoperable Component Description Format). iCDF is an interoperable format for a file that describes the parameter names, how they are displayed, which parameters are editable by the user, and the default parameter values for the PyCells. iCDF essentially contains the contents of the form that pops up when a PyCell (layout) or its symbol (schematic) are placed. The forms will look different in different tools, but the values, permissions and naming will be the same because they have been made interoperable.

Callbacks are another essential - previously proprietary - part of PCells. Advanced PCells offer the ability to substitute formulas or functions ("callbacks") for some variables so that necessary relationships between the shapes are maintained. At a simple level, the callbacks can not only control the input of legal values (such as width > 0) but can define what the tools should do if an illegal value is entered in the parameter attribute form: should it be a warning message, should it automatically supply the nearest legal value, or both? In addition, callbacks are used to maintain dependent parameters: In the first example above, when the poly gate width is increased by stretching the OD (diffusion) layer, callbacks maintain the poly endcap dimension; make the change symmetrical to the center of the transistor; and adds additional contacts when enough space is created. Callback function names are usually stored in the CDF but the callbacks themselves, like PCells, are written in the scripting language Tcl with an agreed upon syntax so that they will behave identically in all tools.

The OA-based version of Laker Custom Layout has undergone extensive interoperability testing during the TSMC iPDK development as well as in independent testing among the IPL partners. Comprehensive testing of advanced PyCell, CDF and callback functions was done to "road test" the standard before release.

An interoperable PDK benefits the entire silicon design chain including users, semiconductor companies, foundries and EDA vendors. The standardization of PDKs benefits custom IC designers by removing bottlenecks in multiple-vendor flows and providing access to innovative new tools. iPDKs can reduce PDK development cost and cycle time for foundries and IDMs while providing designers quicker access to new advanced process technologies.

The IPL Standard adds full interoperability, the ability to use TSMC iPDKs and is supported by most OpenAccess-compatible EDA tools. Long-time users of Laker will be pleased to know that the familiar Laker MCell^TM built-in parameterized devices, UDD (User-Defined Device) GUI-driven parameterized devices, Tcl PCells and their related automation features continue to be supported and improved in the OpenAccess-based version of Laker. As always, all Laker parameterized devices are readable in other tools without additional software. In addition, the iPDK PyCells may be mixed and matched with any combination of other Laker devices to optimize your work flow.

In the previous Behavior Analysis flow, the symbol library mode is recommended over the simulation model to get better performance and memory usage. This is because when the Behavior Analysis engine uses the simulation model, it will look into the library cell to get its equation which consumes a large amount of memory, especially in big gate-level designs. However, the simulation model sometimes has to be used, for example, when the liberty file is not complete, or users would like to maintain the exact behavior of simulation model, etc. To resolve the memory usage issue, SpringSoft has implemented a new technology which can speed up the performance and reduce the memory usage when using the simulation model in Behavior Analysis. The basic idea is to convert the HDL simulation model to an internal symbol library which can be used by Behavior Analysis, in this way the Behavior Analysis does not need to look into each library cell but can still get the correct equation, so that the memory usage will be reduced efficiently. To use this mechanism, users need to import the HDL simulation model with the -y or -v options when compiling the design. The mechanism is transparent to users so users do not need to make any change in the Verdi/Siloti systems. This new technology will be released in the upcoming Novas 2010.04 version.

The Essential Signal analysis and dumping flow in the Siloti^TM Visibility Automation System was refined in the Novas 2010.01 release. The purpose of the change is to make the usage smoother. It enables users to dump Essential Signal FSDB files in the full dump environment without having to touch and recompile the design. Also, the output of Essential Signal Analysis is changed from a text file to a binary database (ESDB). The ESDB supports setting most ESA options at simulation run time; therefore, most of the options can be deferred to simulation run time instead of having to rerun ESA (time consuming) whenever the required ESA options are different. The new ESDB and ES dumping flow is considered general beta in Novas 2010.01.

Here is an example showing how to do Essential Signal Analysis and Essential Signal dumping in the enhanced flow:

• To dump essential signals to FSDB (ES dumping), you need to perform Essential Signal Analysis (ESA) on your design. The output of the ESA is an ESDB binary file which contains the essential signals of the design.
• You can perform ESA via using the esa utility or the Siloti system; however, the following environment variable must be set before invoking the Siloti system or the esa utility.

> setenv SILOTI_ESDB 1

• If you use the esa utility to do ESA, then you need to specify the -db option on the esa utility command line to indicate the output should be an ESDB file. For example,

> esa -db es -top top

• Assume your current design contains a $fsdbDumpvars dumping command to dump signals to FSDB file, for example:

//test.v

initial

   begin

        $fsdbDumpfile("dump.fsdb");

        $fsdbDumpvars;

        #12500 $finish;

   end

• And your simulation executable is already linked with the new re-architected dumper (available in 2010, refer to the Linking Novas Files with Simulators and Enabling FSDB Dumping document, <NOVAS_INST_DIR>/doc/linking_dumping.pdf) similar to the following VCS/simv example:

> vcs -full64 +memcbk +cli+3 -debug_all +v2k +vpi +vcsd -LDFLAGS

"-L/$NOVAS_HOME/share/PLI/lib/LINUX64

-L/$NOVAS_HOME/share/PLI/VCS/LINUX64" 

-P $NOVAS_HOME/share/PLI/VCS/LINUX64/novas.tab $NOVAS_HOME/share/PLI/VCS/LINUX64/pli.a +vcs+lic+wait test.v

• Now, to do ES dumping, you can simply specify the ESDB file on the simulator command line without modifying code. Because the design is untouched for ES dumping, there is no need to regenerate the simulator executable simv. That is, the same simv can be used for both full and ES dumping.
• To dump ESD FSDB by specifying ESDB in simulator command line, use the following:

> simv +fsdb+esdb="es" +fsdb+esoptions="-xsignalfile my.list

-xscope top"

• Where +fsdb+esdb=esdb_filename is used to specify the ESDB file name and +fsdb+esoptions="option_list" (optional) is used to specify ESA options.
• When the +fsdb+esdb=esdb_filename option is specified, the Novas dumper would dump the set of essential signals that can achieve the same visibility (after Data Expansion) as the union of all $fsdbDumpvars commands in design. For instance, if there is one $fsdbDumpvars command $fsdbDumpvars(2, system) specified in design, the ES dump would result in dumping the minimal set of Essential Signals that can be expanded to achieve full visibility over 2 levels of scopes under the system scope.
• You can load the resulting ESD FSDB file that contains dumping of essential signals only to the Siloti system to debug. The Siloti system would perform Data Expansion on demand on the Essential Signals as if you have full visibility.

The Certitude^TM Functional Qualification System identifies holes and weaknesses in the verification environment that can let RTL bugs slip through the process undetected. With the release of version 2010.04 in April, Verdi^TM users will be able to leverage their existing Verdi environment to minimize Certitude setup effort and analyze the results of functional qualification quickly and efficiently using Verdi's powerful debug features.

To ease the setup process, the Verdi system provides a new utility called setupCer that operates on the compiled Knowledge Database (KDB) libraries and generates templates for the files needed to run Certitude. The template files identify the relevant HDL files and locations and ensure that they are listed in the proper order for correct compilation. Users can modify the templates to mark the HDL files to be qualified and specify additional session-specific information prior to running Certitude.

Links from Certitude's Report Viewer to the Verdi system enable quick and efficient analysis of the functional qualification results in Verdi's familiar and powerful environment. The integration provides push-button access to waveforms for the original RTL and the RTL with fault inserted and displays the highlighted nTrace source code view with fault location information (Figure 1).

Figure 1: Links from Certitude Report Viewer to Verdi for analysis and debug

After jumping to the Verdi environment, users have access to Verdi's powerful debug features to analyze the results and determine the fix (new checker, additional test scenario, etc) required to improve the verification environment.

The Verdi system supports searching signals by Regular Expression. This capability provides a flexible way for users to find signals of interest quickly. The following steps provide an example for how to use this capability.

1.     In nWave (with a loaded FSDB file), invoke the command Signal -> Get Signals to open the Get Signals form.

2.     In the Get Signals form, click the Options button to open the Options setting form, turn on the Search Signals with Regular Expression option and then press Close.

3.     In this example we would like to find a signal whose name starts from letter a to letter d, let's input ^[a-d] in the Find Signal field then press Enter.

4.     As you can see in the following figure, signals whose names start from a to d will be listed. Changing the scope in the left pane will list signals with the same Regular Expression in other scopes.

The Verdi system provides the Add Full Bus command in nWave to automatically add the entire bus when a bit signal is selected. The following steps and figure demonstrates the usage of this command:

1.     Assuming there is a one bit signal data[2] in nWave, and it belongs to the 8-bit bus data[7:0].

2.     Select this one bit signal in nWave, click the right-mouse-button and invoke the command Bus Operations -> Add Full Bus.  Note the command will not appear unless you have selected a bus member.

3.     The entire 8-bit bus data[7:0] (which the selected signal belongs to) will be automatically added under the selected signal.

A Unified FSDB Dumper for Cadence IUS, Synopsys VCS and Mentor Graphics ModelSim Simulators

A new breed of FSDB dumper is provided since Novas 2009.10. Different from previous FSDB dumpers, the new dumper is unified to support a broader range of simulators and versions. Currently, the new dumper can support Cadence IUS 6.2, Synopsys VCS 2006.06, Mentor Graphics ModelSim 6.4b and their later versions.

The new unified dumper is scheduled to replace the old dumpers in the year 2010. However, the old dumpers are still available for a considerable amount of time. For detailed usage on the new dumper, refer to the Linking Novas Files with Simulators and Enabling FSDB Dumping document (<NOVAS_INST_DIR>/doc/linking_dumping.pdf). And, for detailed usage on the old dumper, refer to the Linking Novas Files with Simulators and Enabling FSDB Dumping document (<NOVAS_INST_DIR>/doc/linking_dumping_pre-2010.01.pdf).

Here is a short example showing how to load the unified Novas FSDB dumper using the Synopsys VCS simulator:

l   Set shared library search path.

> setenv LD_LIBRARY_PATH \

${NOVAS_INST_DIR}/share/PLI/lib/${PLATFORM}: \

...

l   Compile the design and run the simulation command.

> vcs -line -debug_all -P ${NOVAS_INST_DIR}/share/PLI/VCS/${PLATFORM}/novas.tab ${NOVAS_INST_DIR}/share/PLI/VCS/${PLATFORM}/pli.a

> simv

Note that some of the FSDB dumping commands will also become obsolete in the new unified FSDB dumper.  The details about what is changing for the dump commands can be found in the "A Unified FSDB Dumper" application note (KB#8192-18) located in the knowledge base of the SpringSoft support website.

On occasions where the default black background is too dark, it is possible to change to a white background color.  To do this, follow these steps:

1. Find your Laker install directory. For example: /tools/laker.

2. Under the subdirectory: etc/, find the file: leoDsgWnd.fm.

3. Modify the content of file: /tools/laker/etc/leoDsgWnd.fm

    Find the definition as follows and change the line highlighted in red:

PanedWindow WORKINGWINDOW {

        orientation = vertical;

        Form WORKINGPANEWND {

           DrawingAreaContainer ALLDRAWINGAREA {

              attachLeft = "Form 0";

              attachTop = "Form 0";

              attachRight = "Form 0";

              attachBottom = "Form 0";

              Frame CONTEXTWND {

                  manage = FALSE;

                  DrawingArea DRAWINGAREAWND1 {

                       background = black;

                       width = 100;

                       height = 100;

                       scrollbar = float;

                       traverse = false;

                    }

               }

              DrawingArea SCHDRAWINGAREAWND_F {

                      manage = FALSE;

                      traverse = false;

                      background = black;

                      width = 535;

                      height = 180;

                      attachRight = "Form 0";

                      attachBottom = "Form 0";

                      scrollbar = both;

                }

               DrawingArea DRAWINGAREAWND {

                      background = white;    <-- Change the color here from black to white.

                      width = 640;

                      height = 640;

                      attachLeft = "Form 0";

                      attachTop = "Form 0";

                      attachRight = "Form 0";

                      attachBottom = "Form 0";

                      scrollbar = float;

After changing the background color, you may also need to change the color for other features e.g. the select object color is white by default.

NOTE: When you upgrade the Laker version, the modified leoDsgWnd.fm file cannot be reused. You will need to make the modifications again in the latest Laker installation.

In the Verdi^TM Automated Debug System, the Property Tools window can manage, visualize, and debug assertions and their results. In addition to visualizing assertion results dumped by simulators, the Verdi system provides a unique Assertion Evaluation Engine which can check assertions against a signal level FSDB trace file for the design.

Starting from the Verdi 2009.10 version, this debugging methodology has been enhanced. The Verdi system provides the On-Demand Property/Sequence Evaluation capability - users can dump assertion signals only (without dumping the associated data such as properties, sequences, and local variables of the assertions) to an FSDB file, then the Verdi system evaluates the associated data on-demand so the users will have smaller assertion dumping results but still keep full debugging capability.

Below is a typical scenario which demonstrates how to use the re-designed Property Tools window to browse assertion results and debug assertion failures:

1. First, load the FSDB file which contains assertions into the Verdi system, and invoke the Tools > Property Tools command to open the Property Tools window, which can manage assertions, visualize results, and debug assertions.

2. You can add assertions/properties to the Property Tools window by dragging and dropping scope nodes from the nTrace window or an assertion/property from the nTrace/nWave windows. Or you can click the Get Properties  icon in the Property Tools window to invoke the Get Properties form to select the properties to add to the window. Or you can drag and drop a selected assertion/property from the Property Statistics tab or the Property Details section on the right pane to add the assertion/property to the Tree/Table tabs of the left pane.

3. To delete the properties shown in the Tree/Table Tabs, simply select the nodes/rows to delete and click Delete key on the keyboard.

4. The Property Detail section is for browsing the failures, successes and incomplete data details of the selected assertions/properties. There are a couple of ways to add assertions to the Property Detail section. You can double-click on an assertion on the Tree/Table tab or with one assertion selected on Tree/Table tab, select the Add to Details command on the right mouse button menu.

5. Also, you can double-click on a grid cell on the FSDB Statistic tab to add the related assertions/properties to the Property Details section.

6. After browsing the success, failure and incomplete records for an assertion/property in the Property Details section, you can then identify a record, usually a failure record, to analyze and debug further.

To analyze the assertion failure data, click the Analyze Property icon  or select the Analyze Property command on the right mouse button menu. Then the analyzed results for the assertion data are shown in the Analyzer tab with the time, signal and expression value annotated. You can see easily which expression is contributing to the failure.

7. You can also make use of the nWave window to display the analyzed results of the assertion data. The analyzed data can be automatically shown in the nWave window if you turn on the Add Evaluated Signals to nWave Automatically and Add Signals with Assertion Expression Grouping options on the Analyzer tab in the Assertion Options form. The form can be invoked from View > Options menu in the Property Tools window.