Array dependence pragmas - achieving II=1.

Question

Hello everyone,
I'm after some help with Vivado HLS loop dependencies. I've got a function that's building low-resolution histograms of images. The pseudocode looks like this:
// Image is uint8, but actually the range is guaranteed to be 0 - 191.
void createHistogram(uint8 image[640*480]) {
static int histogram[12];
#pragma HLS ARRAY_PARTITION variable=histogram complete dim=1
for (int i = 0; i < 640*480; i++) {
uint8 value = image[i];
int histogramMainBin = value/16;
int remainder = value - histogramMainBin*16;
int histogramSecondaryBin;
if (remainder >= 6) {
if (histogramMainBin < 11) {
histogramSecondaryBin = histogramMainBin + 1;
} else {
histogramSecondaryBin = 0;
} else {
if (histogramSecondaryBin > 0) {
histogramSecondaryBin = histogramMainBin-1;
} else {
histogramSecondaryBin = 11;
assert(histogramMainBin != histogramSecondaryBin);
int addMain = value * 3 / 4; // Smooth it out between the bins. The bin that this value falls into gets 3/4 of the value, and the next closest gets 1/4.
int addSecondary = value - addMain;
histogram[histogramMainBin] += addMain;
histogram[histogramSecondaryBin] += addSecondary;
// Do something with the histogram.
(it's just pseudocode; in the real thing is quite a lot more complex and also an enourmous mess because of the things I've been testing to make this work).
The HLS tool says:
@W [SCHED-68] Unable to enforce a carried dependency constraint (II = 1, distance = 1)
between 'store' operation (test_cpp/testcode.cpp:620) of variable 'tmp_45' on static variable 'histogram_V_0' and 'load' operation ('histogram_V_0_load_1') on static variable 'histogram_V_0'.
I'm currently getting II=2 because of this loop dependency on 'histogram'. I'd like to get II=1. In the past I've had this problem because the histogram has been in block RAM, and the FPGA can't manage a one-cycle read-modify-write update on that. However, in this case I've got the histogram fully partitioned to individual registers, and you can definitely do a single-cycle register update.
The problem appears to be that HLS is not recognising that histogramMainBin and histogramSecondaryBin cannot ever be equal. This leaves the possibility that in one loop iteration it'll have to read a histogram location, add a value, write to the same location (for the histogramMainBin update), read the same location (for histogramSecondaryBin), add a value, and write to the same location. Since each update is one cycle, it's allocating two cycles for the updates (that's what I'm seeing in the performance analysis output). If I remove the histogramSecondaryBin update (so it only writes to one location on each cycle) then it works fine at II=1. I've tried putting in a pragma to tell it that the same location never gets accessed twice in one iteration ("#pragma HLS DEPENDENCE variable=changes0 intra false") but that hasn't helped.
The only other option I can think of is a giant switch statement:
switch (histogramMainBin) {
case 0: histogram[0] += addMain;
if (remainder >= 6) {
histogram[1] += addSecondary;
} else {
histogram[11] += addSecondary;
break;
case 1: histogram[1] += addMain;
if (remainder >= 6) {
histogram[2] += addSecondary;
} else {
histogram[0] += addSecondary;
break;
That works fine (synthesis at II=1 with no dependence pragmas needed), but it's a horribly messy approach and makes the code much harder to modify (eg. if I decided I actually want 24 histogram bins, I have to rewrite the whole thing with twice as much code, whereas with the original approach it's just a matter of changing a few values).
It seems likely that there's a pragma somewhere that I've missed, but I can't find anything suitable in ug902.
Any ideas would be much appreciated.
Thanks

Answer 1

If anyone's interested, I've found a workaround:
void updateHistogram(int histogram[12], int addMain, int addSecondary, int histogramMainBin, int secondaryBinSelect) {
#pragma HLS FUNCTION_INSTANTIATE variable=histMainBin
histogram[histogramMainBin] += addMain;
if (secondaryBinSelect) {
if (histogramMainBin >= 11) {
histogram[0] += addSecondary;
} else {
histogram[histMainBin+1] += addSecondary;
} else {
if (histogramMainBin == 0) {
histogram[11] += addSecondary;
} else {
histogram[histMainBin-1] += addSecondary;
Moving the histogram update to a separate function means that I can use the FUNCTION_INSTANTIATE pragma and force HLS to evaluate what the function does for each value of histogramMainBin. Presumably once it does this, it realises that actually it's never going to hit the same bin twice in one cycle, so it schedules with II=1. This approach is slightly more expensive than the huge switch statement (probably because it's also building hardware just in case histogramMainBin is greater than 11) but it results in much nicer code.