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: 
Contributor
Contributor
1,429 Views
Registered: ‎02-24-2016

HLS Utilization and Performance estimates, v2015.2 vs v20172, why are so different?

Jump to solution

Hi all,

 

We are now migrating our product from 2015.2 to 2017.2. Most of our IPs are made with HLS.

 

We are seeing really weird things happening with the new HLS synthesis results. Without changes in the code, we can see how the timing is not met and/or the resource estimates just blow up with the new version. However, since it is the new version I would expect to see my code better optimized!

 

For example, one of the blocks is performs a cross correlation. It gives the following results for resources for a Zynq:

 

                | BRAM    |   DSP |     FF |    LUT |
total 2015.2    |   4     |    28 |   4435 |   5916 |
total 2017.2    |   4     |    28 |  14230 |   8991 |

 

 As you can see here...the estimation is now ~5 times higherIn this example, timing and latency are pretty much comparables, just one cycle up/down, nothing important.

 

Finally, if I do 'implementation', the resource estimation really changes:

 

                | BRAM    |   DSP |     FF |    LUT | SLICE | SRL |
Impl. 2015.2    |   4     |    28 |   3975 |   2130 |  1301 |   9 |
Impl. 2017.2    |   4     |    28 |   4138 |   2111 |  1233 |   2 |

 

Now everything looks quite OK, right? 

  

-> Why does this happen? Why is the estimation so off in this new Version? Can I trust the estimation?

 

I would really appreciate to here your experience and recommendations regarding this. I am migrating many IPs and the process seems to be much more difficult than expected.

 

Thanks for your time,
Garbí

 

0 Kudos
1 Solution

Accepted Solutions
Contributor
Contributor
2,012 Views
Registered: ‎03-13-2017

Re: HLS Utilization and Performance estimates, v2015.2 vs v20172, why are so different?

Jump to solution

Hi,

this is also my experience: I had a prj based on 2016.1 version. When I tried to synthesize it in a more recent version of vivado tooling, I got worst HLS synthesis results versus the resources required. Instead, post-implementation resources usage became - more or less - the same in both versions.

About the timing closure, the more recent version had better performances, around 20% reduction of clock period after the implementation phase.
There has been a very interesting post in the recent past. Please have a look at
    HLS 2016.2 generates much higher resource consumption than 2015.3 version

 

Fabio

0 Kudos
5 Replies
Voyager
Voyager
1,420 Views
Registered: ‎06-24-2013

Re: HLS Utilization and Performance estimates, v2015.2 vs v20172, why are so different?

Jump to solution

Hey Garbí,

 

Note that I'm just hand-waving here as Vivado is closed source and I don't know much about the internals.

My guess here is that the newer version has more generic blocks which will use more resources before optimization to achieve the same as the early HLS versions. Once optimization kicks in, the generic blocks can achieve the same or often better results than the older versions.

 

Can I trust the estimation?

An estimation is just an estimation, as you can see, it is already way off in 2015.2 (more than a factor of 2 for the LUTs) and as long as it is the same 'ball park' it should be fine. That said, it would be nice to have ranges and/or uncertainties in the estimation results.

 

Hope this helps,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Contributor
Contributor
1,399 Views
Registered: ‎02-24-2016

Re: HLS Utilization and Performance estimates, v2015.2 vs v20172, why are so different?

Jump to solution
Hi Herbert,

Thanks for your (really quick!) reply. I think you give a fair hypothesis of why these estimations seem to get worse and worse with the time. However, it is kind of a shame that the estimation is sooo different from reality. i can accept the old estimation...but the new one is really off.

Let's see if someone else has other theories hehe ;-).

Many thanks!
Garbí
0 Kudos
Contributor
Contributor
2,013 Views
Registered: ‎03-13-2017

Re: HLS Utilization and Performance estimates, v2015.2 vs v20172, why are so different?

Jump to solution

Hi,

this is also my experience: I had a prj based on 2016.1 version. When I tried to synthesize it in a more recent version of vivado tooling, I got worst HLS synthesis results versus the resources required. Instead, post-implementation resources usage became - more or less - the same in both versions.

About the timing closure, the more recent version had better performances, around 20% reduction of clock period after the implementation phase.
There has been a very interesting post in the recent past. Please have a look at
    HLS 2016.2 generates much higher resource consumption than 2015.3 version

 

Fabio

0 Kudos
Contributor
Contributor
1,378 Views
Registered: ‎02-24-2016

Re: HLS Utilization and Performance estimates, v2015.2 vs v20172, why are so different?

Jump to solution
Wow,

Thanks Fabio. Indeed, that post includes a very interesting discussion. It is kind of what I have already experienced with the tool, being in my case (due to the big gap between 2015.2 and 2017.2) really dramatic raise of resources.

It looks like also in the other post nobody from Xilinx gave any arguments to explain such a change in the estimations. I would like to know why that is happening. If it is just an error in the estimations, this seems to scare people away of using the new versions! Bad business I believe ;-).

Thanks for your reply,
Garbí
0 Kudos
Contributor
Contributor
1,272 Views
Registered: ‎02-24-2016

Re: HLS Utilization and Performance estimates, v2015.2 vs v20172, why are so different?

Jump to solution

So, 

 

I will accept Fabio's reply because it points to another post with additional information in same topic.

However, I am still not happy with the conclusion since no employee from Xilinx has given any justification at all. 

 

Thanks for your replies,

Garbí

0 Kudos