[ibis-interconn] Minutes, March 27, 2024 IBIS Interconnect Meeting
- From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>
- Date: Tue, 2 Apr 2024 01:38:09 +0000
Please find enclosed the minutes from the March 27, 2024 IBIS Interconnect Task
Group meeting. Comments are welcome.
* MM
================================================================================
IBIS INTERCONNECT TASK GROUP
Mailing list: ibis-interconnect@xxxxxxxxxxxxx
================================================================================
Attendees from March 20, 2024 Meeting (* means attended at least using audio)
ANSYS Curtis Clark, Juliano Mologni
Broadcom James Church
Intel Corp. Michael Mirmak*
Michael Brownell
Keysight Technologies Ming Yan
Marvell Steve Parker
MathWorks Walter Katz*
Micron Technology Justin Butterfield
Siemens EDA Weston Beal, Arpad Muranyi*, Randy Wolff*
ST Microelectronics Aurora Sanna
Synopsys Ted Mido, Edna Moreno
Teraspeed Labs [Bob Ross]
University of Illinois Jose Schutt-Aine
Zuken USA Lance Wang
Michael Mirmak called the meeting to order. No patents were declared.
Before the minutes were reviewed, Michael discussed the news that
longtime IBIS contributor and former chair Bob Ross had passed away
the previous week. Walter Katz commented that this was a very sad day
for IBIS. Michael invited more statements from the participants, and
noted that the IBIS Open Forum meeting on Friday would provide more
details as to organizational changes and any observances that may be
made by IBIS as a whole.
Michael reviewed the minutes of the March 20 meeting. Randy Wolff moved
to approve the minutes; Arpad Muranyi seconded. The minutes were
approved without objection.
Michael noted that only he had a standing AR to review the IEEE 370
document for its sampling treatment.
During opens, Arpad noted that he is working on TSIRD 7.1, to correct
minor typographical and other issues. It will likely not be submitted
to the IBIS Open Forum yet, as it is not yet ready.
Arpad opened the discussion of the port-mapping topic by noting that he has
two documents to share, with both already distributed via e-mail.
The team reviewed one presentation from 2023, showing the port map format
in an earlier form. In the format, connectivity comes from the pin list,
and includes pad list, etc. Arpad also found some issues with the original
HL_portmap syntax has revised it.
In that form, the syntax was PORT followed by portnumber, +, descriptor, -,
descriptor, and an optional name. We have since added "side"; Arpad noted that
he dislikes an approach that organized the list by port number and added
"Group_by_Name".
Arpad also added the *.PinName syntax (not yet supported in EMD) to use
references by
reference designator. This feature seems to be able to co-exist with the
syntax.
He proposes adding SPICE NodeName in the netlist and schematic forms, and
including
x,y,z coordinates in PCB packages.
Walter asked about the context of a physical port name. Imagine a 10 sheet
schematic,
with indication of location of a given port on a specific sheet. For an IO, a
physical port
name is just a name. It may depend on whether you are an EMD, or a C_comp
model, or an IBIS.
For IBIS, the format would be Pad:pin_name, or buffer:pin_name.
RefDes.pin_name would be
used for EMD. Walter prefers pindef and does not really like "group" as a
term, as it is overloaded.
Arpad replied that some of the names stem from the original HL syntax, and were
selected to ensure
minimal changes. Walter stated that the format should be generally readable.
He suggested, per page 13,
adding more readable examples, for example, using "net name" for the logical
name. He likes the original
HL names.
Arpad replied that the IBIS specification forced changes to some of them (e.g.,
bus label, signal name,
rail signal names, etc.). The names can be changed.
Walter responded that, if you use the physical pin names, they will map
directly to IBIS. He prefers that
the first entry is the physical port name instead of "pin". One could generate
a wrapper automatically with
consistency if the mapping were done this way.
Arpad noted that Pin_IO and Pad_IO are used for connections to IBIS package
names. One would have to include
actual connection points. Walter suggested that a format like pin.A7 and
pad.A7 would be easier to read.
Michael asked whether the intent here to have a single TS file for an entire
package. Walter replied that one
may want to generate a Touchstone file for the DQ lanes. Michael asked whether
the entire path from buffer to
pin was to be described. Randy suggested the format could describe any path.
Arpad suggested that users were
unlikely to do this, but Michael replied that this is a common usage approach.
Walter stated that we don't want to make Touchstone a netlist format, BUT we do
want to use it as a documentation
format for an entire system where needed. We know what it represents.
Randy suggested that the file format can include reference designator
information. Walter added that parentboard,
childboard designations would also be needed. Randy added that board name vs.
device name distinctions would be
needed.
Arpad replied that the original HL is both a pre- and post-layout format; under
the hood, the tool will save the
entire system as a single S-parameter. He added that he does not think we
should write a specification for it.
Randy noted that he has seen measurements in a lab for multi-board systems.
Walter suggested there was too much
focus on having multiple capabilities in the same file.
Arpad replied that the focus here is the link, for instance, between IBIS
buffer and package file set because they
are "married for life".
Walter responded that 99% of people generating Touchstone files do not need the
connectivity data for IBIS.
Physical port names can be used to identify logical names. *If* it's for an
EMD or an IBIS model, then you can generate
the interconnections.
Randy suggested that the explanation be reorganized, perhaps using
sub-chapters, such as on creating port names for an IBIS package,
creating port names for an EMD usage, etc. We need to prevent people from
reading this super-complicated format and giving up.
Walter added that he has customers that say that they want certain information
in the file, want it parsable, then can use it any
way they want to. They may want to use this for tracking what has been
measured, for instance, and want this data put into the
context of the Touchstone format. He will be requesting a keyword with
"status" as a field for adding information (e.g., measurement);
this may be needed for i,j or x,y not a port. He agreed with Randy that the
document should be organized for onboarding new
users.
Michael asked whether
1) non-physical descriptions in this format are acceptable (e.g., ideal ground)
2) any technical features were still missing from the format.
Walter stated that, even without x,y locations, netlists are still non-physical
connections. Antennas and filters can be
represented through Gerbers.
Walter took the AR to re-send his commentary e-mail to the reflector, and will
re-do slide 7 (the complete feature list) his way. [AR]
Arpad to lead the document with simple examples. [AR]
Arpad moved to adjourn; Randy seconded. The meeting adjourned.
The next meeting will take place on April 3, 2024.
================================================================================
Bin List:
1) [Complete draft Touchstone document separating version 1.0 and 2.0 into
their own chapters] - REMOVED
2) Create structures to encapsulate Touchstone 1.0 data in Touchstone 2+
specifications - TABLED
3) Complete draft Touchstone 2.0 document containing TSIRD3 and TSIRD4
draft (Muranyi) â COMPLETED
4) Complete pole-residue format BIRD draft (Muranyi) - COMPLETED
5) Complete port naming proposal (Katz) - COMPLETED
6) Create alternatives to the Touchstone 1.0 option line before the "R"
character - TABLED
7) Complete ISS-IRD 1 Draft - Enable Cascading of S-parameters Through
W-element (Mirmak) - TABLED
8) Complete/revise Touchstone 3.0 draft outline (Mirmak) â dependent on
several items above
Tabled ARs:
- Arpad to give an example of the physical connectivity needed for EMD
automation.
Other related posts: