Where is the algebraic loop coming from?

Dear all,

I faced an issue with algebraic loop in simulink (see the model attached).

When I update the model it says "Algebraic loop error", even though there seem to be no algebraic loop at all.

The issue is resolved if I combine these two subsystems into a one.

Could you please explain where the algebraic loop is coming from?

Thank you!

Answer 1

[Walter Roberson]

The ready_out of toRAM_interface is an output. You send that to ready_in of the FIFO. Meanwhile, the FIFO has lines that are inputs to the toRAM_interface.

Everything that is connected has to be true at the same time unless separated by a zero order hold or memory block or rate transformation (including a 1/z block with a very short time constant. (I might be overlooking some other cases.) So your connected series means that the ready_out from the toRAM_interface has to be true at the same time as the outputs of the FIFO and the output lines of the FIFO. Even if we suppose that the read_out line is the trigger for the FIFO to send information, no time is being alotted for the *_out lines to settle or for the ready_out line to change state in response to the *_in being received. That is an algebraic loop.

Your system either needs a delay on the ready_out line, or else delays on the *_out lines that are input to the toRAM_interface

[Sergei]

Thank you for your answer, @Walter Roberson,

I am not sure I understood correctly what you mean.

The current output ready_out of toRAM_Interface does not depend on the current input *_in of toRAM_Interface, it only may change in the next cycle (if there was some block that could change the value or ready_out according to readiness of the block I mean) depending on the input one cycle before.

And even if ready_out did depend on the current input *_in, the problem would not be resolved by putting everything in the same subsystem, as per model I attach here.

In my understanding algebraic loop occurs when two signals depend on each other at this time instance -> the simulator cannot decide on the state of the system. Here it is not the case: ready_out does not depend on *_in, so it can be initialized with the actual value (0) and FIFO can assign 0 to signal valid. Correct me if I am wrong please.

Thank you again!

[Walter Roberson]

Suppose we are at the state where toRAM_interface has just set ready_out to be true, thereby triggering the FIFO to send samples. We will simplify the discussion by focusing on the beginning of the ready_out pulse, ignoring any time before that. We will also simplify by assuming that FIFO reacts to the ready_out pulse immediately, making data for the *_out lines immediately available.

Now at some point, the toRAM_interface needs to signal that it is busy (because it is reading the *_out signals and processing them.) When that happens, toRAM_interface will set ready_out to false.

Here is the thing: it takes time for ready_out to flip to false.

Consider the contrary: if it did not take any time for ready_out to become false, then it would become false simultaneously with it becoming true to signal that toRMA_interface is ready. But no signal can be simultaneously true and false, and Simulink cannot process the possibility of a signal being simultaneously true and false.

The Simulink interface between FIFO and toRAM_interface needs to be configured so Simulink knows that there is time between ready_out becoming true and ready_out becoming false. Even if the time is only 50 nanoseconds, there needs to be a delay line or a zero-order hold or a memory block or a transfer function (I might have overlooked options) on the line so that Simulink is not trying to figure out how to handle the situation of ready_out being simultaneously true and false.