Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour

Todd,
thanks for your comments. You are right, in step 2 I meant smallest 
(T1,T2) interval, of course. I think about Vtol and Tmin/2 (half of 
maximum freq period) as algorithm parameters, and I think may be more 
then one iteration will be needed, I mean we start with some initial 
small Vtol (because we want to keep maximum data points possible under 
"over clocking free" condition), run the algorithm, check the results - 
and if time window after trimming is still large then Tmin/2, we 
increase Vtol by some amount and run it again, until we get the desired 
final time window. By the way, it seems the ABSOLUTE value of 
|V(t)-Vendpoint/Vsupply| checking is must if we want keep some 
overshoots or undershoots near end points, if exist in original V/T curves.

About step 4, I agree, printing of such comment into *.ibs file itself 
is a good idea.

About the name conventions, why not, the convention you offered seems 
good exactly as any other possible.

Dmitry.


Todd Westerhoff wrote:
> Dimitry,
> 
> This is good stuff!  I have a few very small comments:
> 
> Step 2: I think you meant you're going to find the *smallest* T1 to T2
> interval that satisfies Vtol.  Alternatively, you could find the largest
> interval from start to T1.
> 
> Step 4: Once you've made this computation, you can determine if you're going
> to be able to shift ALL curves by the same amount and stay within the bit
> time (i.e. maintain time correlation across min/typ/max), or if you need to
> adjust curves by corner - in which case I'd print a message to that effect,
> possibly as a comment in the IBIS file itself.
> 
> Your conclusion about not needing time correlation across min/typ/max curves
> is correct - each corner simulation gets paired with its own set of timing
> data (slow/typ/fast) for timing analysis, so time-correlation between
> corners isn't required.  That having been said, it's good to preserve
> time-correlation between corners when you can, simply because new users
> won't necessarily understand the nuances of how SI results get paired with
> static timing.
> 
> I really like the way you've defined T1 and T2.  I think it would be a good
> idea to identify all the different curves as well:
> 
> 1.  [Min]/[Rising]/[50 ohm GND]
> 2.  [Min]/[Rising]/[50 ohm VDDQ] 
> 3.  [Min]/[Falling]/[50 ohm GND]
> 4.  [Min]/[Falling]/[50 ohm VDDQ]
> 5.  [Typ]/[Rising]/[50 ohm GND]
> 6.  [Typ]/[Rising]/[50 ohm VDDQ] 
> 7.  [Typ]/[Falling]/[50 ohm GND]
> 8.  [Typ]/[Falling]/[50 ohm VDDQ]
> 9.  [Max]/[Rising]/[50 ohm GND]
> 10. [Max]/[Rising]/[50 ohm VDDQ] 
> 11. [Max]/[Falling]/[50 ohm GND]
> 12. [Max]/[Falling]/[50 ohm VDDQ]
> 
> .... or whatever other convention makes sense.  That way, we could talk
> about T1 for Curve 4 and know exactly what we're talking about ...
> 
> Todd.
> 
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA  01754
> (978) 461-0449 x24
> twesterh@sisoft.com
> www.sisoft.com
> 
> -----Original Message-----
> From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
> Of Dimitry Eisenshtat
> Sent: Monday, January 15, 2007 5:02 PM
> To: Todd Westerhoff
> Cc: ibis@eda-stds.org; ibis-users@eda.org
> Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour
> 
> Hi Todd,
> first of all - thanks for your reply, as I said, I'm writing script for 
> trimming V/T tables in order to satisfy Cookbook recommendation, so your 
> explanation is really useful. Thank you :)
> 
> Ok, I see from your virtual DDR example that "over clocking" should 
> require special treatment on IBIS simulator side, and I finally decide 
> to avoid such situations and create IBIS models with V/T tables time 
> window up to  half of minimum signal period the buffer designed for.
> 
> Now some words about HOW I will do it. I think the most important point 
> you mentioned is "time correlation" of all given corner curves. I want 
> use simple algorithm for automatically trimming V/T curves, let me 
> explain. Lets say we have 12 transients, exactly as in your (most 
> common) example of push-pull buffer simulated in 3 corners with load of 
> 50 ohm once to supply, once to ground. The steps will be:
> 
> 1) Run spice simulations (with s2ibis* or manually, does not matter) 
> with as small time step as it possible for simulation time large enough 
> for weakest conditions (corner/load) transition to be finally completed. 
> The idea is to begin with "ideal" time resolution for all transitions 
> regions in our 12 curves.
> 
> 2) For each curve find largest time interval (T1,T2) which satisfy 
> voltage tolerance of delta from initial and final DC solutions, i.e.
>   |(V(T1)-Vstart)/VDD|  < Vtol,
>   |(V(T2)-Vend)/VDD|    < Vtol
> where Vtol tolerance chosen smaller than IBISCHK's one so the checker 
> will not report "DC endpoints" warning on trimmed tables latter. All 
> data points outside of this interval (T1,T2) are declared "dead zones" 
> and have no importance. So the Vtol value actually plays as "dead zones" 
> definition criteria and should be the parameter to be changed if needed.
> 
> 3) For all curves (rising/falling/load) of given corner find the minimum 
> T1 value, lets define it as T1_typ, T1_slow, T1_fast or T1_<corner>.
> 
> 4) Calculate maximum interval dT_max = max {|T2-T1_<corner>|} for ALL 
> curves.
> 
> 5) Shift all curves for given corner left in time by T1_<corner> value.
> 
> 6) Truncate all curves at time dT_max (from new 0 time after shifting)
> 
> 7) Add one points to end of each curve in order to form a line with zero 
> slope for case of some simulators extrapolation will be needed.
> 
> 8) Remember, we start from "the best" time resolution, so it is possible 
> that we get desire time window from overclocking point of view, but 
> number of points in final V/T tables still exceeds the maximum allowed 
> by IBIS spec. In this case I suggest to use "greatest change algorithm" 
> in order to decrease the number of tables points, as it described in 
> Cookbook (pages 63-64).
> 
> As the result, if I have no mistake, we will get "corner time- 
> correlated" tables. However, across corners correlation is not 
> guaranteed. My assumption is that the user will be interested in 
> analyzing the buffer's (buffer itself, I mean not control logic but 
> pullup/pulldown devices which actually drive the pad) corner-specific 
> behavioral/differences, so I at least do not worsen the model quality, 
> or even improve it. Anyway,  in some cases there will be no possibility 
> to satisfy "overclocking free" condition without shifting the corner's 
> curves one to each other, in other words without trimming different 
> amounts from different corners.
> 
> Does it make sense? I like to complete realizing this algorithm in perl 
> and try it on last DDR2 model I produced. Only IBIS simulator I have is 
> HSpice, so the plan is to compare the behavioral of IBIS model before 
> and after trimming. I hope the HSpice is bad enough in "over clocking" 
> scenario, otherwise I will see no difference/improvements anyway :)
> 
> Regards,
>     Dmitry
> 
> 
> 
> 


-- 
  +---------------------------------------------------------+
  | Dmitry Aizenshtat         Circuit Design Engineer, NSTA |
  | Tel : 972-9-9702-020               Fax : 972-9-9702-001 |
  | mailto:dimita@taux01.nsc.com                            |
  +---------------------------------------------------------+



===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.

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