Forum Discussion
Fitter can't fit a small design in Cyclone V SE that fits in a much smaller Cyclone IV device
Hi,
When I try to compile a design for a Cyclone V 5CSEMA5 that works perfectly on a much smaller Cyclone IV, the fitter says:
Info (170195): Router estimated average interconnect usage is 2% of the available device resources Info (170196): Router estimated peak interconnect usage is 25% of the available device resources in the region that extends from location X22_Y0 to location X32_Y10 Critical Warning (188026): The Fitter failed to successfully route the design. You may be able get this design to route by making design modifications, changing the fitter seed or by enabling the Fitter Aggressive Routability Optimizations logic option. Info (188027): The highest placement effort tried by the fitter during this compile was: 2 Error (170143): Final fitting attempt was unsuccessful Info (170138): Failed to route the following 18 signal(s) Info (170139): Signal "...:_VGA_Controller|X[2]" Info (170139): Signal "...:_VGA_Controller|X[11]" Info (170139): Signal "...:_VGA_Controller|DrawLine_To_X[6]" ... Info (170140): Cannot fit design in device -- following 21 routing resource(s) needed by more than one signal during the last fitting attempt Info (170141): Routing resource LAB Block interconnect (X33_Y17, I10) ... Info (170141): Routing resource LAB Input (X30_Y18, I7) ... Info (170141): Routing resource LAB Internal Resource (X30_Y18, I3) ...
Used ressources are:
Logic utilization (in ALMs) 2,010 / 41,910 ( 5 % ) Total registers 1770 Total pins 70 / 457 ( 15 % ) Total virtual pins 0 Total block memory bits 24,576 / 5,662,720 ( < 1 % ) Total DSP Blocks 8 / 112 ( 7 % ) Total HSSI RX PCSs 0 Total HSSI PMA RX Deserializers 0 Total HSSI TX PCSs 0 Total HSSI PMA TX Serializers 0 Total PLLs 2 / 6 ( 33 % ) Total DLLs 0 / 4 ( 0 % )
and the routing summary that fitter reports is (HPS isn't used at all):
| Block interconnects | 7,585 / 289,320 ( 3 % ) |
| C12 interconnects | 88 / 13,420 ( < 1 % ) |
| C2 interconnects | 2,784 / 119,108 ( 2 % ) |
| C4 interconnects | 1,729 / 56,300 ( 3 % ) |
| DQS bus muxes | 0 / 25 ( 0 % ) |
| DQS-18 I/O buses | 0 / 25 ( 0 % ) |
| DQS-9 I/O buses | 0 / 25 ( 0 % ) |
| Direct links | 698 / 289,320 ( < 1 % ) |
| Global clocks | 3 / 16 ( 19 % ) |
| Horizontal periphery clocks | 0 / 72 ( 0 % ) |
| Local interconnects | 838 / 84,580 ( < 1 % ) |
| Quadrant clocks | 0 / 66 ( 0 % ) |
| R14 interconnects | 537 / 12,676 ( 4 % ) |
| R14/C12 interconnect drivers | 599 / 20,720 ( 3 % ) |
| R3 interconnects | 4,202 / 130,992 ( 3 % ) |
| R6 interconnects | 5,758 / 266,960 ( 2 % ) |
| Spine clocks | 9 / 360 ( 3 % ) |
| Wire stub REs | 0 / 15,858 ( 0 % ) |
The design works perfect on a much smaller device, e.g., EP4CE6E22. So it doesn't seem to be a problem of resources, but I have no idea what the error message "following 21 routing resource(s) needed by more than one signal during the last fitting attempt" exactly means and what I could do to get it compiled on the Cyclone V.
I already changed the fitter initial placement seed and the fitter aggressive routability optimizations option as suggested by the critical warning message. Complete message log attached.
Are there any suggestions?
Regards
Gunar
17 Replies
- aesq
New Contributor
Hi,
As I was facing a similar issue with my project,
I took his example and played with the options, placement and so on.
I found an option that makes the routing ok (I changed to my Cyclone V type).
Intel should investigate why this option makes the routing failing.
See picture showing the option, change it from ON to OFF.
This was tested with Quartus 21.1.1 std.
- RichardT_altera
Super Contributor
I have yet to receive any response from you to the previous question/reply/answer that I have provided but I believed that I have answered your question.
With that, I will now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.
Best Regards,
Richard Tan
p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos. - RichardT_altera
Super Contributor
Hi @gschorcht
Could you try the following methods (that you have not try) shown in the link, to troubleshoot the routing issue?
See if any of it works.
Best Regards,
Richard Tan
p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos.- gschorcht
New Contributor
Hi Richard,
sorry, I had no time to work on the problem in last week, so I didn't answer yet. Unfortunatly, the link doesn't work.Regards
Gunar
- sstrell
Super Contributor
Remove the pin assignments, recompile, and see what happens. There must be something physical as to why such a small design won't fit.
- gschorcht
New Contributor
I removed all assignments using menu Assignments -> Remove Assignments -> All with Remove global assignments and Remove instance assignments checked. It didn't help.
- sstrell
Super Contributor
That is very odd.
Is it still saying the same signals cannot be routed? There must be something about them that is causing the issue. Are they part of an off-the-shelf IP you've added to the design from the IP Catalog? Perhaps the IP needs to be regenerated to work with the different device, though Quartus would usually indicate this to you.
Otherwise, I'm stumped.
- RichardT_altera
Super Contributor
Hi @gschorcht
May I know does the suggestion from sstrell helps?Do you need further help in regards to this case?
Best Regards,
Richard Tan
- gschorcht
New Contributor
Hi,
thanks for your answers. There are no other placement requirements than the pin assignments which seem to be correct.
I have also played with fitter setting according to the Routing Resource Usage section in Resource Optimization Advisor with no success. Even though the Chip Planner reports a maximum routing utilization of 77 %, the blocks reported in error messages are different.
Regards
Gunar
- sstrell
Super Contributor
You probably have some type of placement requirement for a specific resource that is not available in the new device. With that amount of resource use, you do not need to mess with the seed. Check the Assignment Editor and/or Pin Planner (or Chip Planner for Logic Lock regions) to see if you are forcing the placement of something that is preventing the design from compiling.