10-10-2018 08:48 AM
I am starting an image processing project for which the end solution will be run on a zedboard. The image processing project involves motion analysis on real-time video feeds.Does anyone have an advice on which route of the below is preferable for design optimization in terms of performance?
1. Use C/C++ and Vivado HLS
2. Use Matlab and HDL coder/System Generator
There is a similar question here : https://forums.xilinx.com/t5/Vivado-High-Level-Synthesis-HLS/Vivado-HLS-or-Matlab-HDL-coder/m-p/561083/highlight/true#M2964
However the answer focuses more on development time.
10-29-2018 04:36 AM
Note: I promise I'm not getting paid by Xilinx for this.
My experience with HDL Coder is a few years old now (and the Vision HDL Toolbox was a very new product), but at that time I was extremely unimpressed by what it offered. I switched to HLS and never looked back.
Considering that it's a hideously expensive package (a 1-year license of Matlab + HDL Coder + Simulink + Image Processing Toolbox + Vision HDL Toolbox was something like six months' salary for me at the time) you'd expect that HDL Coder would be a very nice tool. In reality, it was more like "Verilog, but without all the FPGA-friendly features that make Verilog a good language for FPGAs". You still had to describe what happened in every clock cycle (as you do in Verilog), but in a language that is designed for academics doing matrix maths.
The fixed-point tools (you have to pay for those too...) looked promising, but I felt that they weren't really suitable for production use. Being able to simulate the design and check what ranges are actually used (so you can select an appropriate integer/fraction size) is useful, but for any serious work "it didn't exceed these values in a simulation" doesn't cut the mustard. The only real solution is to mathematically prove the limits, which I think is easier to do in HLS.
There are two key points in HDL Coder's favour. One advantage is when your whole algorithm can be handled with Mathwork's pre-written blocks; then you just chain those blocks together and you're finished in a few hours. Mathworks is an IP company (ie their primary products are toolboxes to use with Matlab), so they have a major interest in developing software that people will want to buy, leading to an extensive range of advanced, pre-written blocks. The other advantage is in their support, because Mathworks seems to provide pretty good customer care - as you would expect given the price.
On to HLS. HLS has neither of HDL Coder's advantages. Xilinx is a hardware company, and they're not really making money from HLS (especially when you're using the free version). I wouldn't be surprised if Vivado as a whole is only (or not even) a break-even deal for Xilinx, with the income from paid versions going to cover support and development. As a result, Xilinx has no real interest in developing advanced HLS blocks; the ones they provide tend to be pretty basic utility functions to allow for simple, practical tutorials. Official support for the free HLS version is minimal; it's all handled through this forum. However, unlike HDL Coder there are plenty of hobbyists using HLS (because it's free) and so community support is pretty solid.
However, once you start doing projects that can't be built from the provided blocks, HLS is really in a class of its own. It's a whole layer of abstraction above HDL (and HDL Coder, when I used it). You describe the behaviour you want (sort-of, see below), and HLS figures out how to pack that into each clock cycle (with hints from you) to achieve the desired performance. C is a better language for FPGAs than Matlab anyway (because of the type system it uses and the manual memory allocation) and combined with the libraries provided by Xilinx (a significant number of the basic OpenCV functions) you get a lot of flexibility. I've used it for a range of blocks, from a near-trivial test pattern generator, to a VDMA (because I didn't like the Xilinx ones), to some serious image processing and machine learning. It's not bug-free, but if you're gentle with it then it's a very, very good tool.
The big HLS limitation is, as always, that it's not really C - or at least not "x86 C". Dynamic memory allocation is largely nonexistent. Floating-point is supported but inefficient. Almost all libraries are unavailable. Numerous C aspects (like pointer to pointers to pointers) are either explicitly unsupported or asking for trouble. In short, if you write a regular C program and hit the "Synthesize" button then you're probably going to have a bad time, and if you feed an optimized-for-x86 C library into HLS then you're going to have a really bad time (people do this every now and then. Don't). Similarly, if you're coming to HLS from the other direction and trying to write Verilog via HLS (eg. getting cycle-accurate output timing) then you're not going to enjoy the experience.
However, if you think of HLS as a way of telling the FPGA what result you want to achieve using simple steps (FPGAs are very, very good at doing a lot of simple operations in parallel) with C-like syntax, then the problems disappear. HLS becomes an extremely powerful tool which can give both a faster result than HDL and more flexibility.
With regards to performance: HLS is not going to be as good as HDL hand-crafted by an expert. It's going to be a whole lot better than HDL mashed-together by a beginner. Since HDL Coder doesn't really give you much opportunity to hand-craft anything (because the language doesn't support the necessary features) I think you'll find that HLS does a much better job.
With that said, it's been a few years. HDL Coder might have gotten better. If you're working for a company or university then you could ask Mathworks for a HDL Coder evaluation license and see how that goes. If you're a hobbyist then the choice is pretty straightforward: either you can buy HDL Coder, or you can use HLS and buy a new car with the money saved.