Subject: [IBIS-Users] Re: Driver schedule interpretation.
From: Angulo, John (john_angulo@mentorg.com)
Date: Thu Jan 29 2004 - 19:04:12 PST
The following is posted on behalf of Itzik Peleg at Marvell. Please send any private replies to itzikpe@il.marvell.com.
-----------------------------------
Hello Arpad
Thank you for the quick replay.
Sorry that I have to ask again since in the BIRD 84.1a that you sent me
the only real difference from the BIRD publish in the IBIS web site is
the corrected wave form (I agree that the correction is needed).
But,
In the last paragraph that include the example the first sentence is:
If "event" was defined as the expiration time of the delay, the delay would
be allowed to run its course, and we would see a rising edge on the output ...
Which tell me that this is the opposite example since the word "event"
doesn't define like that.
The word "event" is defined:
| ... the word "event" refers to
|** the moment in time when the delay is triggered by the
|** stimulus. ...
And further more If the correct answer to my first question is 2 then
you are allowing the "delays" to take their own course without
regarding to the stimulus. This thing isn't desire and said explicitly
In the BIRD " IF "event" ... the delay would be allowed to run its course".
Real buffers correspond to their stimulus and they don't have a "memory"
of previous edges.
According to all of that my understanding is that:
The Rise_on_dly and Rise_off_dly are relative to the Rising edge or
rising "event".
The Fall_on_dly and Fall_off_dly are relative to the Falling edge or
falling "event".
In case that there was an "event" of rising the rising delay apply. If
another "event" happen then the delays start over according to the
corresponding "event" any other delays left from previous cycle will be
canceled.
This is my understanding of this BIRD. Am I got this wrong ?
If yes others have done the same (at least one EDA vendor) Please
consider to rephrase this BIRD and
It would be much appreciated if you give a simple positive example to
illustrate the driver schedule correct implementation.
Thanks in advance.
Itzik,
Muranyi, Arpad wrote:
>Itzik,
>
>The short answer is that #2 should happen.
>
>Reason: The "NA" in the fall_on_dly and fall_off_dly columns
>mean that the falling edge will not trigger anything. Keep in
>mind the meaning of an "NA" is not the same as zero delay. "NA"
>stands for information is not available, therefore you can't
>so anything because you don't know what to do.
>
>You may also look at BIRD 84.1 at
>
>http://www.vhdl.org/pub/ibis/birds/bird84.1.txt
>
>which attempts to clarify some of these issues. The problem is
>that there is a minor, but confusing error in the BIRD. The
>drawing on the bottom should show the output's falling edges
>right under the input's rising edges. I am sending you a fixed
>version of the BIRD in the attachment, which I hope we will
>post on the IBIS web site shortly.
>
>I hope this helps,
>
>Arpad Muranyi
>Intel Corporation
>===============================================================
>
>-----Original Message-----
>From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]
>Sent: Wednesday, January 28, 2004 1:24 AM
>To: owner-ibis-users@eda.org
>Subject: BOUNCE ibis-users@eda.org: Non-member submission from [Itzik
>Peleg <itzikpe@il.marvell.com>]
>
>To: "ibis-users@eda.org" <ibis-users@server.eda.org>
>Subject: Driver schedule interpretation .
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Hello IBIS Users
>
>This question regarding the interpretation of driver schedule keyword.
>I have made a model using driver schedule keyword. the model is working
>fine using one simulation tool.
>and don't working (give a completely massy weave form) in another
>simulation tool.
>When applying to the simulation tool vendor to get his response (and
>after some more emails).
>I realize that the driver schedule is interpreted differently in the two
>
>simulations tool.
>The major difference can be summarize by this question:
>
>When using the [Driver schedule] keyword for example:
>
> [Driver Schedule]
> |
> | Model name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly
> Out_model 0n 10n NA NA
>
>
>When the stimulus start rising the model is activated (the pullup of
>Out_mode get to on state etc')
>If 5ns after the rising of the stimulus, the stimulus have a falling
>edge.
>
>Here is the question: What will happen 1 or 2 ?
>
>1. The pullup of Out_model will get into off state (turn off) at 5ns
>since the stimulus is falling .
> at 10ns nothing will happen since the pullup is in off state
> (the rise_off_dly has been canceled by the falling stimulus).
>
>2 The pullup of Out_model will stay in on state (turn on) at 5ns.
> at 10ns the pullup of Out_model will go into off state since the
>Rise_off_dly time has come.
> (the rise_off_dly isn't canceled by the falling stimulus).
>
>
>I want an answer by the IBIS committee which will guide how this keyword
>
>should be interpreted in order
>that the model maker can make models that will be interrupted correctly
>by the EDA tools vendors.
>
>Regards
>
>Itzik Peleg
>Board Technology Group
>
>
>Marvell Semiconductor Israel Ltd
>Moshav Manof, D.N. Misgav 20184, ISRAEL
>Email - itzik.peleg@il.marvell.com
>Tel - +972 4 9951192
>Cell - +972 54 452482
>Fax - +972 4 9951902
>WWW Page: http://www.marvell.com
>========================================================================
>This message may contain confidential, proprietary or legally privileged
>
>information. The information is intended only for the use of the
>individual
>or entity named above. If the reader of this message is not the intended
>
>recipient, you are hereby notified that any dissemination, distribution
>or copying of this communication is strictly prohibited. If you have
>received this communication in error, please notify us immediately by
>telephone, or by e-mail and delete the message from your computer.
>
>Thank you!
>========================================================================
>
>
>
>
>
>------------------------------------------------------------------------
>
>*****************************************************************************
>*****************************************************************************
> BUFFER ISSUE RESOLUTION DOCUMENT (BIRD)
>
>BIRD ID#: 84.1
>ISSUE TITLE: Driver Schedule Clarifications
>REQUESTOR: Arpad Muranyi, Intel Corporation
>DATE SUBMITTED: September 30, 2003
>DATE REVISED: November 21, 2003
>DATE ACCEPTED BY IBIS OPEN FORUM: Pending
>
>*****************************************************************************
>*****************************************************************************
>
>STATEMENT OF THE ISSUE:
>
>The language describing the [Driver Schedule] keyword in the IBIS 4.0
>specification is ambiguous and can lead to conflicting simulation results.
>Two areas need to be corrected.
>
>a) The usage rules of [Driver Schedule] describe in detail which of the
>keywords in the top-level and scheduled models should be used, but fails to
>mention what should happen with the subparameters of the [Model] keyword,
>except for C_comp. No usage rules are specified for the remaining
>subparameters: Model_type, Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref,
>Vref.
>
>b) The usage rules of the four delay parameters, Rise_on_dly, Rise_off_dly,
>Fall_on_dly, Fall_off_dly use the word "event" without defining what it
>means. Since "event" could refer to the stimulus that triggers the delay
>as well as the moment when the delay expires, there is an ambiguity in the
>usage rules regarding how tools should handle certain timing conditions.
>
>*****************************************************************************
>
>STATEMENT OF THE RESOLVED SPECIFICATIONS:
>
>Changes are marked with the * characters.
>
>|============================================================================
>| Keyword: [Driver Schedule]
>| Required: No
>| Description: Describes the relative model switching sequence for referenced
>| models to produce a multi-staged driver.
>| Usage Rules: The [Driver schedule] keyword establishes a hierarchical order
>| between models and should be placed under the [Model] which
>| acts as the top-level model. The scheduled models are then
>| referenced from the top-level model by the [Driver Schedule]
>| keyword.
>|
>| When a multi-staged buffer is modeled using the [Driver
>| Schedule] keyword, all of its stages (including the first
>| stage, or normal driver) have to be modeled as scheduled
>| models.
>|
>| If there is support for this feature in a EDA tool, the
>| [Driver Schedule] keyword will cause it to use the
>| [Pulldown], [Pulldown Reference], [Pullup], [Pullup
>| Reference], [Voltage Range], [Ramp], [Rising Waveform] and
>| [Falling Waveform] keywords from the scheduled models
>| instead of the top-level model, according to the timing
>| relationships described in the [Driver Schedule] keyword.
>| Consequently, the keywords in the above list will be ignored
>|* in the top-level model. All of the remaining keywords not
>|* shown in the above list, and all of the subparameters will
>|* be used from the top-level model and should be ignored in
>|* the scheduled model(s).
>|
>| However, both the top-level and the scheduled model(s) have
>| to be complete models, i.e., all of the required keywords
>| must be present and follow the syntactical rules.
>|
>| For backwards compatibility reasons and for EDA tools which
>| do not support multi-staged switching, the keywords in the
>| above list can be used in the top-level [Model] to describe
>| the overall characteristics of the buffer as if it was a
>| composite model. It is not guaranteed, however, that such a
>| top-level model will yield the same simulation results as a
>| full multi-stage model. It is recommended that a "golden
>| waveform" for the device consisting of a [Rising Waveform]
>| table and a [Falling Waveform] table be supplied in the
>| top-level model to serve as a reference for validation.
>|
>| Even though some of the keywords are ignored in the scheduled
>| model, it may still make sense in some cases to supply
>| correct data with them. One such situation would arise when a
>| [Model] is used both as a regular top-level model as well as a
>| scheduled model.
>|
>| The [Driver Schedule] table consists of five columns. The
>| first column contains the model names of other models that
>| exists in the .ibs file. The remaining four columns describe
>| delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and
>| Fall_off_dly. The t=0 time of each delay is the event when
>| the EDA tool's internal pulse initiates a rising or falling
>| transition. All specified delay values must be equal to or
>| greater than 0. There are only five valid combinations in
>| which these delay values can be defined:
>|
>| 1) Rise_on_dly with Fall_on_dly
>| 2) Rise_off_dly with Fall_off_dly
>| 3) Rise_on_dly with Rise_off_dly
>| 4) Fall_on_dly with Fall_off_dly
>| 5) All four delays defined
>| (be careful about correct sequencing)
>|
>| The four delay parameters have the meaning as described
>| below. (Note that this description applies to buffer types
>| which have both pullup and pulldown structures. For those
>| buffer types which have only a pullup or pulldown structure,
>| the description for the missing structure can be omitted.)
>|
>|** Remove this sentence:
>|** In the following four paragraphs, the word "event" refers to
>|** the time when the delays are triggered.
>|
>| Rise_on_dly is the amount of time that elapses from the
>| internal simulator pulse initiating a RISING edge to the
>| t = 0 time of the waveform or ramp that turns the I-V table of
>| the PULLUP device ON, and the t = 0 time of the waveform or
>| ramp that turns the I-V table of the PULLDOWN device OFF (if
>| they were not already turned ON and OFF, respectively, by
>| another event).
>|
>| Rise_off_dly is the amount of time that elapses from the
>| internal simulator pulse initiating a RISING edge to the
>| t = 0 time of the waveform or ramp that turns the I-V table of
>| the PULLUP device OFF, and the t = 0 time of the waveform or
>| ramp that turns the I-V table of the PULLDOWN device ON (if
>| they were not already turned ON and OFF, respectively, by
>| another event).
>|
>| Fall_on_dly is the amount of time that elapses from the
>| internal simulator pulse initiating a FALLING edge to the
>| t = 0 time of the waveform or ramp that turns the I-V table of
>| the PULLDOWN device ON, and the t = 0 time of the waveform or
>| ramp that turns the I-V table of the PULLUP device OFF (if
>| they were not already turned ON and OFF, respectively, by
>| another event).
>|
>| Fall_off_dly is the amount of time that elapses from the
>| internal simulator pulse initiating a FALLING edge to the
>| t = 0 time of the waveform or ramp that turns the I-V table of
>| the PULLDOWN device OFF, and the t = 0 time of the waveform or
>| ramp that turns the I-V table of the PULLUP device ON (if
>| they were not already turned ON and OFF, respectively, by
>| another event).
>|
>|** In the above four paragraphs, the word "event" refers to
>|** the moment in time when the delay is triggered by the
>|** stimulus. This stimulus is provided to the top-level
>|** model by the simulation tool. The expiration of delays
>|** cannot generate events.
>|
>| Note that some timing combinations may only be possible if
>| the two halves of a complementary buffer are modeled
>| separately as two open_* models.
>|
>| Use 'NA' when no delay value is applicable. For each
>| scheduled model the transition sequence must be complete,
>| i.e., the scheduled model must return to its initial state.
>|
>| No [Driver Schedule] table may reference a model which itself
>| has within it a [Driver Schedule] keyword.
>|
>| Other Notes: The added models typically consist of Open_sink (Open_drain)
>| or Open_source models to provide sequentially increased drive
>| strengths. The added drive may be removed within the same
>| transition for a momentary boost or during the opposite
>| transition.
>|
>| The syntax also allows for reducing the drive strength.
>|
>| Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly,
>| Fall_off_dly parameters are single value parameters, so
>| typical, minimum and maximum conditions cannot be described
>| with them directly. In order to account for those effects,
>| one can refer to the fastest waveform table with the delay
>| number and then insert an appropriate amount of horizontal
>| lead in section in those waveforms which need more delay.
>|
>| Notice that the C_comp parameter of a multi-stage buffer is
>| defined in the top-level model. The value of C_comp
>| therefore includes the total capacitance of the entire
>| buffer, including all of its stages. Since the rising and
>| falling waveform measurements include the effects of
>| C_comp, each of these waveforms must be generated with the
>| total C_comp present, even if the various stages of the
>| buffer are characterized individually.
>|
>| Note: In a future release, the [Driver Schedule] keyword may
>| be replaced by a newer method of specification that is
>| consistent with some other planned extensions. However, the
>| [Driver Schedule] syntax will continue to be supported.
>|----------------------------------------------------------------------------
>*****************************************************************************
>
>ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
>
>a) Since the rules for the C_comp subparameter already state "that the
>C_comp parameter of a multi-stage buffer is defined in the top-level model",
>and the same rule makes perfect sense for the rest of the subparameters,
>this BIRD proposes that a simple language should be added to the usage rules
>to that effect.
>
>b) In order to be consistent with the behavior of over clocked waveform
>tables (Vt curves) it makes sense to define "event" as the time when the
>delays are triggered.
>
>Considering the following timing values:
>
>[Driver Schedule]
>| Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly
> MODEL_OUT 20.0ns 0.0ns NA NA
>
>where the [Model] MODEL_OUT consists of a complementary driver, the above
>definition of "event" will result in a flat line response on the output of
>the buffer as long as the input stimulus pulse is shorter than the
>Rise_on_dly value of 20.0 ns.
>
>In other words, within [Model]s using the [Driver Schedule] keyword there
>are no internally generated events.
>
>*****************************************************************************
>*****************************************************************************
>
>ANY OTHER BACKGROUND INFORMATION:
>
>If "event" was defined as the expiration time of the delay, the delay would
>be allowed to run its course, and we would see a rising edge on the output
>20 ns after the rising edge stimulus, even though there was a falling edge
>stimulus that should have generated a falling edge on the output (which we
>didn't see, because the output was at 0 V during this time). The output
>would actually go low at the next time the stimulus goes low, because at
>that time the output will be in the high state already.
>
>Here is an ASCII attempt to illustrate this:
>
>Stimulus:
> __ __ __
>___| |________________| |________________| |____________...
>
>Output:
> _________ ________ ____...
>_____________| |__________| |__________|
>
>Note that this problem only occurs if the pulse width is smaller than the
>delay, in other words when the buffer is over clocked. Trying to interpret
>these delays with a physical meaning, we can imagine a buffer that will not
>switch at all under these conditions because it is over-clocked. On the
>other hand, we could also think of a pipelined buffer architecture which
>could very well generate waveforms as shown above. While both
>interpretations may be correct, it seems that the first approach is more
>consistent with the way the waveforms (Vt curves) operate in current IBIS
>simulators. Currently, if the lead-in portion of a waveform is longer than
>the pulse width of the stimulus, the output of that buffer model will not
>switch.
>
>*****************************************************************************
>
>
-- RegardsItzik Peleg Board Technology Group
Marvell Semiconductor Israel Ltd Moshav Manof, D.N. Misgav 20184, ISRAEL Email - itzik.peleg@il.marvell.com Tel - +972 4 9951192 Cell - +972 54 452482 Fax - +972 4 9951902 WWW Page: http://www.marvell.com ======================================================================== This message may contain confidential, proprietary or legally privileged
information. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone, or by e-mail and delete the message from your computer.
Thank you! ========================================================================
|------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just 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 written 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
This archive was generated by hypermail 2b28 : Thu Jan 29 2004 - 19:33:18 PST