Using Formality for RTL-to-Gate in LSI Logics FlexStream Design Flow

Chrystian Roy Jeremy Sewall

LSI Logic Corporation of Canada Kanata, Ontario croy@lsil.com jsewall@lsil.com Copyright 1999 by LSI Logic Corporation of Canada. All rights reserved

Abstract
For large or complex System-on-a-Chip designs, which often consist of over one million gates, full chip gate-level simulation is becoming increasingly time consuming and verication coverage is steadily diminishing. For certain large designs, formal verication techniques can be used to supplement simulation to verify the functional correctness of the designs and, like static timing analysis tools, can validate circuits using analytical methods that are rapid and exhaustive. Synopsys Formality tool is the rst formal equivalence checking tool supported in LSI Logic's FlexStream design ow. As a rst step, the tool was qualied for gate-to-gate verication. This was accomplished in August 1998. The second step, currently ongoing, is qualication for RTLto-gate. This paper will describe procedures and recommendations for using Formality for RTL-to-gate equivalence checking. Workarounds for common problems that were found during the qualication process will be discussed. The RTL signoff of a ip chip design will be used to illustrate the use of Formality from RTL to tape out.

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

1.0 Introduction
LSI Logic is currently in the process of qualifying Synopsys Formality for RTL-to-gate applications in our FlexStream 2.0 design ow. This formal verication tool is qualied for gate-to-gate applications since the release of FlexStream 1.0. After evaluating the equivalence checkers on the market today, Formality was found to be the tool that would offer us the best advantage in most of our scenarios. These included synthesis for our CoreWare library and standard products programs and in the RTL signoff of a customer design. For CoreWare, thorough verication of datapath elements is an especially good candidate for formal verication. The ongoing qualication of Formality for RTL-to-gate consists of these 4 steps: product assurance, methodology assurance, libraries, and documentation. This process is made easier by the excellent relationship that LSI Logic has with Synopsys. Our active participation in beta testing provides us with an opportunity to give our input concerning new features. Their responsiveness as regards to issues that we discover has also been beyond reproach. Note that the meaning of "qualication" as applied to Formality is different from the signoff qualication of PrimeTime. For Formality, qualication means that it is a product that we recommend (but do not require) and for which support (training, application note, etc.) is available. The next 2 sections describe in details procedures and recommendations for using Formality for RTL-to-gate. Some advanced commands for gate-to-gate that were not in our SNUG San Jose '99 paper will also be shown. Following will be an extensive description of the RTL signoff of a ip chip design and how Formality was used to verify that synthesis and other transforms in our ow did not change its functionality. Issues still outstanding (as of this writing in mid-July '99) are in the last section.

2.0 RTL-to-gate
RTL-to-gate equivalence checking can be used to verify that a netlist produced by a synthesis tool does in fact implement what was described in the RTL. It is also quite useful for checking that ECOs and other transformations that were performed did not change the intended functionality. RTL-to-gate equivalence checking is, in general, more difcult than gate-to-gate equivalence checking. Name-matching can become problematic and debugging is usually much harder. Two important features for a RTL-to-gate equivalence checker are its ability to deal with most issues automatically in a transparent way and its completeness in providing easy ways for users to work around a problem when it cannot deal with it on its own. The set_inv_push command and the verication_inversion_push variable are useful in cases where inverters have been pushed through sequential elements. In gure 1, the verication of the improved design will fail on both registers if this command is not used on the rst register or if the variable is not set. Another related command, set_parameter -retimed, is used in cases where Design Compiler was asked to move the sequential elements in order to balance a pipeline.

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

datapath.
D Q D Q

FIGURE 1. Example showing necessity of set_inv_push command.

Soft macros, as shown in gure 2, are sometimes used when inverters have been pushed through sequential elements. This can cause name-matching problems since an extra level of hierarchy has been added.
D Q

FIGURE 2. Using a soft-coded macro to replace a technology cell.

