Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17255 Discussions

WADDR, WE, and DATAIN for SYSC_RAM module

Altera_Forum
Honored Contributor II
1,541 Views

I implemented a RAM in a sub-module. RAM values (an array) are filled via an initial block. However, compilation gave me three warnings, that is, "WADDR, WE, and DATAIN" of SYNC_RAM block have no driver or initial value, using default zero as initial value. Any ideas on how to remove these warnings?

0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
836 Views

You're apparently implementing a ROM rather than a RAM.  

 

You get the same warnings when compiling the Quartus HDL ROM templates. Obviously a weakness of ROM inference. If you instantiate altsyncram as a ROM, you don't get the warnings.
0 Kudos
Altera_Forum
Honored Contributor II
836 Views

Yes, a ROM could solve the problem. I am still learning Verilog language, and the following questions could be very fundamental: 

 

1. What is the correct way to fill values into ROM? Since initial block can not be synthesized, I can't use $readmemh for initialization. Should I simply "assign" a value to the corresponding ROM memory inside the ROM module?  

2. In the top-level module that instantiates ROM, will this instantiation of ROM updates its output whenever its input address value changes? I know all the "assign" statements in the top-level module run in this way, but how about an instantiation of an submodule ?
0 Kudos
Altera_Forum
Honored Contributor II
836 Views

1. I believe ROM should be initialized using the MIF file. 

2. Not very sure what is your question, instantiation only refering to thd ROM instance. It still depend on the address pump to that instsntiated ROM
0 Kudos
Altera_Forum
Honored Contributor II
836 Views

To make my question clear: let's say my sub-module ROM(addr, out) with the input variable addr being updated in the top-level module continuously from 0~7 then back to 0~7 again. Based on the updated input addr as the clock goes (e.g. addr <= addr + 1), I should have corresponding output, which is the content at updated addr. When my input addr runs from 0~7, how many instances should I have for this ROM on the top-level module, even though I only instantiate module ROM(addr, out) once in the code?

0 Kudos
Altera_Forum
Honored Contributor II
836 Views

I try my best to answer your question. Probably is good if you could let us know what is your purpose of doing this? 

If I understand correctly, you want to have continuous read of your ROM data, whatever address you put on the addr, the corresponding ROM data will be available on the q output of the ROM. 

 

So you just need to have a always block on the addr counter, then the corresponding data will be available every clock cycle.
0 Kudos
Altera_Forum
Honored Contributor II
836 Views

However, as I understand, it is not allowed to instantiate a sub-module in an always block. O/w, the compiler will complain. 

 

I am trying to implement an algorithm with loops, and I need to read this ROM one value by one value for each loop respectively. The loops are implemented via clocks.  

 

Thanks in advance.
0 Kudos
Altera_Forum
Honored Contributor II
836 Views

Sorry, why u need to instantiate module inside always block, u just need to instantiate the module outside always blocks, and the always block just used for addr counter only. The addr value assigned to the addr port of the ROM

0 Kudos
Reply