cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
535 Views
Registered: ‎03-22-2018

[Place 30-487] error

Hi,

I've got a Zynq 7020 design with a lot of clocks and clock buffers.
When I add another clock to a MMCM, implementation fails: 

[Place 30-487] The packing of instances into the device could not be obeyed. There are a total of 13300 slices in the pblock, of which 10019 slices are available, however, the unplaced instances require 10201 slices. Please analyze your design to determine if the number of LUTs, FFs, and/or control sets can be reduced.

Number of control sets and instances constrained to the design
Control sets: 2165
Luts: 44122 (combined) 51467 (total), available capacity: 53200
Flip flops: 63321, available capacity: 106400
NOTE: each slice can only accommodate 1 unique control set so FFs cannot be packed to fully fill every slice

Synthesis utilization is moderate. Control set limit has been updated to a huge number.
How can I find out the clock buffer which limits the placement task? Is there a report which clock regions will be used by a clock or how many clocks are/can be placed in a specific region? The pblock is not named, so I cannot search for specific cells.
Is there any advice?

Thanks

0 Kudos
3 Replies
Highlighted
Moderator
Moderator
502 Views
Registered: ‎05-08-2012

Hi @fuxx_14 

I would try the following:

place_ports

report_clock_utilization -file clk_util.rpt -write_xdc placer_floorplan.xdc

The clk_util.rpt will give you a break down of buffers, global clocks, and their locations. The placer_floorplan.xdc will have specific floorplan constraints generated by the placer to partition the clocks. This should help in finding the cause.


-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

 

 

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
466 Views
Registered: ‎03-22-2018

It was really hard to find out that the additional clock was not the real cause of the routing problem - we've already had a very high usage of control sets before.

So I switched from Vivado 2017.3.1 to version 2018.3, because there's a much better report of the control sets (used instances).

Is there a possibility to (graphically) report the bottlenecks of control set usage?
As we found out sometimes asynchronous resets were coded, but it could be solved with synchronous resets.

 

0 Kudos
Highlighted
Moderator
Moderator
417 Views
Registered: ‎01-16-2013

@fuxx_14 

 

Try using below command and check if it helps:

report_control_sets -hierarchical

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos