--- Quote Start ---
Are you getting the error on the FPGA with the 14.0 version of AOC as well? The issue may have already been fixed.
--- Quote End ---
Yes, I've tried both versions and now I'm using 14.0
--- Quote Start ---
Otherwise, I do not see anything unusual in your code. Any legal OpenCL code is expected to work. Perhaps the casting may be exposing a different issue in your code or in the compiler. Will you be able to describe how you are using the ures? or perhaps opening a service request and send your code?
--- Quote End ---
The thing is that I do not see anything unusual in this code, too...
The sctructure of the code is as follows :
In kernel function there is private array M of uchar values.
It's elements are calculated in for cycle using relatively complex expressions of integers, resulting in values, less or greater than 256.
To assign each component of M "% 256" operation and ures are used (code above is taken from another function, called from kernel).
Afterwards M array is used in matrix-vector product to form i+1 vector from i-th.
n-th vector is written to output global array. 0-th vector is taken from input global array.
(In this case it is the same inout buffer.)
As far as I understand observing debug info from kernel (extra global array), M array is calculated correctly
(I mean it contains correct byte values), but such calculations may lead to wrong values written in output buffer
or into i-th vectors. I think so, because when casting from int to uchar does not takes place and M is an array of integers,
kernel seems to work right.
In this case (when we use int everywhere, or even short int) it leads to increasing of resource consumption.
In fact, we do not need to store all 32 bits for all elements of vectors / M array at each cycle, 'cause only 8 bits of them
contain data at the begininng and at the end of cycle, as well as when matrix-vector product is perfomed,
though while calculating this 8 bits we use more wide numbers.
Honored Contributor
