Frequency of operation of M9K bram

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.

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?

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.

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.

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

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.

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.

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

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.

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