Xilinx ISE 'feature': forcing a DUT signal

[Evan Lavelle]

Has anyone managed to get a Verilog testbench to force an internal DUT
signal using ISE (9.2i)? This seems to be impossible.

A DUT force has to be, pretty much by definition, hierarchical. If you
try something like

force top.mod.x = y; // or...
assign top.mod.x = y;

you get a message about an unsupported hierachical expression.
Tweaking the assignments eventually gives you the catch-all
unsupported constructs message, with details in #24068 and an
accompanying pdf doc. The suggested work-around - to add new ports to
the DUT - isn't helpful.

The ISE docs claim to support 'procedural continuous assignments', but
this seems to be a rather wide definition of 'supported'.

Thanks -

Evan

 

[Mike Treseler]

Evan Lavelle wrote:

assign top.mod.x = y;

you get a message about an unsupported hierarchical expression.

Hmm.
Is x also declared as a testbench wire?
is
assign top.mod.x = y;
outside of blocks?

-- Mike Treseler

 

[Evan Lavelle]

On Mon, 01 Oct 2007 12:14:50 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

Evan Lavelle wrote:

assign top.mod.x = y;

you get a message about an unsupported hierarchical expression.

Hmm.
Is x also declared as a testbench wire?
is
assign top.mod.x = y;
outside of blocks?

The syntax is valid; (this) assign is a procedural statement which can
only be used on variables (and the test code works on two other sims).
The procedural assign isn't particularly useful; I only mentioned it
because it shows the same problem as the 'force' statement, which *is*
very useful.

X's error message and docs claim that it's the hierarchical reference
on the LHS ('top.mod.x') which is unsupported, but ISE actually has no
problem with hierarchical lvalues. It only appears to be procedural
force/assign which is affected.

It can be pretty hard to write comprehensive testbenches without a
force statement, so I was hoping to find someone who may have a
workaround, short of wiring up extra ports in the DUT.

Evan

 

[Mike Treseler]

Evan Lavelle wrote:

The syntax is valid; (this) assign is a procedural statement which can
only be used on variables (and the test code works on two other sims).
The procedural assign isn't particularly useful; I only mentioned it
because it shows the same problem as the 'force' statement, which *is*
very useful.

I get it. Thanks.

X's error message and docs claim that it's the hierarchical reference
on the LHS ('top.mod.x') which is unsupported, but ISE actually has no
problem with hierarchical lvalues. It only appears to be procedural
force/assign which is affected.

See slide 4 here
http://www.csee.umbc.edu/~plusquel/415/slides/verilog_behav_const.pdf
claims a related Xilinx synthesis limitation.

"A procedural continuous assignment (PCA)
creates a dynamic binding to a register
variable when the statement executes.
It uses "=" as in procedural assignment
with the keyword assign.
WARNING: The Xilinx synthesis engine does not accept this Verilog construct"


-- Mike Treseler