Subject: Re: Mixed-signal nets, Interfaces & Abstract Types
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Oct 11 2001 - 16:18:40 PDT
Some thoughts on using interfaces with mixed-signal
simulation....
Just to recap: the way that mixed signal processes driving
a single net should be handled is by considering the net as
"neutral" interconnect, and just considering the "type"
of the driver for each process, the resolution of the
drivers is then performed in a domain that is sufficiently
accurate to get a "correct" result, and that result is then
propagated to receiving processes. If a driver or receiver
is in a lower accuracy domain (or of a lower accuracy type)
it is converted. I.e. if you mix real-valued piecewise linear
drivers with digital drivers you insert D->A convertors for
the digital drivers, solve in the analog domain, and insert
A->D convertors for any digital processes receiving the
resolved signal value. Signal resolution of this type is
considered "flat" as design hierarchy is not considered, it
also only applies to one single physical wire at a time and
doesn't easily extend to include abstract types.
VHDL(-A) has a problem because it doesn't do "flat" signal
resolution, which is a consequence of allowing type changes
at port boundaries. Resolution is performed by resolving
a driving value at each level of hierarchy and passing it up
to be resolved again until the top level for the net is
reached and the result at the level is then propagated back
down the hierarchy. That approach means that although you
can mix abstract and physical types, in general you cannot
tell that conservative (analog) nets in different leaves of
a hierachy are actually the same net and consequently
should be a single node in the analog solver - so you are
not guaranteed to get the right result even if you manage
to get accurate A/D convertors inserted at the port
boundaries.
[The last Verilog-AMS LRM has some port-bound stuff which
is a continual source of semantic problems.]
If my understanding of V++ Interfaces is correct, they circumvent
the problem of mixing abstract data types with physical types
that arises with VHDL by moving the type conversion into the
interface(/modport) and not making it part of the hierarchy -
i.e. instances connect to a modport of a single instance of an
interface, rather than having individual translations between
each other as in VHDL.
If we want to drive an abstract type value into an interface
that also has (say) an analog wire "bundle" view, it will be
necessary to have the value translated into an array of
physical type values that can be pushed through the D/A
conversion process described above. To make this obvious in
the interface it may be necessary to add some syntax to
allow the views to be declared distinct e.g.:
interface my_bus;
view logic; // physical
wire [63:0] data64;
endview
view fpu; // abstract
double fp_num;
endview
- items not declared in a "view" would be common to all
views. A C 'union' style construct would do equally well.
The user would provide tasks/routines to convert from
'fpu' to 'logic' as required. In the case where the logic
view has some analog components attached (e.g. loading
caps), a write to the fpu view would be translated into
an array of 64 2-level logic values which will get fed
through D->As to be solved in the analog domain, and
converted back to 2-level logic for processes reading
the 'logic' view, and then to double for processes using
the 'fpu' view.
Note: the approach is similar to VHDL's resolution scheme
but using a "type" hierarchy rather than the design
hierarchy.
Regards,
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Thu Oct 11 2001 - 16:19:56 PDT