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