[ibis-macro] New developments regarding PWL sources and B-element

  • From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
  • To: <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 9 Sep 2005 11:46:07 -0700

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

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).


IBIS Macro website:  http://www.sisoft.com/ibis-macro
IBIS Macro archives: http://www.freelists.org/archives/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

Other related posts: