Defining Flops with Async Set & Reset

[Altera_Forum]

Hi, 

 I have been trying to synthesize a flop with both a asynchronous set and a reset input on a Cyclone V using Quartus 11.1sp2. I have not been able to.  I use  always @(posedge clk or negedge rst_n or negedge set_n) begin  if (!rst_n) q <= 1'b0;  else if (!set_n) q <= 1'b0;  else q <= d; end  This is what is described on the manual, but inspite of it I always get combinatorical (and glitchy) logic added to the set to force it to have a lower priority than the set, although the manual states that asynchronous clear (aclr) is always higher priority than preset or asynchronous load. I have also tried using a active high set, and inverting the two but the result is still the same.  If I recall it right in Synopsys a directive could be set to force it to ignore the both low case and then it would synthesize properly a async set/reset flop flop, but I saw nothing similar in Quartus.  Anyone have ideas here?

[Altera_Forum]

You can't have two asynchronous control signals, it's either a set or reset(polarity doesn't matter). Two try and do what you're asking, it's building something ugly. Do you need both?

[Altera_Forum]

I guess you mean  

else if (!set_n) q <= 1'b1;  Then you get a compiler warning   --- Quote Start ---  Warning: Presettable and clearable registers converted to equivalent circuits with latches. Registers power-up to an undefined state, and DEVCLRn places the registers in an undefined state. Warning (13310): Register "q~reg0" is converted into an equivalent circuit using register "q~reg0_emulated" and latch "q~reg0latch"   --- Quote End ---    It's a question of FPGA hardware properties, not software behaviour.  Starting with Cyclone II, asynchronous preset and load of FPGA core registers have been abandoned, the registers have only an asynchronous clear since then. If you need asynchronous load, or both reset and preset of registers, the function needs to be emulated by additional logic cells and latches (the latter implemented as combinational loops).  The below gate level schematic shows the involved logic. It's rather obvious, why it will be "glitchy" and slower than a basic register. The priority of rst_n should be observed according to the RTL schematic, however.  P.S.: There's detailed help on the above quoted warning available   --- Quote Start ---  CAUSE: One or more registers in the design have one of the following conditions:   •The register has both a preset and a clear signal.  •The register has a preset signal but does not have a clear signal, and Analysis & Synthesis turned off the NOT Gate Push-Back logic option.  •The register has an asynchronous load and corresponding data signal.  The current device family does not support any of these conditions. As a result, Analysis & Synthesis converts the register to equivalent circuits with a latch, a register and logic, and the resulting register powers-up to an undefined state (X). In addition to that, DEV_CLRn places the register in an undefined state, and the resulting circuit is prone to glitches because the there are different paths from the asynchronous signals to the output of the logic representing the register. Since these paths have different delays, glitches can occur, especially if the asynchronous signals are coming from combinational logic, or if the register is feeding combinational logic. See submessages for details.   ACTION: No action is required. If you want to prevent glitches, put KEEP attributes on the asynchronous signals that feeds the register, and on the register itself. This action is necessary only if the asynchronous signals come from combinational logic or if the register feeds combinational logic. Make sure that you perform timing simulation to verify that no unexpected glitches occur.   --- Quote End ---  

[Altera_Forum]

Thanks for the reply. Yes, the set_n line had a typo. 

 As for the answer the application has really both set and reset. I was using the asynchronous fifo as described in the sunburst paper from 2002 http://www.sunburst-design.com/papers/cummingssnug2002sj_fifo2.pdf  Anyways in this application the two never occur at the same time and if the reset is held long enough then there should be no chances of glitches. So it will probably work.  Thanks for the warning though on how the Cyclone FPGAs implement set/reset flops.  -G