ISSUE 618

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 618
Category errata
Synopsis 15.3.2: $timeskew Case 3 and Case 4 are the same
State open
Class errata-discuss
Arrival-DateAug 12 2004
Originator Shalom.Bresticker@freescale.com
Release 2001b
Description
THis was posted on comp.lang.verilog.
See my comments following.

Shalom

---------- Forwarded message ----------
Date: Wed, 04 Aug 2004 11:35:30 +0000
From: Pooja Maheshwari <mpooja@agere.com>

In V2K1 $timeskew has been introduced as new timing check.
On page number 252 of standard 4 cases for $timeskew
arguments (event based flag and remain active flag) are defined.

Case3 and case 4 both says Event based and remain active flags are set.
Does anybody know, whether 4 cases and their interpretations are defined
properly or not.

---------------------------------------

I think Pooja is correct and they are the same.

I also found the following, which strengthens that conjecture:

On Ballot Draft 5, comment AH-10 was:

On page 257, the text under case 2 should go with case 3 instead. In case 2, the remain active flag is not set, so only one violation should be reported after a rising edge on CP. The text currently in the document for case 3 saying that all CPN edges would cause a violation is wrong because CPN edges after E would not cause violations, since the rising CP edge at F with MODE low would disable the check.

Then the resolution for Draft 6 was:

Changed to following--- Case 2: The first negative transitions on CPN at points C shall cause a timing violation and then goes dormant since the remain active flag is not set. Case 3: The first three negative transitions on CPN at points C, D, and E shall cause timing violations. The second reference event at F occurs while mode is false, turning the $timeskew check dormant, and no further violations are reported. This is identical behavior to $skew.

It seems that somehow the last sentence got separated into a separate Case 4.

In looking at this, I found a couple of more issues, I think.
To be continued...

Shalom

Fix

Unknown
Audit-Trail
From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/618: 15.3.2: $timeskew Case 3 and Case 4 are the same
Date: Sun, 3 Apr 2005 07:01:43 +0200 (IST)

This issue was brought up in one of the ballot comments.
I have looked at it and will send my comments later.
For now, I want to send the original proposal for $timeskew, which is
from 1997. Though it was changed before being incorporated into the
standard, it does shed some light on the concept behind it.

----- Begin Included Message -----

>From prabhu@lsil.com Thu Sep 25 12:34 PDT 1997
Date: Thu, 25 Sep 97 12:33:17 PDT
From: prabhu@lsil.com (Prabhakaran Krishnamurthy)
To: wadswort@poci.amis.com, tom_dewey@mentorg.com, pcolwill@viewlogic.com,
elkind@cadence.com, marek@cadence.com, cranston@cadence.com
Subject: Re: $timeskew Proposal
Cc: alec@fintronic.com, dinesh@synopsys.com, samir@lsil.com, ebalaji@lsil.com,
jagmohan@lsil.com, naveen@lsil.com, prabhu@lsil.com, lmike@lsil.com


Hi Everybody,
Here is the new proposal for $timeskew.

Pl. let me know if more details need to be added.

Thanks,
Prabhu K.

======================================================================

IEEE 1364 VSG Issue Number: ATF004

Classification: Timing

IEEE 1364 Version: IEEE 1364'98

Summary: The $skew timing check in Verilog checks that the data event
occurs (if it occurs at all) within the constraint limit
after the reference event. $timeskew addresses problems
related to the time of the violation report and the
ambiguity of the meaning of transitions that take place
while the corresponding condition is false.

Related Issues: None <Xref all related issues by number.>

Relevant LRM Sections: TBD <Xref all relevant LRM sections by number.>

Key Words and Phrases: TBD <IEEE 1364 terms>

Priority - Submitted: Critical

<One of the following:>
Critical
Important
Desirable

Priority Task Force 1 <TF assigns.>

<One of the following:>
1
2
3
4
Unknown <Author assigns.>

Current Status: Submitted

Submitted <Author assigns.>
Analyzed <TF assigns.>
TF-Approved <TF assigns.>
VSG-Approved <TF assigns.>
Superceded <TF assigns.>

Superseded By: N/A

IEEE Ballot Disposition: TBD

<One of the following:>
Unknown
Closed (All Issues Completely Addressed)
Bugs Fixed, Enhancements Outstanding (No TF Issues)
Superseded (TF Issues Outstanding)

Disposition Rationale: TBD<To be completed by the TF>

Superseded By: N/A <superceding issue's number>

Date Submitted: 25 September 1997
Author of Submission: Prabhu Krishnamurthy
Author's Affiliation: LSI Logic Corporation
Author's Post Address: 1501 McCarthy Blvd, Milpitas CA 95035
Author's Phone Number: (408)433-6118
Author's Fax Number: (408)433-4156
Author's Net Address: prabhu@lsil.com

-----------------------
Date Analyzed: TBD <Enter date analyzed in dd month year form.>
Author of Analysis: TBD <Enter author of analysis.>
Revision Number: $Revision: 1.1 $
Date Last Revised: $Date: 1997/09/25 12:11:24 $


Description of Problem
----------------------
Following section describes the issues with the way the $skew check works
right now.

Example: $skew(posedge CP &&& CPN, negedge CPN, 2, notifier)

1. In the above case, the skew check is initiated when the positive edge
on CP occurs when CPN is "1". This is marked as the reference event. If
the negative edge on CPN happens at, say, 10ns after the reference event,
the violation gets reported at that time and the notifier is toggled.
The issue here is as follows:

i. Since skew time is a "max" timing constraint, the violation should
be reported as soon as the "limit" elapses. This way, the
violation reporting, notifier toggling and the action following
that are not delayed.

ii. Another issue with the current behavior is that the triggering
event is active even after the conditioning signal becomes FALSE,
thereby reporting violations for all subsequent changes to the
data event. This is due to the fact that the triggering event
should happen again (satisfying the CONDITION on the reference
event) to begin another check.
___ ___ ___ ___ ___
CP ___| |___| |___| |___| |___| |__
^
_________ ___ ___ ___ ___
CPN |___| |___| |___| |___|
1 2 3 4

The first edge on CP (marked with ^) triggers the first skew
check and reports a violation when CPN event 1 happens (because
the skew exceeded the limit). The trigger still remains active as
the CONDITION on the reference is never again true when CP
experiences a posedge. This causes skew violations to be
reported for events 2,3,4... on the CPN signal with respect to
the first posedge on CP.

2. In cases where the posedge of CP happens first followed by more
transitions on CP without any change to the CPN signal, the skew
violation does not get reported until negedge of CPN happens.

This will be resolved with the timer based approach.

Proposed Resolution
-------------------

The new timing $timeskew check that is being proposed is to overcome
the above limitations of the existing $skew timing check.

Syntax Description
------------------

$timeskew(ref_event1, ref_event2, limit, notifier, evr_flag, dormant_flag)

ref_event1 - edge-triggered event which can accept an edge
modifier and a condition

ref_event2 - edge-triggered event which can accept an edge
modifier and a condition

limit - Positive constant expression or specparam specifying the
maximum by which ref_event1 can precede ref_event2.

The limit is not optional.

notifier (optional) - Register

evr_flag (optional) - Early Violation Report flag. Should be
either null or a constant. A null or zero value indicates that
consecutive edges of one signal with no edges on the other should
not be reported as a violation. If a transition on one signal
occurs late with respect to the other it is reported as a
violation at that time. This is similar to the way $skew works
today.

A non-zero value indicates that a late transition is reported
immediately after the constraint period expires. In this case,
transitions are required to occur - a missing transition on one of
the signals is always reported as a violation.

dormant_flag (optional) - Should be either null or a constant. A
null or zero value indicates that when this constraint is already
active it will remain active after subsequent transitions on the
same signal which caused it to be active when those transitions
take place while the condition is false.

A non-zero value indicates that under these same circumstances the
check will become dormant.

Details
-------
When no edge is specified on either reference signal, then any
edge on ref_event1 can be the trigger that initiates a constraint
period waiting for the transition on ref_event2. Based on the
value of the dormant flag, this check will remain active or dormant.

$timeskew behavior is illustrated in this example, which specifies
that matching edges are required and that the violations be
reported immediately after the end of the constraint period.

