overflow detected due to mux signal

2 views (last 30 days)
vivek patel
vivek patel on 25 Aug 2022
Answered: Andy Bartlett on 25 Aug 2022
Hi,
When i have a pattern like below, where i am working on the vectors and the "wrap on overflow" configuration is set to error then i am getting an overflow error in the model. If i remove the vector and just keep one dimension then there is no overflow error detected.
I am not sure why it works like this ? If the switch condition is met then the F condition should not be executed. The same will happen in the code when generated that there would be if else statement and the operation will not happen ?

Answers (2)

Andy Bartlett
Andy Bartlett on 25 Aug 2022
Hi,
The branches leading to the inputs of the switch block will normally all get evaluated in simulation even though the result of an input may not be used by the switch output or any where else. In other words, you should not expect a system level optimization to realize Add and Divides output are not used later and avoid their computation. If you use Embedded Coder or HDL Coder to generate C or HDL code for this design, then the generated code will do a deep analysis and seek to avoid "useless" computation when it can.
If you want both simulation and code generation to always just compute the branch that is used, then look at using the triggered subsystem and merge block modeling pattern. Put each branch in their own triggered subsystem and feed both outputs to a merge block. Because the trigger signal (i.e. relop output is a vector). You may need to put the whole thing inside a for each subsystem to fully avoid needless evaluations of branches for each index.
  1 Comment
vivek patel
vivek patel on 25 Aug 2022
Thank you for the detailed explanation. But my question would be then why overflow is not detected when i remove the mux block and keep just one dimension signal ? Does that mean in simulink also there would be optimization done then to not calculate all the branches ?

Sign in to comment.


Andy Bartlett
Andy Bartlett on 25 Aug 2022
To understand why overflow is not reported for the scalar case you described, my suggestion is to
  1. Turn on show port data type
  2. Use Simulink Display Values feature (or put a Display blocks on all related signals)
  3. Use Simulink Stepper to debug the model
While single stepping through the model look at the values going in and out of each block, especially Add.
Your vector model implies that you should see values 255 and 7 going into Add. The ideal output should be 262.
If the output of the Add is a type with a small maximum representable value like int8 or uint8, then an overflow is definitely expected. Let's say it's uint8 output, so for saturation 262 would overflow to 255. For wrapping, 262 would oveflow to 7.
Use the debugger and the displays to make sure everything is really what you expect. Are the input values as expected?
Is the output data type displayed the same as what's inspected? Is the output value as expected?
Before single stepping, I also suggest you change both the signal wrapping and saturating oveflow diagnostics to warning instead of error. That allows you to keep poking around without simulation aborting.

Products

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!