[ibis-macro] Re: [ibis-interconn] Fundemental Problems with Externam Models and IBIS-ISS
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 12 Dec 2012 21:01:42 +0000
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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
- » [ibis-macro] Re: [ibis-interconn] Fundemental Problems with Externam Models and IBIS-ISS - Muranyi, Arpad
