Re: errata/659: errata $fullskew bugs

From: Stefen Boyd (stefen@boyd.com)
Date: Tue Apr 12 2005 - 14:20:00 PDT

  • Next message: Shalom.Bresticker@freescale.com: "Re: errata/659: errata $fullskew bugs"

    The following reply was made to PR errata/659; it has been noted by GNATS.

    From: Stefen Boyd <stefen@boyd.com>
    To: etf-bugs@boyd.com
    Cc: yonghao@cadence.com
    Subject: Re: errata/659: errata $fullskew bugs
    Date: Tue, 12 Apr 2005 14:39:44 -0700

     Forwarding since Yonghau wasn't whitelisted yet.
     
     Stefen
     
     -----------------
     
     In general, I agree with the updates. Several comments follow.
     
     Regards,
     
     -Yonghao
     
     
     On Mon, 2005-04-11 at 16:18, Shalom.Bresticker@freescale.com wrote:
    > In 15.3.3 $fullskew:
    >
    > 1. The LRM says,
    >
    > "The default behavior for $fullskew is timer-based. Violations shall be
     reported
    > immediately upon an elapse of time after the timestamp event equal to
     the limit.
    > It then becomes dormant and reports no more violations, even in response to
    > timecheck events, until after the next timestamp event. This check shall
     also
    > become dormant if it detects a timestamp event when the associated
     condition is false."
    >
    > This needs to change to something like the following:
    >
    > "The default behavior for $fullskew is timer-based. A violation shall be
    > reported immediately upon elapse of the time limit after the timestamp
     event if
    > a timecheck event does not occur in this time, turning the timing check
     dormant.
    > However, if a timecheck event does occur within the time limit, then no
    > violation is reported and the timing check turns dormant immediately.
    >
     
     
    > If a second timestamp event occurs within the time limit, then a new timing
    > check is activated and no violation is reported on the first.
    > However, if it detects a conditioned timestamp event when the associated
    > condition is false, then the timing check turns dormant.
     
     ===> It is possible that the first timing check is already dormant.
     Consider the following sequence of events, all within time limit:
     timestamp event, timecheck event, timestamp event. The timecheck event
     will turn the first timing check dormant. The other thing, even if the
     tcheck is dormant already, if a false condition is detected for the
     second time stamp event, the (dormant) timing check still need be
     updated so that it starts with the new timestamp event. This is
     important since the last stamp event will be a reference to determine if
     a following ref/data event should start a new timing check or not (see
     Shalom's original commment below)
     
     Also I think the term "timing check" in above context is a bit
     confusing, since it also refers to the whole timing check task. In other
     subsections of this chapter, "timing window" has been used in similar
     context. Following is an attempt to rephrase:
     
     "A second timestamp event occurring within the time limit starts a new
     timing window that replaces the first one. If the timestamp event has
     no condition or has a true condition, and the timing check is dormant,
     then the timing check is activated. However, if a false condition
     associated with the timestamp event is detected, and the timing check is
     active, then the timing check turns dormant."
     
     
     
     PS. The "within" in above statement has potential ambiguity. What
     happens if the second timestamp event occurs at the time of (first
     timestamp event + time limit)? This is the same type of ambiguity
     Shalmom mentioned in the last review meeting. The LRM doesn't address
     it. But based on the cases of $skew analogous to this, it probably
     should be considered inclusive. i.e. the second timestamp event occuring
     at the boundary time should start a new timing window to replace the
     first one, hence no violation will be reported.
     
     
     
    >
    > A reference event or data event is a timestamp event and activates a new
     timing
    > check, unless it is a timecheck event occuring within the time limit after a
    > preceding timestamp event.
    >
     
     ===> It should be noted that, the "within" in above statement is
     inclusive. This is made clear by the LRM (see the end of p252 and
     beginning of p253). Specifically, if the timecheck event happens at the
     time of (timestamp event + time limit), then it will not be treated as a
     new timestamp event.
     
     In relation to my previous change, the above can be rephrased as below:
     
     "A reference event or data event is a timestamp event and starts a new
     timing window, unless it is a timecheck event occurring within the time
     limit after a preceding timestamp event."
     
     
    > In the timer-based mode, the remain active flag is ignored."
    >
    >
    > 2. Case 1 says,
    >
    > " Case 1: Event based flag and remain active flag not set.
    >
    > The transition at A of CP while MODE is true begins a wait for a negative
    > transition on CPN, and a violation is reported at B as soon as a period
     of time
    > equal to 50 time units has passed. This resets the check and readies it
     for the
    > next active transition.
    >
    > A negative transition on CPN occurs next at C, beginning a wait for a
     positive
    > transition on CP while MODE is true. At D a time equal to 70 time units has
    > passed without a positive edge on CP while MODE is true, so a violation is
    > reported and the check is again reset to await the next active transition.
    >
    > A transition on CPN at E also results in a timing violation, as does the
    > transition at F, because even though CP transitions, MODE is no longer
     true.
    > Transitions at G and H also result in timing violations, but not the
     transition
    > at I, because it is followed by a positive transition on CP while MODE
     is true."
    >
    > Reminder: we decided that Case 1 should be simply, "Event based flag not
     set."
    >
    > The first paragraph says,
    >
    > "a violation is reported at B as soon as a period of time equal to 50
     time units has passed."
    >
    > However, the intent is that 50 timepoints passed WITHOUT a negedge in CPN.
    > But in the figure, we clearly see that there IS a negedge on CPN before B.
    > So the figure does not correct show the intended case.
    > The figure should be redrawn so that there is no negedge on CPN before B.
    >
    > Next, it says,
    >
    > "A negative transition on CPN occurs next at C". As mentioned above,
    > this should appear in the diagram AFTER B. The arrows and vertical lines
    > showing the time between C and D need to move to the right as well.
    >
    > Finally, it ends with
    >
    > "Transitions at G and H also result in timing violations, but not the
     transition at I, because it is followed by a positive transition on CP
     while MODE is true."
    >
    > That positive transition on CP is J. In the current diagram, J is more than
    > 70 timepoints after I. It should be within that time.
    >
    > Simply moving the CP waveform a little to the right might fix all of these.
    >
     
     
     ====> I have updated the diagram to be visually correct, and to reflect
     this description.
     
     
    >
    > 3. Case 2 is:
    >
    > "Case 2: Event based flag set, remain active flag not set.
    >
    > The transition at A of CP while MODE is true begins a wait for a negative
    > transition on CPN, and a violation is reported at C on CPN because it
     occurs
    > beyond the 50 time unit limit. This transition at C also begins a wait
     of 70
    > time units for a positive transition on CP while MODE is true. But for
    > transitions on CPN at B through H there is no positive transition on CP
     while
    > MODE is true, and so no timing violations are reported. The transition
     at I on
    > CPN begins a wait of 70 time units, and this is satisfied by the positive
    > transition on CP at J while MODE is true."
    >
    > The same comments that C should be after B and J after I hold here too.
    >
    > The sentence "But for transitions on CPN at B through H" should be
    > "But for transitions on CPN at C through H".
    > (The history of this is that in the 1364-2001 draft, it was originally
    > written "This transition at B also begins a wait of 70 time units.."
    > and one reviewer noticed that it should be C, but the second place where
    > B should also be C was missed.)
    >
    > Note that the same rules about when a new timing check is activated hold
    > in the event based mode as well as in the timer based mode.
    >
    >
    > 4. I'm getting tired...
    >
    >
    > 5. Case 3:
    >
    > "Case 3: Event based flag and remain active flag both set.
    >
    > The transition at A of CP while MODE is true begins a wait for a negative
    > transition on CPN, and a violation is reported at C on CPN, and it shall
     also
    > begin a wait for a positive transition on CP while MODE is true. No such
    > transition on CP ever takes place after CPN transitions C through H, but no
    > violations are reported because CP never experiences a positive transition
    > while MODE is true. Transition I also reports no violation because a
     positive
    > transition at I on CP while MODE is true occurs within the 70 time unit
     skew
    > limit."
    >
    > Case 3 actually describes EXACTLY the same value as Case 2.
    >
    > So what difference does the remain active flag mean here?
    >
    > I'm not sure whether there is a case where it does make a difference.
    >
    > Note that in the original proposal, the original version of this flag had
    > a different role, to determine whether a conditioned timestamp event with
    > condition false would turn the check dormant or not.
    >
    >
     
     
    > 6. The paragraph describing $fullskew in event based mode should be changed
    > because it says that in this mode, $fullskew is like $skew, which is
     misleading,
    > because $skew is unidirectional. And it does not describe the behavior shown
    > in Case 2, describing when an event is a timestamp and when it is a
     timecheck
    > event. The rules are the same as in timer based mode. Case 3 is definitely
    > not describing a behavior like $skew, which reports multiple violations on
    > multiple timecheck events.
    >
     
     ===> I agree. The behavior of $fullskew in event mode is a new one that
     $skew doesn't have, and the second sentence of this paragraph need be
     fixed. Aslo in the last sentence of the same paragraph, "$timeskew"
     should be "$fullskew", and the rest of the sentence need also be
     updated.
     
     
    >
    > 7. The example for both $fullskew and $timeskew should contain the flags,
    > such as
    > $fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, e_b_f, r_a_f);
    >
    >
    > 8. Finally, an easy one: The $skew section says that "$timeskew and
     $fullskew
    > shall be used if violation reports are absolutely required". That should be
    > "should" instead of "shall".
    >
    > Thank you and good night.
    >
    > Shalom
    >
    >
    >
     

    This archive was generated by hypermail 2.1.4 : Tue Apr 12 2005 - 14:20:20 PDT and
    sponsored by Boyd Technology, Inc.