[ibis-macro] Minutes from the 1 April 2014 ibis-atm meeting
- From: "Randy Wolff (rrwolff)" <rrwolff@xxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 4 Apr 2014 19:56:59 +0000
Minutes from the April 1, 2014 IBIS ATM meeting are attached.
Randy
IBIS Macromodel Task Group
Meeting date: 1 April 2014
Members (asterisk for those attending):
Agilent: * Fangyi Rao
* Radek Biernacki
Altera: David Banas
ANSYS: * Dan Dvorscak
Curtis Clark
Cadence Design Systems: * Ambrish Varma
Brad Brim
* Kumar Keshavan
Ken Willis
Scott Huss
Ericsson: Anders Ekholm
Intel: * Michael Mirmak
LSI * Amaresh Malipatil
Dai Xingdong
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: * John Angulo
* Arpad Muranyi
* Vladimir
Dmitriev-Zdorov
Andrey Matvienko
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
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- Michael Mirmak asked for time to discuss an issue.
- Arpad noted that Mike L. and Bob Ross sent emails that they could not attend.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad sent an email to prepare people for a vote on the direction of BIRD147
backchannel modeling.
-------------
New Discussion:
Amaresh introduced himself. He is in the SerDes architecture group at LSI. He
is substituting for the usual LSI attendee.
Michael has been looking with Bob at the ibischk6 parser. They found an issue
with AMI parameters. Michael showed Tx_Rj on page 207. The Type is Float or
UI. In Table 25 and 31, Float is not shown for Tx_Dj/Jitter/Rj/Sj. The parser
is going off the tables, so which is correct?
David said Float must be allowed. Todd said that Tx_Jitter has its own weird
types like dual dirac. Michael clarified that this is a Format and not a Type.
Todd said there is a purpose for Float or UI, as some parameters scale with
data rate and some don't. Float can be independent of datarate. Michael
concluded that therefore he should assume the tables are wrong and need to be
fixed. He'll tell the parser developer to ignore the tables. Also, there is a
document in the Version 6.0 directory of known issues. Arpad asked do we need
a BIRD or is it an editorial issue. Michael thought a BIRD is needed to bring
greater attention to it. Radek suggested checking the original BIRD text.
BIRD 147:
Arpad noted that we discussed last week taking an informal vote. An email was
sent out last week to get attention and ended up bringing up discussion on what
the questions really are. Ambrish also contacted Arpad to let him know that he
added a statistical flow to a new draft of BIRD147. Should we look at the BIRD
or do the vote?
Walter said he would like to move for a straw man vote on the questions posted
in his email, since there are subtleties to discuss. Ambrish said he still
believes statistical flow is not representative of the deveice, but he hears
there is a demand for it in the industry. So, he decided to add the support
for it in the BIRD. Michael seconded the motion.
Walter described the vote. A vote of Yes means that you desire to have a
single BIRD that:
1. Enhances IBIS AMI to enable Backchannel/Training/Co-Optimization.
2. It will not be required that an IBIS 7.0 AMI model support
optimization.
3. Optimization can be performed in either statistical (Init) and/or time
domain (GetWave).
a. It will not be required that an AMI model be able to support both
statistical and time domain optimization.
b. An AMI model may be able to support both statistical and time domain
optimization.
4. Enables an EDA tool to analyze the performance of the optimized channel.
5. Communicates to the EDA tool the Tx and Rx setting for the optimized
channel.
Vladimir asked for clarification on what Yes/No votes mean. Walter responded
that yes means any BIRD must satisfy the conditions stated. Walter stressed
the importance of item 5. Michael asked if item 5 means the EDA tool or the
user. Walter clarified that it means that it communicates to the user.
Kumar disagreed with the need for communicating settings, especially from the
Rx. David said we need to look at slides 4,5,6 of Walter's presentation to
understand what the requirements really are that we are voting on. Michael
thinks we are voting on the sense of the committee about requirements, not
setting anything in stone. Walter responded that item 5 is significant.
BIRD147 does analyze the performance of the optimized channel, but there is a
need to get the particular Tx tap coefficients from the model. Current BIRD147
in the time domain doesn't give a mechanism for doing this. Kumar noted that
there are too many types of Tx that report their settings in different ways to
standardize the output. Walter responded that there are always going to be tap
values that get set or emphasis values that get set.
Kumar said that Cadence should get a chance to present their flow and then see
what is not covered. Ambrish added that the Tx and Rx can communicate about
what values need to be changed in their flow. Todd said to Walter that he was
hearing a lot of confusion about what the votes mean. Todd recommended
withdrawing the motion, giving time to hear Cadence's BIRD and discuss next
week. Walter said he would like to get Cadence's BIRD changes to look at off
line. Ambrish said we can start discussion now and look at changes off line.
David said he would like to see Walter's presentation first.
Arpad noted a comment from Bob that whatever we do, we should solidify where we
are at with BIRD147, posting a BIRD147.2, then moving on with discusion. It
would be a good fall back point if we mess it up later. David asked what we
need more than the copy in the work archive. Walter noted he thought this
discussion was academic and we should move on.
Walter withdrew his motion.
Walter showed his presentation "Tx_Init_Optimizes". It is related to the
redriver BIRD, but also to backchannel. Tx_Init_Optimizes is a proposed name
for a new parameter. The presentation is on why Tx optimizing is wrong and how
to fix it. Walter stated that the redriver statistical flow in IBIS 6.0 is
incorrect. A Tx optimizing itself is wrong because no silicon does this.
Kumar felt that included settings such as P7 for PCI express are a useful place
to start. Todd added that what we see are Tx models that look at impulse
reponse and try to optimize to the channel assuming there is no Rx
equalization. We see that Tx taps can be dialed back and let the Rx optimize
better. David responded that we shouldn't embed language in a BIRD that could
be anti-innovation. Walter resopnded that AMI files should advertise if the Tx
is doing this or not.
David said imagine a Tx that has three settings: manual, auto or training.
Adding this parameter assumes auto has no place in the AMI universe. Michael
stated that we need to know if a tool is handling optimization. Walter stated
that (Usage In) (List False) is manual, the True setting is Auto, and training
he thinks is the same as a False setting. Ambrish thinks there is nothing
stopping this from happening with Model_Specific parameters. Ambrish asked for
time to talk over the BIRD147 changes since Walter's presentation was more
about the redriver flow and not backchannel modeling.
Ambrish noted one BIRD change was to use AMI_parameters_out for passing a
string from the Tx AMI_Init function to the Rx AMI model. Section 1.5.2 was
added for AMI_Init statistical flow. Tx AMI_Init is called twice in the flow.
Walter noted that the flow doesn't work if the Rx increments registers, only if
it sends back actual tap coefficients.
Walter requested time next Tuesday to give another prsentation on Tx models
that allows more flexiblity in the backchannel process.
Arpad requested Walter and Ambrish to send their documents to Mike LaBonte for
posting.
-------------
Next meeting: 08 April 2014 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 1 April 2014 ibis-atm meeting - Randy Wolff (rrwolff)
