Re: [IBIS] Question regarding V-t tables

Arpad:

There are several implications and threads with respect to
the original question and proposed solutions. Data dependent
results in (2) seem to indicate pre-emphasis/de-emphasis
which can be modeled by current switching or [Driver Schedule]
approximations or *-AMS formulations instead of waveform
selections. So I question whether (2) is even a good approach
vs alternatives.

Regarding (1) the specification has holes in it based on
non-practical situations. Yes, we could document a few more
restrictions, if they are really issues in industry. However,
our efforts might be better spent on other things.

For fun, the file at the end is legal and passes ibischk4
with zero errors and warnings as a Version 2.1, 3.2 and 4.0
IBIS file. So what is wrong with it? I wonder what EDA
tools do with it.

Bob

Muranyi, Arpad wrote:

> Bob,
>
> I understand your point. It is usually better to think
> positively than negatively. However, some times it is
> necessary to establish rules to limit the possibilities
> of mistakes. Think about the stop sign situation. It
> is a very negative thing!!! You cannot speed through
> the intersection at your convenience. You MUST stop.
> But how many lives did it save? Probably a lot...
>
> So the question I am asking is twofold:
>
> 1) Should we leave the IBIS spec as it is and leave
> the potential open for making (bad) models with repeated
> Rfixture/Vfixture parameters, or should this be declared
> illegal with a statement in the spec, so that such models
> could be flagged by the parser before they are released?
>
> I know, tools may have their own protection mechanisms
> to guard themselves against situations like this, but at
> that point it is too late, the model may be bad, or may
> have intentions for which the tool doesn't have the
> proper algorithms. It may be better to prevent this
> from happening at the earliest stage, when the model is
> being made.
>
> 2) If we decide to leave the spec as it is and allow
> this, should we add new subparameters to the waveform
> keywords to specify how this kind of data is intended
> to be used by the simulator? For example, use Waveform_1
> when the data pattern is 10101010, use Waveform_2 when
> the data pattern is 11001100, use Waveform_3 when it is
> 111000111000, etc...
>
> Arpad
> =======================================================

[IBIS Ver] 4.0
[File Name] zero.ibs
[File Rev] 0.0
|
[Component] ZERO
[Manufacturer] Zero
[Package]
R_pkg 0.0 NA NA
L_pkg 0.0 NA NA
C_pkg 0.0 NA NA
|
[Pin] signal_name model_name
0 zero Zero
|
[Model] Zero
Model_type I/O
Vinh = 0
Vinl = 0
Vmeas = 0
Rref = 0
Vref = 0
|
C_comp 0 NA NA
[Voltage range] 0 NA NA
|
[Pulldown]
0 0 na na
1 0 na na
|
[Pullup]
0 0 na na
1 0 na na
|
[Ramp]
| typ min max
dV/dt_r 1f/1.0f NA NA
dV/dt_f 1f/1.0f NA NA
|
[Rising Waveform]
R_fixture=0
V_fixture=0
0 0 na na
1f 0 na na
|
[Rising Waveform]
R_fixture=0
V_fixture=0
0 0 na na
1f 0 na na
|
[Falling Waveform]
R_fixture=0
V_fixture=0
0 0 na na
1f 0 na na
|
[Falling Waveform]
R_fixture=0
V_fixture=0
0 0 na na
1f 0 na na
|
[End]

-- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993