Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16558 Discussions

Dose quartus use any Black magic to constrain dcfifo(gray code pointer)?

Altera_Forum
Honored Contributor II
1,873 Views

First of all, sorry for my poor English, I'm from China. 

 

The question is about gray code pointers in the async fifo. 

 

There are some similar post here: 

http://www.alteraforum.com/forum/showthread.php?t=44720 

http://www.alteraforum.com/forum/showthread.php?t=37134 

http://www.alteraforum.com/forum/showthread.php?t=3373 

 

But I'm still confused 

 

To my knowledge, the delay of gray code pointer in the async fifo should not delay exceed 1 clk cycle of transmit clk, or the fifo will be failed. 

 

The delay is from register of source clk to register of destination clk, and exclude the clock skew. 

 

In the 《SCFIFO and DCFIFO IP Cores User Guide》,which is the altera megacore fifo user guide,it says that “ 

When using the Quartus II TimeQuest timing analyzer with a design that contains a DCFIFO block apply 

the following false paths to avoid timing failures in the synchronization registers: 

•For paths crossing from the write into the read domain, apply a false path assignment between the 

delayed_wrptr_g and rs_dgwp registers: 

set_false_path -from [get_registers {*dcfifo*delayed_wrptr_g 

[*]}] -to [get_registers 

{*dcfifo*rs_dgwp*}] 

•For paths crossing from the read into the write domain, apply a false path assignment between the 

rdptr_g and ws_dgrp registers: 

set_false_path -from [get_registers {*dcfifo*rdptr_g 

[*]}] -to [get_registers 

{*dcfifo*ws_dgrp*}] 

The false path assignments are added through the HDL-embedded Synopsis design 

constraint (SDC) commands when you compile your design. The related message is shown under the 

TimeQuest timing analyzer report. 

Note: The constraints are internally applied but are not written to the Synopsis Design Constraint File 

(.sdc). To view the embedded-false path, type report_sdc in the console pane of the TimeQuest 

timing analyzer GUI. 

” 

 

 

 

Question 1:Quartus automatically add set_false_path constrain to the gray code pointer, but how quartus confirm that the delay dose't exceed 1 clock period of source clock? Dose the fitter have some black magic to place the registers as close as possible? 

 

 

note: The set_false_path constrain has the highest priority 

 

 

 

 

 

 

 

 

Sometimes, users may use some gray code in design(e.g handwrite fifo......), and don't use ther altera's DCFIFO megacore. 

To constrain the 1 clock period dealy, in the timequest the closest constrain is set_max_delay. But if we use it to constrain the gray code pointer, it will calculate the clock skew also. This is totally wrong, but it should calcute the data path rout delay only. 

 

When I generate the async fifo in the vivado of xilinx , I can find that the tool generate the set_max_delay constrain in the XDC file, with the option "datapath_only". And I think that's what I need. 

 

 

 

Question 2:In this case, what constrain should be added in the SDC file? 

0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
412 Views

For Grey counter there are two paths to consider: 

 

i) clk1 to clk2 registers (async path): This will violate timing and set false path is essential to stop warnings or affect timing closure efforts. 

 

ii) The synchroniser chain path (on same destination clock) This should pass timing though physically will be violated due to metastability. 

MTBF can be reduced by some factors, one of them is that this path should have optimum slack. This is where controlling delay is helpful. 

whether done in sdc command or fitter does it automaticlly.
0 Kudos
Altera_Forum
Honored Contributor II
412 Views

In Q15.0 a constraint change is being made to these cases. set_false_path is being removed and set_net_delay is being used to constrain the datapath, while set_max_delay 100 and set_min_delay -100 are used to override the clock waveforms' derived setup/hold requirements. set_max_skew is also being added for multi-bit bus transfers that need a skew requirement. set_net_delay and set_max_skew now have new options as well to derive their values based on the clock periods of the clocks involved in the transfer. 

 

You can generate the net delay and skew constraints using the get_value_from_clock_period calls and the value_multiplier options to scale to a % of the clock period you select. 

 

Usage: set_max_skew [-h | -help] [-long_help]  

[-exclude <Tcl list>]  

[-fall_from_clock <names>]  

[-fall_to_clock <names>]  

[-from <names>]  

[-from_clock <names>]  

[-get_skew_value_from_clock_period <src_clock_period|dst_clock_period|min_clock_period>]  

[-include <Tcl list>]  

[-rise_from_clock <names>]  

[-rise_to_clock <names>]  

[-skew_value_multiplier <multiplier>]  

[-through <names>]  

[-to <names>]  

[-to_clock <names>]  

[<skew>] 

 

Usage: set_net_delay [-h | -help] [-long_help]  

[-from <names>] 

[-get_value_from_clock_period <src_clock_period|dst_clock_period|min_clock_period|max_clock_period> ]  

[-max] 

[-min]  

[-to <names>]  

[-value_multiplier <multiplier>] 

[<delay>]
0 Kudos
Altera_Forum
Honored Contributor II
412 Views

Excellent! This is the proper way to do it. Xilinx's datapath_only is better than cutting the path altogether, but it doesn't account for clock skew between different bits of the gray code counter. Hopefully it's small, but shouldn't be ignored. Glad to see this being done right. 

 

Does the user have to do this for the DCFIFO, or is it done already? Is the set_false_path embedded in the RTL still there, and if so how do they interact? Do you have an example?
0 Kudos
Altera_Forum
Honored Contributor II
412 Views

 

--- Quote Start ---  

In Q15.0 a constraint change is being made to these cases. set_false_path is being removed and set_net_delay is being used to constrain the datapath, while set_max_delay 100 and set_min_delay -100 are used to override the clock waveforms' derived setup/hold requirements. set_max_skew is also being added for multi-bit bus transfers that need a skew requirement. set_net_delay and set_max_skew now have new options as well to derive their values based on the clock periods of the clocks involved in the transfer. 

 

You can generate the net delay and skew constraints using the get_value_from_clock_period calls and the value_multiplier options to scale to a % of the clock period you select. 

 

Usage: set_max_skew [-h | -help] [-long_help]  

[-exclude <Tcl list>]  

[-fall_from_clock <names>]  

[-fall_to_clock <names>]  

[-from <names>]  

[-from_clock <names>]  

[-get_skew_value_from_clock_period <src_clock_period|dst_clock_period|min_clock_period>]  

[-include <Tcl list>]  

[-rise_from_clock <names>]  

[-rise_to_clock <names>]  

[-skew_value_multiplier <multiplier>]  

[-through <names>]  

[-to <names>]  

[-to_clock <names>]  

[<skew>] 

 

Usage: set_net_delay [-h | -help] [-long_help]  

[-from <names>] 

[-get_value_from_clock_period <src_clock_period|dst_clock_period|min_clock_period|max_clock_period> ]  

[-max] 

[-min]  

[-to <names>]  

[-value_multiplier <multiplier>] 

[<delay>] 

--- Quote End ---  

 

Can you give a sample of the usage of set_net_delay?  

I want to constrain the datapath between {u6|out~32_I|combout} with {u6|out~40_I|datac}, and the datapath is combinational logic. Can I use set_net_delay to achieve this?  

Can the set_net_delay be used in Quartus II 9.1?
0 Kudos
Reply