Radek,
Thanks for your response.
Regarding “Somewhat disagree. V is mentioned in the text (see above).”, you are
correct,
“V” is mentioned in the text in the equations. But I still think that the
labeling in the drawing
and the explanation in the text gives the reader an “out of touch with each
other” kind of
feel. We could/should do better on that.
Regarding “…but I do not like confusing “ports” and “terminals”.” The reason I
did not delete
the words “terminals” is because the terminology in BIRD189 uses “Buffer
Terminal” for this
specific location. What we should say then is something like “…ports connected
to buffer
terminals…” I want to make sure that the reader of the spec knows that these
are the same
location.
Regarding your comment on the package issue:
“I agree with your modifications up to the highlighted text. However, I believe
the consensus at the ATM meeting of June 27 was in line with the original text.”
The biggest problem I have with the original text is that it makes the
following statement:
“Please note that the package data is added to the channel by the user using
user’s own data or using some other vendor’s data.”
This is simply not true, i.e. wrong. Nowhere in the IBIS specification are we
saying that the package
model is added by the user manually. IBIS has package keywords for the reason
so that the
user would NOT have to do that. With BIRD189 this will be even more true,
since the new
syntax will provide high quality package models, and actually usable models.
The fact that this was
done manually in the past was due to the IBIS package models being useless…
But that is changing
now with BIRD189. We should not promote something that is going in the
opposite direction of
what the spec’s intent was/is. I don’t mind provisions for an override
mechanism, but that
should not be the “mainstream” thing we discuss/promote in the spec.
So, how do you plan on going forward from here? Are you going to make another
draft, or
are we going to have more discussion on this in the ATM meeting or this email
reflector
before you are going to make any changes to the draft? In other words, I
wonder how we
are going to come up with something that is agreeable to all of us?
Thanks,
Arpad
=============================================================================
From: BIERNACKI,RADEK (K-Sonoma,ex1) [mailto:radek_biernacki@xxxxxxxxxxxx]
Sent: Tuesday, July 18, 2017 1:43 PM
To: wkatz@xxxxxxxxxx; Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: FW: Comments on BIRD158.6 draft2
Hi Arpad/All,
Thanks for your efforts to improve this BIRD. I agree and like some of your
modifications but disagree with others. My comments are as marked below inside
of your text.
Best regards,
Radek
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, July 13, 2017 6:42 PM
To: Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: FW: Comments on BIRD158.6 draft2
Arpad,
I totally agree with the changes you have made.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, July 11, 2017 3:44 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] FW: Comments on BIRD158.6 draft2
According to the request in today’s ATM meeting, I am forwarding my comments
on BIRD158.6 draft2 to the ATM reflector. Questions, comments, suggestions are
all welcome…
Thanks,
Arpad
=================================================================
From: Muranyi, Arpad
Sent: Wednesday, June 28, 2017 6:14 PM
To: 'radek_biernacki@xxxxxxxxxxxx'
<radek_biernacki@xxxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxxx>>
Subject: Comments on BIRD158.6 draft2
Radek,
I am sending this to you privately, because I have a lot of things to pick on
and don’t want to do it publicly to avoid any embarrassment, etc… Maybe
after we converge on something we can go public…
The following sentence sounds a little awkward to me:
“This section discusses alternative analog buffer modeling devised specifically
for AMI applictions.”
Maybe something along these lines would be better (but I would leave it up
to native English speaking people to find the best wording):
“This section discusses an alternative analog buffer modeling technique,
specifically designed for AMI applications.”
RB >> I am ok with either of the above.
The voltage labeling on the “transmitter analog circuit” drawing and the text
below it seems to be “out of touch” with each other.
“The voltages of the voltage sources correspond to V=Tx_V for logic level 1,
and V=-Tx_V for logic level 0.”
I don’t see any “Tx_V” in the drawing. Also, the “Vdc” notation in the drawing
seems to be misleading because these sources are NOT DC voltage sources,
these are bit patter sources. Also, the drawing uses “V/2” for the value of
these
sources, but I don’t see “V” being mentioned in the text anywhere… In addition,
this paragraph doesn’t mention Tx_R at all, and I think it should explain that
too.
I think the text and drawing should match.
RB >> Somewhat disagree. V is mentioned in the text (see above). I agree that
both Tx_V and Tx_R could be mentioned here as being defined later in the
definitions of the new keywords. The actual sources are neither DC nor bit
pattern sources. The only purpose of showing these source is to identify the
low and high states via the expressions relating to the value specified under
the new reserved keyword “Tx_V”.
My next comment is a minor thing, but may eliminate misinterpretations later.
I would change this sentence:
“Ports 1 and 3 are at the stimulus source side, and ports 2 and 4 are connected
to the buffer terminals.”
to:
“Ports 1 and 3 are at the stimulus source side, and ports 2 and 4 are the
transmitter buffer’s output terminals.”
RB >> I agree, but I do not like confusing “ports” and “terminals”. I would
keep your text after removing the word “terminals”.
In the receiver analog circuit description section, I would change this
sentence:
“Ports 1 and 3 are connected to the buffer terminals, and ports 2 and 4 serve
as the differential input to the Rx algorithmic model.”
to:
“Ports 1 and 3 are the receiver buffer’s input terminals, and the waveforms
obtained at ports 2 and 4 represent
the channel’s response that is used for the AMI simulations.”
We can work some more on the exact wording, especially the 2nd half of this
sentence, but the main point here is that the waveform at ports 2 and 4 are
not the input to the Rx AMI model. (If anything they are the input to the
Tx AMI_Init function)…
RB >> I agree only partially. I would use your first modification but without
the word terminals and would keep the rest unchanged. We are talking about
connections (the order of ports in the data) and any references to the
waveforms obscures the point. You are trying to re-explain the AMI flow here
while this should be clear enough simply because of the scope of the models
discussed here. In other words I would have the following.
“Ports 1 and 3 are the receiver buffer’s input, and ports 2 and 4 serve as the
differential input to the Rx algorithmic model.”
The following two paragraphs have multiple problems:
“The IBIS AMI flow requires that the EDA tool generates the impulse response of
the entire analog circuitry from Tx to Rx algorithmic models. Typically, the
Touchstone file data specified here is to be used for either the Tx analog
buffer excluding the Tx package model and/or the Rx analog buffer model
excluding the Rx package model. In the preceding sentence the term “package”
may mean just the package or the package together with the on-die interconnect.
The following figure illustrates the corresponding entire setup when both Tx
and Rx use the Ts4file parameter.”
“Please note that the package data is added to the channel by the user using
user’s own data or using some other vendor’s data. This means that the Tx or
the Rx analog circuits specified in the AMI file are to be used in lieu of the
analog buffer model. This can be modified by another new reserved AMI parameter
Ts4file_Boundary. In any case the package and possibly the on-die interconnect
data associated with the IBIS model pointing to this AMI file via the
[Algorithmic Model] keyword shall not be automatically incorporated into the
above schematic by the EDA tool.”
The 1st sentence may sound better this way:
“The IBIS AMI flow requires that the EDA tool generates the impulse response of
the entire analog circuitry including the Tx and Rx analog buffer models.”
RB >> Only partially agree. An impulse response is “from-->to”. Your addition,
while accurate (and I do not object adding it) removes that aspect of the
impulse response.
The rest of this paragraph and the following paragraph could be combined and
simplified like this for easier reading:
“Typically, the Touchstone file data specified here will be used to describe
only the analog behavior of the buffer itself, excluding the effects of the
package and/or the on-die interconnect, as illustrated in the following figure.
This way the Tx or Rx analog circuits specified in the AMI file may be used as
a direct replacement for the corresponding analog model described by the
[Model] keyword. However, the model maker may choose to include the package
and/or on-die interconnect model in the Touchstone file data. The new reserved
AMI parameter Ts4file_Boundary shall be used by the model maker to inform the
EDA tool about the content of the Touchstone file. If the model maker includes
the package effects in the Touchstone file (i.e. Ts4file_Boundary is set to
“pin”), the EDA tool must ignore the package model in the IBIS file. If the
package effects are not included in the Touchstone file (i.e. Ts4file_Boundary
is set to “buffer” or “pad”), the EDA tool shall provide a selection mechanism
for the user to decide whether to automatically include the applicable package
model from the IBIS file or not. This gives the user an option to manually add
other package and/or on-die interconnect models to their simulation setup.”
RB >> I agree with your modifications up to the highlighted text. However, I
believe the consensus at the ATM meeting of June 27 was in line with the
original text. The point is that, most frequently, this Ts4file model is to
bypass the calling IBIS model and therefore the calling IBIS model is a simple
“stub” with no meaningful package data. The original text neither prohibits nor
imposes what the EDA tool setting options should be.
The content of the next paragraph should be moved up to the text below
the transmitter analog circuit and the text below the receiver analog circuit.
“For Tx models that have the reserved parameter Ts4file, the reserved parameter
Tx_V is required and the reserved parameter Tx_R is optional. For Rx models
that have the reserved parameter Ts4file, the reserved parameter Rx_R is
optional. In other words, for a Tx buffer, the transmitter circuit defines the
analog buffer model between the zero impedance stimulus input voltage source
and the buffer terminals. For an Rx buffer, the receiver circuit defines the
analog buffer model between the buffer terminals and a high impedance probe at
the input to the Rx Algorithmic model.”
RB >> I agree, the placement of what is optional is now improved. Yet, still
the forward reference of the new reserved keywords may further improve the text.
I am not sure what the purpose of the last paragraph is:
“Given that the Touchstone 4-port model is LTI there are many methods of
generating the impulse response to be used in AMI modeling that will give the
identical result within numerical accuracy of the technique chosen. One
technique commonly used in EDA tool simulation is to generate the impulse
response by applying a step stimulus and calculating the time derivative of the
response. When both Tx and Rx Ts4file parameters are present the impulse
response is measured between the SRC_pos/SRC_neg input and a high impedance
differential probe between ports 2 and 4 of the Rx 4-port network. When only
one of Tx or Rx .ami files has the Ts4file parameter present then the other
component’s contribution to the impulse response comes from the model details
provided under the [Model] keyword referencing the .ami file without the
Ts4file parameter.”
The 1st sentence really doesn’t say anything. The 2nd sentence basically
contradicts the purpose of this entire approach, which is to be able to do
the channel response without a time domain step response simulation.
The 3rd sentence is kind of obvious, but could be combined with what I
suggested in my change in the receiver analog model text. The last sentence
doesn’t say what it really should say, which is that in the mixed model case
we have to resort back to the time domain step response simulation approach…
RB >> I have never been in favor of that paragraph. That was also one of the
confusing issues raised by Michael Mirmak. It’s been a massaged version of an
original text coming from the first draft of this BIRD several years ago. I
will be happy to remove it entirely.
I didn’t read the rest of the document yet. But in order to make it easier
for you, I am attaching my version of this BIRD including all the changes I
suggested above. I did an accept all changes on your document, and turned
on the tracking after that, so the marked changes you see are only my changes.
Let me know if you want to get together on the phone to discuss these
suggestions.
Thanks,
Arpad
================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Curtis Clark
Sent: Wednesday, June 28, 2017 12:46 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Minutes from the 27 June ibis-atm meeting
Minutes from the 27 June ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been posted
to the ATM work archives.
DATE
AUTHOR<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibis.org%2Fatm_wip%2Farchive-author.html&data=01%7C01%7Cradek_biernacki%40keysight.com%7C7b9b250547fc49f9940408d4ca597c09%7C63545f2732324d74a44dcdd457063402%7C1&sdata=o%2BPpqfvJUxySvGSSiIbaGDqHKK%2FgOC5G9bfe2%2Fyttis%3D&reserved=0>
ORGANIZATION<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibis.org%2Fatm_wip%2Farchive-org.html&data=01%7C01%7Cradek_biernacki%40keysight.com%7C7b9b250547fc49f9940408d4ca597c09%7C63545f2732324d74a44dcdd457063402%7C1&sdata=KBqWtyJtbAmcCENHfsTvw0RwN6wtjOYRsyy5fBEhmcg%3D&reserved=0>
TITLE<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibis.org%2Fatm_wip%2Farchive-title.html&data=01%7C01%7Cradek_biernacki%40keysight.com%7C7b9b250547fc49f9940408d4ca597c09%7C63545f2732324d74a44dcdd457063402%7C1&sdata=3nkIx41MUJQVU3Y1OsXHBV102J2FVbw1QdcGclLp00E%3D&reserved=0>
FORMATS
27-JUN-2017
Radek Biernacki
Keysight Technologies
BIRD 158.6 draft 2
(zip<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibis.org%2Fatm_wip%2Farchive%2F20170627%2Fradekbiernacki%2FBIRD_158_6_draft_2.zip&data=01%7C01%7Cradek_biernacki%40keysight.com%7C7b9b250547fc49f9940408d4ca597c09%7C63545f2732324d74a44dcdd457063402%7C1&sdata=8dRww3hWdxGtDqJhXGbFZvz849yw7q8xVD13NZvzV9s%3D&reserved=0>)(docx<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibis.org%2Fatm_wip%2Farchive%2F20170627%2Fradekbiernacki%2FBIRD%2520158.6%2520draft%25202%2FBIRD_158.6_draft2.docx&data=01%7C01%7Cradek_biernacki%40keysight.com%7C7b9b250547fc49f9940408d4ca597c09%7C63545f2732324d74a44dcdd457063402%7C1&sdata=5MzW66EDWvwGTT%2BZGTANV1phkm9AKXuvQ1TDwDxRdW8%3D&reserved=0>)
