How to detect compiler

Question

I have to load ROM from file. Quartus can use .mif files directly and for the simulator I have written (a quick and dirty) .mif file parser with the help of textio. Is there a way to detect Synthesizer tools (Quartus in my case) and to generate textio file loader process only if it is not being compiled by the Synthesizer tool?

(the source question)

Answer 1

You can detect the synthesis tool by using a pragma that is only accepted by your specific synthesis tool. For example, you can write:

constant isQuartus : std_logic := '1'
-- altera translate_off
and '0'
-- altera translate_on
;

This constant will be '1' only if you synthesize this using Altera's Quartus.

More about the various VHDL metacomment pragma's at: http://www.sigasi.com/content/list-known-vhdl-metacomment-pragmas

Answer 2

Are you trying to infer ROMs from your code? If you're using the LPM functions, everything should "just work".

I use ROMs in Quartus and ModelSim without issue. Just create a custom VHDL file for your ROM using the MegaWizard plugin and direct it to the appropriate initialization file, or directly instantiate an altsyncram component and include the init_file generic.

Then compile or simulate as normal. I have had no problems running simulations using ModelSim (Altera version or stand-alone version) with initialized ROMs, and have not had to write any initialization code to read *.mif or *.hex files.

For reference, here is a directly instantiated ROM megafunction from a bit of my code that simulates properly in ModelSim (note the init_file generic):

-- Sine lookup table
sine_lut : altsyncram
generic map (
    clock_enable_input_a    => "BYPASS",
    clock_enable_output_a   => "BYPASS",
    init_file               => "./video/sine_rom-512x8.mif",
    intended_device_family  => "Arria GX ",
    lpm_hint                => "ENABLE_RUNTIME_MOD=NO",
    lpm_type                => "altsyncram",
    numwords_a              => 512,
    operation_mode          => "ROM",
    outdata_aclr_a          => "NONE",
    outdata_reg_a           => "UNREGISTERED",
    widthad_a               => 9,
    width_a                 => 8,
    width_byteena_a         => 1
)
port map (
    -- Read port
    clock0      => clk,
    address_a   => sine_addr,
    q_a         => sine_do
);

If you really need to do something different when simulating vs. synthesizing, there are a several ways to go about it. For simple things, you can use something like the following directives:

--synthesis translate-off
<code for simulation only>
--synthesis translate-on

http://quartushelp.altera.com/11.1/master.htm#mergedProjects/hdl/vhdl/vhdl_file_dir_translate.htm?GSA_pos=5&WT.oss_r=1&WT.oss=--%20synthesis%20translate_off

You should be able to find a lot of real-world examples of these directives via internet search, and I've included one example below (power-on reset is shorter when simulating vs. when running in real hardware):

-- Async. Power-on Reset, with de-assertion delay
process (clk)
begin
    if rising_edge (clk) then
        -- Create a delay at power-up
        if rst_PowerOn='1' then
            rst_pora    <= '1';
            rst_por_cnt <= (others=>'0');
        -- synthesis translate_off
        elsif rst_por_cnt(5)='1' then  -- 256 nS in simulation
            rst_pora    <= '0';
        -- synthesis translate_on
        elsif rst_por_cnt(19)='1' then -- 4ms in real hardware
            rst_pora    <= '0';
        else
            rst_por_cnt <= rst_por_cnt + 1;
        end if;
    end if;
end process;

For more complex situations, use your imagination. Some folks use the C pre-processor, the M4 macro language, or something similar as a preliminary build step prior to synthesis/simulation. I have makefiles and scripts that convert FileName.sim.vhdl (for simulation) into FileName.vhdl (for synthesis), processing it with some text utilities to comment/un-comment various blocks of code based on rules I crafted so I could maintain both versions in a single file (think something like an enhanced C pre-processor tweaked for use with VHDL). Just do something that fits with your workflow and team dynamics/culture.