Erroneous "combinational loops" warnings

[lambtron]

found combinational loop during mapping

Anyone know how to eliminate false "Warning: found x combinational loops!" messages from Synplify? Specifically, the problem is that this warning pops up wherever I have a bidirectional bus interface. I am using Lattice Semiconductor's ispLEVER Starter Synplify 5.0.01.73.31.05.

For example:

-- junk.vhd

library IEEE;
use  IEEE.std_logic_1164.all;
use  IEEE.std_logic_unsigned.all;

entity cpld is
    port (
        dir:	in 		STD_LOGIC;
        a_bus: 	inout 	STD_LOGIC;
		b_bus:	inout	STD_LOGIC
  	); 
end cpld;

architecture Structure of cpld is

	signal i_a_in:	STD_LOGIC;
	signal i_a_out:	STD_LOGIC;

	signal i_b_in:	STD_LOGIC;
	signal i_b_out:	STD_LOGIC;

	component G_BIDIR Port (
			I 	: in    std_logic;
           	OE 	: in    std_logic;
           	O 	: inout std_logic;
           	FBK : out   std_logic );
	end component;

begin	
	
	A_BUS:  G_BIDIR	port map( I => i_a_out, OE => dir    , O => a_bus, FBK => i_a_in );
	B_BUS:  G_BIDIR	port map( I => i_b_out, OE => not dir, O => b_bus, FBK => i_b_in );
	
	i_a_out	<= i_b_in;
	i_b_out	<= i_a_in;

end Structure;	   

---------------------------

library ieee;
use ieee.std_logic_1164.all;

entity G_BIDIR is Port (
	I 	: in    std_logic;
	OE 	: in    std_logic;
	O 	: inout std_logic;
	FBK : out   std_logic );
end G_BIDIR;

architecture behavioral of G_BIDIR is
begin
	O 	<= I when OE='1' else 'Z';
    FBK <= O;
end behavioral;

Synplify generates the following warnings for the above code:

Warning: Found 1 combinational loops!
         Each loop is reported with an instance in the loop
         and nets connected to that instance.
@W: BN134 :"junk.vhd":57:4:57:5|Found combinational loop during mapping
1) instance A_BUS.O_1 work.cpld(structure)-A_BUS.O_1, output net "a_bus" in work.cpld(structure)
    input nets to instance:
	net "b_bus" in work.cpld(structure)
	net "dir" in work.cpld(structure)
End of loops
Warning: Found 1 combinational loops!
         Each loop is reported with an instance in the loop
         and nets connected to that instance.
@W: BN134 :"junk.vhd":57:4:57:5|Found combinational loop during mapping
1) instance A_BUS.O_1 work.cpld(structure)-A_BUS.O_1, output net "a_bus" in work.cpld(structure)
    input nets to instance:
	net "b_bus" in work.cpld(structure)
	net "dir" in work.cpld(structure)
End of loops

Any ideas would be appreciated!

 

[anovickis]

combinational loops

In general you need to add clocked logic to get rid of those sort of things.

:|

 

[lambtron]

combinational loop synplify

In general you need to add clocked logic to get rid of those sort of things.

If what you say is true then it would be impossible to implement a bidirectional bus buffer!

This device (Lattice ispMACH LC4064) has an architecture that is clearly intended to support bidirectional buses: each i/o cell has a tri-state pin driver and separate internal input/output nets. I see no reason why a latch should be formed when there is no combinatorial path between the i/o block's internal input and output nets.

Frankly, I think it's a Synplify bug, and what I need is a bug fix or some kind of vhdl workaround. Unfortunately, shoehorning a clock into my flow-through bus buffer is not a viable workaround as it will introduce unacceptable delay and unmanageable setup and hold time restrictions.

 

[lucbra]

vhdl found combinational loop

Hi,

If you look closely to the architecture of the LC4K, then you will find that the tristate is an output from a macrocell. This cell has a FF in it.
So to avoid the warning, you should add a FF in the output stage of the bidir, the input can be used to drive another FF.

So as said allready, use clocked signals. You will get rid of the warnings. And it's definitely not a bug in Synplify.

Not using clocked signals is never a good practice and must be avoided by any means.

Regards

 

[anovickis]

synplify rename my signals

Yes we should use clocked, but .. still it should work as it is - I'm thinking this appears to be bug. The logic actually generated looks correct though

Leo spec does not complain about this and the schematic is correct.

Have you tried submitting to SOS ?

I'm enclosing both images of the technology view - one from leo spec one from synplify...

As an aside in leo you must also rename the buffer instance names to not clash with the signal names.

 

[lambtron]

loop in isplever combinatorial

If you look closely to the architecture of the LC4K, then you will find that the tristate is an output from a macrocell.

No! The attached diagram shows quite clearly that the tristate driver is part of the io cell. There is no FF in the io cell, implied or otherwise. Furthermore, the diagram shows that the left sides of the input and output buffers are separate nets and, as a result, a latch is NOT formed so long as these nets are not combinatorily connected.

Not using clocked signals is never a good practice and must be avoided by any means.

Perhaps you are confusing this application with state machines and sequential logic. There are a good many applications in which unclocked logic is not only acceptable, but mandatory, and this is one of them.

I am attempting to bridge two asynchronous buses, A and B, in real time. Bus A will be driven onto B, or B onto A, but never both at the same time. This is a very common application that has been implemented with unclocked, combinatorial logic for decades. If you are unfamiliar with this then have a look at the venerable 74245 bidirectional bus buffer!

 

[lucbra]

inout std_logic

Hi,

You are right about the tristate bus in the IO cell, but still, the input of the IO cell is coming from the ORP (output routing pool). And this is connected to the macrocell.

So, your signal (port A) comes in through a buffer, is routed to the central switch matrix, out to the macrocell, to the output routing pool, to the IO cell (with the tristate buffer), to the IO pad, right?

There is only one way to bypass the FF in the macrocell, this is through the high speed path. I don't think you are using this feature, so you get the warning, and the predictable result.

In case you aren't convinced, try calling your local FAE. If he thinks it is a bug in Synplify, he will certainly submit a case to techsupport, and you will soon get your bug fixed.
I personally don't think it is a bug, but I don't want to argue.

Regards

 

[lambtron]

fpga combinational loops

There is only one way to bypass the FF in the macrocell, this is through the high speed path. I don't think you are using this feature, so you get the warning, and the predictable result.

The macrocell is shown below. It includes a multiplexer that can be configured to bypass the FF. This feature is present on virtually every pld macrocell I have ever seen.

As with all other pld's I have used, there is no need for me to do anything special to select the FF bypass; this is configured automatically by the synthesis tools when I specify a combinatorial function. If this were not the case, how would I ever implement a combinatorial function?

In case you aren't convinced, try calling your local FAE.

Good idea! I did that and the fae acknowledged what I have determined experimentally: the synthesis tools are generating false warnings but no undesired latches. There doesn't appear to be any way to eliminate these false warnings without also turning off legitimate warnings. So I must carefully read through all the warnings to be sure there isn't a valid one hidden among the false ones.

It looks like the solution can only come from Synplify since this is clearly their bug and no one has suggested a viable workaround. If and when the fix is available I will no longer get these warnings. In the meantime I have documented this issue and put a notice in the design files that (hopefully) others will see.

 

[sudhirkv]

warning: found combinational loop

Your analysis is ok but is there any issues that this circuit will not work for that intended functionaltiy bcoz of that warning...