Hi Greg:
A question and comment.
1. The [Test Data] keyword includes a Driver_model subparameter to specify a
driver model. Should there also be a Receiver_model subparameter to specify
the receiver?
2. The [Rising Golden Waveform]/[Falling Golden Waveform] keywords are
"Required: Yes (within the scope of [Test Data]". I think I understand what
you are trying to say -- if [Test Data] is present then the golden waveforms
must also be present -- but both [Test Data] and the golden waveform
keywords belong in the global scope. I'd make the requirement read
"Required: Yes, if [Test Data] is present."
Regards,
Stephen
-----Original Message-----
From: Gregory R Edlund [mailto:gedlund@us.ibm.com]
Sent: Monday, April 16, 2001 8:48 AM
To: ibis@vhdl.org
Subject: BIRD 70.1
Here is BIRD 70.1 for discussion at Friday's Open Forum conference call.
After discussion with Bob Ross and Al Davis, I made some significant
changes that should make it upwardly compatible. Please note that this
BIRD sets up the infrastructure for a future BIRD to facilitate non-RC
standard loads. In fact, that BIRD becomes almost trivial.
I have two questions for readers:
1) Semiconductor vendors: If your customers require you to supply Golden
Waveforms and IF a production-quality SPICE-to-IBIS modeling tool were
available to support them, would this BIRD enable you to do so?
2) EDA vendors: If your customers asked you to support automated analysis
of Golden Waveforms and produce a correlation figure of merit table, would
this BIRD enable you to do so?
Thanks for your consideration everyone!
Greg
Greg Edlund
Electrical Packaging
IBM Server Technology Development
3605 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
gedlund@us.ibm.com
****************************************************************************
***
****************************************************************************
***
BIRD ID#: 70.1
ISSUE TITLE: Golden Waveforms
REQUESTOR: Greg Edlund, IBM
DATE SUBMITTED: April 16, 2001
DATE ACCEPTED BY IBIS OPEN FORUM: Pending
****************************************************************************
***
****************************************************************************
***
STATEMENT OF THE ISSUE:
Golden Waveforms are a set of SPICE waveforms simulated using known ideal
test loads. They are useful in verifying the accuracy of behavioral
simulation results for any given simulator. They are not the same thing as
the traditional VT tables recommended in the "IBIS Cookbook." The "I/O
Buffer
Accuracy Handbook" recommends a set of ideal test loads for classical
push-pull and open-drain drivers.
There is currently a problem with including Golden Waveforms in an IBIS
datasheet: the simulator tries to use these waveforms to construct its
stimulus waveform, and erroneous simulations result.
This BIRD proposes a new syntactical construct to tell the simulator
that a waveform is a Golden Waveform. The simulator may then choose to
ignore the data or (better yet) run a set of simulations using the network
and circuit parameters provided and report the correlation between the
simulation results and the Golden Waveforms. The mechanism for describing
a Golden Waveform involves two new keywords whose scope is global:
[Test Load] and [Test Data]. Under the [Test Data] keyword are two new
keywords whose scope is local: [Rising Golden Waveform] and
[Falling Golden Waveform].
[Test Load] is a description of a test load network that may be referenced
by any Golden Waveform under the [Test Data] keyword. [Test Data] is a
marker keyword that indicates the beginning of a group of Golden Waveforms.
****************************************************************************
***
STATEMENT OF THE RESOLVED SPECIFICATIONS:
|===========================================================================
==
| Keywords: [Test Data]
| Required: No
| Description: Indicates the beginning of a pair of Golden Waveforms
| and references the conditions under which they were
derived.
| An IBIS file may contain any number of [Test Data] sections
| representing different driver and load combinations.
|
| Sub-Params: Test_data_type, Driver_model, Test_load, Test_point,
| T_period, T_meas, V_meas
|
| Usage Rules: The name following the [Test Data] keyword is required.
| It allows a tool to select which data to analyze.
|
| The Test_data_type subparameter is required, and its value
| must be either "single_ended" or "differential."
|
| The Driver_model subparameter is required. Its value
| specifies the "device-under-test" and must be a valid
[Model]
| name.
|
| The Test_load subparameter is required and indicates which
| [Test Load] was used to derive the Golden Waveforms. It
must
| reference a valid [Test Load] name.
|
| The Test_point subparameter is optional. It indicates
which
| node in the test load network the Golden Waveforms
represent.
| The legal values for Test_point are "near" and "far." If
| Test_point is not specified, it defaults to "far."
|
| The T_period subparameter is optional. In the case that
the
| Golden Waveforms represent more than one rising or falling
| edge, the T_period subparameter tells the simulator the
| period between rising or falling edges. This subparameter
| is useful when constructing a test load in which a
reflection
| from the first edge hits the driver during the second edge.
|
| The T_meas subparameter is optional. It captures the time
| at which the standard load crosses the threshold specified
| in the component datasheet during a SPICE simulation. This
| subparameter is useful when correlating timing intervals
| between SPICE and behavioral simulations. It defines the
| beginning of a timing interval.
|
| The V_meas subparameter is optional and is also used to
| perform timing interval correlation. The end of a timing
| interval is defined as the time when a Golden Waveform or
| a behavioral waveform crosses V_meas.
|
| A timing interval in a behavioral waveform begins when
| the waveform crosses V_meas defined in the [Model] keyword
| while driving C_ref and R_ref, i.e. the standard load
defined
| in the component datasheet. Note that there are two
| DIFFERENT V_meas subparameters in IBIS: one associated
with
| [Model] and one associated with [Test Data].
|
|---------------------------------------------------------------------------
--
[Test Data] Data1
Test_data_type single_ended
Driver_model Buffer1
Test_load Load1
Test_point far
T_period = 10ns
| variable typ min max
T_meas 1.0ns 0.5ns 1.5ns
V_meas 0.75V 0.75V 0.75V
|
|===========================================================================
==
| Keywords: [Rising Golden Waveform], [Falling Golden Waveform]
| Required: Yes (within the scope of [Test Data])
| Description: Describes the shape of the rising and falling Golden
| Waveforms of a given driver and a given [Test Load].
| A model developer may use the [Rising Golden Waveform] and
| [Falling Golden Waveform] keywords to document Golden
| Waveforms whose purpose is to facilitate the correlation of
| SPICE and behavioral simulations.
|
| Sub-Params: None.
|
| Usage Rules: The process, temperature, and voltage conditions under
which
| the Golden Waveforms are generated must be identical to
those
| used to generate the VI and VT tables. The Golden Waveforms
| must be generated using unpackaged driver and receiver
models.
| The simulator must NOT use the Golden Waveform tables in
the
| construction of its internal stimulus function.
|
|---------------------------------------------------------------------------
--
|
[Rising Golden Waveform]
| Time V(typ) V(min) V(max)
0.0000s 25.2100mV 15.2200mV 43.5700mV
0.2000ns 2.3325mV -8.5090mV 23.4150mV
0.4000ns 0.1484V 15.9375mV 0.3944V
0.6000ns 0.7799V 0.2673V 1.3400V
0.8000ns 1.2960V 0.6042V 1.9490V
1.0000ns 1.6603V 0.9256V 2.4233V
1.2000ns 1.9460V 1.2050V 2.8130V
1.4000ns 2.1285V 1.3725V 3.0095V
1.6000ns 2.3415V 1.5560V 3.1265V
1.8000ns 2.5135V 1.7015V 3.1600V
2.0000ns 2.6460V 1.8085V 3.1695V
| ...
10.0000ns 2.7780V 2.3600V 3.1670V
|
[Falling Golden Waveform]
| Time V(typ) V(min) V(max)
0.0000s 5.0000V 4.5000V 5.5000V
0.2000ns 4.7470V 4.4695V 4.8815V
0.4000ns 3.9030V 4.0955V 3.5355V
0.6000ns 2.7313V 3.4533V 1.7770V
0.8000ns 1.8150V 2.8570V 0.8629V
1.0000ns 1.1697V 2.3270V 0.5364V
1.2000ns 0.7539V 1.8470V 0.4524V
1.4000ns 0.5905V 1.5430V 0.4368V
1.6000ns 0.4923V 1.2290V 0.4266V
1.8000ns 0.4639V 0.9906V 0.4207V
2.0000ns 0.4489V 0.8349V 0.4169V
| ...
10.0000ns 0.3950V 0.4935V 0.3841V
|
|===========================================================================
==
| Keywords: [Test Load]
| Required: No
| Description: Defines a generic test load network and its associated
| electrical parameters for reference by Golden Waveforms
| under the [Test Data] keyword. The Golden Waveform
| tables access a given [Test Load] by the value of the
| Test_load subparameter under the [Rising Golden Waveform]
| and [Falling Golden Waveform] keywords.
|
| Sub-Params: Test_data_type, C1_near, Rs_near, Ls_near, C2_near,
Rp1_near,
| Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far,
| C1_far, V_term1, V_term2, Receiver_model, R_diff_near,
| R_diff_far.
|
| Usage Rules: The value of the Test_data_type subparameter must be either
| "single_ended" or "differential."
|
| The subparameters specify the electrical parameters
| associated with a fixed generic test load. The diagram
| below describes the single_ended test load.
|
| All subparameters except Test_data_type are optional.
| If omitted, series elements are shorted and shunt elements
| are opened by default.
|
|
| V_term1
| o-----------o
| | |
| \ \
receiver_model_name
| ______ / /
______
| | | NEAR Rp1_near \ \ Rp1_far FAR |
|
| | |\ | / / | |\
|
| | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \
|
| | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-|
> |
| | | / | | | | Td | | | | | /
|
| | |/ | | C1_near | \ Zo \ | C2_far | | |/
|
| |______| === === / / === ===
|______|
| | C2_near | \ \ | C1_far |
| | | / / | |
| | | | V_term2 | | |
| o--------------o o-----------o o--------------o
| | Rp2_near Rp2_far |
| GND GND
|
|
| If the Td subparameter is present, then the Zo subparameter
| must also be present. If the Td subparameter is not
present,
| then the simulator must remove the transmission line from
| the network and short the two nodes to which it was
| connected.
|
| V_term1 defines the termination voltage for parallel
| termination resistors Rp1_near and Rp1_far. This voltage
| is not related to the [voltage range] keyword.
| V_term2 defines the termination voltage for parallel
| termination resistors Rp2_near and Rp2_far.
|
| Receiver_model is optional and indicates which, if any,
| receiver is connected to the far end node. If not used, the
| network defaults to no receiver.
|
| If Test_load_type is differential, a the test load is a
| pair of the above circuits. If the R_diff_near
subparameter
| is used, it is connected between the near nodes of the two
| circuits. If the R_diff_far subparameter is used, it is
| connected between the near nodes of the two circuits.
|
|---------------------------------------------------------------------------
--
|
[Test Load] Load1
Test_load_type single_ended
C1_near = 1p
Rs_near = 10
Ls_near = 1n
C2_near = 1p
Rp1_near = 100
Rp2_near = 100
Td = 1ns
Zo = 50
Rp1_far = 100
Rp2_far = 100
C2_far = 1p
Ls_far = 1n
Rs_far = 10
C1_far = 1p
R_diff = 100
Receiver_model Input1
| variable typ min max
Vterm1 1.5 1.4 1.6
Vterm2 0.0 0.0 0.0
|
| Example Transmission Line and Receiver test load from "I/O Buffer
Accuracy
| Handbook," section 3.4.4.
|
[Test Load] Tline_rcv
Td = 1n
Zo = 50
Receiver_model Input1
|---------------------------------------------------------------------------
--
****************************************************************************
***
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an
attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is
actually more compact and efficient because it allows multiple models to
access the same [Test Load]. Recommendations came from Bob Ross, Al Davis,
and the IBIS Open Forum, 3/2/01.
Changes between BIRD 69.1 and BIRD 70:
1. Scope of the "generic test load" is now global rather than being
local to a particular model. This is a big improvement.
2. Added one subparameter, Golden_test_load, to [Rising Waveform],
[Falling Waveform] keywords. Added text to describe new the
subparameter.
The Golden_test_load subparameter calls a [Test Load].
3. Exported all the other code to the new [Test Load] keyword.
4. Removed T_ref subparameter. To do timing correlation, the simulator can
pick a point on the 50 Ohm VT waveform as its "SPICE reference point"
and
then simulate both the 50 Ohm load and the Golden_test_load to calculate
a time difference.
5. Removed Pkg_pin parameter. It is too complicated. The user can model a
simple single-pin lumped circuit using the parameters supplied.
6. Added Tline_present subparameter. If not used, the Tline should be
removed from the simulation rather than assigned a very small delay
value.
This prevents the simulator from taking ridiculously small time steps.
7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters.
This makes the BIRD more economical.
8. Got rid of the paragraph that read, "Using the Golden Waveform
tables..."
This seemed to be redundant.
9. Specified which parameters are optional and which are required.
Changes between BIRD 70 and BIRD 70.1:
1. Moved the Golden Waveforms OUT of the [Model] scope and under the
scope of a new keyword, [Test Data].
2. Changed [Rising Waveform] to [Rising Golden Waveform].
Changed [Falling Waveform] to [Falling Golden Waveform].
3. Added subparameter Driver_model under [Rising Golden Waveform] and
[Falling Golden Waveform]. This is necessary because the waveforms
are now outside the scope of the [Model].
4. Changed the subparameter Golden_test_load to Test_load.
5. Added the V_meas subparameter to indicate where timing correlation
measurements should begin and end.
6. Added subparameters Test_data_type and Test_load_type to facilitate
upward compatibility with future versions of IBIS.
7. Removed Tline_present subparameter in favor of language explaining
that the simulator should remove the Tline if Td is not present.
8. Moved Driver_model, Test_load, V_meas under the scope of [Test Data].
9. Added T_meas subparameter to facilitate timing correlation.
10. R_diff became R_diff_near and R_diff_far.
11. Added T_period subparameter to allow multi-cycle correlation in the
case where a reflection hits the driver while it is switching.
BIRD 70.1 adds 205 lines of code to IBIS, of which 162 are comments.
****************************************************************************
***
ANY OTHER BACKGROUND INFORMATION:
See BIRD 69.1.
****************************************************************************
***
Received on Mon Apr 16 12:23:19 2001
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT