Abstract

Traditionally, The RTL simulations are followed by Gate level simulations (GLS) in order to catch issues that may not exist at the RTL level. Such issues maybe to check for structures such as DFT logic that was added afterwards. However, another major reason for running GLS, is to check the validity of timing constraints as specified in the SDC file. Even though, there are rule based static constraints verification tools, they cannot validate the intention of the timing values as specified by the designers.

Since, setting of the GLS is very arduous and iterative task, it is often limited on validating only a subset of tests.

This paper presents an assertion based verification (ABV) methodology that uses the System Verilog Assertions (SVAs) to validate the timing constraints specified in the SDC file.

Background

Typically, the RTL is simulated to ensure functional correctness. The timing associated with the design is captured in SDC format independent of the RTL functionality. The two aspects of the design, i.e., the functionality and the timing only align much later in the design cycle when SDF annotated GLS is performed.

After the RTL is synthesized to Gates, Logical Equivalency Checking (LEC) is performed between the two to ensure that the Gates functionality matches that of the RTL. The timing of the Gates netlist is validated through Static Timing Analysis (STA) tools.

One would assume that with the combination of LEC and STA, the need for GLS is not necessary. Unfortunately, this is not the case. There are many situations where GLS can catch issues that STA or LEC tools are not able to report. Among others, the main areas why GLS is performed are:

1. STA tools are dependent on correctness of timing constraints in the SDC file. Incorrect constraints can only be caught during GLS.
2. STA tools cannot time the asynchronous Clock Domain Crossing (CDC) paths.
3. Glitches in clocks or data path that cannot be adequately caught by STA tools.
4. X state pessimism or optimism.
5. Timing Intent (independent of design structure) type of false or multicycle path exceptions
6. Logic structure not present in the RTL, for example, DFT structures – Must be validated at Gate level

Advancements in recent technologies have addressed most of these points, For example, the timing constraints can be checked by Excellicon’s ConCert tool. CDC and Glitches can be detected using tools such as Mentor’s Questa. There are also multiple vendors offering solutions that checks for X-state pessimism/optimism.

However, today no EDA solution exists that can validate the timing-intent nature of the timing constraints. The timing-intent refers to the constraints that are independent of the design structure but are based on the designer’s intent. For example, complex clock waveforms defined in the SDC file; or false/multi-cycle paths specified in the SDC file that are not based on logic structure, rather are specified based on designer’s knowledge. Once such example is multicycle paths applied from configuration registers, since the designers knows that the configuration registers will be programmed by the firmware and remain constant after the boot up cycle. Hence, it does not need to be timing for a single cycle and can be multi-cycled for timing relaxation purposes. 

The frontend designers who are responsible for RTL development, concentrate on the design functionality and leave the development of timing constraints with backend engineers. With this disconnect between frontend and backend engineering teams, mistakes can easily creep in, where the timing constraints may not reflect the intended timing specs, especially when the designs now consist of thousands of clocks.

This necessitates the need for GLS to catch these kind of issues. However, one major problem with GLS is that setting up the GLS environment is an extremely tedious task. GLS also suffers from false violations caused by X propagation that must be cleaned up. This is an iterative and time consuming task. Furthermore, GLS is inherently slow and also may suffer from inadequate coverage.

For this reason itself, designers tend to limit the GLS to only a subset of regression test cases and start on GLS activity as early as possible.

Excellicon’s Solution

In order to circumvent these issues and to help simulate the design at an earlier phase of the ASIC cycle (without the need for delay annotation through SDF), Excellicon through its ConCert™ tool, developed an ABV solution that targets the relevant timing constraints and converts them to SVA’s that can be used during simulation

With this method, the timing constraints for constraints such as clock waveforms, timing intent type of false and multicycle paths, clock gating checks and other relevant timing-intent type of constraints are converted to SVA’s. These SVA’s along with the design can be simulated much early on in the design cycle, thus eliminating the need to run GLS.

For simple clock waveforms, the conversion is straightforward, however, in some cases the clock waveforms may be quite complex. For example, if a complex waveform for a clock is being generated through the use of an ICG cell, i.e., the enable of the ICG cell is used to form a complex waveform at the output of the ICG cell. This requires a variety of techniques to represent the clock waveform in the SVA format.

Similarly, for false and multicycle paths, if the SVA’s were generated simply based on the syntax of these timing constraints, it may result in millions of SVA’s. In order to reduce the volume of SVA’s and to prune out redundant ones, the design is analyzed comprehensively. Subsequently, the SVA’s are generated only for the relevant paths that the exceptions are targeting.

This method, greatly reduces the volume of SVA’s which ultimately benefits the simulation run-time.  

Conclusion

Since the need for GLS is essentially to validate the timing against the functionality, we have provided a methodology that combines the functionality and timing early on in the design cycle, thus eliminating (or at least reducing) the need for GLS.

Furthermore, the converted SVA from the Gate SDC’s can be used to for RTL simulation, thus providing even more benefit in terms of simulation run-time.

By: Himanshu Bhatnagar - Excellicon CEO