[ibis-macro] Re: SiSofts Official Position on BIRDS 116-125 ...
- From: Taranjit Kukal <kukal@xxxxxxxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 11 Feb 2011 09:59:53 +0530
Hi Walter,
I have one comment on item 3). Why do we need special referencing to ISS
Package Model - can't that be wrapped into Analog Buffer Model as subckt inside
of Main subcircuit of Analog buffer?
As per BIRD125, Package model section would have reference to ISS package and
that is the model to be used as default and if some if-then is required, then
the model should be sub-model of main subcircuit in [EXTERNAL MODEL] and that
would be covered by your item 2)
Am I missing something?
Rgds
..kukal
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Thursday, February 10, 2011 12:01 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] SiSofts Official Position on BIRDS 116-125 ...
All,
After reviewing all of the discussion on BIRDS 116-125, I have come to the
following conclusions
1. Requiring the unity gain model inside ISS Analog Buffer models is
acceptable to SiSoft. We will support any consensus within the ATM committee
and the Open Forum.
2. We will modify BIRD 122 to support the AMI file referencing ISS Analog
Buffer Models directly.
3. We will modify BIRD 122 to support the AMI file referencing ISS
Package Models directly.
I think this is a good time to revisit a decision that was made three years ago
about how AMI Models were referenced in the .ibs file. In review, a typical AMI
section in an IBIS file might look like:
[Algorithmic Model]
Executable Linux_gcc3.4.6_64 tx.linux64.dll tx.ami
Executable Linux_gcc3.4.6_32 tx.linux32.dll tx.ami
Executable Windows_VisualC++2008_32 sb_tx.win32.dll tx.ami
[End Algorithmic Model]
Suppose instead the interface was
[Advanced Model]
AMI_File tx.ami
[End Advanced Model]
And the .ami file had a reserved parameter "AMI_Model_Type", and the .ami file
also contained reserved parameters that would have as values the names of the
DLL files.
With this structure, one can simply declare new following new AMI_Model_Type
values:
SerDes_Tx
SerDes_Rx
SerDes_Repeater_Rx
SerDes_Repeater_Tx
ISS_Tx
ISS_Rx
VHDL-AMS
Verilog-AMS
SPICE
And use the power of the .ami language to define the interface to the Model.
In short, we get around the issues of Typ, Min, Max and inability for IBIS to
adapt to changing requirements by using the Advanced Modeling Interface as
method of interfacing to the latest technologies, and we have a simple method
of adopting as standard, by promoting the AMI parameters that define the
interface to these new models as Reserved Parameters.
I think this approach is the correct one, and I think that the IC Vendor and
System Design community that use IBIS models would recognize that this is the
path for IBIS to become more relevant for the demanding needs of the users of
models for non SerDes Algorithmic Models.
We will accept any consensus within the ATM committee and the Open Forum
regarding defining the interface to package and buffer analog ISS subckts in
the existing .ibs file, as long as it also supports the ability to make these
interface definitions in the .ami file.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.883-2120
Other related posts:
