Min-pulse-width-check timing paths

All sequential elements require the clock pulse to have a pulse of at-least a certain width in order to function correctly. This is coded in their timing models in terms of a "minimum pulse width" requirement. And the timing path pertaining to check minimum pulse width of a signal is termed as "min-pulse-width-check" timing path. A min-pulse-width-check timing path essentially checks the arrival of one transition of the clock at the endpoint with respect to its fall transition. In other words, both constrained signal and reference signal are the same, just the opposite transitions.

For instance, min-pulse-width-check timing path for a high pulse will have fall transition as the reference signal and rise transition as constrained signal. The latest arrival of rise transition is checked against earliest arrival of fall transition Similarly, min-pulse-width-check timing path for a low pulse will have fall transition as constrained signal and rise transition as reference signal. The latest arrival of fall transition will be checked against earliest arrival of rise transition.

Constraining min-pulse-width-check timing paths: There are two kind of scenarios:

• Min-pulse-width requirement for the pin is picked from timing model

• User specifically specifies a "min-pulse-width" check at a specific pin using "set_min_pulse_width" command. This may be required in certain scenarios, such as a clock going out of the design through an output port, and we need to maintain a minimum duty cycle for the outgoing clock.

Regardless of this, we just need to define a clock of required period and we can report min-pulse-width-check timing path as desired.

In-to-out paths

In-to-out paths start from an input port and end at an output port. Figure 1 below shows an in-to-out path. As shown in figure 1, most of the times (not always), in-to-out paths are subset of a reg-to-reg path seen from a higher level of hierarchy. For instance, an in-to-out path at the level of a block-level design may be a reg-to-reg path as seen at SoC flat.

For in-to-out paths, the clock path is always assumed fully outside the design. 

Constraining in-to-out paths: There are two ways that we can constrain in-to-out paths:

Constraining with respect to a virtual clock: We can consider in-to-out path as a sub-segment of a larger reg-to-reg path. And we can constrain these paths using a virtual clock. Using "set_input_delay" for input port and "set_output_delay" for output port with respect to same virtual clock, these paths can be constrained.

• Create a clock VCLK without any source
• "set_input_delay" at input_port with respect to VCLK
• "set_output_delay" at output_port with respct to VCLK

Constraining as point-to-point paths: We can constrain in-to-out paths using "set_max_delay" command as point-to-point paths. However, using this approach, we may need to apply some extra constraints as well depending upon the behavior of the tool we are using.