Another "registers lost all their fanouts during netlist optimizations" confusion

Altera_Forum · ‎03-10-2013

Hi,

Another VHDL, Quartus and FPGA newbie. I'm not a student, graduated in microelectronics systems engineering > 20 years ago; this is new a hobby.

I've created my own little "CPU". Works fine under ModelSim. I now want to upload it to my FPGA but notice that I have the newbie problem "Total Logic Elements 0" and the warning "Info (17049): 296 registers lost all their fanouts during netlist optimizations."

I've seen previous suggestions to "ensure that the top level entity drives some output". As far as I can tell, that's what I'm doing, as I have some output signals in the top entity.

Obviously I'm getting something fundamentally wrong, and I'd really appreciate some pointers. Was looking forwards to flashing some LEDs :cry:

I've attached my VHDL code and the map.rpt output file.

If it makes any difference the target device is an EP2C5T144-8 on a DigiASIC board, and I am using Quartus 12.1 32bit under Windows 7 64bit.

Thank you,

Mark

Altera_Forum · ‎03-10-2013

The tool is, somehow, figuring out that "led"'s output is constant.

I suggest you simulate your design and make "led "change state. That will help you find the bug.

Altera_Forum · ‎03-10-2013

--- Quote Start ---

The tool is, somehow, figuring out that "led"'s output is constant.

I suggest you simulate your design and make "led "change state. That will help you find the bug.

--- Quote End ---

Thank you. The CPU simulated fine previously. However, as instructed I decided to simulate again. To do so I needed to add the "OUT_LEDs" instruction into my CPUs "program" (temporarily hardcoded!).

As soon as I did so, the compilation worked as expected, reporting

Total logic elements    1,103
Total combinational functions    583
Dedicated logic registers    560
Total registers    560
Total pins    9

It (still) simulates OK, and the "led" signals change as expected. JPEG attached.

This behaviour completely confuses me. Why should utilising one of my opcodes cause it to work? Obviously the CPU can't have its program hardcoded - this is just to simplify my testing.

Altera_Forum · ‎03-10-2013

The synthesis tool is simply trying to optimize your design and remove any unneeded logic.

Since your program is a hard-coded part of the design, it was actually seeing that "led" would never change and optimizing away all the logic.

So, there was nothing wrong actually. :)

A suggestion: you can use a LPM_ROM primitive to store your program code, initialized from a .hex file.

One advantage is that Quartus won't look "inside" and optimize away logic based on it's contents.

The other advantage is that you can change the program code and rebuild the FPGA configuration file without having to re-synthesize the entire design.

You could also use .MIF files, but then ModelSim doesn't know how to read .MIF. .HEX is, AFAIK, the only common format between Quartus and ModelSim.

You use it like this. And you'll find a wealth of .hex file editors out there.

        rom : lpm_rom
        generic map (
                LPM_WIDTH => 8,
                LPM_WIDTHAD => 14,
                LPM_FILE => "rom.hex",
                LPM_ADDRESS_CONTROL => "UNREGISTERED",
                LPM_OUTDATA => "REGISTERED"
        )
        port map(
                outclock => clk,
                address => address,
                q => data
        );

Altera_Forum · ‎03-10-2013

Thank you very much indeed.

I will investigate the LPM_ROM primtive, as a stepping stone to using the board's I2C eeprom.

I'm still amazed that the synthesiser can understand the "program" hardcoded into the "cpu"! Clearly I'm missing something, but am sure it will dawn on me sooner or later.

Altera_Forum · ‎03-10-2013

Well, the tool isn't smart enough to understand your program flow or something like that.

It can just apply generic logic simplification and optimization.

But if your "OUT_LEDs" opcode never shows up in the CODE array, then the tool will notice that "when OUT_LEDs" will never become true and thus that

"led <= std_LOGIC_VECTOR(to_unsigned(ACC, 8));" will never be used and thus led will always stay at zero.