Minutes from the 25 February ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 25 February 2020
Members (asterisk for those attending):
Achronix Semiconductor * Hansel Dsilva
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: Ambrish Varma
Ken Willis
Kumar Keshavan
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
* Todd Bermensolo
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): Walter Katz
Mike LaBonte
SPISim: * Wei-hsing Huang
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Fangyi to email his draft GetWave2() BIRD to ATM.
- Done. The version sent to ATM and posted to the work archives contains the
changes discussed at the previous meeting and captured in the previous
meeting's minutes.
- Arpad to send an email reminder about a straw poll on the sampling issues
in statistical flow AMI.
- Done. Arpad noted that additional email discussion had been triggered by
the reminder.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the February 18
meeting. Bob moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
DDR Clock Forwarding:
Fangyi reviewed the draft version of the BIRD sent to ATM after the previous
meeting. He noted that the Usage Rules: section for GetWave2_Exists now allows
for both AMI_GetWave and AMI_GetWave2 to be provided in the same model. In
addition, the Other Notes: section states that the model consumer, i.e., the
user or EDA tool, decides which one to use if both are provided.
Arpad asked if we should explicitly state that the EDA tool should not use both
GetWave() and GetWave2() from the same model in the same simulation. Fangyi and
Radek said they thought the existing language stating that the model consumer
"decides whether to use AMI_GetWave or AMI_GetWave2 in simulation" was clear.
Fangyi reviewed a new Note: he had added at the end of the AMI_GetWave2
section.
It stated that:
"AMI_GetWave2 shall be implemented only by Rx models that need to model
clock forwarding. In DDR systems, DQ Rx models can implement AMI_GetWave2.
DQS, command-address, control and clock Rx models shall not implement
AMI_GetWave2 because these signals do not use forwarded clock."
Arpad suggested that the second sentence be changed to:
"In DDR systems, for example, DQ Rx models may implement AMI_GetWave2."
Fangyi agreed and made the change.
Bob noted that the Required: section of GetWave2_Exists should state that it is
illegal before 7.1 (not 7.2), if we want this in 7.1. Fangyi/Arpad/Randy agreed
this should go into the same version as the DC_Offset BIRD (BIRD197.7), which is
version 7.1. Fangyi made the change.
Fangyi said his search had revealed 193 places where AMI_GetWave was mentioned
in IBIS 7.0. Radek noted his suggestion from the previous meeting that we
might include a blanket statement that any use of AMI_GetWave could also apply
to AMI_GetWave2. Arpad said this was a good suggestion, but we would have to
review the document because it might not work in every instance. Fangyi said
he was reviewing the document to find any instances for which the blanket
statement would not work.
Bob asked if we should state where within the specification these new sections
should be added. Fangyi said he thought this might be an editorial issue, and
he noted that recent BIRDs using the new template had not specified this
information. Arpad said that info could be added to the Summary of Proposed
Changes: section if necessary. Randy said the Editorial task group can figure
out where to insert the sections.
Other editorial changes, spelling, white space, etc., were suggested and made.
Arpad and Fangyi agreed that it was not necessary to post this version to the
ATM archives. The changes made during this meeting will appear in Fangyi's
next major update.
Discussion on "Gap in IBIS for sampling with statistical mode AMI models":
Arpad noted that he had sent the reminder email about today's straw poll to
choose a direction to pursue in a BIRD. The two choices, as defined in the
email, were:
a. Rx model tells the EDA tool where to sample
b. IBIS specification describes the rules for the EDA tool on where to sample
As this was just a straw poll to set direction, and Achronix had played a role
in advancing the topic, all attending organization were allowed to vote. The
straw poll went as follows:
Achronix - method a
Ansys - method a
Cadence - method a (via email)
Keysight - method a
Mentor - method a
Micron - method a
SiSoft - method a (via email)
SPISim - method a
Teraspeed - method a
Method a received 9 votes, method b received 0 votes.
Hansel asked what the next step was. Arpad said it was to start work on a BIRD,
and he noted that he thought Walter had said he'd be willing to draft a BIRD if
method a were chosen. Hansel said he would like to propose some additional
controls for the sampling. Since the IR matrix passed into AMI_Init contains
the through channel and crosstalk responses, why not have the sampling point
specified individually for each of the responses?
Arpad noted that he would have expected the sampling point to be the same for
all of them, but if there's a reason to control it independently then we can
consider that during the process of drafting the BIRD. Hansel noted that this
topic had come about as a result of trying to make AMI statistical mode work for
DDR vendors not just SerDes, and offset sampling points for crosstalk might be
useful. Fangyi asked what the definition of "sampling point" is for crosstalk?
Hansel said the issue was in phase vs. out of phase crosstalk. Fangyi asked if
that was a matter of the phase relationships between the different Txs,
something that's already controlled by the EDA tool. Hansel said he would put
together more information on the topic and present it at a later date.
Arpad noted that there might be two ways for the model to provide the sampling
point information to the EDA tool. It could provide an index into the
waveform, or it could provide a floating point value for the absolute time.
He asked if there was a reason to favor one over the other. Hansel said he
thought that both could work, but he preferred an index. He said that if we
decided to use a floating point value in UI or seconds then, depending on the
way we pass the value, we may have to worry about the number of digits of
precision, etc. Arpad and Randy said they thought a floating point number
allowing us to specify a time in between the fixed sample times would be better
than an integer index into the waveform. Arpad noted that these were details to
be worked out in the BIRD. He also noted that while he had voted for method a,
he would prefer we allow an option for the EDA tool to override the value
returned by the model.
- Curtis: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 03 March 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
