Post-simulation is to simulate the gate-level netlist after synthesis/placement and routing. Compared with the pre-simulation to simulate the rtl code to find out the functional defects, the post-simulation mainly checks the timing problems; compared with the ideal situation Under the rtl simulation (functional simulation, pre-simulation), the post-simulation consumes more time, and the difficulty of debugging is greatly enhanced when walking in cells with poor readability. Generally, when we do post-simulation, it often means The time until tapeout is very urgent
Post imitation steps:
1. Use the timing calculation tool to generate timing information and store it in the SDF file
2. Add the notiming_check list file to the simulation tool options
3. Back-annotate the SDF file into the design: add the statement initial $sdf_annotate to the tb_top file
SDF file
The SDF (Standard Delay Format) file preserves the device delay and line delay information during the layout and routing process. Based on this, the timing of the entire path can be calculated during path timing analysis, and then the timing constraints can be judged. Know if timing requirements are met. The SDF file contains timing information for all cells in the design, which provides timing information for the simulated gate-level netlist
The SDF file includes timing information for each unit in the design, and the basic timing data consists of the following parts:
(1) IOPATH delay
(2) INTERCONNECT delay
(3) SETUP timing check
(4) HOLD timing check
When using VCS to read the SDF file, the delay value will be "back-annotated" into the design, that is, adding or changing the delay value in the source file. There are two ways to back-annotate the SDF file, one as elaboration The option specified, the other is to call the system function $sdf_annotate in the bench to complete;
(1) As an option for elaboration
-sdfmin|typ|max: instance_name :file.sdf
如vcs-sdf min: top.i_test: test.sdf
(2) Use the $sdf_annotate system task to perform anti-annotation, and its usage format is as follows:
$sdf_annotate (“sdf_file”[, “module_instance”] [,“sdf_configfile”][,“sdf_logfile”][,“mtm_spec”] [,“scale_factors”][,“scale_type”]);
in:
"sdf_file": specify the path of the SDF file
"module_instance": Specify the scope of the anti-mark design (scope)
"sdf_configfile": specify the SDF configuration file, generally default
"sdf_logfile": Specifies the SDF log file where VCS saves error and warnings messages. You can also use the +sdfverbose runtime option to print all backtick messages
"mtm_spec": Specifies the delay type "MINIMUM(min)", "TYPICAL(typ)" or "MAXIMUM(max)", "TOOL_CONTROL(default)".
"scale_factors": Specify the scaling factors of min:typ:max respectively, the default is "1.0:1.0:1.0"
"scale_type": Specifies the source of the delay value before scaling, "FROM_TYPICAL", "FROM_MIMINUM", "FROM_MAXIMUM" and "FROM_MTM" (default).
In addition to sdf_file must be given here, other parameters can use default values, such as:
$sdf_annotate(“test.sdf”);
To explain the parameter scale_type, the timing information in the sdf file will consist of 3 numbers, which correspond to the delays in the three cases of minimum, typical, and maximum respectively (of course, sometimes there are only minimum and maximum cases, so the typical delay is not just omit)
Possible values of scale_type are:
FROM_MINIMUX
selects the mininum timing in the SDF file. The so-called min refers to the minimum delay of the combinational logic. This sdf focuses on the check of the hold time
FROM_TYPICAL
selects the typical timing in the SDF file
FROM_MAXIMUM
selects the maximum timing in the SDF file. The so-called max refers to the maximum delay of the combinational logic. This sdf focuses on the check of the setup time
FROM_MTM
system default
After the back mark is completed, you can see this sentence from the log:
Annotating SDF file "***.sdf" ... Done
tfile file
When simulating after running, some paths do not need to do timing check, such as the first DFF of the synchronizer, because usually asynchronous signals are synchronized, and the first DFF of the synchronizer usually may have a setup or hold violation, as follows:
At this time, you need to write the path that does not need to be checked in the tfile file to tell the emulator. The above example can be realized in the following two ways:
Method 1:
ncverilog -input aaa.tcheck ...
In the aaa.tcheck file:
tcheck -off u_top.syna_d1_reg
tcheck -off u_top.synb_d1_reg
...
run
(If no run is added, ncsim will automatically stop after executing all tcheck instructions)
Method 2:
ncverilog -tfile aaa.tcheck ...
In the aaa.tcheck file:
PATH u_top.syna_d1_reg -tcheck
PATH u_top.synb_d1_reg -tcheck
For the two compilers VCS and XRUN, there are some differences in the writing of the file and the simulation parameters:
| translater | Solution steps |
| NC of cadence | 1. Add parameters for NC simulation -tfile notimingcheck.tfile。 2. Edit the notimingcheck.tfile file PATH tb.dut.u_dff2_reg –tcheck |
| synopsys的vcs | 1. Add parameters for vcs simulation +optconfigfile+notimingcheck.cfg。 2. Edit the notimingcheck.cfg file instance {tb.dut.u_dff2_reg} {noTiming}; |
In addition, you can also specify the object through module and tree, but it can only be the module name and cannot have a hierarchy.
If there are multiple asynchronous D flip-flops, write multiple lines, and write one constraint per line
Some debugging experience of timing violations
1. Check whether it is an asynchronous path
If it is an asynchronous path, it should be added to the notiming_check list.
2. Check whether the input of VCS (including netlist and SDF file) is correct
Not only VCS, but as long as it is a process related to tools, if an exception occurs, we need to ensure that the input information of the tool is accurate before continuing to debug. Then the input of imitation is mainly netlist and SDF file. For these two files, we need to check whether their paths are correct, and whether the versions of the netlist and SDF files correspond.
3. Check whether the clock frequency of the post-imitation clock is consistent with STA
It is often seen in non-standard processes that the frequency of post-simulation does not match the frequency of STA analysis. Therefore, when encountering a violation, we must first check the clock frequency after imitation. If the frequency is higher than the frequency analyzed by STA, then it is reasonable for the setup to have problems.
4. Check the STA report to see if the timing is clean
The premise that there is no problem with the same clock frequency as the STA is that the STA has been timing clean. But in reality, especially in MPW projects, STA may ignore some violations due to the tight project schedule. For example, the system clock is 200M, but there is a small violation, and the precision of the clock can be fine-tuned, so it is possible to let it go. Therefore, we need to confirm this with the STA owner, and adjust the clock frequency of the imitation according to the actual situation.
5. Compare whether the delay of the path in STA is consistent with the delay of the waveform
After the previous steps are confirmed to be correct, it is necessary to consider whether there is something wrong in the process of spitting out the SDF, such as changing the derate value due to a hand injury. The method to check this is also very simple. Please directly ask the STA owner to report the corresponding path, and then compare it with the delay of the imitation waveform. At this time, it is very likely that it cannot be matched. So the next thing is the STA owner's business, we just need to wait for the SDF to be updated
6. Registers without reset
Under normal circumstances, the registers in the design must have a reset terminal. However, don’t forget that post-imitation includes not only the designed netlist, but also various models, such as analog models. These models may have register signals without initial values and resets for various reasons. These registers often cause us a lot of trouble when post-imitation
reg rg_a, rg_b;
always @(posedge clk) begin
rg_b <= rg_a;
end
Solution:
We assign the initial value to the register by force-release in testbench, because the variable is of type reg, so as long as the initial value is assigned, it will always maintain the value entered by force when no other conditions are triggered.
7. The high-impedance signal of the undriven pad port is transmitted to the design internally.
There are many io ports of tri-state gates on the top layer of the general design. When we instantiate the design in the bench, we must pay attention to these tri-state gates. In addition to being able to use wire-type signals for connection, it is also necessary to consider pull-up/pull-down without driving.
If you ignore the pull-up/pull-down, you will generally not encounter problems during functional simulation, but when the state of 'z is passed into the design after imitation, a mine will be quietly laid, and the output of a certain gate will become x, and Eventually the simulation stops.
The solution is very simple. When connecting the design in the bench, add a pull-up/pull-down signal to the signal connected to the tri-state gate.
wire scl;
dut i_dut(.scl(scl));
pullup(scl);
What if the pullup is already occupied elsewhere? It doesn't matter, there are different strengths of pullup, choose a weak strength, so that even if there are pullups/pullups in other places, it will not be affected.
The above pull-up statement plus strength level, namely: pullup (weak1) p0 (scl)
8. Signal inversion
When we use the netlist for post-simulation, the signal in the DUT driven or monitored in the testbench is likely to be an inverted signal. Especially the signal on the port, the name has not changed, and the thing called rstb behaves like rst. It's not that the designers were careless, but tools like DC and ICC.
What is particularly hateful is that a certain bit of a multi-bit data signal is quietly reversed. When I accidentally compare it with the previous imitation for debugging, even the location of the data is not accurate~ It often makes the verification engineer dumb.