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: 
Visitor mohdumar
Visitor
1,183 Views
Registered: ‎10-02-2017

Coding style suggestion

Consider a function

 

 

void hw_func(hls::stream<TYPE1> &inStream, hls::stream<int_32_side_channel__> &outStream, volatile fixed_point* mem_addr)
{
#pragma HLS INTERFACE m_axi depth=1500000 port=mem_addr offset=slave
#pragma HLS INTERFACE s_axilite port=mem_addr
#pragma HLS INTERFACE axis port=inStream
#pragma HLS INTERFACE axis port=outStream
#pragma HLS INTERFACE s_axilite port=return


#pragma HLS DATAFLOW

// define some internal streams

hls::stream<fixed_point> tmpStream1, tmpStream2, tmpStream3;

 

call_sub_func_1(inStream,tmpStream1,mem);

call_sub_func_2(tmpStream1,tmpStream2);

call_sub_func_3(tmpStream2,tmpStream3,mem);


// ... write tmpStream3 to output stream with side channels ...



}

 

 

I am using the m_axi port twice in a DATAFLOW region. Is this allowed?   Like the streams  must be produced and consumed exactly once.

 

I ran into problems successfully running this function.

 

I have tested some cases:

 

  • Dataflow ON: the simulation/hardware is hanging on using this IP. If each sub_func above has II = Latency, there should be no cases of concurrent access to "mem" port right? But still the simulation hangs.
  • Dataflow OFF: requires stream size to be set. I set maximum stream size for each stream. But simulation again hangs / goes beyond 100%. I have other optimizations turned off as well in this case.

 

Any suggestions for the possible cause of cosim hanging?

 

 

0 Kudos
6 Replies
Visitor mohdumar
Visitor
1,133 Views
Registered: ‎10-02-2017

Re: Coding style suggestion

Update:

 

Removing dataflow removes the cosim hanging problem. My previous test was incorrectly reported.

0 Kudos
Scholar u4223374
Scholar
1,120 Views
Registered: ‎04-26-2015

Re: Coding style suggestion

I'm pretty sure HLS won't be able to figure out dataflow with the system you've got, which explains why it fails.  With Dataflow HLS is trying to run all the functions simultaneously, but it doesn't know how to share an AXI Master between two simultaneously-running functions. As a result, it'll probably refuse to start function_3 until after function_1 has finished - and you'll need one of the streams to include a large buffer.

 

That might still be acceptable; it'll mean that the AXI Master is utilized almost constantly, so you're getting about as much throughput as you can reasonably expect.

Visitor mohdumar
Visitor
1,095 Views
Registered: ‎10-02-2017

Re: Coding style suggestion

Does the "STREAM" directive automatically "break" the dataflow?

0 Kudos
Highlighted
Visitor mohdumar
Visitor
1,079 Views
Registered: ‎10-02-2017

Re: Coding style suggestion

How would I go about inserting a buffer? Would a simple array in between the two functions suffice? I mean an array into which the last stream is read and then a new stream is generated from the array for the next function?

0 Kudos
Scholar u4223374
Scholar
1,049 Views
Registered: ‎04-26-2015

Re: Coding style suggestion

The STREAM directive works fine with dataflow; in fact that's what I'd use in this case.

 

Something like:

 

#pragma HLS STREAM variable=tmpStream2 depth=100

This inserts a 100-element buffer into the tmpStream2 FIFO. If sub_func_1 finishes before those 100 elements are filled, then it releases the AXI Master and sub_func_3 can empty out that buffer, priming allowing for another 100 elements to be read.

Visitor mohdumar
Visitor
1,035 Views
Registered: ‎10-02-2017

Re: Coding style suggestion

this approach didnt work for me, i had to split the dataflow into two sub-functions at the cost of latency

 

there should be a better way

0 Kudos