Answers Database

M1.3, M1.4 NGD2VER: "Stuck at 0" and Stuck at "X" problems in Verilog simulation


Record #3149

Product Family:  Software

Product Line:  Merged Core

Problem Title:
M1.3, M1.4 NGD2VER: "Stuck at 0" and Stuck at "X" problems in Verilog
simulation



Problem Description:
Keywords: gsr, global, reset, tristate, gr, stuck

Urgency: standard

General Description:
Problems have been observed in Verilog timing simulation
netlists generated by NGD2VER in which the design outputs
in timing simulation appear to be stuck at X or "0",
even though the simulation is run at a clock frequency that is
well within what TRCE estimates the design can run at.



Solution 1:

In some cases, the source of the problem may be associated
with  the new M1.3 methodology for supporting global reset and
tristate.  This new methodology makes use of `ifdef directives
to define Verilog macros named "GSR_SIGNAL" for 4KE/4KEX/4KXL
global set/reset, "GR_SIGNAL" for 3K and 5K global reset, and
"GTS_SIGNAL" for 4K and 5K global tristate.

The `ifdef conditional tests in the *design netlist* check
whether these macros have been defined, while the actual
definition of these Verilog macros using `define statements
is done in the *testbench template* generated by NGD2VER.

If you base your testbench file on the testbench
template generated by NGD2VER and specify the design netlist before the testbenc
h file when invoking Verilog-XL, the
definitions of the GSR_SIGNAL, GRSIGNAL, and GTS_SIGNAL macros
are not be known to the Verilog compiler.  As a result, the
conditional `ifdef test on these macros fails, and the action
specified by the `else is performed instead.

In many cases, this causes a disconnect with the net which
the user specifies for controlling global reset or tristate.

To work around this, you must specify the testbench file
first (as documented in the Cadence Interface/Tutorial Guide),
or move the `define statements for GSR_SIGNAL, GR_SIGNAL
and/or GTS_SIGNAL to the design.v file.




End of Record #3149