Subject: RE: net_resolution
From: Ian Wilson (imw@antrim.com)
Date: Fri Feb 23 2001 - 15:54:55 PST
My comments below. I'll rework the example and mail the updated version.
--ian
> >
>
> -- is it not 'continuous assignment' or 'assignment' - not sure where
> the
> 'quasi' came from.
My mistake. LRM uses "continuous assignment".
>
> -- 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.
Agree, it would be clearer to use the 'net declaration' form.
>
> 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?
The key here is whether the net has multiple digital drivers. My note puts
undue emphasis on the port declaration - I'll fix that. I am of the opinion
that a connect module candidate should only match if the port declaration
is correct (thus inout would be required in this case).
>
> -- 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?
If a driver is introduced as a result of connect module insertion, that
driver should not appear in the list returned by the driver access functions.
>
> 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 was from the original example. I just fixed the errors.
>
> 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'.
>
I thought of getting rid of most of this to make it a simpler illustration
of driver access function usage. What do you guys think? Keep the original
variable-impedance driver idea or simplify the example to focus on driver/
receiver segregation etc?
<ends>
This archive was generated by hypermail 2b28 : Fri Feb 23 2001 - 15:50:57 PST