[ibis-macro] Re: A Boolean logic excersise, Mea Culpa, You are right
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 8 Jun 2010 22:40:59 -0700
Walter,
Thanks again for your reply. I will try to point out something
regarding your first two paragraphs. I will not go into the
last two paragraphs, because I don't fully understand your 3rd,
but even if I did, those are basically wishful thinking type
topics.
Regarding "in the definition of Use_Init_Output, it's value is
only used when GetWave_Exists is True", I assume you are referring
to page 145 where it says:
| ... when creating the input waveform
| presented to the AMI_Getwave function.
There are several problems with this statement. It doesn't
specify which Init and which GetWave function it is referring
to. The original flow had only one Init to GetWave connection,
that was between Rx Init and Tx GetWave. The corrected flow
has no direct connections between an Init output and a GetWave
input. So because of this vagueness I can't make far reaching
conclusions and establish precise rules for these Booleans.
Here is why:
Consider the case when there is only one GetWave for the Rx.
Is the rule then to ignore the Tx Use_Init_Output setting
and obey the Rx Use_Init_Output setting?
Same goes for the reverse, when there is a Tx GetWave and no
Rx GetWave.
Or am I supposed to ignore both Use_Init_Output settings in
these two cases? How would you come to the conclusion for
either decision? I cold certainly not make such decisions
based on the statement that I quoted above from pg. 145.
On a different note, Todd was right when he commented in the
ATM teleconference that we need to distinguish three cases:
1) Statistical simulation
2) LTI TD simulation
3) non-LTI TD simulation
For the first, we would most likely have no GetWave functions
at all. For the second we may have 0, 1 or 2 GetWave functions
provided that they do not contain any non-LTI algorithms. For
the third we could still have 1 or 2 GetWave functions, but in
this case they will have non-LTI algorithms.
The point here is that for 2) and 3) we cannot tell whether the
simulation is an LTI or a non-LTI time domain simulation from
the GetWave_Exists Boolean value, so making decisions based on
GetWave_Exists alone doesn't seem to be the right thing to do
(to me at this point in my life)... Please educate me if I am
missing something.
Any comments?
Thanks,
Arpad
================================================================
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 08, 2010 11:24 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: A Boolean logic excersise, Mea Culpa, You
are right
Arpad,
It is true that the current spec says "| If Use_Init_Output is False,
GetWave_Exists must be True", and you take use of this statement in your
flow diagrams, so they are consistent and that is why I was wrong. But
it is
also true that in the definition of Use_Init_Output, it's value is only
used
when GetWave_Exists is True, and there is not logic in the IBIS 5.0 that
uses the value of Use_Init_Output when GetWave_Exists is Flase, other
then
saying that it cannot be set to False.
This has always been a pet peeve of mine that Use_Init_Output exists at
all.
The fact of the matter is statistical simulation doe not use it at all,
and
that it has one meaning when GetWave_Exist is True and no meaning when
GetWave_Exists is False.
Alas, it is what it is and I apologize again for my last feeble gasp at
trying to clean this up. Please be clear, that the intent of
Use_Init_Output
was when the equalization is reported by AMI_Init was not included in
the
equalization added by AMI_GetWave.. Is the output of AMI_Init suitable
for
statistical simulation? What equalization is not included in AMI_Init?
And
in either case, why do we expect model developers to be able to create
these
complex models, and yet not be able to save the Impulse Response of the
equalization from the Init call and implement a well-documented Overlap
and
Save method to include the equalization in the AMI_GetWave call?
All would have been good if BIRD 107 just stated what it did about
Use_Init_Output except that its default value should be False, and that
if
GetWave_Exists is True then Use_Init_Output must be False. Then the
default
value (False) would mean that the output of AMI_Init would be suitable
for
statistical simulation, and that the output of AMI_GetWave would contain
all
of the models equalization. It was only when Mike Steinberger explained
how
we could use de-convolution to get the information we need to process
models
that has Use_Init_Output True, that I relented on the addition of
Use_Init_Output, and I had the mistaken hope that all in the IBS-ATM
committee would repair this differently.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 08, 2010 11:02 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: A Boolean logic excersise, Mia Culpa, You are
right
Thanks Walter, I am glad we are in agreement. You got me worried
on this one a little... However, I am not sure what you mean by:
It is an unfortunate statement of fact that Use_Init_Output
only has meaning when GetWave_Exists is "True",...
I wanted to write about this too after the meeting, but decided to
take it one step at the time. Recall, the current specification
already has a rule that:
| If Use_Init_Output is False, GetWave_Exists must be True.
In the previous email I showed how this is equivalent to say that
when GetWave_Exists = F Use_Init_Output must be T.
In addition, we all agreed on a new rule (to fix problems in the spec)
which says that:
For statistical simulations Use_Init_Output is ignored and is
treated as if it was TRUE.
Based on this, your suggestion to ignore Use_Init_Output every time
when GetWave_Exists is False is equivalent to what I am showing in
the current flow diagram (7j) including the three notes repeated on
the bottom of each slide and what I attempted to write up in the BIRD
for Section 2.3 (i.e. the text version of the flow). So this argument
is somewhat academic or philosophical.
I would prefer to write the spec in a way that makes it easier to
read and understand for everyone, including the new readers. If
everyone agrees to word it your way, I will make (yet) another version
of my flow diagram drawing, in which the Use_Init_Output value is
grayed out for all GetWave_Exists=F combinations, change the value of
Use_Init_Output from "T" to "X" for all those cases, and I would also
remove the Use_Init_Output from the sentence in Note #2. But I want
to warn everyone, that making these changes will add at least one
more week to the process of finishing this BIRD, because we will
have to review the flow diagram drawings again, and I would have to
make the corresponding changes to the BIRD text in this area. I
personally don't think this is worth our time, but I will let the
members of the ATM Task Group decide...
Please let me know ASAP!
Thanks,
Arpad
=====================================================================
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 08, 2010 4:38 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] A Boolean logic excersise, Mia Culpa, You are
right
Arpad,
I am sorry, you are definitely correct. It is an unfortunate statement
of
fact that Use_Init_Output only has meaning when GetWave_Exists is
"True",
but the BIRD is explicit as to how it needs to be set when
GetWave_Exists is
False. SO based on this and the excellent work you did in combining the
flows, I recommend we go with what you have. We still need to review the
other definitions that changed, but I hope we can move on. Again, I
apologize for the confusion.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 08, 2010 4:59 PM
To: IBIS-ATM
Subject: [ibis-macro] A Boolean logic excersise
Hello AMI experts,
The discussion over the AMI Booleans at the end of today's
ATM teleconference prompted me to write this message. First,
two quotes from the existing IBIS specification. Page 144
says:
| Note that if Init_Returns_Impulse
| is set to "False", then Getwave_Exists MUST be set to "True".
and page 145 says:
| If Use_Init_Output is False, GetWave_Exists must be True.
To make my notation simpler, I will abbreviate the names of the
Booleans to GWE for GetWave_Exists, UIO for Use_Init_Output and
IRI for Init_Returns_Impulse. Also, a "===" indicates "must be".
So this is what the current spec says today:
If IRI = F then GWE === T
If UIO = F then GWE === T
From these we can write the following truth tables:
--------
IRI GWE
--------
F T
T T
T F
--------
--------
UIO GWE
--------
F T
T T
T F
--------
From this we can see that when GWE = F the only possible value
for UIO or IRI is T. So the sentence I put into my BIRD draft:
|* Note that if GetWave_Exists
|* is set to "False", then both Use_Init_Output and
|* Init_Returns_Impulse MUST be set to "True".
is in complete agreement with the existing specification, and
does NOT introduce any new features. The only question that
remains comes from the fact that UIO is not a required parameter.
However, the current specification also states on p. 145 that
| Use_Init_Output is optional. The default value for this
| parameter is "True".
Which means that if UIO is not present, it is the same thing as
if it was present with a value of T. This condition will still
satisfy the rule I wrote into the BIRD draft. So I would like to
see proof for why the above statement in my BIRD draft changes
anything in the existing spec or introduces any new features to
it.
Any comments? (Quick replies would be appreciated).
Thanks,
Arpad
===================================================================
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
