[ibis-macro] Re: Some block netlist formats

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "IBIS Macro" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 25 Jun 2008 15:52:07 -0700

I need to correct an omission in my previous message.
The following:
 
 
In general, this can be summarized as:
 
ArbitraryInstanceName : entity  LibraryName.ElementName(ViewOfThatElement)
 
 
should have been written as:
 
 
In general, this can be summarized as:
 
ArbitraryInstanceName : entity  LibraryName.ElementName(ViewOfThatElement)
                        generic map (ParameterList)  port map (NodeList)
 
 
I apologize if this caused any confusion...
 
Arpad
============================================


________________________________

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Muranyi, Arpad
Sent: Wednesday, June 25, 2008 11:55 AM
To: IBIS Macro
Subject: [ibis-macro] Re: Some block netlist formats


Hello Everyone,
 
 
I promised yesterday in the IBIS-ATM meeting that I would
send some VHDL-AMS and Verilog-A(MS) netlisting examples
to this list for our discussion.
 
 
The first example here is in VHDL-AMS and the graphical
representation of the circuit looks like this:
 
i.e. there is an ideal pulse with a series resistor, driving
a transmission line which is loaded by an inductor and a
"black box" (receiver model).  In VHDL-AMS this drawing is
written as follows:
 
 
   R1 : entity StatEye_Library.IBIS_R(IDEAL)
      generic map ( Rval => 100.0 )
      port map ( p => INPUT,
                 n => Tin );
 
   T1 : entity StatEye_Library.IBIS_T(IDEAL)
      generic map ( Z0 => 100.0,
                    TD =>  0.5e-9 )
      port map ( N1   => Tin,
                 REF1 => REF,
                 N2   => Tout,
                 REF2 => REF );
 
   L1 : entity StatEye_Library.IBIS_L(IDEAL)
      generic map ( Lval  => 10.0e-9,
                    I0    =>  0.0,
                    Scale =>  1.0 )
      port map ( p => Tout,
                 n => Rcv );
 
   C1 : entity StatEye_Library.C_StatEye(StatEye_on)
      generic map ( CVAL         => 1.0E-12,
                    WfmLenght    => 3.0e-9,
                    UnitInterval => 200.0e-12,
                    Resolution   => 1.0e-3,
                    TimeStep     => 1.0e-12,
                    BERvalues    => (0.0, 0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 
0.35, 0.4, 0.45, 0.5),
                    WriteFile    => true)
      port map ( p        => Rcv,
                 n        => REF);
 
 
In general, this can be summarized as:
 
ArbitraryInstanceName : entity  LibraryName.ElementName(ViewOfThatElement)
 
Also, in VHDL-AMS "generic" stands for parameters, "port"
stands for node as we know it from SPICE.  Please note that
there are several different ways to write this code which
may depend on personal style.  For example, the lists of
"generics" (= parameters) and "ports" (= nodes) do not have
to be formatted in columns, they could span across a single
line if so desired.  Also, the generic and port lists can
use a syntax "by name" as shown above, or a syntax "by order"
which may take up less space, and obviously, the parameter
values do not have to be literals, the can also be other
generics (= parameter names) or expressions using the
combination of the two.
 
The above code is part of my presentation I gave at the IBIS
Summit at DesignCon 2007:
http://www.vhdl.org/pub/ibis/summits/feb07/muranyi.pdf
http://www.vhdl.org/pub/ibis/summits/feb07/StatEye_project.zip
 
 
The next example is a netlist to instantiate a resistor
in Verilog-A(MS).  I am only giving a single line of code
here for brevity, but obviously there is no limit for
how many lines of such code can be put into a netlist.
 
IBIS_R #(.Rval(R_val), .Scale(Scale_val)) R1 (Node1, Node2);
 
which can be summarized in general as:
<http://www.bmas-conf.org/2007/2-6_presentation.pdf> 
 
ElementName  #(ParameterList)  ArbitraryInstanceName  (NodeList);
 
 
Note that what I called "element" here is officially called
"module" in Verilog-A(MS).  Also, I keep using the parentheses
for "(MS)" because the above syntax is the same regardless
whether we use the full mixed signal "(MS)" Verilog-AMS
language or its analog subset Verilog-A only.  As in the
case of VHDL-AMS, there is a certain amount of freedom in
this syntax as well regarding the parameters passed by order
or by name, line breaks, etc...
 
 
As you can see, these netlist syntax of the *-AMS languages
are very similar to the SPICE netlist syntax, and I would
think they are easily translated from one to another.  One
major difference I can see is in what I called "element name".
The element name is not necessarily predefined in these
languages as they are in SPICE (unless we are talking about
the SPICE compatibility in Verilog-AMS as described in Annex E
of the LRM [Section E.2.2.3]):
http://www.eda.org/verilog-ams/htmlpages/public-docs/lrm/2.2/AMS-LRM-2-2.pdf
 
 
The elements (modules) are usually described in libraries,
some of which may be standardized by standards bodies, such
as IEEE, but most of them are probably user written today.
Thus, we need to be careful about which library we refer to
in case the same exact element (module) name exists in
multiple libraries.  So we will need to have a certain
library in mind if/when we write these netlists.
 
 
The other reason I mentioned this is because I heard
conversations regarding the SPICE alphabet problem, that
there are not enough letters for all element types that
one would like to have in SPICE.  The *-AMS netlisting
syntax does not suffer from that problem, and extensibility
is not limited as it is in SPICE.
 
 
A small netlist example (test bench) written to test each 
element of the Macro Model Library I wrote earlier for IBIS-ATM
(then called Macromodeling Library Task Group) in the two *-AMS
languages can be found on our web site:
http://www.vhdl.org/pub/ibis/macromodel_wip/element_lib/VHDL-AMS_element_library_SMASH_test.zip
http://www.vhdl.org/pub/ibis/macromodel_wip/element_lib/Verilog-A_element_library_HSPICE_test.zip
(Beware the annotation of the Verilog version is not finished
so there may be a lot of incorrect or misleading comments in
there, but the functions are all working correctly, they were
tested in HSPICE-Verilog-A).
 
 
I would like to express my position on this topic once again,
that I think we would be a lot wiser making use of if nothing
else, at least the netlisting portion of these existing
(standardized) *-AMS languages rather than spending a lot
of time and energy on developing yet another netlist syntax
of our own.
 
 
Of course, going onward, the next question will be content
related (as Michael Mirmak already alluded to it in the
meeting yesterday):  What will be inside these elements?
But I will defer that topic to a later time...
 
 
Thanks,
 
Arpad
================================================================
 
 
________________________________

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Walter Katz
Sent: Tuesday, June 24, 2008 6:07 PM
To: IBIS Macro
Subject: [ibis-macro] Some block netlist formats


All,
 
Here are a couple of different block oriented netlist formats. One is based on 
the parameter tree implemented as part of AMI. The other is "Spice Like". I 
then demonstrated how a new model type could be added just as easily to either 
one.
 
Walter
 
 
Parameter Tree Format
 
(Block R1     
(Type R)
(Nodes 7 17)
(Value 1.7K) 
)
(Block C1
(Type C)
(Nodes U7.3 0)
(Corner 1.3p 2.5p .7p) 
)
(Block T7
(Type Tline)
(Nodes 12 27)
(Z0 '50*(1.+Age/20)')
(Td (Range 200p 150p 300p)) 
)
(Block W7
(Type Wline)
(Nodes 12 27 18 54)
(Length Length)
(File '50Ohm.rlgc')
(Model '50Ohm') 
)
(Block s7
(Type Touchstone)
(Nodes 12 27 18 54)
(File '50Ohm.s4p')
)
(Block X12
(Type subckt)
(Nodes 12 2)
(File 'xyz.mod')
(subckt xyz)
)
 
 
 
 
 
Spice Like Format
 
R1 7 17 R=1.7k
C1 U7.3 0 c='(Corner 1.3p 2.5p .7p)'
T7 12 27 Z0='50*(1.+Age/20)') Td='(Range 200p 150p 300p)'
W7 12 27 18 54 Len=Length File='50Ohm.rlgc' Model='50Ohm'
s7 12 27 18 54 File='50Ohm.s4p'
X12 12 27 subckt=xyz file='xyz.mod'
 
 
 
Adding a new model type (Physical Electrical Description of a "trace"). The DC 
Resistance of a trace is determined from its cross section area (Width*Height), 
Length and conductivity (Rho). The frequency dependence of the resistance is 
determined from formulae of the perimeter (2*Width+2*Thickness), Dielectric 
Constant, Length, Roughness and frequency.
 
How it can be handled as part of the parameter tree:
 
(Block U12
(Type physical_electricsl)
(Nodes 12 17)
(Er (Value 4.3)) 
(Len (Value .07)) 
(Rho (Value 5.6e6)) 
(Roughness (Value 1.7)) 
(Width (Value .0004)) 
(Thickness (Value .0001))
)
 
 
How it can be handled Spice Like:
 
U12 12 27 Z0=50 Er=4.3 Len=.07 Rho=5.6e6 Roughness=1.7 Width=.0004 
Thickness=.0001

GIF image

Other related posts: