Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21604 Diskussionen

Synthesis ramstyle

Altera_Forum
Geehrter Beitragender II
2.892Aufrufe

Hi, 

 

I am trying to do the ram code but failed to infer to Mlabs, which instead goes into logic. 

 

Can anyone help? I attached the source code. 

 

device used:STRATIX V GT 

 

Thanks alot for helping. 

Best regards 

Jenny
0 Kudos
4 Antworten
Altera_Forum
Geehrter Beitragender II
1.542Aufrufe

I'm not using Veriolg, but I hope, the synthesis attributes (you're actually using it twice) should work. I also noticed that Stratix IV is supporting asynchronous read (I assume, you are not using Stratix V, that is yet unsupported by available Quartus versions ...). The Quartus Verilog templates are suggesting a slightly different syntax, however. 

 

The RAM inference templates don't have an synchronous read example. It may be the case, that this mode isn't supported for interference. You may want to use an explicite MegaFunction instance instead of spending much time with trial-and-error.
Altera_Forum
Geehrter Beitragender II
1.542Aufrufe

 

--- Quote Start ---  

Hi, 

 

I am trying to do the ram code but failed to infer to Mlabs, which instead goes into logic. 

 

Can anyone help? I attached the source code. 

 

device used:STRATIX V GT 

 

Thanks alot for helping. 

Best regards 

Jenny 

--- Quote End ---  

 

 

Hi, 

 

the RAM is implemented in logic, because you are using a asynchronous read. I would follow the advice of FvM and use the megawizard instead inference, because you have a better control over the implementation. However, the following example shows a that the inference in MLAB in principle works. 

 

 

(* ramstyle="MLAB" *) module test(clk1, we, data_out, rdaddr, wraddr, datain);  

 

parameter addr_width = 6; 

parameter data_width = 10;  

 

input clk1,we; 

input [data_width-1:0] datain; 

input [addr_width-1: 0] wraddr,rdaddr; 

 

output [data_width-1:0] data_out;  

 

 

reg [data_width-1:0] q; reg [data_width-1:0] mem [(2**addr_width)-1:0] /* synthesis syn_ramstyle = "MLAB"*/;  

 

always @(posedge clk1) begin  

if (we) mem[wraddr] <= datain;  

end 

 

always @(posedge clk1) begin  

q <= mem[rdaddr]; 

end  

 

assign data_out = q; 

 

endmodule  

 

Kind regards 

 

GPK
Altera_Forum
Geehrter Beitragender II
1.542Aufrufe

The point is, that Stratix IV and some other FPGAs are supporting asynchronous read. In so far, you can wish Quartus to infer asynchronous read for internal RAM. But I fear it doesn't. I didn't perform any tests, but if you see, that using sync versus async read makes the difference, it's apparently unsupported.

Altera_Forum
Geehrter Beitragender II
1.542Aufrufe

I just wanted to post an answer here for future reference. I was having exactly the same issue and it took me a while to find the answer so hopefully this reply will help someone. 

 

The tools do in fact support inferring an MLAB with an asynchronous read. The original posters logic is precisely correct, however, they are missing one little key piece of info that the synthesis tool needs in order to allow the inference to occur. The syn_ramstyle attribute must be slightly modified to include the "no_rw_check" option as follows: 

 

/* synthesis syn_ramstyle = "MLAB, no_rw_check"*/ 

 

This will allow the tool to properly infer the dual-port MLAB with asynchronous read. If you do not add the "no_rw_check" attribute then you will receive the following message from MAP: 

 

Info (276009): RAM logic is uninferred due to unsupported read-during-write behavior 

 

Here is the official Altera answer if anyone is interested in the details: 

 

https://www.altera.com/servlets/searchredirect?srtitle=how_to_infer_mlab_with_asynchronous_read&contactid=1-7ifaal&resulttitle=can%20quartus%20ii%20synthesis%20%3cb%3einfer%3c/b%3e%20a%20small%20%3cb%3easynchronous%3c/b%3e%20memory%20%3cb%3e...%3c/b%3e&resulturl=http://www.altera.com/support/kdb/solutions/rd12112006_212.html&gsa_pos=1&wt.oss_r=1&wt... 

 

The "no_rw_check" syn_ramstyle attribute is not required if the user is trying to infer a synchronous read. In fact, you should make sure that you don't include it in order to avoid hardware/simulation mismatches.
Antworten