Minutes from the 30 June ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 30 June 2020
Members (asterisk for those attending):
Achronix Semiconductor * Hansel Dsilva
ANSYS: * Curtis Clark
* Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Ken Willis
* Jared James
Google: Zhiping Yang
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
Radek Biernacki
Ming Yan
Todd Bermensolo
Stephen Slater
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
Mike LaBonte
Teraspeed Labs: * Bob Ross
Zuken USA: Lance Wang
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Note: The next meeting will be on July 14th. The normally scheduled meeting
for July 7th has been cancelled.
-------------
Review of ARs:
- Hansel to add the PAM4 sentence back to his Rx_Clock_Recovery_Mean BIRD draft.
- Done. Submitted as BIRD206.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the June 23
meeting. Curtis moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD198.2:
Arpad noted that the BIRD's authors had agreed to the changes proposed by ATM at
last week's meeting. Randy reported that it had been submitted to the Open
Forum as BIRD198.2. Randy encouraged people to review the BIRD and raise any
technical questions via an email to the ATM list. Arpad said that since it had
been officially submitted to the Open Forum, he would remove it from the ATM
agenda. We can add it back if the Open Forum sends it back to ATM for any
further technical review.
Editorial Change to Rx_Clock_Recovery_Mean (BIRD206):
Arpad noted that at the last meeting the group had decided this BIRD was ready
to submit to the Open Forum. Randy said that he had received it from Hansel on
Friday afternoon, not quite in time to be introduced at the Open Forum meeting.
It is officially BIRD206 now, and Randy has asked Steve Parker (webmaster) to
post it. Walter said the BIRD was an excellent clarification of the language.
Arpad said he would also remove this from the ATM agenda.
Supporting PI Modeling/Simulation in IBIS:
Randy reported that Zhiping was unable to attend this week, and we could likely
pick this topic up at the next meeting. Randy noted that Zhiping had asked if
he should start writing up a BIRD based on any of his ideas. Randy and Arpad
agreed that it is too early to write a BIRD, and we are better off discussing
how to approach the subject. Arpad encouraged anyone with ideas on the topic to
start a discussion via email to the ATM list.
New Topic - Passing Pin/signal_name into an AMI model:
Randy raised a topic Michael Mirmak had first brought up during the BIRD204
(clock forwarding) discussions. For IBIS AMI simulations of DDR buses, we might
need a new Reserved parameter as a way of passing the signal_name or signal
identity to the model. For example, if the model is dealing with different DQ
to DQS delays for different DQs, this new parameter would allow the model maker
to avoid having a separate AMI model for each DQ pin.
Walter suggested a new Reserved parameter Signal_Name, which would be of Type
Input and Format String. It would be used to pass in the signal_name of the
[Pin] in the [Component]. The EDA tool would know the pin and component
information and pass it into the model. Arpad asked if DLL_ID could be used
for this purpose. Walter and Randy said no and thought DLL_ID's current usage
wouldn't align with overloading it in this way, though Randy noted the new
parameter would be defined similarly as a String Input. Arpad said he
understood DLL_ID's current purpose, and wondered if it would be useful here if
we need to uniquely track all 64 DQs in a simulation, for example. Randy and
Walter said the need for this new parameter is only to identity the DQ signals
on a given component (4-bit or 8-bit component, for example), not the overall
simulation. The goal here is to let one AMI model handle all the pins on a
given component.
Arpad asked if refdes information would be useful. Randy said the EDA tool
would handle things at that level. This new Reserved parameter would just be
used to specify which of the DQs within a given component. Randy said this was
envisioned for the individual DRAM level (4 bits or 8 bits). Fangyi said you'd
only need the refdes if you wanted to tell the difference between different
DRAMs, but if each DRAM was the same you wouldn't need that info.
Fangyi and Randy agreed the AMI model wouldn't need the refdes. Fangyi said the
AMI model would already know what type of signal it was handling, so perhaps we
only need an index to specify which one (e.g. 0,1,2,3 for a 4bit DRAM). Randy
agreed that you'd likely have separate models for DQs and DQSs, for example, so
the model would know what signal type it was handling. However, he wondered if
that would be the case for all technologies and said we still might want a
signal name. Curtis said if the parameter only took an index, we would still
have to specify the mapping so the user or EDA tool knew which index to use for
a given pin being simulated. Fangyi agreed. Fangyi asked if swizzling would
pose a problem, for example, if you tell the model you're signal DQ2, the model
may not be able to figure out which pin that is because of swizzling.
Walter summarized the fundamental problem: One has a component with a bunch of
DQ pins, one or more DQS pins, and some other pins (cntrl, etc.). We want a way
to tell the .dll it's working with this particular pin on this particular
component. We could either do it by pin name or signal name. You have to give
rules to the person writing the software. If we're using DQ3, pin 7, how do we
tell the model that? That's the problem to be solved. Randy agreed and said if
you give a unique identifier, probably signal name, that would be sufficient as
long as it's the signal_name given in the IBIS [Component]. That's what the
model should expect to be given. Walter said it could be pin name or signal
name, but the nice thing about signal name is that it's the same regardless of
how you number your pins. It's clear to the tool and the model.
Fangyi said the two are not always the same. He said in one design you might
use one pin on the component for DQ1, and in another design you might use that
same pin for DQ2 (swizzling). So signal name doesn't necessarily tell you the
pin. Randy said this was a good point, and you might have the same component
that can be a x4 or x8 or x16. In DDR4 and DDR5 we aren't really switching the
names around, but that could happen if you have mirror functions like you see
on graphics devices where a command address pin becomes a different command
address pin when it's mirrored. At some point you might need to give more
information such as the component name. Fangyi said if we used the pin name
we wouldn't have that problem, but Randy said you still want the component name
because pin 'a7' might not mean much without knowing the component. Fangyi
said if we're just worried about internal delay then the pin name should be
enough because the model is confined to the component. Randy agreed you could
create a .dll that's tied to a given component.
Walter suggested we could add another Reserved parameter to pass in the
[Component] name. A model that used it would be advertising that it needs the
component name as well as the signal name. Randy said that would probably do
it. Arpad wondered whether using the same die in different packages would need
special treatment, but perhaps having the component info would solve that too.
Randy agreed and said that even in mirrored cases they typically just made a
unique [Component] for each of the mirrored cases (mirror function pin 0 or 1)
because that setting changes all the signal names.
Arpad asked if stacked dies, multiple copies of the same die, would be a
problem. He said that would probably be wrapped in an EMD model. After
discussion, Randy and the group decided that higher level EBD, EMD, etc., issues
would not come into play. Fangyi said the dll represents what's going on inside
the die, so the model only needs to know the [Component] name and nothing higher
level. Randy agreed.
Fangyi asked if we wanted to use signal name or pin name. His concern was that
a pin can be used for one signal name in one case and another signal name in a
different case. Randy said in either case the EDA tool has to read in the
[Component] information and pass in the component name and pin/signal name. So
the tool is passing in information from the [Component]. The model maker could
deal with either. Walter said it's a bit more complicated, and signal name
would make life easier for the model maker. For example, if you have 5
components that all use the same chip, the pin names might be different, but
the model maker would want to just think in terms of DQ0, DQ1, DQ2, DQ3 inside
the model. Randy agreed that he finds signal name more convenient. Fangyi
confirmed that we are talking about the signal_names specified in the
[Component], and the naming convention is therefore created by the model maker.
Randy agreed.
Arpad asked if this was important enough and ready to be drafted into a BIRD.
Randy took an AR to start work on a BIRD and discuss it with Michael. Randy
said he would post the information to the ATM email list so everyone could be
involved.
cancel next meeting:
Walter noted that the agenda is somewhat sparse right now. He moved that we
cancel the next meeting. Curtis seconded. There were no objections. Arpad
cancelled the meeting scheduled for July 7th.
- Curtis: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
AR: Randy to draft some ideas for the component and signal name Reserved
parameters proposal and send them to the ATM list.
-------------
Next meeting: 14 July 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
