UpsampleNearestNeighbour bug when Padding=scale_factor

[hleblevec]

Hello,

I've been working on a support of rectangular inputs for the UpsampleNearestNeighbour recently, and while doing some tests I encountered an issue that also exists in the original square implementation.
Basically, if you have a scale factor that is equal to the padding, you will encounter a read while empty error (for example if IFMDim = 3 and OFMDim = 8, you have a scale factor of 2 and also a padding of 2).
The error message is the following:
ERROR [HLS SIM]: an hls::stream is read while empty, which may result in RTL simulation hanging. If this is not expected, execute C simulation in debug mode in the GUI and examine the source code location of the blocked hls::stream::read() call to debug. If this is expected, add -DALLOW_EMPTY_HLS_STREAM_READS to -cflags to turn this error into a warning and allow empty hls::stream reads to return the default value for the data type.

I found that it comes from the way the count_row variable is used (c.f.

finn-hlslib/upsample.hpp

Lines 114 to 116 in 80bc6f0

	count_row++;
	if (count_row > scale_factor)
	count_row =1;

). If you're in the situation where scale_factor == Padding (which translates in OFMDim/IFMDim==OFMDim%IFMDim), count_row will reach a value equal to scale_factor one time too much, which will issue a read on an already empty buffer.

They are several ways to solve this bug in terms of C++ code, but I am unsure which one would make the most sense with HLS synthesis in mind. What do you think?