Uninferred ram logic cyclone III

[Altera_Forum]

I am trying to migrate usb design from xilinx virtex V based fpga to Altera cyclone III. The usb implementation is written in VHDL and uses a few asynchronous ram constructs. (synchronous write but asynchronous read). 

Quartus II v9. gives uninferred ram logic info   Info: RAM logic "usb_controller_interface:usb_cntrlr_intfc_inst|usb_controller:usb_controller_inst|pkt_handler:pkt_handler_inst|rx_handler:Inst_rx_handler|rx_controller:rx_controller_inst|stream_ep_flag_handler:stream_ep_flag_handler_inst|out_buf_length" is uninferred due to inappropriate RAM size  what does it imply? 1) will my ram logic not be implemented or it will be implemented in logic cells rather than m9k memory blocks. 2)when i use attribute ramstyle = "logic , no_rw_check" the above info persists. 3)when ramstyle is changed to "MLAB , no_rw_check" memory bits usage is increased and logic elements usage decreases. quartus deduces "altdpram". since "altdpram" is not supported in cyclone III neither is MLAB so it offers equivalent solution with relevant warnings.   is there any other way to implement asynchronous ram in cyclone III?  Thanks and regards.

[Altera_Forum]

--- Quote Start ---  I am trying to migrate usb design from xilinx virtex V based fpga to Altera cyclone III. The usb implementation is written in VHDL and uses a few asynchronous ram constructs. (synchronous write but asynchronous read). Quartus II v9. gives uninferred ram logic info   Info: RAM logic "usb_controller_interface:usb_cntrlr_intfc_inst|usb_controller:usb_controller_inst|pkt_handler:pkt_handler_inst|rx_handler:Inst_rx_handler|rx_controller:rx_controller_inst|stream_ep_flag_handler:stream_ep_flag_handler_inst|out_buf_length" is uninferred due to inappropriate RAM size  what does it imply? 1) will my ram logic not be implemented or it will be implemented in logic cells rather than m9k memory blocks. 2)when i use attribute ramstyle = "logic , no_rw_check" the above info persists. 3)when ramstyle is changed to "MLAB , no_rw_check" memory bits usage is increased and logic elements usage decreases. quartus deduces "altdpram". since "altdpram" is not supported in cyclone III neither is MLAB so it offers equivalent solution with relevant warnings.   is there any other way to implement asynchronous ram in cyclone III?  Thanks and regards.  --- Quote End ---    Hi,  1. The memory will be implemented in logic cells.  2. As far as I know all RAM's in Cyclone III are synchronous 3. Is that really true, Cyclone III have no MLAB's ( at least as far as I know)  Kind regards  GPK

[Altera_Forum]

cyclone III info dump says so  

"Warning: Assertion warning: Device family Cyclone III does not have MLAB blocks -- using available memory blocks" and uses altsyncram  what does Info: RAM logic "in_buf_length" is uninferred due to inappropriate RAM size imply ??  thanks and regards

[Altera_Forum]

--- Quote Start ---  cyclone III info dump says so  "Warning: Assertion warning: Device family Cyclone III does not have MLAB blocks -- using available memory blocks" and uses altsyncram  what does Info: RAM logic "in_buf_length" is uninferred due to inappropriate RAM size imply ??  thanks and regards  --- Quote End ---     Hi,  what is the size of your RAM ?  Kind regards  GPK

[Altera_Forum]

hi 

my ram size is word length 7 bits and depth 16 words.  type MEM is array (0 to 15) of std_logic_vector(6 downto 0); signal in_buf_length:MEM; attribute ramstyle:string; attribute ramstyle of in_buf_length:signal is "no_rw_check";  thats my ram definition template

[Altera_Forum]

Use altsyncram, there is no MLAB in CIII 

I think your memory is too small that is why it is using logic instead of block ram. I used to have that issue, but it went away when I inferred a bigger RAM.

[Altera_Forum]

Hi 

is it neccesary that ram declaration(or deduction) neccessarily takes up full M9K block? read in one of the posts that quartus can pack more than one ram declarations in a single M9k block. so "uninferred due to inappropriate RAM size" due to small memory size is a bit confusing.  Thanks and regards sanat

[Altera_Forum]

No, it's not. 

But Quartus, by default, does not use M9K blocks for such small memories. You can force it to, either by setting the "Allow Any RAM Size for Recognition" option (Analysis & Synthesis) or by specifying "M9K" as the ramstyle attribute.  That said, unless you're having trouble fitting your design or achieving timming closure, my advice is to let the tools figure it out automatically.

[Altera_Forum]

Thanks all 

I feel enlightened now :)

[Altera_Forum]

It's easy to set the intended "RAM-style" by synthesis attributes in the HDL text. Check the language templates in the Quartus editor context menu.