The ungroup command in Formality can be very useful in those cases because it simply removes that additional level of hierarchy. One must be careful to use the -simple_names option, especially with Verilog. If you do not use it, the names of the ungrouped modules will be escaped and will contain the '/' character. This can create problems since Formality uses '/' as a hierarchy separator. The user then has to remember to escape all these names with the '\' character. This can be a major pain, especially since it prevents you from feeding the output of a Formality command to another one. The -simple_names option should also be used when running the ungroup command in Design Compiler, as recommended in Synopsys' chip synthesis workshop. Note that the ungroup command should only be used when appropriate as it can make name matching more difcult. Formality provides three other commands for name-matching problems. The rst, rename_object, would be useful for changing escaped names into regular names. The 2 others are set_compare_rule and set_compare_point. These commands are used less frequently than before since Formality v1998.12 and later has improved name-matching algorithms.

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

An offbeat solution to name-matching problems was required once on a design where, for some reason, Formality would not match 3 inputs to 11 logic cones. Every single command and variable related to name-matching was tried to no avail. Our quick-and-dirty solution was to run verications on the 11 failing compare points 8 times, each run with a different set of constants on the 3 unmatched inputs (2^3 = 8 possible combinations). This simili-ATPG algorithm allowed us to quickly prove that those 11 failing compare points were in fact correct. The TCL script used is provided in the appendix. An area of concern for us is the strange (when you do not know about it) optimization of the propagation of constants in Design Compiler. Presumably to save area, DC will tie wires that go between modules if they are driven constant as shown gure 3. Except for a slight increase in run time and memory usage, this is not an issue when a top-down verication is run. It does create problems in Formality when a bottom-up verication methodology is used.

FIGURE 3. DC doesnt preserve subdesign interfaces by default.

The recommended way to do a bottom-up verication is to use the remove_design command after a sub-module is successfully veried. This will save memory and make the verication of the next level run faster than if the set_equivalence command was used on the sub-modules. The remove_design command removes the design information from the database. That sub-module becomes a black-box that is assumed equivalent (if it is a black-box in both designs). Formality still knows the direction of the ports to the sub-module if the design was linked from the top. It guesses conservatively if it does not know the port directions. The set_equivalence command simply replaces the implementation design by the reference design. Verication of the logic inside will still occur. This is why remove_design is faster and requires less memory. The problem with remove_design when constants have been optimized is that Formality does not know what comes out of the output of that black-box. It sees a wire tied to a constant in the implementation design and not in the reference design. Any logic cone driven by this wire will then fail. This problem can be avoided by setting the compile_preserve_subdesign_interfaces variable in Design Compiler to tell it not to optimize the propagation of constants. This might cause a slight increase in the reported area in DC. The other workaround at this time is to use set_equivalence, not an optimal solution for memory usage and run time but one that does work.

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

3.0 Gate-to-gate
Our previous paper for SNUG San Jose '99 (available on the SNUG web site) described how to use Formality for gate-to-gate equivalence checking in LSI Logic's FlexStream design ow. Scan, JTAG, and BCT insertions and IPO were discussed in details. This section deals with some advanced commands useful for other gate-to-gate applications. Hierarchy changes sometimes do occur. This can create some major name-matching problems in Formality. The command that sounds like the best bet for name-matching problems, set_compare_rule, is currently totally useless when the relative level of hierarchy has changed. The other ways around are the set_compare_point command (but you must enter each compare point manually) or the ungroup command (great if an extra level of hierarchy is the only difference between the reference and the implementation). We recently had a design in which, not only was an extra level of hierarchy was added, but the names of thousands of registers were changed slightly as well. These 2 problems, in combination, caused us a lot of grief. The ultimate solution was to use ungroup on the extra level of hierarchy, set_compare_rule on some of the name changes, and set_compare_point on the rest. A few iterations were needed to get everything right. We would run a verication and then use the report_unmatched_inputs command to spit out a list of matching problems still remaining. We would then run a Perl script on those to get the next set of set_compare_point commands. Fuzzy name-matching (name_match_allow_subset_match variable) was also used. This was a really atypical case since we use Formality in a push button approach most of the time at LSI Logic. We have found Formality to be of great value in cases when we are doing a technology migration. Sometimes cells in older technologies are not in the more recent ones. The way around is usually to create soft macros to recreate those old ones. Formality can prove that those soft macros are equivalent (or not) to the old cells. The ungroup command is used to remove the soft macro wrapper before verication. This makes for easier name-matching. We recently had a case where the designer had used a different naming convention on the ports of a soft macro around a RAM. This was preventing us from running the verication at the top level since Formality does not allow users to declare 2 modules equivalent if the number of ports and their directions or if their names do not match. The solution was to use the rename_object command to rename those ports. We could then declare the 2 RAMs equivalent. The 3 lines script also used the Formality nd_port command and the TCL string toupper command. As of you have probably noted by now, name-matching can be difcult in some situations and innovative ways around those problems sometimes have to be invented.

4.0 Case Study

The case study to which we refer in this paper is a 460,000 gate G10p (0.35 micron) ip chip ASIC. Approximately 50% of the gates exist as CoreWare, and there are over 30 on-chip memories. LSI Logic was responsible for all ASIC implementation tasks, starting from RTL. This included RTL synthesis, DFT insertion and vector generation, static timing analysis, layout, and functional verication of the gate level netlist. In essence, LSI Logics customer handed off RTL, and LSI delivered prototypes. This can be a very efcient and fast way to get a working chip. The

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

main advantage is that it allows the designers to spend their time worrying about design and verication and not implementation. This particular customer decided that the whole implementation task was best left to LSI Logic. During the design cycle, RTL was delivered to LSI logic at several stages. Each time a RTL release was delivered, LSI Logic would develop and enhance scripts for RTL-to-gate verication and other tasks. Each time a new issue was uncovered, a workaround or ow change had to be incorporated. We will discuss some of the issues encountered. The rst verication of RTL-to-gates that was attempted was aborted before completion once we realized that the netlist (inadvertently) contained scan ip-ops. Design Compiler was using the TI (Test Input) pin on those ip-ops to implement the functional design. The problem was related to ip-op selection from the technology library during synthesis. A slight synthesis script change was required to narrow the scope of ip-op selection. This resulted in an improved design and simpler verication. An interesting thing happened during some initial synthesis passes, which formal verication revealed. A ip-op was being instantiated in the RTL, and subsequently not used. Thus, the synthesis tools would optimize the design and remove the useless op. When RTL-to-gate verication was performed, the removed ip-op was discovered as an unmatched compare point. While this is not a serious issue, it was unexpected. The nal version of the RTL had no unused ip-ops. The synthesis strategy required an initial bottom-up compile, followed by reoptimization from the top down. However, the lowest level of module used for compilation was not necessarily a leaf level design module. By default, the synthesis tools (Synopsys Design Compiler) wouldnt preserve the subdesign interfaces. DC propagated constants to lower level modules whenever possible. While this doesnt cause a problem with design functionality, it can cause problems if formal verication is performed bottom-up. It is not a problem for a top-down verication. Refer to gure 4. From the gure, you can see that bottom-up verication will fail since the subdesign interfaces of A are now tied to VSS. This issue could actually pose as a problem if the gate level version of module B was reused in a different design, where no constants should be applied to a port. This issue was overcome by modifying the synthesis constraints to set the compile_preserve_subdesign_interfaces switch on, as discussed in section 2.0. The switch change was recommended by the Synopsys DC support staff.

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

A B D C

A B D C

FIGURE 4. Constant Propagation Issue

