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

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: james.zhou@xxxxxxxxxx
  • Date: Wed, 19 Dec 2012 20:40:23 -0500

To further clarify what Arpad has said, full isolation is required between
the AMI behavoral model and the channel analog models in order to define a
unique impulse response.  It is not correct to say that there is no
electrical connection.  There is.  But Arpad is correct in saying that
there are no electrical interactions between the AMI and the analog models.
This "isolation" also exactly mimics the way that standard IBIS driver and
receiver models work.


On Wed, Dec 19, 2012 at 8:10 PM, James Zhou <james.zhou@xxxxxxxxxx> wrote:

>  Arpad,
>
>
>
> Thanks for the clarification.
>
>
>
> James
>
>
>
>
>
> *From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:
> ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Muranyi, Arpad
> *Sent:* Wednesday, December 19, 2012 5:00 PM
>
> *To:* ibis-macro@xxxxxxxxxxxxx
> *Subject:* [ibis-macro] Re: Analog Buffer Model Inside DLL
>
>
>
> “So, are the analog buffer and AMI block connected or not? ”
>
> In the real physical world they are, i.e. EQ, CDR, DFE, etc…
>
> are connected to the analog “front end” of the buffer, but in
>
> IBIS-AMI simulations the specification treats them as two
>
> independent animals.  According to the IBIS-AMI spec, they
>
> are not connected in an electrical sense, i.e. there are no
>
> voltages and currents flowing between the analog models and
>
> the AMI DLL-s and consequently no electrical interactions are
>
> possible between the two domains.  The AMI DLL only supposed
>
> to know about the analog model through the impulse response
>
> of the channel.
>
>
>
>
>
> “Is this connection point (or "isolation point" as you have been
> referring it as)
>
> the same as D_drive or A_signal in Table 12 (also depicted in  Fig 19) of
> IBIS 5.1? ”
>
>
>
> It is D_drive, not A_signal.
>
>
>
> I hope this helps,
>
>
>
> Arpad
>
> ================================================================
>
>
>
>
>
> *From:* James Zhou [mailto:james.zhou@xxxxxxxxxx]
> *Sent:* Wednesday, December 19, 2012 6:30 PM
> *To:* Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
> *Subject:* RE: [ibis-macro] Re: Analog Buffer Model Inside DLL
>
>
>
> Hi Arpad,
>
>
>
> Your comments help to clarify the spec on some issues and are appreciated.
>
>
>
> With the sole purpose of correctly interpret the spec, when putting your
> words  together with the spec, I couldn't make sense out of them:
>
> Arpad:     In IBIS v5.1 the analog buffer models were not intended to be
> connected to the AMI model using such electrical connections.
>
> IBIS 5.1:     The transmitter equalization, receiver equalization and
> clock recovery circuits are assumed to have a high-impedance
> (electrically isolated) connection to the analog portion of the channel.
>
>
>
> So, are the analog buffer and AMI block connected or not?
>
>
>
> Is this connection point (or "isolation point" as you have been referring
> it as) the same as D_drive or A_signal in Table 12 (also depicted in  Fig
> 19) of IBIS 5.1?
>
>
>
> James
>
>
>
>
>
>
>
>
>
>
>
> *From:* ibis-macro-bounce@xxxxxxxxxxxxx [
> mailto:ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx>]
> *On Behalf Of *Muranyi, Arpad
> *Sent:* Wednesday, December 19, 2012 3:20 PM
> *To:* ibis-macro@xxxxxxxxxxxxx
> *Subject:* [ibis-macro] Re: Analog Buffer Model Inside DLL
>
>
>
> 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.
>
>
>
> 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 <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
>
>
>  ------------------------------
>
>
> This message and any attached documents contain information from QLogic
> Corporation or its wholly-owned subsidiaries that may be confidential. If
> you are not the intended recipient, you may not read, copy, distribute, or
> use this information. If you have received this transmission in error,
> please notify the sender immediately by reply e-mail and then delete this
> message.
>
> ------------------------------
>
> This message and any attached documents contain information from QLogic
> Corporation or its wholly-owned subsidiaries that may be confidential. If
> you are not the intended recipient, you may not read, copy, distribute, or
> use this information. If you have received this transmission in error,
> please notify the sender immediately by reply e-mail and then delete this
> message.
>



-- 

Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Road
Falmouth, ME 04105

(401) 284-1827 Business

http://www.teraspeed.com

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC

Other related posts:

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