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: 
Observer alexkroh
Observer
362 Views
Registered: ‎04-25-2015

HLS CHStone jpeg bug

I am trying to use Vivado HLS 18.3 to synthesize the jpeg program in the CHStone suite v1.11. I think I am hitting an HLS bug and would like to report it and hopefully find a workaround until it is fixed.

Here is the top function and my directives:

void
jpeg_read (unsigned char *read_buf)
{
#pragma HLS INTERFACE m_axi depth=32 latency=12 port=read_buf offset=slave
#pragma HLS INTERFACE s_axilite port=return

The problem is that read_buf is not being read correctly over m_axi.

In the generated jpeg_read.vhd file, I noticed that I_ARADDR is assigned a constant 0x00000000 instead of a dynamic offset to read_buf.
If I comment out the body of pgetc(), which accesses read_buf via an alias, I_ARADDR seems correct.

I think the problem is in the pointer aliasing that this program uses:
read_markers() uses its own global bump pointer when reading the JPEG header from read_buf. When the address of the JPEG data is found, it assigns another global to point to that address.
decode_start() uses the pointer that read_markers() assigned and copies that to its own bump pointer. pgetc() is the abstraction for that bump pointer, hence commenting out the body of that function prevents read access to the pointer.

Any assistance would be very appreciated.

Thanks,

  - Alex

0 Kudos
1 Reply
Observer alexkroh
Observer
278 Views
Registered: ‎04-25-2015

Re: HLS CHStone jpeg bug

The root of the problem might be the way that Vivado HLS inlines the code to avoid pointer-to-pointers.


The top function has two main parts:

read_markers:
  From the log, this function AND its children are being inlined

decode_start:
  From the log, only decode_start is being inlined. If there is a legitimate reason why children are not inlined too, it is not being reported.


I performed a binary search on the code until I found a small section that would assign I_ARADDR to a sane (correct?) value when it is commented out. After manually inlining this code, I_ARADDR is assigned a sane value instead of being hardwired to 0.
I tried using #pragma HLS inline on the original function and reverted the code back to calling that function, but I_ARADDR was again hardwired to 0. There is too much work involved in manually inlining every function so I have to give up on using Vivado HLS for this HLS benchmarking program.

0 Kudos