Re: errata/659: errata $fullskew bugs

From: Shalom.Bresticker@freescale.com
Date: Tue Apr 12 2005 - 23:50:01 PDT

  • Next message: Shalom.Bresticker@freescale.com: "errata/660: Clause 7 does not clearly specify output of primitives with 1 input"

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

    From: Shalom.Bresticker@freescale.com
    To: yonghao@cadence.com
    Cc: etf-bugs@boyd.com
    Subject: Re: errata/659: errata $fullskew bugs
    Date: Wed, 13 Apr 2005 10:02:35 +0300 (IDT)

     Hi, Yonghao.
     
     My responses:
     
     
    > 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.
     
     Yes, this is true of course.
     The simplest case is at the beginning of time.
     If the first event to occur is a conditioned event with condition FALSE,
     then nothing should happen.
     
     
    > 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)
     
     I'm sorry, I did not understand this.
     As I understand it, if the timing check is dormant, then it waits for
     either a reference event or a data event. If either of these is conditioned,
     it is recognized only if the condition is true. If the condition is false,
     then it is ignored. The first event to occur with condition TRUE (if it is
     conditioned) will be the timestamp event.
     
     As specified in the LRM (and I am not sure that this is what should have
     been written, but this is what is there now), conditioned events with
     condition FALSE are totally ignored, except in the special case of
     $timeskew or $fullskew where a second timestamp event, if it occurs with
     condition FALSE, will turn an active timing check dormant.
     
    >
    > 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:
     
     I agree that 'timing check' is ambiguous.
     I agree that 'timing check' properly refers to the entire task.
     I was looking for a term to describe the action from the time where the
     timing check is triggered till it turns dormant again.
     I did not 'timing window' in the current LRM.
     
       
    > "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."
     
     Pretty good.
     However, it is a little ambiguous. The 3rd sentence contradicts the 1st.
     The 1st sentence says unconditionally that a 2nd timestamp event starts
     a new window. The 3rd sentence says that if the condition is false, the
     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.
     
     Yes, I think it is the same ambiguity, but I think you meant $timeskew
     instead of $skew. I think the LRM should be more clear about this in both
     cases.
     
     
    > > 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.
     
     Yes.
     
     
    > 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."
     
     Very good.
     
     Please don't stop reading here, there are a couple of more comments
     through to the end.
     
    > > 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.)
     
     Need to fix this.
     
     
    > > 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.
     
     The LRM needs to state that the rules about starting and ending timing windows
     apply to the event-based mode as well.
     
     
    > > 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.
     
     Need to deal with this.
       
       
    > > 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.
     
     Yes.
      
      
    > > 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".
     
     Need to fix these as well.
     
     We are getting closer. Even if we don't manage to fix everything,
     even a partial fix will be significant.
     
     Thanks,
     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
     

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