Forum Discussion

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

Synthesis error in Quartus v12 & v11

There is an apparent synthesis error in Quartus v12, v11 and possibly other versions. I found this by adding an asynchronous preset to a register bit. When this is done that register bit is not preset to one when the async preset signal is asserted and the bit remains permanently stuck at zero even after the async signal is de-asserted. If the preset is removed from the design then the register bit will change state as expected. All the other bits in the register toggle as expected. I haven't seen this before, so it's probably a combination of things that causes it to happen. I'm seeing this in the gate level simulation; the RTL simulation functions as expected. What is the best way to bring this to Altera'a attention?

6 Replies

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

    what chip is it for? newer chips have dropped the async set and preset inputs to the registers.

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

    Please show a code example that allows to reproduce the problem.

    If you are feeding both asynchronous set and reset to a DFF, it has to be emulated by a combination of a DFF, XOR gates and latches for most recent FPGA, also Cyclone III. What you describe may be either a real synthesis error or just lack of understanding how Quartus emulates the function at gate level.

    An example is shown in this post http://www.alteraforum.com/forum/showthread.php?t=36490
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Here is the code snippet:

    
    reg  sr;
    reg  qCtrl;
    reg  qDelay;
    reg  qTrigA;
    reg  qTrigB;
    reg  qXfrStart;
    reg  qXfrSize;
    wire  regAddr = sr;
    always @(posedge clk109, posedge reset109) begin
       if(reset109) begin
          qCtrl <= 16'b100;
       end else begin
          if(shiftIn)
             sr <= { sr, dataSync };
          if(rxEnd) begin
             case(regAddr)
                3'd0: qCtrl <= sr;
                3'd1: qDelay <= sr;
                3'd2: qTrigA <= sr;
                3'd3: qTrigB <= sr;
                3'd4: qXfrStart <= sr;
                3'd5: qXfrSize <= sr;
             endcase
             sr <= { 4'b0, stopIndex };
          end
       end
    end
    

    The line highlighted in blue is the preset causing the problem. If it's changed to:

    qCtrl <= 16'b0;

    The problem does not occur. The clock enables shiftIn and rxEnd are mutually exclusive, in case you were wondering.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The problem should be expected to occur in a reduced design as well, did you try?

    qCtrl[2] will be synthesized applying "not pushback", means the polarity of this register bit is inverted, also it's D and Q lines. As a side effect, the initial state of qCtrl[2] changes to '1'. Did you notice?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    According to the post-fit simulation, qCtrl[2] is always zero, even right out of initialization. It remains zero when reset109 is asserted and it cannot be set synchronously either. It's like the bit is hardwired to ground.