Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Problems casting from int to uchar in OpenCL kernel

Dear Sirs !

I'm using AOC ver 13.1 (recently updated to ver 14) and Terasic DE5-NET device.

I've spent much time trying to solve some unusual problem in Altera OpenCL kernel.

In kernel I need to calculate some integer values, that are at last 1-byte

long and have leading zeros ('cause they are calculated as a reminder of dividing

values by 256). Afterwards I try to assign them to uchar variables

(array members, or standalone). I've tried both implicit and explicit cast, but

in both cases I face the problem that results of kernel work are not correct.

Here is the example of casting :

int res = doSomeCalc(); // returns int

res = res % 256;

uchar ures = res; // or uchar ures = (uchar) res;

When I run this kernel on GPU, CPU, or in new Altera's x86 emulator (in 14 version of AOC),

in all cases kernel works fine.

But when I run it on FPGA (DE5-NET) it works wrong.

When I change all types in kernel to int to avoid casting, it works on FPGA, too.

But in this case (when I apply needed number of steps in main cycle, much more

compared to test, which passes ok) kernel uses too much

chip resources and does not fit in FPGA.

Maybe I miss some important issues about possibilities of using such casting

in AOC ?

Thanks,

Andy

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Are you getting the error on the FPGA with the 14.0 version of AOC as well? The issue may have already been fixed.

    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?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- 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.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    It is hard to tell if there is a problem with the algorithm or the compiler.

    I recommend that you update to the new 14.1 version, which includes some bug fixes.

    You can also try performing the matrix vector-product using uchar, but storing the final data as int? This may narrow down the problem and may be a work-around solution.

    If these do not work, you can open a service request and share your code; then the Altera team can find the root cause of the problem.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Thank You for your replies !

    --- Quote Start ---

    It is hard to tell if there is a problem with the algorithm or the compiler.

    I recommend that you update to the new 14.1 version, which includes some bug fixes.

    You can also try performing the matrix vector-product using uchar, but storing the final data as int? This may narrow down the problem and may be a work-around solution.

    If these do not work, you can open a service request and share your code; then the Altera team can find the root cause of the problem.

    --- Quote End ---

    Yes, I'll try 14.1

    As for matrix-vector product, it is done according to your recipe - using uchar, but storing in int (in short int in fact).

    How can I open a service request ?

    Thanks !