User Guide: DSim Delay Model for Module Paths

SV-LRM section 30.2 defines distributed delays and module delays as follows and this document adheres to these definitions:

1. Distributed delays, which specify the time it takes events to propagate through gates and nets inside the module (see 28.16)

   
   

2. Module path delays, which describe the time it takes an event at a source (input port or inout port) to propagate to a destination (output port or inout port)

   
   

This section covers Module Path Delays, followed by a section on Operational Modes which can be targeted with an appropriate setting of command line options.

Basic Module Path Delay Model

Given a module with a specify block which defines one or more module paths to an output, this section discusses the delay module used to determine the transitions on that output.

In the basic case, assuming no invocation options are given, the reject limit = error limit = delay of trailing edge. In this case the following approach is taken:

1. The previously scheduled value of the output is tracked throughout. During initialization it is set to the initial value of the output for variables or x for nets.

   
   

2. When a new value for the output is scheduled (eg by: continuous assignment, gate output, udp output) the transition type (one of 12 possibilities {0,1,x,z} ? {0,1,x,z}) is determined by comparing the previously scheduled value and the newly scheduled value.

   
   

3. Based on the rules set out in SV-LRM 1800-2012 section 30.5 the active path is selected and the delay is calculated.

   
   

4. The transition time of the input of the active path, plus the delay is the intended transition time for the output, ie the schedule time.

   
   

5. The output schedule is then analyzed and adjusted for the new value of the output.

   
   

   1. If there is another entry pending in the schedule and the new output?s schedule time is prior to that we have a negative pulse, see the Negative Pulse Handling section.

      
      

   2. If the output?s schedule time is at or after the pending item the pulse width is calculated as the difference of the scheduled times.

      
      

      1. If the pulse width < reject limit the pulse is rejected. The Pending transition is removed from the schedule and if the new value of the output != the starting value of the previously pending transition a new transition is added from the starting value of the pending transition to the new output value at the output?s schedule time.

         
         

      2. If the pulse width >= reject limit a new entry is made in the output schedule at the output?s schedule time.

         
         

Fine Tuning Reject and Error Limits

The default reject and error limit can be modified in various ways including (See command line option documentation for details):

• -pulse_e, -pulse_r percent

  
  
  • percent modifiers applied to the transition delay to get the error and reject limits respectively

• -pathpulse with $PATHPULSE specparams in the specify blocks

  
  
  • enables the $PATHPULSE settings in the specify blocks, if -pathpulse is not specified $PATHPULSE specparams are ignored.
  • these take precedence over the default limits even when pulse_e and pulse_r are specified.

• +transport_path_delays - changes the default reject and error limit to 0

  
  
  • Note that using transport delay allows small pulses to propagate and will impact simulator performance negatively particularly in large combinational logic.

Taken together with the appropriate precedence these various settings prepare the reject and error limits that are used to fine tune the pulse filtering.

The pulse width calculated in 5.2 of the Basic Module Path Delay Model is handled slightly differently in the presence of rejectLimit != error limit:

• if pulse width < reject limit it is handled as described in 5.2.1

  
  

• if rejectLimit <= pulse width < error limit then the output schedule is adjusted to add a transition to x and back to the final new output value.

  
  

  • if pulse_e-ondetect is specified the transition to x is actioned immediately, the previously pending transition is removed from the schedule and a new transition from x to the new output value is scheduled at the output?s schedule time.

    
    

  • Otherwise (by default or if pulse_e-onevent is specified) the previously pending transition is adjusted to be a transition to x and a new transition from x to the new output value is scheduled at the output?s schedule time.

    
    

Negative Pulse Handling

Regardless of how the pulse limits are set, negative pulses are detected as described in step 5.1 of the Basic Module Path Delay Model.

The in the absence of pulse style settings within the specify block and command line option -showcancelled, the negative pulse is rejected.

Otherwise the pulse style showcancelled is in effect and the output schedule will be adjusted with a transition to x and from x to the new output value.

• If pulse_e-ondetect is specified the transition to x is actioned immediately, the previously pending transition is removed from the schedule and a new transition from x to the new output value is scheduled at the time of the previously scheduled transition.

  
  

• Otherwise (by default or if pulse_e-onevent is specified) a new transition to x is made at the output trailing edge?s schedule time, the previously pending transition is removed from the schedule and a new transition from x to the new output value is scheduled at the time of the previously scheduled transition.

  
  

Operational Modes

This section discusses how the Basic Module Path Delay Model can be used with various options to achieve various operational modes. Please note these are not global modes and only apply the delays controlled with module paths within specify blocks.

Pure inertial (default mode)

This is the default mode with neither -pathpulse nor +transport_path_delay options set.

The $PATHPULSE settings in the specify blocks are ignored and the error and reject limits are set equal to the delay associated with the trailing edge of a pulse. Since the error limit == reject limit the only time the result will go to x as a result of pulse handling is when a negative pulse occurs with showcancelled enabled.

Hybrid Delay Model

This mode is enabled by one or more of the following options:

• -pathpulse option which will enable the $PATHPULSE settings.
• -pulse_e/-pulse_r percent options adjusting the default error and reject limits away from the defaults.

Note if +transport_path_delay is set the default error and reject limit will be 0 instead of the trailing edge?s transition delay.

The error and reject limits are set based on precedence rules and the settings of $PATHPULSE -pulse_e and -pulse_r values. If the error limit is not provided but the reject limit is, then the error limit will be set equal to the reject limit. When neither is specified the delay of the trailing edge will be used for both limits.

Pure Transport Mode (all pulses transmitted)

To enter this mode add the +transport_path_delay and not the -pathpulse options nor the pulse_e/pulse_r options.

The $PATHPULSE settings in the specify blocks are ignored and the error and reject limits are set equal to 0. Since the error limit == reject limit == 0 the only time the result will go to x as a result of pulse handling is with showcancelled enabled.