Hi Arpad,
Thank you for pointing on useful and helpful training classes.
I have at least one question about slide 28:
=======================================================
What about typ., min., and max. supply voltages?
* the voltage range should be based on the typical value only
because there is one voltage column for each case, and a
numerical value is required in the first and last points
=======================================================
There is quite strange recommendation from my point of view, because
[Voltage range] IBIS keyword used not just as a reference voltage for
[Pullup]/[Power clamp],
But! It is define IO Buffer operation voltage as well, according to IBIS
standard (see below)
|=======================================================================
======
| Keyword: [Voltage Range]
| Required: Yes, if [Pullup Reference], [Pulldown Reference], [POWER
| Clamp Reference], and [GND Clamp Reference] are not
present
| Description: Defines the power supply voltage tolerance over which
the
| model is intended to operate. It also specifies the
default
| voltage rail to which the [Pullup] and [POWER Clamp] I-V
data
| is referenced.
Could you clarify more detailed, please?
How we will be able to use exactly same (typical) voltage range with
different typ/min/max supply voltages?
According to standard it is exactly same value. Isn't it?
The only one thing that we can change is - voltage that we sweep on a
pad (Voutput in terms of Cookbook).
But PullUp/Power clamp curves would be mismatched any way - either Vcc
referenced or ground referenced. Isn't it?
The cookbook more/less well defined for One (let's say typ values)
But - almost nothing about max/min waveforms capturing and printing.
BTW, my first name is Sergey.
Use surname is not really necessary for a future communications :-)
Thanks,
Sergey Nikonchuk
Characterization and View Generation
Digital Standard Cell and IO Pad Cell Libraries
TSO / DT / L&M / Libraries Organization
www.freescale.com
Phone: +7 (495) 589 1839
Phone: +7 (495) 536 9987
Mobile: +7 (916) 993 3467
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On
Behalf Of Muranyi, Arpad
Sent: Tuesday, January 26, 2010 7:18 PM
To: ibis-users@eda.org
Subject: RE: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and
proposed Solutions
Nikonchuk,
In addition to Bob's answer, I would suggest that you look at slides
26-28 and 85-92 in the "IBIS_class_2003_11_03.PDF" file in
http://www.vhdl.org/pub/ibis/training/IBIS_class_2003.zip
Even though there are not too many words on these slides, I hope that
the pictures will help you to understand these details about I-V curves.
I would also recommend that you look at the IBIS Cookbook:
http://www.vhdl.org/pub/ibis/cookbook/cookbook-v4.pdf
Starting at Section 5.1.3.3 the Cookbook deals with I-V curve extraction
for the various tables for IBIS models.
Regarding what s2ibis does, I had a chance to talk with the authors at
the time it was first being developed and made similar observations as
you, and suggested alternative ways, but they still decided to do it the
way it is. That was their choice, which does not necessarily mean that
it is the best method.
I hope these answers will help you in your work.
Thanks,
Arpad
=============================================================
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On
Behalf Of Bob Ross
Sent: Friday, January 22, 2010 4:59 PM
To: Nikonchuk Sergey-R6294C
Cc: ibis-users@eda.org; bob@teraspeed.com
Subject: Re: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and
proposed Solutions
Hi Nikonchuk:
This is the right group to ask IBIS questions. Here is a quick
responses without commenting on all of the points you raised.
Q1. You are correct that the ranges for I-V table are based on the
typical Vcc rather than the actual Vcc. So the minimum column can have
some overlap and the maximium column can miss some currents at the ends
of the range (if it were extended to -Vcc_max to 2*Vcc_max).
As a practical matter, EDA tools can and will extend the range if
needed, either by extrapolation or extension of the table.
That should be accurate enough for the unlikely case of having
simulations converge in that region. (It that were the case, there is
probably a design problem or simulation setup problem that needs to be
resolved.) So there was no compelling reason for use the Vcc_max value
as the basis for suggesting the table ranges.
However, you are allowed to go beyond the ranges suggested by IBIS as
long as they apply for all three columns.
Q2. The specific question is why the ranges -Vcc to Vcc were chosen for
[Gnd Clamp], and Vcc to 2Vcc for [Power Clamp].
In the early days of IBIS (1993), the specification was written for both
CMOS and bi-polar transistors and TTL devices (e.g.,
74F244) where the input had a bias resistor to Vcc through a diode.
So the I-V table showedsmall negative current until the voltage reached
about 2 V (with a 5 V Vcc). Then it cut off to nearly 0 A.
The IBIS authors chose to use the [Gnd Clamp] table extended to Vcc to
capture this effect.
Otherwise, the authors might have split the difference an had the ranges
of the [Gnd Clamp] and [Power Clamp] table meet in the middle (Vcc/2).
But that choice would have produced a clamp table "gap" at that point of
interest if the ranges had not been chosen to extend to Vcc_max per Q1.
There are other comments with your other statements, which I will only
summarize. If the non-monotonic issues is in the numerical "noise"
region or as a result of some double counting due to the extraction tool
algorithm, it would be permissible to correct the data and take out a
few points or zero the data of one of the tables.
If there are on-die terminators, then the correction of the tables need
to be carefully considered based on other information to avoid double
counting - based on what rail or rails the ODT is referenced. But the
main point is that the currents of both the [Power Clamp] and {Gnd
Clamp] add together for all points in both tables including the extended
points that are not specified in either table.
Q3. Without giving specific names, I know of several vendors that
implement the DEQ-style method and split up the ODT into the components
referenced by each rail so that their models correspond to the physical
device structure. The accuracy issue is depends on the type of analyis
and assumptions. But there are theoretical issues based on tool setups
and capabilities if power and ground package model elements are used, or
if SSO analysis is done (now and with future features). These issues
relate to the Vcc to Gnd impedance changes that may cause the model to
switch abruptly in a manner that does not correpond to the physical
device operation.
Bob
Nikonchuk Sergey-R6294C wrote:
> Dear IBIS Users Community.
> This is a first time when I send e-mail to the IBIS community.
> So, be patient, please, if I am use wrong e-mail address or asking
> questions which one already clarified in some documentation.
> Just point me on right source.
> My particular questions that I hope to get answers highlighted below
as
> "Q1, Q2, Q3"
>
> During detailed evaluation of IBIS characterization flow, especially
for
> ODT (On-Die Termination) cells,
> we find some issues in Existing s2ibis3 implementation for Clamp
current
> capturing and printing in to IBIS model.
>
> 1. The Voltage range not cover Max condition for
> [Pullup]/[Pulldown]/[GND_clamp]/[POWER_clamp] I-V Curves As
> recommended by IBIS standards and Cookbook , the range for the IV
> curves have to be -Vcc::2*Vcc Now, for "Vcc" value the "Typ" value
> used.
> It mean, if we have Typ Vcc =1.8V +/- 0.1V for Max/Min conditions, we
> have -1.8V::3.6V range for IV curves, which one cover Typ and Min
> recommendation, But not enough for Max condition, which one should be
> -1.9V::3.8V
>
> I suggest to extend the range for IV Curves capturing up to Max
[Voltage
> Range] value.
> That's have to be applied for All 4 IV curves -
[Pullup]/[Pulldown]/[GND
> clamp]/[POWER clamp]
>
> Q1. Is there any particular reasons, comments - Why IV curves
referenced
> to Typ Vref? Is there concern to extend IV ranges up to Max Vref ?
>
>
> 2. The Minimum recommended range for Clamp IV capturing cause
> non-monotonysity issue in Final IBIS models.
> Existing implementation of s2ibis3 Assume the Minimum Voltage ranges
> for Clamp Curves:
> [GND_clamp] -Vcc::Vcc
> [POWER_clamp] Vcc:2*Vcc (Ground referenced)
>
> Below is example:
>
>
> [Voltage Range] 3.3000V 3.0000V 3.6000V
> |
> [GND_clamp]
> |Voltage I(typ) I(min) I(max)
> |
> -3.30 -3.5860A -3.6101A -3.4617A
> -3.23 -3.4782A -3.5024A -3.3533A
> -3.16 -3.3704A -3.3947A -3.2450A
> .....
>
> 3.14 31.9335uA 32.7227uA 40.1997uA
> 3.21 32.7095uA 73.2482uA 41.1226uA
> 3.28 33.5298uA 0.2503mA 42.0514uA
> |
> [POWER_clamp]
> |Voltage I(typ) I(min) I(max)
> |
> -3.28 3.5775A 3.6016A 3.4528A
> -3.24 3.5154A 3.5397A 3.3904A
> -3.20 3.4534A 3.4777A 3.3281A
> .....
>
> -0.08 35.8263uA 26.4944uA 47.5355uA
> -0.04 34.5005uA 25.3183uA 46.9642uA
> 0.00 33.7999uA 24.7033uA 46.4029uA
>
> Looks fine so far?
> Now remind that we have [POWER_clamp] values in IBIS file referenced
to
> [Voltage range]
>
> Vtable = Vreference - Voutput
>
> So, if we will re-print the [Power_clamp] table for the
Ground-reference
> voltages, we will have something like as following:
>
> [POWER_clamp]
> |Voltage I(typ) I(min) I(max)
> |
> 6.88 3.4528A
> 6.84 3.3904A
> 6.80 3.3281A
>
> ....
> 6.58 3.5775A 2.4528A
> 6.54 3.5154A 2.3904A
> 6.50 3.4534A 2.3281A
>
> ....
>
> 6.28 2.5775A 3.6016A 1.4528A
> 6.24 2.5154A 3.5397A 1.3904A
> 6.20 2.4534A 3.4777A 1.3281A
>
> .....
>
> 3.68 39.8263uA 46.4944uA 47.5355uA
> 3.64 38.5005uA 45.3183uA 46.9642uA
> 3.60 37.7999uA 44.7033uA 46.4029uA
>
> ...........
> 3.38 35.8263uA 36.4944uA ?????????
> 3.34 34.5005uA 35.3183uA ?????????
> 3.30 33.7999uA 34.7033uA ?????????
>
> ........
> 3.08 26.4944uA
> 3.04 25.3183uA
> 3.00 24.7033uA
>
> And when [POWER_clamp] and [GND_clamp] combined together and added to
> [Pullip]/[Pulldown] for simulation, We have double counting "Min"
> clamps between 3.0V and 3.3V And we have kind of "Hole" for Max clamp
> between 3.28V and 3.6V Does it looks negligible?
>
> inischk4 say No.
>
> WARNING - Model v330_11_c4: POWER Clamp : Typical value never becomes
zero
> WARNING - Model v330_11_c4: POWER Clamp : Minimum value never becomes
zero
> WARNING - Model v330_11_c4: POWER Clamp : Maximum value never becomes
zero
> WARNING - Combined Pulldown for Model: v330_11_c4 Typical data is
> non-monotonic WARNING - Combined Pullup for Model: v330_11_c4 Typical
> data is non-monotonic WARNING - Combined Pulldown for Model:
> v330_11_c4 Minimum data is non-monotonic WARNING - Combined Pullup for
> Model: v330_11_c4 Minimum data is non-monotonic WARNING - Combined
> Pulldown for Model: v330_11_c4 Maximum data is non-monotonic WARNING -
> Combined Pullup for Model: v330_11_c4 Maximum data is non-monotonic
>
> That's Especially Important for the ODT models, where Clamp currents
is
> quite significant
> And cause issues related to accuracy of models simulation.
>
> What the Solution could be for the issue above?
>
> Proposed Solution to extend Simulation ranges for both [Power_clamp]
and
> [GND_clamp] to -Vcc::2*Vcc
> (See IBIS_Cookbook_v4.pdf, Table 5-6)
> In this case we will cover whole range.
> BUT! If we will print All the data "As Is" in to IBIS model, Clamp
> Currents will be Duplicated!
> One of the Option to avoid duplication described in IBIS cookbook -
> Sections 5.1.3.4, 5.1.3.5 If we just "Clip" the data as described - we
> have to be take care
about
> Extrapolation Errors (Section 5.1.3.9) At the end - it would be almost
> the same as "minimal range" and will
NOT
> resolve all ibischk4 warning and simulation concerns.
>
> More reasonable Approach, applicable for ODT models as well described
in
> Following Presentation:
> http://www.vhdl.org/pub/ibis/summits/jun03b/muranyi3.pdf
>
> This called as "Clip and Extend"
>
> ? Sweep device from -Vcc to 2*Vcc twice: GND and Vcc relative ? Cut
> clamp curves where they reach zero current going left to right ?
> Extrapolate all clamp curves horizontally to 2*Vcc
>
> Opposite to Cookbook Proposal, this approach Cut clamp current when
it's
> going from Positive to Negative value
> And Extend (Extrapolate) this value to end of characterization range.
>
> In a reality, for plain (non-ODT) buffers it mean GND_clamp range:
> -Vcc::0 POWER_clamp range 0::2*Vcc (Ground referenced)
>
> Q2: Why Cookbook 4.0 Sections 5.1.3.4, 5.1.3.5 recommend to clip the
> date by Differerent ranges?
> GND_clamp range: -Vcc::Vcc
> POWER_clamp range Vcc::2*Vcc (Ground referenced) Is there any concerns
> to use "Clip and Extend" Approach for All Buffer
> types, not ODT only?
> GND_clamp range: -Vcc::0
> POWER_clamp range 0::2*Vcc (Ground referenced)
>
> The Cookbook recommended Clamp ranges seems contradictive with what
> IBISCHK really expected and potentially could confuse simulators.
> Am I miss something here?
>
> At the same time, during investigation of this issue we find
Alternative
> (claimed as more accurate for ODT) approach called as DEC:
> http://www.vhdl.org/pub/ibis/summits/sep05/ross2.pdf
>
> This Approach seems more tricky for Implementation with questionable
> added value in term of accuracy.
>
> Q3: Does anybody implement this approach in they models? What is
impact
> in terms of simulation accuracy vs. "Clip and extend"?
> Can anybody share particular code to split clamps according to DEC
> algorithms?
>
>
> I will greatly appreciate any feedback and proposals to address
issues
> above.
>
>
> Sergey Nikonchuk
> Characterization and View Generation
> TSO / DT / L&M / IO Pad Cell Libraries Freescale Semiconductor, Inc.
> www.freescale.com <http://www.freescale.com/>
>
> Contacts:
> Phone +7 (495) 589 1839
> Mobile +7 (916) 993 3467
> Fax +7 (495) 787 0151
> Sergey.Nikonchuk@freescale.com <mailto:Sergey.Nikonchuk@freescale.com>
>
> This e-mail and any attachments have been classified as:
> [x] Public
> [ ] Internal Use Only
> [ ] Confidential Proprietary
>
>
>
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner <http://www.mailscanner.info/>, and
is
> believed to be clean.
-- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Wed Jan 27 01:07:14 2010
This archive was generated by hypermail 2.1.8 : Wed Jan 27 2010 - 01:07:43 PST