[ibis-macro] Re: [ibis-interconn] Re: Fundemental Problems with Externam Models and IBIS-ISS
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'IBIS-Interconnect'" <ibis-interconn@xxxxxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 13 Dec 2012 14:35:52 -0500 (EST)
All,
I would like to respond in the two applications of IBIS models,
SerDes/AMI, and normal Buffer Models.
Normal Tx Buffer models do require a Stimulus which have transition
events, and therefore need a D_to_A converter to satisfy the internal
requirements of the [External Model] internal threshold levels to
determine the transition times. Normal Rx Buffer models did not require a
A-to_D converter, since the IBIS Model did have receiver threshold levels.
So in retrospect [External Model] did require a D_to_A converter, the Rx
A_to_D converter was superfluous. IBIS-ISS has no threshold sensing
capability and everything else required to handle non-linear IV curves and
anything other than a VT stimulus that is linear between a low and high
stimulus voltage level.
SerDes/AMI Tx and Rx buffer models implicitly require that the buffer is
LTI, and therefore the static Tx pullup and pulldown IV curves be linear.
The shape of the VT curve is academic since this has only high frequency
content which is quickly filtered out in any realistic channel. The static
Rx clamp curves must also be linear to satisfy being LTI. Arpad pointed
out quite correctly that the "Equivalent Circuit" Tx and Rx buffer models
described in BIRD 122 can represent exactly any IBIS legacy model with
linear IV curves.
ALL IC vendor internal tools represent the analog Tx and Rx buffer as
either a Equivalent Circuit described in BIRD 122 or an s4p Touchstone
file described in BIRD 122. In these tools the time domain waveforms are
generated by applying the waveform generated by the Tx digital signal
processing directly to an analog channel that includes the one of theTx
buffer analog models described in BIRD 122 and one of the Rx buffer analog
models described in BIRD 122 . In AMI terms, this waveform is the output
of the Tx AMI_Getwave convolved with the channel impulse response. In
SPICE simulation, the channel is represented as a series of concatenated
IBIS-ISS subckts and the simulation is a simple SPICE time domain
simulation with a differential stimulus being simply the output of Tx
AMI_Getwave. The simple Equivalent Circuit buffer models described in BIRD
122 are sufficiently accurate for SerDes buffers at data rates <~6Gbps. At
data rates >6Gbps they are not sufficiently accurate, and IC Vendors
therefore use Touchstone s4p models.
What do we need today and what do we need tomorrow for the next generation
of AMI modeling?
Today we absolutely need the ability to specify a Touchstone file for both
Tx and Rx AMI models. I believe all EDA vendors support his in their
tools, all we need is a clear method to define in an IBIS/AMI file the
name of the s4p and its required termination characteristics. We probably
do not absolutely need the Equivalent Circuits defined in BIRD 122. I
point out that it is not uncommon for a Tx buffer to have a large number
(~128) strength settings, with each strength setting having a different
impedance. If IBIS supported these Equivalent Circuits and Dependency
Tables only one [Model] and one AMI file is required. SiSoft builds such
models that only work in our tool. We also supply an IBIS file with a
Model Selector that contains 128 models and 128 .ami files to make these
models portable and work on all of the other EDA Vendor tools. Technically
these two alternative IBIS models are the same, but both IC Vendors and
Users of AMI models much prefer the Equivalent Circuit and Dependency
table method.
"Tomorrow" we will need to support PAM4. For PAM4 the "stimulus" has 4
levels (-.5,-.1333,.1333,.5). Tx and Rx DLLs are internally is more
complicated, but the interface and flows remain the same. The analog
buffer remains either an Equivalent Circuit or an s4p Touchstone file.
There may be additional Rx reserved parameters to do the appropriate PAM4
waveform analysis. Implementing PAM4 using BIRD 122 just falls out,
implementing in [External Model] is problematic because of the multi-level
signaling.
BIRD 122 defines reserved AMI parameters such as Tstonefile for Tx and Rx
s4p Touchstone File, and Rs and Cc for Tx IBIS-ISS Equivalent Circuit and
Rt and Cc for Rx IBIS-ISS Equivalent Circuit. With this approach there is
no need for the added complexity of delivering IBIS-ISS subckt files with
the IBIS model. I think we need to revisit the decision IBIS-ATM made that
analog models must be in the IBIS file.
Walter
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 12, 2012 4:02 PM
To: IBIS-Interconnect; IBIS-ATM
Subject: [ibis-interconn] Re: Fundemental Problems with Externam Models
and IBIS-ISS
Walter,
IBIS-ISS and IBIS-BSS might be one and the same thing in the
future, IBIS-BSS being a more general superset of IBIS-ISS
which includes a few new features which are not in IBIS-ISS
yet. We can just add the name of it to the list of languages
supported in [External ***], whatever it ends up being called.
Remember, we will most likely still go with the HSPICE syntax
in IBIS-BSS, provided we get permission from Synopsys to do so.
So IBIS-ISS is an HSPICE subset, and IBIS-BSS will be still an
HSPICE subset, except it will have more stuff in it.
The big issue here is the difference in our views (yours and mine)
about analog vs. digital stimulus for [Model]. I think this is
the "to be or not to be" question we need to figure out collectively
in our upcoming meeting(s).
I claim that even though the IBIS specification failed to clearly
spell this out in the versions before [External ***] were added,
the intention was always to treat the stimulus of [Model] as a
digital signal, or event. Time zero of the [Ramp], or the V-t
table is marked by an event which starts them off in a simulation
to get the transitions going on the analog output of [Model]. If
IBIS would have considered the stimulus to be an analog waveform,
IBIS would have defined threshold levels for them. Without such
thresholds you really don't know where the beginning of these
transitions are. This was also the reason that when we added the
[External ***] keywords, we had to go through the pain of defining
the D_to_A and A_to_D converters for the purely analog languages
(SPICE and Verilog-A).
Putting a 4-port S-parameter model reference into [Model] simply
does not work, because the stimulus side of the S-parameter
model would be interfacing a digital signal or event which
doesn't make sense.
My understanding is that having a 4-port [Model] is important for
you in the AMI context because you want to feed the output of
Tx GetWave into that 4-port analog model directly. Unfortunately
the AMI flow does not describe a flow like that, and [Model] was
not intended to be used like that either, as far as I can tell.
I see that this is a nice way to run AMI simulations, but if we
want to support this type of a flow in IBIS, we need to make more
substantial changes to the specification than just turning [Model]
into a 4-port analog model with a simple Touchstone subparameter
or keyword.
I know that you disagree with me on this, we had way too many
private emails and conversations on this before, but I think it
is time to discuss this openly in the committee meetings to
finally put an end to our disagreements with a solution that
is acceptable to the two of us and the entire industry.
So I would like to solicit others on these email lists to chime
in so we could get a better understanding of how this issue in
the IBIS specification should be resolved.
Thanks,
Arpad
==================================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, December 12, 2012 12:26 PM
To: IBIS-Interconnect
Cc: IBIS-ATM
Subject: [ibis-interconn] Fundemental Problems with Externam Models and
IBIS-ISS
All,
The two possible applications of [External Model] are SerDes/AMI, and
normal Buffer Models.
Normal Buffer Models are not LTI and therefore IBIS-ISS does not apply.
When IBIS-BSS (Buffer Subcircuits) is defined then one can consider adding
IBIS-BSS to [External Model]. IBIS-BSS is not LTI, uses PWL voltage
controlled sources, level sensors, and a time function. I point out that
IBIS would not consider EMD until IBIS-ISS was defined and approved.
SerDes AMI models do not have digital input and digital output. The A/D
and D/A converters make no sense. All of the stuff inside of [External
Model] makes no sense for LTI SerDes Tx and Rx models which just have
analog differential inputs and analog differential outputs. They are
always four port subckts. They can always be represented as an s4p, or the
IBIS-ISS subsckts described in BIRD 122.
The only functionality needed is to define some simple [Model] (or AMI
keywords) that either point to an s4p Touchstone file, or a couple of
simple template 4 port IBIS-ISS subckts.
So why have a complicated gobbledygook change to [External Model] when
[External Model] by definition does not address the needs of LTI,
SerDes/AMI buffers.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
- » [ibis-macro] Re: [ibis-interconn] Re: Fundemental Problems with Externam Models and IBIS-ISS - Walter Katz
