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

[gschorcht]

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

[sstrell]

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.

[RichardTanSY_Intel]

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]

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]

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]

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

[sstrell]

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.

[gschorcht]

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.

[gschorcht]

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.

[gschorcht]

@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.

[sstrell]

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.

[gschorcht]

@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.

[RichardTanSY_Intel]

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. 

[gschorcht]

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

[RichardTanSY_Intel]

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

[gschorcht]

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

[RichardTanSY_Intel]

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. 

[aesq]

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.