[IBIS] RE: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS

Todd,

Thanks for the explanation.  I think the flow you outlined
below eliminates the double courting problem.  However, I don't
think any of us had this understanding of the flow before.

I think previous to this discussion we all thought that the
output of Tx GetWave was the "waveform at the Rx pad", as
shown on pg. 5 in the 3rd bullet of your last Tuesday's
presentation:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20080401/toddwesterh
off/IBIS-AMI%20Correlation%20and%20BIRD%20Update/IBIS_ATM_BIRD_Update_04
0108.pdf

and on pg. 3 in your DesignCon presentation:
http://www.vhdl.org/pub/ibis/summits/feb08/westerhoff.pdf

With the flow you outlined below the output of Tx GetWave
includes the Rx equalization, which changes the meaning
of the waveform at the output of Tx GetWave from "Rx pad"
to something like "Rx on the die after the EQ".  I understand
that this can be changed back to its original meaning IF we
use the appropriate value for "Use_Init_Ouput" to suppress
the Rx equalization in the Tx GetWave input, but is this
not going to have any other side effects?

I think having a flow of 

  Tx Init -> Tx GetWave -> Rx Init -> Rx GetWave

may be more appropriate, but I haven't given it enough thinking
time yet to see all the details and consequences of this flow,
especially considering the double counting problem and the newly
proposed Boolean variable's effects...

I am concerned that the flow you outlined below is not what we
had in mind when we wrote the original BIRD, and I think this
must be handled cautiously, but most importantly even if we 
agree to this, we MUST spell it out in the spec very clearly.

Arpad
=================================================================





-----Original Message-----
From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Todd Westerhoff
Sent: Sunday, April 06, 2008 10:09 AM
To: ibis@eda.org; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API
(AMI) Support in IBIS

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@sisoft.com
www.sisoft.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993