( ESNUG 382 Item 8 ) -------------------------------------------- [11/15/01]
From: Stefan Griebel <sgriebel@audiologic.cirrus.com>
Subject: I Hate How Verilog-XL Screws Around With My Negative Timing Checks
Hi John -
This Verilog-XL "bug" shows up when back-annotating an SDF file with negative
hold times and using the +neg_tchk option. Verilog should use the negative
hold times correctly, but instead will set the negative values to zero
without issuing an error or warning.
The problem is caused when an SDF file has 2 or more timing checks w/ respect
to an event edge, (like posedge clock) and the violation regions created by
these timing checks do not overlap each other. This condition causes
the negative timing check algorithm not to converge. Verilog-XL forces
convergence by setting negative values in the timing check to zero.
Verilog-XL sets one value to zero and then checks to see if the timing
converged. The process is repeated until the timing converges or all the
negative values are set to zero. Example:
....4....3....2....1....0....1....2....3
_______________
clock ________________________/
Positive and negative timing checks in SDF file
....4....3....2....1....0....1....2....3
___________________________________
d(pos) ____/____/
___________________
d(neg) \____\____________________
(TIMINGCHECK
(SETUPHOLD (posedge D) (posedge CK)
(4.000:4.000:4.000)(-3.000:-3.000:-3.000))
(SETUPHOLD (negedge D) (posedge CK)
(2.000:2.000:2.000)(-1.000:-1.000:-1.000))
)
Positive and negative timing checks in Verilog-XL after convergence. Both
negative hold values set to zero.
....4....3....2....1....0....1....2....3
___________________________________
d(pos) ____/___________________/
________________________
d(neg) \_________\_______________
After annotation:
$setuphold(posedge CK, posedge D, 4, 0);
$setuphold(posedge CK, posedge D, 2, 0);
Test data changes at (0.5)
....4....3....2....1....0....1....2....3
______________________ _________________
d ______________________X_________________
The SDF file has a violation region of (4, -3) for the positive edge of (D)
and (2, -1) for the negative violation region. After convergence both
negative hold values get set to zero, (4, 0) for positive edge and (2, 0)
for negative edge.
During simulation the (D) input is changed (0.5) time units before the
postive edge of (CK). This should be a good time, but a setup time
violation is issued.
Solutions to bypass this problem (from Cadence):
1). You have to make the violation regions overlap a little bit. This
way Verilog-XL will converge. The SDF file has to be edited by hand
to change the values in the timing check so that the violation regions
overlap. Scripts can be created to help automate to the editing
process. (We do not have a script for this purpose.) You can avoid
this non-convergence by hand-editing the timing checks in the HDL or
in the SDF file to create some overlap.
2). If you use NC-Verilog from the LDV3.3 or LDV3.2 (with latest ISR),
NC-Verilog has two new options address this non-convergence issue.
a. -EXTEND_TCHECK_Data_limit <percent_relaxation>
b. -EXTEND_TCHECK_Reference_limit <percent_relaxation>
The -extend_tcheck_data_limit option changes the hold or recovery
limit in the timing checks so that the violation regions overlap by
at least two units of simulation precision.
The -extend_tcheck_reference_limit option changes the setup or removal
limit in the timing checks so that the violation regions overlap by at
least two units of simulation precision.
The percent_relaxation argument in both is the maximum percentage
increase allowed in the timing violation window to achieve the overlap.
Both of these solutions offered by Cadence only bypass the problem, possibly
making it worse; they do not actually fix it! These solutions change the
actual timing characterization of the particular cell in question rather than
going to the root of the problem which is that Verilog-XL can't handle
non-overlapping violation regions. When I inquired as to whether this
"convergence" issue would be fixed, I was told, "No. That is how Verilog-XL
will continue to work". Has anyone else run into this before, and possibly
come up with a better solution? Are there any opinions as to how major of
an issue this really is? Any feedback would be greatly appreciated, but
I'm also happy just to share my findings.
- Stefan Griebel
Cirrus Logic
|
|
