driver schedule clarifications

Steve:

You asked some good questions and I am responding to the ibis reflector
per our discussion. These were discussed at the February IBIS Open
Forum meeting.

My responses are in your text IN UPPERCASE.

Bob Ross
Mentor Graphics

Date: Thu, 25 Mar 1999 15:59:49 -0800
To: arpad.muranyi@intel.com, bob_ross, mbflora@hyperlynx.com
From: Steve Kaufer <stevek@hyperlynx.com>
Subject: driver schedule clarifications
Cc: dc.sessions@tempe.vlsi.com

Hi Everyone,

Here's a summary of the issues relative to [Driver Schedule] that
HyperLynx
is looking for clarification on in tomorrow's meeting. Matt Flora will
be
attending for us (and basically listening for the answers). For issues
#1
and #2, I've listed the cases that I've heard argued in favor of. I've
used
the (probably bad) term "sub-model" to refer to models that are not at
the
top level but are added by / referred to in the [Driver Schedule] table.

***1) If [Driver Schedule] is used, is a top-level model required? If
so,
how is it used?

Case #1: Yes, a top-level model is required, but it represents a
"combined"
model that only approximates the behavior of the set of models used by
[Driver Schedule]. If the target simulator supports [Driver Schedule],
the
top-level model is not used; all of the models in the [Driver Schedule]
table are "sub-models." If the simulator does NOT support [Driver
Schedule], it may use the top-level model as an approximate fallback.

THIS IS THE CORRECT ANSWER. A SIMULATOR THAT DOES NOT SUPPORT [DRIVER
SCHEDULE] WILL PROBABLY REPORT A SYNTAX ERROR. THE USER CAN THEN DELETE
THE [DRIVER SCHEDULE] KEYWORD AND RELATED LINES AND GET AN "APPROXIMATE
RESPONSE".

Case #2: Yes, a top-level model is required. It is the "t=0ns" or
first-switching model for each transition. Later-switching models in the
table are "sub-models."

NOT THE CORRECT INTERPRETATION

Case #3: No top-level model is required. I.e., the I-V tables that would
normally appear at the top level may be omitted entirely in favor of
data
contained only in "sub-models."

A TOP-LEVEL MODEL IS REQUIRED

***2) Do models that are turned on in one transition carry over, still
turned on, into the opposite transition?

Consider the following example; assume a rising transition at t=0ns and
a
falling transition at t=10ns:

> | Model_Name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly
> |
> stage1 0.0ns NA 0.0ns NA
> stage2 1.0ns NA 4.0ns NA
> stage3 2.0ns NA 8.0ns NA

Case #1: No, there is no carry-over. If there was, sourcing and sinking
buffers would be "fighting" each other. So the following events occur:

time event
-----------------
0ns stage1 turns on high
1ns stage2 turns on high
2ns stage3 turns on high
10ns falling edge begins; all high stages turn off
          and stage1 turns on low
14ns stage 2 turns on low
18ns stage 3 turns on low

INCORRECT

Case #2: Yes, there is carry-over. The following events occur:

time event
-----------------
0ns stage1 turns on high
1ns stage2 turns on high
2ns stage3 turns on high
10ns stage1 turns on low;
          stage2 and stage3 stay on high
14ns stage 2 turns on low
18ns stage 3 turns on low

CORRECT INTERPRETATION. THE WAY TO LOOK AT THIS IS TO THINK OF A MASTER
"CLOCK" WITH A RISING EDGE AND A FALLING EDGE. THE RISE_ON_DLY AND
RISE_OFF_DLY
ARE RELATIVE TO THE RISING EDGE. THE FALL_ON_DLY AND FALL_OFF_DLY ARE
RELATIVE TO THE FALLING EDGE.

***3) Miscellaneous wording changes and clarifications proposed by Matt
Flora.

On question ***1, HyperLynx doesn't care what the answer is. Having a
"fallback" top-level model sounds nice, but I suspect semiconductor
modeling folks won't want to create it and that it won't be accurate
enough
for real use.

YOU MAY BE CORRECT. THIS IS REALLY A STUB.

On question ***2, the Case#1 interpretation is simpler, and so we'd
prefer
it if all else was equal. But the question should really be answered by
the
semiconductor people who know what kinds of buffers are actually being
built. One vendor creating multi-stage output cells told me that theirs
matches Case#1. If Case#2 is the true intent, then how would an output
cell
that behaved like Case#1 be represented?

YOU WOULD USE "0" FOR THE FALL_OFF_DLY ENTRIES.

Regards,

Steve Kaufer,
HyperLynx
17641 N.E. 67th Court
Redmond, WA 98052
tel: 425-869-2320
fax: 425-881-1008
e-mail: stevek@hyperlynx.com
Received on Mon Mar 29 17:57:21 1999