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

From: Todd Westerhoff <twesterh_at_.....>
Date: Sun Apr 06 2008 - 15:26:13 PDT
Arpad,

The flow

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

Was what I was thinking last Thursday when I modified the BIRD text.

I don't think it works, though.  In the flow above, you'd need to take the output of Tx_Init and
convolve it with b(t) x p(t) before presenting it to Tx_Getwave.  You can't present the result to
Rx_Init, because Rx_Init only knows how to process impulse responses, and you've already got a
waveform that needs to be processed in blocks.

Slide 3 in the DesignCon presentation (and slide 5 in last Tuesday's, which was lifted directly from
a Dec 2006 presentation) were both developed before we realized that the model maker needed to be
able to specify the desired relationship between AMI_Init and AMI_Getwave calls.

What's now clear in retrospect is that Cadence thought Use_Init_Output would _always_ be True, and
SiSoft thought Use_Init_Output would _always_ be False.   We each thought there was only one way
models would be developed and used, we each thought everyone saw it the same way we did, and we each
believed different things.  It made for some interesting conversations when we tried to sort out
differences in simulation results.

What's become clear that there are two equally valid ways to develop a model with both AMI_Init and
AMI_Getwave outputs, and that the model maker needs to be able to declare how the model should be
used.  

That's exactly why we introduced the new Reserved_Parameter Use_Init_Output, and expanded the
terminology for TX and RX equalization to differentiate between filtering applied by the AMI_Init
and AMI_Getwave calls (last Tuesday's presentation, page 7).

I now believe the reference flow

Channel Response -> Tx_Init -> RX_Init -> x Stimulus -> Tx_Getwave -> Rx_Getwave

Is the one we need to speak to.  There are probably other ways to run the models and get equivalent
results, and that's fine ... we just document that the results of any other flow should match the
results from the reference flow.

Make sense?

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

-----Original Message-----
From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi,
Arpad
Sent: Sunday, April 06, 2008 5:24 PM
To: ibis@eda.org; IBIS-ATM
Subject: [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
---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@freelists.org
  Subject: unsubscribe



-- 
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
Received on Sun Apr 6 15:27:11 2008

This archive was generated by hypermail 2.1.8 : Sun Apr 06 2008 - 15:27:38 PDT