Minutes from the 12 July ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
12-JUL-2016 Bob Ross Teraspeed Pin Reference Concerns (zip
<http://ibis.org/macromodel_wip/archive/20160712/bobross/Pin_Reference_Concerns.zip>
)(pptx
<http://ibis.org/macromodel_wip/archive/20160712/bobross/Pin%20Reference%20Concerns/ross_reference.pptx>
)
IBIS Macromodel Task Group
Meeting date: 12 July 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
* Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
* Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Ambrish to check for a collaborator's feedback on his nearly ready new
version of the Backchannel proposal.
- In progress. Ambrish reported that he had recently heard back from one of
the collaborators and would be reviewing their input.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Bob R.: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
New Redriver Flow Proposal:
- Discussion: Fangyi reported that he continues to work on drafting the actual
BIRD.
Improved C_comp proposal:
- Discussion: Randy noted that he has an updated BIRD draft ready to be
introduced. (Note: We did not get to this topic, as Bob Ross' "Pin
Reference Concerns" presentation (below) took the entire meeting).
Pin Reference BIRD:
- Bob R.: [sharing "Pin Reference Concerns" presentation]
- [slide 2 - Main Points]
- Editorial comments on the BIRD text itself.
- Threshold subtleties (scaling) too big a topic and a separate topic that
should not be discussed in this BIRD.
- Alternate interpretations of the purpose of the [Pin Reference] BIRD?
- [slide 3 - Editorial Comments]
- Put this section after the last keyword where a bus_label can be declared.
- Avoid forward referencing, and utilize the fact that bus_label and
signal_name will be well defined already.
- Remove pin_name as a sub-parameter.
- The first column used in the keyword (pin_name in this case) is not
typically listed as a sub-parameter.
- Remove "with model thresholds" at the end of the first sentence in Usage
Rules. Don't open Pandora's box and discuss thresholding here.
- Strike various language defining bus_label or signal_name. They are
properly described earlier in the spec.
- Also, suggest adding a sentence stating that each line in the [Pin
Reference] has a first column containing the pin_name and a second
column containing the bus_label (signal_name), as is done in the
Usage Rules section of other keywords.
- [Slide 4 - Editorial Comments continued...]
- In the Other Notes section, add "described later in the Buffer Modeling
Section" to handle the forward referencing of the [* Reference] keywords.
- Also add a forward referencing statement for the mention of C_comp.
- Possibly controversial: Suggest that for ECL models the EDA tool should
use the pullup_ref entry under the [Pin Mapping] keyword.
- [Slide 5 - Editorial Comments continued...]
- Cleanup of the Example:
- Remove VSS, it doesn't exist in this example.
- Change VEE to -3.2V, a more traditional value.
- Could delete the [Model] section but provide voltage details as
comments in the [Pin] section.
- Could add an Output Pin example as a second entry in [Pin Reference].
- (Note: the indention of the [Pin Mapping] keyword on this slide is a
simple typo).
- We might consider adding a second example, for example RS232.
- [Slide 6 - Legal ECL Test Setup and Operation]
- In a real PECL device Vss does not always exist.
- Schematic representation of a real set-up for extracting timing test
load sample waveforms or for v(t) extraction.
- No Ground Pin connection. No device Pin connected to test fixture ground.
- Vee at -3.2V relative to test fixture ground.
- Vcc at 2.0V relative to test fixture ground.
- "Device Under Test" symbol represents die and package. Lines that touch
that symbol are the pin and probe locations on the DUT.
- [Slide 7 - C_comp]
- Possible complications for choosing a default reference terminal for ECL.
- [Slide 8 - PECL Gate with a Normal Load]
- Not concerned with the Input portion for this discussion.
- Everything in the "box" on the figure is in the Silicon. The package is
is also included in the box.
- Discussion: Walter noted that the picture has 4 pins on the right side
(VCC, VEE, Vout+, Vout-). He asked where the ground symbol on the
schematic (inside the "box") was connected. Bob stated that it might be
connected to Vee. Walter said in that case Vee would be "0V", but otherwise
that ground symbol must represent a connection to some other pin on the
device, right? Bob asked that we wait until we reviewed the other slides
before addressing this question.
- [Slide 9 - PECL IBIS Output Simulation]
- IBIS Model setup. No different than slide 8.
- The Pin Interface is the bold dashed line.
- Right hand side of this line is the measurement extraction setup.
- Discussion: Walter asked what the on chip reference point for the VCC = 5.0V
shown on the left of the dashed line would be. Arpad suggested that the
ground symbol shown on the left side was actually connected to the VEE line
shown, and that it would be the reference terminal. Radek agreed and noted
that the assumptions that were not spelled out were that Vref is driven with
VCC - 2.0V, and that VEE is implicitly considered the same as ground in this
example. The Vref is driven externally (that info not even known to the
IBIS file), and the assumption is that the receiver at the other end would
be properly biased as well. Bob suggested that the following slide would
get to the heart of Walter's line of questioning.
- [Slide 10 - Split PECL IBIS Output Simulation ... No VSS Pin]
- This is the case Walter is trying to get at.
- VCC = 2.0V, VEE = -3.2V. Those are the only two voltages provided to
the device.
- One of the conclusions of the [Pin Reference] discussion had been that
there must be a test fixture ground reference VSS Pin. [this split PECL
is a counter example]
- Discussion: Arpad noted that this slide also contained the Vcc and the
ground symbol on the left side of the dashed line. He asked if the
ground symbol would be considered connected to the VEE or the GND shown
on the right (external). Bob said that in the IBIS model is not clear,
and the note (bottom left) points out that some tools might connect it
to VEE in any event. Walter asked how one could measure VCC = 2.0V on
the Silicon, and Bob said that you could not do so in this split PECL
configuration. All one could measure on the Silicon was (VCC,VEE) = 5.2V.
Bob noted that the external voltage circuitry being driven by a PECL
device is critical to the flow, and that there really is no "VSS = 0V"
Pin anywhere on this device. Bob said that such a device could be modeled
with an IBIS file that had only -3.2V and 2.0V provided as [* Reference]
values, and tools could simulate it properly by assuming a global ground
"node 0" GND. Radek noted that we have to distinguish between measurement
setup and simulation. This figure, Vref = 0, is showing the specific
biasing for setting up the Vfix, Rfix, etc., and doing the extraction.
When you have this device in action, then you don't have this 0.0V and all
you have is the 5.2V difference between the rail terminals. Now the
output voltage has to be properly defined with respect to what? Walter
said he thought this was pointing back to his DUT_ref_terminal BIRD, which
would have allowed VEE to be specified as the reference terminal, other
terminal voltages (Pullup_reference and Vout) to be computed relative to
VEE, and then the -3.2 would be added back in to those values to convert
back to the DUT conditions recorded in the IBIS file. In this case, one
would have to reference Vout and VCC to VEE. In other cases, like RS232,
one would make measurements relative to an actual ground pin. To get a
voltage value to compare to the values in the IBIS file, one would compute
(Vout,Vee) + (-3.2V). In the current version of the BIRD, you would
specify the bus_label corresponding to the VEE signal_name coming into
the package for this example. For RS232C, the signal_name would be VSS
instead. Bob agreed and noted the VSS would be a different Pin in the
RS232C example.
- [slide 11 ECL Output (another example)]
- Here VCC is 0V, which is another standard configuration.
- In this case the GND symbol might go to VCC.
- Discussion: Radek noted that here one could define the bus_label
corresponding to VCC as the reference. In the earlier split PECL example
one could define the bus_label corresponding to VEE as the reference. One
could also want to provide a bus_label other than VCC or VEE, and you
would need a separate bus_label to provide that reference, but the
combination of the [Pin Reference] and [DUT_ref_terminal] would facilitate
this. Bob noted that there was no disagreement regarding [Pin Reference]
itself working for PECL and ECL, but for split PECL there exists a
legitimate configuration with no VSS Pin. So for split PECL one could
choose VCC or VEE as the reference (most likely VCC for other reasons).
- [slide 12 Reference Rail]
- VSS pin (DUT test fixture ground connection) may not always exist.
- Since [* Reference] contains an ideal voltage relative to DUT test
fixture ground, a non-zero value is just as good a reference as a zero
value.
- [slide 13 - Suggestions, Actions]
- Modify the example.
- Perhaps add a different default rule for ECL.
- A terminal corresponding to a [* Reference] with a value of zero may not
always be the best choice for reference.
- Be careful using this for thresholds.
- Discussion: Walter noted that the last point (thresholds) was related to the
scaling issue (if the DIA rails are not simply uniformly shifted relative
to the DUT rails then one has to be careful with threshold scaling), and
that this is a separate issue for which IBIS doesn't yet have a complete
solution. Walter asked if Bob was concluding that an EDA tool could simply
use any one of the rails as reference, shift the relative voltages measured
with respect to that reference as they see fit, and that we don't need this
BIRD it all? We would state that in IBIS the GND, ground symbol, node 0,
are simply referring to what's done for device under test. At simulation
time, however, one should not assume node 0 is meaningful, as all
measurements must be relative to rails at the buffer terminal. Bob said he
wasn't ready to dismiss the [Pin Reference] BIRD, but that Walter's
statement might be correct. Radek reiterated his position that we should
move in the direction of letting the model maker specify the reference for
the Vout. Bob noted that [Pin Reference] may be necessary for power aware
simulations, and that he was not opposed to the BIRD itself, just its
assumption that a Vss pin must always be present.
- Arpad: Thank you all for joining.
-------------
Next meeting: 19 July 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
