- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Like FVM said the only other (and prefered method) is to use synchronous set/preset. any reason they have to be async?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Kaz for your quick response.
With your help I fixed the warnings. Regards, Wamor- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page