[ibis-macro] Minutes from the 08 Jul 2014 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 09 Jul 2014 08:39:27 -0400
Minutes from the 08 Jul 2014 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 08 July 2014
Members (asterisk for those attending):
Agilent: * Fangyi Rao
Radek Biernacki
Altera: * David Banas
ANSYS: * Dan Dvorscak
* Curtis Clark
Avago (LSI) Xingdong Dai
Cadence Design Systems: * Ambrish Varma
Brad Brim
* Kumar Keshavan
Ken Willis
Ericsson: Anders Ekholm
Intel: * Michael Mirmak
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
* Bob Ross
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- Mike L: Arpad is not here, who can chair?
- Michael M agreed to chair.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad formulate a vote for next week.
- Arpad not present.
-------------
New Discussion:
BIRD 147:
- Michael M: Did we discuss the announcement from SiSoft in the last meeting?
- John: Yes.
- John: Arpad formulated the list of questions for us in agenda item #5.
- Michael M: We can discuss those questions.
- Bob: we need to tighten up the list.
Question #a) Should we make a recommendation to the IBIS Open Forum about BIRD
147
now (to be accepted as is) and develop a more general solution
later?
- Kumar: No EDA tool can do optimization.
- We should not waste time on this.
- Arpad: BIRD 147 addresses the backchannel mechanism only.
- It is a subset of a general solution.
- Cadence believes it is all that is needed.
- Kumar: EDA tools have no place in optimization.
- The RX will find a solution and the EDA tool can't interfere.
- Arpad: Is it the job of IBIS to cover this or are tools on their own?
- Ambrish: The question is what are we trying to solve?
- Todd: One of our customers wants this, they optimize on a per channel basis.
- SiSoft might have to disengage from this meeting if we can't discuss a
solution for that.
- Kumar: They can come up with a solution but it will not be what the RX
actually does.
- Michael M: The EDA tool will have to be involved in any communication between
TX and RX.
- We have internal tools that find the best settings for a channel.
- These tools do make recommendations about what the silicon does
automatically.
- Todd: ... Whether the hardware does optimization or not.
- Michael M: True.
- It must be clear to the tool and user what mode you are operating in.
- Todd: The silicon doesn't interact with the EDA tool.
- The goal is to identify optimized register settings for bring-up.
- Michael M: A specific solution and a more general solution would be fine.
- Ambrish: Is it the specification's place to define this?
- Michael M: We will provide only the pipes.
- If vendors want to provide extra capabilities they will need this.
- Todd: No one suggested we were putting optimization in EDA tools.
- We are generalizing communication between TX and RX.
- Ambrish: We saw a TX that makes jitter adjustments without changing taps.
- The RX sends analog feedback, just good/bad signals.
- Todd: The RX sends info that is not a tap setting?
- We need to know the details.
- Ambrish: We just need to keep the door open for new methods.
- BIRD 147 is formatted for that.
- Todd: You're saying you can more broadly enable cross vendor optimization.
- This is because BIRD 147 makes no assumptions about what the TX and RX
will ccommunicate.
- SiSoft is saying the TX can be characterized by taps, spacing, limits, and
tap quantization.
- If we accept that, legacy TX models can work with optimizing RX models.
- BIRD 147 requires both TX and RX to be written to support optimization.
- Ambrish: BIRD 147 helps vendors A and B to agree on what the controls are.
- Kumar: We are not talking about vendor A and B.
- We can't be restricted from doing proprietary things.
- What goes to the TX can't be done outside the RX.
- Michael M: We don't want the TX and RX stepping on each other.
- Arpad: How involved does the spec have to be?
- Walter: There are two kinds of models in this context:
- One has limits on granularity, it does standard things.
- Another has a "framis" knob that can be anything.
- The RX might know how to handle the TX's framis.
- It should be a requirement for the RX to be able to communicate those
settings.
- Todd: The Cadence proposal is based on the BCI file.
- The SiSoft proposal would not know how to handle new control types.
- Walter: A new "framis" parameter could be added to tell the tool what
settings to change.
- Todd: The question has been if we put parameters to be tweaked in the spec or
just say "hers is a channel" and stand back.
- The appeal of the SiSoft proposal is co-optimizing TXs not made for it.
- Introducing "framis" makes this more a subject of contention.
- Walter: We can kill two birds with one stone.
- John: An adapter could be used to make existing models work.
- Could the SiSoft proposal work in the context of BIRD 147?
- The RX would say what it needs to control, the TX would say how to do it.
- Walter: A PCIe3 RX would say what it is controlling and the EDA tool would
take care of it.
- Todd: Careful, this is handled in real time.
- Walter: AMI_Init can be called multiple time for legacy models, to adjust
settings.
- John: Maybe Cadence and SiSoft could merge these ideas
- You would have to observe some principles.
- Michael M: Maybe this would answer Arpad's first 4 questions.
- Ambrish: Is the question how to make model A work with model B in the
back-channel framework?
- Kumar: The final solution is path-dependent.
- Algorithms have vast dynamic range.
- It is heavily device dependent.
- For example it might change the CTLE first then DFE, or other way around.
- Todd: This is the local minima/maxima problem.
- Michael M: The tool does not control the order of evaluation.
- Kumar: The RX does.
- Todd: The question is if we can characterize TX capabilities in a generic way
or if specific TX/RX pairs have to be made.
- Michael M: We probably are not near agreement on item #e.
- Will we have text for a vote next week?
- Todd: I think we are closer.
- Arpad: Users keep trying tap settings until they like what they see.
- Why can't we automate that?
- Ambrish: We already have that ability.
- Walter: Users have documents to help them do that.
- The EDA tool needs that extra information in a format it understands.
Questions we did not get to:
#b) Should we develop a complete optimization solution and bring that to
the IBIS Open Forum when done (with or without BIRD 147)?
#c) Should BIRD 147 be extended towards a complete solution?
#d) Should we develop an independent BIRD for a general optimization
solution (but making sure it works together with BIRD 147)?
#e) What should be the scope of the complete solution?
- define a system optimization in which the Rx model is in control:
in this case the EDA tool would only act as a translator between
and optimizing Rx model and a non-optimizing Tx model
- define a system optimization in which the EDA tool is in control:
in this case the EDA tool would do the optimization with non-optimizing
Tx and non-optimizing Rx models
-------------
Next meeting: 15 Jul 2014 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 08 Jul 2014 ibis-atm meeting - Mike LaBonte
