[ibis-macro] Re: New developments regarding PWL sources and B-element
- From: "Mike LaBonte (milabont)" <milabont@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 9 Sep 2005 16:10:28 -0400
I don't get a good feeling about this. My sense is that users will want
to specify only the file name and model name, and will be put off if we
appear to be proposing something that is difficult to explain. My
opinion is that it's not worth the price if we add ugliness so that we
can retain the elegance of a single buffer definition. And how would
this translate to HSPICE, for example, if the buffer instantiation does
not have a file name and model name?
That said, I can't quite picture what it would look like. And please
correct me if I appear to be making false assumptions.
Mike
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, September 09, 2005 2:46 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] New developments regarding PWL sources and
B-element
Importance: High
Hello all,
As I am working on implementing the B-element equivalent in our library,
I have found a few things which gives us an option to possibly get away
from the problem of hard coded file names and its consequence of having
to duplicate the module for each of its instance. What I learnt can
also be applied to the PWL controlled sources.
The reason I am writing to you about this is because I would like to get
some feedback on this in order to know how I should proceed with
implementing these building blocks. I think the solution is much
better, but not necessarily perfectly neat.
Here is the scoop. Parameters can be arrays. Their size can be defined
at the time the module is instantiated using another parameter. For
example:
module an_example(a, b);
parameter integer n = 2 from [2:inf);
parameter real datatable[1:n] = {1.0, 2.0}; ...
...
This will declare a parameter for the array size, and the array
parameter, which as a default is 2 elements long, containing 1.0 and
2.0. When I instantiate this module, I can put anything into "n"
between 2 and inf, and I can pass a corresponding number of real values
into the "datatable" array. I am also told that the size of the array
parameter can be different for each instance of the module.
This means that we can pass the IV and Vt tables of an IBIS model into
the IBIS_B building block as parameters at the time they are
instantiated without having to make duplicates of it for every instance.
Good news!
The bad news is that the IV and Vt tables of the buffer will have to be
passed into the IBIS_B module at the time it is instantiated.
So the calling line could become zillions of lines long instead of just
one. There may be a workaround using the `define capabilities, which
could be tucked away into include files using the .include statements,
and then the IBIS_B calling statement would just use the `datatablename
syntax for the IV and Vt tables. This would clean up the netlist
significantly, but requires that the netlist writer (=macro model
writer) is familiar with the Verilog-A(MS) `define (which is very simple
by the way).
The same exact technique could also be applied to the data tables of PWL
sources.
The other part of the bad news is that Verilog-A(MS) does not have any
decent file I/O capabilities with which I could code some sort of a file
parsing mechanism to make this any nicer. This means that The data
tables I mentioned above will have to be strictly the IV and Vt tables
from the IBIS file, and nothing more. This shouldn't be a big deal,
because even the earlier hard coded idea would have had to have the same
type of data, I am just mentioning it here because the more I am working
with Verilog-A(MS), the more I am starting to hate it... The pressure
is building up in me...
VHDL-AMS is a language with many more capabilities, it is a lot more
mature and better defined, even though it is uglier because it is a
strongly typed language. I am already sensing that we could do a lot
more with it even for this simple library.
Anyway, back to the main question. Please give me some feedback whether
you like this approach of passing the IV and Vt tables into the IBIS_B
and PWL controlled source building blocks on the instantiation line. I
am leaning towards coding it up this way simply because using this
method the user of the library will not need to mess with making copies
for each instance of the IBIS_B building block (and the PWL controlled
sources).
Thanks,
Arpad
====================================================================
---------------------------------------------------------------------
IBIS Macro website: http://www.sisoft.com/ibis-macro IBIS Macro
archives: //www.freelists.org/archives/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website: http://www.sisoft.com/ibis-macro
IBIS Macro archives: //www.freelists.org/archives/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
