[ibis-macro] Re: One Page Functionality of My Group Set Rules in Bullet Form

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 7 Dec 2017 06:56:02 +0000

Walter,

Here is a portion of your spreadsheet:

[cid:image002.png@01D36EE8.F2C65AB0]

First, note that I crossed out "Model" and replaced it with "Set".  Like I said 
before,
Groups can only contain Sets, so let's try to call things by their proper name. 
 This
applies also to your "bullet form" summary.  I think in some places you use 
Model
instead of Set there too.

Along the same line of thinking, I believe that each row in this spreadsheet 
represents
a Group Type and each "X" represents one (or more) Set(s) that may be present 
in any
of the Group Type(s) or rows.

The concept of having a Group with NOT a single Set is new.  I thought that in 
the BIRD
we said that a Group had to have at least one Set.  I see why you are doing 
this, and
I think we could live with this idea, I just wanted to point it out.

I think we still need to write rules on how the bits and pieces of the whole 
interconnect
can be split up between Sets and Models.  Your bullet form summary and the 
errors and
warnings list in it are a good start, but they do not address everything.  For 
example, if
pins 1-16 have several Models, one that is coupled, another that is uncoupled, 
and
additional variations which touch different interfaces (pin/die/buffer), and 
then for pins
17-32 there are more Models generated in a similar manner, how are they 
supposed to
be organized between the Sets and Groups?  Can or do they have to be In the 
same Set,
or different Sets?  Or are the no restrictions?  Does the requirement of 
organization (if
there are any) depend on what interface the Models or Sets touch?  In other 
words, can
a Set have Models which touch different interfaces?  Or can a Group have 
multiple Sets
which touch different interfaces?  Does the signal and supply modeling have to 
follow
the same organizational rules, or can they be organized independently?  Your 
summary
does cover some of these questions, but not all of them...

Since we are trying to write a specification, we need to spell such rules out.

When I got the AR to write a proposal for this whole grouping and selector 
topic, these
were the questions we were debating.  I might have missed it, but I don't think 
we came
to an agreement/resolution on what these rules should be.  This idea of using 
Group
Types is a nice mental exercise, but I don't think it answered all of the 
original questions
we started from, at least not directly.

Some observations, using the spreadsheet representation:
The position of the "X" character could help us to formulate the rules we need 
to write.
Note that the only time there are two "X" in a row is when both the package and 
the
on-die model exists.

If Pad_to_Buffer  and Pin_to_Buffer doesn't exist, short the pad with the 
buffer terminal
If Pin_to_Pad and Pin_to_Buffer doesn't exist, or Group is empty, use legacy 
package model

Note that this applies to both signal and power modeling.  But do they have to 
be followed
simultaneously, or are they independent?

Regarding usage of the legacy package model, didn't we have a rule (or goal) in 
BIRD189
that said that we didn't want to mix the old and new modeling styles?  
Depending on
how we answer that, I wonder whether we really need a subparameter to indicate
bare-die, because other than the optionality of using the legacy package model 
for the
bare die case, your rules are the same  for the bare die and the component 
cases...

So much for now.  I think this is a good start, but we need to work some of the 
details
into the BIRD (spec) format.

Thanks,

Arpad
=========================================================================

From: ibis-interconn-bounce@xxxxxxxxxxxxx 
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, December 6, 2017 2:13 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>; IBIS-ATM 
<ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: One Page Functionality of My Group Set Rules in 
Bullet Form

All,

The IBIS Parser (or any EDA tool for that matter)  can generate a spreadsheet 
report for each group that describes the Model Interfaces for each pin. This 
can be done for the models in Groups that satisfy either Bob's or my rules. It 
is a simple graphical way of describing what models can be in a Group.

The enclosed spreadsheet is an example of such a report with all possible legal 
Interface combinations using my rules for the two Group Types in my proposal 
(Component, Bare-Die). This example report reports for each signal pin only 
victim usage, I did not include Aggressor columns for info if the pin appears 
in Models as an Aggressor.

Walter

Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
978.461-0449 x 133
Mobile 303.335-6156

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, December 6, 2017 12:28 PM
To: 'IBIS-Interconnect' 
<ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>>; IBIS-ATM 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: One Page Functionality of My Group Set Rules in Bullet Form

All,

Features of my Group/Set proposal in bullet form


  *   An interconnect "Model" "Interface" is either between Pin/Buffer, Pin/Pad 
or Pad/Buffer.
  *   A Set contains a list of Models that have a logical association (e.g.)
     *   All models in a bus (e.g.. DDR4, or PCIeG3)
     *   PDN Network
     *   All I/O models between Pad and Pin
     *   All I/O models between Buffer and Pad
     *   All uncoupled models
     *   All coupled models
  *   A Group has a list of Sets.
     *   Therefor a Group has a list of Models derived from the list of Sets in 
the Group
  *   A [Component] can have one or more Groups.
  *   The User/EDA tool selects one Group for generating interconnect models 
for a simulation.
  *   Group Types
     *   Component
        *   The interconnect is between buffer and pins.
        *   Buffers and Pads are shorted if there is a Pin/Pad Model but no 
Pad/Buffer Model for an I/O or rail.
        *   Use a legacy Pin/Pad model If there is a Buffer/Pad model and no 
Pad/Pin model for an I/O or rail.
     *   Bare-Die
        *   Models in the Group can only be Pad/Buffer. This implies that all 
of the Models in all of the Sets in the Group are Buffer/Pad.
  *   Errors in Model Compatibility within a Group
     *   All Models in a Bare-Die Group can only be Pad/Buffer
     *   I/O pin_name rules
        *   Two Models cannot have the same Victim Pin Pin_name
        *   Two Models cannot have the same Victim Buffer Pin_name
     *   Rail rules
        *   The following rules apply to models that define rail connections 
Pin/Buffer, Pin/Pad or Pad/Buffer. They do not apply to models when a rail is 
only on one terminal to supply a reference voltage
           *   Two models cannot have the same pin rail connection.
           *   Two models cannot have the same buffer rail connection.
  *   Warnings in Model Compatibility within a Group
     *   I/O pin_name rules (include both Aggressor and Victim terminals.
        *   Two Models cannot have the same Pin Pin_name.
        *   Two Models cannot have the same Buffer Pin_name.
     *   No need to report warnings if already reported as errors.

Walter


Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
978.461-0449 x 133
Mobile 303.335-6156

PNG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2017