Frequency of operation of M9K bram

[Altera_Forum]

Hi, 

 Does anybody know where/how to find the operating frequency of a block ram? I particularly need M9K and M10K. I was not able to find them in the altera documentation. Kindly let me know if you have any info on this.  Thanks.

[Altera_Forum]

AFAIK, it's not explicitly documented anywhere but with the exception of the M144K blocks you find on some devices, all the other blocks are usually capable of operating at the same frequency as the device's clock tree. 

 Anyway, the best way is to synthesize a simple design and see what you can get.

[Altera_Forum]

Hi rbugalho, 

 Thanks a lot for your reply.  As far as synthesizing the design is concerned can you please tell me how to check for the frequency? When I specify the clock frequency to the M9K block say in a simple dual port mode using the Time Quest Analyser won't it operate at this frequency? Can you please let me know how to go about measuring the operating frequency?

[Altera_Forum]

I'm not sure if I'm understanding your question.. 

The RAM blocks will operate at frequency of the clock signal you use to drive them. You should specify that clock frequency in TimeQuest and TimeQuest will tell weather your design will operate (correctly) at that frequency or not. TimeQuest will also give you a (less reliable) estimate of the maximum frequency your design can operate at, in the fmax summary pane.

[Altera_Forum]

Hi rbugalho, 

 I got what you are saying. I tried it. However I have a question.. I have synthesized a simple dual port ram having 32x8 depth and width. I use the TimeQuest Timing Analyser wizard to set the clock, input and output constraints. Setting the clock constraint is fine, but when I need to set the i/p and o/p constraints I need to select each of the 32 write data ports , 8 write and read address ports individually. Is there an easier way of doing this?  Looking forward to your answer.  Thanks.

[Altera_Forum]

--- Quote Start ---   Setting the clock constraint is fine, but when I need to set the i/p and o/p constraints I need to select each of the 32 write data ports , 8 write and read address ports individually. Is there an easier way of doing this?   --- Quote End ---    To get valid timing results you have to use the RAM in the style you intend to use it. What you describe is an on-chip RAM instance that has its signals routed to I/O pins. This is probably not how you intend to use this RAM right? What you need to do is create a simplified design with a dual-port RAM instance in it. Then perform a TimeQuest analysis.  To get the maximum performance from an on-chip RAM, you need to enable it to use its input and output registers, drive the input from registers, and capture the output to registers. You can then analyze the timing path from the input registers through the RAM to the output registers.  I'll often create designs using a small Qsys system, eg., per this tutorial  http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial  and then either create the new component as a Qsys component, or create another component like your RAM that you can read or write to using say PIO. You can always cut the timing paths from the Qsys system to the input/output registers to isolate the path from TimeQuest analysis. Depending on how you do this, your design might not actually function correctly, but the timing results will be correct, i.e., TimeQuest will tell you what the delays are between the registers in the design.  Note however that you're getting a little too focused on one aspect of the FPGA. Designs can not run on RAM alone. You're better off to come up with a simplified design and check the timing on that.  Cheers, Dave

[Altera_Forum]

Driving the RAM block I/Os directly from I/O pins will give pessimistic resuts. 

Unless your final design calls for it, you should create a small design where the RAM block I/Os are connect to internal registers. I'm not familiar with the TQ wizzard, I always write my constraints by hand. The syntax supports wildcards so it's easy to constrain multiple things at once.  As Dave mentioned, the maximum frequency your design can operate is unlikely to be limited by the RAM blocks but by something else in your design.

[Altera_Forum]

Thanks so much for your replies. Helped me with the issue I was facing.  

 I am having trouble with inferring RAM blocks when it is instantiated in another module. When I synthesize the RAM design alone, the M9K blocks are inferred. But when I wrap the RAM in a test harness and synthesize it , the blocks aren't inferred! The top level module has instances of RAM and registers which are connected to the word input and output of the RAM. When I synthesize this module though the RAM blocks are't inferred. What must I do to solve this?  Please help with inputs of any kind.  Thanks.

[Altera_Forum]

--- Quote Start ---   I am having trouble with inferring RAM blocks when it is instantiated in another module.   --- Quote End ---   The RAMs should be inferring altsyncram components. The altsyncram blocks have internal input and output registers. If you are somehow accidentally connecting some of your other logic to what is effectively the output of the RAM input registers, then you might be upsetting the inference.  I would recommend placing the RAM interference code inside its own component. If you've done that already, and are still seeing this issue, then I would upload a code example, or file a Service Request with Altera.  Since you have to write tool-specific syntax to get inference working, I see no advantage over just instantiating an altsyncram directly. If you need portable VHDL, then you can always use configurations.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 Thanks for your quick response :) Appreciate it.   I have attached the file : test_harness.v . I am working on multiported memories. Since I was suggested to connect input and output registers to the RAM {since RAM pins cannot be connected directly to IO pins} I have  1) To reduce the number of IO pins used, have instantiated and connected word-wide shift-registers to only "data inputs" of the RAM.  [ Address inputs are left unconnected since the address comes from the control unit and not from IO pins] 2) Then comes the RAM instance itself. - This is the one which is not being inferred. This module if I synthesise it separately, is inferred as M9K blocks. But now it is implemented in Logic cells. 3) Instances of word-wide registers are connected to the RAM output.  Kindly let me know what I could do so that the RAM infers altsyncram component.

[Altera_Forum]

--- Quote Start ---  Since you have to write tool-specific syntax to get inference working, I see no advantage over just instantiating an altsyncram directly. If you need portable VHDL, then you can always use configurations.  --- Quote End ---  In my experience, there's a very reasonable overlap among the multiple synthesis tools' RAM inference templates.Also, the inference capabilities often lead to cleaner code.

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

Hello Dave, 

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

[Altera_Forum]

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

[Altera_Forum]

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?

[Altera_Forum]

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

[Altera_Forum]

Jed,there's nothing wrong with the ram inference.You're just experience the effects of logic optimization. The synthesis tool will, as much as it can, optimize away any logic that is not needed. Due to the very simple logic you have in test_harness, the tool is able to reduce the "m0" module to a mere 8 bits and thus decides not to spend a M9K block on it. Hence the inapropriate RAM size message.

[Altera_Forum]

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.