cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
648 Views
Registered: ‎09-25-2019

Hold Timing Fixes in Synplify Netlist

I am using a netlist synthesized in Synplify for a portion of my design. The netlist is added to Vivado as a .vm file (Verilog netlist). The rest of the design is in Vivado, using the typical "IP Integrator" flow. This is for a Kintex Ultrascale part.

During Implementation, I am unable to achieve timing closure. There are hold violations in paths internal to this Synplify netlist. What’s curious is the hold time violations are constant for these nets that are failing, even after tweaking certain things like Implementation strategies and clock uncertainty parameters. It seems like the tool is not even attempting hold fixes.

Xilinx support has advised me that Vivado sees a Synplify netlist the same as its own, and this shouldn't impact whether hold fixes are applied or not. I was also advised to look for "DONT_TOUCH" or "MARK_DEBUG" attributes that may be preventing fixes, however, I have found none.

Does anyone know of any interactions between Synplify or Vivado that would prevent this? Any settings to tweak? Any help or insight would be greatly appreciated!

0 Kudos
Reply
6 Replies
Voyager
Voyager
643 Views
Registered: ‎06-20-2012

Is the clock with hold errors external or generated within Synplify netlist ?

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
Visitor
Visitor
634 Views
Registered: ‎09-25-2019

Thanks for the reply.

It is generated external to the Synplify netlist

0 Kudos
Reply
Voyager
Voyager
614 Views
Registered: ‎06-20-2012

Have checked if the clock network is connected to a clock buffer ?

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
0 Kudos
Reply
Guide
Guide
584 Views
Registered: ‎01-23-2009

Why don't you post a complete path report for one of the failing hold time checks?

Avrum

0 Kudos
Reply
Visitor
Visitor
581 Views
Registered: ‎09-25-2019

Yes it is, the clock is generated by a Xilinx MMCM, and then goes through a clock buffer.

And unfortunately, I cannot post a path report. 

0 Kudos
Reply
Visitor
Visitor
485 Views
Registered: ‎09-25-2019

I will add, regarding the data path: the source primitive is SRLC32E (32-bit shift register LUT), there is routing (net) delay, and the destination primitive is SRL16E (16-bit shift register LUT)

0 Kudos
Reply