[ibis-macro] Re: [IBIS] RE: 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: Mon, 7 Apr 2008 08:52:02 -0400

Kumar,

 

It goes to how the filtering applied by AMI_Init and AMI_Getwave are to be 
viewed from a system
perspective.

 

The two different views are:

 

-          AMI_Init and AMI_Getwave model sequential stages in the device (the 
original Cadence
view)

-          AMI_Init and AMI_Getwave each represent the whole device's behavior 
(the original SiSoft
view)

                  

Let's consider the second case (which is what I think you're asking about) - 
why would anyone want
to do this?  Because architectural exploration and detailed design analysis can 
make efficient use
of different representations.  

 

Let's assume that I can represent a particular device's filtering using either 
AMI_Init or
AMI_Getwave models.  The AMI_Getwave model includes nonlinear and time-varying 
behavior that I'm
going to want to run before design signoff, but the AMI_Getwave model takes 10X 
longer to run than
the AMI_Init model.  When I'm in the early stages of the design, looking at 
approximate channel
lengths and interconnect characteristics, the AMI_Init model will let me run 
more simulations in
less time.  I'm not doing detailed implementation - I'm just trying to get a 
rough idea of channel
length, bit rate, equalization settings and the quality of the resulting eye.  
If I can run 50
simulations quickly to identify the 5 cases I want to study in more detail, 
then I'm going to want
to do that.

 

The trick is - the EDA platform needs to know that AMI_Init and AMI_Getwave 
both represent the
device's full behavior.  If I'm running an architectural simulation (scenario 
1), I want the EDA
platform to take the output of the AMI_Init call, convolve it with the stimulus 
waveform, and treat
that as the simulation output.  If I'm running a detailed simulation (scenario 
2), I want to EDA
platform to take advantage of the non-linear and time-varying capabilities of 
the AMI_Getwave call.

 

Here's the rub:  AMI_Init has no way of knowing whether it's being called as 
part of scenario 1 or
scenario 2.  AMI_Init ALWAYS gets called, so I need to be able to ignore the 
filtered impulse
response returned by AMI_Init in scenario 2.  That's _exactly_ what 
Use_Init_Ouptut=True is meant to
accomplish.

 

Does that answer your question?

 

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

  _____  

From: owner-ibis@xxxxxxx [mailto:owner-ibis@xxxxxxx] On Behalf Of C. Kumar
Sent: Monday, April 07, 2008 4:13 AM
To: Todd Westerhoff; ibis@xxxxxxx; 'IBIS-ATM'
Subject: Re: [IBIS] RE: [ibis-macro] Re: BIRD107: Update to Algorithmic 
Modeling API (AMI) Support
in IBIS

 

todd aan arpad:
there is one thing here I am not getting. If the model maker does not intend to 
use init ouptut why
he will modify it in the first place? if hew wants for his book keeping he 
should make a copy of it
and leave the original data undisturbed

Todd Westerhoff <twesterh@xxxxxxxxxx> wrote:

Arpad,

The measurement point is a really good one - as it stands at the moment, yes - 
you'd edit the AMI
file, change Use_Init_Output to False and rerun.

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: Sunday, April 06, 2008 6:51 PM
To: ibis@xxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) 
Support in IBIS

Todd,

I can see all these reasons, but I want to make
sure everyone else understands the differences,
and agrees with it too.

Also, how are we going to do correlation with
measurements, if we can't generate an Rx pad
waveform? Or, are you saying that for that
purpose we would have to select a different
value for "Use_Init_Ouput" and redo the simulation?

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

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Sunday, April 06, 2008 3:26 PM
To: ibis@xxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API
(AMI) Support in IBIS

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

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi,
Arpad
Sent: Sunday, April 06, 2008 5:24 PM
To: ibis@xxxxxxx; 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@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Sunday, April 06, 2008 10:09 AM
To: ibis@xxxxxxx; '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@xxxxxxxxxx
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@xxxxxxxxxxxxx
Subject: unsubscribe


---------------------------------------------------------------------
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@xxxxxxxxxxxxx
Subject: unsubscribe

---------------------------------------------------------------------
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@xxxxxxxxxxxxx
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@xxxxxxxxxxxx
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis 
| subscribe ibis-users 
| unsubscribe ibis 
| unsubscribe ibis-users 
|
|or e-mail a request to ibis-request@xxxxxxxxxxxxx
|
|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



 

  

  _____  

You rock. That's why Blockbuster's offering you one
<http://us.rd.yahoo.com/evt=47523/*http:/tc.deals.yahoo.com/tc/blockbuster/text5.com>
  month of
Blockbuster Total Access, No Cost.
-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

Other related posts:

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