cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
wave_rider
Visitor
Visitor
942 Views
Registered: ‎03-10-2021

Why Xilinx is making HLS worse?

Hi Xilinx Team,

I don't really get why Xilinx is trying so hard to make HLS worse, by implying things like new restriction in Vitis_HLS. For instance, the maximum port size of Vitis HLS is now 4096 vs 32k of Vivado HLS. We understand not everyone need port size that large but I am quite sure there are people like myself having design with more than 4096bit IO.

Why would Xilinx try to upset happy Vivado HLS user by making HLS worse in Vitis? Am I suppose to stick with Vivado HLS and expected that I would not update my design to new device?

Example like this happens everywhere, like the "data_pack" pragma is no longer supported and the new aggregated pragma does not work on interface.

I just didn't quite get it why Vitis is worse comparing with Vivado HLS. Or should I try to write my own compiler when Xilinx officially released the source code of the llvm front end? When the Vitis team is trying so hard to piss existing user off...

 

9 Replies
aoifem
Moderator
Moderator
800 Views
Registered: ‎11-21-2018

Hi @wave_rider 

Thanks for the feedback. Some of the new limitations were brought in to make the tools more efficient for synthesizing RTL. Unfortunately there was a trade-off here in some situations.

The 4096 limit can be worked-around by using two ports of size 4096 bits.

The data_pack pragma has been replaced with the __attribute__(packed(X)) instead, as explained in the Vitis HLS User Guide

That being said, the team are open to feedback, and are open to adapting the tool as users want it, as long as enough demand is there. 

Aoife
Product Application Engineer - Xilinx Technical Support EMEA


**~ Got a minute? Answer our Vitis HLS survey here! ~**

**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
wave_rider
Visitor
Visitor
795 Views
Registered: ‎03-10-2021

It is kind of funny when I see reply like this.....

No offence but...

1. we had a working solution for port size > 4096, and now we have to settle for "work around"? I don't see the logic here...

2. Do you even know what is the difference of attribute packed and the vivado HLS packed pragram. One is byte aligned packing and the other one is bit level packing. You cannot do the same with attribute packed.....

And yes I did fill in the survey but does it even matter?

u4223374
Advisor
Advisor
758 Views
Registered: ‎04-26-2015

@wave_rider I may be wrong, but I think the "AGGREGATE" pragma does the same as what DATAPACK used to do?

 

With that said - it would be a mistake to assume that just because a tool is newer, it must be better. I'm pretty sure even Xilinx official advice is to pick a version that you like and stick with it. Vivado 2016.2 does nicely for me, and it's a tiny fraction of the size of newer tools/versions.

0 Kudos
wave_rider
Visitor
Visitor
747 Views
Registered: ‎03-10-2021

Pragma aggregate does not apply to interface.

and your argument about picking up old version of tools is wrong.

new device will only be supported by new version. And timing of old device will be changed as well so we cannot avoid new versions.

but then why should I rewrite my code just because Xilinx engineers feel like breaking things?

Breaking changes like this is one of the reason why people does not take HLS seriously in production environment. Because Xilinx does not take it seriously and think random breaking changes are acceptable….

0 Kudos
frederic
Xilinx Employee
Xilinx Employee
591 Views
Registered: ‎04-14-2013

@wave_rider: the 4,096-bit is a hard limit in the newer version of Clang that Vitis HLS uses for C synthesis.  It's an issue that's called out in the migration guide UG1391.

If you are looking to create long concatenated words out of individuals variables, take a look at the new vector capabilities (see user guide and search for hls_vector.h)

 

As far as data_pack goes, Vitis HLS adopts a new approach that "packs" by default to better support host/kernel top port variable associations.

Through the new Clang, the tool supports the GCC struct packing attributes and for custom packing you can use the aggregate pragma.

For example to "beat" the new byte minimum otherwise compatible with software, you can use aggregate and bit to pack to the max:

#pragma HLS AGGREGATE variable=result bit

(packs the struct "result" at the bit granularity)

 

maps-mpls
Mentor
Mentor
573 Views
Registered: ‎06-20-2017

>Why would Xilinx try to upset happy Vivado HLS user by making HLS worse in Vitis?

 

Only slightly off topic, and I'm not agreeing or disagreeing with you, but I was just talking about this in the context of Microsoft tools as well.  Visio was a much better product before Microsoft bought it and and wrecked it.  Outlook and email in general was much better when it was ASCII.  Just when you get used to a word interface, they change it.

As far as I can tell, the evidence is that CEOs of high tech corporations get together running around in the woods naked doing mock human sacrifices and conspire over 50 year old scotch and cigars on ways to make the U.S. less productive.  This is of course a ludicrous theory but it is not without evidence--at least on the productivity side.  

Anybody that wants to take the plunge into new tools is going to have to, for example, learn a lot about Linux administration--much more than they wanted too--unless they already have that skill set or work on a team with somebody else who sets up machines.   

*** Destination: Rapid design and development cycles *** Unappreciated answers get deleted, unappreciative OPs get put on ignored list ***
wave_rider
Visitor
Visitor
566 Views
Registered: ‎03-10-2021

The old visio is one of the best tools I ever used, I am quite sure that most people use it the way just like me, which is open the "basic flow chart" and start drawing whatever I needed.

I am not upset with new features. On the other hand as a intensive user I very much appreciate new features. I am upset that Xilinx does not take it seriously. Let me give you an example.

If you were the designer of the C++ language and you think that creating a new stl container call vector<> is good. Will you kill off normal native array in the language? No. That will break all the old code. And no one would consider C++ as a production ready robust language.

Now what Xilinx is doing is just like killing normal native array when they have a new container class vector. Yes it might be better, but it is not respectful to existing user. And IMHO it looks like that HLS is just an experiment or a TOY for them and anyone who jump on this boat are expected to get that kind of treatment.

 

Another example is in my another post

https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/Inaccurate-resource-usage-estimation-in-C-synthesis/td-p/1233983

 

I pointed out that the HLS C syn is not accurate in terms of resource usage estimation and latency. The only reply I got is

"Yes it is like that please go ahead and run a place an route"....

 

Come on are you even responsible to your own product?

I am quite sure that the Xilinx silicon team would not have that kind of attitude.

"Hey we are not very sure if the new transceiver works or not, but just try to tape it out and cross your finger so that it might work"

no that will not happened.

Then why that kind of attitude exist in the HLS team?

0 Kudos
maps-mpls
Mentor
Mentor
542 Views
Registered: ‎06-20-2017

Good points, and I have a feeling I am about to run into the same frustrations you have (as I am about to start using HLS again on a new project). 

On Visio, its the grotesque pastel colors for the default shapes that I hate most.  For block diagrams, I like black (0,0,0), red (255,0,0), and blue(0,0,255).   Every time I start a new diagram I have to drag a shape to the diagram, and reset its color.  And I haven't figured out a way to just make all of the shapes black by default. 

Regarding C++, before that there was C, and before that there was C that was not standardized, and before that B.  But in the case of C, we had two benevolent dictators who valued simplicity and symmetry in syntax.  HLS may someday either standardize, merge and standardize, or evolve into ILS (I after H).  Then the IEEE will have political votes on technical matters and things will either get better or worse.

For heterogeneous compilers that can target heterogeneous processors and/or fabric and other PL resources, we're talking super specialized Ph.D. level problems, in a world where fewer Ph.D.s in computer engineering are being funded, being developed by specialists who don't always have the big picture or historical knowledge necessary, and as they gain experience realize better ways to do things, or are forced to make necessary changes based on new direction, etc.  Frankly, I expect the situation will continue for some time, though your point about not breaking existing code that compiles is something that should be put high on a priority list.  I guess its hard to say "no" when you have product managers and other executives pushing hard on release dates, especially if you just got hired to work at Xilinx after completing a Ph.D.

So, to summarize:  I support making a high priority goal to not introduce features that require previously working code to be re-written.  On the other hand, this is some bleeding edge stuff, and a lot has been bitten off as far as goals while covid-19 has been having an impact on many aspects of our lives.

 

 

*** Destination: Rapid design and development cycles *** Unappreciated answers get deleted, unappreciative OPs get put on ignored list ***
0 Kudos
doonny
Explorer
Explorer
381 Views
Registered: ‎07-28-2013

Hi @aoifem , In Vitis HLS, non-blocking access of streaming interface can not be compiled by v++, however, in the user guide, it was said still supported.

Refer to this issue https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/How-to-use-non-blocking-with-stream-interfaces/m-p/1238222#M24302

 

Please feed back this issue to the design team.