Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Dynamic type in declarative context

1,399 views
Skip to first unread message

Ronit Edri

unread,
Feb 20, 2011, 6:46:39 AM2/20/11
to
Hi
I defined an interface in system verilog and added a wire which I
assigned to it RTL signals.
In the sv testbench, I force it in a loop, I do HOT ONE to the wire
which is 48 bits size.
when I run the test I get the following error:

Error-[DTIDCIL] Dynamic type in declarative context
/home/redri/msp5_dv/direct/msp/tests/gpio_in.sv, 23
"force msp5_env_top.u_gpio_in_if.gpio = (1 << i);"
Argument: i
Automatic variable may not be used in declarative context.
the wire is the "gpio"
thanks for any help

Jonathan Bromley

unread,
Feb 20, 2011, 10:14:52 AM2/20/11
to

Your first and most important error is to use "force" as
a way to generate testbench stimulus. The primary use
of "force" is to override a specific signal to work around
a bug, or to introduce an artificial error in situations
where you can't do that with regular stimulus.

Bear in mind that "force" effectively creates a new
process driving the forced signal. After your force
statement is activated, it remains active until
cancelled, observing changes on all its inputs and
responding to those changes by updating its forced
value. It can't do that if there is an automatic
variable in the expression (1<< i).

The fact that you need to use "force" here, because
your signal "gpio" is a wire, suggests that you have
got your test harness badly organized. Find a way to
drive "gpio" from a reg (remember you can always set
that reg to 'z if you need to switch off the drive).
Then you can simply write to that reg with a normal
procedural statement, no force required.

One obvious approach would be to add this code to
your interface:

reg [47:0] gpio_stimulus = 'z; // undriven at start
assign gpio = gpio_stimulus;

and then replace your "force" with this...

msp5_env_top.u_gpio_in_if.gpio_stimulus = (1 << i);

There are probably better architectures, but without
seeing more of your problem I can't guess what they
should be.
--
Jonathan Bromley

0 new messages