[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






PNG image

================================================================================

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: