CODEWITHSUNDEEP
vhdlram
fiz
fiz

Reputation: 934

Optimisation of RAM

I'm currently debugging my DPRAM. As usual, simulation works perfectly but in real life it fails. The syntax is as such:

ram[Address][Data]

I can get the data to write to the first 8 addresses but anymore and the data is just lost (even on chipscope). As a work around, I stitched two pieces of DPRAM together with a simple logical switch to re-route the data to the second DPRAM after it hit the eighth address. This worked but it just looks so messy.

My thinking is that it is being optimised away, even if it isn't this will be a good learning curve anyway (and any thoughts on this are welcome).

Here is the signal variable in the DPRAM with my effort at stopping it from being optimised away:

type ram_array is array(16 downto 0) of std_logic_vector(31 downto 0);
shared variable ram: ram_array;


attribute KEEP: string;
attribute KEEP of ram_array : type is "TRUE";

I think I need to add a line to the UCF file also though I can't seem to get the syntax right, with entity name path obviously changed:

NET "entity/name/path/dpram/ram_array" KEEP ="TRUE";

So is this how I'd add the code if I wanted to stop optimisation?

EDIT:

Output (guess there wasn't optimisation):

Found 17x32-bit dual-port RAM <Mram_ram> for signal <ram>. Summary: inferred 1 RAM(s). inferred 65 D-type flip-flop(s). Unit <dpram> synthesized.

Thanks =)

Upvotes: 0

Views: 344

Answers (1)

Bruno JJE
Bruno JJE

Reputation: 231

Don't use shared variable for synthesizable code

If your code needs to be synthesizable, then don't use shared variable.

Inferring BlockRAM

If you need sample code to implement your memory without using a shared variable, use the documentation provided for your FPGA.

Sample doc links :

Hope this helps.

Upvotes: 1

Related Questions