Hello Dmitry I have been using Hspice to simulate IBIS models for a while and i have observed that there is no difference(or let me say miniscule diffrences) after trimming V-t curves. It can make difference only if you have missed many intermediate points before trimming and after trimming they are included. But if you have been careful enough to extract your V-t waveforms i feel trimming does not bring any improvement in the results. Also i have felt that Ramp data is also not important if you have given V-t waveforms. No matter how weird your ramp data may look simulation results will be good if your V-t waveforms are extracted properly. One parameter which changes the waveform considerably is C_comp. One should be careful in extracting C_comp as wrong calculation of C_comp can lead to bad results. I leave to the experts to comment on my observations. Regards Amit Kumar ST Microelectronics-Noida Ummalaneni, Venu Babu (Venu) wrote: >Dmitry and all, > >I am curious to know your experiences on the experiments with "trimming >V-t curves". Could some one please comment on the behavior of IBIS model >with Hspice simulator before and after trimming? I mean, whether the >correlation of the IBIS vs golden model in over clocking mode improved >after trimming the V-t curves? > >Thanks & Best Regards, >Venu > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On >Behalf Of Dimitry Eisenshtat >Sent: Tuesday, January 16, 2007 3:32 AM >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 > > >Todd Westerhoff wrote: > > >>Sorry for the delay in reply - I took the weekend off ;-) >> >>As far as non-time correlation between IBIS and transistor models goes >>- no, it isn't a problem at all. It's just important that people >>understand what a model represents and what it doesn't, so that they >>can draw the right conclusions from their simulations. I was just >>re-iterating one of my favorite points with "time 0 in an IBIS model >> >> >is arbitrary". > > >>To your point, it's worth noting that time 0 in a spice model-based >>simulation is often arbitrary as well. A spice model represents only >>the output buffer at most, so if you're analyzing a device with a >>clock-to-out timing specification, you still need to figure out how to >> >> > > > >>combine the delays measured in simulation with the timing spec for the >> >> >device. > > >>I think people often ascribe too much credibility to spice models. >>The model you receive is a function of how the netlist and parasitics >>for the buffer were extracted - it's far too easy to become confused >>about what part of the overall device the spice model represents. >> >>As to page 70 of the IBIS cookbook - I agree with what it says. That >>particular page is assuming a DDR device, so that a 100 MHz clock >>yields 200M transfers/sec, each with a 5 ns UI. Let's suppose you >>have a model with a 6ns rising V-T curve for this case. The simulator >> >> > > > >>will trigger the curve, begin sweeping the output, and then get >>retriggered at the 5ns point >>- before the rising edge is complete. What should the simulator do? >> >>- should it just jump to the start of the falling curve (if it does, >>you may get a discontinuity on the output that can either glitch the >>output or cause a convergence problem) >> >>- should the simulator "pipeline" the waveform results, and just >>remember the next edge starts 1 ns later - and if the input edges keep >> >> > > > >>coming faster than the curve length, how long should the simulator >>keep this up before it starts clipping data? >> >>... my earlier point was that the IBIS spec has no guidance on how a >>simulator should handle "overclocking" and different simulators DO >>handle this issue different ways. That being the case, it's best to >>avoid the problem by complying with the strong recommendation on page >> >> >70. > > >>As far as curve trimming goes, allow me to provide a *brief* overview, >> >> > > > >>although I'm sure this subject has been discussed previously. >>Pointers into the archive for this subject from others would be >> >> >appreciated. > > >>Let's consider a push-pull output stage instead of open drain - >>open-drain will just be a simpler case. >> >>Each output should have the following V-T curves >> >> [Corners] x [Edge] x [Loading] >> >> [Min / Typ / Max] x [Rising / Falling] x [50 ohms GND / 50 ohms >> >> >VDDQ] > > >>... for a total of 12 sets of V-T curves. >> >>... for each [Corner]/[Loading] combination, it is ESSENTIAL that if >>you trim dead time off one curve, you trim the SAME amount of dead >>time off the other. As an example, if you trim 1ns off the start of >>the [Min]/[Rising]/[50 ohms GND] curve, you MUST trim 1ns off the >>[Min]/[Rising]/[50 ohms VDDQ] curve. If the second curve was already >>rising at that point, well, you need to trim less. >> >>This is what's called "time correlation" between curves, and it must >>be maintained. >> >>... good practice dictates that you coordinate your trimming across >>all four of the V-T waveforms for any corner. If you don't do this, >>you'll introduce duty cycle distortion into the simulated waveform >>without meaning to. I believe this is now considered to be required >>practice. So, if you trim 1ns off the start of the [Min]/[Rising]/[50 >> >> > > > >>ohms GND] curve, you really, really should trim 1ns off the following >> >> >curves: > > >> [Min]/[Rising]/[50 ohms VDDQ] >> [Min]/[Falling]/[50 ohms GND] >> [Min]/[Falling]/[50 ohms VDDQ] >> >>... so that time correlation is maintained across all the [Min] >>curves. As before, if you go to trim any of the curves and find the >>transition was already starting, you need to trim less. >> >>I don't believe IBIS requires that you coordinate trimming across >> >> >corners. > > >>Thus, you can trim different amounts from the [Min] and [Typ] curve >> >> >sets. > > >>In practice, you'll find this is useful because if you try to >>coordinate trimming across a 3 corners, the amount you are able to >>trim may be sharply limited. It's important to understand, though, >>that if you trim different amounts from the different corners, the >>time correlation between the corners will be lost. Strictly speaking, >> >> > > > >>that's not a problem, as time 0 in an IBIS simulation is arbitrary. >>HOWEVER - if users of the model simulate the [Min] and [Typ] cases and >> >> > > > >>overlay the results, they will draw incorrect conclusions if they >> >> >assume the curves are time-correlated. > > >>It probably goes without saying, but - you can trim any amount of dead >> >> > > > >>time you want off the END of a curve once the slope is zero. Good >>practice says the last two points should form a line with zero slope, >>so that any extrapolation the simulator performs does what you expect. >> >>As in all modeling - knowing what you've got is the first step in >>understanding what conclusions you can draw. >> >>Arpad & others - please correct me if I've gotten any of this wrong >> >> >... > > >>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: Saturday, January 13, 2007 3:58 AM >>To: Todd Westerhoff >>Cc: ibis@eda-stds.org; ibis-users@eda.org >>Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour >> >>Todd, >>ok, we understand that time correlation between IBIS and HSpice is not >> >> > > > >>guaranteed, but is it really problem? I mean, in the most often >>situation there is no place for such comparison at all, because you >>have only IBIS model, no spice netlist is available. This is the first >> >> > > > >>reason for making IBIS (if simulator speed is not an issue), is it >>right? Lets say, I'm with semiconductor vendor side, I have the >>netlist of the buffer, I make the IBIS model based on spice >>simulations, not lab measurements, so on final step when the model is >>ready I like to check it vs. original spice behavioral. This is the >>only situation I agree the comparison is important. But in such case >>there is no REAL problem - I know exactly about the delay, and if it >>is the only difference between the IBIS & spice - I don't care. >> >>I want ask you about IBIS simulator aspect of the point we are talking >> >> > > > >>about. Look, I find in "Cookbook for ver4" strongly recommendation to >>trim IBIS model time tables at least to half of max buffer frequency >>period. (http://www.vhdl.org/pub/ibis/cookbook/cookbook-v4.pdf page >>70, >>5.4.2 V-T Table Windowing). Can you please prefer from simulator >>software side - is it really problem for the simulator if the time >>table window is more then such time interval? And one additional >>point, you wrote "There are specific restrictions on how the dead time >> >> > > > >>may be trimmed, which is a longer discussion" - right now I writes >>perl script which will trim tables in order to leave only transition >>region and decrease the time window as the Cookbook recommends to do. >>So, can you please explain about these restrictions? >> >>Thanks, >> Dmitry >> >>... (previous thread clipped) >> >> >> >> > > >-- > +---------------------------------------------------------+ > | 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 > > > -- 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 Thu Nov 29 03:31:02 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 03:32:42 PST