Sync Resets with Clock Enables

[Steve89]

With AMD FPGAs, sync resets are recommended. Coding in HDL is straightforward because the sync reset input has priority over the clock enable.

Intel FPGAs have a different priority. Async resets, then clock enables, then sync resets. Does Intel recommend one reset type over the other?

If sync resets are used and a clock enable is needed, isn't extra logic required to force the clock enable high when triggering a sync reset?

I see two alternatives:

1. switch to async resets

2. add the logic to force the clock enable high on assertion of a sync reset.

Any advice would be appreciated.

[sstrell]

Synchronous resets are recommended over asynch if possible.

I guess I don't understand the issue.  If clock enable is needed, then it must be enabled for a synch reset to work.  If you don't need clock enable, then don't use it and synch reset will work.

[Steve89]

I'm glad to hear sync resets are recommended. And I understand that I need to assert CE for the sync reset to work.

My concern is the extra logic that it takes. With AMD, I don't need to assure the clock enable is asserted. Assert sync reset and the flip-flop will reset on the next rising edge of the clock.

Say I have a module with a sync reset input. The clock enable on each flip flop is used to register the data. I would expect that the flip-flops in the module are going need various signals for the CE but only the single reset. But with the Intel FF priority, I will need to do:

local_ce_0 <= sync_reset or ce_0

local_ce_1 <= sync_reset or ce_1

...

local_ce_x <= sync_reset or ce_x 

Maybe with being new to Intel FPGAs I'm not thinking about it correctly. But it seems that it adds to the source code and the hardware required.

Another issue for those of you with experience porting designs between the two vendors -- if you're using sync resets do you rewrite the code to account for the different priority?

[ShengN_Intel]

Hi,

Sync reset is more recommended compared to async reset in terms of retiming.

In terms of logic, sync reset with clock enable will have more logic compared to sync reset (screenshot):

Async reset with clock enable have same logic as async reset (screenshot):

Thanks,

Best Regards,

Sheng

[_AK6DN_]

Question: why does your SYNC RESET with NO CLOCK ENABLE example NOT use the SCLR input on the DFF and instead uses a separate logic mux on the input?

CycloneIV device logic blocks look like this and your example does not use the CE or SR capability of the DFF itself. Why?

 

[sstrell]

As mentioned, you don't need to use clock enable at all.  Just assert synch reset and it resets with the clock edge.

[Steve89]

I found more information in the Intel Quartus Prime Pro Edition User Guide, Design Recommendations (UG-20131), for 20.1. Section 1.5.2, Secondary Register Control Signals ...

"If you define a register with a synchronous clear signal that has priority over the
clock enable signal, Intel Quartus Prime synthesis emulates the clock enable
functionality using data inputs to the registers."

"The signal order is the same for all Intel FPGA device families. However, not all device
families provide every signal. The priority order is:
1. Asynchronous Clear (clrn)—highest priority
2. Enable (ena)
3. Synchronous Clear (sclr)
4. Synchronous Load (sload)
5. Data In (data)—lowest priority
The priority order for secondary control signals in Intel FPGA devices differs from the
order for other vendors’ FPGA devices."

In Example 37, they use all of the control signals:

module top(clk, clrn, sclr, sload, ena, data, sdata, q);
    input clk, clrn, sclr, sload, ena;
    input [7:0] data, sdata;
    output [7:0] q;
    reg [7:0] q;
    always @ (posedge clk or posedge clrn)
        begin
        if (clrn)
            q <= 8'b0;
        else if (ena)
            begin
            if (sclr)
                q <= 8'b0;
            else if (!sload)
                q <= data;
            else
                q <= sdata;
            end
        end
endmodule

This would not be optimal in an AMD device because the sclr would need to be higher priority than the ena. 

After 20 years of Xilinx/AMD, I can't see the advantage of Intel's priority.  But I'll have to adapt.