Minutes from the 18 January ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 18 January 2022
Members (asterisk for those attending):
Achronix Semiconductor: Hansel Dsilva
Amazon: John Yan
ANSYS: Curtis Clark
* Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Jared James
Google: Zhiping Yang
Intel: * Michael Mirmak
Kinger Cai
Alaeddin Aydiner
Keysight Technologies: * Fangyi Rao
* Majid Ahadi Dolatsara
Ming Yan
Radek Biernacki
* Rui Yang
Todd Bermensolo
Luminous Computing David Banas
Marvell Steve Parker
Mathworks (SiSoft): * Walter Katz
Mike LaBonte
Micron Technology: * Randy Wolff
* Justin Butterfield
Missouri S&T Chulsoon Hwang
Siemens EDA (Mentor): * Arpad Muranyi
Teraspeed Labs: * Bob Ross
Zuken USA: * Lance Wang
The meeting was led by Arpad Muranyi. Randy Wolff took the minutes.
--------------------------------------------------------------------------------
Opens:
- Michael got an update offline from Walter about AMI root name checking.
- Michael had a presentation to share on expanding Test Load and Test Data to
support IBIS-AMI.
-------------
Review of ARs:
-
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the January 11th
meeting. Michael moved to approve the minutes. Lance seconded the motion.
There were no objections.
-------------
New Discussion:
Agenda item #6: Alphanumeric [Pin] names BIRD draft 2:
Arpad reported the draft did not change from last week. Arpad noted Bob's AR
was to check the function_table_group checking in the IBIS parser. Bob
confirmed the parser does not check for alphanumeric characters only. Making
the change in the BIRD will not lead to breaking old models. Randy commented
he thought the BIRD looked good. Michael moved to submit the BIRD to the Open
Forum. Randy seconded the motion. There were no objections.
Arpad will submit the BIRD draft to the Open Forum [AR]
Agenda item #7: BIRD Requiring clock-forwarded AMI data Rx models to return
clock times
Bob asked if the parser needs to enforce the new requirement in some manner.
Arpad noted you would not be able to check for the desired behavior with the
parser without exercising the model and checking its output. So there would
be no change to the parser.
Arpad noted this would be a help for the EDA vendors. EDA tools would not
have to invent behavior that the model should be responsible for. Fangyi
asked about the sentence "All clocked receiver models (which are accompanied
by the reserved parameter Rx_Use_Clock_Input in their .ami parameter file)
must return valid clock times.". What does it mean? Arpad described that we
have SerDes models (traditional) and new clocked receiver models with a second
clock input. He was trying to define the requirement is only needed for the
new clocked models. Fangyi proposed shortening the sentence to "A receiver
model that specifies the Rx_Use_Clock_Input parameter must return valid clock
times." Arpad added this sentence to draft 4.
Walter moved to submit the BIRD to the Open Forum. Michael seconded the
motion. There were no objections.
Arpad will submit the BIRD draft to the Open Forum [AR]
Michael shared a presentation: [Test Load]/[Test Data] and AMI: Some Intial
Thoughts
[Test Load] defines the circuit, which is a simple circuit made of RLC
elements and a simple transmission line. [Test Data] waveform keywords tell
you what to expect at various points in the circuit and whether they are
rising or falling data.
You could relatively easily enhance [Test Data] to support IBIS-AMI. This
would allow model-makers to convey the exact setup that works for them. This
would save debug time. It would require more intensive AMI support by IBISCHK
than exists today. There isn't an active simulation done by existing IBISCHK.
Michael showed a pseudo-format for an AMI [Test Data] keyword.
If we decide this is useful there are a lot of choices to make. There isn't
much to change to support Tx models. For the Rx, we'd need to support a
waveform location inside the buffer. Do we need to define success criteria
beyond the waveforms? Supporting crosstalk might be a future discussion.
Would we limit this to AMI_Init? Would we need to condiser updating [Test
Load] to support IBIS_ISS and Touchstone interconnects?
Arpad commented on the success criteria. We can check that clock times is
monotonically increasing.
Walter noted we are only checking the DLL. All you need for the AMI test data
is to point to 2 files. One is the input to the AMI_Init function. The
second is a file of results of the target, what the DLL should produce. They
should be identical. We need to define a format of the contents of the input
file. There is a CSV file format for testing that exists already and could be
looked at.
Michael noted he agreed there are only 2 files necessary. Walter noted the
DLL doesn't care about near/far designations as currently described in [Test
Data].
Ambrish asked what the point of [Test Data] for AMI is. Is it to validate EDA
tools or validate the model? Michael noted it is to verify the model is
working as the model maker delivers it but also to deliver additional
information that is not part of the AMI defulats but is part of documentation
that could not be automatically read. This also resolves the root name issue,
which helps with debug. It shows a known good setup condition of the model.
Arpad agreed it does confirm a known good operation of the model. Ambrish
asked if the CSV input file format is something we would add. Michael noted
you'd have to supply the impulse matrix and the output matrix. The question
is how to structure the data.
Fangyi asked what is the next step for determining the output of the model
really does match what is supplied. What are the rising and falling waveform
data doing? Arpad noted it would be beneficial to test the analog portion of
the model, not just a DLL checker. Walter confirmed there would be one set of
[Test Data] to test the analog portion and a separate set of [Test Data] to
test the AMI portion. Michael is open to separate eveluations with different
sets of data. Bob agreed we should separate the AMI testing from the analog
testing. Fangyi noted it is difficult to understand what near and far mean in
the context of AMI. Wei-hsieng asked about models that do no processing in
AMI_Init. Michael noted that supporting AMI_GetWave would require additional
thought and discussion. Wei-hsieng noted Ignore_bits adds complexity to
supporting AMI_GetWave.
Fangyi asked what could go wrong. What are we testing here? Walter commented
it is a due diligence check that the parser could provide for model testing.
Walter noted there may be difference in OS and rounding that makes the output
file and the DLL output slightly different. Michael commented this gives the
model developer a way to document a known good configuration of the model.
Michael noted a Tx model is intended to point to a [Model] name. All the
information will be there to say that the model with a certain setup works.
Fangyi noted this could help model users to catch environment specific
behaviors.
Bob noted IBIS doesn't suport .csv format currently.
Michael to send out his presentation to the ATM reflector [AR].
Walter asked Fangyi to review Walter's draft of BIRD211.4 [AR].
- Michael: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
AR: Arpad to submit the Alphanumeric Pins BIRD draft to the Open Forum
AR: Arpad to submit the Clocked Rx AMI Models BIRD draft to the Open Forum
AR: Michael to send out his presentation to the ATM reflector
AR: Fangyi to review Walter's draft of BIRD211.4
-------------
Next meeting: 25 January 2022 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
