[ibis-macro] Minutes from the 21 April ibis-atm meeting

  • From: Curtis Clark <Curtis.Clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 28 Apr 2020 04:29:43 +0000

Minutes from the 21 April ibis-atm meeting are attached.
IBIS Macromodel Task Group

Meeting date: 21 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.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Fangyi to send out the updated version of the BIRD_DQ_DQS_Clocking (draft 2)
  to the ATM list.
  - Done.

- Arpad to email Steve Parker asking him to post Fangyi's document 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 April 14
meeting.  Curtis moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

Agenda Cleanup:
Arpad asked if item #9 (BIRD201 discussion) could be removed.  Walter said it
could, since BIRD201 had been submitted to the Open Forum and a vote was already
scheduled for the upcoming Open Forum meeting.

Arpad asked if item #7 (DDR clock forwarding BIRD draft) could be removed, 
since 
Fangyi's and Walter's proposals had merged and could be handled by item #6.
Fangyi agreed.

Gap in IBIS for sampling with statistical mode AMI Models:
Walter said that he had spoken with Hansel that morning and thought he would
attend the meeting.  Discussion was deferred until Hansel could attend.

DDR clock forwarding BIRD draft:
Fangyi shared the BIRD_DQ_DQS_Clocking_Draft_2 he had sent out after last week's
meeting.  Fangyi noted some cleanup modifications to the Definition of the
Issue section, particularly the two scenario examples.  Arpad asked about the
examples using DQ and DQS instead of the generic Clock and Data terminology.
Walter, Fangyi and Michael noted that the BIRD text itself uses the more general
Clock and Data terminology, and this is mentioned in the last sentence of the
section.  The illustrative example scenarios in the section are based on DDR5.

Fangyi noted that he had replaced "DLL" with "executable model".  In scenario
2, the path delay from the DQS pad to the DQ latch is different for each DQ
latch.  Fangyi noted that the example of a possible solution uses one DQS model
with a common path delay experienced by all DQs.  Each bit could then have its
own DQ model that would accommodate the different additional DQS path delay for
that bit.

Michael said that the first part of the possible solution, a common DQS model,
implied one model and one instance of that model.  However, the second part,
with different DQ models for each bit, implied unique DQ models not just
multiple instances of the same DQ model.  Radek said each DQ could have a
separate instance of the same model.  Michael said that the proposed solution
required separate models if different DQ delays were handled by each.  Randy
said this is where it can get messy if you intend to use different .ami files
for each DQ, as you would have to wrap each in a separate [Model] for each DQ.

Walter said that given one DQ and one DQS it all depends on the number of clock
trees between the DQS and the DQ latch.  There are many types of configurations
for this.  The basic executable model functionality would be the same.  The only
difference is the depth of the clock tree.  One could have a single executable
model for the DQ and another for the DQS, and an AMI parameter in the DQ or DQS
model could be used to specify the depth of the clock tree.  This would be a
different approach that wouldn't require a separate model for each depth level
of a clock tree.

Fangyi agreed that there were many ways to implement a model.  For this section,
which is just an introduction to the BIRD, we should simply list a few possible
solutions and indicate that the process is flexible.  One simple approach is
for each DQ to have its own [Model].  Another approach would be for the DQs to
share a common executable model but use different delay parameter values. 

Michael suggested that the simple example should start from a Pin list point of
view.  He said the example would need to address the issues in scenario #2.  He
noted that there's an implicit connectivity in this flow, and we might want a
figure to illustrate what the path/tree looks like.  The model maker's
perspective on the connectivity might not quite be the same as what the data
flow would look like in the simulation.  Fangyi said the connectivity could be
addressed via a "DQ_Index" parameter that specified which DQ was being
simulated.

