Olivier FAURAX wrote:
> However, I tried to deposit a value on the output pin. As long as the
> input pin value doesn't change, the output pin is stuck, even if clock
> tick should make the output pin value to update.
If I understand you correctly, you are using $deposit, the user
interface, or PLI to deposit a value on a net (not a reg).
> I suspect that this behaviour is due to the fact that ncsim is
> event-oriented : "if inputs don't change, we don't compute output".
>
> How can i force real behaviour, i.e. computation even if the input
> doesn't change ?
I am afraid that "deposit a value on a pin" and "real behavior" are not
compatible concepts :-).
A deposit on a net doesn't correspond to anything real. You have set a
net to a value that does not correspond to the value being driven on
it, and are trying to rely on how long it will remain in that
physically unreal state.
A force can be viewed as something real, like an overpowering driver,
or disconnecting the old drivers and connecting a new driver. A
deposit cannot. The concept of setting the value until the simulator
updates it again has no meaning in a real circuit, or the definition of
the Verilog language, only in a particular simulator implementation.
The point at which the simulator will update that value is undefined by
the language, and could be any time between the deposit and an actual
change to the value driving the net (which is not same as the value on
the net, because you did the deposit). In this case, it is not
updating the value until the value being driven changes, which is very
efficient and predictable behavior (even if it isn't what you
expected). Verilog-XL does the same thing, and I would expect the same
thing from most simulators. But a simulator could update it earlier,
and you would have no valid complaint. If you cause an actual value
change at the driver (which you haven't), then it should be propagated.
Otherwise, nothing is guaranteed.
I would suggest that you avoid using deposit on nets. Perhaps if you
explained what you are trying to accomplish, someone could propose a
better way of doing it.
> PS : thanks to [email protected] for the solution about escaping signal
> names.
You're welcome.