Minutes from the 14 April ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 14 April 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
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. Justin Butterfield took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Walter to send his "BIRD_DQ_DQS_Clocking" presentation and BIRD draft to the
ATM list.
- Arpad reported this was done.
- Arpad to ask Steve Parker to post Walter's documents to the ATM work
archives.
- Arpad is still waiting on this.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the April 7
meeting. Randy moved to approve the minutes. Ambrish seconded the motion.
There were no objections.
-------------
New Discussion:
DDR Clock Forwarding:
Fangyi shared his comments on the DDR Clock Forwarding BIRD draft that he sent
over email. He asked if we really need the Times input mode. Ambrish replied
we need the Times input types. If the EDA tool can provide the clock_times,
this can reduce the burden on the model maker. He noted this can be a simpler
approach, and the model maker can decide the input type of clock_times. Arpad
noted this parameter tells what is stored in the memory location for
clock_times. Ambrish commented the models he has would be sufficient to use
the Times type. Fangyi noted the DQS model might have its own way of
computing the Times information.
Regarding the requirement to have None in the list, Fangyi commented this
would require every model to support having its own CDR. Walter stated we can
let the market decide how this should be done. He suggested it would be a
good practice for model makers to support the None option with no explicit
clock_times input. Ambrish asked if this would require the EDA tool to
support the external clock_times.
Arpad asked if this parameter is an input to model. Walter replied, yes, the
Rx_Use_Clock_Input parameter tells the model which mode you are in. Fangyi
commented it is both telling the EDA tool what to do and an input to the
model. Walter commented we have other Reserved Parameters that are similar
concepts. Arpad asked, since the EDA tool will ask the user to pick one of
these options, is this a question for the model and not the user. Fangyi
replied the user may or may not care about the jitter tracking. Ambrish
asked, if the model can determine from the data, what type of input it has.
Fangyi replied the model needs to know how to interpret the clock_times
pointer. Arpad asked if this is a parameter for the DQ or the DQS model.
Fangyi replied it is for the DQ.
Randy asked if the Other Notes applies to Times and Wave. Fangyi agreed we
should clarify the last sentence. Ambrish commented the EDA tool will process
the DQS waveform regardless of the DLL. The concern is if the DLL is not
there the EDA tool can handle this.
Randy commented, regarding the None option, he plans to continue to have a CDR
in the model to support the case where a user wants to run a simple
simulation. Fangyi asked if all models should support the None option. Randy
agreed it might not be required. We could remove the requirement and let the
market decide, as Walter previously stated.
Bob asked if omitting the parameter is the same as None. Radek stated the
parameter allows the user to select the option mode they want to simulate.
Randy suggested the parameter can be omitted if it is not supported. Ambrish
commented, to be able to use this model in EDA tools supporting only older
versions of IBIS, None will be required for the model. Randy agreed, if you
have a model that supports None, it can work in older tools.
Bob asked if we are supporting both Usage In and Usage Info. Arpad replied we
are effectively doing both, but for other similar parameters we have them as
Usage In. Fangyi stated any parameter that is listed is also Info. Arpad
noted the parameter Modulation is "Usage In, Info". He suggested to make this
parameter Usage In and make a statement that the EDA tool will use the
parameter. Ambrish suggested it should be "Usage In and Info" and to clarify
this in the text. Bob noted the syntax does not support "Usage In and Info".
Arpad agreed and suggested in the rules we can say the tool will use the
parameter. Fangyi agreed and made the parameter Usage In and added a sentence
about this in the Usage Rules section.
Arpad shared the DLL_Path parameter from IBIS 7.0, which is Usage In. It has
text stating what the EDA tool is responsible for. Fangyi agreed this is more
clear.
Radek asked if any combination of the None, Times, and Wave parameter values
makes sense. He suggested only having None would not make much sense. Randy
asked if Value should be listed as a valid Format. Arpad agreed Value would
make sense as a Format. He commented we need to decide if we are requiring
the None option to be present to answer Radek's question. Randy asked if the
List can accept one value. Bob noted we have defined strings for the
parameter options in the past. Arpad commented, for List, we do not have any
requirement in the IBIS specification that it has more than one value, but he
was not sure about the parser. Fangyi changed the Format to "List, Value".
Fangyi noted he fixed a few typos. He also changed the phrase "Rx DQ" to "DQ
Rx". Fangyi asked if we are passing the contents or the pointer. Arpad asked
if it will waste memory to copy the contents. Ambrish agreed we want to pass
the pointer. Fangyi asked about the definition of the issue where it mentions
the x4 and x8 DQ cases. Randy stated these cases would be possible. Arpad
asked if we should change "DLL" to "executable model". Fangyi made this change.
Michael asked if there is a requirement for the DQS to have an executable
model. Fangyi asked if it was clear from the Other Notes text. Michael noted
it is a question of abstraction, where the analog model data would be
supported by model or by the EDA tool. It is not clear if the DQS AMI model
is required. Michael asked if this is something we should clarify. Fangyi
replied this is outside the scope of this BIRD. Walter stated if the DQS DLL
is required the model the maker should provide one. If the DQS model is
supplied, then it should be used by the EDA tool. Arpad suggested we should
add a sentence about this to the BIRD.
- Ambrish: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.
AR: Fangyi to send out the updated version of the BIRD_DQ_DQS_Clocking.
AR: Arpad to ask Steve Parker to post Fangyi's document to the ATM work
archives.
-------------
Next meeting: 21 April 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
