[ibis-macro] Re: IBIS-to-AMS script update
- From: "Paul Fernando" <prfernan@xxxxxxxx>
- To: ibis-macro@xxxxxxxxxxxxx
- Date: Fri, 3 Feb 2006 18:42:38 -0500 (EST)
Arpad,
Other than 4), 6) & 10) everything else should be fixed in this version.
FYI: I updated the file naming scheme to:
<ibisfile>_<modelname>_<corner>.dat for Verilog
<ibisfile>_<modelname>_<corner>.txt for VHDL
(These were the extensions used in the macro libraries)
The <corner> is one of t,n or x (i.e. Typ, miN or maX)
Thanks,
Paul
On Fri, February 3, 2006 3:53 pm, Muranyi, Arpad wrote:
> Paul,
>
> I just found another one. This may be why SMASH doesn't
> converge...
>
> The naming of the Vt vectors is reversed. The voltage
> vector is called T... and the time vector is called V...
>
> Arpad
> =======================================================-----Original
> Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf
> Of Muranyi, Arpad
> Sent: Friday, February 03, 2006 12:37 PM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: IBIS-to-AMS script update
>
> Paul,
>
> Thanks for the fix. Unfortunately I found some
> problems. I ran into these when I was testing
> the VHDL-AMS portion, they may or may not apply
> to the Verilog-AMS portion of the code.
>
> 1) In some places you output characters indicating
> scaling. For now we must have exponential notation.
> I.e. instead of writing 5.0pF, write 5.0e-12. I
> saw this with Vinl also (800.0m instead of 800.0e-3,
> or 0.8), and may be a universal problem.
>
> 2) The Vpc_ref and related parameters are spelled
> incorrectly, there is no underscore after the first V.
> Also, for some reason I got "V_pc_ref t" with the extra
> space t after the parameter name. Please make sure there
> is nothing after any of the parameter names, only a new
> line character of some sort.
>
> 3) The data in the IV tables is repeated about 4
> times for some reason. Must be a bug in your loop
> control.
>
> 4) This may be a more difficult one, but for the Vt
> curves, r1, r2, f1, f2 must be in a specific order,
> actually related to the voltages of Vfixture.
>
> r1 means PU_on
> r2 means PD_off
> f1 means PD_on
> f2 means PU_off
>
> for complementary buffer models where both PU and PD
> exist. This implies that the r1 waveforms must have
> a Vfx that is low (GND), the r2 Vfx must be high (Vcc)
> the f1 Vfx must be high (Vcc) and f2 Vfx must be low
> (GND).
>
> I am not sure how to handle this yet, and whether it
> should be done by your program or not. Part of the
> problem is that the Vfx values may not be rail voltages
> so checking their values must be done carefully.
>
> 5) This is only cosmetics, but the comment above the
> IV tables to indicate the beginning of the IV tables
> is in the wrong place.
>
> 6) Another tricky one, about the IV curve reference
> values. My models need all four ***_ref values. The
> IBIS specification says that we can either use Vpower
> or the reference values. My code doesn't use Vpower.
> We would either add some intelligence to the converter
> to "translate" Vpower into four ***_ref values or I
> would have to add that logic to my model code. I don't
> know yet which way is better. The problem is that there
> are multiple valid combinations of Vpower and the ***_ref
> parameters.
>
> After I made all these changes manually, I was still getting
> convergence errors with SMASH. There may be either more
> problems, or I may have messed up the data by these edits.
> It could also be that SMASH seems to be more sensitive to
> non convergence problems than I would like...
>
> I like the GUI a lot! The one thing I would change is that
> I would not pop up the output file in a text window after it
> is done. It tends to be an annoyance to me to constantly
> have to click it away...
>
> 9) Regarding the file name construction for the output file,
> I think you should also add in the corner, and some indication
> for whether this is for Verilog-AMS or VHDL-AMS. It would be
> nice not having to rename the output file manually to avoid
> conflicts.
>
> 10) The command version may be a good thing to have when
> people want to run it in an unattended batch mode. If you
> can make the GUI version do that, than you could get rid
> of the command line version. Otherwise it may be a good
> thing to have. I was also thinking whether I could run
> this converted from inside the model. I.e. the model in
> the library gets the file name and model name and then
> it would run this converted to extract the data and then
> continue reading the data. I didn't figure out how to
> run system commands from the models yet. It may not be
> possible or easy or even safe... People could write
> something that deletes the entire hard disk...
>
> Anyway, could you please look into these problems and
> start fixing the easier ones?
>
> Thanks,
>
> Arpad
> =========================================================-----Original
> Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf
> Of Paul Fernando
> Sent: Thursday, February 02, 2006 8:51 PM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: IBIS-to-AMS script update
>
> Arpad,
>
> Here's the fixed version.
> The help file is attached as well- which is why it gave a dialog.
>
> Please note: Only the 'convert' menu performs a useful function - converting
> ibis files
> to verilog or vhdl A(MS). 'File' and 'Help' work as well. The other menus are
> work in
> progress. I was thinking of getting the 'template' menu to read in a template
> file and
> get its data using dialogs and create a complete set of output files ready for
> simulation.
>
> Should I update version1 (without GUI) or should it be considered obsolete?
> Alternatively, I could update the GUI version so that it accepts command line
> input as
> well.... What do you think?
>
> Thanks,
> Paul
> ---------------------------------------------------------------------
> 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:
