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
Did you mean:
Highlighted
Explorer
516 Views
Registered: ‎05-23-2017

## hls::stream using problem

In ths top function "a" is the stream channel between function_a(producer)  and function_b(consumer).

I want to pipline these two functions using dataflow pragma.

I wonder which using of the hls::stream is a better way?

Thanks.

```function_a(input,hls::stream<int> a){
a<<input;   };

top(input,b){    hls:stream a;    for(1:100){       #pragma HLS dataflow       function_a(input,a){};
function_b(a,b){};    }
}```

```function_a(input,hls::stream<int> a){
for(1:100){        a<<input;   }
};

function_b(hls::stream<int> a,b){    for(1:100){       int b1<<a.read();       b+=b1;}};
top(inout,b){hls:stream a;#pragma HLS dataflowfunction_a(intput,a){};
function_b(a,b){};
}```

1 Solution

Accepted Solutions
Explorer
392 Views
Registered: ‎05-23-2017

## Re: hls::stream using problem

I implement a design based on this two strategies and find the second one is much better.

Not sure the resason.

7 Replies
Mentor
485 Views
Registered: ‎10-23-2018

## Re: hls::stream using problem

@mathmaxsean

The pseudo code doesn't have quite enough detail (or as expected) to definitively answer...

Assuming function a & b share the same stream (producer & consumer)

If the stream were not shared, the 'first' pattern will allow DATAFLOW to get parallelism in the loop... The second pattern once, if you do a return or if's etc.. will not.

The 'first' pattern might also be smaller as it has less control structures.

Hope that helps

If so, please mark as solution accepted. Kudos also welcomed. :-)

Scholar
458 Views
Registered: ‎04-26-2015

## Re: hls::stream using problem

@mathmaxsean I prefer the second approach, because each function call has some overhead (unless the functions are inlined), so it makes sense to have each function do a lot of work. This pushes the overhead down to being a very small proportion of total time.

However, your two examples are fundamentally different. The first one will send every even-numbered stream element (0, 2, 4, 6, 8, 10, etc) to function_a, and every odd-numbered stream element (1, 3, 5, 7, 9, 11 etc) to function_b. The second will send the first 100 elements to function_a and the second 100 elements to function_b.

Explorer
443 Views
Registered: ‎05-23-2017

## Re: hls::stream using problem

Sorry for make the code unclear.

Mentor
431 Views
Registered: ‎10-23-2018

## Re: hls::stream using problem

@mathmaxsean

Due to the data dependency... The timing will be the same... But the first one will use a couple less LUTS... But, for the most part, as is, these are near equal.

Hope that helps

If so, please mark as solution accepted. Kudos also welcomed. :-)

Explorer
393 Views
Registered: ‎05-23-2017

## Re: hls::stream using problem

I implement a design based on this two strategies and find the second one is much better.

Not sure the resason.

Mentor
387 Views
Registered: ‎10-23-2018

## Re: hls::stream using problem

@mathmaxsean

That's odd... I did too and found the opposite... Maybe I made some different assumptions in filling in the pseudo code. Can you share your code? I am really curious. Thanks

Mentor
340 Views
Registered: ‎10-23-2018