[ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

Ha!  This kind of stuff happens to me all the time too.

When my mind is ahead of my typing I start hitting

keys which belong to words ahead of the words I am

in the process of typing, some times leading to all

kinds of interesting outcomes...

 

Arpad

=======================================================

---

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Thursday, April 22, 2010 4:50 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

In my last post, when I said:

 

“that’s the wave I always understood it”

 

I meant to say:

 

“that’s the way I’ve always understood it”

 

Knowing me, you might well have assumed it was merely a bad pun, but it really was a typo.

 

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: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Thursday, April 22, 2010 5:37 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

 

Fangyi,

 

There’s an important historical point worth mentioning here.

 

The flow described in section 2.3 of the current 5.0 spec is a time-domain simulation flow.  If you look at the paragraph right under the 2.3 heading, it says:

 

“The following steps are defined as the reference simulation flow.  Other methods of calling models and processing results may be employed, but the final simulation waveforms are expected to match the waveforms produced by the reference simulation flow.”  “Waveforms” in this case means the simulated response to actual stimulus patterns, not the impulse / pulse response used by a Statistical simulation engine.  I’ll readily admit I’m splitting linguistic hairs, but that’s the wave I’ve always understood it.

 

Section 2.3 was created in direct response to issues we had running IBIS-AMI models in both the SiSoft and Cadence IBIS-AMI toolkits; issues that resulted in the definition of the Use_Init_Output parameter.  Tests with both toolkits in early 2008 showed that, in effect, SiSoft had assumed Use_Init_Output would always be False, while Cadence had assumed that Use_Init_Output would always be True.  Adding this Use_Init_Output parameter to the spec allowed the model maker to declare (for models that supported both Init and Getwave) whether the Init and Getwave calls were to be considered independent (i.e. the model supported both Statistical and Time-Domain simulation) or whether the calls needed to be chained together (i.e. part of the model was in Init, part of the model was in Getwave).  We saw merit in both methods of model development, and allowed the model maker to declare which method they had followed.

 

You are correct; the intent was that Use_Init_Output would have no effect on a Statistical simulation, and would affect Time-Domain simulation only.

 

The 5.0 spec doesn’t explicitly define a Statistical simulation flow, although it does establish all the model functions and controls needed to enable it.  At present, there are both tools and models in the market that comply with the 5.0 spec and support Statistical simulation.  That being the case, it makes sense to clarify the specification and the reference flow for both Statistical and Time-Domain simulation, which is exactly what the flow discussions (and flow diagrams) were intended to do.

 

Hope that helps,

 

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: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx
Sent: Thursday, April 22, 2010 2:17 PM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

 

Hi, Arpad;

 

Ambrish’s flow is not about moving Tx Use_Init_Output to the left or right in your flow chart. If I understand him correctly, he was suggesting:

 

·         In statistical simulation, Use_Init_Output has no effect. Impulse returned by Tx Init always goes into Rx Init. Impulse returned by Rx Init is always used for statistical eye calculation.

·         In time-domain simulation, Use_Init_Output controls the flow the way stated in section 2.3., or in your flow chart presented in last meeting.

 

I think this make sense. It pretty much keeps both statistical and time-domain simulations consistent without the need of new parameter.

 

Regards,

Fangyi

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, April 22, 2010 8:47 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

 

Ambrish,

 

This is exactly why we moved the Use_Init_Output Booleans to

the right side in the November flow.  In one of the recent

ATM meetings when I showed a draft of the flow that I

started to work on, one of you (can't remember if it was you

or Fangyi) suggested that I should put it back to the left

side.  This happened when I brought up the issue with some

of the combinations needing de-convolution.

 

But aside from that the real problem with this is the spec

itself, because the section you quoted here is in direct

contradiction with the flow described in section 2.3 in

great detail.

 

But now we are starting to go around in a circle because

we have already talked about this in this thread.

 

Summary:

 

- If we move Use_Init_Output to the right, we do it according

  to the Use_Init_Output definition, but have de-convolution problems

- If we move Use_Init_Output to the left, we do it according

  to section 2.3, but the LTI flow is broken

 

The November flow moved it to the right, but also fixed the

de-convolution problem by adding the Init_Returns_Filter

Boolean.  This was voted down recently, but it seems that

the same people who voted it down are now arguing that the

correct interpretation of the spec is that Use_Init_Output

should be on the right.  If it is on the right we need to

find a solution for the de-convolution problem.  This proves

to me that the Init_Returns_Filter is really not a new feature,

but a correction to the problem after all, and we should just

go with the November flow.

 

However, now that we also discovered that the Init_Returns_Impulse

is lacking in its definition, i.e. it doesn't spell out what is

returned when it is False, I would like to suggest that we should

revise the November flow by adding the Init_Returns_Impulse

Boolean to the drawings and define what it does when it is False.

Maybe by doing that we could eliminate this "new" red herring

Boolean called Init_Returns_Filter...  :-)  So I am going to

start a new thread to discuss Init_Returns_Impulse.

 

Arpad

===================================================================

 

 

 

 

---

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Thursday, April 22, 2010 8:48 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

Arpad,

The flow as you drew was correct for TD simulation. For Stateye type simulation, the EDA tool takes into account only the 2 Init functions – so there was a missing link in your presentation.

 

About Use_Init_output, my understanding is that it is only meaningful for the TD flow as alluded to in the

definition for Use_Init_Output

 

| Use_Init_Output is of usage Info and type Boolean. When

| Use_Init_Output is set to "True", the EDA tool is

| instructed to use the output impulse response from the

| AMI_Init function when creating the input waveform

| presented to the AMI_Getwave function.

|

| If the Reserved Parameter, Use_Init_Output, is set to

| "False", EDA tools will use the original (unfiltered)

| impulse response of the channel when creating the input

| waveform presented to the AMI_Getwave function.

 

Thanks,
Ambrish.

---

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, April 22, 2010 12:35 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

 

Ambrish,

 

So is my understanding of what you are saying correct if I

summarize it this way:

 

You are only asking a different VISUAL representation of the

flow to accentuate the two separate paths, but the flow is

actually correct as I drew it for the presentation yesterday

(except for the question that follows)?

 

A (minor) detail question about your PDF attachment.

 

On the left side, the Stateye flow, you took out the

Tx Use_Init_Output Boolean.  Did you mean this, or is this

omission just part of the "crude representation" of the

flow (as you put it)?  If you meant it, do you mean to

say that we should assume that this Boolean is always

True for the Stateye flow whether it says False in the

.ami file or not?  In other words, are you suggesting

that this Boolean should only be meaningful for the TD

flow, otherwise it should be assumed to be True?

 

Thanks,

 

Arpad

==============================================================

 

---

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Wednesday, April 21, 2010 11:08 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

Arpad,

Your observations are correct. Use_Init_Output does allow the model maker to have effectively the same algorithms in Init and Getwave. It’s a case of ‘can’ and ‘should’ as you pointed out in one of your earlier mails. I keep pointing out to you the intent of section 2.1 and 2.2 and the default value in the definition of Use_Init_Output and not the possibilities. This is how I understand what the intent was: in section 2.1, we don’t need a getwave, why – because init was necessary and sufficient. In section 2.2, however, we do need a getwave – why – because Init is NOT sufficient.

But – as you said, we did leave the door open …

 

When I wrote to you about separating the TD flow and the Stateye flow – I meant separating it visually, in your slides – to fix the issue Walter pointed out yesterday. Basically when the user wants a Stateye type simulation, the EDA tool takes into account only Init and is done. The path would look like this:

Obtain Channel Impulse Response (hAC(t)) à Tx_Init call (hAC(t) x hTEI(t))à Rx_Init call (hAC(t) x hTEI(t) x hREI(t)) à Stateye type analysis.

 

What you have already in the slide can be kept as is for TD simulation. I have attached a crude representation.

 

Thanks,

-Ambrish.

 

---

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, April 21, 2010 7:24 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

 

Ambrish,

 

I would like to see how you came to the conclusion that

"If you separate the Stateye flow with the TD flow, we will have what the spec says currently".

 

I re-read the spec once again to find out how you came to that

conclusion, but my reading resulted in the opposite conclusion.

 

1)  pg. 181, 2.1 Linear, Time-invariant Equalization Model:

 

 

This implies (although not stated), that for the LTI (or Stateye) flow

the Init_Returns_Impulse Boolean must be set to true.

 

2)  On pg.182, 2.2 Nonlinear, and / or Time-variant Equalization Model

    I read the following:

 

 

This is now talking about the non-LTI flow.  Note that it says that

"AMI_Init may also compute the impulse response of the block...". 

This means that the Init function can still return a modified impulse

response even if we are doing a non-LTI analysis with GetWave.

 

3)  pg. 144, GetWave_Exists says:

 

 

Note that is says "if Init_Returns_Impulse is set to "False"..." basically

GetWave must exist.  This means that the only time Init is allowed not to

return a modified impulse response is when we do a non-LTI analysis with

GetWave.  But notice that it doesn't say that if GetWave exits, Init_Returns_Impulse

must be False, or in other words, it doesn't say that when we are ding a

non-LTI analysis with GetWave, the Init function is not allowed to calculate

a modified impulse response.

 

There are several things we can conclude from this:

 

- if the Init function doesn't calculate the modified impulse response,

GetWave will have to include the algorithm to do that calculation

 

- the spec doesn't say anything that this algorithm may not be duplicated

in the Init and GetWave functions, i.e. this duplication is not forbidden

 

- this means that the model writer has a choice to put the algorithm

that is responsible for calculating the modified impulse response into

either the Init or the GetWave function or both

 

- if there is a duplication of this algorithm in both Init and GetWave,

the model maker may set Use_Init_Output to False so that double counting

is prevented in the results

 

- with this approach one can build a parallel path for the LTI (or Stateye)

and non-LTI (or TD) calculations within the same model without the danger

of double counting for any effects

 

 

Clearly, the authors of the specification left it up to the model maker

to decide whether the modified impulse response is calculated in the

Init or the GetWave function or both.  One approach could be to "factor

it out" and put the LTI part of the algorithm into the Init function and

put the non-LTI portions of the algorithm into the GetWave function,

but one could also put the entire thing into the GetWave function and

have a duplicate LTI algorithm or a similar LTI approximation in the

Init function.

 

This is what I am reading from the EXISTING specification.  I would like

to get a similar detailed analysis from you that explains how you arrived

to the opposite conclusions based on the current specification.  I am not

asking this to give you a hard time, I am making this request to find out

why the existing specification can be interpreted in such completely

different ways so that we can fix the spec and eliminate the possibilities

for such misinterpretations in the future.

 

Thanks,

 

Arpad

============================================================================

 

 

---

From: Ambrish Varma [mailto:ambrishv@xxxxxxxxxxx]
Sent: Wednesday, April 21, 2010 3:52 PM
To: Muranyi, Arpad
Subject: RE: [ibis-macro] Re: AMI_Flows_6.pdf for today's ATM teleconference

Arpad,

If you separate the Stateye flow with the TD flow, we will have what the spec says currently. I think the issue with what you had yesterday was the mixing of the 2 flows together.

Let me know if you want me to elaborate.

-Ambrish.

-- 
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC