12-01-2020 09:38 AM
I have a pretty large design at my current job that implements UltraRAMs in a signal processing chain. When I get through synthesis, it shows the correct amount of UltraRAMs being utilized. However, when the tool builds the synthesized netlist, it blows away a good portion of the RAM interface for one portion of my signal chain.
Any thoughts would be appreciated.
12-01-2020 10:27 AM
Vivado implementation likely has opt_design phase as is_enabled by default. This does some optimizations which might be removing your logic.
https://www.xilinx.com/support/answers/58616.html (Vivado - Debugging opt_design trimming)
https://www.xilinx.com/support/answers/53845.html (Vivado Implementation - Is there a switch in Vivado that can be used to prevent trimming of unconnected logic?)
You could also try disabling opt_design in your implementation settings temporarily to confirm this.
12-03-2020 06:42 AM
12-03-2020 06:44 AM
Not a silly question at all. Yes I did simulate it. There are 64 adc channels in my design which all talk to their own ultrarams. I use a generate loop to instantiate the same component N-times. Sim looks great, as does the synth netlist. It's just P&R that decides that I don't need them...?
12-03-2020 07:05 AM
It is possible opt_design is removing these if they are part of a OOC synthesis netlist but aren't used in the context of the larger design during implementation (e.g. no logic loads on the outputs or not further used downstream).
-making sure they look ok in the synthesized netlist
-turn opt_design back on and look for applicable messaging on why to help narrow this down (see AR58616 above).
12-03-2020 07:27 AM - edited 12-03-2020 07:28 AM
When I inspect the individual components with RAM signals (address / data / etc), they become n/c after P&R. They are connected after synthesis on the schematic when I hit the F4 key.
12-03-2020 08:04 AM
The question still holds, does that produce a concrete problem we can help with? otherwise we are just discussing on philosophical grounds whether that ultraram should or shouldn't be there. To me, something is needed (therefore it's a problem to take it out) when things don't work as expected without that thing.
12-03-2020 08:31 AM
Fair point. I should elaborate. Yes logically each channel needs to access their own RAMs individually as logically they are allowed to behave independently across all channels (IE: channels 0 - 15 all read their own UltraRAMs at the same time when commanded, and there is no time sharing).
So functionally yes they need to be there. I don't believe this is a case where the tool discovered that the logic implementation could be optimized down to a single channel, more it decided "I see you have these channels here, let me just remove all but the first one."
12-03-2020 09:12 AM
My next logical questions would be "is a bitstream generated?", "does it run as expected?", "is data correct?"
In the absence of a practical approach, I would be interested in knowing how is that memory inferred and interfaced? What if only one channel is used?