Hi Everyone,
During review of these minutes at the 29 September meeting, Bob Ross noted one
correction/clarification with respect to one of his comments. The following
sentence:
He said they'd even developed a separate rail specification and parser,
but it wasn't adopted.
has been changed to:
He said they'd even developed a separate RAIL (Rules Augmented
Interconnect Layout) specification (circa 1996) and parser, but it wasn't
widely adopted by the industry.
Since these minutes hadn't yet been posted to the website, I'm attaching a
corrected version.
Thanks,
Curtis
________________________________
From: Curtis Clark
Sent: Thursday, September 24, 2020 6:45 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: Minutes from the 22 September ibis-atm meeting
Minutes from the 22 September ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 15 September 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
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 Randy had suggested that the "IBIS-ISS parser" entry in the
topic bin list could be removed because the Interconnect task group is looking
into it.
-------------
Review of ARs:
- Michael to send a second 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 15
meeting. Michael moved to approve the minutes. Lance seconded the motion.
There were no objections.
-------------
New Discussion:
New Clock-Data Pin relationship BIRD [Clock Pins]:
Michael Mirmak briefly summarized the [Clock Pins] BIRD draft, which had been
introduced and described at the previous meeting.
- New keyword [Clock Pins]
- Each entry (row) has three columns
- The first two columns contain pin_names from the [Pin] list.
- The third column defines a timing relationship between the two.
Michael said the goal is to tell the tool/user that there's a timing
relationship between pins. He said that based on feedback from the first draft
he had added language to deal with the case of [Diff Pin] pairs. Based on
feedback from Bob he also added text to deal with [Model Selector]. He
reiterated that his hope is to focus on this new keyword alone and get this
timing relationship concept into the specification as soon as possible. He said
this concept can't be included at the [Model] or .ami level. Its immediate
goal is to facilitate the clock pin - data pin relationship needed by DDR. It
does contain the third column and some allowed values for it, but the third
column is currently just providing a descriptive string with no other meaning
defined. Long term he expects an additional BIRD and perhaps additional
keywords to be added to fully define the information in the third column. For
now it's a place holder, so we don't get bogged down for a long time defining
those relationships.
Randy asked if we need to think this through carefully to make sure this keyword
will stay relevant and not become obsolete as the future changes are made.
Michael said this was a good question, and this was why he had tried to make
this keyword as simple as possible. We would need a new BIRD to define the
timing relationships and expand upon them, but it shouldn't affect this BIRD.
He noted that if we get into more complex timing relationships, for example,
defining a relationship amongst more than a pair of pins (or pair of diff pin
pairs), we might have to revisit this BIRD then. He said he wasn't expecting
this to happen.
Michael noted that there had been some questions about the relationship with the
package and whether the timing relationships might have to be at the pin or the
pad, but this could be dealt with later. Randy asked if this was related to the
Si_location Sub-param. Michael said it was, and the problem with Si_location is
that it is specified for the entire [Component]. Since different interfaces
specify pin level or pad level timing, a component wide Si_location might not be
sufficient. He said that the process of defining these timing relationships in
column 3 might be the beginning of a change to address this shortcoming. We
might define something that overrides Si_location, or perhaps define the concept
of clock pins and clock pads.
Arpad said the discussion had moved into timing and timing locations, and he
didn't think we needed to get into timing yet, as this BIRD only defines a
logical clock-data relationship not the timing relationship. Michael agreed
but said Randy is suggesting that [Clock Pins] strongly implies that the pin is
the timing location.
Arpad asked if this proposal would be able to handle splits and joins if IBIS or
EMD ever allowed that and got away from the one-to-one pin to pad mapping. For
example, he brought up a RAMBUS example Walter had described where two clock
pins connected to the same pad (e.g., clock pin1 connects to pad1 and then back
out to clock pin2). Michael said the current proposal would support that by
letting the clock on one pin be an input and the clock on the other pin be an
output. He noted that right now in this BIRD the column three data is not
really cross checked with the types of pins, only the relationship and perhaps
the directionality can be checked. Perhaps the relationship would be Clock_Skew
in this case. Currently the first entry has to be a clock, the second entry
could be a clock but is most likely data, and the third entry is just a string.
Randy said that as written, since the BIRD doesn't talk about timing, we are
okay for now and can expand things later.
Bob and Fangyi asked if it was possible for a clock pin to appear in column 1
(this is required), and a clock pin to also appear in column 2, and for the
pin in column 2 to appear as the clock pin in column 1 on another row. Fangyi
explained this scenario as having a clock pin defined for a data pin, but that
clock pin is itself derived from a reference clock. Michael referred to this
sentence in Usage Rules:
Entries in the second column shall not appear on more than one line under the
keyword.
He said this sentence prohibited the scenario Bob and Fangyi asked about, but
that we could relax this restriction. He noted, however, that history had shown
us that it's much easier to define something narrowly to start with and then
expand it later if necessary.
Bob said that historically IBIS had decided many years ago to keep timing
separate from the IBIS buffer. He said they'd even developed a separate RAIL
(Rules Augmented Interconnect Layout) specification (circa 1996) and parser, but
it wasn't widely adopted by the industry. Michael said Bob raised a good point,
a limitation of putting timing information in a [Model] is that a given [Model]
could be applied to multiple interfaces with different timing relationships. We
want to avoid having timing in the [Model] and keep it at the interface ([Pin])
level.
Bob noted that it's legal for a [Model Selector] to include [Model]s of various
types. Michael agreed and said language in the proposal explicitly states that
it's compatible with [Model Selector], but it notes that it may be possible to
declare timing relationships that may be inappropriate if certain [Model]s are
selected. He said this can't result in a parser error because it's possible
other models in the selector would be valid. Perhaps the parser or tool could
issue a warning if a model type incompatible with the timing relationship were
seen.
Fangyi asked Michael for definitions of the three relationships defined in the
proposal. Michael said the relationships' definitions are somewhat implied by
the description of the allowed directionality (input/output) of the pins in
column 1 and column 2. For Clock_to_Out and Setup_Hold, the first pin is some
type of clock and the second pin is some type of data.
Clock_to_Out - first pin is incoming clock and there is some delay before the
data appears at pin 2. Pin 1 input or bi-directional. Pin 2
output or bi-directional.
Setup_Hold - clock is on pin 1 and there's a setup and hold relationship
with the data pin 2. Pin 1 input or bi-directional. Pin 2
input or bi-directional.
Clock_Skew - pin 1 is a clock and pin 2 is a clock and there's a delay
between them. Pin 1 output or bi-directional. Pin 2 output or
bi-directional.
Lance asked if there were rules to enforce use of the right Model_types for the
two pins. Michael said that the relationships imply a directionality and the
parser could report an error if an incompatible type were used, for example, if
an output Model_type were used with either pin of a Setup_Hold relationship.
Randy asked if Setup_Hold, for example, was envisioned for a write clock where
the strobe is input or bi-directional and the data is bi-directional. Michael
agreed that was the intent.
Fangyi asked Michael what types of signals he envisioned on pin 1 and pin 2 for
the Clock_Skew case. Michael said one example might be a mux or multi-clock
chip where you need to specify timing limits of the relationship between one
output and another. Randy suggested a register DIMM example with a clock in
and four clocks out. Michael agreed this would be one example.
Fangyi asked if the relationship defined the signal path in the IC or just the
timing relationship in the measurement. Michael said the goal was only to state
the timing relationship in the measurement. He said that historically, for
single-ended memory simulation, IBIS had no timing, jitter, etc., information at
all. All of this had to be provided to the user outside of IBIS somehow. Now
the goal of this proposal is to start to pull that information back into IBIS.
We now have BIRD 204, which allows for a DQ buffer that needs to be latched by
an input DQS. We currently have no way in IBIS to tell the user/tool where that
DQS signal is coming from. This proposal wants to fill that void. Michael said
he was open to other ways of providing that information, but he wanted to avoid
getting bogged down in the details of the timing relationships themselves.
Arpad asked about [External Circuit] and referred to figure 30 on page 150 of
IBIS 7.0. He noted that pin 4 is the clock for the data pin 3, and he asked if
this proposal could be used to give pin relationship information for [External
Circuit] calls. Randy and Bob noted that it could be more difficult to do
consistency checking with [External Circuit], as it's harder to infer
directionality. Arpad said use of a D_to_A, for example, implies it's an output
or I/O. Randy asked if the parser currently checked that. Michael said that
the high-level answer to Arpad's question is that there are no conflicts between
[Clock Pins] and [External Circuit], but nothing in this BIRD says to cross
check the directionality with [External Circuit]. Michael said [Clock Pins] is
optional, so there's no requirement to make it comprehensively support [External
Circuit]. Randy suggested it would simplify the BIRD if we simply stated that
it is not cross checked with [External Circuit].
Ambrish noted Michael's stated primary goal of getting the timing relationship
concept into the specification. He asked why column 3 is included at all in
this BIRD. Michael said this was a good question and that he was open to the
suggestion to eliminate it. However, without column three there are several
concerns: the parser can't do directionality checking, the third column does
provide some architectural information (per Fangyi's earlier question), and the
complication of having a subsequent BIRD have to add a column 3 later. Fangyi
said at this point column three is really more for the parser than anything
else.
Michael gave himself an AR to consider five possible change suggestions from
this meeting:
- "clock pads" per Randy.
- rails per Bob.
- whether the proposal should allow clocks to appear in column 1 and later in
column 2 per Bob and Fangyi.
- define what the relationships really mean per Fangyi.
- at least state that the directionality of [External Circuit] can't be cross
checked per Arpad and Randy.
- Randy: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Michael to create a third draft of the [Clock Pins] BIRD proposal.
-------------
Next meeting: 29 September 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
