Radovan, I will try to answer your questions. First, you need to be careful when using the words "frequency dependent", because it can be interpreted several different ways. Your questions deal with the over clocking situation in time domain, which is not the same kind of frequency dependence that people refer to when talking about frequency domain simulations. To help you to understand the situation, you can think of the V-t curves as a scaling coefficient curve as a function of time. When let's say the pulldown turns on, its I-V curve is scaled from 0 to 1 using these curves as time goes by. The ramps do the same thing, except the shape of the waveform is assumed to be a perfect trapezoid. The IBIS specification assumes that the transition begins and ends in a steady state, i.e. the waveform begins and ends perfectly horizontally. It is not defined what tools should do when you clock a model faster than the length of the transition, the results can vary arbitrarily. The problem is that you may run into problems even if the V-t curves have long, but horizontal ends (or beginnings). Therefore the usual recommendation is to reduce the length of the V-t curves as much as possible. However, one must be careful when shortening the data. For one, the V-t curves must remain time correlated, i.e. you can't chop off different amounts from the beginning. Removing data from the ends is much easier, but you need to make sure that the end point is representative of the steady state conditions, otherwise you may get I-V and V-t curve mismatch messages. Regarding the question you asked about the buffer's internal delay, yes, by removing the front end of the V-t curves, you are removing that portion of the internal delay from the buffer's model. However, this portion of the V-t curves should never be interpreted as a true internal propagation delay for the buffer, because it only contains as much delay as the SPICE model's circuitry contains. SPICE models usually do not include the delay of the entire clock distribution tree on the die, while the Tco number in the spec may include all that too. SI timing budgets usually contain a separate bucket for this internal buffer delay, so your simulations should not include this in the flight times, otherwise you would be double counting it. For this reason, it is usually OK to remove the unnecessary horizontal portions form the beginning of the V-t curves. For some extra information you can also look at the following presentation: http://www.eda.org/pub/ibis/summits/jun03b/muranyi2.pdf I hope this answers your questions. Arpad Muranyi Intel Corporation ====================================================================== -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Radovan.Vuletic@infineon.com Sent: Monday, June 20, 2005 9:51 AM To: ibis-users@eda.org Subject: [IBIS-Users] "Frequency Dependant IBIS Models" Hi IBIS Experts, question about so called "Frequency Dependant IBIS Models". I understand why are these things happen (if rising + falling waveforms on V/T are longer than your clock period), but I still don't know what are simulators doing with V/T curves and dV/dt_r and dV/dt_f? I have seen some models where are the trailing points, i.e. points when the rising/falling has finished and response has steady state commented out (or deleted), at it is fine. But, I have also seen some models where are the points with no current change before signal even started to rise/fall deleted, so this V/t curves are artificially made to fit in duty-cycle. That means that fly-by-time (propagation of signal from I/O buffer input to I/O buffer output) of an I/O buffer is reduced to almost zero? Is it OK to do something like that? I don't know what are simulator doing with V/t curves, but on that way fly-by information is lost! Is it needed at all? If one can delete trailing points or points with no current change and present that as an valid model, do we need then V/t curves at all? Then should be only dV/dt_r,f data enough...Right or I am missing something? I would be thankful for any kind of answer or link where are these things explained. Best regards / Mit freundlichen Gru?en / S postovanjem Radovan Vuletic Infineon Technologies AG MP PD PDE Room 03.911 Balanstra?e 73 D-81541 Munchen Phone: +49 (0)89 234 20108 Fax: +49 (0)89 234 27705 Fax (PC): +49 (0)89 234 955 5305 E-mail: radovan.vuletic@infineon.com |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just 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 email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just 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 email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993Received on Mon Jun 20 22:40:21 2005
This archive was generated by hypermail 2.1.8 : Mon Jun 20 2005 - 22:41:23 PDT