11-06-2019 05:21 AM - edited 11-06-2019 05:51 AM
I am seeing a weird behavior with the gateway in block.
Below is an example,
I have a constant block with value 8589934591 which is a 33 bit max value.
My gateway in have the same fixed point settings as the input,
When I run the simulation, I see an overflow error. Why? It requires exactly 33 bits!
Am I missing anything obvious.
Also I do not see this behavior for values which require 32 bits or less!
Any input is appreciated!
11-06-2019 05:48 AM
Well, it includes both matlab constant block and also the xilinx dsp Gateway In. I don't know yet which of these is the reason for this behavior!
11-06-2019 06:56 AM
11-12-2019 06:01 AM
We have reproduced the issue at our end. Currently, we are checking the source of error.
11-12-2019 10:12 PM - edited 11-12-2019 10:15 PM
3. Issue: Now the values are converted from ufix to double in sysgen before sending to gateway in. And due to above conflict in the values, SysGen throws the simulation error due to 'flag as error' option. The difference in above figure is causing the overflow
Workaroud: Set the output data type to ‘double’and enter the input value as 8589934591 or 2^33-1 (not as 2^33).
11-13-2019 09:48 AM
2^33 (8589934592) value requires 34 bits to represent it. That is the reason why it is saturtating it to the maximum number that can be represented by 33 bits which is 8589934591 (as seen from your screenshots) and this is the expected behavior.
My problem is different,
I give 8589934591 as UFix33 (which is representable as proved in the above screenshot) to gateway In with 33 bits and gateway says it is an overflow. !!!
When given as double, of course it works but I want to know why it does not work for UFix constants. My input signal needs to be in UFix format for specific reasons.
There are multiple (specific) workarounds which we did for our design,
However no.3 may not work for other designs.
But I am only curious why exactly Simulink UFix33 Constant does not go with Xilinx UFix_33_0 gateway In!
11-13-2019 10:24 AM
Actually, it is not saturating to max value. If you try '8589934593' for ufix33, then overflow error will be shown by Matlab as well; whereas the '8589934592' is converted to '8589934591'.
During the conversion 'from fixed to double' by SysGen, the conversion of (2^33) 8589934591 value from “ufix33” into “double”, makes the value 8589934592 due to the floating-point conversion (precision) issue. This is the reason for overflow (i.e. overflow in simulation). In the other words, ufix33 has max value 8589934591, but during conversion it will appear as 8589934592 to gateway in port, therefore sysgen is throwning error on it.
The 'wrap' option doesn't care about the simulation overflow, but you may see warnings if MATLAB and SysGen simulation does not match.
11-28-2019 09:14 AM
thank you for your reply.
Okay so if I understood right, you are saying 8589934591 is getting converted into 8589934592 due to some precision issue (fix to double). 8589934592 needs 34 bits and not 33 so there is an overflow.
But in the screenshot you uploaded ufix_33 8589934591 is not converted to 8589934592 and also the same when I tried in my simulink.
Also in matlab when I try to convert fixed to double I do not see this happening.
Additionally, I observed that all the numbers which requires 33 bits i.e from 4294967296 to 8589934591 had an overflow when fed to the 'gateway in' with 33 bit. How do I make sense of this with your explanation?