[ibis-macro] Re: IBIS-to-AMS script update
- From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 6 Feb 2006 16:39:03 -0800
Paul,
I tested the VHDL-A(MS) portion of the script, and
it seems to be working fine (except for those "more
involved" issues). I was finally able to generate
a waveform with my library IBIS buffers in SMASH
using real IBIS data!
Regarding #4, I think we could do the following:
To decide which rising edge waveform becomes ...r1
or ...r2 look at the value of Vfixture. The waveform
that is associated with a LOWER Vfx should become
...r1. Similarly, to decide which falling edge
waveform should be ...f1 or ..f2, look at Vfixture
and the waveform with a HIGHER Vfx should become
...f1. This needs to be done only with buffers which
are not Open_something. The Open_something types have
only one rising and falling edge, so they become ...r1
and ...f1 regardless of the Vfixture values.
Regarding #6, the IBIS spec says:
| Keyword: [Voltage Range]
| Required: Yes, if [Pullup Reference], [Pulldown Reference], [POWER
| Clamp Reference], and [GND Clamp Reference] are not present
So as soon as any of the other four is present,
[Voltage Range] is not required. Turn this around,
and say if we only have [Voltage Range] then pu_ref
and pc_ref get the value of [Voltage Range], and
pd_ref and gc_ref get zero volts. If any of the
other four keywords appear, they will be in effect
regardless of the value in [Voltage Range]. In this
case use the value of [Voltage Range] for the pu_ref
or pc_ref if either the [Pullup Reference] or the
[POWER Clamp Reference] keyword is not present,
respectively, and do the same on the low side,
use zero for pd_ref or gc_ref if the corresponding
[*** Reference] keyword is not present. If all
four [*** Reference] keywords are present, then we
can basically ignore [Voltage Range] completely.
Can you implement this?
Regarding #10 we can wait and see how the rest of
the group feels...
Please let me know if you have any questions.
Thanks,
Arpad
===================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Paul Fernando
Sent: Friday, February 03, 2006 3:43 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-to-AMS script update
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
> =========================================================
---------------------------------------------------------------------
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:
