Minutes from the 12 February ibis-atm meeting are attached
IBIS Macromodel Task Group
Meeting date: 12 February 2019
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
Maziar Farahmand
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
* 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:
- Randy to investigate if/why/how a clock waveform input might be used.
- In progress. Justin noted that this is worth exploring based on some of the
DesignCon IBIS Summit presentations.
- Michael M. to investigate if/why/how a clock waveform input might be used.
- In progress.
- Michael M. to check with IP experts on whether DC_Offset is useful for Tx.
- In progress.
- Randy to submit BIRD197.2 to the Open Forum.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the January 15
meeting. Mike L. moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
No one had anything new to discuss for the current agenda topics.
IBIS-AMI Post Simulation Processing (FEC): (from the Topic bin list)
Mike L. raised this topic. He asked how people feel about the idea that an AMI
model, in addition to providing services for simulation, could also have a
function that takes simulation results and settings and generates some final
post-processed output (e.g., html report). He noted that one controversial
aspect of the proposal was that the model might be doing something that is
normally in the domain of the EDA too. For instance, the model maker might
include compliance reporting for a particular version of a standard that the
model supports.
Walter rephrased the proposal as: Could we add some function to the .dll that
is called just before AMI_Close(), and it would handle this special reporting?
Mike L. agreed that was an accurate representation of the question/proposal.
Walter noted that the AMI_Close() function itself is passed the memory handle
and conceivably knows everything about the simulation. So, the model maker
could simply have AMI_Close() generate any special reporting. That is, without
any change to the IBIS spec, the model maker is already free to put anything
they want into AMI_Close(). Mike agreed this was true, but suggested we might
at least add a Reserved parameter to tell the user this extra reporting was
provided. Walter felt this was unnecessary, as we already have DLL_ID that
provides a unique name to every instance, and the model maker could add a Model
Specific "generate_report" parameter if they wanted to.
Arpad noted that each time this topic came up in the past the answer was always,
"No, we don't need to do anything in the spec." However, the topic keeps being
raised. Arpad said maybe the broader discussion topic is whether IBIS is just
a modeling spec or whether it also does more things like post processing and
compliance evaluation. Walter noted that in practice many IBIS parameters that
were intended for use modeling the way the silicon actually works are just
filled in with values for spec compliance. For example, Vinl and Vinh should be
a way to specify when your device transitions, but in practice the values
provided by model makers in Vinl and Vinh are often from a particular standard's
compliance data. Values are often injected into models because of compliance
rules.
Arpad asked if we could continue to stay silent on this topic. Mike said that
in theory the model maker could already do everything in AMI_Close(). He noted
that he felt this topic could be removed from this list if it had not gained any
traction at this point. Bob said he was neutral on whether to remove the topic,
but he noted that it originated based on some FEC proposals by ZTE and Huawei.
Mike recalled that 4 summit presentations had been given (several years ago),
and two had specifically suggested that IBIS should do something about FEC.
Walter had noted at that time that FEC was at a different layer than IBIS is
typically used to model. Arpad said we might need to reach out to the authors
for more specific proposals, or at least a high-level block diagram of what they
had in mind. Mike L. took the AR to reach out to various summit presentation
authors to see if they could provide more input.
Power-Aware vs. AMI models: (Topic bin list)
Mike L. noted that Ted Mido had presented his paper on his approach 3 times now.
He asked if it would be up to Ted to partner with someone and write a BIRD.
Arpad asked if everything Ted had presented could be handled without any changes
to the spec (no new flows, no new parameters, etc.) Walter and Ambrish noted
that they weren't sure how someone would do power-aware AMI when AMI assumes you
have one IR computed at the beginning of the simulation. Walter noted that
nothing could be done in AMI_Init(). Perhaps in the time domain GetWave() flow
the tool could use sinusoidal power scaling or something else when it prepares
the input waveform for the Rx GetWave(). This might not be a spec change, but
it would be a flow change since the tool is doing something other than merely
convolving the IR with the stimulus. Arpad noted that Ted's approach was
different, and he was converting power fluctuations of the analog buffer model
into a jitter distribution type value. To account for that additional jitter
introduced by the power fluctuations, would we need to add any new parameters?
Walter noted that a power-aware model could change the amplitude of the waveform
but could also include a spectral density of the jitter. Perhaps we would need
a new parameter (e.g. Tx_spectral_table or Rx_spectral_table) to point to a file
containing the spectral density information. He noted that this sort of
spectral density information probably couldn't be folded into one of the
existing
single-valued jitter params. Arpad asked if anyone wanted to start such a BIRD.
Walter said that he didn't think we should unless/until someone came to us with
a request. Mike noted that what Ted had presented was largely a flow. We would
probably need to understand more fully exactly what flow he had used and whether
IBIS could add something to help.
- Mike L.: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
AR: Mike L. to reach out to FEC presentation authors for more information.
-------------
Next meeting: 19 February 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
