Minutes from the 06 October ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 06 October 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
Google: Zhiping Yang
Intel: * Michael Mirmak
Kinger Cai
Keysight Technologies: * Fangyi Rao
Radek Biernacki
Ming Yan
* Todd Bermensolo
Rui Yang
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SAE ITC * Jose Godoy
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:
- Arpad noted that the agenda had stated that we will need to switch the meeting
to Microsoft Teams in the future. However, in attempting to log in to today's
meeting, people discovered the Webex had been cancelled. So today's meeting
was held with Teams. Look for the Teams meeting link in future agendas.
- Arpad noted that he had removed the previous item #7 from the agenda list,
since we had discussed Intel's presentation from the most recent IBIS summit.
In its place, he had added a topic for a new GDDR6x technology Randy had asked
to discuss.
-------------
Review of ARs:
- Michael to send a fourth draft of the [Clock Pins] BIRD proposal.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the September 29
meeting. Randy moved to approve the minutes. Michael seconded the motion.
There were no objections.
-------------
New Discussion:
New Clock-Data Pin relationship BIRD [Clock Pins]:
Michael Mirmak briefly summarized the fourth draft of the [Clock Pins] BIRD,
which he had sent out prior to the meeting. He noted that this version focused
on the reintroduction of the third column. The third column is for future
expansion, and the only permitted entry at this time is "unspecified", which is
case-sensitive. This gives us something other than "NA", but it is still a
fixed allowed value. Text now states that the first and second columns contain
pin_names, but it no longer specifically says "clock" and "data" pins. Instead,
it states that the pin in column 1 clocks the pin in column 2. There is no
checking of directionality other than the sentence about the allowable
Model_types. Michael also noted that he had added one final sentence prior to
the example. It states that this proposal is compatible with Timing_location.
Walter said that one issue is the numbers themselves (min-max delay, rising,
falling, etc.), and we all know that is complex. Walter said he'd be willing to
share the numbers from their timing models when we get to that discussion. He
said the other issue is "what kind" of relationship (clock to out, setup and
hold, for clock forwarding on the write it is skew between clock and data), and
that information is independent of the numbers. Walter said he would prefer to
have four columns. The third could be the relationship, and the fourth could be
a place holder for a future pointer to a data structure fully defining the
relationship. Walter acknowledged that he'd missed the last few meetings and
may have missed some discussion. Michael confirmed that we had discussed the
second issue at great length in the past few meetings. He had originally
included a third column providing only the names of three relationships, but he
had encountered demands for more detailed information on exactly what the
relationship names meant. Rather than get bogged down in attempting to provide
definitions yet keep the terms vague enough to be fully defined later, he had
dropped the relationships and gone with the "unspecified" placeholder column.
Walter said he was fine with approach if we had already discussed the options.
Bob said that Walter had a good point about the complexity of defining the
relationships and providing all the numbers. He said he would ask Steve Parker
(webmaster) and Mike LaBonte to resurrect the links to the RAIL (Rules Augmented
Interconnect Layout) specification that had been developed years ago. He noted
that it had carefully defined many relationships. Bob said this current
proposal provides a template for relating two pins, but the entire relationship
may take 5 or 6 more keywords and won't be a simple BIRD.
Bob noted, as he had in the last meeting, that he preferred "NA" instead of
"unspecified". Michael said we had discussed it last time and put considerable
thought into "NA". He said the goal here is to leave it so the tool or user can
fill in the details for now. "Unspecified" says that the relationship is not
specified. "NA" could be taken to imply that no relationship exists, and we may
need to have "NA" available later for that meaning. Bob agreed that Michael's
logic was sound, but he said he'd prefer the first letter of "unspecified" be
capitalized. Michael changed all instances to "Unspecified" and noted again
that this would be a case-sensitive comparison.
Bob stated that this proposal now allows chains: al clocks a2, a2 clocks a3,
a3 clocks a4, etc. Michael agreed and said the only remaining restrictions
are that an entire row can't be repeated, and that the same pin can't appear
in column 1 and column 2 on the same row. Arpad asked if loops were possible,
for example a4 could then clock a1 in Bob's previous example. Michael said
nothing in the syntax prevented it. Bob said he had brought up a loop at the
previous meeting as a pathological case, but that a circular loop actually
didn't make sense. Walter said one could look at a Rambus clock to see how
complicated this could get.
Arpad asked if the group felt this was ready for Michael to submit as an
official BIRD. Randy moved to recommend Michael submit it. Curtis seconded.
There were no objections. Michael took an AR to submit the BIRD to Randy
for posting. Bob noted that it would likely be assigned the number BIRD208.
GDDR6x Discussion:
Randy reviewed his presentation "GDDR6x Introduction". Randy noted that GDDR6
is a graphics DDR memory technology that has been around for a while, and GDDR6x
is a new super speed variant. It was developed with Nvidia. The presentation
summarizes publicly available information on the new memory signaling
technology. The goal of the presentation is to spur thought about IBIS modeling
support requirements.
slide 2 - What's new:
- Link to a technical brief with more details
- Makes use of single-ended PAM4
- Pushes single-ended I/O beyond 16Gbps, targeting up to 32Gbps
slide 3 - PAM4:
- Same old PAM4, just single-ended this time
- NRZ has broken down beyond 16Gbps, but PAM4 can achieve 32Gbps
slide 4 - Tx/Rx specs:
- Tx and Rx will have Equalization
- 1.25V or 1.35V VDD/VDDQ
- VDDQ terminated bus
- First product 19Gbps or 21Gbps, in future moving beyond that
- Gray coded data
- 3 Rxs, 3 VREFD levels
- 40 or 48 Ohm ODT
Arpad asked if the VREFDs were provided externally or internally generated.
Randy said it's internal, like DDR5, with registers set to provide 64 steps.
Bob asked if termination was selectable or fixed. Randy said the 40 or 48 is
selectable.
slide 5 - Tx Impedances:
- Tx implemented with 60 and 120 Ohm PU/PD legs.
- The 4 combinations provide the 4 output levels.
- Various swings based on VDDQ (1.25V or 1.35V) and Rx termination (40 or 48
Ohm).
Arpad asked what the red resistors in the diagrams represent. Randy said they
represent the termination value at the Rx.
slide 6 - Clocking:
- clock diagram shown (PAM4 operation shown, lower speed non-PAM4 also exists)
- Similar to graphics:
- base frequency clock
- write clock
- data itself
Bob asked how this would fit it with BIRD208. Randy said you'd have a write-
clock to data relationship.
slide 7 - What is needed from IBIS?:
- IBIS
- New Model_types (I/O_PAM4, Input_PAM4, Output_PAM4)?
- two-bit input stimuli?
- Multiple Pullup/Pulldown curves?
- 6 sets of V-T waveforms (one for each transition)?
- [Driver Schedule]-like architecture?
Randy said the last point wasn't strictly like Driver Schedule in the sense of
various delays being applied, but that you'd be switching differently depending
on the input bit pattern. Bob said if we need a dynamic change in behavior, we
might look at Arpad's presentation from the 2018 SPI IBIS Summit. Arpad agreed
this might be worth a look. He noted that they had implemented their examples
with VHDL-AMS, but we could fold them into legacy IBIS. Randy said it would be
helpful to review it.
- IBIS-AMI
- EDA tools
- Support new Model_types for use in channel characterization?
- Multiple edge responses?
- Multiple bit responses for superposition schemes?
- PAM4_*Threshold levels are VREFD levels. How are they to be set?
- Special DC_Offset handling required?
- Modify IBIS Section 10.7 (Modulation Reserved Parameters).
Ambrish noted that for SERDES PAM4 in AMI we hadn't worried about different V-T
waveforms. Arpad said as long as the step response is defined over the full
range of the PAM4 signal swing, the one-level IBIS [Model] should work the same
way here. Randy said he wasn't sure how SERDES PAM4 devices worked, but that
the drivers for this GDDR6x are not at all linear over the entire range.
Walter said he had some experience with single-ended PAM4 channels. He said
people worry about the non-linearities, but that those effects tend to go away
because of the high frequency losses. His experience suggested single-ended
AMI allowed users to do good engineering analysis, the IR processing works,
and we probably just have to lift the restriction that says that PAM4 AMI is
limited to differential. He said he'd yet to see a case where non-linearities
were important for NRZ, PAM3, or PAM4 at these data rates. He thought we could
go a long way before we'd have to worry about different V-T tables for different
transitions. Until then, we should just think about what changes might be
required in the future. Ambrish and Walter agreed that we have a workable
solution already.
Walter asked if this would end up as a JEDEC standard. Randy said there had
been a G5x, and he didn't think that had been standardized. He didn't think
G6x would be standardized, but perhaps PAM4 might go into a G7. Arpad asked
if Randy expected that only Micron and Nvidia would be making these G6DDRx
devices or if everyone would make them. Ambrish answered that their IP group
had asked them to look into it too.
Bob asked about the resistor combination figures on slide 5. Randy said these
were implemented inside the pullup/pulldown structures attached to the same
location. Walter noted that the PAM4 symbols, referred to as -3, -1, +1, +3 on
this slide, are more often called 0, 1, 2, 3 in the industry.
- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Michael to send the [Clock Pins] proposal to Randy to submit as a BIRD.
-------------
Next meeting: 13 October 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
