Ed,
You raised a bunch of very good questions...
OK, class is over, see you next week. :)
-------------------------------------------
More seriously, here is how I see things:
#1) I agree that there is not enough material out there for IBIS modeling,
not to mention IBIS-AMI modeling. Part of the problem is that the IBIS
committees are way too over loaded with work on corrections and improvements
to the spec (BIRDs) and we are even behind in those areas, and our people
are doing this all on volunteer bases. There is simply not enough time for
us to develop IBIS cookbooks and the like to teach model makers and users
how to do things. However, model makers could also do a little better on
providing documentation for their customers on how to use the model properly...
But I am sure they are also under a lot of time pressure imposed by their
company goals and competitors...
#2) Model makers should test their models in multiple tools to make sure
it works. If they do not have all the tools in house, they can hopefully
get someone at the EDA vendor's side to try it out for them and provide
feedback. My company is very supportive of these requests, and this helps
all of us. The model maker will be happy to find out if their model works,
or get professional feedback if something is not working properly, and we
get more test cases to test our tools and potentially fix bugs in our tools
if we find some. But this is not always an easy road to travel.
Occasionally I have bad experiences with model makers because they claim
that their model works in other tools so if it doesn't work in our tool
than our tool must be wrong. More often than not it turns out that they
were not aware of some details in the specification and their model is
actually not spec compliant. The fact that the model works in another
tool might actually indicate that the other tool might not be fully spec
compliant. This is when the messy arguments begin, and sometimes it is
impossible to get closure because they are not willing to change their
model since it works in the tool they are "married to". Then the question
is, should we "adjust" our tool to these non-compliant models and EDA
competitors, or remain spec compliant? What if someone else writes a
model that follows the spec correctly? Then we would need a GUI button to
select the spec compliant mode or the XYZ tool/model compliant mode.
Why do we have a spec then? Hmmm...
#3) That might be a nice thing, but it doesn't belong to the specification
or any of the IBIS committees. Maybe a third party policing agency should
be set up for this purpose... :) But keep in mind that AMI modeling requires
several different skills which not too many people have. For one, you need
to be a good electronic engineer, and be familiar with signal processing
algorithms. In addition, you also need to be a good programmer, so that
you can implement these signal processing algorithms, not only that but do
it efficiently that it would execute fast, and then do it right so that there
are no memory leaks, divide by zero operations, and the like. Not an easy
assignment for a newbie...
#4) This is an interesting question and it actually applies to the good old
SPICE transistor modeling as well. Most programming languages, including
SPICE, provide nice conveniences for their user, such as global variables,
parameters or global nodes. These are nice conveniences, especially for
novice users, but there is a heavy price. If you make a parameter or node
global in one model, the other model will see it too. That when the fun
begins, and you won't know what hit you. This applies to IBIS-AMI too. Part
of the answer goes back to the previous question, the model maker has to know
what they are doing, and that includes knowing how what they are doing could
affect what others are doing.
Like I said above, not all of these issues can be (or should be) addressed
in the IBIS specification. You can get a driver's license by learning how
to read all the traffic signs and what the traffic rules are, but does that
make you a good driver? Not necessarily, even if you pass the driving test.
Is it the job of the books explaining the traffic signs/rules to teach anyone
how to be a good driver? I don't think so...
Regarding Matlab, I have seen quite a few AMI models written in Matlab in
the early days of IBIS-AMI. But these required the Matlab run-time to be
installed, and these models were notoriously slow. It seems that people
came to realize that this is not the way to go. But I also hear that some
people develop their algorithms in Matlab first and then they translate it
to raw C, C++ or something similar to get better performance.
That's all I can think about now...
Thanks,
Arpad
================================================================================
From: Ed Sayre [mailto:esayre@xxxxxxxx]
Sent: Wednesday, June 10, 2015 9:01 PM
To: Muranyi, Arpad; ibis@xxxxxxxxxxxxx
Subject: RE: Flexibility of a specification
Arpad and fellow IBIS workers:
I agree with your comments about future developments. However, I have a couple
of pertinent questions for you and other IBIS pioneers:
1. How do we use what we have to evaluate channel and driver/receiver
designs when there is so little in the use of user guides?
2. How do we deal with models that don't run at all or models that run on
one simulation engine but not another?
3. Can we define the qualifications of model makers since it seems the
quality of the model depends heavily on the experience of the model maker and
what they know about how devices actuall work?
4. How do we deal with models that run alone but not with another model,
i.e., interoperability?
I find these questions not addressed in any of the the IBIS documents.
As an alternate, the COM tool and Stat-eye, which are MatLab based tools, seem
to have certain limitations as well when the Tx and Rx analog behavior behavior
are included in the simulation. Do you see that semiconductor manufacturers
are going to provide MatLab based behavioral models?
ed
