[ibis-macro] Minutes from the 27 May 2014 ibis-atm meeting

  • From: Mike LaBonte <mike@xxxxxxxxxxx>
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 27 May 2014 16:27:07 -0400

Minutes from the 27 May 2014 ibis-atm meeting are attached.

Mike
IBIS Macromodel Task Group

Meeting date: 27 May 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
                              Scott Huss
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
Teraspeed Consulting Group:   Scott McMorrow
                            * Bob Ross
Texas Instruments             Alfred Chong

The meeting was led by Arpad Muranyi.

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

- None

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

- None

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

- None

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

Backchannel:

- Bob: The issue is whether or not to have a BCI file.
  - The Cadence proposal has 3 reserved parameters, 6 BCI, and a new Type Bits.
  - The SiSoft proposal has 16 Reserved_Parameters, but it has more generality.
  - Don't have a good feeling about the BCI file.
- Arpad: There is a question about the gatekeeper of the BCI file.
  - Do we need to decide that first?
- Fangyi: We can't decide on a proposal without deciding that.
- Ambrish: That language is in the BIRD.
  - The IBIS committee or a subcommittee would review and post on the website.
- Fangyi: Would voting be required?
- Ambrish: Yes, we need a standard way to accept it.
- Ken: This committee will be important.
  - If it goes into the AMI file there probably will be new reserved parameters.
  - I like the Protocol_Specific, which avoids new parser requirements.
- Ambrish: It would not depend on interpretation from anyone else.

- Radek: There could be an interpretation problem, and private protocols.
- Ambrish: Private protocols would not use the standard BCI files.
- Fangyi: How will the too understand private protocols?
- Ambrish: It does not have to understand anything.
- Radek: We might ratify something not in BCI and have an empty solution.
- Walter: The BIRD itself can not have any BCI examples that would be ratified 
at the same time.
  - Increment and decrement are part of the private protocol.
- Ambrish: It is part of the BIRD right now.
- Todd: If it's a black box then it can't say increment and decrement?
- Walter: Yes.
- Bob: That is confusing.
- Walter: 1.5.1 says the RX can send increment, decrement, or unchanged 
commands.
  - PCIe doesn't do that, it sends a number 0 to 63 for tap coefficients.
- Ambrish: We have a solution for that which takes just a few lines.
- Walter: Why can't that be private?
- Ambrish: The RX and TX need to understand each other.

- John: Does anything need to be added to help designers?
- Ambrish: Like the final values that are settled on?
  - There can be an output file.
- John: EDA tools should be able to present that to the user.
- Ambrish: That is not decided yet.
- Ken: That is not a functional issue.
- John: There might be a model specific part of the BCI file.
- Ambrish: That's a good idea but not part of this.
- Ken: Outputs beyond what a protocol requires should be accommodated.

- Radek: We have not discussed dependence between BIRDS 147 and 128.
  - Communication between RX and TX may depend on it.
- Arpad: Does Walter's proposal depend of 128?
- Walter: It is preferable to use existing GetWave, but we could have a new one.
  - That should not affect the decision.
  - A alternative TD approach could call Init and GetWave.
  - My proposal does rely on BIRD 128.
  - Truly private communication would need only a new text parameter.
  - It may not be needed, all current TXs can be controlled with what I've 
proposed.
- Ambrish: Statistical models are not a reflection of actual silicon.
- Walter: That is an imaginary problem, every TX has dynamic range limits.
- Arpad: Someone asked about training with only one GetWave call, can that be 
done?
- Walter: A real system requires the RX to communicate to the TX between 
GetWave calls.
- Ambrish: It is possible the RX could say nothing needs to be done.
- Kumar: 600,000 bits in one call should not be a problem.
- Arpad: This is about requesting a long bit stream for optimization.
- Kumar: There may be practical memory problems, we should support multiple 
calls.
- Todd: The RX only needs to not send another instruction until it has enough 
bits.
- Arpad: Can the models tell the EDA too how many bits to provide?
- Walter: There can be performance issues, but a new Reserved Parameter would 
be needed.
  - Any reasonable adaptation would require at least 10 to 20 iterations.
  - You can only change taps once per GetWave.
- Fangyi: Will be final result depend on GetWave sizes?

- Arpad: Could we revisit the motion from the last meeting?
- Walter: Ambrish made the motion and I seconded.
- Ken: It should be whether to proceed with BIRD 147.
- Arpad: That BIRD is currently open but tabled in the Open Forum.
  - The SiSoft proposal is not a BIRD.
  - We can make recommendations to the Open Forum on how to vote on BIRD 147.
- Walter: The question is if this committee should table work on BIRD 147.
  - Option B would be to work on another BIRD.
- Michael M: BIRD 147 was sent to us by the Open Forum for our recommendation.
- Radek: Last week we had IC vendors who are not here today.
  - We should have their votes.
- Arpad: Two responses received from one company conflict with each other.
  - That might be an abstention or we could take the second response.
  - Not sure what the final opinion would be from the others.
  - TI is not a voting member however.
- Michael M: It depends on who made the motion.
- Ambrish: It should be to work on BIRD 147 or go with Walter's proposal.
- Michael M: Usually the vote is Yes/No/Abstain

- We votes on whether to proceed with BIRD 147.
- Roll call vote:
  Agilent:                  N
  ANSYS:                    A
  Cadence Design Systems:   Y
  Intel:                    Y
  Mentor Graphics:          A
  Micron Technology:        A
  SiSoft:                   N
  Teraspeed                 A
- Tally: 2 Yes, 2 No, 4 Abstain.

- Ambrish: Can we hold the vote later with other members present?
- Arpad: Marvell may want to vote.
- Bob: Marvell is not a member.

- Walter motioned to invalidate the vote and schedule a new vote.
- Arpad: That may not be necessary, we had a tie.
- Walter: DAC is next week, we might not meet.
- Arpad: We can meet in two weeks and vote then.

-------------
Next meeting: 10 June 2014 12:00pm PT

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 27 May 2014 ibis-atm meeting - Mike LaBonte