Frequency of operation of M9K bram

It's really hard to say what's going wrong unless you also attach the RAM modules.

That said, the synthesis tool will usually print a message telling you why it was unable to infer a block RAM.

--- Quote Start ---

In my experience, there's a very reasonable overlap among the multiple synthesis tools' RAM inference templates.

--- Quote End ---

That's good to know, thanks. I had done some tests a while back with Altera/Xilinx/Lattice tools to try to create a common set of components (like the lpm components), but the inference syntax for many of the components was different, so I ended up having to use a generic to select the implementation anyway ...

--- Quote Start ---

Also, the inference capabilities often lead to cleaner code.

--- Quote End ---

Yep, I agree. In an ideal world, HDL would be portable ...

Cheers,

Dave

--- Quote Start ---

I have attached the file : test_harness.v

--- Quote End ---

That's not much to go on with. I'd recommend uploading a synthesizeable example.

This thread has a Modelsim testbench for a dual-port altsyncram

http://www.alteraforum.com/forum/showthread.php?t=35572

write your code to use a generic so that it replaces your inferred component with an altsyncram component.

If you can show that the design can work with altsyncram, then it should also be able to infer an altsyncram from HDL.

At that point, you should be able to determine what is wrong with your inference syntax.

Cheers,

Dave

Hi rbugalho,

Thank you so much for the reply. Kindly find attached the modules of the RAM.

1) The module named MEM_2w4r.v is the entire RAM design. - This when synthesized alone , M9K blocks were inferred.

2) The module named test_harness.v is the test harness which is used to wrap the RAM design.

The compilation report gave this message : Info (276014): Found 4 instances of uninferred RAM logic

Info (276004): RAM logic "MEM_2w4r:m0|MEM_1w4r:MEM_1|MEM_1w1r:MEM_1w1r_0|memory" is uninferred due to inappropriate RAM size

Info (276004): RAM logic "MEM_2w4r:m0|MEM_1w4r:MEM_1|MEM_1w1r:MEM_1w1r_1|memory" is uninferred due to inappropriate RAM size

Info (276004): RAM logic "MEM_2w4r:m0|MEM_1w4r:MEM_1|MEM_1w1r:MEM_1w1r_2|memory" is uninferred due to inappropriate RAM size

Info (276004): RAM logic "MEM_2w4r:m0|MEM_1w4r:MEM_1|MEM_1w1r:MEM_1w1r_3|memory" is uninferred due to inappropriate RAM size

The RAM is used in Simple dual port mode, with depth = 256 and width = 32.

Please suggest how I can overcome the issue.

Hello Dave,

Please find attached synthesizable code above. Yeah all the modules are generic. None of them are altera specific modules.

--- 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

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 ---

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

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.