- Previous message: Shalom.Bresticker@freescale.com: "What is $fullskew?"
- Maybe in reply to: Shalom.Bresticker@freescale.com: "What is $fullskew?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Without getting into details, Shalom's interpretation of $fullskew is
correct. It definitely is not intended to be shorthand for two
$timeskew's, but to address the situation, as Shalom describes, where
two signals must occur within a specified time of each other, but the
order is not important. $timeskew required complex conditionals on the
signals to handle the situation.
--Ted
-----Original Message-----
From: shalom@fil.ea.freescale.net [mailto:shalom@fil.ea.freescale.net]
On Behalf Of Shalom.Bresticker@freescale.com
Sent: Monday, April 11, 2005 3:05 AM
To: etf@boyd.com
Cc: Yonghao Chen; Ted Elkind; David Roberts
Subject: What is $fullskew?
I want to discuss $fullskew. I want to discuss what it is and it is not
and
then examine the LRM in a follow-up mail. Some of my conclusions depend
on the correct
interpretation of $fullskew, but others do not.
I claim that $fullskew has been misunderstood.
$fullskew (event1, event2, limit1, limit2) ;
is not the same as
$timeskew (event1, event2, limit1) ;
$timeskew (event2, event1, limit2) ;
Let's see why.
The LRM says, and here it is correct,
"$fullskew is identical to $timeskew except the reference and data
events can
transition in either order...
The reference event is the timestamp event ... when the reference event
precedes
the data event. The data event is the timestamp event ... when the data
event
precedes the reference event.
"The $fullskew timing check reports a violation only in the following
case,
where limit is set to limit1 when the reference event transitions first,
and to
limit2 when the data event transitions first:
(timecheck time) - (timestamp event) > limit"
From here, it is clear that when there is a reference and data event,
only one
timing check is performed, not two. Which depends on whether the
reference or
data event comes first.
Only one of two possible $timeskew checks is performed. The check is
conditional, and the condition is which event comes first.
If $fullskew were the same as two unconditional $timechecks, there would
have
been no need and no justification for a new timing check. $timecheck
would have
sufficed. If one wanted both of them, he would simply write both of
them.
$fullskew would not have added any new functionality.
It's not logical, either.
What are we talking about? Two events which are supposed to happen more
or
less together and we want to check that they do indeed happen together.
An example would be a signal and its complement. We want to check that
when
they toggle, they toggle together. The complication is that we do not
know
(or care) which will toggle first.
Suppose we write
$fullskew (a, b, 5, 5);
Now when a and b occur, they are supposed to occur together
The $fullskew says, if a occurs first, then b should occur within 5
timepoints
afterwards. If b occurs first, then a should occur within 5 timepoints
as well.
If that is what happens, everything is OK and there is no violation
reported.
Suppose we wrote instead:
$timeskew(a, b, 5) ;
$timeskew(b, a, 5) ;
What would happen? Suppose a occurred first. This triggers the first
$timeskew.
If b occurs within 5 timepoints, then the timing check is satisfied.
But now
b has triggered the second $timeskew, requiring a to happen again within
another 5 timepoints of b. That event will trigger the first $timeskew
again,
requiring b to happen also a second time within another 5 timepoints,
and so
on, infinitely.
In order for a violation to not be reported, in order for the $fullskew
to be
satisfied according to this interpretation, a and b would have to happen
one
after the other forever. No one ever claimed that this is what $fullskew
is
for, and it would not be very useful either.
All we said is that we want to check the skew between two events, in the
case
where we do not know which will precede the other.
I also claim that $fullskew corresponds exactly to the SDF BIDIRECTSKEW.
This is what IEEE Std 1497-2001 says in Clause 5.5.11:
"The BIDIRECTSKEW construct shall specify limit values for bidirectional
signal
skew timing checks. A signal skew limit is the maximum allowable delay
between
two signals, which if exceeded causes devices to behave unreliably.
Syntax 47
shows the formal syntax for the bidirectional timing check.
bidirectskew_timing_check ::=
( BIDIRECTSKEW port_tchk port_tchk value value )
Syntax 47: Syntax for bidirectional skew timing check
The first port_tchk shall be either the stamp or check event,
depending on
whether it transitions first or second.
The second port_tchk shall be either the stamp or check event,
depending on
whether it transitions first or second.
value is the maximum skew limit when the first port_tchk transitions
first.
value is the maximum skew limit when the second port_tchk transitions
first.
The bidirectional BIDIRECTSKEW construct shall annotate values for skew
checks
where the skew can be measured in either direction. Either port_tchk can
transition first. Both limits must be positive.
Example (42):
(Figure 22 shows a diagram where clk1 and clk2 rise, in either order.)
(INSTANCE x)
(TIMINGCHECK
(BIDIRECTSKEW (posedge clk1) (posedge clk2) (6) (7))
)
When clk1 transitions first, the delay before the clk2 transition is
measured
against the first value, 6.
When clk2 transitions first, the delay before the clk1 transition is
measured
against the second value, 7."
Ted Elkind wrote,
"Bidirectskew was intended to anticipate a potential enhancement to
1364.
I should probably say a little more about bidirectskew. It was intended
to address the situation where two signals have skew relative to one
another, and either one could occur first."
Again, it is clear, that when the pair of signals transition, only one
timing
check is performed, not two. There are two potential checks, with
complementary
conditions. Only one is triggered.
The two signals should transition together, but the time between each
pair of
transitions could be very large.
Similarly, in the original $fullskew proposal from 1997, which I
forwarded a
few days, we see the following:
"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. It doesn't perform a check where
either of the two signals could occur first.
...
Example: $skew(posedge CP &&& CPN, negedge CPN, 2, notifier)
...
___ ___ ___ ___ ___
CP ___| |___| |___| |___| |___| |__
^
_________ ___ ___ ___ ___
CPN |___| |___| |___| |___|
...
3. Since $skew check in Verilog is "uni-directional" ie. the first
signal
is the reference event (which should happen first to initiate a
check) and the second signal is a data event (which is when the
check is actually performed), another $skew statement is required to
cover the bi-directional nature of most skew checks. Following is
the bi-directional counterpart for the above skew check for the same
edges of the reference and data signals but in the reverse order.
ie. $skew(negedge CPN &&& ~CP, posedge CP, 2 , notifier)"
Here we really see that the bidirectional counterpart is not achieved by
a simplistic reversal of the reference and data events.
The following, taken, from the original proposal, shows the intended
behavior,
and I think it is basically logical and correct.
Remember that the flags in the original proposal are different from what
they are now, close to being the complements. The following corresponds
to
what happens when our event_based_flag is 0."
" When no edge is specified on either reference signal, then any
edge on either signal can be the trigger that initiates a
constraint period waiting for the transition on the other signal.
A constraint period that ends with a violation begins another
constraint period, while one that ends with no violation does not
begin another constraint period.
...
$fullskew(posedge REF, posedge DAT, 5, 5, ntfr, 1);
Assume that beginning at simulation startup the REF and DAT
signals transition in this manner, and that the transitions, when
they occur, obey the constraints:
___ ___ ___ ___ ___ ___
(a) REF xxxx___| |___| |___| |___| |___| |___| |_
___ ___ ___ ___ ___
DAT xxxxxxxxxxx___| |___| |___| |___| |___| |__
When the first posedge on REF takes place DAT is still in the X
state, and the constraint period elapses with no posedge on DAT,
so a timing violation message is issued. The next signal to
experience a posedge, be it REF or DAT, begins the next constraint
period. In the example it is DAT that transitions next with a
posedge, and since REF occurs within the 5 unit constraint period
there is no violation. This posedge on REF dos not begin anotehr
constraint period, since it is already ending one that does not
result in a violation. The next posedge transition of DAT begins
another constraint period, and so forth.
...
One interesting aspect of $fullskew behavior is that when the
timing is truly off between the two signals there will be two
violations given per cycle. The first edge of one signal will
occur, and when the edge on the other signal is late a timing
violation message is issued and a new constraint period is begun.
The next edge of the original signal is now late relative to the
other signals edge, and another violation is issued."
Regarding the mode where our event_based_flag is 1, giving behavior
similar
to $skew, he wrote:
" The waveforms in (a) would not generate a timing violation message
until the first transition of DAT. This edge of DAT would then be
used to begin a new constraint period, since it ended a constraint
period that resulted in a violation."
Can anyone justify a different interpretation of what $fullskew is
intended
to do?
In a folllowup mail, I will discuss the problems I see in the current
description of $fullskew in the LRM, which includes internal
contradictions
as well as incorrect descriptions.
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 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary
- Next message: Shalom.Bresticker@freescale.com: "errata/659: $fullskew bugs"
- Previous message: Shalom.Bresticker@freescale.com: "What is $fullskew?"
- Maybe in reply to: Shalom.Bresticker@freescale.com: "What is $fullskew?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.4
: Mon Apr 11 2005 - 05:47:02 PDT
and
sponsored by Boyd Technology, Inc.