Inferring DP-ROM

[Altera_Forum]

I’d like to infer a 2-port ROM with a read-enable signal using VHDL. Without the read-enable everything is o.k.. Using the read-enable, Quartus use a single ported ROM with the double size instead of the dual ported one. Is it not possible to build up an enabled DP-ROM? 

  ... type memory_t is array (0 to (2**TAB_ADR_BITS)-1) of std_logic_vector (BITS-2 downto 0); function init_rom return memory_t is variable tmp : memory_t := (others => (others => '0')); begin for k in 0 to 2**TAB_ADR_BITS - 1 loop tmp(k) := ... end loop; return tmp; end init_rom; signal TAB: memory_t := init_rom; begin ROM_read: process(clk) begin if clk'event and clk = '1' then --if ena = ‘1’ then Signal_1 <= TAB(index_1); Signal_2 <= TAB(index_2); --end if; end if; end process; ... Has anyone an idea how to do it?

[Altera_Forum]

Quartus integrated synthesis (QIS) does not support all possible control signals for inferred memories. It looks like QIS supports an enable for a single-port ROM in Cyclone III but not dual port. You might also be running into a limitation for your device family. 

 Try instantiating a "ROM: 2-PORT" megafunction configured with the MegaWizard to have a clock enable. I verified that this will work with Cyclone III.

[Altera_Forum]

For my MegaWizard suggestion, you will need a memory initialization file. I did not test this, but you might be able to infer the ROM without the enable, save the .mif file that Quartus creates in the db directory, and use that .mif file for the instantiated "ROM: 2-PORT" megafunction. That will save you the trouble of creating a .mif or .hex file manually.

[Altera_Forum]

Quartus can only infer logic, that can be realized by the existing hardware. A read enable isn't present in the RAM/ROM hardware, so Quartus has to use an equivalent construct. It is apparently not operational with a DP variant. You can try to find another way compatible with your intended use. It's general helpful to understand the available hardware options, particularly wich signals have to registered. The information is present either in the alt_ram MegaFunction user guide or the respective hardware manual.

[Altera_Forum]

--- Quote Start ---  A read enable isn't present in the RAM/ROM hardware...  --- Quote End ---     The Cyclone III device handbook says this:    --- Quote Start ---  The ROM read operation is identical to the read operation in the single-port RAM configuration.  --- Quote End ---   The single-port RAM figure shows both a clock enable and read enable available, although I saw only clock enable in the "ROM: 2-PORT" MegaWizard.  Despite the handbook statement giving me the impression that a ROM can't be dual port, I did successfully implement the dual-port ROM without enable using an inferred memory and the dual-port ROM with enable using the MegaWizard with the clock enable selected.

[Altera_Forum]

Brad is right, Cyclone III has a read enable.The problem is probably a different one. Synchronous RAM/ROM has always registered addresses and optionally registered output.  

 If the RAM is inferred with unregistered addresses, as in the example (I guess so, the origin of address signal is hidden), Quartus has to turn registered output into registered addresses with unregistered output. This necessary conversion may hinder Quartus to realize the DP option.  I would try to define the logic with synchronous addresses and asynchronous output as in the Quartus manual inference example.

[Altera_Forum]

--- Quote Start ---  If the RAM is inferred with unregistered addresses, as in the example (I guess so, the origin of address signal is hidden), Quartus has to turn registered output into registered addresses with unregistered output. This necessary conversion may hinder Quartus to realize the DP option.  --- Quote End ---    From the Quartus handbook, Volume 1, Section II, Chapter 6, under "ROM Functions—Inferring altsyncram and lpm_rom Megafunctions from HDL Code":    --- Quote Start ---  For device architectures with synchronous RAM blocks, such as the Stratix series devices and newer device families, either the address or the output has to be registered for ROM code to be inferred. When output registers are used, the registers are implemented using the input registers of the RAM block, but the functionality of the ROM is not changed.  --- Quote End ---    I still suspect that the limitation the original poster ran into is just what I said earlier about QIS not supporting all possible control signals for inferred memories.     --- Quote Start ---  I would try to define the logic with synchronous addresses and asynchronous output as in the Quartus manual inference example.  --- Quote End ---    My test used Quartus handbook, Volume 1, Section II, Chapter 6, Example 6-25. (I filed a service request for this example missing the needed "end rtl;" at the end and otherwise having everything shown twice.) This handbook example is very similar to the one in this thread with the RTL implying that the only registers are on the output, so Quartus moved those registers to the address inputs for my test.