[ibis-macro] Minutes from the 12 April ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Fri, 15 Apr 2016 13:52:04 -0400

Minutes from the 12 April ibis-atm meeting are attached.

The following document, which was originally posted after the 08 March
meeting, was again discussed during this meeting.

08-MAR-2016 Fangyi Rao Keysight Technologies AMI Simulation Flow Round 3 (
zip
<http://ibis.org/macromodel_wip/archive/20160308/fangyirao/AMI_Simulation_Flow_Round_3.zip>
)(pdf
<http://ibis.org/macromodel_wip/archive/20160308/fangyirao/AMI%20Simulation%20Flow%20Round%203/AMI_flow_round3.pdf>
)
IBIS Macromodel Task Group

Meeting date: 12 April 2016

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Broadcom (Avago):             Xingdong Dai
                            * Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                      * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:            * Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:              John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Fangyi to email Walter to check on the status of his review of the Redriver
  Flow proposal.
  - Done.  Fangyi said that he had received some questions from Vladimir and had
    responded.  He said that Walter had proposed some modifications to the flow
    and had commented that Fangyi's presentation was unclear in places.  He said
    he would need to think about Walter's proposed modifications.  Fangyi
    suggested that we revisit his presentation during the meeting since Walter
    and Ambrish had each suggested it was unclear.
  
- Arpad to email Vladimir for the same purpose.
  - Done. (see above)

- Ambrish to check for a collaborator's feedback on his nearly ready new
  version of the Backchannel proposal.
  - In progress.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Ambrish: Second.
- Arpad: Anyone opposed? [none]

-------------
New Discussion:

- Arpad: We can use this time to review Fangyi's presentation if no one has
         anything to discuss on other topics. [none suggested]  

New Redriver Flow:
- Fangyi: [sharing his "AMI Simulation Flow Round 3" (posted March 8, 2006)]
- Walter: I have a couple of questions:
  - You're returning the same IR of the channel modified by the Rx equalization.
  - That is unchanged.
  - You're returning two additional IRs.
    - One is the IR of the DFE.
    - The other is the IR of the CTLE convolved with just the channel IR.
  - Is that correct?
- Fangyi: Yes, correct.
- Walter: Why can't you just return the IR of the CTLE?
  - Let the EDA tool, if it wants to, generate that convolution of the IR of the
    CTLE with the IR of the channel.
- Fangyi: I understand your point.
  - With that approach you could even eliminate the crosstalk IR matrices.
- Walter: Yes.
- Fangyi: In principle they are the same approach.
  - The slight difference is that in my original proposal the model vendor will
    align the DFE with the linear portions of the impulse (the channel convolved
    with the CTLE).
  - The model vendor will use their own algorithm to find the location of the
    main cursor.
  - If the model just returns the CTLE and DFE, and the EDA tool will convolve 
the
    channel IR with the CTLE, then the EDA tool will also need to use its own
    algorithm to define the main cursor to align the DFE and the linear impulse.
  - That's the only difference.  My original proposal assumes it's better to let
    the model vendor use their method to locate the main cursor.
- Walter: That distinction does not make sense to me.
  - Since all you're doing is generating the IR of the CTLE convolved with the
    channel, I don't understand why you need to do that?
  - I understand the DFE has to align with the main cursor.
  - Why can't the model just assume that the EDA tool will generate that
    convolution of the CTLE with the channel, and the model can go ahead and
    align the DFE as appropriate?
  - Once you have the IR of the CTLE and the IR of the DFE, and I agree that
    they relatively have to be aligned, then the EDA tool can do everything.
- Fangyi: I agree, but that alignment algorithm represents how the internal CDR
          works.
  - The model vendor might prefer to use their own method to make that happen.
- Walter: It still doesn't sound logical to me, but let's proceed for now.
- Fangyi: Let's review the flow presentation page by page.
  - We can see where Walter and Ambrish think things are unclear.
  - [Slide 4: Normal Time Domain Flow: GetWave Tx]
    - By "Normal" I mean there are no repeaters.
    - Two further possibilities.
      - Rx has GetWave()
      - Rx does not have GetWave()
    - There are no changes to the TxInit() interface in this proposal.
- Ambrish: Could you add something to the title of the slide defining "Normal"?
  - Could you also add a legend for what the red, green, blue boxes mean?
- Fangyi: The boxes represent the inputs and outputs of the RxInit().
  - red box in  --> red box out.
  - blue box in --> blue box out.
  - green box is a new additional output.
  - So the legend text is already on top of each box.
  - There are two inputs to the RxInit().
    - Red is the "partial", which only includes the analog channel.
    - Blue is "total", and includes the Tx equalization and the analog channel.
      It is the TxInit() output.
  - On the right we have what the RxInit() does with those.
    - It takes the red box and convolves that with all the linear portions of
      the Rx (gain and CTLE, everything that is non-DFE).  This is a new partial
      I call Rx,out.
    - It also generates the DFE IR.
    - The Rx can optimize the CTLE and DFE based on the blue box input, and then
      apply those to the red and green outputs.
    - The RxInit() also returns a combined impulse that includes everything 
      (blue box output).
    - As we just discussed with Walter, it will align the DFE (green box) with
      the linear impulse (red box) when it returns these two impulses.
- Ambrish: The blue boxes are what we have today.
- Fangyi: Yes.
- Ambrish: Maybe as a minor clarification you could note "what we have today"
           where applicable.
- Walter: The green and red boxes on the right are the two additional outputs.
  - What is the red box on the output?
    - That is the analog channel (AC) combined with the non-DFE Rx equalization.
  - Why don't you take that Rx non-DFE and just return that (instead of the
    convolution of that with the AC)?
  - The Rx DFE would have the appropriate phase.
  - Then you let the EDA tool do that convolution.
- Fangyi: Now I see.
  - You mean the returned DFE is already aligned with the combined impulse.
  - The EDA tool will just have to regenerate that combined impulse (convolve
    the AC and the Rx non-DFE), and then it can use the DFE directly.
- Walter: Yes.
- Fangyi: Okay, then we are essentially the same.
  - I originally thought you meant the returned DFE had no delay.
- Walter: I'm saying instead of giving it the AC, just have it return that
          non-DFE Rx.
- Fangyi: No, the model still needs that AC.
  - Internally, in the RxInit(), it needs the AC to convolve with the CTLE and
    then find the phase of the DFE.
- Walter: No.
- Fangyi: Then how does the Rx DFE have the right phase relative to the AC?
  - Imagine there is no CTLE, just DFE.
  - How would the DFE align with the AC?
  - The Rx model still needs this AC in order to determine the DFE's phase.
- Walter: What if the red box input on the left was a unit impulse response?
- Fangyi: Then this DFE will be aligned with that Dirac delta.  That's the main
          cursor.
  - In this proposal I let the model developer determine the DFE phase with
    respect to the red box output that includes the AC.
- Ambrish: The DFE is being implemented in the RxInit() in this case, right?
  - It has to align with the main cursor to work, and for that you need the AC
    IR?
- Fangyi: Yes.
  - That's actually what a current model is doing in the current blue box flow.
- Ambrish: How are the red and green outputs returned?
  - All three (red, blue, green outputs) are returned to the EDA tool.
  - There's an empty place holder in the input where the Rx DFE is returned.
- David: Are you proposing a change to the function signature of RxInit()?
- Fangyi: No, it would just add two new columns to the IR matrix.
- Walter: If you really think we need to keep the red box output (combined
          impulse), then we could just add a third additional output IR that is
          just the Rx non-DFE.
- Fangyi: Then you eliminate the need for all the crosstalk data.
- Walter: Yes, you're either legacy AMI or this new one, and in the new one you
          don't pass the crosstalk channels' IRs.
  - You just return the equalization of the CTLE, the equalization of the DFE,
    and the red box output, and the EDA tool can proceed as it chooses.
  - You would have four IR outputs for an RxInit().
- Arpad: We aren't replacing crosstalk with this new information, are we?
- Walter: One of the outputs shown on the slide right now, the red box, is the
          CTLE equalization convolved with the AC.
  - If we add an additional output that is just the CTLE equalization, then the
    EDA tool can apply that to all of the crosstalk channels that used to be
    inputs to the model.
  - We just give responsibility for that to the EDA tool.
- Arpad: I understand.
- Ambrish: Why only CTLE?  Why not DFE?
- Walter: On the Rx side cross talk comes from other Txs, not "my" Tx.
  - So that cross talk that comes into the Rx just goes through the CTLE.
  - Everything goes through the CTLE.
  - But the crosstalk is not affected by the DFE.
  - The CTLE part of the Rx amplifies the crosstalk, the DFE does not.
- Fangyi: [sharing Summary (Slide 10)]
  - Currently, we combine the input crosstalk IRs with the non-DFE as Walter
    said.
  - If the model now returns the non-DFE impulse, then we don't need this
    crosstalk data.  The tool can perform this convolution.
  - (So the need for the bottom row of the Summary slide could be eliminated.)
- Ambrish: Okay.
- Fangyi: Walter, if we really want to reduce the size of the data, we can
          stay with three output IRs.
  - We could just return the Rx non-DFE impulse in the same location in which
     the AC was passed in:
          (red box in (AC) -> red box out could be (Rx non-DFE)).
  - But it would be a little confusing because now the input and output data
    in that location would be completely different.
- Ambrish: That's how things are done now in the sense that data is modified
           in situ.
- Fangyi: [Returning to slide 4]
  - Now with this information, we look at the two cases:
    - Rx has GetWave()
      - TxGetWave() output is convolved with AC and passed into RxGetWave().
    - Rx doesn't have GetWave()
      - EDA tool takes the output of TxGetWave() and convolves it with the
        red box (AC and Rx non-DFE), and on top of that it adds in the
        convolution of the digital Tx input and the Rx DFE.
      - Note that the Tx digital input will need to be aligned with the
        TxGetWave() output.  The tool is responsible for shifting the digital
        Tx stimulus to align with the TxGetWave() output.
- Ambrish: Why doesn't the current version work in this scenario?
- Fangyi: Currently, if Tx has GetWave() and Rx does not, then you need to use
          deconvolution.
- Radek: Avoiding the deconvolution here is a side benefit of this proposal for
         the redriver flow.
- Ambrish: Understood.
  - We might clarify that red and blue are being passed in and red, blue, green
    are being passed out.
- Fangyi: [Normal Time Domain flow: Init-only Tx (slide 5)]
  - Now the red and blue inputs are identical.
  - Model outputs (Note: CTLE synonymous with non-DFE from here forward)
    - red - CTLE convolved with the AC and Tx equalizer.
      - This output is all the linear portions of the system.
    - blue - still what we have in the current flow.
    - green is still the DFE.
      - Now the DFE alignment with the linear impulse also considers the
        Tx equalizer.
  - Two cases for time domain analysis:
    - Rx has GetWave()
      - EDA tool just convolves the Tx digital input with the TxInit() output
        and passes it to RxGetWave().  Same as the current flow.
    - Rx has no GetWave()
      - EDA tool convolves the Tx digital input with the blue box output that
        contains everything.
- Ambrish: This is all the same as the current flow.
- Fangyi: Yes.
- Ambrish: When would we need the red and green outputs?
- Fangyi: They would not be needed (for this slide's scenarios).
- Fangyi: [Normal Statistical Flow (slide 6)]
  - Both the red and blue input boxes are just TxInit() output.
- Ambrish: Why would we need the red and green outputs?
- Fangyi: We don't need them.
  - The blue boxes are used for statistical.
  - Same as the current flow.
- Fangyi: [Redriver Time Domain Flow: GetWave Tx2 (slide 7)]
  - We are looking at the second half of the channel (downstream channel).
  - Tx2 has GetWave()
  - Model Inputs:
    - Red is the second half of the analog channel (AC2).
    - Blue is the entirety of the upstream channel back to the Tx1.
      - Blue output of Rx1 (includes Tx1, AC1, Rx1) convolved with the output
        of Tx2 Init().
- Ambrish: This is new.
- Fangyi: Yes, this is what Walter wants.
  - Rx2 operation is similar to other scenarios.
    - It convolves the CTLE with the red input (AC2).
    - It also returns DFE.
    - It updates the blue input by adding all the Rx2 effects.
  - Two cases for time domain analysis:
    - Rx2 has GetWave()
      - EDA tool convolves the Tx2GetWave() output with AC2 and passes it to
        Rx2GetWave().
    - Rx2 has no GetWave()
      - EDA tool convolves Tx2GetWave() output with the red box output (linear
        impulse, i.e., AC2 convolved with CTLE).  To this it also adds the
        digital input to Tx1 convolved with the Rx2 DFE.
      - Again note that the tool must align the Tx1 digital input and the Tx2
        GetWave() output.
  - The model gets to use the blue box input, the entire channel, to optimize
    the CTLE and DFE.
  - In this case, blue is really used for optimization.  The red and green are
    used for the actual waveform calculation.
- Fangyi: [Redriver Time Domain Flow: Init-only Tx2 (slide 8)]
  - Model Inputs:
    - Here the red box is the Tx2Init() output (AC2 and Tx2 equalizer).
    - The blue box is the same as before (entire channel).
  - Rx2 will use the blue box input to optimize the CTLE and DFE.
  - It then applies the CTLE to the red box input (to produce the red box
    output) and also returns the DFE in the green box.
  - Two cases for time domain analysis:
    - Rx2 has GetWave()
      - EDA tool convolves the Rx1 output with Tx2Init() output and passes it to
        Rx2GetWave().
    - Rx2 has no GetWave()
      - EDA tool convolves the Rx1 output with the red box output (Tx2Init()
        output convolved with Rx2 CTLE).  To this it also adds the digital input
        to Tx1 convolved with the Rx2 DFE.
- Ambrish: As much as possible, could you note when it is "current flow"?
  - For example, the time domain processing in the GetWave Rx2 case is the same
    as the current flow.
- Fangyi: Yes, I can add a note wherever it is the same as the current flow.
  - Note that the current flow has no total (blue box) input.
- Fangyi: [Redriver Statistical Flow (slide 9)]
  - Model Inputs:
    - Red box is Tx2Init() output (AC2 and Tx2 equalizer).
    - The blue box is the same as before (entire channel).
  - The model processes them the same way.
    - The red box output now also includes the Tx2 equalizer.
  - For the victim channel, the EDA tool will use the blue box output that
    includes everything.
  - When the tool also wants to include aggressors that come in on Rx1 and
    propagate down to Rx2, then it will need the red box output to account for
    those.
- Arpad: Did we get all the questions clarified?
- Walter: Yes.  With the change I requested so that we return the IR of just the
          CTLE, we can do everything we wanted and more.
  - In the email with Fangyi I also requested some Tx enhancements.
- Fangyi: The Tx enhancements are something new, so I need some time to
          consider them.
- Arpad: We talked about the CTLE and crosstalk processing.
  - What if there is no CTLE?  Can we still handle the crosstalk?
- Fangyi: Yes.  If we decide to return the CTLE alone in this red box, then
          it would just be a Dirac delta if there is no CTLE.
- Mike L.: I just want to remind everyone that we have a newly adopted BIRD
           template to use when this gets written up as a BIRD.
- Arpad: Thank you all for joining.

-------------
Next meeting: 19 April 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts: