Subject: Re: net_resolution
From: Dan FitzPatrick (dkf@synopsys.com)
Date: Fri Feb 23 2001 - 13:58:33 PST
Hi,
Sorry about stepping in kinda late, but was traveling this
week.
Going along with the apparent consensus to remove the mystical
net_resolution operator, have some questions regarding some
apparent pixie dust...
Ian Wilson wrote:
>
> After more discussion, we agree with the proposal to eliminate the
> mystical net_resolution operator.
>
> Here's a proposal for how to overhaul the relevant sections. I have
> reworked the connect module example, removing the syntax errors and
> moving the collection of driver information into the analog block so there
> are no problems with unsynchronized access to shared variables as in the
> original.
>
> --ian
>
> 8.10.5
> - change title from "net_resolution" to "Driver-Receiver Access in Connect Modules"
> - replace body by:
> When a connect module containing a digital inout port is added to a net,
> the drivers and receivers of that net become decoupled. The outputs of the
> drivers are combined using standard Verilog-D resolution mechanisms. This
> resolved value may be accessed in the connect module by reading the inout
> port. The receivers can be driven by writing to the inout port. Although
> the same identifier is used for the input and output directions of the port,
> the effect is the same as if there were distinct, unidirectional, ports.
>
> No default processing is applied within a connect module. The output side of
> the digital port must be driven explicitly with a quasi-continuous assignment
> or equivalent (see following section for an example).
>
-- is it not 'continuous assignment' or 'assignment' - not sure where
the
'quasi' came from.
-- it would seem that the explicit assignment, either by:
assign d = out;
or,
inout d = out;
in the example seems a bit bothersome. i believe they are equivalent
for
this example, but when you use the second form, it doesn't necessarily
feel
comfortable.
from what i remember of past discussions, the input/output/inout
qualifiers
were fairly irrelevant in verilog - if that is the case, can we make the
distinction between inout and input/output qualifiers for the
driver-receiver
segragation?
-- if the proposal is ok wrt to the above question, does the assign d =
out
statement introduce another driver for 'd'? if so, what effect does it
have
on the driver access functions? do we need another class of driver?
i have omitted the rest for brevity, but the following seems to be a bit
odd from a modeling/simulation perspective:
>
> // analog drivers, configured according to active drivers & levels
> V(pull_up) <+ 1/((1/r1)*num_ones + (1/roff)) * I(pull_up);
> V(pull_dn) <+ 1/((1/r0)*num_zeros +(1/roff)) * I(pull_dn);
> V(power) <+ supply;
this seems to assume that there is only one 'electrical rail' - or you
would have more one 'V(power) <+ supply' branch for each connect module
instance, or we can guarantee that the condition 'V(power) + V(pull_up)
+
V(pull_dn) = 0'.
--Dan FitzPatrick | Voice: (650) 584-4700 | Fax: (650) 584-1368
This archive was generated by hypermail 2b28 : Fri Feb 23 2001 - 13:59:12 PST