Eckhard then turned the presentation over to Dr. Christian Sporrer, who has implemented the first steps of the IQC.
Christian continued with an overview of the implementation. There is an IQC library, which contains functionality form computational tasks as well as executables with IBIS checks and datasheet checks. The checker will make usage of plug-in modules by using encapsulation. This means that the check does not work directly, but will use methods. He then explained the structure of both the parameter file and the configuration file. They are grouped into 5 sections: package, pin, model general, model specific and data sheet.
The configuration file will contain more general parameters for a first basic model check, while the parameter file will contain more specific or more restrictive values/checks. He explained these files with two examples. He then showed an overview of the File I/O methods in the IQC library. There are different files with different methods for checking the models, but the names of these methods should be self explanatory. Examples are getconfigurationvoltage, gettolerance (which will check for the tolerance of the power supply) and getibispinlist.
The computing methods are the computational part of the check with names like compareValues(), checkRampOrder() and countModels(). On the next slide he showed the checks that are already implemented in the IQC demonstrator. They contain section A (package), section B (pins), section D (models) and section E (datasheet). Afterwards, he explained how a new check could be added to the IQC. Everything should be implemented as methods for a high level of reuse as well as a high level of modularity. At the end he showed an excerpt of the Perl program with the voltage check plug-in.
In the summary he pointed out that the IBIS Quality checklist would only have a chance if most of it can be automated; the benefits are clear, but no one has started using it yet. There will be a lot of work to do to implement the tool if all checks are to be included at once. He suggested that this should be done step by step and invited everybody to help out.
The first question was whether a vendor will support the configuration and parameter files. It was answered that there won’t be any problems concerning the confidential aspects, but the use of these files is user dependant, so usually the files will have to be application specific.
Another observation was that the user normally doesn’t want to do these checks, and that everything should be shifted to the vendor. Will this be possible? Christian answered that the advantage of the IQC would be that, not only the will the parser checks be fulfilled (with the IBIS parser), but also, additional quality checks will be accomplished. But, of course, a reference platform for model checks would be fine. By giving the vendor a reference platform they will get good information on how to check the models beyond the IBIS parser and checklist, because the model in-sourcing can only be done when the supplier delivers a good model. Christian pointed out that it might be possible to deliver to the customer an application specific model, which then will work explicitly for this costumer, but that this also might lead to additional costs.
The last observation was that a check of the curves is also very important, and that this might be the trickiest part to do.