Coding philosophy : Is using global goto like using a global variable?

Hi,

Must I considere that using a global goto block in a Simulink model is like defining a global variable in a code?

I dont' talk about the functionnal point of view, but about "coding philosophy".

In several companies I've worked for, I've come across coding rules that recommand to use global variables as less as possible, and more often totally avoid them...

In a code, global variables are shared between functions, while in Simulink, global gotos are shared between subsystems... But subsystems are not "functions"...

So I'm wonder about this "global" Goto option in Simulink... Is it just an "option name" or is there something underlying behind this name?

GL.

Answer 1

[Fangjun Jiang]

The simple answer is YES.

1. What you see in C code is a code flow. The code is executed in sequence.
2. What you see in Simulink is a data flow. The data flollows the signl lines.
3. The function interface in C code gives a data flow. The input/output arguments of the function give you clear indication of what data are inputs and outputs, except when there are global variables involved. Global variables are invisible at the function interface. Their access are all over the place thus complicated in terms of execution order.
4. Simulink model gives you immediate data flow/interface at every level, except when there are Goto/From blocks with global scope. Goto/From block gives you a way to track the data flow but it is not visible at interface level. Although most subsystems are non-functinal ("virtual" in Simulink term), many subsystems could be "atomic" or "non-virtual" thus a function could be generated for that subsystem, thus there will be a global variable declaration inside that function.

Answer 2

[Pat Gipper]

The thing about global visibility is that this signal can be accessible anywhere in the entire model, from sub-system to sub-system, from the top level of the model on down. The signal name cannot be re-used anywhere else in the entire model. This makes it difficult to combine subsystems from multiple designers because of potential signal name duplication.

It is therefore encouraged that you use "local" option to the maximum extent. But local signals are only accessible in From blocks at the same diagram level as the Goto block. This is painful restriction results in the "scoped" option, which allows you to have the From block at lower levels within the same sub-system. But the one drawback is that you are forced to also include a "Goto Tag Visibility" block at the top subsystem where the signal is going to be used.