Using a mif file in Quartus

fpgaquartusquartus-ii

I have created an mif file in Quartus and I am working with cyclone 2 Altera. My query is "How can I use this mif file to initialize a variable in my top level design architecture"?
Let me elaborate. My aim is to produce a sine wave using FPGA storing the values in look up tables and accessing it from a VHDL program. I calculated the look up table values myself using MATLAB. I have put them in a mif file. Now I think I should write a program that takes in these LUT values and feed it to the DAC.

For this I am trying to write a vhdl program with a variable that is initialised with my LUT values. I will then assign the values to an output vector variable(should it be a two dimensional array?) and then use the DAC.

I heard there are no direct DACs in cyclone 2?

Best Answer

You can use the memory IP cores to create a memory with initial mif content. You can check the IP core user guide for more information.

Another solution is to use VHDL attributes to initialize the content of your variable. You have to be confident that your code is indeed interpreted as a ROM by altera, otherwise the attribute will be ignored. This is the example usage from altera's documentation:

type mem_t is array(0 to 255) of unsigned(7 downto 0);
signal ram : mem_t;
attribute ram_init_file : string;
attribute ram_init_file of ram : signal is "my_init_file.mif";

A third way, which I prefer, is to initialize the memory in VHDL code, for example:

type rom_t is array(0 to 1023) of signed(15 downto 0);

function fill_sin_rom return rom_t is
    variable ret : rom_t;
begin
    for i in ret'range loop
        ret(i) := to_signed(integer((2.0**15 - 1.0)*sin(2.0*MATH_PI*real(i)/1024.0)), 16);
    end loop;
    return ret;
end function fill_sin_rom;

constant sin_rom : rom_t := fill_sin_rom;

This code would be in a package for an architecture declaration sections. It requires use ieee.math_real.all and use ieee.numeric_std.all to work. The advantage of this solution is that it also works in simulation, while the attribute would not.

Related Solutions

FPGA Synthesis = 0 LE (Altera Quartus II)

Without the code, you can only expect general advice.

However the most likely scenario is that the outputs don't actually depend on the inputs, so that optimisation eliminates all the logic in between them and hardwires the outputs to '1', '0' or 'Z'.

This can often be due to a mistake in your logic, or a reflection of the fact that you are trying out an incomplete design, and the missing portions contain logic that would prevent the optimisation from deleting what you have done so far.

Electronic – Generating pulse train of varying frequency on an FPGA

What you want to do is called a Numerically Controlled "Oscillator", or NCO. It works like this...

Create a counter that can increment by values other than 1. The inputs to this counter are the master clock, and a value to count by (din). For each clock edge, count <= count + din. The number of bits in din is the same as the number of bits in the counter. The actual count value can be used for many useful things, but what you want to do is super simple.

You want to detect every time the counter rolls over, and output a pulse to your motor when that happens. Do this by taking the most significant bit of the counter and running it through a single flip-flop to delay it by one clock. Now you have two signals that I'll call MSB, and MSB_Previous. You know if the counter has rolled over because MSB=0 and MSB_Prev=1. When that condition is true, send a pulse to the motor.

To set the pulse frequency, the formula is this: pulse_rate = main_clk_freq * inc_value/2^n_bits

Where inc_value is the value that the counter is being incremented by and n_bits is the number of bits in the counter.

An important thing to note is that adding bits to the counter does not change the range of the output frequency-- that is always 0 Hz to half of main_clk_freq. But it does change the accuracy that you can generate the desired frequency. Odds are high that you won't need 32-bits for this counter, and that maybe just 10 to 16 bits will be enough.

This method of generating pulses is nice because it is super easy, the logic is small and fast, and it can often generate frequencies more accurately and with better flexibility than the type of counter+comparator design that you have in your question.

The reason why the logic is smaller is not only because you can get by with a smaller counter, but you do not have to compare the entire output of the counter. You only need the top bit. Also, comparing two large numbers in an FPGA usually requires a lot of LUTs. Comparing two 32-bit numbers would require 21 4-Input LUTs and 3 logic levels, where as the NCO design requires 1 LUT, 2 Flip-Flops, and only 1 logic level. (I'm ignoring the counter, since it is basically the same for both designs.) The NCO approach is much smaller, much faster, much simpler, and yields better results.

Update: An alternative approach to making the rollover detector is to simply send out the MSB of the counter to the motor. If you do this, the signal going to the motor will always be a 50/50 duty cycle. Choosing the best approach depends on what kind of pulse your motor needs.

Update: Here is a VHDL code snippet for doing the NCO.

signal count :std_logic_vector (15 downto 0) := (others=>'0);
signal inc   :std_logic_vector (15 downto 0) := (others=>'0);
signal pulse :std_logic := '0';

. . .

process (clk)
begin
  if rising_edge(clk) then
    count <= count + inc;
  end if;
end process;

pulse <= count(count'high);

Best Answer

Related Solutions

FPGA Synthesis = 0 LE (Altera Quartus II)

Electronic – Generating pulse train of varying frequency on an FPGA

Related Topic