Michael said an example would be a good way for us to formulate a structure.  He
said there are currently gaps in defining the implementation of this multiple-
model flow and structure.  The system flow for this has to integrate multiple
buffers (clock and data), and we haven't had to do that before.  We may want to
create a topic wish list of things we need to define to make this work.  We may
need a new parameter in AMI to support this.  There may be quality assurance
aspects to correctly modeling this that IBIS should not and cannot touch upon.
Michael said he might be able to present a few slides on this topic at a future
meeting.  Randy agreed that this BIRD doesn't have to address all of these
issues, but we have to think about them.

Walter noted that his tool utilized a timing model that captured the set up and
hold relationship between a given DQS and DQ.  For memory this is pretty simple,
since there's typically only one DQS per chip.  On the controller, it can be a
real mess.  You might have 64 DQSs and 4*64 DQs that go with them.  We need to
know the relationship of each DQ with its DQS.  Walter asked if Michael's point
was that we need to understand that relationship.  Michael said that we needed
that as a minimum.  Michael said the end user has no way of knowing a priori
what that relationship is.  The model maker does know this, but we need a way
to convey it to the user or EDA tool.  Walter said you'd have a model maker for
the DQ and the DQS, and then the IBIS file would provide the connectivity (it's
not in the executable model).  However, this is a component level relationship
that IBIS doesn't currently convey.  Michael said that might be the first
thing we need to add after this BIRD.  Fangyi said this BIRD was dealing with
the buffer level models.

Walter proposed an example of 2 different chips that would use the same DQ and
DQS .dlls.  One chip has a two-level clock tree and one has a four-level clock
tree.  He said the models could use the same .dll, but the DQS model on the two-
level clock tree part might have a Model_Specific In parameter called
"tree_level" that is set to 2.  The model for the four-level tree part might
have the same parameter set to 4.  Randy said this was a reasonable scenario,
but the next step would be to define how the proper value of that parameter is
passed in.  Randy said the process would break down if you want to pass in a
a value that's unique to each DQ while sharing a single executable model.
Walter said each DQ could point to a different IBIS [Model], and each of them
would use the same .dll but a different .ami file (with a different value for
the parameter).  Randy said that is possible, but it leads to an explosion in
the number of Models and Model Selectors.

Randy said the analog portions of the model (on-die termination, etc.), would
likely be the same for all DQs, but we'd need some sort of "DQ_index" type AMI
parameter that's tied to the DQ index.  Walter proposed a possible solution that
could involve a new BIRD.  He suggested we might add a new Reserved parameter
used to pass in the pin name or pin number or signal_name from the IBIS file.
The EDA tool could pass it in, and the model could use it to tell whether it's
dealing with DQ1, DQ2, etc.  Fangyi agreed.

The group then discussed changes that were more editorial in nature.  Bob and
Randy noted that the allowable values of Rx_Use_Clock_Input ("None", "Times",
and "Waves") should be enumerated in the Usage Rules section and not as part of
the Format.  Radek suggested we refer to the "content" of the clock_times
input not the "data type".  Arpad said describing the contents as "empty" (in
the case of "None") might be confusing.  Fangyi suggested we state that the
contents are "ignored" in this case.  Ambrish asked if "ignored" was the right
term to use.  Radek and Curtis thought that stating that the contents would be
ignored in the "None" case was correct.  They said that in IBIS 7.0,
clock_times is only used as an output by the model, and the EDA tool is only
responsible for making sure that enough memory has been allocated to clock_times
for the model to return the clock ticks.  Any data in clock_times when the model
is called is ignored by the model in the "None" case (or in IBIS 7.0).  Radek
suggested we remove the pointer-style "*" from clock_times and wave output
throughout the draft text.  Fangyi made the changes to the draft.

Randy moved to submit the modified version to the Open Forum.  Fangyi seconded.
There were no objections.

- Michael: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

AR: Fangyi to send the modified DQ DQS draft to Randy to be submitted to the 
    Open Forum as a BIRD.

-------------
Next meeting: 28 April 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 21 April ibis-atm meeting - Curtis Clark