[ibis-macro] [Fwd: Re: Bug found in the Perl script]

  • From: "Paul Fernando" <prfernan@xxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 2 Mar 2006 22:51:33 -0500 (EST)

----------------------------------- Original Message 
Subject: Re: [ibis-macro] Bug found in the Perl script
From:    "Paul Fernando" <prfernan@xxxxxxxx>
Date:    Thu, March 2, 2006 10:42 pm
To:      arpad.muranyi@xxxxxxxxx


Done. Please check the new version (attached) and let me know if its ok.



On Thu, March 2, 2006 1:31 pm, Muranyi, Arpad wrote:
> Paul,
> We found another bug in the Perl script you wrote.
> This happens when we extract data from a model which
> doesn't have a complete set of everything, such as an
> input model.
> For example, when extracting the input buffer's data,
> the last line in the .DAT file will be something like:
> .Vgc_data({-3.30000000E+0, ... 6.60000000E+0}), \
> \
> with an extra ", \" at the end of the last array data
> line and a "\" on the following line.  This causes
> HSPICE to crash.  The correct ending should be at the
> last ")" character, nothing more.
> This will probably require some additional intelligence
> in your program to monitor where the data really ends and
> then stop putting in the commas and line continuation
> characters.  Remember, this whole file is a giant macro
> text in terms of the Verilog-A(MS) language, and it must
> end without a comma or line continuation characters.
> This should only effect the Verilog extractor.
> I have another comment, which is not a bug, but may be worth
> changing.  You give the buffer name to the macro on the
> top.  I wonder whether this is good.  The reason is that
> this way the macro text name is different in every .DAT file
> and consequently the netlist will have to use a different
> data passing name for every instantiation of a buffer model.
> I think it would be more convenient if we fixed this so that
> the macro name would always be the same, and that way people
> writing the netlist would only need to change the file name
> in the `include statement.
> I checked in the LRM, this is not supposed to cause any
> conflicts, because new macro definitions override the
> previous ones, so if multiple buffers are instantiated
> we can just put the `include statement right before the
> next instance an then the new data will replace the
> previous data in the macro text definition of the
> `include statement.  This should work, but as usual
> it would be a good idea to test it.
> So I would like to be able to do this:
>    `include ".\Macro_lib\lab_1_in33v_t.dat"
>    IBIS_INPUT  #(`Data)  B1  (Power, Ground, Pad, Rcv_D);
>    `include ".\Macro_lib\lab_1_in33v_n.dat"
>    IBIS_INPUT  #(`Data)  B2  (Power, Ground, Pad, Rcv_D);
>    `include ".\Macro_lib\lab_1_in33v_x.dat"
>    IBIS_INPUT  #(`Data)  B3  (Power, Ground, Pad, Rcv_D);
> instead of:
>    `include ".\Macro_lib\lab_1_in33v_t.dat"
>    IBIS_INPUT  #(`lab_1_in33v_t)  B1  (Power, Ground, Pad, Rcv_D);
>    `include ".\Macro_lib\lab_1_in33v_n.dat"
>    IBIS_INPUT  #(`lab_1_in33v_n)  B2  (Power, Ground, Pad, Rcv_D);
>    `include ".\Macro_lib\lab_1_in33v_x.dat"
>    IBIS_INPUT  #(`lab_1_in33v_x)  B3  (Power, Ground, Pad, Rcv_D);
> Thanks,
> Arpad
> ===========================================================---------------------------------------------------------------------
> 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:

  • » [ibis-macro] [Fwd: Re: Bug found in the Perl script]