Minutes from the 07 April ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 07 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
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Fangyi to send his "Clock Forwarding BIRD Discussion" presentation to the
ATM list.
- Done.
- Arpad to email Steve Parker asking him to post Fangyi's presentation to the
ATM work archives.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the March 31
meeting. Michael moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
DDR Clock Forwarding:
Arpad noted that Walter had prepared a presentation on an alternate BIRD. He
asked if Michael or Ambrish had feedback to share first. Ambrish said his group
had been working on a counter proposal of their own and would need another week
to draft it. Michael said he preferred to wait until after Walter's
presentation, so any of his remaining questions could be stated in the context
of Walter and Fangyi's proposals.
Walter shared his "BIRD_DQ_DQS_Clocking" presentation.
slide 2: Overview
- Introduce a new BIRD that overloads the existing clock_times argument in
GetWave so that it can be used as an input as well as an output.
- As an input it can be:
- Ignored (current behavior)
- Can contain the DQS clock_times output
- Can contain the DQS waveform output
- One new AMI Reserved Parameter specifies how it is used as an input.
slide 3: Background
- For DDR5 (and clock forwarding applications in general) the skew between DQ
(data) and DQS (clock) has two components:
- The N*UI skew (e.g., from a DQS clock tree)
- The fine skew to get the DQS clock at the center of the DQ eye.
- It would be nice to have a DDR5 DQ Rx model that has both the DQ waveform and
either a DQS clock ticks or DQS waveform, so the clock can be correctly
located in each UI of the DQ waveform.
- There are multiple clock forwarding interfaces, for example MIPI at 10G, and
as you go to higher and higher speeds there's an increased need to model the
interaction between the clock and data waveforms. At the lower speeds of
DDR5, right now 4G to 6G, this might not be quite as important yet. The PI
issues might not be that important for DDR5 yet, and some would argue that
DQS clock ticks are sufficient for that. However, if we are going to enable
clock forwarded applications, we should be able to handle higher speed system
modeling that may require DQS and DQ waveforms.
slide 4: Alternative BIRD
- The clock_times argument passed to the DQ GetWave:
- Content of clock_times as an input to the model is ignored (IBIS 7.0).
- Content of clock_times contains the clock_times output of DQS GetWave.
- Content of clock_times contains the waveform output of DQS GetWave.
Stephen asked if this proposal was broadening the definition of clock_times in
that it could contain clock ticks on input or the full DQS waveform. Walter
agreed that it was. Walter noted that IBIS 7.0 behavior is that clock_times
is only used as an output, so its contents on input to the model are ignored by
the model.
slide 5: New AMI Reserved Parameter Rx_Use_Clock_Input
- Usage type In
- Tells the model what to expect in the clock_times argument.
- List Type includes values "None", "Times", "Wave"
- "None" - legacy IBIS 7.0 behavior
- "Times" - clock ticks from DQS will be in clock_times as an input
- "Wave" - waveform from DQS will be in clock_times as an input
Walter noted other possibilities included the models only supporting "None" and
"Times" or only supporting "None" and "Wave". He had not included the option
for the model to only support "Wave" and or "Times". That is, he had not
allowed
for the model to not support "None" and therefore not support legacy IBIS 7.0
operation. However, he was willing to discuss any combination of options people
thought we should allow.
Arpad confirmed that the entire DQS waveform might be passed in using the same
clock_times argument, in the case of "Wave". Walter agreed. Wei-hsing asked
about the lengths of the arrays, since clock ticks and the full waveform would
have different lengths. Walter said the spec defines the size of the array in
those two cases, and tools would have to get it right.
Michael asked for confirmation that only those three choices ("None", "Times",
"Wave") were valid, and that "None" was the default. Walter said those were the
only choices, but that the model maker could specify whichever they wanted as
the default. Walter said that if the parameter is not provided in the model,
then the default behavior is IBIS 7.0 behavior, i.e., "None".
slide 6: Block Diagram from Fangyi's GetWave2 proposal
The slide shows that a GetWave model using clock_times as an input containing
the DQS waveform is a drop-in replacement for a GetWave2 model. In addition,
clock_times could be used to input clock ticks instead.
slide 7: Advantages
- No loss of functionality relative to the GetWave2 proposal
- No new function signature AMI_GetWave2
- Models work in the existing IBIS 7.0 flow for tools that don't support this
BIRD
- DQS simulations not required in order to simulate DQ data path
Bird Draft itself:
The BIRD draft defines the new Rx_Use_Clock_Input parameter. Walter noted that
he had included language stating that if the DQ Rx model contained this new
parameter, then the corresponding DQS model must have GetWave_Exists true. He
said we might not want to keep that restriction. He said he had drafted it that
way initially in part because it was easier write that restriction than to
explain the alternatives. Ambrish said he thought that restrictive language
should be removed because the EDA tool is capable of providing the inputs
to the DQ model, so the DQS GetWave isn't required. Michael said this had been
one of their questions as well, did this proposal or the GetWave2 proposal
include the assumption that DQS has a GetWave? Fangyi said that in the original
GetWave2 proposal he had assumed the DQS model contained a .dll and GetWave.
However, if it didn't, then he assumed the tool would provide a DQS pass-through
.dll to provide the necessary inputs to the DQ model. Walter drafted some new
language in the Other Notes: section to state that the EDA tool should
effectively insert a pass-through Clock GetWave function if one does not exist.
Walter noted that he was careful to use Data and Clock, as opposed to DQ and
DQS, in the BIRD draft to keep it generic to any clock forwarding applications.
Michael asked how a DQ Rx model would know what its corresponding DQS Rx model
contained, or even what its corresponding DQS model was. Walter said this could
be a tricky question. He said for memory side model makers its straightforward.
Controllers, on the other hand, can have multiple DQS outputs and you have to
know which DQS goes with DQs for writes. He said his tool stored this
information in a timing model, so the tool knows what DQS belongs to what DQs.
Michael noted that Walter had said the tool had the timing model. He said this
was a case where the model maker can't provide that information, that is, a
memory vendor's model can't know a priori the DQS associated with a particular
DQ. He asked if this came down to the user defining the topology. Walter
agreed that it did, and said the tool customers know the relationships and go
the data book for their particular controller. They then make the correct
associations in the tool, and the tool stores the information in a timing model.
Walter noted that IBIS doesn't support the concept of a timing model. Arpad
said it's not a question of IBIS not supporting something, it's really a
simulation set-up issue for the user or tool. Walter agreed, and noted that
in slide 6, the block diagram from the GetWave2 proposal, we have to know that
DQS0 goes with DQ0 through DQ7 and DQS1 goes with DQ8 through DQ15.
Fangyi asked if we need the "None" value for the new parameter at all, as this
is just the legacy behavior. Ambrish agreed, he said if the parameter isn't
there it's assumed "None" (legacy behavior). He asked if all models were
required to support "None" and said that it's not as trivial as it sounds, since
the model will be providing a CDR in that case. Walter said, yes, the model
still needs to support "None" in case it is called upon to do a DQ simulation
without a DQS path. Ambrish said a model supporting "None" is essentially
saying that it doesn't need all this new stuff, and it can compute accurate
enough results using its internal CDR. Arpad said that for brainstorming or
prototyping it would be much easier if the parameter supported all three options
than it would be if you had to remove the parameter altogether to get the "None"
behavior.
Walter noted some thoughts for memory vendors. He said for controllers, on
reads, it has the phase interpolator (PI) and knows how to adjust the fine skew
to center the DQS clock in the DQ UI. However, for writes, we need to know the
N*UI skew, and advanced models that want to know all the subtle effects in fine
skew will want the DQS waveform too. A memory model maker might want to
consider having their DQ Rx model contain an internal CDR that can shift the
"recovered clock" on its own to get it aligned with the data. That would miss
some of the subtle DQ to DQS effects, but it could report back a single value to
indicate the skew. Then that value could be used by the EDA tool in a second
simulation that can take this effect into account. He said this was just an
idea for a possible flow.
Fangyi confirmed that the output of the clock_times argument would be unchanged
by this proposal. Walter agreed.
Arpad asked Fangyi if he thought Walter's approach would work and would cover
all the issues Fangyi had outlined in his presentation. Fangyi said that he
thought it would, and he thought Walter's proposal was a combination of the
clock ticks only and GetWave2 approaches. Fangyi said he would have to review
it in detail and discuss it with others to be sure. Arpad said he would too,
and he said he liked the idea of Walter's proposal.
Radek asked if the new BIRD discussed the issue of allocating the memory for
clock_times. Walter said the EDA tool has always been responsible for the
allocation, and it will have to be smart enough to allocate the right amount
depending on the setting of Rx_Use_Clock_Input. Arpad agreed with Radek that we
have to carefully review the existing language to make sure it covers this
extension.
Arpad asked Walter to send the presentation and updated BIRD draft to the ATM
list. Walter agreed. Arpad said he would send Steve Parker an email asking him
to post them to the ATM work archives.
- Ambrish: Motion to adjourn.
- Michael: Second.
- Arpad: Thank you all for joining.
AR: Walter to send his "BIRD_DQ_DQS_Clocking" presentation and BIRD draft to the
ATM list.
AR: Arpad to ask Steve Parker to post Walter's documents to the ATM work
archives.
-------------
Next meeting: 14 April 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
