Subject: RE: net_resolution
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Feb 26 2001 - 15:10:05 PST
Jon,
> From owner-verilog-ams@eda.org Mon Feb 26 09:15:41 2001
>
....
>
> Without a doubt this is the most complex part of the language to understand and teach.
> I myself would favor consistency over most simplification. If we want to make it easier
> for the users I say we make the default mode (user / modeler needs to do nothing) to
> pass the digital values directly to the receivers. Then we provide the mechanisms for
> users / modeler to do more accurate modeling if they please. This seems to line up
> more with other features in the language that we have done.
I would prefer a consistent simplification :-)
As I said elsewhere, CMs, driver/receiver segregation and net_resolution etc. are just
a signal-resolution function. You take all the drivers, resolve them at a level of
representation that handles them all (without loss of information) and convert
back to the view required by the receivers.
The above should be true for any mix of simulation environments, not just Verilog-AMS.
Disciplines and/or domain give you the view to use for the drivers and receivers,
"split" & "merge" tell you whether to group drivers and receivers; merge is an optimization
for speed.
Drivers and receivers are processes, ports are only part of the mechanism by which
they communicate, and a convenient place to hang type information (which should really
be in the processes). Considering nets as having hierarchical segments of 'analog' or
'digital' adds unnecessary confusion, i.e. 'NetA' in your example is neither analog or
digital, those attributes belong to the attached processes.
If a net in an elaborated circuit has only "digital" processes accessing it then
resolution is performed in that domain. If there is any analog contribution (an analog
driver) to the net it is resolved in the "analog" domain.
The tricky case is when a net has digital drivers and only analog receivers (no
contributions), it can be resolved in the analog domain in order to derive the analog
receiver view and converted back to give a resolved digital value, but logically the
digital view should be unaltered by the analog receivers and should therefore be the same
as that resolved in the pure digital case, so you could do a purely digital resolution
in parallel and skip putting in an A2D. If the CM inserted to get the analog view
includes contributions to the net being resolved you would probably have to assume that
the assumption is violated and insert A2Ds. Also, if the implicated A2D CM rules are for
"split" rather than "merge" it would be advisable to insert A2Ds.
Kev.
...
>
> In fact, what happens if I have the following:
>
> output (logic) inout (logic)
> --------O----------------------------O------------------------
> | NetA
> | inout (electrical)
> ------------------O-----------------------
>
> If NetA is logic then the CM is connected across the electrical port. Driver receiver
> segregation is done an effects both digital ports (one inout, one output), correct?
>
> If NetA is electrical then I have two cases:
>
> a) Merged: Since these are likely to be covered by different connect rules
> this should give you the same results as Split.
>
> b) Split: In this case you get two CM's, one across each digital port. Is driver-receiver
> segregation still done on NetA? Since I have two CM's writing to the
> electrical net both are considered drivers while one is also a receiver sometimes. What
> happens if another digital block is added that only has an input port? What happens in the
> case of merged.
>
> If I understand correctly the above stuff why would changing my inout digital port to an
> input port change the behavioral of driver-receiver segregation?
>
....
Back to top ^
This archive was generated by hypermail 2b28 : Mon Feb 26 2001 - 15:29:59 PST