Issue with ResNet18 Context Synthesis Step 16/19 in FINN - Possible BRAM, CPU RAM or FPGA Size Limitation?

[omarghoneim3]

Hello,
I'm currently running FINN on Ubuntu within a virtual machine (with 26GB allocated). I successfully used the end-to-end example for the cyber model, and it worked fine on my computer. Encouraged by that, I tried implementing ResNet18 on the same setup.

Everything is working perfectly except for the Context Synthesis step (16/19) in which its stay stuck. At this step, Vivado doesn't seem to show any activity. The top function indicates no visible progress either.

Here are some relevant details about my setup:

1. FPGA Board: Nexys Video
2. Part: xc7a200tfbg484-2
3. BRAM (18K): Reported usage is 1192 out of the available 1350

This suggests I'm nearing the BRAM limit of the FPGA. I'm not sure if this is the root cause of the issue or if there's something else that might be causing the hang at step 16/19.

Do I need a significantly larger FPGA for ResNet18, or another CPU?

Thanks in advance!

[fpjentzsch]

Hi,
you could look into the log files (vivado.log and runme.log of individual runs) in the temporary Vivado project in FINN_BUILD_DIR to see what Vivado might be working on during the hang.

[omarghoneim3]

Thank you for the suggestion! I’ve checked the logs (vivado.log and runme.log) as you recommended. Here’s what I’ve observed so far:
1)There are critical warnings about AXIS interface attributes: Example: "Misformed interface info attr: xilinx.com:interface:axis:1.0 m_axis_0".
2)There are also clock parameter warnings: Example: "Clock interface 'ap_clk' has no FREQ_HZ parameter."
3) The design includes a large number of AXIS-based components (e.g., StreamingFIFO, ConvolutionInputGenerator), and the reported BRAM usage is 1192 out of 1350. This suggests I might be nearing the resource limits of the FPGA (Nexys Video - xc7a200tfbg484-2).
4)Vivado Context Synthesis stalls during Step 16/19, with no visible progress, even though it seems to generate the required hardware definition files (.v, .hwh, etc.).
vivado.log
I suspect the issue may involve resource bottleneck, given the high BRAM usage and module count or Metadata/configuration issues with AXIS interfaces and clock/reset signals.
Could you please clarify:
Are these AXIS attribute warnings typical for FINN-generated designs, and how can they be resolved?
Do you think the FPGA resource constraints (e.g., BRAM usage) are the primary cause, or should I focus on fixing these interface warnings first?

[fpjentzsch]

This vivado.log is from a "vivado_stitch_proj_*" folder, right? It indicates that Vivado successfully ran until completion.
If it hangs during step_out_of_context_synthesis, you'll need to look in the corresponding "synth_out_of_context_*" build dir.

These warnings are typical for FINN-generated designs. The BRAM usage could be the issue, but I think an "endless" Vivado runtime is more likely due to severely over-utilized LUTs or routing, rather than slightly over-utilized BRAM alone.

If it was crashing due to RAM exhaustion, you would see errors in FINN's output as it would not be able to find the expected output files.

[omarghoneim3]

Thank you for the guidance! I’ve checked the LUT utilization, and it’s only 27,000 out of 200,000, so LUTs don’t appear to be the issue. This makes me suspect the problem might be related to:

1. Routing congestion: Possibly due to the interconnections between the numerous AXIS components.
2. Other resource constraints: While BRAM usage is high (1192/1350), it might be contributing to routing or timing challenges.

I’ll investigate further in the synth_out_of_context directory, as you suggested. Could you advise on:

1. Strategies for identifying and resolving potential routing congestion?
2. Common adjustments in FINN to simplify routing or optimize interconnect design?
3. Which specific logs or files I should check in the synth_out_of_context_* folder, and any particular keywords, warnings, or errors I should look for?

[DriesDriessens]

@omarghoneim3 , do you have any other vivado.log files?
If it's routing congestion, there should be warnings in the implementation vivado.log file, more specifically during the route_design stage.
Depending on the type of congestion (short or long), either the spreadlogic for short or the NetDelay strategies for long congestion will help.