Minutes from the 24 July ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 24 July 2018
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
* Ming Yan
* Stephen Slater
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
SPISim: * Wei-hsing Huang
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the July 10
meeting. Walter moved to approve the minutes. Randy seconded the motion.
There were no objections. (minutes for this meeting had not been prepared in
time for the July 17 meeting)
Arpad asked for any comments or corrections to the minutes of the July 17
meeting. Walter moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
Upgrading the input thresholds/measurement info to include eye diagram specs:
Arpad noted that Walter's email to the ATM group ("New Keyword [Standard]", sent
just prior to the meeting) described what Arpad had proposed. A new keyword and
possibly Subparam(s) under the [Model] keyword would provide a "pointer" to an
external specification. Arpad noted that he had suggested this approach because
IBIS specification releases tended to lag behind the leading edge. Pointing to
a particular standard would be faster, and we wouldn't get bogged down in
discussions about finding the best syntax for the parameters we had to define in
IBIS.
For review, Radek noted that Walter's original proposal had described
"include" files, which did define/contain the parameters that were needed to
support a particular standard. Walter agreed, and noted that Ambrish and others
had objected to his original proposal. Walter confirmed that he supported
Arpad's "pointer" approach. Walter noted that in practice his implementation
might still rely on his "include" files. However, we could keep it simple in
the IBIS standard and simply refer to an external specification.
Walter summarized the applications for this proposal and the discussions thus
far:
1. Original application stemmed from the fact that there are a bunch of
different thresholds that apply to DDR4 that don't exist in IBIS.
a. Walter's original approach was to define a new list of IBIS parameters
to address these issues (e.g. VdiVW, etc.).
b. The current alternative is that we have a "pointer" to a standard (e.g.
JEDEC DDR4), and state that a particular model is the DQ, CLK, etc. The
EDA tool can then choose what to do. It can choose to ignore existing
IBIS [Model] params (e.g. Vinl, Vinh) if the outside standard should
provide the info.
2. As a second application, if a buffer [Model] works for DDR3 and DDR4, then
we have a way to specify the different standards that could be used during a
given simulation. The EDA tool can do whatever it wants to implement a
simulation for a given standard.
Fangyi asked if the [Standard] parameter would have any impact on the way the
[Model] itself behaves. Arpad and Walter said no. It merely allows the model
maker to specify which standards a [Model] may support in simulation, and it
also might influence how any post processing would be done. Walter noted that
he strongly recommended that we allow multiple instances of [Standard] in the
same [Model].
Stephen asked the model makers to comment on whether they thought this proposal
would be helpful to their users. Randy noted that it would make it more clear
to the user exactly what standard a [Model] could support for simulation. Randy
noted that there are a lot of standards, so there might be some effort in coming
up with the list of supported standards. Michael M. agreed and noted that the
proposal was important for convenience. He noted that the user typically needs
some sort of documentation that accompanies the model, but it is difficult to
ensure this process goes smoothly. Instead, if you can explicitly state the
context for which the model and its evaluation are designed, you can avoid
confusion about whether a particular model or set of loads is compliant with a
given standard.
Michael M. noted that we may still have a big gap between merely pointing to an
external specification and including additional information we may need within
IBIS to make this useful. For example, we might point to a general USB3.0
standard but still need to define how something should be interpreted for IBIS
simulations. Arpad agreed and noted that we might need a mechanism to point to
a particular subsection of a given standard (e.g. different speed grades, or
different clock or data signaling types, etc.).
Bob noted that we would have to have some process to register the approved
standard names that IBIS would support at any particular time. Walter noted one
interesting pitfall to avoid. He said that IEEE 802.3 had at one point been
too specific in referencing something external, and this caused a version to
become obsolete prematurely because it referred to something else that became
obsolete. Walter said we might not want to get too specific about which version
of some standard was supported. Walter thought the name proposed as an example
in his email was sufficient (JESD79-4, DQ model). Bob disagreed and said if we
didn't describe the particular version precisely then one EDA vendor might
support the very latest version while another did not. Arpad said we could
address such specifics later. Walter noted that the process to register
approved standard names should not require a BIRD and the accompanying delay of
waiting for the next release of the IBIS standard.
Arpad noted that the Vinl, Vinh parameters reminded him of the fact that IBIS
has many required parameters that might be meaningless in certain contexts. For
example, recent discussions about the need to provide a meaningless Value in the
.ami file for a parameter of Usage Out were similar. Walter said that Vinl and
Vinh, for example, should probably remain required. He said this was because
the parser wouldn't know whether they were meaningless in certain contexts. For
example, Vinl and Vinh might be meaningless (overridden by the external spec.)
for DQ, but be required for CLK. Arpad noted that he was hesitant to have even
more mandatory but potentially meaningless parameters. He noted that he was
simply introducing the topic so we could consider it later.
Bob asked if any subsection specifier (e.g. the DQ in Walter's "JESD79-4 DQ"
example) would be defined in the IBIS file or in the external spec. Walter said
it would be a name defined in the external spec. For example, DDR4 has rules
for DQ, DQS, CK, etc. Bob asked if these were sections in the spec. Walter
said yes and noted that each section has specific rules. Bob noted that whether
certain legacy [Model] parameters were meaningful might depend on the section.
Walter asked that everyone think about this topic and be prepared for a vote at
the next meeting as to whether we should proceed with this proposal.
Single-ended applications for AMI:
Arpad noted the topic had been discussed at the previous meeting.
One issue was clock forwarding, and Arpad noted that there was consensus that we
would need a clock input for the Rx GetWave, and that this would require a BIRD.
The floating Vref in the case of DDR4/5 was also an issue, since the IBIS spec.
currently contains a fixed reference voltage for the receiver thresholds.
The issue of asymmetric rising/falling edge rates had also been discussed, and
Arpad noted that comments at the previous meeting suggested that there was no
need to enhance the specification to address this issue. It had been suggested
that the EDA tools could account for this without the need for changes to the
AMI models (or the model interface) themselves. Walter agreed and noted that
he and Ambrish had agreed that rise/fall issues could be handled by the EDA tool
without any change to the AMI specification.
Fangyi noted that he disagreed. He said that if your Tx has a GetWave()
the asymmetric rise/fall will throw the whole AMI algorithm off. You need two
IRs, but the current AMI standard says the output of the Tx is convolved with
"the" IR of the channel to produce the input to the Rx. Fangyi said we first
have to agree that the current flow has a problem. Walter acknowledged that the
current flows defined in the spec. have problems. But he noted that they were
reference flows for differential SERDES. Walter said the spec. had to define
the inputs to the model, but that the reference flows were merely informative
and not part of the spec. Walter noted that preparing the proper inputs to be
passed to the GetWave() functions was the challenge, but it could be handled by
the EDA tool.
Arpad asked about interoperability. Walter said interoperability was provided
by the AMI model's .dll, but that tools can implement different flows to
utilize the .dll. Ambrish agreed. Fangyi disagreed and said that the standard
defines the processing of the signal, and that processing is broken for channels
with rise/fall asymmetry. Arpad also suggested the spec. should define the
flow. If not, could we guarantee consistent results if two EDA vendors
implemented different flows? Fangyi said we couldn't. Fangyi said you could
not simply say, "My EDA tool has some secret sauce" that converts the output of
Tx GetWave() to the output of the channel (input to Rx GetWave()). We need to
define the mathematical relationship between the Tx output and the channel
output.
Walter agreed the EDA vendor has to document what it does. Fangyi asked why
we would need the spec then. Walter suggested that if EDA vendors documented
their approaches, then we might even end up picking a favorite approach. Walter
noted that he thought Fangyi agreed with him and Ambrish in the sense that it
was the flow that was broken, not necessarily the AMI modeling API. Fangyi said
we have to mathematically define how the Tx GetWave() output is related to the
channel output, otherwise there is no standard. Walter agreed, and said he
would be happy to draft that document. However, he noted that if Ambrish, or
Fangyi, or someone else didn't agree with his flow then it wouldn't pass.
Walter said he was concerned that others wanted him to describe the way he had
solved the problem, but no one else was volunteering to describe how they had.
Stephen noted that everyone agrees the clock is ticking on these issues. We
need to define an ecosystem and modeling approach that work for everyone. He
noted that Keysight would start to document items they might want to see in a
BIRD. Arpad said this was a good start, and he noted that in the meantime we
could also make progress on the low-hanging-fruit for which there was already
consensus.
- Mike L.: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 31 July 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
