[ibis-macro] Re: Package and on-die modeling
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 6 Sep 2012 14:00:00 +0000
Since the regular release schedule was mentioned, I would
then suggest to consider the Repeater and Back Channel
proposals in a short order. It seems that these may be
easier to deal with than figure out all these analog
modeling challenges...
Arpad
==========================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Gregory R Edlund
Sent: Thursday, September 06, 2012 8:51 AM
To: wkatz@xxxxxxxxxx
Cc: IBIS-ATM; ibis-macro-bounce@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Package and on-die modeling
Walter,
This seems like a reasonable, incremental approach to me -- one that would be
consistent with Michael Mirmak's presentation at DesignCon on the topic of a
regular release schedule. I do think we can tackle IBIS 6.0 in a six month
period if we quickly converge on an approach. We may need some additional
break-out calls. Would a face-to-face meeting help get the effort off the
ground? It's about time for the famous Boston fall colors. For that matter,
Minnesota is a central location, and we probably have another month until the
first blizzard hits! 8-)
Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N Bldg 050-3
Rochester, MN 55901
[Inactive hide details for "Walter Katz" ---09/05/2012 02:11:16
PM---All,]"Walter Katz" ---09/05/2012 02:11:16 PM---All,
From: "Walter Katz" <wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>>
To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Date: 09/05/2012 02:11 PM
Subject: [ibis-macro] Package and on-die modeling
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
________________________________
All,
I would like to propose the following specific package and on-die modeling plan:
IBIS 6.0
Support only On-Die Tstonefile (s2p and s4p) interconnect models using the
[Model] sub parameters [Tstonefile] and [Tstonefile Ports].
Support package IBIS-ISS subckts as a .ipkg file which would be in Parameter
Tree format.
IBIS 7.0
Support On-Die IBIS-ISS subckts as a .idie file, similar to the .ipkg file but
between pads and buffers instead of between pins and pads.
IBIS 7.0
Create a new EMD standard
IBIS 8.0
Create a new IBISx format (.ibsx) which is .ibs in Parameter Tree format
I would defer any work on IBIS-BSS until IC Vendors make a specific request for
such functionality. Again, we need to be driven by IC Vendors desire and
ability to supply buffer models in such a modified SPICE syntax. I point out
that IBIS-AMI modeling was driven by two IC Vendors.
I make the recommendation for IBIS 6.0 because IC Vendors are only delivering
On-Die Tstonefile (s2p and s4p) interconnect models today. We should not create
an On-Die IBIS-ISS standard until we get definitive requirements from IC
Vendors. We now know the requirements for On-Die Tstonefile (s2p and s4p). If
IC Vendors do give compelling reasons to implement On-Die IBIS-ISS subckts we
can consider moving the implementation to IBIS 6.0, since much of the basic
work will be done in the implementation of package IBIS-ISS subckts as a .ipkg
file.
I recommend doing the IBIS-ISS package model in .ipkg Parameter Tree format
because
1. It is easily to parse
2. It is easily extensible
3. It satisfies all known requirements for package models currently being
delivered
4. It will slide into the new EMD standard with minimal effort
Most of the issues raise about my presentation Tuesday were on EMD and .ibsx,
since these are deferred, and once I have implemented examples with additions
IC Vendor supplied package models the syntax of the .ipkg file can refined and
ready to be reviewed in detail and documented in a BIRD.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
