Minutes from the 9 Sep 2014 ibis-atm meeting are attached. Thanks to Curtis Clark for taking minutes.
Mike
IBIS Macromodel Task Group
Meeting date: 09 September 2014
Members (asterisk for those attending):
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
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: * John Angulo
* Arpad Muranyi
Micron Technology: Randy Wolff
Justin Butterfield
QLogic Corp. James Zhou
Andy Joy
eASIC Marc Kowalski
SiSoft: * Walter Katz
* Todd Westerhoff
Mike LaBonte
Synopsys Rita Horner
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- Mike LaBonte unable to attend. Curtis Clark to take minutes.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- No new ARs from last week. Holdovers:
- Ambrish - Investigate other ways to communicate tap coefficients in BIRD 147.
- In progress.
- Arpad to review IBIS spec for min max issues.
- In progress.
-------------
New Discussion:
BIRD 147:
- Arpad - We had an intense discussion last week.
- We were left with a question, really an AR for all EDA vendors.
- Observation was made that, as written, AMI Init() back channel
results are not available for use in GetWave() flow.
- In non-backchannel simulations this use of Init() output in the GetWave()
flow is allowed.
- SiSoft raised issues with this limitation in BIRD 147.
- How do other EDA vendors feel?
- I had internal discussions with my colleagues. I have some questions.
- I'd like to let others speak up first if they have questions. [None]
- Todd - You're asking if we want a model to support Init() and GetWave()?
- Arpad - I want to get feedback on this limitation of BIRD 147.
- Can't use the Init() function's optimization results in the GetWave()
flow with back channel.
- Comment from SiSoft last week was that this is imperative.
- Walter - Arpad asked -other- vendors for their comments.
- Todd - I just want to clarify the question.
- A model is training in Init() (first level) and then that can be used as a
starting point for GetWave().
- Arpad - Now here is my question. Are we talking about:
- 1. Backchannel between the Init() Tx and Rx telling each other things. Then
take those results into a normal time domain flow GetWave(), but no
more backchannel is done.
- 2. Or, other approach is Init() functions begin backchannel and then
GetWave() continues with more backchannel and refining things before the
actual time domain simulation begins.
- Which scenario are you talking about?
- Walter - The answer is yes ;-)
- Particularly the second one.
- PCIe Gen3 has three phases of training:
- 1. Data rate.
- 2. Coarse training - basically a series of presets without describing a
mechanism for how the hardware does it. It has the Tx configure itself
in one of 7 or 9 presets that Gen3 requires. Then the Rx decides which
one is best and tells the Tx to start off.
- 3. Then it goes to fine tuning, where it starts modifying tap coefficients
by small amounts.
- So, SiSoft thinks that one way to efficiently implement this is to do coarse
training in Init(). Rx Init() does a coarse evaluation based on presets.
Then it can go through time domain GetWave() to do fine tuning.
- Arpad - I understand that some protocols may do this.
- Does it have to be split up into Init() and GetWave() portions?
- Ambrish - You're exactly right.
- Nothing precludes it from doing both [coarse and fine] in one flow.
- The EDA tool could run Init() and then use the output to do GetWave().
- Walter - How does the EDA tool know the model is written that way?
- Ambrish - The model says if it supports Init() and or GetWave().
- Assume Init() based training is more coarse.
- Walter
- But the EDA tool is responsible for taking the BCI branch string and passing
it back and forth.
- According to the BIRD it can be passed back and forth in the Init() flow or
GetWave() flow [not both].
- Ambrish - It could do both.
- It runs Init() then takes the output and passes it back to GetWave().
- Arpad - Going back to the question of where to do it.
- Vladimir gave me feedback that if we were to allow backchannel to start in
Init() and then continue to GetWave(), the logic of the function calls could
get very complicated. I haven't thought this all through.
- Ambrish - In the flow you don't need to do both and can still get good
results.
- Arpad - Our feedback on the two questions seems to be:
- Allowing dual Init() and GetWave() training could get complicated.
- We could, however, use Init() training results directly for GetWave() flow.
- Arpad - I would like to know if we should continue asking Ambrish for changes.
- Radek - I didn't get as much feedback as I had hoped.
- My personal opinion, I would like to go back to the more fundamental
question of whether we should allow or consider mixed simulation type versus
training type.
- That's the first question, whether we allow Init() training for a subsequent
GetWave() time domain simulation and, vice versa, can we use a GetWave()
type training prior to a statistical analysis?
- Those are my first fundamental questions before worrying about mixing of
Init() and GetWave() based training.
- I haven't gotten good feedback on that yet.
- What's the answer to that first fundamental question?
- Arpad - What question?
- Radek - Do we allow mixing training and simulation types?
- For example, GetWave() training followed by Init() based simulation.
- Arpad - Good question. I didn't get that question out of it.
- John - Once you're in GetWave(), you can't go back to Init().
- Arpad - Well, we are messing with the flow anyway.
- John - Not that much.
- Radek - Just until training. After training you can use a different flow.
- John - Can the model now remember from Init() call to Init call()?
- Walter
- If we required or allowed the ability for Tx GetWave() to output its tap
coefficients - not unreasonable to ask for - in a way that the EDA tool
could understand, then it could start a new simulation flow Init() using
those coefficients.
- John - I have a question, Walter.
- Can that be abstracted away from the specific topic of pre-emphasis tap
weights?
- I think you're only asking for reserved parameters based on assumptions
about what you need to describe the set up.
- What if we said any InOut parameter could be remembered by the EDA tool and
passed into the following Init() call?
- Walter - It makes a lot of sense.
- EDA tool would have to be written in such a way that it could take the InOut
parameters from the last call and pass it in to the follow on Init() call.
- Excellent idea.
- EDA tool needs to know the model can do this.
- Radek - One comment I got was the current BIRD doesn't say what's allowed.
- Walter - I'd like to step back on another thing.
- One of the statements made at the last DAC summit by Synopsis was about the
interoperability of training between Tx and Rx. In practice, the only
implementations of Silicon where training actually worked were when the Tx
and Rx were designed by the same IP vendor. Any time they tried to mix Tx
and Rx IP vendors it failed. One of the reasons is that if you go to the
standards and read about "link training" it's pretty horrific. Two
companies could come up with two different methods. So, it's an issue in
the industry and anything that can help support it including IBIS support
for backchannel or "link training" could help. The point I'm making is that
BIRD 147 was written three years ago by people who may have had a link
training working in their hardware, but it was myopic. The current BIRD
describes the way the interpretation was made by Gennum three years ago, and
I don't think the industry understood the problem.
- As I've said repeatedly, there are two fundamental problems with BIRD 147.
- 1. It really says that you train in Init() or GetWave() but not both. It
doesn't recognize dual mode models supported by the industry.
- 2. It puts constraints on the kind of you content you can put in the BCI
branch for communication in order to be a standard.
- Both problems are fundamental and structural.
- Ambrish - We are trying to solve issues faced today, not three years ago.
- The industry has adopted backchannel training in hardware.
- You're right that expecting Tx and Rx makers to interpret training sections
is a non-starter.
- That's why we want to have people sit down and layout the backchannel part.
- We've tried to keep it as simple as possible.
- We believe two companies could make a Tx and Rx and follow this flow and it
will work.
- Walter - Ambrish, I agree.
- You're 100 percent right. Communication of what Tx sends to Rx and vice
versa needs to be defined.
- But why limit the definition of what you can send?
- Ambrish - The increment decrement system is the most basic communication.
- Last week you mentioned a standard that doesn't use it.
- But, I went back and looked and it does use increment decrement.
- I think we have enough in the BIRD to allow the model maker to define their
Tx Rx communication.
- The reason we haven't crisscrossed [Init() and GetWave() training] is to
keep it simple.
- The communication is simple: Init() - Init(), or GetWave() - GetWave().
- Walter - You agree that PCIe Gen3 uses coefficients not increment decrement?
- Ambrish - We added that for you.
- But you can make an AMI model that will use increment decrement to model it.
- When making the BCI you can define increment decrement so it will do it.
- Walter - Let's say I did a piece of IP that doesn't do increment or decrement.
- It does it by setting coefficients.
- I look at the standard and it's very clear that Tx advertises
coefficients...
- Arpad - This isn't the current hangup, it has been added.
- The current question is the mix of flows.
- Walter - We haven't settled the fact that there could be other mechanisms.
- What is the purpose of Cadence insisting on constraining what gets
communicated back and forth?
- Why can't some standard say, "Here's my black box" and define what it is?
- Ambrish
- That will complicate the entire process of standardizing the way of
communicating.
- Two vendors can write their own BCI file. If it then becomes a standard...
- Walter - I give up.
- Radek - I agree with Walter. Why limit ourselves?
- Remove all this information from the IBIS spec, and all info about the BCI
branch should be in the specific protocol and the EDA tool should not be
bothered to understand it.
- Ambrish - The EDA tool already doesn't bother.
- Radek - We do say increment, etc., when we don't have to.
- Ambrish - Where?
- Radek - That should be in the specific BCI file.
- It would define the interpretation of the protocol specific data.
- Ambrish - All standards other than PCIe Gen3 have increment and decrement.
- Radek - Tx and Rx should be passed entirely without EDA tool interference.
- Arpad - Sorry to bring up a long time pet peeve of mine.
- This goes back to numerous presentations I've made at summits.
- I always wanted more flexibility.
- Canned keywords restrict us. Why don't we use a more general language?
- I even demonstrated that it could be done.
- I used AMS languages to make an AMI flow.
- I have an issue with predefined footprints and flows.
- We should have a general language like VHDL AMS.
- Then people can write their own models.
- But we decided to go with IBIS AMI the way it was written and with
predefined flows.
- Now we are in that box.
- We are pushing the limits of that box and feeling the constraints.
- Ambrish
- The whole discussion here is how to provide a Tx Rx feedback mechanism.
- Increment decrement isn't just general it's the basic way of doing it.
- We would have to discuss this mechanism every time we came up with a new
BCI file.
- But if it is in the specification already then you just go.
- Radek - But then you get locked into the current version.
- If it is open you establish the means and method of communication but the
interpretation comes from the protocol.
- Ambrish - That would complicate it.
- Walter - It would simplify things for the EDA tool.
- Is it possible Cadence has some IP that works the way you want for "ibis
approved" protocols?
- Ambrish - No, this is what we agreed upon.
- Walter - Then why not say anything can be "ibis approved?"
- Ambrish - BCI file itself is still an IBIS approved document.
- It's the feasibility of maintaining one document or 5 or 10 or 15 documents.
- Walter - My concern is that you've said for 3 years that it is done this way.
- Then we get to a very common bus [PCIe Gen3] and find it's not true.
- Ambrish - All use increment decrement except PCIe Gen3.
- Once you write the AMI model you can still do it using coefficients.
- Walter - Not really.
- In Gen3 they want to set presets, tap coefficients, and data rate.
- Gen3 doesn't start off at 8GHz, it starts elsewhere.
- It gets really complicated to constrain everything to one company's
understanding from three years ago.
- We know things from three years ago were not interoperable.
- We need to not implement what Cadence and Gennum wanted 3 years ago.
- Ambrish - We asked this question a few months ago.
- This was acceptable to most IC vendors.
- That's why we're talking about this BIRD and not the alternative.
- Walter - That's not a true statement.
- You may have polled some IC vendors, but not all found it acceptable.
- Arpad - Let me stop and ask two questions.
- 1. Can BIRD 147 be adjusted so that it is acceptable to those who are
objecting to it?
- 2. Will Cadence make the changes if people want them?
- Ambrish
- Walter's chief objection is that we've constrained communication methods.
- Arpad - Question: Can BIRD 147 be adjusted to meet the questions?
- Ambrish - Are we trying to splinter the IBIS spec?
- Arpad - I'm not sure I follow...
- Ambrish - Communication mechanism would not be in the IBIS spec.
- It would be in a separate document read by the Tx and Rx guys.
- Arpad - I want to understand where we stand.
- It has been: we request change, Ambrish makes it, we request change...
- Do you, Walter, see that BIRD 147 could be adjusted to handle your issues?
- Walter - I do not think it is possible.
- I think it is based on so many premises I disagree with that I don't see a
path.
- Arpad - Okay, we don't have to ask the next question of Cadence.
- Ambrish - I agree with Walter.
- Walter requested Init() based training.
- Walter asked us to include PCIe Gen3 training and table it until we did.
- Now he has other issues...
- Walter - No, I never requested that you include PCIe Gen3.
- I just said don't exclude it.
- Ambrish - This was not excluding PCIe Gen3.
- Walter - Okay...
- Arpad - That would put an end to this discussion.
- We need to just bring this to a vote.
- Get a motion to get this finished and make a recommendation to take a vote.
- Bob - I have some technical changes in some of the content.
- It's not ready for a vote.
- I have concerns with how it's written.
- Page 3 of the training section, some of the rules are inconsistent...
- Arpad - Maybe we need to continue this via email.
- There are only 3 minutes left.
- Bob - Right, okay, I'll send Ambrish some changes.
- Arpad - This looks like a good stopping point for today's meeting.
- Any last minute questions? [None]
- Thank you all for joining.
- Let's try to finish this next week and hopefully get a motion to vote.
-------------
Next meeting: 16 September 2014 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
