Forum Discussion

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

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

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,

14 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

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

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

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