[ibis-macro] Re: Analog Buffer Model Inside DLL

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 19 Dec 2012 23:19:49 +0000

James,

You caught me!  … but not quite…

Changing the wording of that sentence to clarify what it says
might be a little different from adding a bunch of technical
details that hasn’t been mentioned in the spec yet.

In the framework of IBIS v5.1, that sentence seems to be sufficient
in what it says.  In v5.1 legacy [Model]-s are two-port blocks
between the signal pad and ground and/or power, but there is no input
to output relationship as in a 4-port.  On the Tx side, [External
Model] is kind of an exception when the external model’s language
can only have analog ports (SPICE and Verilog-A) because these
can have an input port as well, but note that IBIS v5.1 really
doesn’t provide connection access to these inputs to the external
world.  The same is also true on the Rx side.  An [External Model]
Rx might have an output port, but again, IBIS v5.1 doesn’t provide
connection access to this port for the outside world.

In IBIS v5.1 the analog buffer models were not intended to be
connected to the AMI model using such electrical connections.
The analog model was supposed to be used to generate the impulse
response of the channel and the AMI DLL-s were supposed to be
working with the impulse response of the channel, but not the
analog models in the channel.

I am not saying that these types of flows couldn’t be done in
practice to achieve the same results.  I am just explaining
what IBIS v5.1 says and what is “legally” possible in IBIS v5.1.

Having said all this, I don’t see why there is a need in IBIS
v5.1 to spell out rigorously what the driving and loading
impedances are at that isolation point.  That point is not
available for electrical connections for the user or the model
maker as far as IBIS v5.1 goes.  This is why I thought it might
be “sufficient” as is within the v5.1 framework.


On the other hand, I agree completely that as soon as we extend
[Model] and/or [External Model] to the world of S-parameter
modeling, we will need a more detailed definition for this
boundary.  This is why I wrote BIRD 152 (to accompany BIRD 116).
So your suggestion to write BIRDs to clarify the boundary
conditions has already been taken care of.

The only issue that I see left is the discussion on the nature
of the input port to the Tx [Model]s and the output port of the
Rx [Model]s.  This is a new topic that surfaced after BIRD 116
and 152 were written and submitted, so this topic is not addressed
in them.  I was hoping to have some discussion on that in the
Interconnect meeting today, but we didn’t get to it.

I hope this clarifies the apparent contradiction you found in
my words.

Thanks,

Arpad
===================================================================


From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Wednesday, December 19, 2012 3:42 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL

Arpad,

The comment  of  "that sentence, as it is written today in v5.1 is actually 
sufficient"
seems to contradict with your earlier comment of   "I agree, the wording could 
be better"

It was recommended in yesterday's call  to draft a new BIRD to clarify this 
part of the 5.1 spec. Due to the fact that the work group had spent much time 
debating this issue, using some simple math (which of course we had all failed 
terribly in school) together with word engineering might be the way to go in 
drafting the proposed new BIRD.

James

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2012