Open nrother opened 7 years ago
Hello @nrother,
even with changing the code, Vivado has huge problems in handling big generic and big constants in synthesis. I can see a synthesis slowdown by x100 and more. Moreover, it consumes more and more memory while synthesizing.
Regarding the 36k vs. 18k memory problem: It's it a dual port memory using the JTAG Loader on port 2?
Kind regards Patrick Lehmann
Hi @Paebbels,
there seems to be a confusion: This template (which I refereed to) does not contains huge generics, since the memory content is read from a file. The code reading the memory from the file causes problems with Vivado (due to the line
argument). This was the error I originally reported.
When this bug is fixed (e.g. by inlining read_hex
), Vivado infers two 36KBit memories, even when the code size is below 1024. But this is probably nothing that could be fixed in the template, since this might also be an "optimization" that has to do with the rest of my code (which does not contain a JTAG loader or anything other requiring dual port memory).
I forced Vivado to use a single 18KBit BRAM by using this template (which does pass the content using generic, without file I/O). This worked without problems, I didn't notice a huge slowdown as you described (but I didn't really looked for it).
I haven't pursued Vivado support for the generic ROM. I've been waiting for Xilinx to improve its VHDL support in Vivado and hopefully make this issue go away. I will look into a possible fix.
The generic rom template
picoblaze_rom.vhdl
is not usable in Vivado 2017.2 because Vivado does not likeline
arguments inread_hex
:(This is probably also a problem in your vhdl-extras library)
I inlined
read_hex
, but this caused Vivado to infer two 1Kx36 memories instead of the sufficient 1Kx18 (for <1024 instruction). I'm not sure if this is a bug/limitation of your code, forcing Vivado to use a 1Kx18 BRAM uses a few more LUTs, so this might be a intended optimization by Vivado.