Multipath timing constraints not giving expected results

[Altera_Forum]

Hi all, 

  I am trying to constrain the timing for a design, where a part of the design resembles the included schematic. The paths which are failing timing are between two registers, where the launch register is driven by a slower clock (200MHz, 5ns), and the latch register is driven by a clock having twice the frequency (400MHz, 2.5ns). There is also a multiplexer before the latch register which selects the long, failing path for every other clock edge of the fast clock. This should mean that the long, failing, path should have 5ns, rather than the 2.5ns that TimeQuest is currently allowing it, as shown in the image.   http://www.alteraforum.com/forum/attachment.php?attachmentid=13226&stc=1    As a result, after the design had compiled, I added the following multipath constraint:   set_multicycle_path -from {design_top:u_d|proc:gen_proc .u_p|source_reg } -to {design_top:u_d|proc:gen_proc .u_p|ram_true_dual:u_ram|altsyncram:*|*:*|*} -setup -end 2   This constraint appeared to work, since the paths now reported a small positive slack after refreshing TimeQuest. However, after re-running the synthesis again, the paths were failing timing, despite the multi-cycle constraint. At the bottom of the page are the reports for the path, after synthesis with and without the constraint.   To further test what was happening, I replaced the clock of the destination register with the same clock as the source register, and removed the multipath constraint. After running synthesis again, the paths in question were not failing timing.   Are there any other constraints that are needed in order to get Quartus to handle this path as intended?  Thanks.      AFTER APPLYING MULTIPATH, AND REFRESHING TIMEQUEST Path# 1: Setup slack is -0.597 (VIOLATED) =============================================================================== +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ; Path Summary ; +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ ; Property ; Value ; +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ ; From Node ; design_top:u_d|proc:gen_proc.u_p|source_reg ; ; To Node ; design_top:u_d|proc:gen_proc.u_p|ram_true_dual:u_ram|altsyncram:altsyncram_component|altsyncram_fur2:auto_generated|ram_block1a0~porta_datain_reg1 ; ; Launch Clock ; clk ; ; Latch Clock ; clk2x ; ; Multicycle - Setup End ; 2 ; ; Data Arrival Time ; 8.801 ; ; Data Required Time ; 8.204 ; ; Slack ; -0.597 (VIOLATED) ; +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ AFTER APPLYING MULTIPATH, AND RE-SYNTHESIS Path# 1: Setup slack is -2.299 (VIOLATED) =============================================================================== +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ; Path Summary ; +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ ; Property ; Value ; +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ ; From Node ; design_top:u_d|proc:gen_proc.u_p|source_reg ; ; To Node ; design_top:u_d|proc:gen_proc.u_p|ram_true_dual:u_ram|altsyncram:altsyncram_component|altsyncram_fur2:auto_generated|ram_block1a0~porta_datain_reg1 ; ; Launch Clock ; clk ; ; Latch Clock ; clk2x ; ; Multicycle - Setup End ; 2 ; ; Data Arrival Time ; 10.459 ; ; Data Required Time ; 8.160 ; ; Slack ; -2.299 (VIOLATED) ; +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+

[Altera_Forum]

OK, so the signal you have labeled "mux" in the picture, the mux select, is clk2x? 

 It sounds like you are constraining correctly. It would be helpful to see the waveform tab from a detailed timing report in TimeQuest to make sure your multicycle constraint is correct. You might need a hold multicycle as well since the setup multicycle is moving the hold analysis along with it. Also, are you only failing setup or is hold an issue as well?  It would also be helpful to see the Data Path tab in the report to see where most of the delay is occurring. If it's long IC (interconnect) delay, the registers may be placed too far apart from each other for some reason.

[Altera_Forum]

How about re-registering both inputs to the mux with clk2x? Then everything before and after the mux is in the clk2x domain and you don't have to worry about the multicycle constraints. You should easily be able to meet the reg-to-reg timing from clk to clk2x without the mux in the path. 

 Another way to skin the cat if this will work for you.

[Altera_Forum]

I second rsefton's idea.  

