Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)

Bug in Quartus II

Altera_Forum
Honored Contributor II
1,695 Views

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 !
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
643 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
643 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
643 Views

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).
0 Kudos
Altera_Forum
Honored Contributor II
643 Views

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.)

0 Kudos
Altera_Forum
Honored Contributor II
643 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
643 Views

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...)

0 Kudos
Reply