Memory usage

A few things that might help.

1 - Quartus gives extremely detailed and powerful reports. For example, in the "Analysis and Synthesis" or "Fitter" section of the report, you can look at the "RAM usage summary" or "Resource Utilization by Entity" or various other sub-sections to determine which components are using which RAM blocks and how many.

2 - My guess is that you've configured the RAM in such a way that it's wasting bits. How are you configuring the altsyncram component? Have a look at page 1 of the following document to see legal configurations for M4K blocks:

http://www.altera.com/literature/hb/cyc2/cyc2_cii51008.pdf

3 - It's also possible that Quartus is inferring RAM blocks from some of your logic. If this is the case, Quartus will inform you during compilation so you can get it from the report section. If you want to ensure this isn't happening:

Assignments->Settings->Analysis and Synthesis Settings->More Settings. Then set "Auto RAM Replacement" and "Auto ROM Replacement" to Off.

Try this:

Set the q bus to 36 bits. Set the number of words to 4352. This should give you 156672 bits of memory. Now, set the maximum block depth to 512 words. Controlling the maximum block depth changes the way the RAM is configured.

Jake

Actually I think setting the block depth to 128 would be best in the case I gave.

Jake

Thanks Jake for the reply...

In my test design I am placing just a single ALTSYNCRAM component and there is nothing else there - the connections from this component are routing straight to the external device pins.

The test design is using C20 device to make it compile easily. From its compilation report I gather the design is using 38 M4K blocks instead of 36. I wrote about it in my original post. In the Resource Usage Summary I have:

M4Ks 38 / 52 ( 73 % )

Total block memory bits 153,600 / 239,616 ( 64 % )

Total block memory implementation bits 175,104 / 239,616 ( 73 % )

Not sure what exactly is the difference between these last two...

I have not tried your suggestion for 36 bits bus width yet.

Currently, I have a 16 bit processor driving this thing, and 4 data bit on the LCD, so to simplify the video sequencer I set the memory component to be 16 bit wide on the write port and 4 bits on the read port (simple dual port mode). I have also requested 153600 bits of memory, exactly as needed to have 2 pages 320x240 pixels each.

OK, I took your idea and made 9-bit bus. Now it appears I can use the parity bits, but it complicates a lot of things, unfortunatelly...

16-bit CPU writing 9 bit bus will take double time to update the screen.

Also the sequencer from 9 bit read to 4 bit LCD data bus will not be easy.

Is there any simpler way to use the parity bits from Cyclone?

what about an ip block between your cpu and the 9 bit memory ?

this ip block would do the bitshift of your 16bit cpu and the display memory and the adr calculations

also this ip would do the cpu writes as read modify write cycles.

as the fpga internal memory is very fast you can access this memory with your system clock speed, but be aware of the read delay see the timing diagramm available when you create your memory with the wizzard.

yes that is correct, but don't forget that the cpu is 16bit so one port into this memory block must be 16bit.

i have player a while with different port a & port b combinations but we must also consider the device he is planning to use and the available memory

so this is more difficult as it seems to at first sight