Answers Database
VERILOG-XL: Buffer output does not follow transitions on its input (transport and inertial delays)
Record #648
Product Family: Software
Product Line: Cadence
Product Part: Verilog-XL
Problem Title:
VERILOG-XL: Buffer output does not follow transitions on its input (transport and inertial
delays)
Problem Description:
Urgency: Standard
General Description:
clock buffer's output does not follow transitions on its input
during simulation. The buffer output ends up being stuck
at 0 or stuck at 1.
This is usually due to the user trying to clock the design at
a higher rate than allowed, based on the delay between the
I/O pin and the clock buffer output.
Verilog-XL runs in "pulse swallowing mode" by default, which
means that it will simulate distributed delays as *inertial
delays* unless told to do otherwise. With an inertial delay,
a delaying element does not pass a pulse through if its
duration is shorter than the element's delay to its output.
On the other hand, an element with *transport delay*
functionality *does* pass pulses of shorter duration than the
element's delay.
Solution 1:
To force Verilog-XL to enable transport delay functionality:
+transport_path_delays
Enables transport delay functionality and pulse control for
module path delays.
+transport_int_delays
This option enables transport delay functionality and pulse
control for inter-connect delay.
+multisource_int_delay
Enables transport delay functionality and pulse control for
interconnect delays plus unique source-load delays for multi-
source nets.
For pulse rejection, you may also need to specify these
additional pulse limit options:
+pulse_e/n
Example:
+pulse_e/0 sets the module output path to e
(error state) and lets the
module path output pulse pass
through if the pulse width
exceeds 0 time units)
+pulse_r/m (sets the module output path to e
(error state) and lets the
module path output pulse pass
through if the pulse width
exceeds 0 time units)
Also in Verilog-XL v2.5, interconnect delays are controlled
with the following plus options on the command line:
+pulse_int_e/n
+pulse_int_r/m
You can determine whether routing and component delays are
the cause of the problem by using XDelay to run a static
timing analysis on the problem path to check the delay of the
buffer input signal against the delay through the buffer.
End of Record #648 - Last Modified: 10/14/99 15:40 |
