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

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "IBIS-Interconnect" <ibis-interconn@xxxxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 7 Dec 2017 06:58:18 -0500 (EST)

Arpad,

 

A group has Sets and Sets have Models. Therefore a Group contains a list
of Models generated from all of the Models in the Sets in a Group. Bottom
line is a Group ends up with a list of Models.

 

I described a report hat can be generated for each Group. The report lists
all pins in a [Component]. A Group is not required to have interconnect
models for each Pin. For example, a Group may have Models for just one
bus. Randy described his case of having Models for the DQ and DQS pins,
and rely on legacy models for the other buses in the chip.

 

See further comments below.

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, December 7, 2017 1:56 AM
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

 

Walter,

 

Here is a portion of your spreadsheet:

 



 

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.

 

WMK> A Group has a list of Sets. A Set has a list of Models. Therefor a
Group has a list of Models.

 

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.

 

WMK> Each row in the spreadsheet represent the "Model Types" that are in
the Group for that Pin. Each "X" represents if there is a Model of that
"Model Type" in the Group.

 

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.

 

WMK> The concept of having a Group with NOT a single Model is not new. A
Group has to have at least one Set but there is no requirement that there
be a Model in each set for each Pin.

 

WMK> The following needs to be re-thought out based on my comments above.

 

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>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, December 6, 2017 2:13 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx <mailto: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

 <mailto:wkatz@xxxxxxxxxx> 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

 <mailto:wkatz@xxxxxxxxxx> 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