Subject: RE: Duty Cycle
From: Jeremy Plunkett (jeremy@serverworks.com)
Date: Wed Sep 26 2001 - 16:46:04 PDT
Well said, Todd.
I would just like to add that even without bird 68.1, the default method of
generating IBIS data from a spice netlist will in most cases produce Vt
curves with accurate rising and falling Tco delays included. However, the
person formatting the data into the model and the simulation tool using the
model must both be conscientious in doing all editing/removal of time points
on all curves together to maintain the rising/falling relationship. This
has not been the case for many models and simulation tools to date, but it
isn't difficult.
In answer to Jon's original question, in the typical situations where I use
IBIS models, it's the same thing--the duty cycle of the signal(at the driver
output pad) is determined by the difference in output delay on rising and
falling transitions. This is because the internal logic for most
source-synchronous busses uses one edge of a clock at 2x the bus frequency
to generate the output transitions.
Regards,
Jeremy
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
Behalf Of Todd Westerhoff
Sent: Wednesday, September 26, 2001 12:51 PM
To: ibis-users@eda.org
Subject: RE: Duty Cycle
Jon,
I think the answer here is: yes and no. Yes, because we want to model the
effect of the differing prop delays on the output, and no, because we're not
trying to be able to explicitly isolate the delay through the output buffer.
The BIRD talks about being able to correctly predict ISI - and that's just
what I took away from it. If the IBIS model won't correctly predict the
percentages of time the signal spends high and low in a cycle - then doing
any kind of random data / eye diagram analysis is pointless. We find that
kind of analysis very useful, and want to be able to interchange IBIS and
HSpice modeling with consistent results. If the model doesn't follow the
points outlined in BIRD 68.1, then it seems unlikely that the two sets of
results would correlate.
Make sense?
Todd.
Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:twester@hhnetwk.com - ph: 978-671-5084
============================================
"Oh, but ain't that America, for you and me
Ain't that America, we're something to see
Ain't that America, Home of the Free
Little pink houses, for you and me"
- John Mellencamp
-----Original Message-----
From: Jon Powell [mailto:jpowell@innoveda.com]
Sent: Wednesday, September 26, 2001 5:21 PM
To: 'Jeremy Plunkett'; 'Todd Westerhoff'; ibis-users@eda.org
Subject: RE: Duty Cycle
Are we really talking "Duty Cycle" here or is this really a difference of
internal delay between rising and falling signals.
example:
We have a simple clock buffer.
The data takes longer go through the buffer on 0-1 than on 1-0
is that what we are talking about?
(if not, please give real example)
jon
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
Behalf Of Jeremy Plunkett
Sent: Tuesday, September 25, 2001 4:08 PM
To: 'Todd Westerhoff'; ibis-users@eda.org
Subject: RE: Duty Cycle
Todd,
I don't know the intentions of the authors of the IBIS spec, however there
are some simple choices in the process of generating an IBIS model and using
the data that will guarantee that duty cycle will be preserved. This has
been the case with IBIS models that I have developed myself and compared to
the original spice netlist using the hspice B element(barring other
simulation errors and B-element bugs, that is).
At the time the original IBIS spec was defined, Tco differences between
rising and falling edges were a small fraction of the data bit cell width,
so many tools may have been sloppy(relative to our current requirements) in
their implementation and traded off accurate preservation of rise-fall
timing in order to make the model smaller or simpler to process. Whatever
the reason, these implementations cause problems today--if the duty cycle
information is not accurately preserved in the IBIS model, then the user is
required to manually adjust the duty cycle based on part specs in order to
have the correct duty cycle in simulation(as you mention below). Since the
duty cycle error if this is not done affects the waveforms and their
accuracy with respect to ISI/crosstalk but does not cause any blatant timing
violation (due to the use of time-to-Vm adjustment), it is likely to be
missed by users unless it is visually obvious when looking at the waveforms.
It would be a very good thing for makers of SI tools to see what they can do
to preserve the rise-fall relationships present in the IBIS model Vt
waveforms(per bird 68.1). Also, anyone generating IBIS models today should
be sure to generate all Vt curves off of the same internal clock edge if
they don't do so already, and if they remove any portion of the curves do it
to all curves equally.
regards,
Jeremy Plunkett
Signal Integrity Engineer
ServerWorks Corporation
jeremy@serverworks.com
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
Behalf Of Todd Westerhoff
Sent: Monday, September 24, 2001 9:46 AM
To: ibis-users@eda.org
Subject: RE: Duty Cycle
I agree with Jon. IBIS models are not meant, by default, to represent a
device's duty cycle. You can get the model to produce the correct behavior
if you're careful with your modeling - but the tools typically used to
create IBIS models will not automatically produce a model that reflects the
device's duty cycle.
Todd.
Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:twester@hhnetwk.com - ph: 978-671-5084
============================================
"Oh, but ain't that America, for you and me
Ain't that America, we're something to see
Ain't that America, Home of the Free
Little pink houses, for you and me"
- John Mellencamp
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
Behalf Of Adam.Tambone@fairchildsemi.com
Sent: Monday, September 24, 2001 9:54 AM
To: Jon Powell
Cc: ibis-users@eda.org
Subject: RE: Duty Cycle
hmmm... OK, here is another two cents, but I do not believe it disagrees
with the previous remarks.
I have found through experience that the raw rising and falling waveform
data does not in itself represent correct duty cycle. Instead this data
must be modified to 'fit' the devices actual duty cycle. One can modify
the R/F V-t data in a number of ways including editing the delay region (
before the rising and falling edges occur ) to fit duty cycles at specific
frequencies found thorough laboratory measurement. Since duty cycle can
vary over frequency I have found it best to leave R/F V-t data in it's raw
state, and with R and F relative to each other as David described.
Here is an example with HSPICE that illustrates that the raw R/F V-t data
itself does not represent correct duty cycle. One has R/F V-t data through
HSPICE simulation and has included this data in an IBIS datasheet. Then
this IBIS datasheet is used in HSPICE simulation comparing it to the
original HSPICE sims used to generate the IBIS datasheet. I have found
through experience that the duty cycles of the simulated IBIS datasheet
will not be the same as the duty cycles of the HSPICE model of the device,
especially as frequency varies. Like Jon said, simulator vendors have
their own algorithms to process R/F V-t data in order to form a desired
duty cycle.
Adam Tambone
"Jon Powell" <jpowell@innoveda.com>@eda.org on 09/22/2001 12:01:24 PM
Sent by: owner-ibis-users@eda.org
To: "'Lorang, David D'" <david.d.lorang@intel.com>
cc: <ibis-users@eda.org>
Subject: RE: Duty Cycle
I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.
The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.
regards,
Jon Powell
Innoveda Consulting Services
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: ibis-users@eda.org
Subject: RE: Duty Cycle
Tim,
I think you have it right.
Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output. Suppose output data changes on every
rising clock edge. You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.
Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file. You would might run
two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data. The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time (0 ns). From the tabular output files, for those two sims you
could create two IBIS V-T tables.
Where exactly the output edges occur is dependent on internal buffer
delays,
and that is not important, but where the two edges occur relative to each
other is important. So you make sure you handle both tables in the same
way
when you import them into the IBIS file. You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other. All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges. For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions. In the end you
would
have four V-T tables, with their waveforms all correlated. So, in summary,
you need to correlate rising and falling edges in the same way you
correlate
the two load configurations.
Have I answered your question?
Dave Lorang
-----Original Message-----
From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com]
Sent: Thursday, September 20, 2001 12:34 PM
To: ibis-users@eda.org
Subject: Duty Cycle
Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?
Thank you for any information provided
Tim
This archive was generated by hypermail 2b28 : Wed Sep 26 2001 - 17:06:22 PDT