Re: errata/618: 15.3.2: $timeskew Case 3 and Case 4 are the same

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

  • Next message: Shalom.Bresticker@freescale.com: "1364 ballot response meeting tomorrow"

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

    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
     

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