Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Bug in Quartus II

I stumbled upon a bug in Quartus II (9.0 and 9.1 SP2). It confuses a preset for a clear in some situations.

It does not show in the RTL Viewer, nor the program file, but does show in the Technology Map Viewer, and affects (and this is how I found out !) the standard Simulator (which acts as if the preset is in fact a clear).

Sort of minimal AHDL input looks like this (built for an EPM7128STC100-10) :

---

SUBDESIGN lala

(

reset : INPUT;

clock : INPUT;

data[1..0] : INPUT;

product : OUTPUT;

)

VARIABLE

wrong_ff[1..0] : DFFE;

BEGIN

wrong_ff[].d = data[];

wrong_ff[].clk = !clock;

wrong_ff[0].prn = reset;

wrong_ff[1].clrn = reset;

product = wrong_ff[0]# wrong_ff[1];

END;

---

There does not seem to be an obvious way around this bug (e.g. ungrouping and/or renaming the DFFEs). Although removing the 'other' DFFE seems to prevent the problem.

And yes, I know I should be using other simulators.

Fix this, Altera !

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Where on earth have all my line breaks gone ? :mad: Had to re-edit !

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Note that all asynchronous presets will get converted to asynchronous clears and a not-gate will be placed before and after the register. So when the register powers-up to 0 or is cleared to 0, the not-gate after it will invert it so it looks like a 1. All logic going into the register will get inverted going in and out. So from a system level, everything works fine, but if you look at that register by itself in a simulation(or with SignalTap), it will look like it's behaving the opposite of what it should. There should be a table in the synthesis report about Inverted Registers, although I wish they would change the register name in a way that would make it recognizable without going to that table. In FPGAs, these extra inversions are generally free. The major place they aren't is I/O registers since there is no LUT between the register and the I/O port, but the I/O registers actually have a real preset.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Informative, thanks.

    Very bad idea not to reflect the inversion of the register in the simulator, though. Nobody trawls through reports unless they have to (well, I don't, and I've just had a look, and even then couldn't find it being mentioned).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I'd rather have the name changed in an identifiable way(if you're register had ~inv added to the end, or something like that, it would probably at least let you know something was up). I'm not a fan of post-synthesis simulations not showing the inversion since it gets away from "how" something gets synthesized. (If you're doing AHDL, then there really is nothing equivalent to an RTL simulation, it always get synthesized into logic for simulation.)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I expect the name in simulation to reflect the name in the design file, if they are the same. The name has semantics, which must not be changed silently in simulation.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    For VHDL/Verilog simulation that's true, because RTL simulation is before synthesis every touches it, and post-synthesis and/or fit simulations are supposed to represent how it's actually synthesized, even if it doesn't match the original code. For AHDL, there is no RTL simulation, which is why this can occur. (Trust me, there is a whole other can of worms, probably much bigger, when you get into the differences between simulation and synthesis of HDL...)