cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
4,813 Views
Registered: ‎07-07-2016

DONT_TOUCH, ASYNC_REG and falling edge flip-flop

Jump to solution

Hi,

 

I use Vivado 2016.2 and I put objet properties in a XDC constraint file (i don't want to modify the existing code).

 

In my design, I specify a lot of synchronizers by using the ASYNC_REG = TRUE property on both synchronizer flip-flops (FF).

Several synchronizers have a large fanout so the second FF is duplicated by Vivado.

In order to prevent these duplications, I also set the DONT_TOUCH = TRUE property on both synchronizer FF.

But now, Vivado adds a NOT LUT for the FFs that are driven by my clock falling edge...

 

Could you confirm that the ASYNC_REG property do not prevent Vivado to duplicate the FF ?

For the falling edge driven FFs, how should I constraint my design (I would like ASYNC_REG = TRUE, no duplication and a clock inverted FF) ?

 

I don't want to completely disable the tool duplications because it is useful in my design in other cases.

 

Best regards

0 Kudos
Reply
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
8,633 Views
Registered: ‎05-07-2015

HI @robby

Instead of applying dont_touch , which prevents the tool from doing other essential stuff.

I suggest you apply MAX_FANOUT attribute on the signal driven the second FF and set it to very high value.
(note: this might in turn lead to timing violations due to high net delays)

MAX_FANOUT instructs Vivado synthesis on the fanout limits for registers and signals. You can specify this either in RTL pr XDC. The value is an integer. This attribute only works on registers and combinatorial signals.  Applying this in RTL is the  best way.

verilog and VHDL  usage examples are in page 55 of UG901
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug901-vivado-synthesis.pdf

 

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------

View solution in original post

0 Kudos
Reply
3 Replies
Xilinx Employee
Xilinx Employee
8,634 Views
Registered: ‎05-07-2015

HI @robby

Instead of applying dont_touch , which prevents the tool from doing other essential stuff.

I suggest you apply MAX_FANOUT attribute on the signal driven the second FF and set it to very high value.
(note: this might in turn lead to timing violations due to high net delays)

MAX_FANOUT instructs Vivado synthesis on the fanout limits for registers and signals. You can specify this either in RTL pr XDC. The value is an integer. This attribute only works on registers and combinatorial signals.  Applying this in RTL is the  best way.

verilog and VHDL  usage examples are in page 55 of UG901
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug901-vivado-synthesis.pdf

 

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------

View solution in original post

0 Kudos
Reply
Highlighted
Visitor
Visitor
4,777 Views
Registered: ‎07-07-2016

Hi @nagabhar

 

I apply MAX_FANOUT on each ASYNC_REG = TRUE FF and it works fine. Thank you.

 

In my example, I have a global list of my FFs, I apply ASYNC_REG on it and MAX_FANOUT on the FF output nets.

set my_ff_list {......}

set_property ASYNC_REG TRUE [get_cells $my_ff_list]

set_property MAX_FANOUT 99999 [get_nets -of_objects [get_pins -filter "direction == out" -of_objects [get_cells $my_ff_list]]]

 

 

0 Kudos
Reply
Highlighted
Xilinx Employee
Xilinx Employee
4,761 Views
Registered: ‎05-07-2015

HI @robby

Good to know that.
As I said , the only possible issue with this approach would be the high net delay from second FF to another endpoint in dest clock domain which is OK as long as timing is met.

 

All the best

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Reply