[ibis-macro] Re: SiSoft's Official Position on BIRDS 116-125 ...
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 11 Feb 2011 06:57:26 -0800
Walter,
This caught my eyes:
"the EDA tool must be able to output the characteristic of the channel
(typically insertion loss, return lose, and ICR of the channel that
needs to include the package model at both ends, but exclude the analog
model of the Tx and Rx"
I thought that having a channel model without the Tx and Rx
models would not be useful for much, since the reflections
at the end of this kind of a channel would be completely
incorrect. Why do you say that an EDA tool would also be
able to do this?
Thanks,
Arpad
================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, February 11, 2011 7:35 AM
To: 'Taranjit Kukal'; 'IBIS-ATM'
Subject: [ibis-macro] Re: SiSofts Official Position on BIRDS 116-125 ...
Kukal,
You are correct, but you are not considering several important points.
The AMI Buffer analog model is written by the IC designer (or the IP
provider) of the SerDes buffer. He can generate the analog model for the
buffer, but he does not design the package that the silicon is being
used. Further, the same chip can be used in multiple package
configurations. The package model is then built by a different
individual with different tools. Secondly, the EDA tool must be able to
output the characteristic of the channel (typically insertion loss,
return lose, and ICR of the channel that needs to include the package
model at both ends, but exclude the analog model of the Tx and Rx.
Including the package model with the IC analog model makes this
problematic.
Walter
-----Original Message-----
From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx]
Sent: Thursday, February 10, 2011 11:30 PM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] SiSofts Official Position on BIRDS 116-125 ...
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
Phone 303.449-2308
Mobile 303.883-2120
Other related posts:
