# Algebraic loop debugging of Simulink delay block

29 views (last 30 days)
Tim Nash on 3 Feb 2021
It is unclear to me why Simulink flagged this as an algebraic loop:
Assuming the delay block is effectively nothing more than a D-flip flop, and also assuming that the enable input of the delay block is synchronous (sensitive to the clock edge driving the delay block), then the delayed output is a reflection of the state of the inputs (including the enable) one time step later and NOT the same instance in time as the inputs. The delay block has a defined initial condition of 0, so the initial condition of the enable is also known. I cannot figure out why Simulink thinks this is an algebraic loop.
Adding an additional delay between the delayed output and the enable would break the design.
Thoughts? Is there a difference between this delay block and a D-flip flop?

Kiran Felix Robert on 9 Feb 2021
Hi Tim,
You are getting an algebraic loop error/warning because the enable input of the delay block is driven by the current output. Though the output of the block is at a delay with respect to the input (in values), but the mathematical model input of the block has a direct dependence on the current output which causes an algebraic loop error. Refer the Algebraic Loop Concepts for more information regarding algebraic loops.
Basically, algebraic loops occur when an input port with direct feedthrough is driven by the output of the same block, either directly, or by a feedback path through other blocks which have direct feedthrough.
If an algebraic loop is detected you have two options: leave the algebraic loop intact (suppress the warning), or eliminate it. If the speed of execution of the model is acceptable, leaving the loop is probably the better choice. If the speed of execution is slow, you must eliminate the algebraic loop.
To resolve the loop, you can add a unit-delay to the feedback path and to all other forward paths in the same stage (balance the feedback loop delay with delays in other paths).