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:
Hello,
ReplyDeleteIf I get the SDC syntax right, there might be a typo in the command that is supposed to 'bring back the hold check 2 cycles back to zero cycle [..] as shown in Figure 5 in blue':
set_multicycle_path -hold 2 -from ff1/Q -to ff2/D
I think it should rather be:
set_multicycle_path -hold 1 -from ff1/Q -to ff2/D
Please disregard my comment if I got the syntax wrong :)
And thank you so much for all the invaluable material you shared through this site!
Ciao,
Paolo
Hi Paolo
DeleteNo, the figure is relaxing hold check by 2 cycles, so hold multicycle should be 2 cycles only. And thanks for appreciation.
I think,
ReplyDeleteat figure 8, blue line for set_muliticycle_path 2 -setup ..-start
not correct
-> It means,2 cycle in term of start clock
blue line only 1,5 cycle of start clock
Hi
Delete"set_multicycle_path n -setup" means that you get "n-1" cycle extra than default setup check.
I agree with Hung. This multicycle here doesn't makes sense to me as well. What we are saying effectively that every 1.5 Cycle launch clock will send data. But launch clock can send data either every clock cycle or every 2 clock cycle. If it sends data every cycle then capture clock wont be able to take that data at that pace & there will be data loss. If the launch clock sends data every 2 cycle, then the MCP should be worst 2 cycle of launch clock.
DeleteIn my view, when we apply MCP between slow & fast clock, the MCP is always applied wrt the faster clock. Please let me know if I am missing something.
yes, but what you have drawn is 1.5 extra cycles instead of 2. Look at the start clock, you've drawn the blue line to the negative edge, making it 1.5 cycles instead of the 2.
ReplyDeleteHi
DeleteMulticycle path of "n" means (n-1) cycles extra than default setup check. In this case, default setup check was 0.5 cycles; hence, MCP of 2 is 1.5 cycles of the clock with higher period.
I guess I missed that the default is always based on the capture clock. Thanks.
DeleteThanks a lot ! Without your explaintion ,I would still don't undertand exactlly.
DeleteI am wondering what the waveforms would be looked like for fig8 and fig9 if multicycle for setup are 3, for hold are 2.
ReplyDeleteWhat is the meaning if we give set_multicycle_path -setup 3 -from [get_pins {ff1/q}]
ReplyDeleteIt will mean that all the timing paths starting from ff1/q will get 2 extra cycles with respect to start clock. However, i see a basic issue in this statement, most of the tools will allow only "-through ff1/q", since flop/q pin is not a timing startpoint.
Delete