Minutes from the 14 February ibis-atm meeting are attached
IBIS Macromodel Task Group
Meeting date: 14 February 2017
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
IBM Luis Armenta
Trevor Timpane
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
* Vladimir Dmitriev-Zdorov
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Walter noted that he would like five minutes to discuss BIRD 189.
-------------
Review of ARs:
- Walter noted that he had asked everyone to review the updated file naming
rules document, BIRD 186.1. Bob R. had sent it to the ATM list for review.
- Bob R. noted that at the last Open Forum meeting BIRD 147 had been sent back
to ATM for review. Radek had suggested that one sentence detailing a
potential work around a tool that didn't support the BIRD was unnecessary.
Bob Miller had agreed. Arpad noted that Vladimir was attending so we could
review some of his questions as well.
- Arpad to help Fangyi with introducing the equation notation to the Flow BIRD.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- The February 7th minutes were not prepared and posted in time for the meeting.
Minutes for January 24th were reviewed, as they had not been ready for the
February 7th meeting.
- January 24th minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Bob R.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD 147 Discussions:
- Arpad: Bob M. and Vladimir could discuss the private emails they've had
regarding some of Vladimir's questions.
- Bob M.: [sharing the email]
- Question: Do all the AMI parameters files used by the AMI models need to
explicitly specify AMI_Version 7.0 in order for EDA tools to consider back-
channel communication mode, or is it enough to make sure that all the AMI
models define the same protocol and have all other required parameters set
properly?
- Bob M.: My only answer is that the parser will fail if it sees these new
reserved AMI parameters for BCI in an AMI file with a revision prior
to when this BIRD is introduced.
- Discussion: Walter noted that some EDA tools are already dealing with these
parameters as model specific parameters. If the model's AMI file contains the
model specific parameters then some tools will support them. The EDA tools
need only pass in the user selected values for some In parameters (note:
BCI_State is an InOut, however). Walter noted that the goal was to minimize
the EDA tool's involvement. He noted that one thing the EDA tool did to make
the process easier was to automatically provide the BCI_ID value to all models
on the same channel, but this was not required. Walter said this had been
designed with minimal EDA tool involvement so model makers like Bob M. could
proceed with some back-channel work prior to tools supporting the BIRD.
Vladimir noted for clarification that for now we had a temporary workaround of
using these parameters as model specific, but starting from 7.0 (or when this
BIRD is adopted) these would become Reserved parameters. Arpad noted that
this was similar to the BIRD 158 situation, in which some models were being
released with BIRD 158 parameters in the model specific section and those
would be Reserved when and if BIRD 158 becomes part of the spec. Walter
agreed. Vladimir asked why we needed this BIRD at all if it could be done
currently with model specific parameters. Ambrish noted the BIRD fully
defined several parameters that allowed the EDA tool to control training time,
abort the simulation, monitor training progress, etc., and provided a
first step toward generalizing a solution for back-channel. He said that
without this BIRD we had no generally defined and recognized way for tools
to support back-channel. Bob R. noted the general purpose of adding Reserved
parameters so that their meaning is fully defined by the specification and
every tool knows exactly how they should be utilized. After this discussion
Vladimir noted that he might re-formulate some of his questions and resubmit
them later.
- Bob M.: I want to mention one other question of Vladimir's I found
interesting.
- Question: It looks like no training is allowed when communicating the
modified impulse responses between Init() calls, only GetWave() may
implement model communication?
- Discussion: Bob noted that this was a true statement. Nothing prohibits the
Tx or Rx from leaving a BCI message in the file after Init(), but the Rx
has no means of communicating information back to the Tx before the first Tx
GetWave(). Bob noted that there had been concerns about how training during
Init() might modify the flow for the tool. Ambrish also noted that there had
been other concerns about complicating the messages left in the BCI file
itself. So, in general, this BIRD deals only with GetWave() based
optimization.
- Bob M.: I've submitted BIRD 147.6, with the only change being the deletion of
the work-around sentence "If an EDA tool does not use
BCI_Training_UI ...", as we discussed.
- Mike L.: I received that submission. I will get it posted.
- Walter: Motion that ATM recommends that the IBIS Open Forum pass BIRD 147.6
for inclusion in the next significant release of IBIS.
- Ambrish: Second.
- Arpad: Anyone opposed? [none]
- I will send an email to notify the Open Forum.
BIRD 186.1:
- Walter: Did anyone have any questions about 186.1 after reviewing it?
- Walter: Motion that BIRD 186.1 be submitted to the IBIS Open Forum with a
recommendation from ATM that it be passed.
- Bob M.: Second.
- Arpad: Anyone opposed? [none]
- Bob R.: I will submit it to the Open Forum.
- Arpad: I will also send an email to notify the Open Forum about this one.
BIRD 158:
- Walter: Radek has gone through a re-write of this.
- We should defer until Radek is here.
Single Ended Applications of AMI: (DDR5 coming soon)
- Arpad: Do we need anything in the spec for this?
- Walter: Last week I made the statement that there's nothing we have to do in
IBIS to handle single ended channels.
- It came up because at the DesignCon Summit Fangyi brought up common mode
issues with single ended channels (DDR4, DDR5, etc.).
- I suggest we table this until Fangyi is here.
- Ambrish: It was also mentioned at the DesignCon Summit that there is no place
in the spec that says we can't do single ended.
- The spec currently mentions that we can do both.
- There may be something else we have to add, but as of now it's a raw analog
waveform which is passed to the model, and we do handle it.
- Walter: Specifically, we are talking about IBIS AMI on DDR4 DQ models.
- Ambrish and I agree that we should wait for Fangyi.
- Bob R.: Question for Randy, for single ended applications would you expect to
see an s2p models.
- Randy: I think you could be modeling a full channel with coupling, or if you
do a single DQ at a time it might be an s2p.
- Another complication is that the clock is not embedded. We need to simulate
a strobe too.
- Walter: Another answer to Bob's question is that when we say DDR5 (or maybe
DDR4, too) for single ended the channels will be SPICE models and may
include s2p. We're not sure if the driver itself is going to need a
Touchstone option. It's not clear because the DDR5 spec hasn't been
written yet. However, DQS, the strobe is really not true differential
but two single ended DQ buffers. It's not clear about the routing, so
they may use s4p or s2p.
- Ambrish: Do we even need an AMI model for the strobes?
- Randy: Yes, because it will have the same receiver as the data will. Any
equalization is applied to the strobe as well as the data.
- Walter: Even though the data pattern is 010101, and peaking filters don't do
anything with that, and DFE doesn't do anything productive with it,
they want the same equalization on the DQS as the DQ so they don't
introduce any additional skew.
- Probably train on DQ and then introduce the same equalization on the DQS.
- It's basically a waste of power to have equalization on the DQS.
- Randy: Fangyi had talked about some potential common mode issues. I asked him
to attend the ATM call to discuss the concerns.
- Walter: It is true that there are common mode issues that the EDA tool has to
deal with very carefully.
- This is for the EDA tool to deal with, not the model.
- Arpad: If it turns out that there is nothing we need to add to the spec from
the algorithmic point of view, then will we need any new "logistics"
parameters to help deal with the timing issues and the fact that we
have data and clock on separate lines?
- Walter: Likely no.
- Randy: Probably similar to how there's lots of timing in current DDR specs,
but it's up to the EDA tool to do it.
- Arpad: Currently, when we run an AMI simulation we make an eye using clock
ticks returned by the receiver that models the CDR.
- How is that done if you have separate clock and data lines?
- Walter: I'd like to answer that, but I'm not sure people on JEDEC have
resolved it.
- There is still disagreement on fundamental issues in the DDR5 spec.
- As soon as DDR5 has been standardized we can write a BIRD to handle it.
BIRD 189:
- Walter: I'd like to talk about packaging.
- Many of us have been in the packaging meetings.
- The BIRD has been finished and submitted.
- There will be an update with errata and improved graphics but no substantive
change yet.
- I think it's important that every EDA vendor review the BIRD to make sure it
is well defined enough that they can implement it.
- It's also important that every IC vendor that delivers package models make
the following judgement, "I am currently making package models for customers
that need broadband package models. Can I use these same models with this
new syntax?"
- Arpad: I have a question for Randy.
- Randy, in your package models you usually provide an on-die decoupling
subcircuit.
- Would that kind of modeling also be supported with this new BIRD 189?
- Randy: Yes, as long as the on-die decoupling is IBIS-ISS compliant or is a
Touchstone you can wrap it up in a package or on-die interconnect
model and BIRD 189 will fully support that.
- Arpad: You often provide a full chip decoupling model and per DQ model.
- Would they both work?
- Randy: I think you could decide if you wanted to include a more detailed on-
die interconnect model for the PDN, then you could use the per DQ
decoupling models to show where they actually attach to the PDN.
- Otherwise, if you don't need that kind of detail, the full chip decoupling
model is probably quite sufficient.
- Arpad: Would you see the need to continue supplying the two types?
- If so, is there an easy way to select one approach or the other?
- Would you need two completely different models for per DQ vs. overall?
- Randy: I'd probably need two separate models available through a selector if
I really wanted to have both.
- I'd probably just choose one or the other approach when I created the model.
- Walter: I'd like to get better coverage and review by IC vendors in general.
- There are only two things in the BIRD that I'm not happy about. One is:
- The requirement that if we split models between the on-die interconnect
and the package interconnect so that the models are really in two separate
files, they have to be concatenated together in one model set. I'd like
to be able to put the on-die models in one interconnect model set and the
package interconnect models in another set. The BIRD does not actually
prohibit that, but it does "strongly recommend" that they be put in the
same interconnect model set. I think "strongly recommend" is too strongly
worded. I think it can be inconvenient to do that, particularly for
memory and FPGA vendors, and I would like more flexibility.
- Bob M.: I would generally support more independent representation of the
models in IBIS files as opposed to linking them all together. Linking
has generally caused problems for us in getting the data associated
with the right Tx, Rx, and IBIS file when things are mixed and matched
all over. Being able build a model for an Rx, and embed it in an IBIS
file, and have an AMI file for it and package it all up as an Rx is
more useful for me.
- Walter: You would like to have the package model as part of the AMI file?
- Bob: I'm not sure.
- I tend to view the package as part of the channel as opposed to part of the
Tx or Rx. That's because I'm doing ASICs as opposed to standard parts.
- Walter: That's one reason. The other reason is that you can't put these
broadband package models in an IBIS file right now. The only way
you can do it is by putting it in the channel.
- That's one of the reasons we implemented this.
- I could look at one of your examples and demonstrate how to take one of
those package models that you normally put in the channel and incorporate it
into the IBIS file. If that gets far enough we could show the example to
the ATM.
- Bob: Okay.
- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Bob Ross to submit BIRD 186.1 to the Open Forum.
AR: Arpad to email the Open Forum regarding BIRD 186.1.
AR: Arpad to email the Open Forum regarding BIRD 147.6.
-------------
Next meeting: 21 February 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
