UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor aikgg
Visitor
3,320 Views
Registered: ‎05-05-2017

UCF constraints for reset synchronizer

Jump to solution

I have a "reset bridge" in my scheme. And i have XDC constraints, how to correctly translate them into UCF?

XDC constraints:

 

set_property ASYNC_REG TRUE [get_cells {ldpc_top_inst/rst_sync_inst/pos_act_edge_rstn.rff1_reg ldpc_top_inst/rst_sync_inst/pos_act_edge_rstn.rff2_reg}]
set_max_delay -from [get_cells ldpc_top_inst/rst_sync_inst/pos_act_edge_rstn.rff1_reg] -to [get_cells ldpc_top_inst/rst_sync_inst/pos_act_edge_rstn.rff2_reg] 2
set_false_path -to [get_cells ldpc_top_inst/rst_sync_inst/pos_act_edge_rstn.rff1_reg]

I tried to convert them to UCF, but it seems to me that I'm doing something wrong:

 

INST "ldpc_top_inst/rst_sync_inst/rff1" ASYNC_REG = TRUE; 
INST "ldpc_top_inst/rst_sync_inst/rff2" ASYNC_REG = TRUE;

NET "ldpc_top_inst/rst_sync_inst/rff1" MAXDELAY = 2ns;

And I do not understand how to translate these part:

 

 

set_false_path -to [get_cells ldpc_top_inst/rst_sync_inst/pos_act_edge_rstn.rff1_reg]

 

 

Reset_bridge.png

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
5,933 Views
Registered: ‎01-23-2009

Re: UCF constraints for reset synchronizer

Jump to solution

@aikgg

 

 

I am not sure where you are getting your XDC constraints from. The naming convention is odd (with a . before the last hierarchical name) - that is not standard, it should be a slash, and your names have "extra stuff" in them (at least based on your schematic). Furthermore, the set_false_path is insufficient; it needs to go to both flip-flops, not just the first.

 

Other than the naming of the XDC, the ASYNC_REG constraints look correct in the UCF.

 

The mechanisms both you and @viviany used for the MAXDELAY are both OK, yours constraints the routing delay on the NET, Vivian's constrains the path delay. They are slightly different, but both accomplish what you want.

 

Similarly, the TIG constraint that Vivian gave is correct for the one pin you have in the set_false_path, but there should be another one for the other FF - so

 

PIN "ldpc_top_inst/rst_sync_inst/rff2.CLR" TIG;

 

should be added.

 

If the net driving the C pins has a name that you know, and it can go nowhere else then you can do

 

NET "<name_of_net> TIG;

 

instead.

 

Avrum

Tags (2)
2 Replies
Xilinx Employee
Xilinx Employee
3,254 Views
Registered: ‎05-14-2008

Re: UCF constraints for reset synchronizer

Jump to solution

The "NET MAXDELAY" in UCF is not equal to the set_max_delay in XDC. A more appropriate UCF constraint is "FROM TO". The "FROM TO" constraint counts for the setup/hold spec of FFs and the clock skew, while "NET MAXDELAY" only constrain the routing delay of the net between the FFs.

TIMESPEC TS_maxdelay = FROM FFS(ldpc_top_inst/rst_sync_inst/rff1) TO FFS(ldpc_top_inst/rst_sync_inst/rff2) 2ns;

 

As for the set_false_path, you can use TIG constraint.

PIN "ldpc_top_inst/rst_sync_inst/rff1.CLR" TIG;

 

Thanks

Vivian

Highlighted
Historian
Historian
5,934 Views
Registered: ‎01-23-2009

Re: UCF constraints for reset synchronizer

Jump to solution

@aikgg

 

 

I am not sure where you are getting your XDC constraints from. The naming convention is odd (with a . before the last hierarchical name) - that is not standard, it should be a slash, and your names have "extra stuff" in them (at least based on your schematic). Furthermore, the set_false_path is insufficient; it needs to go to both flip-flops, not just the first.

 

Other than the naming of the XDC, the ASYNC_REG constraints look correct in the UCF.

 

The mechanisms both you and @viviany used for the MAXDELAY are both OK, yours constraints the routing delay on the NET, Vivian's constrains the path delay. They are slightly different, but both accomplish what you want.

 

Similarly, the TIG constraint that Vivian gave is correct for the one pin you have in the set_false_path, but there should be another one for the other FF - so

 

PIN "ldpc_top_inst/rst_sync_inst/rff2.CLR" TIG;

 

should be added.

 

If the net driving the C pins has a name that you know, and it can go nowhere else then you can do

 

NET "<name_of_net> TIG;

 

instead.

 

Avrum

Tags (2)