The default setup relationship is 2.5ns. When you add a multicycle -setup 2, then the default relatinoship moves to 5ns, which should make timing much easier to meet. But the default hold timing shifts with the setup relationship(long explanation, and maybe look at my TimeQuest User Guide on alterawiki.com for more details), but basically the hold relationship is now a positive 2.5ns. You've shifted the latch window over one cycle, but not made it any bigger. So the router has to add delay to meet the hold timing at the slow corner, and you still fail setup. Really annoying. When you want to make the latch window bigger, you need to add a multicycle setup of N and multicycle hold of (N-1). So in this case: set_multicycle_path -from {design_top:u_d|proc:gen_proc[*].u_p|source_reg[*]} -to {design_top:u_d|proc:gen_proc[*].u_p|ram_true_dual:u_ram|altsyncram:*|*:*|*} -setup -end 2 set_multicycle_path -from {design_top:u_d|proc:gen_proc[*].u_p|source_reg[*]} -to {design_top:u_d|proc:gen_proc[*].u_p|ram_true_dual:u_ram|altsyncram:*|*:*|*} -hold -end 1 Now your setup relationship is 5ns and your hold relationship should be 0ns, and it should meet timing.

[Altera_Forum]

Thanks all for your replies. 

 I have looked further into the issue, and it seems to be because I've been ignoring hold. Adding the extra constraint -hold 1 seems to solve the issue.  I have attached the timing waveforms for the original no multicycle case; the -setup 2 case; and the -setup 2 -hold 1 case.  The waveforms show how when I applied the -setup 2 constraint, but did not re-run synthesis, the 2.47ns hold slack would be reduced to -0.03ns, which I had not noticed before. After running synthesis with the -setup 2 constraint then did not improve the timing due to the hold constraint which I had not considered.  The -setup 2 -hold 1 constraint solves the issue, assuming the -hold 1 constraint is what I want, given the initial schematic. I may end up putting a register, clocked by clk2x, in the middle of the long path. My only concern with this is that I would have to try to place the register in the middle of the path, however Quartus should hopefully move the register along the path as it feels fit in order to offer the best timing.  http://www.alteraforum.com/forum/attachment.php?attachmentid=13233&stc=1 imgur link (the forum seems to remove all the detail from the image) (http://i.imgur.com/pyjaiay.png) http://i.imgur.com/pyjaiay.png

[Altera_Forum]

Thanks all for your replies. 

 I have looked further into the issue, and it seems to be because I've been ignoring hold. Adding the extra constraint -hold 1 seems to solve the issue.  I have attached the timing waveforms for the original no multicycle case; the -setup 2 case; and the -setup 2 -hold 1 case.  The waveforms show how when I applied the -setup 2 constraint, but did not re-run synthesis, the 2.47ns hold slack would be reduced to -0.03ns, which I had not noticed before. After running synthesis with the -setup 2 constraint then did not improve the timing due to the hold constraint which I had not considered.  The -setup 2 -hold 1 constraint solves the issue, assuming the -hold 1 constraint is what I want, given the initial schematic. I may end up putting a register, clocked by clk2x, in the middle of the long path. My only concern with this is that I would have to try to place the register in the middle of the path, however Quartus should hopefully move the register along the path as it feels fit in order to offer the best timing.  Timing waveforms: http://i.imgur.com/pyjaiay.png

[Altera_Forum]

Thanks all for your replies. 

 I have looked further into the issue, and it seems to be because I've been ignoring hold. Adding the extra constraint -hold 1 seems to solve the issue.  I have attached the timing waveforms for the original no multicycle case; the -setup 2 case; and the -setup 2 -hold 1 case.  The waveforms show how when I applied the -setup 2 constraint, but did not re-run synthesis, the 2.47ns hold slack would be reduced to -0.03ns, which I had not noticed before. After running synthesis with the -setup 2 constraint then did not improve the timing due to the hold constraint which I had not considered.  The -setup 2 -hold 1 constraint solves the issue, assuming the -hold 1 constraint is what I want, given the initial schematic. I may end up putting a register, clocked by clk2x, in the middle of the long path. My only concern with this is that I would have to try to place the register in the middle of the path, however Quartus should hopefully move the register along the path as it feels fit in order to offer the best timing.  https://www.alteraforum.com/forum/attachment.php?attachmentid=13246  (I tried to respond a couple of days ago, but the post is still waiting moderation because, I assume, I linked to an external image hosting site to get around the image resizing on the forum. As a result, a duplicate of this post may appear later... )

[Altera_Forum]

your mux is running on 2x rate (from diagram) so multicycle of 2 does not apply. 

 if you put one register on A before mux and on B before mux it might help timing