Xilinx Announces Vitis

[Sal Ammoniac]

https://www.xilinx.com/news/press/2019/xilinx-announces-vitis--a-unified-software-platform-unlocking-a-new-design-experience-for-all-developers.html

[jaromir]

I was waiting a few days for any resposnes to this, but none appeared, so it looks I have to ask: Is this complete development suite or just appendix to existing ones? What is the purpose of this? Any advantages or disadvantages over old ISE and newer Vivado?

Honestly speaking, I have hard time distilling this or other relevant information from heaps of marketing speak and buzzwords.

[mark03]

I believe the point is an extension of the existing Vivado HLS (high-level synthesis) stuff:  To suck more software engineers, data scientists, and algorithm designers into FPGA-land, people who may not have any background or interest in hardware design.  Xilinx sees this as a major driver of their future growth, primarily because it broadens their user base, but also maybe because it will drive sales of ever-larger FPGAs to accommodate the less efficient designs produced by the new tools!

All of this seems to parallel the trajectory of software.  As the dominant stacks become less and less efficient (see: Javascript), they require faster hardware to run effectively.  In both worlds (FPGAs and software), engineers with lower-level knowledge will have an edge, as they can do more with less, but only up to a point.  For example, we could write all software in C or assembly, but time to market, and maintaining a complex codebase with hundreds of contributors, will often dictate a higher-level paradigm.  In ___ years, we may look at hardware design in Verilog/VHDL the way we look at programming a microprocessor in assembly today:  crazy efficient, but who has the time?!

[asmi]

To me is seems more like evolution of SDSoC. And I'm not interested in it for the same reason - it's bound to devboards, while I prefer building custom boards for my projects.

[dferyance]

As the dominant stacks become less and less efficient (see: Javascript), they require faster hardware to run effectively.  In both worlds (FPGAs and software), engineers with lower-level knowledge will have an edge, as they can do more with less, but only up to a point.

That is an interesting perspective but I really don't see developers shifting to FPGAs outside of specialized fields. There are companies and fields that do care about code performance. But the vast majority of developers want to code in a high-level language, glue up some microservices, and let performance be someone else's problem (e.g. AWS lambda node.js).

The software trend has been to avoid having to care about how computers work. We transitioned from assembly to highlevel languages to not care how the CPU worked. Then we transitioned to operating systems to not have to care how the rest of the computer worked. Then we transitioned to runtime platforms on top of the operating system to not care how the operating system worked. Then we transitioned to cloud platforms on top of the runtime platforms to not have to care how the computing cluster worked.

Many of the programmers that I've worked with that have entered the field within the 10 years or so, have never made an API call into the operating system or would know how to do so. It is hard for me to think that software developers will care about digital logic with all the layers we have put in place.

Now back to npm installing and gluing code together....

[SiliconWizard]

I haven't seen any interest factor in this for me so far, but hey.

[chickenHeadKnob]

I was waiting a few days for any resposnes to this, but none appeared, so it looks I have to ask: Is this complete development suite or just appendix to existing ones? What is the purpose of this? Any advantages or disadvantages over old ISE and newer Vivado?

Honestly speaking, I have hard time distilling this or other relevant information from heaps of marketing speak and buzzwords.

My take: there is increased interest in combining fpga's and servers for back-end processing. This is Xilinx's response  to Intel absorbing Altera and threatening to gain advantage in new market area. High frequency trading, GNN and other types of neural networks, specialized  Map/Reduce ect 

[Bassman59]

To me is seems more like evolution of SDSoC. And I'm not interested in it for the same reason - it's bound to devboards, while I prefer building custom boards for my projects.

I don't think this has anything to do with development boards (which are toys, of course) and everything to do with Xilinx' newish business of selling hardware-acceleration products.

That is, if you have a particular problem which might benefit from hardware acceleration, you buy a PCIe (or whatever follow-on bus) board that runs your algorithms which are called from your higher-level software running on your server or workstation.

The end user of these boards won't care what FPGAs or SoCs are on them. They only want their data crunched.

So to that end, the new development software abstracts the hardware, and it has to be separate from Vivado because it's not an FPGA development tool as we know them.

[Someone]

The software trend has been to avoid having to care about how computers work. We transitioned from assembly to highlevel languages to not care how the CPU worked. Then we transitioned to operating systems to not have to care how the rest of the computer worked. Then we transitioned to runtime platforms on top of the operating system to not care how the operating system worked. Then we transitioned to cloud platforms on top of the runtime platforms to not have to care how the computing cluster worked.

Many of the programmers that I've worked with that have entered the field within the 10 years or so, have never made an API call into the operating system or would know how to do so. It is hard for me to think that software developers will care about digital logic with all the layers we have put in place.

Different level of programming. An FPGA rarely runs UI, it is usually handling 2 things: interconnecting/interfacing hardware, and compute or memory bandwidth intensive workloads. So the parallel in the software world is writing drivers or high performance computing, worlds apart from platform agnostic high level code.

What languages and software frameworks do people writing drivers use? Or producing code to run on supercomputers?

[OwO]

I don't really give a shit about this or HLS in general. As long as I can keep getting decent FPGA hardware at a decent price.

[dferyance]

What languages and software frameworks do people writing drivers use? Or producing code to run on supercomputers?

Drivers? I think the web browser, node or python handles that somehow. I'm kidding, I have written device drivers before. Naturally there is still a need for low-level code like this but it has become way more of a specialized area than it used to be.

[agehall]

Or producing code to run on supercomputers?

I believe Fortran is still pretty popular on supercomputers. But C and many other languages are also used.

The reason people gravitate towards "inefficient" languages is probably that while you could write more efficient code in a low-level language, the data structures you get for "free" in high-level languages allows you to easily implement much more efficient algorithms and that is what counts in the end for most software.

<story time>
About 20 years ago, I was taking an AI course at the university. In that course, we had to do a bunch of lab assignments and the framework was written in LISP. There were things like implementing a Sokoban solver or simulating a robotic vacuum cleaner and each lab included a scoring system and your solution was put on a high-score list so you could compare it to everyone else's.

My lab partner and I didn't really care for LISP at the time (I still don't!) so we opted for a slightly different route. In about half of the assignments, we just re-implemented the framework in our favorite high-level language and wrote our solution in that language. In the rest of the assignments, we wrote generators that simply output the LISP code for us and ran within the original framework.

The result? Our solutions outperformed all other solutions by 2-10x the previous high-score, not just that year but since the start of that course. Not because we were much smarter or better than everyone else but because we could spend our efforts on making our algorithms very efficient instead of dealing with what most of our classmates referred to as "parenthesis hell" to do even the simplest of things in terms of data structures...
</story time>

Now, I know LISP isn't C, but the moral of the story still applies when comparing your favorite high-level language to something like C. Sure you can be more efficient in something like C, but the effort to do things like index a 3D hashmap with string indices in C is a lot higher than doing so in Javascript or Python. So unless you are writing a highly streamlined piece of computational software, you are probably better off in a high-level language. And this is the core issue I see with HLS and FPGAs - most people using FPGAs are used to writing very much streamlined computation code because that is one big area where FPGAs shine...

[NorthGuy]

Sure you can be more efficient in something like C, but the effort to do things like index a 3D hashmap with string indices in C is a lot higher than doing so in Javascript or Python. So unless you are writing a highly streamlined piece of computational software, you are probably better off in a high-level language.

High-Level languages are like automatic transmission. It is true that you need less "efforts" to drive automatic, but this is not true that you can driver better or faster. It is also not true that the automatic can do everything which manual could - for example, you cannot push your car if your battery dies. For a person who already knows how to drive shift-stick, there's no difference, and he can drive automatic if need be. But for the person who can only drive automatic, shift-stick looks like something crazy and pre-historic. These people really believe that the automatic transmission helps them concentrate on driving. Imagine that.

[agehall]

Sure you can be more efficient in something like C, but the effort to do things like index a 3D hashmap with string indices in C is a lot higher than doing so in Javascript or Python. So unless you are writing a highly streamlined piece of computational software, you are probably better off in a high-level language.

High-Level languages are like automatic transmission. It is true that you need less "efforts" to drive automatic, but this is not true that you can driver better or faster. It is also not true that the automatic can do everything which manual could - for example, you cannot push your car if your battery dies. For a person who already knows how to drive shift-stick, there's no difference, and he can drive automatic if need be. But for the person who can only drive automatic, shift-stick looks like something crazy and pre-historic. These people really believe that the automatic transmission helps them concentrate on driving. Imagine that.

Good analogy, but I'd compare the situation more to when you are stuck in traffic that moves fairly slow and you constantly have to shift between first and second gear. Sure you can do that with a stick shift - no problem, but it is a lot more convenient with an automatic transmission.

If we instead look at the case where you are driving down the highway at full speed, the manual transmission gives you a lot better control over where and when you want the power and torque from your engine.

[supperman]

Ha, yes, that is a perfect analogy.. especially now that, after many decades, automatic transmissions outperform even the best human drivers. It just takes time...

[OwO]

I don't think automatic transmission is a good analogy for HLS; designs generated by HLS do not come even close in area efficiency (think 2x area needed) to a "normal" design done in VHDL/SystemVerilog. It's not even comparable to assembly vs C.

Here is one real world comparison of HDL vs HLS: https://translate.googleusercontent.com/translate_c?depth=1&rurl=translate.google.com&sl=auto&sp=nmt4&tl=en&u=https://habr.com/en/post/427361/

HLS makes you think about hardware design in a completely wrong way. There is nothing resembling sequential operations on data in hardware, and modeling control flow sequentially instantly throws away most of your hardware because you are blind to the fact that e.g. a multiply, a subtract, and a multiplex operation can all happen at the same time, and you only might use a small portion of your hardware at a time. Sure the tools can "parallelize" some of your codepaths if it can statically determine there are no data hazards, but the presumption of sequential execution forces you to make design decisions that are no good match for the hardware. The pipeline is probably the most basic hardware structure and there is no clean way to describe it in HLS. I think a better analogy would be programming by putting lego blocks together.

[Nerull]

Sure you can be more efficient in something like C, but the effort to do things like index a 3D hashmap with string indices in C is a lot higher than doing so in Javascript or Python. So unless you are writing a highly streamlined piece of computational software, you are probably better off in a high-level language.

High-Level languages are like automatic transmission. It is true that you need less "efforts" to drive automatic, but this is not true that you can driver better or faster. It is also not true that the automatic can do everything which manual could - for example, you cannot push your car if your battery dies. For a person who already knows how to drive shift-stick, there's no difference, and he can drive automatic if need be. But for the person who can only drive automatic, shift-stick looks like something crazy and pre-historic. These people really believe that the automatic transmission helps them concentrate on driving. Imagine that.

It's funny you bring up transmissions, where today automatic transmissions dominate racing because they are faster in every way. No human driver can shift that fast. In drag racing manuals have been moved to their own classes in many cases due to the inability to stay competitive.

[NorthGuy]

It's funny you bring up transmissions, where today automatic transmissions dominate racing because they are faster in every way. No human driver can shift that fast. In drag racing manuals have been moved to their own classes in many cases due to the inability to stay competitive.

I guess my experiences with automatic transmissions are obsolete

I am sure, there will be some day when automatic programming will outperform humans, and humans will not be needed for programming any more, if at all. But this is a long way from today's HLS.

[langwadt]

Sure you can be more efficient in something like C, but the effort to do things like index a 3D hashmap with string indices in C is a lot higher than doing so in Javascript or Python. So unless you are writing a highly streamlined piece of computational software, you are probably better off in a high-level language.

High-Level languages are like automatic transmission. It is true that you need less "efforts" to drive automatic, but this is not true that you can driver better or faster. It is also not true that the automatic can do everything which manual could - for example, you cannot push your car if your battery dies. For a person who already knows how to drive shift-stick, there's no difference, and he can drive automatic if need be. But for the person who can only drive automatic, shift-stick looks like something crazy and pre-historic. These people really believe that the automatic transmission helps them concentrate on driving. Imagine that.

It's funny you bring up transmissions, where today automatic transmissions dominate racing because they are faster in every way. No human driver can shift that fast. In drag racing manuals have been moved to their own classes in many cases due to the inability to stay competitive.

in what racing class other than drag racing, which is a very special case, does automatic dominate?

paddle shift is not automatic, it is just manual with different controls

[supperman]

ugh.. sorry for going off topic here.. sure.. if you consider a Porsche PDK to be a manual then you are right...