[ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <ibis@xxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Sun, 6 Apr 2008 13:08:39 -0400
Arpad,
This is a really good question.
Let me start by outlining the "Use_Init_Output" reference flow as I understand
it. In this flow
Use_Init_Output is True for both the TX and RX devices:
1. Simulation platform prepares hcr(t)
2. hcr(t) -> tx_init -> hcr(t) x htei(t)
3. hcr(t) x htei(t) -> rx_init -> hcr(t) x htei(t) x hrei(t)
4. hcr(t) x htei(t) x hrei(t) -> simulation platform
-> hcr(t) x htei(t) x hrei(t) x b(t) x p(t)
5. hcr(t) x htei(t) x hrei(t) x b(t) x p(t) -> tx_getwave
-> hcr(t) x htei(t) x hrei(t) x b(t) x p(t) x hteg(t)
6. hcr(t) x htei(t) x hrei(t) x b(t) x p(t) hteg(x) -> rx_getwave
-> hcr(t) x htei(t) x hrei(t) x b(t) x p(t) x hteg(t) x hreg(t)
The steps in this flow are chained, and the input of steps 2-6 is the output of
the step that
preceded it.
When "Use_Init_Output" is False, the corresponding init step in the chain still
gets run, but any
filtered data produced by that step isn't passed on - the input to that step is
passed on instead.
For example, if Use_Input_Output was False for the TX, the output for step 2
would be discarded, and
hcr(t) would be passed to step 3 instead (this is the language I changed in
BIRD 107 last Thursday
because I didn't have a clear understanding of the reference flow).
While it's true that the order of convolution of LTI elements doesn't matter,
are side issues that
can crop up here.
For example, consider the case of a model with RX_Init and RX_Getwave that uses
RX_Init to "preset"
DFE tap parameters for the start of RX_Getwave (something I refer to as
"warm-starting" the DFE
taps). Thus, the impulse response you pass to RX_Init should have the effects
of TX_Init included
(i.e. you don't want to change the order of steps 2 and 3, even though you'd
theoretically get the
same output).
There's a flaw in the above argument when the TX doesn't return an equalized
impulse response from
Init. Even if you use the reference flow, RX_init will try to preset based on
the wrong impulse
response. While I don't expect this scenario will be common (TX_Getwave but
no output from
TX_Init), the solution is this case is - either the user tells the RX model to
"cold start" the tap
parameters from zero, or just lives with the fact that the starting point isn't
as well optimized as
it could be.
My conclusion is that the evaluation order of AMI models needs to be
deterministic for the user to
be able to manage the situation settings, and ensure consistent results across
tools. Thus, we
should spell out the reference flow above if everyone doesn't already
understand it. I'm guessing
everyone doesn't, and therefore we should include language to this effect in
BIRD 107.1.
I hope it goes without saying that the evaluation order of 5 and 6 can't be
changed, because neither
of these behaviors can be considered LTI. They might be, but it's not
guaranteed.
Is my explanation clear here, and do you agree with this?
Thanks,
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi,
Arpad
Sent: Friday, April 04, 2008 3:51 PM
To: ibis@xxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI)
Support in IBIS
Mike,
You raised a bunch of VERY GOOD and VALID questions, most of which
I haven't thought about before! I think they are very important
topics and we should discuss them (or even mention them in the
spec).
However, I would like to return to Todd's posting (to which you
replied), which brings up the order of execution question.
-------------------------------------------------------------------
All,
If we go with what was proposed on pg. 18 of the presentation
discussed in the last ATM meeting, the EDA tool will convolve
either the output of Init, OR the unmodified channel response
with the input waveform for GetWave's input. (I know, Kumar
is warning us not to say "convolved" because there may be other
ways to do this, but for the sake of this discussion I will just
use the word convolve). Note that neither the presentation, nor
BIRD107 distinguishes between Tx GetWave or Rx GetWave, so I
assume that the above has to be done for both (unless we change
the words). If the channel response (modified or not) is present
in the input of both Tx GetWave and Rx GetWave, aren't we double
counting the channel response?
Todd seemed to indicate that his execution order rule would take
care of that but I don't see yet how.
TX AMI_Init -> RX AMI_Init -> TX AMI_Getwave -> RX AMI_Getwave
The order in which convolution is done on various data blocks
doesn't change the outcome. We can only eliminate the double
counting by eliminating the duplicate input of the channel
response (or modified channel response) somewhere in the chain.
So, is the above order of execution rule supposed to mean that
because of that, one of the channel responses are dropped
somewhere in the chain, meaning that the rules on pg. 18 are
different for Tx GetWave and Rx GetWave regarding the usage
of channel response?
If that is what this means, we need to write separate rules for
Tx and Rx GetWave. If the order of execution does something
I don't understand yet, we need to write a specific section on
that into our BIRD to describe it to those of us to whom this
is not obvious...
Arpad
==================================================================
-----Original Message-----
From: Mike LaBonte (milabont) [mailto:milabont@xxxxxxxxx]
Sent: Friday, April 04, 2008 9:47 AM
To: twesterh@xxxxxxxxxx; Muranyi, Arpad; ibis@xxxxxxx; IBIS-ATM
Subject: RE: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling
API (AMI) Support in IBIS
I remember the problems caused by C++ destructors that relied on each
other, and were called in different order on different platforms in the
early days of C++. On the theory that there could be multiple TXs in a
simulation as well as multiple RXs, I would suggest specifying only:
1) All Init()s are called before all GetWave()s, which are called before
all Close()s
2) Within each group (Init, GetWave, Close), no function shall be
written in such a way that it depends on the order in which instances of
the same group are called.
3) There *might* be an additional stipulation about interleaving
GetWave() calls so that one instance is not called multiple times
between calls to another instance. For example, TX GetWave() can't be
called 100 times before RX GetWave() is called once. On the other hand
if that is to be allowed it should be explicit.
My opinion is that each model instance preferably should only use memory
associated with the instance, not global "static" memory that could be
shared among multiple instances. But even if they do, no call order
should be assumed. For example, I don't think we should assume that TX
Init() is called before RX Init(). Knowing that the call order among
instances is indeterminate will warn people to create models that are
safe no matter how memory is shared.
Mike
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Friday, April 04, 2008 9:28 AM
To: Arpad_Muranyi@xxxxxxxxxx; ibis@xxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API
(AMI) Support in IBIS
Arpad,
I have given this one a lot of thought, and realized my changing the
BIRD text was another one of those perspective things. I'm pressed for
time at the moment, but wanted to get this one the wire before I have to
jump into a meeting ...
If we agree models get called in the following sequence:
TX AMI_Init -> RX AMI_Init -> TX AMI_Getwave -> RX AMI_Getwave
Then the original text was okay and I shouldn't have changed it. I had
a different perspective that let me to think the text needed to be
changed. I realized the perspective I had was based on a particular
context, one that didn't really reflect how these models would be
executed in an operating EDA platform.
I can go into detail how I got to that point, but I don't think it
matters.
If everyone else expected the calling sequence I listed above, then we
should just go back to the original text. This will have been case of
the editor trying to solve a problem that didn't exist.
My apologies for the confusion.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
---------------------------------------------------------------------
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:
