4 replies to this topic

[Jason Dickens]

The case discovered is as follows:

c = (a+ % 255;
x = A[c];

works, but:

x=A [ (a+%255];

gives an incorrect answer. In my particular case, all variables are "unsigned char", and I haven't tested to know if the type matters.

I don't want to get into why I can't simply change the code, suffice it to say that its begin generated by an automatic tool.
Other expressions in the array index have worked.

Has anyone discovered this, is there a fix?

I'm using version 3.60

[etrexel]

The case discovered is as follows:

c = (a+ % 255;
x = A[c];

works, but:

x=A [ (a+ %255];

gives an incorrect answer. In my particular case, all variables are "unsigned char", and I haven't tested to know if the type matters.

I don't want to get into why I can't simply change the code, suffice it to say that its begin generated by an automatic tool.
Other expressions in the array index have worked.

Has anyone discovered this, is there a fix?

I'm using version 3.60

Hi Jason,
There may be a timing issue due to the modulus being an asynchronous call to a multi-cycle module. Looking at your code by itself and resulting HDL, it is not obvious whether the error being caused is inherent to the logic itself. There may be other parts of the surrounding code to consider, such as whether the stage also contains an I/O operation such as a co_stream_read/write(). If this may be the case, placing a co_par_break(); after x=A[(a+%255]; statement may effectively isolate it to avoid the issue. If this doesn't help, please post (or send it to support@impulsec.com) more of your code for review.

Another suggestion more from the point of view of optimization for speed: Multiplication will be faster than division (or modulus) and multiplying by a reciprical may yield the same results in fewer cycles.

Best Regards,
Ed

[Jason Dickens]

Since the first post I've done a lot of experimentation, but have gained little knowledge.

I definitely believe its a timing problem, and related to the modulus operator. In any case, I tried putting co_par_break() both before and after this piece of code with no improvement, I honestly thought that was good idea and was going to solve my problem. It turns out simpler things exhibit the same behavior. You need only x=A[ i % 255];

I've also learned that there is more to it than just the modulus. My function reads three integers from a stream I'll call sel, p1 & p2.

I use a switch based on sel to decide which operation to perform. The following two would seemingly be equivalent:

case 1:
x=A[p1%255];
break;
case 2:
x=A[p2%255];
break;

However, the case 2 exhibits a lag and only gets the correct answer on the second call with the same parameters. (of course if you drop the %255 part it works fine.) The situation is complicated by the fact that I also use p1 in a different case to fill the array.

As I mentioned before I can't really rewrite the code itself, as least not on a case by case basis. So while I understand the comment about multiplication, its really not an option for me.

Thanks,

Jason

[etrexel]

Hi,
Just a quick note that I'm going back and forth with the developer regarding this issue and will post when there is a workaround or fix available.

Best Regards,
Ed

[etrexel]

Hi,
We're having difficulty reproducing the error and would need code from you (post here or send to support@impulsec.com) exhibiting the error. Running the code below through HDL simulation is producing expected results.

CODE

unsigned char A[256], x;
unsigned int a, b;
for(cc=0;cc<256;cc++) {
A[cc] = cc;
}

while(1) {
x = A[(a+b )%255];
a += 256;
co_stream_write(output_stream,&x,sizeof(x));
}

Best Regards,
Ed