[ibis-macro] Re: Comments on BIRD 156.1
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: <fangyi_rao@xxxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 20 May 2013 18:09:55 -0700
Fangyi:
Is BIRD131 required to document the connectivity of Redriver Inputs and
Outputs?
If so, this should be stated and added to the documentation and example
e.g.,
[Repeater Pin] tx_non_inverting_pin
1p 2p
If not, then how do you document how to correctly identify a re-driver
Input and a re-driver output in the file?
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx
Sent: Monday, May 20, 2013 2:59 PM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Comments on BIRD 156.1
Thank Arpad, Walter, Ambrish, Bob, Michael and others in the ATM discussion
for all your input. I incorporated them into the attached revision of BIRD
156. Main modifications include
- Rephrase description of redriver Tx analog model
- Additional figure to illustrate simulation flow and replace Tx/Rx
triangle with pentagon (I hope you like the new shape for Tx/Rx J)
- Rephrase time domain flow description
- Add statistical flow
Thanks,
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, May 08, 2013 11:35 AM
To: IBIS-ATM
Subject: [ibis-macro] Comments on BIRD 156.1
Fangyi,
I took some time after the ATM meeting yesterday to re-read
BIRD 156.1 with a "fresh mind". I would like to make the
following comments:
#1) From an editorial point of view, you need to organize the
BIRD a little differently so we would know what is going to
go into the specification and where. Obviously, the "ANALYSIS
PATH/DATA THAT LED TO SPECIFICATION" section will not go
into the specification, but it is not clear whether you intended
everything that follows that paragraph to be in the specification
or not, and where in the spec should things be placed. Should
all this be a new chapter of its own, or added to an existing
chapter or keyword, and if the latter, which one. Please make
specific recommendations for that. This way the editorial
committee is not going to know what to do with the content of
the BIRD.
#2) Please try to follow the formatting of the existing specification
and use Courier New 10 font for the example.
#3) The following sentence seems to be somewhat problematic:
"Therefore, the output analog model is expected to describe an analog
circuit as oppose to the conventional digital-to-analog converter."
First a typographical correction: a "d" is missing from "as opposed to"
towards the end.
Second, the wording "conventional digital-to-analog converter" is
misleading.
I understand that you are trying to describe the nature of the [Model]
keyword which essentially "converts" a digital event stimulus to an
analog waveform in the simulation environment, but calling these
digital-to-analog converters doesn't seem to be appropriate, because
their functionality in the purpose of a simulation is not what a D/A
or A/D does, it is what an analog buffer does. I understand what your
reasons are for using these words, since this topic was discussed in
the recent months, but the reader of the spec will not know any of that
a few years from now, and I think this will be confusing to them.
However, the bigger problem with the above sentence is that you don't
explain how this can be achieved. Since the stimulus to [Model] is
a digital event (as you stated it) we can't use that keyword for this
purpose unless we make provisions for that somehow in this or another
BIRD. The same reasoning applies to [External Model] also. The only
keyword that could be used currently for buffer modeling with an analog
input in this way is the [External Circuit]. It would be nice if this
was explained in the BIRD and consequently in the spec and illustrated
in the example. The current example you have cleverly side steps this
by using "...". You might also want to establish some rules for this,
for example, that a redriver analog output model may only be modeled with
the [External Circuit] keyword. Or did you have something else in mind?
#4) I have a problem with the sentence:
"It is the input impulse to the redriver input algorithmic model's AMI_Init
function.", because
the hAC1 impulse response is first passed to what you call SerDes Tx
algorithmic model, and it is only passed to the redriver input algorithmic
model after that. This sentence seems to suggest that it is passed
directly to the redriver input algorithmic model, which doesn't seem
to agree with step 2 later in the BIRD.
#5) I would insert the words (or something similar) in red bold in the
following sentence in step 7 to make it a little more clear to the reader:
"The simulation platform performs simulation on the upstream channel, which
consists of the Tx algorithmic model, the upstream physical channel, and the
redriver's input algorithmic model, making use of the AMI_GetWave functions
of the algorithmic models if present according to the AMI flow defined in
the specification for channels without redriver."
#6) Similarly, I would insert the following words in step 8:
"which consists of the redriver's output algorithmic model, the downstream
physical channel, and the Rx algorithmic model, making use of the
AMI_GetWave functions of the algorithmic models if present according to the
AMI flow defined in the specification for channels without redriver."
Thanks,
Arpad
===============================================================
Other related posts:
