Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

Fitter can't fit a small design in Cyclone V SE that fits in a much smaller Cyclone IV device

gschorcht
Beginner
1,749 Views

 

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

0 Kudos
17 Replies
sstrell
Honored Contributor III
1,715 Views

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.

0 Kudos
RichardTanSY_Intel
1,699 Views

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

 

0 Kudos
gschorcht
Beginner
1,672 Views

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

0 Kudos
sstrell
Honored Contributor III
1,636 Views

Remove the pin assignments, recompile, and see what happens.  There must be something physical as to why such a small design won't fit.

0 Kudos
gschorcht
Beginner
1,612 Views

I removed all assignments using menu Assignments -> Remove Assignments -> All with Remove global assignments and Remove instance assignments checked. It didn't help.

0 Kudos
sstrell
Honored Contributor III
1,593 Views

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.

0 Kudos
gschorcht
Beginner
1,454 Views

Yes, it's the same signals that can't be routed. The design does not use any IPs from the IP catalog with the exception of a PLL.

0 Kudos
gschorcht
Beginner
1,421 Views

I could reduce the design to the module for which I get the routing errors, and I could reduce the module itself to the parts that don't fit. The reduced design can be found as an attachment.

The design fits only if you comment out either line 117, line 123 or line 124 in the VGA_GraphicsController.sv file.

0 Kudos
gschorcht
Beginner
1,225 Views

@sstrell May I politely ask you to take a look on my minimized design attached to this reply to give me a clue what I am doing wrong that the fitter can't route all the signals of this very small design. I have absolutely no idea, but something must be wrong with the design. I would really appreciate any advice. I have really tried everything to get it working. Thanks.

0 Kudos
sstrell
Honored Contributor III
1,219 Views

Since the issue occurs when accessing Data, which is an array (a memory), the issue could have to do with the way memory is implemented in the older device vs. the newer one.  Check to see how Data is getting implemented, as logic blocks or memory.

I don't know what else it could be.

0 Kudos
gschorcht
Beginner
1,210 Views

@strell Thank you for looking at my design.

`Data` is implemented as logic, probably because several elements are read in same clock cycle. I already tried to replace this array by separate register variables, but that didn't help either.

0 Kudos
RichardTanSY_Intel
1,520 Views

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. 

https://www.intel.com/content/www/us/en/programmable/quartushelp/current/index.htm#msgs/msgs/wvpr20k_vpr_no_route_suggestion_message.htm

 

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos. 

 

0 Kudos
gschorcht
Beginner
1,455 Views

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

0 Kudos
gschorcht
Beginner
1,378 Views

Hi Richard,

I am really stumped and have no idea what I am doing wrong.

  • I have reduced the design to an absolute minimum so that the logic utilization is only 282/32070 ( < 1%) but the routing problem is still reproducible.
  • During fitter process, the router shows an estimated average interrconnect usage of 0% and an estimated peak interconnect usage of only 7%.
  • In the Chip Planner no routing congestions are shown, the maximum routing utilization is 68 %, see the screenshot attached. There doesn't seem to be any congestion.
  • I have neither timing contraints nor assignment constraints, so the fitter has a maximum degree of freedom.
  • Enabling the Fitter Aggressive Routability Optimizations logic option doesn't help.
  • I can't generate a Global Router Wire Utilization Map with Quartus II Lite 20.1 for Cyclone V (at least I didn't find a way in the Quartus Help).

I don't know whats wrong with my design and how it could be solved. It just contains about 100 wires that are shared by two modules. The design can be found attached.

Any help is welcome. As mentioned earlier, the original and much larger design works perfectly on a much smaller Cyclone IV.

Regards
Gunar

0 Kudos
RichardTanSY_Intel
1,491 Views

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. 

0 Kudos
aesq
Novice
277 Views

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.

 

0 Kudos
Reply