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:
Explorer
816 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
692 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
Teacher
785 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
758 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
743 Views
Registered: ‎05-23-2017

## Re: hls::stream using problem

Sorry for make the code unclear.

Teacher
731 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
693 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.

Teacher
687 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

Teacher
640 Views
Registered: ‎10-23-2018