In section 2.0, we described how to deal with the case where inverters are pushed through ipops. This issue arose during verication of the case study BIST logic. The verication_inversion_push Formality variable was set, and the set_inv_push command was also used to overcome the problem. In this case, the problem occurred due to the fact that DC couldnt select an appropriate ip-op from the technology library, which would match what was requested in the RTL code. That is, a ip-op did not exist in the technology library which directly satised the demands of the RTL code. Several workarounds for this issue were possible, and we elected to generate a soft-coded ip-op which satised the requirements of the RTL. The soft-coded ip-ops were hand instantiated in the design, replacing the ops which DC had selected. The reason for replacing the ops was that DC had instantiated positive edged ops with inverters on the clocks rather than use true negative edged ops as was requested. Since we had generated soft-coded ip-ops, an additional level of hierarchy was added to the design. This caused problems during verication, when Formality was attempting to match compare points. To overcome the problem, we used DC to atten the soft-coded cells. This then lead to another issue which was described in section 2.0, where ungrouping should be performed with the -simple_names switch to avoid name matching problems in Formality. We also used the rename_object functionality in Formality to help it match up the ip-op names. Finally we had a complete ow and set of scripts which could be used to quickly verify RTL versus gates, whenever changes to the RTL (or gates) were made. The extensive preparation paid off, since verication of nal RTL versus the initially compiled nal gates required only 55 minutes of run-time. The total number of gates formally veried against RTL was approximately 200,000. Memory usage was 615 MB, which was well within tolerable limits. Note that the RTL was veried against the gates as a single block. Later during the design cycle, gate-to-gate formal verication was also used extensively. Verication of the core logic required 17 minutes of CPU run time, and consumed 695 MB of

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

RAM. All benchmark data is from a dual 300 MHz CPU, Sun Ultra 2 with 2 GB of RAM, and is very design dependent of course. The case study design cycle took 6 weeks to go from nal RTL to tape out. A detailed design ow is shown in gure 5. To understand the ow diagram, it is helpful to know how the design was partitioned. All memory BIST logic was generated in RTL, and synthesized separately from the rest of the ASIC. All customer RTL existed in a separately synthesized core module (with several sub-modules). The rest of the design existed as a top level design module, into which the core was instantiated. The top level included I/O buffers, JTAG controller and boundary scan cells, and some other DFT circuitry. As shown in the gure, RTL-to-gate verication was performed on the core-level design. Gate-to-gate verication was conducted on the entire ASIC netlist. Also note that the diagram doesnt show a verication stage for the top level of the design. The top level of the design (excluding the core) was veried by simulation in order to establish a golden version. All subsequent changes to the full chip netlist could then be veried against this reference point. Figure 5 shows several incremental verication points. It also shows a verication point that encompasses all netlist modications, where initially synthesized gates were veried against the nal netlist gates, at the core level. This step is not part of our standard ow at the moment since it is usually unnecessary. In our case, it closed the loop on the verication process, adding condence in the results.

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

Core RTL

BIST RTL

Synthesis

Synthesis

Core Gates

BIST Gates

Scan Insertion

Scanned Core Gates

Top Level Gates

Full Chip Gates

V V
Layout Based Netlist Transformations (Includes scan reorder, timing optimizations, design rule xes, and other netlist tweaks.)

Full Chip Gates

BCT Insertion

Gates + BCT

Final Netlist Touch-ups

Final Netlist

= Formal Verication

FIGURE 5. Case Study Flow Diagram

Although it isnt shown in gure 5, the case study design verication also included extensive static timing analysis using Synopsys PrimeTime. The combination of formal and static timing verication techniques are combined to create a powerful ow for implementing ASICs in a short period of time, with maximum coverage of potential design bugs and problems.

SNUG99 Boston

Formality in LSI Logics FlexStream Design FLow