$timeskew(posedge REF1, posedge REF2, 5, ntfr, 1);

Assume that beginning at simulation startup the REF1 and REF2
signals transition in this manner, and that the transitions, when
they occur, obey the constraints:
___ ___ ___ ___ ___
(a) REF1 xxxx___| |___| |___| |___| |___| |___
___ ___ ___ ___ ___
REF2 xxxxxx__| |___| |___| |___| |___| |__

In the above case, if the skew limit elapses after the posedge of
REF1 happens without the posegde on REF2 happening, the violation
will be reported.

Suppose there is another skew check between the same events in
a reverse fashion for bi-directionality like:

$timeskew(posedge REF2, posedge REF1, 5, ntfr, 1);

This check would get triggered at the first posedge of REF2, for
lack of any conditions on the events. This would report a violation
with respect to the next posedge on REF1. In order to avoid that, the
two checks would need to be conditioned as follows:

$timeskew(posedge REF1 &&& (REF2 != 1), posedge REF2, 5, ntfr, 1);
$timeskew(posedge REF2 &&& (REF1 != 1), posedge REF1, 5, ntfr, 1);

How conditions affect timestamp events is an important issue, and
is the motivating factor for the dormant flag. Take
this $skew check:

$skew(posedge CLK1 &&& CND, CLK2, 50);

Presume that CLK1 experiences transitions 0=>1 at time 100 while
CND is true, then CND becomes false at time 110, followed by CLK1
transitioning low at time 150 and high at time 200. If CLK2 now
transitions at time 220 $skew will issue a violation against the
last CLK1 transition while CND was true, which was at time 100.
By this measure CLK2 is late, arriving after 120 time units
instead of the required 50. In some designs this might not make
sense because they intend that a CLK1 transition with a false
condition makes the check dormant (ie, it is no longer looking for
a matching signal). This is the justification for the dormant
flag of the $timeskew check.


From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/618: 15.3.2: $timeskew Case 3 and Case 4 are the same
Date: Tue, 5 Apr 2005 23:01:04 +0300 (IDT)

OK, I studied the $timeskew section.

Let's start with $skew, though.

Its form is

$skew (reference_event, data_event, limit, notifier) ;

A violation is reported if

time(data_event) - time(reference_event) > limit.


(The LRM says,
"Simultaneous transitions on the reference and data events can never cause
$skew to report a timing violation, even when the skew limit value is zero."

This should be reworded to,
"Simultaneous transitions on the reference and data events shall not cause
$skew to report a timing violation, even when the skew limit value is zero."

The same change should be made in the text for $timeskew.)


Notes:

- No violation is reported unless and until a data_event occurs.
If data_event never occurs, no violation is reported.

- Similarly, if data_event occurs before reference_event, no violation is
reported.

- The timecheck remains active after a reference_event infinitely until
the next reference_event. If multiple data_events occurs after the
time limit, each will cause a violation report.

- The latest occurence of the reference_event is the one used.

A slightly ambiguous point is what happens if the reference_event is a
conditional event of the form "<event> &&& <condition>", e.g,
"posedge CP &&& MODE".

This is recognized as a reference_event only if <event> occurs while
<condition> is true.

What happens if <event> occurs while <condition> is false?

The description of conditional events implies that <event> is ignored
in that case.

The description of $skew makes no mention of this, also implying that
if the condition is false, then the event is ignored and $skew continues
blissfully reporting violations on all data_events that occur since the
last reference_event when the condition was true (after <limit> time has
passed).

And in fact, I checked three implementations and they do indeed work that
way.

Maybe the LRM should say so explicitly, because $timeskew works differently.


$timeskew has the form

$timeskew (reference_event, data_event, limit, notifier, event_based_flag, remain_active_flag) ;

notifier, event_based_flag, and remain_active_flag are optional, but for
the purpose of the discussion, I will treat them as though they are
always there. If either of the two flags is missing or null, it is treated as 0.

$timeskew reports a violation, like $skew, if

time(data_event) - time(reference_event) > limit.

But we will see the differences.

There are of course 4 theoretical combinations of the two flags, 00, 01, 10, and 11.

