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> 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
Phone 303.449-2308 <(303)%20449-2308>
Mobile 303.335-6156 <(303)%20335-6156>
