[Synth 8-295] found timing loop

[bhagavantha.reddy@open-silicon.com]

hi..,

Vivado2019.2 giving [Synth 8-295] found timing loop critical warning durring syathesis run. any idea, why i am facing this issue in vivado 2019.2. is it tool issue ?

Thanks,

[drjohnsmith]

its in your timing constraints,

[syedz]

bhagavantha.reddy@open-silicon.com 

Open synthesized design and run check_timing report by running the following command. This report will show you the loop on which tool is complaining. You need to fix it.

check_timing -verbose -name timing_1

--Syed

[bhagavantha.reddy@open-silicon.com]

Hi johnsmith,

Thanks response. can you please elaborate more on, what is it ?

[bhagavantha.reddy@open-silicon.com]

Hi Syed,

Thanks for the response.
I do checked with given command. now I could able to see timing window and looped paths and some more other details.
Can you please tell me, why I am seeing this critical warning only in vivado2019.2. is it RTL issue or tool issue ?

Thanks,
Reddy

[syedz]

bhagavantha.reddy@open-silicon.com 

Its a design issue. You should get the loop from the report showing the output of combinational logic getting connected back to input logic.

--Syed

[markg@prosensing.com]

bhagavantha.reddy@open-silicon.com 

One type of timing loop is described on page 309 of UG906(v2019.1) as follows:

Combinatorial timing loops are created when the output of combinatorial logic is fed back to its input, resulting in a timing loop. This loop unnecessarily increases the number of cycles by infinitely going around the same path and cannot be timed. To resolve the timing loop, the Vivado IDE disables the timing arc on the cell in the loop.

Mark

[bhagavantha.reddy@open-silicon.com]

Hi Mark,

Thanks for your response.
Ill use this for clearing issue.

[drjohnsmith]

One question

why was this not spotted when you simulated,
thats where logic errors are found,

[bhagavantha.reddy@open-silicon.com]

hi Syed,

I've cross checked RTL design by running simulation, here we don't see any timing loop issue and timing loop issue is coming only in vivado2019.2 but no issue with older version of vivado and ISE tools. Can you please have your observation on it.

Thanks,
Bhagavanth

[richardhead]

Without the source, there is little we can say

[dcbingaman]

I am getting the same issue.  Attached is the VHDL code.  If you set SPI_Slave2.vhd as top level and run synthesis you do not get a timing issue.  If you set TopLevel.vhd as the top and run it with SPI_Slave2 entity instantiated you get the error.  I see nothing wrong in the VHDL.

[markg@prosensing.com]

@dcbingaman 

-see the following post for instructions on locating the timing loop:

https://forums.xilinx.com/t5/Implementation/DRC-LUTLP-1-Combinatorial-Loop-Alert-But-I-didn-t-find-this/m-p/1115337

Mark

[surajc]

Hi bhagavantha.reddy@open-silicon.com ,

Are you using any kind of Custom Attributes on the signal in RTL? 

To check this as @syedz mentioned Open Synthesized Design -> do a Check Timing -> Select the net / cell for this loop -> Right Click -> Go to Source.

Previously there were issues reported in which the attributes like syn_preserve and async_reg were not properly handled by synthesis and tool inferred timing loops on those signals.

Can you check if this is the case? 

Also, can you try this in the latest release of vivado i.e. 2020.1?

[dcbingaman]

Thanks for the response and help.  I simply changed the design and the problem went away.

[prajwalkempanna]

--> Open synthesized design

--> type "check_timing -verbose -name timing_1" in the tc console 

this will report the paths were combo loops are present.

The example below will give you an idea to overcome this issue,

if(a = '1')then

if(sop = '1')then

a <='1';

else

a<= 0;

In the above example, we are using signal 'a' to generate signal 'a' back again this is called a combo loop.

you need to convert it to a sequential block.

[cube1]

drjohnsmith: Although I am not the OP here, I had a situation where I had a half-dozen timing (combinatorial) loops out of an historical design for an IBM 1410 done to the IBM logic block level.  It simulated just fine, because in the "real world" other signals were such that the conditions necessary for the timing loop never actually occurred because of those other signals.  So that is one reason why it might not be caught during simulation.    Even at that, only two of those were blocking generating a bitstream.

In my case it took me a few hours to track it down because 1) It was not an issue I had run into before during the pilot where I recreated a design I was involved in as a student in 1972 and 2) The tool was optimizing away some of the intermediate logic elements.  Turning down the level of optimization (I set flatten_hierarchy none) along with "Go To Source" available on *some* of the logic elements helped me to be able to track it down, because then I could see signal names to follow the loop.

(Interestingly, in Vivado 2018.2, without flatten_hierarchy set to none, Go To source on the LUT in the schematic sent me off to something that was not even closely related to the issue, perhaps because the LUT was being used in more than one place.)