presettable and clearable registers warning in Quartus, how to fixed it?

[Altera_Forum]

hi, 

 When i check my syntheis report in Quartus, there is some latch warnings " 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 "vga_controler_line:vga_cntl_1|hsync_out" is converted into an equivalent circuit using register "vga_controler_line:vga_cntl_1|hsync_out~_emulated" and latch "vga_controler_line:vga_cntl_1|hsync_out~latch" "  my code is just like this  " always @(posedge clk or posedge rst) if(rst)  hsync_out <= ~SYNC_POLARITY; //SYNC_POLARITY is register setting else  hsync_out <= xxx; "  How i can code the better way to void Qurartus synthesis latch warning?  Thanks very much,

[Altera_Forum]

I'm having the same problem, it seems Quartus won't start (reset) a register with a value coming from a certain bus or wire with preset or clear. Did you solve this?

[Altera_Forum]

I think newer devices have had the preset and set pins removed from the register, so latch circuits are muxed into the D path to get preset and set to work.

[Altera_Forum]

There's no simple workaround. You either have to accept the equivalent circuit, involving two or three LEs consumed in addition and increased delay for the register in- and output signals. Or use a synchronous set instead of an asynchronous if ever possible.

[Altera_Forum]

I've actually used this several times because I need parallel loads on shift registers for custom SPIs, is there maybe another reliable way to do this? I'm not worried about the extra LE's but the fact of having latches just doesn't quite comfort me in terms of delay and maybe glitches.

[Altera_Forum]

Like FVM said the only other (and prefered method) is to use synchronous set/preset. any reason they have to be async?

[Altera_Forum]

No specific reason, is just the way I normally see it, and this is the way Xilinx translates it in the RTLs, although I haven't checked if it does implement that or if it changes the circuit for an equivalent one like Altera.

[Altera_Forum]

Following the tips in this thread, I have been attempting to cure this "critical warning" (according to the Timing Advisor). I'm using a Cyclone III so I suppose this device is one that does not have the preset and clr. So I need to do synchronous setting/clearing. Its been tricky, but I think I discovered how to do it. Perhaps someone can confirm that I'm on the right track. 

 As an example, I want to take input data and put it in an address register when the ale signal is high. The address would be used in a read or write operation in another part of the code. Then at the end of a read or write cycle I want to increment the address. This basically implements an auto-incrementing multiplexed address/data bus. You can give it a new address with the ale signal or just let it increment at the end of a read or write.  First, the problem seems to be caused when I do something like this:  always_ff @ (posedge ale, negedge end_rd_or_wr) begin if (ale) address <= data_in; else address <= next_address; end  The end_rd_or_wr signal comes out of a state machine. The next_address is just address + 1. When this code is compiled I get the warning that address is being converted into latches, etc.  However, if I use the base clock of the system and then use the ale and the end_rd_or_wr inside the always block, it does not give me the warning. Code looks like this:  always_ff @ (posedge clk) begin if (ale) address <= data_in; if (end_rd_or_wr) address <= next_address; end  When coded this way I have to adjust how I'm creating end_rd_or_wr so that its only high during one clk rising edge. But I can do that.  So is this the right way to clock stuff into a register when you need it to depend on other conditions?

[Altera_Forum]

That's one way to do it. I'm sure you're just going to get two cascaded mux's as the input to your address register, with "ale" having the higher priority.

[Altera_Forum]

--- Quote Start ---  That's one way to do it. I'm sure you're just going to get two cascaded mux's as the input to your address register, with "ale" having the higher priority.  --- Quote End ---    That sounds like what I want. I'm open to other suggestions though.

[Altera_Forum]

--- Quote Start ---  That's one way to do it. I'm sure you're just going to get two cascaded mux's as the input to your address register, with "ale" having the higher priority.  --- Quote End ---   In the present code, the priority is for end_rd_or_wr according to sequential code evaluation (the last assignment wins). You have to exchange both lines or use an if ... else ... construct to set it different.  As an additional remark, asynchronous ALE latch operation is usually chosen on purpose. Analyze the bus timing to check if synchronous ALE can work as well.

[Altera_Forum]

--- Quote Start ---  In the present code, the priority is for end_rd_or_wr according to sequential code evaluation (the last assignment wins). You have to exchange both lines or use an if ... else ... construct to set it different.  As an additional remark, asynchronous ALE latch operation is usually chosen on purpose. Analyze the bus timing to check if synchronous ALE can work as well.  --- Quote End ---    The 2 signals would never occur at the same time, so its a don't care. Can you elaborate on what you are suggesting for asynchronous ALE? The ale signal is in fact asserted well after the address is put on the bus and for several clk cycles.

[Altera_Forum]

Hello, 

 The below code is giving me the following warnings: 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: Timing Analysis is analyzing one or more combinational loops as latches    It sounds maybe a little paranoid but I always want to have my code warning-free. Coud someone maybe explain to me how to fix these warnings.   Thank you for the responses,   Wamor    process(clk, reset_n, delay_out_reg, count_out_reg) begin if reset_n = '0' then multi_IO_output_counter <= delay_out_reg; multi_IO_pulse_counter <= count_out_reg; else if rising_edge(clk) then if multi_IO_clock_enable = '1' then if multi_IO_output_counter > clock_divide_out_reg - 1 then multi_IO_output_counter <= (others => '0'); if multi_IO_pulse_counter > 0 then multi_IO_pulse_counter <= multi_IO_pulse_counter - 1; end if; else multi_IO_output_counter <= multi_IO_output_counter + 1; end if; else multi_IO_output_counter <= delay_out_reg; multi_IO_pulse_counter <= count_out_reg; end if; else -- need to do something here?? end if; end if; end process;

[Altera_Forum]

Your are assigning at reset to "multi_IO_output_counter" ...etc another signal. 

When you do that it implies that the clocked register "multi_IO_output_counter" has also to acquire a value from external logic on its q output outside clocked edge. The compiler then builds some unclocked logic on q output that latches the async value until clock edge arrives.   normally we assign a constant here at reset release.Here the flip can inherently apply zero. It can also apply 1 and you get a warning that can be ignored.  If you do want that then apply reset synchronously.

[Altera_Forum]

Thank you Kaz for your quick response. 

With your help I fixed the warnings.   Regards,   Wamor