Forum Discussion

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

Warning Combinational Loop

I'm getting a warning (332125) from Quartus which is telling me that it found a combinational loop. I found an example of a schematic of what a combinational loop means and I understand that. Its feeding the output back to the input through some logic that is not clocked so it generates a race condition.

The problem is I do not know why my verilog source code is creating such a loop and I don't know how to accomplish the task I'm trying to do.

The goal is to create an address register which I can set from the outside world by toggling an address latch enable (ALE) bit. Then I want to auto increment the address inside the device every time I toggle a read bit (which reads what the address is pointed to). Heres the code I'm trying to use (simplified): 


module foo(inout wire  data, input bit ale, input bit rd, input bit clk);
  reg  data_in;
  reg  addr;
  // clock the data bus into the input register
  always_ff @ (posedge clk)
    data_in <= data;
  // set the addr at the pos edge of ale, increment it at neg edge of rd
  always_ff @ (posedge ale, negedge rd)
  begin
    if (ale) addr <= data_in;
    else addr = addr + 1'b1;
  end

The addr increment seems to create the combinational loop because if I comment it out then there are no problems. But how can I do what I want? I can't use the clk signal to create sequential logic because that will clock it many times, not just on the falling edge of rd. Do I need to create a state machine?

5 Replies

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

    Apparently you are using a FPGA family that doesn't support asynchronous set of registers (most recent FPGAs don't). Thus the ale action has to be emulated by a multiple LE construct, including combinational loops. You get detail information by viewing the Quartus online help for the respective warnings.

    If the timing constraints of your design are met, you can simply ignore the warning. Or find a fully synchronous way to implement the intended function. Without knowing the exact timing of involved signals, the feasibility can't be determined.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Over the weekend I worked on a higher level section of my code and I tried implementing this auto incrementing address again and this time it worked without complaints. Here is the code that worked: 

    
	always_ff @ (posedge ale, negedge rd)
	begin
		if (ale)
			addr_register <= data_in;
		else
			if (! rd) addr_register <= addr_register + 8'h01;
			else ;
	end

    There are a couple differences with the original code. I have an explicit test for the rd line low, which I had assumed in the original code (only other way to trigger this code if the ale was not the cause). I also used a non-blocking assignment and added an 8 bit representation of the +1. I'm not sure which of these actually makes it work but it seems to work fine now.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    I'm not sure which of these actually makes it work but it seems to work fine now.

    --- Quote End ---

    You reported about warnings, not failure of the original code.

    In any case, the problem can be rarely avoided by the changed code.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    True, they were warnings. But the nature of the warning seemed very serious to me since it described a possible race condition.

    I re-wrote the code the original way and still there is no warning. So that puzzles me even more. Oh well, I don't like these types of mysteries.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    I don't see any mystery involved. I presume you are uisng a recent FPGA family without a register asynchronous load feature. Then you'll get a warning for the original code unless data_in evaluates to a constant.