Possible compilation error of nested if statements in VHDL

Altera_Forum · ‎07-06-2010

Hello!

Is there any implicit difference between nested "if" statements in the process block under "'event" and single "if" utilizing "and product"?

For some unknown (to me) reason the commented "if" produces an expected netlist of upper bounded counter, but the nested "ifs" that follows do not. They seems to result in some confusing "highest bit setter" (with two sequential muxes on reg D input) that sets frame_reg to ('high => '1', others => '0'), and that is all the logic does.

Can it be the case of an error in compiler that mistakenly tries to instantiate some priority encoding logic?

Or is it a known behaviour?

Or maybe it is a VHDL feature?

Thank you in advance.


frame_wren <= '1' if another_cnt = to_unsigned(12, another_cnt'length) else '0';
process(reset_n, clk, clk_ppu_en, frame_reg, frame_wren)
begin
    if reset_n = '0' then
        frame_reg <= (others => '0');
        
    elsif clk'event and clk = '1' then
--     if clk_ppu_en = '1' and frame_wren = '1' and frame_reg(frame_reg'high) = '0' then
--            frame_reg <= frame_reg + 1;
--     end if;
        if clk_ppu_en = '1' then
           if frame_wren = '1' then 
               if frame_reg(frame_reg'high) = '0' then
                   frame_reg <= frame_reg + 1;
               end if;
           end if;
       end if;
    end if;
end process;

Altera_Forum · ‎07-07-2010

When you nest if's like you have done, you are implying priority.

Because you could have extra code inside each if statement, the extra "enable" output is needed for each.#

for example:


if clk_ppu_en = '1' then
  a <= ip;
    if frame_wren = '1' then 
      b <= ip2
    if frame_reg(frame_reg'high) = '0' then
      frame_reg <= frame_reg + 1;
    end if;
  end if;
end if;

When you check the netlist - are you checking the RTL view, or the map view? The fitter may be able to collapse the nested ifs into a single boolean equation.

Altera_Forum · ‎07-07-2010

I see, but in my case there is now other signals in ifs. And I believe, this constructs, when synthesized, must behave exactly the same way (not paying attention to timings).

But they don't :( I checked it many times on harware (Cyclone II on DE2 board) trying to find out why does so simple component produce so strange results.

The RTL View shows that the single "if" construct is compiled into an "and" gate that feeds the clk_en input as expected, but the second one is not. The compiler generates some strange two-stage MUX feeding data input of the register, but mux doesn't select between reg and reg+1, but rather '1' & reg(reg'high-1 downto 0) and reg+1 (or something alike).

Does it sound like a compiller bug? Should I post my findings elsewhere?

Altera_Forum · ‎07-07-2010

I dont think it is a compiler bug. Did you checp the map view rather than RTL view?