Occasional Contributor
Super ContributorDid you add the RAMs through code inference or by adding them as IP through the IP Catalog? If it was code inference, that might be the issue. If you show your code, that could help diagnose the problem.
Also, if you are using code inference, check out the templates in the Quartus text editor (Edit menu -> Insert Template) to make sure you are following the coding guidelines to have your design synthesized the way you intend.
Occasional ContributorHello, thank you for your reply.
I used MegaWizard.
Code as simple as this:
reg [8:0] r_fir_RAM_address = {9{1'b0}}; wire [15:0] w_fir_RAM_data_out_lo; wire [15:0] w_fir_RAM_data_out_hi; reg [15:0] r_fir_RAM_data_in_lo = {16{1'b0}}; reg [15:0] r_fir_RAM_data_in_hi = {16{1'b0}}; reg r_fir_RAM_we = 1'b0; fir_ram_lo fir_ram_lo ( .clock(FFCLK), // address - same for both channels, even/odd .address_a( { r_fir_RAM_address[8:0], 1'b0 } ),// even byte .address_b( { r_fir_RAM_address[8:0], 1'b1 } ),// odd byte // write enable .wren_a(r_fir_RAM_we), .wren_b(r_fir_RAM_we), // indata .data_a(r_fir_RAM_data_in_lo[7:0]), .data_b(r_fir_RAM_data_in_lo[15:8]), // outdata .q_a(w_fir_RAM_data_out_lo[7:0]), .q_b(w_fir_RAM_data_out_lo[15:8]) ); fir_ram_hi fir_ram_hi ( .clock(FFCLK), // address - same for both channels, even/odd .address_a( { r_fir_RAM_address[8:0], 1'b0 } ),// even byte .address_b( { r_fir_RAM_address[8:0], 1'b1 } ),// odd byte // write enable .wren_a(r_fir_RAM_we), .wren_b(r_fir_RAM_we), // indata .data_a(r_fir_RAM_data_in_hi[7:0]), .data_b(r_fir_RAM_data_in_hi[15:8]), // outdata .q_a(w_fir_RAM_data_out_hi[7:0]), .q_b(w_fir_RAM_data_out_hi[15:8]) );
Occasional ContributorThere seem to be a weak workaround (if it is a valid workaround at all) distributing the data across the whole M9K block. But there's a risk that at some stage Quartus (or its other version) identifies that design does not use specific addresses in the space, and pack everything as it wants and as it was not designed by the developer, causing problems and penalties in performance.
Thus I need explicit command/instruction for Quartus for NOT doing any RAM space optimizations, and leave M9K block and connections to it as designed in the project.
I am still not sure from previous replies if what I see is Quartus behavior as it was designed. I can not find any related information, articles, datasheets or whitepapers on the subject. The mechanism of this "optimization" is unclear as from my perspective it is, with current M9K block usage, simply impossible without any tricks or undocumented features.
Update: looked through, and played with all the options available in the "setting" section (compilation and fitting), which look like may affect the problem. No change. Nothing suitable in the "device" menus.
Occasional ContributorIt seems Intel senior managers in customer support / application engineering had never used their portal as a customers.
1. It appears that these "Intel community forums" are the main support vehicle of the Intel. In my understanding community is a meeting place of the interested parties and people, who may know something, and be somehow responsible for something, and have some experience. "Community", as a term, is not a formal place to come and expect formal reliability and formal responsibility. See the definition of community here. IMHO, it is incorrect and misleading using word "community" as a buzzword for formal support services. What is service level agreement (SLA) of these forums? Where can I learn them in comprehensive way and set my expectation accordingly?
2. As it appeared that this community forum is formal customer support portal, I would expect to see real names of the Intel employees here, with their positions and locations, so that I know whom I am talking to. So far everyone I meet are nicknamed individuals with no indication what experience they have and if they are trustworthy or credible. Whatever "honored" profile holder is, I am not going to base my decision making on anonymous opinions if they do not convince me 100% and have no confirmation from other, trusted parties.
3. There seems to be another support means called "Intel customer support". I opened the ticket there, while filling the form there were no, absolutely no, questions/checkboxes what product issue I have so that ticket can be routed properly onto the respective team at the first place. There's only a "description" field to put custom information into. The form does not look like being customer-oriented, and makes an impression it is a support for people who do not have Intel web pages loading properly in their browser (webmaster support).
4. I had emails from "supportreplies", and these emails does not explicitly state that its mailbox is not monitored, and I had to learn it after writing several emails into there... so there's no way to give feedback to the support people privately without using this forum.
I was an HP IT resource center member for several years in the past (being an HP customer support expert employee), these days sometimes use support services and forums of Maxim Integrated, NXP, TI, Wiznet, Microchip and other component and IP vendors. I used Altera support services in the past - they were decent. As a customer, I rank the Intel support as the worst out of all in terms of the process. Yes, I am very small customer, but I expect to be guided through my problem resolution in expected, responsible and informed manner.
The support process is broken.
Regular ContributorIn reading your code snippet, for the instantiation of your two RAM blocks the **ONLY** difference is in the data input/output signals.
The address/data/control signals are IDENTICAL for each block.
So Quartus can easily (and validly) pack BOTH of your RAM blocks into a single M9K block that has a wide enough data port (of 32bits) and a deep enough depth (256 locations, as you indicate the upper address bit is always zero). 256*32 = 8192 < M9K size so it fits in one memory block.
Darn good optimization by Quartus. Why are you complaining?
Occasional ContributorUpdate: after some conversations we decided that it is not clear how to deal with the issue, and I decided to change architecture of the circuit using one single port RAM. It has performance penalty, but satisfies minimal requirements, thus there's no more urgency in and severity of dealing with the issue.
Special thanks to everyone who was involved into the escalation.
>Why are you complaining?
This is a very good question!
1. In my previous designs I have seen clear difference between performance of *8 and *16 M9K RAMs. I can not explain why *16 configuration is not up to speed, most probably it has some more logic involved speeding down the operation causing invalid data output at specific clock frequencies - I use ~112 MHz;
2. There must be an option to tell Quartus not to be that darn good, but perform as it was designed by the human designer. So far we did not find anything which would instruct Quartus to make 2 RAMs and not one RAM which (see my item #1) may not be up to speed causing artefacts in its output thus system failure;
3. The M9K guide for Cyclone 3, at its page 3-11, has a table listing possible configurations for True Dual Port RAM - the one I used in the design. Table 3-4 does not list 256*32 configuration. Thus Quartus must have had two RAMs. In general, the documentation does not show "native" configuration of the M9K blocks which provides maximum performance;
4. And finally, the actions and optimizations Quartus performing are not clear, and thus suspicious, without any traces in its warnings or informational messages. There must have been messages that Quartus merges RAMs, but there're none. Then only related are about Quartus rightfully reporting that MSBs of the addresses are not used.
