Subject: RE: Duty Cycle
From: Todd Westerhoff (twester@hhnetwk.com)
Date: Mon Sep 24 2001 - 09:45:43 PDT
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 : Mon Sep 24 2001 - 10:12:54 PDT