UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
3,234 Views
Registered: ‎04-22-2015

Access array out of bounds

Jump to solution

 

Is it allowed in Vivado HLS to access arrays out of bounds? I understand it is not safe to do this in software, since all arrays share the same physical memory. However, in hardware we normally have separate RAM memory for each array, which gives me a hope that I can do this.

 

What I mean:

int i = 100; // array index (any number large that array size).

float a[3] = {1,2,3};

a[i] = 5; // will this line change the array?

 

I need this to pipeline the loops efficiently.

0 Kudos
1 Solution

Accepted Solutions
Scholar u4223374
Scholar
5,664 Views
Registered: ‎04-26-2015

Re: Access array out of bounds

Jump to solution

This is an extremely bad idea in every possible way. There are two situations:

 

(1) HLS fails to catch it and you end up with undefined behaviour - possibly depending on the HLS version, changes elsewhere in the code, and the target architecture. The block may run fine in certain situations but completely lock-up (to the extent that a full FPGA reconfiguration is required to get it working again) in others.

 

(2) HLS does catch it and you get a synthesis failure. This is the best-case option.

 

 

Quite apart from that, it renders C simulation impossible - you're just asking for segfaults and random incorrect results.

 

 

What behaviour would you expect? I'd imagine that (assuming "a" is not partitioned) HLS would implement it using a 2-bit address. 100 would therefore wrap around to value 0, and you'd be writing to the first array element. Or HLS might decide that the smallest LUTRAM it can create is 16 elements (depending on architecture) and use a 4-bit address, which would result in this assignment writing to a[4].

 

If you want the first situation, that's easy:

float a[4] = {1,2,3};
a[ap_uint<2>(i)] = 5; // will this line change the array?

Now "a" always has four elements, and you've restricted the address to those four. The second situation is similar. Or you might want to just prevent writes that are out of bounds, which is similarly easy with a simple "if" statement:

 

if (i < 3) {
    a[i] = 5;
}
0 Kudos
1 Reply
Scholar u4223374
Scholar
5,665 Views
Registered: ‎04-26-2015

Re: Access array out of bounds

Jump to solution

This is an extremely bad idea in every possible way. There are two situations:

 

(1) HLS fails to catch it and you end up with undefined behaviour - possibly depending on the HLS version, changes elsewhere in the code, and the target architecture. The block may run fine in certain situations but completely lock-up (to the extent that a full FPGA reconfiguration is required to get it working again) in others.

 

(2) HLS does catch it and you get a synthesis failure. This is the best-case option.

 

 

Quite apart from that, it renders C simulation impossible - you're just asking for segfaults and random incorrect results.

 

 

What behaviour would you expect? I'd imagine that (assuming "a" is not partitioned) HLS would implement it using a 2-bit address. 100 would therefore wrap around to value 0, and you'd be writing to the first array element. Or HLS might decide that the smallest LUTRAM it can create is 16 elements (depending on architecture) and use a 4-bit address, which would result in this assignment writing to a[4].

 

If you want the first situation, that's easy:

float a[4] = {1,2,3};
a[ap_uint<2>(i)] = 5; // will this line change the array?

Now "a" always has four elements, and you've restricted the address to those four. The second situation is similar. Or you might want to just prevent writes that are out of bounds, which is similarly easy with a simple "if" statement:

 

if (i < 3) {
    a[i] = 5;
}
0 Kudos