[ibis-macro] Re: Example BIRD 158 .ami file

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "Bob Miller \(APD\)" <bob.miller@xxxxxxxxxxxx>
  • Date: Tue, 10 Jan 2017 17:50:00 -0500 (EST)

Bob,



Re technical comment,



This was one of the major issues that SiSoft and Keysight had to work out. 
We each had customers who took different approaches on how to generate the 
Touchstone file. Each of the customers of course thought that they were 
doing it the only correct way. This is the solution that we came up with 
that made everyone happy.



Walter



From: Bob Miller (APD) [mailto:bob.miller@xxxxxxxxxxxx]
Sent: Tuesday, January 10, 2017 5:44 PM
To: Walter Katz <wkatz@xxxxxxxxxx>
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: Re: [ibis-macro] Example BIRD 158 .ami file



...and here's a technical comment about 158.4:



I'd like to point out that the use of Tx_R (R1 an R2 in the transmitter 
circuit diagram) and Rx_R (R3 and R4 in the receiver circuit) are rendered 
irrelevant if their respective termination model touchstone files 
incorporate them behind impedance-isolating ideal buffers, also within the 
touchstone models. Perhaps requiring the model maker to do so (takes a lot 
of head-scratching on the Tx side) is not worth the benefit of eliminating 
Tx_R and Rx_R, but I like not caring what these parameters are set to (My 
channel simulates the same if they are defaulted to 50 ohms or set to 0.1 
ohms.)



But doing so would also eliminate the resistors in the pesky "analog 
models". The EDA tool merely drives the Tx algorithmic model out value 
(scaled by Tx_V) between port1 and port3 of the tx s4p model and passes the 
difference between port2 and port4 in the Rx termination s4p directly to the 
Rx model.



Regards,



Bob



On Tue, Jan 10, 2017 at 3:17 PM, Bob Miller (APD) <bob.miller@xxxxxxxxxxxx 
<mailto:bob.miller@xxxxxxxxxxxx> > wrote:

Comrades-



[ am somewhat late to this renewed discussion and if there is another active 
discussion thread point me to it/include me in it.]



From a model maker/support standpoint, I have long had difficulty 
maintaining a robust model manufacturing workflow which keeps the .ibs file 
sync'ed with the AMI model. When first developed, Tstonefile (e.g. the 
AMI-centric approach) allowed me to produce an analog model as precise as I 
wished while also pulling all of the critical modelling details into one 
place.



Our .ibs files tend to pair Tx and Rx, which complicates the forward 
propagation of changes to either's analog model. (Yes there are ways to 
accommodate this but it's Yet Another Thing To do.) Having the analog model 
definition concisely wedded into the .ami file (which resides within the ami 
model's directory, revision control, etc. was simply too convenient to 
abandon, especially after being used to build a small army of models we 
continue to support customers on. So I have contributed to this 
"bifurcation" in analog model approach.



I personally think its time to just "punt" and accept both methods. I 
understand the reasons why the termination models should rightfully be 
specified in the .ibs file, but the truth is it's easier to specify them in 
the AMI file and the pain of changing is great enough that I'd have to be 
pretty much forced to change (say by a customer demand to run their models 
on a non-Tstonefile EDA tool) to make the change. And the longer we let 
Tstonefile, whose users are probably NOT going away, be "unsupported" we 
risk drifting even further apart (If I as a model maker can't use your tool 
I will care less deeply whether your tool supports some other cool new 
feature).



Anecdote: Avago recently merged with Broadcom and our modeling groups were 
delighted to find out we both use Tstonefile.



Completely non-technical argument, I know!! Let's just patch up the status 
quo and agree to hang together better in the future.



Regards,



Bob



On Tue, Jan 3, 2017 at 2:11 PM, Walter Katz <wkatz@xxxxxxxxxx 
<mailto:wkatz@xxxxxxxxxx> > wrote:

All,



The enclosed zip file contains an IBIS file, .ami files and .mod files  that 
implements the proposed BIRD 158 with [External Model] syntax that allows an 
EDA tool to use the AMI parameters directly to generate Impulse Response in 
the frequency domain and allow EDA tools that do not support BIRD 158 
parameters to use the [External Model] syntax. BIRD 158.4 is also enclosed.



As written, BIRD 158.4 does not require that the IBIS file has the [External 
Model] statements that are shown in the .ibs file example.



Also, the Receiver and the Transmitter Circuit should have the earth ground 
symbol replaced with the local ground symbol.



Walter



Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>

Phone 303.449-2308 <tel:(303)%20449-2308>

Mobile 303.335-6156 <tel:(303)%20335-6156>





Other related posts: