High Level Discussion of Vitis

[supperman]

Hi All,

I'm surprised to find very little on Vitis on this board... and I'm really struggling with the marketing speak at Xilinx to fully understand what their product offerings are..

1. I want to use it since I want to develop for the Zynq. I primarily need an embedded processor that can interface with hardware for some specific tasks. 90% of what I do will be in C++ on the processor. All the hardware implementations will be driven by the processor. So it is VERY enticing.

2. Vitis seems like an extension to SDSoC. Did I get this right? In that sense calling it a separate toolset is probably just marketing?

My biggest question:

1. Why do none of the 3rd party board manufacturers have "drivers" that are up to date for either SDSoC or Vitis. It seems to be a major hurdle to develop hardware profiles for either.. so much so that the rapid development industry selling modules can't even get it right. I purchased a 104 demo board from Intel for that reason.. but once I have it up and running.. how hard will it be to port what I have to my own hardware?? Is that a no-go? I mean do you lose all the rapid dev benefit once you have to go and develop your own hardware profile?

2. Are there any good tutorials on using Vitis / learning Vitis.. or even getting a better understanding of how Vitis fits in with everything else. Shit.. even installing "Vitis" simply installs their main tool-chain and I can't even find the Vitis name in the install.

Many thanks for your thoughts.. and no haters please.. I am probably the guy they are targeting.. a software architect.. with a little hardware experience.. and I really don't want to spend my time figuring out the right version of Peta Linux and be in driver hell developing hardware extensions if I can avoid it...

Again. many thanks for any help..

[OwO]

IMO don't bother with the software stack that Xilinx provides and just run ordinary Debian on the Zynq (using the linux-xlnx kernel). Input your board parameters in Vivado block design as usual, and use the SDK to generate the first-stage bootloader (which sets up most of the important board-specific settings), and the rest is generic stuff that is independent of your board. On the FPGA side you just need the board specific pin assignments (.xdc). After that all you need to do is add your accelerator or whatever in Vivado block design and access it from Linux userspace using /dev/mem, and use UIO for interrupts. No need for drivers.

[supperman]

Thanks OwO,

I appreciate your feedback. That may very well turn out to be the way to go. Are you making this suggestion because you are familiar with the Vitis platform and think it is unhelpful or is it rather familiarity with the way you approach Zynq development?

I get that Vitis is very new.. and it is part of a marketing effort to create market share. But it sounds rather fantastic and ground-breaking... So I want to make sure to hear from people with hands on experience if at all possible. Xilinx seems to have gone all out on this and especially since I'm new to Xilinx dev.. why not learn the new stuff rather than the old stuff from 10 years ago??? (unless it is garbage of course)

[OwO]

For me the biggest reason is portability; with HDL you can seamlessly switch between Altera SoCFPGA and Zynq (and any other vendor) with no changes to the core designs. The other big reason is hardware design is NOT programming, and doing things in a sequential language like C forces you to approach the design the wrong way. Even if the tools eventually reach similar area efficiency as plain HDL (which I have fundamental reasons to believe it won't), I still see VHDL as easier to write because it's a far more natural description of dataflow and processing pipelines.

Contrary to popular belief HDL is not a low level language; you don't deal with any of the nasties that are associated with "low level languages" in programming which are undefined behavior and lack of machine abstraction. In fact HDLs present a highly abstracted and ideal view of the hardware in which you describe dataflows. I would consider VHDL a high level language, and C/HLS a low level language that is nasty to program for. See my comments here: https://www.eevblog.com/forum/fpga/xilinx-announces-vitis/msg2857882/#msg2857882

[OwO]

There is a big caveat with what I just said though: HDLs do have a big learning curve and you really have to take a full semester course (or equivalent) and adjust your way of thinking to be able to design hardware properly. Once you have overcome the learning curve however, you can design just as fast with HDL as HLS, assuming you want to do an optimized design and not just wing it. I can see the value of HLS which is that it allows non hardware designers to put some code in a FPGA and have it be comparable power efficiency wise to a GPU solution, but that misses out on much of the power efficiency potential of using an FPGA, which in some applications can beat a GPU by many times.

[supperman]

OwO,

Thanks, This is super helpful and much appreciated. It probably is project dependent too.. at least to some degree. It should be possible to mix and match as well? I.e. High level.. using various IP components for memory and math.. and then optimizing sections that need it later at a lower level?

I totally get what you are saying with hardware methodology.. and how a GPU is not like an FPGA. I certainly don't want to lose the connection to the hardware..

Best,
Andrew

[NorthGuy]

I haven't used it, but the idea seems very simple. Zynq has an ARM CPU. You program it in C. Then the profiler identifies the critical pieces where the program spends the most time, and the system builds hardware pipelines to accelerate the most critical loops. As an example they cite video acceleration, but I don't think FPGA stands any chance against GPU in the area of graphic processing. Otherwise, it has a potential to accelerate your calculations many times compared to what you would get from ARM alone.

There are 100 (or may be 1000) times more C/C++ programmers than HDL programmers. Xilinx tries to make FPGA available to all these people - that's the buzz. Since I already can program in HDL, this doesn't help me, and I don't see a reason to use this.

What exactly your project is?

[blacksheeplogic]

After that all you need to do is add your accelerator or whatever in Vivado block design and access it from Linux userspace using /dev/mem, and use UIO for interrupts. No need for drivers.

Spinning up a device driver does not really take long and makes working with the device a lot easier from that point on.

[supperman]

I'm new at Vitis and am digging in deeper. It took me a full 3 days to get a full build up and running (building linux and app and deploying a hello world type of app with some custom logic.) I plan to post the 150 some steps here when I get a chance to clean it up a bit. Vitis is a bit of a half baked and Xilinx has not made solid instruction available. There are actual errors in the instruction that you can find..

But all that said.. I think it is important to not miss the point to it all. Vitis seems ideally suited for a computer system that interfaces with hardware and or needs custom acceleration. I think an Oscilloscope might be a perfect project for it. You start from a software perspective since 95% of all if it is software! You work the profiler just the way you normally would writing software.. but now you have the option to accelerate key functions in hardware.. on the fly with a few clicks. You can play with this and find a balance between cost and speed (Arm and gates).

Sure you could do it the old way.. but you will quickly get locked down in an inflexible design. The idea of sketching out what is hardware and what is software prior to implementation is problematic since you don't know what is best.

I think the real software analogy is working with or without a profiler. The old way.. write in C and use assembler where you think you need it (not hard right). The new way is to write everything in C and run the profiler.. then dig in where it matters.. and in the case of Vitis you have the tools to do that on the fly.. trial and error. There is a world of difference between the two approaches.. IMO..

But of course it could be crap.. since it is very unfriendly from a setup perspective..and that is using their own demo hardware..

[NorthGuy]

I think an Oscilloscope might be a perfect project for it.

You think so?  Even a small scope with 4  1Gs/s channels produces 32 Gb/s. Doesn't seem like something a CPU can deal with. Thus, you'll need a lot of work done in PL before CPU can even get any data.

[OwO]

Don't think that's a good analogy, there is nothing in common between digital logic and code running on a CPU. I think it's more like letting a tool decide what parts of your circuit are analog and which parts are digital. There are limited cases where you can even come up with a figure of merit to optimize for ("total runtime" is only really applicable to batch processing applications). Oscilloscope is the perfect example of something not appropriate for Vitis (signal processing is more easily designed as a pipeline, hw/sw separation is logical and natural, CPU must not be heavily loaded because of realtime requirements, trigger logic and others with hard realtime requirements that can not be described in software, etc).

[supperman]

I think the IP that goes into a modern scope (on the digital side) is 90% software that runs in C. Certainly from a development-time effort perspective and certainly later with firmware updates. I don't know how good Vitis is at moving data around and optimizing things like FFT in hardware.. but I did see it crush though a 4k video canny edge filter at 60 FPS on a Zynq simply by moving a C-function to hardware and setting some parameters.. so they definitely are targeting it. (I think that is 11Gbit touched 9 times via a 3x3 and written back out.. 110Gb/sec?? perhaps)

I'm not selling Vitis! Right now Vitis is in the dog house for me since I spent 3 days on Hello World.. but I'm optimistic.

[filssavi]

I think Vitis is targeted more at the Software market, there is a very large potential customer base for FPGA acceleration (think about high speed networking, data mining/ data science, computer vision, AI etc ) where the possible speed ups are large, but projects are small and varied enough that there it does not make any sense to create HDL IP.

A scope is kind of the opposite, all the magic is in the analog front end and sample clock generation. FPGAs in modern scopes are used for triggering, which being highly performance critical will be done in HDL, and for an extremely wide memory interface, and that will be off the shelf IP.

All other processing FFT, averaging, etc, are extremely simple signal processing steps for which IP will be already available, and even if it weren’t it would take more time to set up and learn the Vitis environment than to just develop it in HDL

[supperman]

I think in the end we are all agreeing.. and perhaps talking past each other..

Vitis targets the Zynq and does not even work on other platforms.. So if it is not a Zynq.. don't use Vitis. I don't think I disagree with anything said. Analog is the real magic.. not something I'm addressing. FFT etc.. easy.. correct. AND IP is done...

So.. 90% of the stuff is Software.. on a Zynq.. (Like Tek MSO4 series..) UI, High Level decoding.. Graphics.. Data presentation..

I mention scope because it really only makes sense if there is a lot of software required AND there is a high speed custom hardware connection required.. (or you could just use a micro processor)

To make my argument short: If you have a Zynq in your design you should probably look at Vitis.. I think a LOT of modern scopes run on Zynq these days..

[SiliconWizard]

Of course, that approach can make development faster, but it also ties you to Xilinx, which is the whole point why they came up with Vitis to begin with...

If you need a a system built around a CPU+FPGA, writing software on a CPU and the FPGA part in HDL will make life much easier if you ever want to switch to a different vendor. So, that's always something to keep in mind.

[supperman]

That is a very good point and not lost on me. From a software perspective if feels like Microsoft tools back in the day.. and it was problematic once implementing DirectX and such..

But does it matter as much with hardware? I don't see products switching FPGAs mid stream since the hardware itself locks you in... a bigger question would be perhaps what does it look like switching from FPGA to ASIC???

I'm not an expert here.. so I'm unsure.