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

From: Shalom.Bresticker@freescale.com
Date: Sat Apr 02 2005 - 20:40:00 PST

  • Next message: Shalom.Bresticker@freescale.com: "Re: errata/618: 15.3.2: $timeskew Case 3 and Case 4 are the same"

    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: 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.
     
     

    This archive was generated by hypermail 2.1.4 : Sat Apr 02 2005 - 20:40:20 PST and
    sponsored by Boyd Technology, Inc.