HDL-Coder: Vivado gives errors creating bitstream due to disconnected URAM cascade inputs

Hello,

Using Simulink/HDL Coder, I've created a system that works "just great" - I can create a bitstream and get static timing results (it meets timing) etc., but this is not a bitstream we can actually load onto our hardware (a custom Zynq Ultrascale+ platform).

I've handed the HDL over to our FPGA engineer. He has embedded it into our larger design and run simulations with it to prove everything works. He then created an IP block for the whole thing and put that into a block design connecting up to the rest of the Zynq. Next step: synthesis, check. Place and route, check. Creating bitstream... failed! (worse yet, no XSA file)

There were numerous issues, and I don't have the list yet, but one that he mentioned has to do with the use of UltraRAMs: the URAM cascade inputs are not connected (paraphrasing our FPGA guy - I'm working on getting the actual messages).

In HDL Coder, I've "hinted" that certain memories should be URAMs. This works just fine; I can see in the Verilog these sorts of directives:

  (* ram_style  = "ultra" *)   reg[DataWidth - 1:0] ram [2**AddrWidth - 1:0];
  reg  [DataWidth - 1:0] data_int;

We go through synthesis and the report shows the right number of URAMs being used. Same with place and route.

We are both mystified. Obviously, we can't specify a URAM block in Simulink and connect signals to the cascade inputs; the very idea sounds ludicrous. But where along the path did we screw up? Is there some obscure setting somewhere that defaults these unconnected inputs to ground?

Thanks,

Charles

Answer 1

[Kiran Kintali]

>> Using Simulink/HDL Coder, I've created a system that works "just great"

Glad to hear it.

The error you describe in the message sounds like Vivado synthesis workflow step issue;

Would you be able to connect with MathWorks tech support on this topic? We need a sample model and or code that can reproduce the error.

We should eliminate manual coding error before reaching out to Xilinx/AMD tech support for additional inputs.

[Charles]

Thanks for your response. Manual coding errors are certainly a possibility. It occurred to me that, with the other issues, the URAM messages might be red herrings and the real issue might be one of the messages. But I need to work with our engineer to get those messages and see if he can resolve them.