Subject: Re: BIRD30 Prog. Buffers Comment

From: [email-masked] ( Bob Ross)
Date: Wed, 6 Sep 95 13:00 PDT

Jon:

My view is that the selection of various buffer types would be done through
a user interface extension for the simulator.  It could be directly based
on model names associated with the [Model Selector] name or by some other
method based on using the description information.  The user would have
to set up the mapping if it differs from the default.

The default pin mapping will be set up.  The user would have to modify
the IBIS file to change the default mapping.

Any non-default mapping selection done within the IBIS file would require
editing the file.  Therefore the selection method needs to be external
to the IBIS file.  I do not know of any way to standardize on this for 
a variety of whatif and semiautomatic selection applications.

Bob Ross,
Interconnectix, Inc.

> How does one control the selection of the various buffer types?

> It seems that it would be important to provide a mechanism that allows
> simple programmable selection of output types. If this is not provided then
> the user will be forced to create a unique IBIS file that has the actual model
> mapping that was decided. Even if you "leave this up to the tool vendors" the
> user will still have to, effectively, create their own pin map file.

> regards,
> jon

---

From: [email-masked]
Date: Wed, 06 Sep 95 14:57:31 PDT

Hi Bob, Jon and Ibisans,

As you may recall from the BOF meeting at DAC this topic of 
different strength, speed, you name it, I/O cells is a topic
that has been troublesome already to me in my short time applying
IBIS modeling to real world designs..

I think that the mechanism proposed in Bob's last posting works
if the simulator UI's can be coerced into it. I like this one:

Bob sezz..,

>Comments could provide a description of the buffers if they are no clear
>from the name.  An alternative is to have another column required column
>for describing such buffers, similar to "signal_name in the [Pin] keyword:
>
>The description would not be standardized since there are many ways to
>differentiate models.  The simulator could display the description and
>could optionally base a selection mechanism on the description.  This
>syntax would then have two columns for each model for consistency.

If I understand this correctly the way to use this is as follows:
(I pirate freely from Bob's post)

[Component]     PROGRAMMED_PART
[Manufacturer]
[Package]
| variable      typ             min             max
R_pkg           0.0m            NA              NA
L_pkg           0.0nH           NA              NA
C_pkg           0.0pF           NA              NA
|
|***************************************************************
|
[Pin]           signal_name     model_name      R_pin   L_pin   C_pin
1               OUT_1             Progbuffer2
2               OUT_2             Progbuffer1
3               OUT_3             Progbuffer2
4               OUT_4             Progbuffer1
|
|
[Model selector]             Progbuffer1
|   model name               description
    ABCD0123456789ABCDE2     SS3.3              | the default
    ABCD0123456789ABCDE0     WS3.3
    ABCD0123456789ABCDE1     WF3.3
    ABCD0123456789ABCDE3     SF3.3
    ABCD0123456789ABCDE4     SF3.3_OD
|
[Model selector]             Progbuffer2
|   model name               description
    ABCD0123456789ABCDE3     SF3.3              | the default
    ABCD0123456789ABCDE0     WS3.3
    ABCD0123456789ABCDE4     SF3.3_OD
    ABCD0123456789ABCDE5     SF5.0
    ABCD0123456789ABCDE6     SF5.0

Of course a list of the models in IBIS syntax would follow. 
  
I would hope the simulator UI would bring up a list of the model names
available for the given pin, complete with the description, so that the
user would merely point and shoot at the desired model to be used for
that particular simulation.

I think the first one in the list after the [Model selector] should
automatically be the default. Saves making more keywords.

Am I in the ballpark on the usage model? I think this can work also for
a "whatif" mechanism for ASIC's and glue logic too! One of the problems
I have encountered is that currently if a [Model] isn't referenced by
a [Component] then it doesn't get loaded and so is not available for
"whatif" experiments(more than one vendor's sw exhibits this). This is
a neat way around that.

Thanks,

Brock Hannibal
HW Design Engineer
Tektronix, Inc.

---

From: [email-masked] (Jon Powell)
Date: Wed, 6 Sep 95 15:58:00 PDT

I guess I would like to tie the model into the physical selection mechanism.

For instance, if the output strength is tied to the state of an input pin PROG
I would like the user to be able to say PROG=1 and the IBIS model know what that
means. This would mean that the [Model Selector] choices would be tied to selection
values (Physical or Logical)

If these things are programmed by JTAG shift registers, maybe we should use the JTAG
input file description or some derivative. 

By the way, this only sounds complex, the implementation could be as simple as C
#ifdef statements.

What do the IC vendors have to say about strength selection?

regards,

jon

---

From: [email-masked]
Date: Wed, 06 Sep 95 17:34:28 PDT

Hi guys,

The problem with tying the selection of strength, speed, whatever to a
physical thing on the part is that sometimes its an internal register
that the board designer really has no visibility of. The software guys
may program it, the part designer may have hardwired it through a 
fuse(PAL), the internal programming of the PLD may select it. It's
hard to say what information about the part(if any) will tell us which
[Model] to select. 

It would be nice if we had some kind of automatic selection but it
doesn't appear to me that the appropriate information is available in
the IBIS model or from the board database. A Verilog or VHDL simulation
of the system might or might not contain the salient info. The software
might contain the appropriate information, as might the firmware. I don't
see a clear path to linking the analog I/O behavioral simulation to the
logic simulation or the software/firmware. 

Brock Hannibal
HW Design Engineer
Tektronix, Inc.