[ibis-macro] Re: BIRD-125: ISS as package-model
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 13 Jan 2011 09:33:49 -0800
Kukal,
Your statement that "the BIRD requires the user to always specify one
sub-circuit for the whole package"
is incorrect. The [Pin Numbers] keyword in the package model does NOT
have to have a full listing of all the pins listed in the [Pin] keyword
of the .ibs file. So you may have a 10000 pin device with a 6 pin
package
model (which describes three differential SERDES channels, for example).
You may wonder, how would you then be able to describe several different
subsets of the 10000 pin device if there is only one [Package Model]
keyword
in an .ibs file. This is when the [Alternate Package Models] keyword
can be
used. You can write a bunch of package models using the [Define Package
Model]
keyword, each of which can cover a different section of the full device,
or
give alternate versions for the same section, and when you simulate
certain
pins of the fill device, you would just select the corresponding package
model from the [Alternate Package Models] keyword.
Regarding the direct referencing of the S-parameter models, I think it
is
not a bad idea, but it has its own complications in the area of port
ordering.
If we invented such a direct reference to S-parameters, we would also
need
to make provisions for defining the port ordering. If you have ideas on
how
to do this, feel free to write a BIRD... I just like the ISS subcircuit
approach
better because there is more flexibility in the ISS subcircuit. A
direct
instantiation of the S-parameter may be somewhat simpler, but is only a
subset of what ISS can do.
Thanks,
Arpad
========================================================================
=========
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal
Sent: Thursday, January 13, 2011 1:26 AM
To: IBIS-ATM
Subject: [ibis-macro] BIRD-125: ISS as package-model
Hi Arpad,
The BIRD surely bridges a gap that was very important as almost every
package needs to be an s-parameter model at MGH.
However, it seems that the BIRD requires the user to always specify one
sub-circuit for the whole package. So, if the package had 8, 16, or 100
pins then the user needs to provide a 16, 32, or 200 terminal subckt,
respectively.
We always get package models as models for single pins or diff-pin(s). I
think we should extend the BIRD to include subcircuits per pin (and
per-diff-pin) and may be cover cases where several smaller sub circuits
can be assigned to subsets of the package pins.
Another minor thing is that we are forcing the user to wrap s-parameter
files into ISS - Not sure if the syntax should allow direct s-parameter
instantiation.
This is a surely not a big issue.
rgds
..kukal
Taranjit Kukal | Product Engineering Architect
P: 91 120 3984000 www.cadence.com <http://www.cadence.com/>
Other related posts:
