>From: "Daniel Mlynek" <daniel.mlynek@aldec.com.pl>
>In attached code signal sig_read is driven by both procedural assign via
>virtual interface and continous assign via port connection
>Should it be error in simulator (variables cannot be driven by mixture of
>procedural and continuous assignmenr)?
I don't think there is any practical way of enforcing the multiple driver
rule in the general case when virtual interfaces are used for the writes.
>if not then How should be the value of sig_read in such case resolved?
I think the value will be somewhat unpredictable. I would expect the
value from a procedural assignment to be overwritten by the continuous
assignment at some time ranging from immediately, to the next time the
output of the continuous assignment actually changes. One intermediate
possibility would be that it is overwritten when an input to the
continuous assignment changes, regardless of whether that affects its
output value. Exactly when a continuous assignment evaluates and when
it updates its output are not defined, because they don't matter if the
rules are followed.
>In below code value sig_read should be always == z or it should be == 1 at
>the eof???
I would say that this is undefined. Since the input to the continuous
assignment (the output reg read) is not changed by its second assignment
to z, I would expect that the continuous assignment would not evaluate.
But I don't think the LRM forbids it.
In addition to the question of when a continuous assignment evaluates,
you are changing read and sig_read in the same time slice (time 1), so
this example also has a race condition that could affect the result.
>Is this issue known?
I think I have noticed it before.
Gord filed an issue related to longest static prefixes when virtual
interfaces are involved, which might include this issue.
> Does improvements described in "Is There a Future for
>SystemVerilog Interfaces" resolve this issue?
I doubt it.
Steven Sharp | Architect | Cadence
P: 508.459.1436 M: 774.535.4149 www.cadence.com
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon May 10 08:15:07 2010
This archive was generated by hypermail 2.1.8 : Mon May 10 2010 - 08:17:49 PDT