RE: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and proposed Solutions

Hi Bob,
Personally I believe that Clean, Detailed Up-to-Date methodology for
creation models
Is even more important than detailed validation checklist, probably.

If/when Peoples would know for sure What, How they have to do to create
Right Models -
Quality would be increased upfront. And not so long, detailed check
lists would be required even.

As I understand, you (IBIS Quality workgroup) just complete new Quality
Guidelines.
That's probably a good time to review development methodology.

Regards,
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: Bob Ross [mailto:bob@teraspeed.com]
Sent: Monday, January 25, 2010 10:09 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 Sergey:

We currently do not have an active working group for the Cookbook.
If we set one up, we would welcome you as a participant an reviewer.

Best Regards,
Bob

Nikonchuk Sergey-R6294C wrote:
> Hi Bob,
> Thank You very much for valuable and helpful feedback!
>
> Seems like IBIS Cookbook have to be enhanced/clarified, especially for

> a future 5.0 standard, features And modern technologies/designs.
> Do you have some specific working group for?
> Is it possible to participate in - at least for review?
>
> 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: Bob Ross [mailto:bob@teraspeed.com]
> Sent: Saturday, January 23, 2010 1:59 AM
> 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
>>
>>
>>
>>
>>

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