All,
I recommend that we correct all of the details, issue BIRD197.3. This may
delay the vote, but there is no urgency.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 27, 2019 4:59 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx)
Subject: [ibis-macro] Re: Technical questions on BIRD197.2
Ha! One more:
"which is the singled ended voltage"
Arpad
=============================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 27, 2019 6:58 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Technical questions on BIRD197.2
And yet another one in the same section:
"A DLL may need to know the singled ended voltage levels"
Arpad
===============================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 27, 2019 6:57 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Technical questions on BIRD197.2
By the way, there is another grammatical error in the BIRD:
"The forces all AMI simulations to be centered"
but this is in the "DEFINITION OF THE ISSUE" section which will
not be put into the spec, so we don't really need to fix it.
Thanks,
Arpad
================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 27, 2019 6:45 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Technical questions on BIRD197.2
Mike,
#1) God catch. Should be fixed to 7.1 or x.x
#2) The BIRD says
"If the impulse response was generated by differentiating the step response,
then."
This doesn't indicate to me "that both step responses and impulse responses
are now legal waveform types",
it just says that if the IR was based on a step response then, this and
that.
#3) I agree, this is weird, but so is the "placeholder" for Out types, when
the .ami file
has to contain a dummy value that will be replaced by the real thing coming
from the
DLL. At some time in the future we might want to clean these weird things
up...
Thanks,
Arpad
=================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Wednesday, March 27, 2019 12:53 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Technical questions on BIRD197.2
Sorry not to have raised these earlier, but the recent posting of BIRD197.2
to the IBIS reflector in advance of the Open Forum vote has "inspired" some
questions.
1) The BIRD explicitly states under "Required" that the parameter
DC_Offset is "illegal before AMI_Version 7.0". Should this read "7.1", or
even be left as "X.X" until the BIRD is formally integrated into a specific
IBIS document?
2) The BIRD definition and part of the BIRD change text mention step
responses. Are there any other adjustments to IBIS language needed to make
explicit that both step responses and impulse responses are now legal
waveform types as part of AMI simulation? The concern is that the model and
tool may not have unambiguous information about the waveform to
generate/expect.
3) DC_Offset is somewhat "weird" in that we are declaring an input
parameter as part of a .ami file but which is essentially only a
placeholder. In other words, we have other "inputs" to a DLL which are
defined in the specification but are not formally part of the .ami file
structure (the waveform itself is one such instance, as is bit_time).
Anything part of the .ami file is actually determined by the model maker.
Shouldn't DC_Offset be part of the AMI function calls, similar to bit_time?
Thanks in advance.
- MM
