Frequency of operation of M9K bram

--- Quote Start ---

Now everything is working fine.

--- Quote End ---

Wahoo! :)

Cheers,

Dave

The RAM is inferred when I connect the address ports too to the shift registers. Now everything is working fine.

rbugalho and Dave..Thanks a lot for helping me out.

Dave, Jed.

_there's nothing wrong with inference of the memory module Jed has written_.

It's just that when instantiated within test_harness as top level module, the entire design gets reduced to 13 registers, of which the memory block takes only 8 bits. Quartus will not, by default, use a M9K RAM block for just 8 bits.

Inference of RAM blocks for Jed's 2W4R module is working correctly and when you surround it with some logic that actually makes use of 4096 bits, it will be inferred into RAM blocks.

My guess would be that since 512 x 8-bits = 4kB, that the inference is dumb.

1024 x 8-bits = 8kB, which needs a whole M9K. Try that.

Cheers,

Dave

Hello Dave and rbugalho,

I somehow needed to get the RAM inferred.

Dave...I tried what you told me to do in your previous post. When I instantiated the altsyncram component instead of my generic verilog code, M9K blocks are being inferred. I also tried wrapping the simple dual port RAM instead of the 2W4R RAM[ I have pasted the code below] in the test harness and synthesizing it. But I am facing the same problem.

module my_memory_blocks(

output reg [7:0] q,

input [7:0] d,

input [5:0] write_address, read_address,

input we,clk );

reg [7:0] mem [511:0];

always @ (posedge clk) begin

if (we)

mem[write_address] <= d;

q <= mem[read_address];

end

endmodule

When I click on the "Info (276004): RAM logic "my_memory_blocks:m0|mem" is uninferred due to inappropriate RAM size" it is pointing to the line in red in the above code. I cannot understand what is inappropriate in it even after following all the altera coding standards. I guess I will go ahead and file a service request as you said.

--- Quote Start ---

I'm using Cyclone IV GX : EP4CGX110CF23C7

http://www.altera.com/literature/hb/cyclone-iv/cyiv-53001.pdf - In page 26 , it says M9K in "Simple dual-port 256 × 36 CLK" . But even when I changed the port configuration to 36 from 32 it is not able to infer :(

What does that CLK in " Simple dual-port 256 × 36 CLK " mean? Does the clock there have any significance?

--- Quote End ---

It might mean single-clock dual-port. I'm not sure if it has significance. You'll have to read the handbook.

My suggestion would be to instantiate an altsyncram exactly how you want it, eg., use the MegaWizard to create an instance, and then either use that directly, or copy and paste the altsyncram component from inside the MegaWizard file. Synthesize that. That will give you a known altsyncram configuration.

Then go and figure out what it takes to get Quartus to infer that identical logic. If you cannot, then file a Service Request with source code that contains a generic to select either the altsyncram or your inferred RAM.

Cheers,

Dave

I m using Cyclone IV GX : EP4CGX110CF23C7

http://www.altera.com/literature/hb/cyclone-iv/cyiv-53001.pdf - In page 26 , it says M9K in "Simple dual-port 256 × 36 CLK" . But even when I changed the port configuration to 36 from 32 it is not able to infer :(

What does that CLK in " Simple dual-port 256 × 36 CLK " mean? Does the clock there have any significance?

--- Quote Start ---

... is uninferred due to inappropriate RAM size

Please suggest how I can overcome the issue.

--- Quote End ---

Infer an appropriate RAM size :)

M9K = 9kBits, 256 x 32-bits is ok in terms of the number of bits, but you also need to check that the device you are targeting supports that particular data width. Your design files do not include a project, so I can't tell which device you are targeting. Assuming you are targeting a Cyclone IV:

http://www.altera.com/literature/hb/cyclone-iv/cyclone4-handbook.pdf

p22 tells you that true dual-port mode only supports 16/18-bit data, so you need two blocks of M9K to create a 256 x 32-bit block, but you would use 512 x 36-bits of M9K, so you may as well increase the address width.

I guess the Quartus inferrence engine is not too smart ... another reason to just instantiate an altsyncram (or two) directly :)

Cheers,

Dave