Subject: Module Overloading for AMS
From: Kevin Cameron (dkc@galaxy.nsc.com)
Date: Mon Jan 14 2002 - 18:52:40 PST
[Conceptual rough outline]
Module (or primitive) overloading would work much the same way as routine
overloading in C++. You would be able to declare any module with multiple
port profiles and different contents (e.g. all digital, all analog, inputs digital
outputs analog, inputs analog and outputs digital, etc.), and different (analog)
disciplines on the same port would be considered distinct too.
At elaboration time all non-overloaded modules would be instantiated first,
then overloaded modules would be instantiated dependent on input disciplines
matching, e.g. if you have an all-digital version and an all-analog version, and
one input pin is analog, you instantiate the all-analog version. Outputs would then
be re-resolved and any promotions to analog from digital would cause the a
dependent overloaded module to be replaced by a "more analog" one. Eventually
all port instances should match the wire types as closely as possible.
Overloaded modules would be expected to be the most efficient implementation
for the particular configuration of analog and digital inputs and outputs and would
obviate A/D insertion as the funcionality would be in-lined (the working assumption
is that the multiple models would be created by automatic characterization of cells
and would not normally be created by a manual process).
Driver look-ahead for analog ramp generation becomes less of an issue because
there is more slack time available across a cell which is synchonizing an input
with an output than there is in an auto-inserted D2A (which has no slack and
requires the look-ahead to work properly because the input and output are the
same wire). Also, if properly constructed, the cells can drive their (digital) outputs
with enough delay that auto-inserted D2As get the look-ahead they need.
While the number of library cells and the complexity of elaboration goes up with
this scheme, the number of components in the final simulated net list should be
the smaller as the number of auto-inserted A/D convertors is less, and accuracy
should be better for well charaterized cells.
It could be used purely for primitive definition if the only overloadable modules are
"external" or some kind of representation stop.
Note: "derived" disciplines have a hierarchy that lets you determine that a discipline
is more or less closely related to another when examining overloaded inputs.
I can expand on this if anyone thinks it would be useful.
Regards,
Kev.
PS: For the case Jon mentioned of a resistor being a valid component for distinct base
disciplines we probably want a "void" discipline and a "typeof" keyword (as in GNU C)
which would let you do:
external module resistor (a,b);
void a; // take type from connection
typeof(a) b;
// behavior defined by simulator
endmodule
This archive was generated by hypermail 2b28 : Mon Jan 14 2002 - 18:57:15 PST