The LRM first discusses the default case, where both flags are 0 (or null
or missing). In this case, says the LRM, a violation is reported as soon
as the time limit expires if a data event has not occurred. Data events
after the time limit do not cause violation reports. So at most one
violation report will be issued, and that will be at the expiration of
the skew time limit.

Then the text says,
"This check shall also become dormant if it detects a reference event
when its condition is false."

(Ambiguity: what happens if a new reference event, with condition
either true or false, occurs simultaneously with time limit expiration?
Is a violation reported or not? I guess it is determined by the order
of execution within the timestep.)

This text seems to be referring to the default mode only, those as we
will see, there is a little ambiguity about this. Let's assume for now
that it refers only to the default mode.

The text does not discuss the possibility of event_based_flag = 0
with remain_active_flag = 1. We'll discuss that later as well.

Let's move on to discuss what happens if event_based_flag = 1.

The text says that if both flags are 1, then $timeskew behaves the same
as $skew. (Since the flags are constant expressions and so cannot change
dynamically during simulation, this raises the question why you need
this mode, just use $skew! And the question of why you need the
remain_active_flag at all! But let's assume at this stage that it is
for compatibility with 1364-2001, that is probably a good enough reason.)

And if event_based_flag is 1, whereas remain_active_flag is 0, then
$timeskew is like $skew, EXCEPT that it will become dormant after the
first violation.

So far, so good, more or less.

Now the LRM gives a series of examples.

It uses the statement

$timeskew (posedge CP &&& MODE, negedge CPN, 50) ;

(Really it should be

"$timeskew (posedge CP &&& MODE, negedge CPN, 50, event_based_flag, remain_active_flag) ;")

In the figure, Figure 15-1, it is difficult to tell whether timepoint E
is before, at the same time as, or after timepoint F. If it turns out to
make a difference in the end, then F should be moved later to be clear.

(In some versions of the LRM, the negedge of CP following F did not come
out in print. Please check your versions.)

Case 1 is where both flags are 0. No problems here. A violation is reported
at B and never again, as expected.

The case of event_based_flag = 0 and remain_active_flag = 1 is not
mentioned. Back to this later.

Case 2 is event_based_flag = 1, remain_active_flag = 0.

Here we get a violation report at C, but not at D and E. This is the
expected behavior.

Then comes the next sentence and ruins it.

"The second reference event at F occurs while MODE is false, turning the
$timeskew check dormant, and no further violations are reported." ???

This is unexpected for two reasons.
First, because after C, long before F, the check has already turned dormant.
Second, because no one mentioned till now that reference event with false
conditions affects this timecheck when the event_based_flag = 1.
Earlier, the text said that this case is like $skew, except that it turns
dormant after the first violation.

It appears that the sentence about the "second reference event at F"
is incorrect, though I am not sure.

Now appear Cases 3 and 4.
BOTH of them describe the case that both the event_based_flag and the
remain_active_flag are 1, but they describe different behaviors.

Case 3 says that violations are reported at C, D, and E, whereas the 2nd
reference event at F with MODE=false turns the check dormant.

Case 4 says that every negedge on CPN is reported as a violation,
identical to $skew.

These are contradictory.
Earlier, it was stated that this case is identical to $skew (as described
in case 4), whereas the behavior described in Case 3 is different from
$skew.

I believe Case 3 is a mistake and should be deleted, and Case 4 should be
renumbered to be Case 3.

Finally, what happens if event_based_flag = 0 and remain_active_flag = 1?

It could be argued that the remain_active_flag has no meaning in that
case since the check turns dormant after the timelimit expires anyway.

The ballot comment states that case should be illegal (or maybe that
the remain_active_flag should just be ignored in that case.)

Stu Sutherland understood similarly in his Verilog-2001 book.

A possible meaning for remain_active_flag in that case is to ignore
a reference event with condition false, which is earlier stated to turn
the check dormant.

In that case, maybe remain_active_flag=0 would also have the meaning
that a reference event with condition false turns the check dormant
even when event_based_flag = 1?


Shalom

--
Shalom.Bresticker @freescale.com Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

Unformatted



Hosted by Boyd Technology