Gate level formal verication required some setup which was different from the RTL-to-gate verication runs. The additional setup was primarily related to disabling the scan chains, and dealing with the CoreWare modules in the ASIC. Scan chains were disabled by applying constraints which would prevent verication of the scan mode. The functionality of the scan chain was veried by simulation. CoreWare modules were designed independently from the case study ASIC. These CoreWare blocks were not modied for the case study ASIC, and therefore they were eliminated from the formal verication by black-boxing them. The CoreWare modules also had scan ports associated with them, which had to have remove_compare_point commands applied to them in order for verication to succeed. So what did all of this verication achieve? No bugs were found during RTL-to-gate verication. However, two aws were uncovered during gate-to-gate verication. One of the bugs would have been very difcult to locate if simulation based regression tests were all that was relied upon for bug nding. The advantages of formal verication as opposed to regression simulations were revealed when bugs were not only found, but the cause was also quickly located. This saves both simulation time (approximately 2 weeks of simulations on a workstation farm for the case study ASIC), and bug tracing time. Even though regression simulations may catch functional issues, it will usually take quite some time for the designer(s) to locate the precise cause of the problem. At the time of writing, the case study ASIC had been taped out, fabricated, its manufacturing tests completed, and was in use in the customers test environment. No aws have been found in the silicon to date.

5.0 Pending issues, limitations

As part of the qualication, we are currently working with Synopsys to resolve the issues described in this paper. The rst issue is the pushing of inverters through sequential elements. The verication_inversion_push variable only seems to work if all the registers in a module have had their states inverted. We would like Formality to be able to deal with them in a more usertransparent way. Manually setting them using set_inv_push takes some time, especially if the person doing the Formality runs does not know which registers were modied. A few iterations are then necessary. The handling of escaped names with the '/' characters also needs to be improved since special care is currently necessary in dealing with them. The set_compare_rule command should also be modied so that it becomes useful for hierarchy changes. This would make verication of designs with different hierarchies more straightforward. Although it has been greatly improved in the past year, there is still some room for improvement in name-matching in general. On the language side, more support for VHDL '93 would be nice. This applies to Design

SNUG99 Boston

10

Formality in LSI Logics FlexStream Design FLow

Compiler as well. Formality currently supports all the constructs that Design Compiler supports. Support of behavioral constructs is limited. Support for VHDL 93 is planned for the next major release of Formality (estimated Q1 2000). An issue that has been quite difcult to solve in equivalence checking is the verication of large multipliers, especially when they have different architectures. The size of the multipliers that can be veried by Formality has doubled in the last year but there is still a limit as to how large they can be. The workaround is to use simulation to verify large multipliers. This is not an ideal solution. These limitations affect only a small number of designs. For most, Formality can be run quickly and easily.

6.0 Summary
Synopsys Formality will be fully qualied for RTL-to-gate verication in FlexStream 2.0. Formality is currently qualied for gate-to-gate verication in FlexStream 1.0, since August 1998. Our case study has shown the utility of formal verication in its ability to accelerate ASIC implementation, perform exhaustive functional verication, and thereby reduce design cycle time and costs. The case study was not an academic design, but rather a real ASIC which is undergoing eld testing at this time, with no aws found to date.

7.0 Acknowledgments
The authors would like to thank Anwar Ali, Marco Battocletti, Tony Dunn, Yoon Kim, Kurt Scheuermann, Huaiqi Xu, and Ming Zhong who all contributed to this paper in one form or another.

8.0 Trademarks List

FlexStream and CoreWare are registered trademarks of LSI Logic Corporation. All other brand and product names may be trademarks of their respective companies.

9.0 Appendix
Simili-ATPG Algorithm set list_of_compare_points " ... " foreach compare_point $list_of_compare_points { set result 0 for { set i 0 } { $i <= 7 } { incr i } { if {$i == 0} { set_constant rtl:/WORK/MODULE_A/SIGNAL[8] 0

SNUG99 Boston

11

Formality in LSI Logics FlexStream Design FLow

... set_constant gate:/WORK/module_a/signal_8 0 ... } elseif ... ... ;# a different combination of constants } if [verify rtl:/WORK/$compare_point gate:/WORK/$compare_point] { incr result } } remove_constant rtl:/WORK/MODULE_A/SIGNAL[8] ... remove_constant gate:/WORK/module_a/signal[8] ... if {$result == 7} { remove_compare_point rtl:/WORK/$compare_point remove_compare_point gate:/WORK/$compare_point } } verify rtl:/WORK/top gate:/WORK/top

SNUG99 Boston

12

Formality in LSI Logics FlexStream Design FLow