In the post Multicycle paths - the architectural perspective, we discussed about the architectural aspects of multicycle paths. In this post, we will discuss how multicycle paths are handling in backend optimization and timing analysis:
How multi-cycle paths are handled in STA: By default, in STA, all the timing paths are considered to have default setup and hold timings; i.e., all the timing paths should be covered in either half cycle or single cycle depending upon the nature of path (see setup-hold checks part 1 and setup-hold checks part 2 for reference). However, it is possible to convey the information to STA engine regarding a path being multi-cycle. There is an SDC command "set_multicycle_path" for the same. Let us elaborate it with the help of an example:
Let us assume a multi-cycle timing path (remember, it has to be ensured by architecture) wherein both launch and capture flops are positive edge-triggered as shown in figure 3. The default setup and hold checks for this path will be as shown in red in figure 4. We can tell STA engine to time this path in 3 cycles instead of default one cycle with the help of set_multicycle_path SDC command:
How multi-cycle paths are handled in STA: By default, in STA, all the timing paths are considered to have default setup and hold timings; i.e., all the timing paths should be covered in either half cycle or single cycle depending upon the nature of path (see setup-hold checks part 1 and setup-hold checks part 2 for reference). However, it is possible to convey the information to STA engine regarding a path being multi-cycle. There is an SDC command "set_multicycle_path" for the same. Let us elaborate it with the help of an example:
 |
| Figure 3: Path from ff1/Q to ff2/D is multicycle path |
Let us assume a multi-cycle timing path (remember, it has to be ensured by architecture) wherein both launch and capture flops are positive edge-triggered as shown in figure 3. The default setup and hold checks for this path will be as shown in red in figure 4. We can tell STA engine to time this path in 3 cycles instead of default one cycle with the help of set_multicycle_path SDC command:
set_multicycle_path 3 -setup -from ff1/Q -to ff2/D
Above command will shift both setup and hold checks forward by two cycles. That is, setup check will now become 3 cycle check and hold will be 2 cycle check as shown in blue in figure 4. This is because, by default, STA engine considers hold check one active edge prior to setup check, which, in this case, is after 3 cycles.
However, this is not the desired scenario in most of the cases. As we discussed earlier, multi-cycle paths are achieved by either gating the clock path or data path for required number of cycles. So, the required hold check in most cases is 0 cycle. This is done through same command with switch "-hold" telling the STA engine to pull hold back to zero cycle check.
 |
| Figure 4: Setup and hold checks before and after applying multicyle for setup-only |
However, this is not the desired scenario in most of the cases. As we discussed earlier, multi-cycle paths are achieved by either gating the clock path or data path for required number of cycles. So, the required hold check in most cases is 0 cycle. This is done through same command with switch "-hold" telling the STA engine to pull hold back to zero cycle check.
set_multicycle_path -hold 2 -from ff1/Q -to ff2/D
The above command will bring back the hold check 2 cycles back to zero cycle. This is as shown in figure 5 in blue.
 |
| Figure 5: Setup and hold checks after applying multi-cycle exceptions for both setup and hold |
We need to keep in mind the following statement:
Setting a multi-cycle path for setup affects the hold check by same number of cycles as setup check in the same direction. However, applying a multi-cycle path for hold check does not affect setup check.
Setting a multi-cycle path for setup affects the hold check by same number of cycles as setup check in the same direction. However, applying a multi-cycle path for hold check does not affect setup check.
So, in the above example, both the statements combined will give the desired setup and hold checks. Please note that there might be a case where only setup or hold multi-cycle is sufficient, but that is the need of the design and depends on how FSM has been modeled.
What if both clock periods are not equal: In the above example, for simplicity, we assumed that launch and capture clock periods are equal. However, this may not be true always. As discussed in multicycle path - the architectural perspective, it makes more sense to have multi-cycle paths where there is a difference in clock periods. The setup and hold checks for multicycle paths is not as simple in this case as it was when we considered both the clocks to be of same frequency. Let us consider a case where launch clock period is twice the capture clock period as shown in figure 6 below.
 |
| Figure 6: Default setup and hold checks for case where capture clock period is half that of launch clock |
Now, the question is, defining a multi-cycle path, what clock period will be added to the setup check, launch or capture? The answer depends upon the architecture and FSM of the design. Once you know it, the same can be modelled in timing constraints. There is a switch in the SDC command to provide for which of the clock periods is to be added. "set_multicycle_path -start" means that the path is a multi-cycle for that many cycles of launch clock. Similarly, "set_multicycle_path -end" means that the path is a multicycle for that many cycles of capture clock. Let the above given path be a multicycle of 2. Let us see below how it changes with -start and -end options.
1. set_multicycle_path -start: This will cause a cycle of launch clock to be added in setup check. As expected, on applying a hold multicycle path of 1, the hold will return back to 0 cycle check. Figure 7 below shows the effect of below two commands on setup and hold checks. As is shown, setup check gets relaxed by one launch clock cycle.
set_multicycle_path 2 -setup -from ff1/Q -to ff2/D -start
set_multicycle_path 1 -hold -from ff1/Q -to ff2/D -start
 |
| Figure 8: Setup and hold checks with -start option provided with set_multicycle_path |
2. set_multicycle_path -end: This will cause a cycle of capture clock to be added in setup check. As expected, on applying a hold multicycle path of 1, the hold will return back to 0 cycle check. Figure 8 below shows the effect of below two commands on setup and hold checks. As is shown, setup gets relaxed by one cycle of capture clock.
set_multicycle_path 2 -setup -from ff1/Q -to ff2/D -end
set_multicycle_path 1 -hold -from ff1/Q -to ff2/D -end
 |
| Figure 9: Setup and hold checks with -end option provided with set_multicycle_path |
Why is it important to apply multi-cycle paths: To achieve optimum area, power and timing, all the timing paths must be timed at the desired frequencies. Optimization engine will know about a path being multicycle only when it is told through SDC commands in timing constraints. If we dont specify a multicycle path as multicycle, optimization engine will consider it as a single cycle path and will try to use bigger drive strength cells to meet timing. This will result in more area and power; hence, more cost. So, all multicycle paths must be correctly specified as multicycle paths during timing optimization and timing analysis.
Also read: