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!

Showing results for 
Search instead for 
Did you mean: 

Adam Taylor’s MicroZed Chronicles Part 144: Cracking open High Level Synthesis (HLS)

Xilinx Employee
Xilinx Employee
0 0 48K


By Adam Taylor


So far on this journey, we have touched HLS (high-level synthesis) when we looked at the Xilinx SDSoC Development Environment. However, we have not directly used the standalone Vivado HLS, which comes as standard as part of the Vivado HLx Design Suite. It is time to correct this oversight. Over the next few blogs, I want to introduce the basics of HLS and then introduce how we can best use HLS for creating embedded-vision designs.


So what is wrong with plain, old HDL design? Why do we need a whole new design-capture paradigm? As devices get larger and as designs get more complicated, we need new to use new development methodologies to achieve the required results while keeping development time reasonable. This has always been the case for Programmable Logic (see the figure below).





Overview of Programmable Logic Development over the last 40 plus years



As the marketers like to say, HLS raises the level of design abstraction and that higher level allows us to create complex designs more quickly. The marketers like to say this, and in this instance they happen to be correct. HLS has been on the verge of breaking into mainstream development for a number of years. (Certainly I remember a demo when I was a graduate in 2000 of HandelC.) However, recent development-tool introductions including the Vivado HLx releases have pushed HLS firmly into mainstream design. I now use it a lot and like it.


That said there is still a place for HDL modules where handcrafted hardware design is needed to achieve maximum performance. The key is knowing what tool we as engineers should use for the task at hand so that we can deliver designs while meeting quality, time and budget goals.  


The HLS environment within Vivado HLx should be very familiar to you if you are developing with the Xilinx Zynq SoC or Zynq UltraScale+ MPSoC using SDK or SDSoC. Vivado HLx and SDSoC are both based on the Eclipse platform.


We can use Vivado HLS to directly generate HDL from C, C++, or SystemC descriptions. The code for the function we want to compile with HLS must stand alone and must be contained within its own source file. (We will examine more HLS constraints in future blogs). Another big advantage of using HLS is that you also define the test bench in C, which allows for much quicker verification. What is really cool is we can use this high-level test bench to verify the HDL module compiled from the C/C++/SystemC code.


The Vivado HLS menu bar allows us to implement all of the steps we need. The menu bar shows C Simulation, Synthesis, Co-Simulation, Export RTL, Open Report and View Waveform—roughly the order in which they are used.





Vivado HLS menu bar




The Vivado HLS design flow is very simple, as we will see with a simple example (which adds two integers together). This flow is outlined below:


  1. Write the C function we wish to compile with HLS. Add this source file to the source directory within Vivado HLS. (See add_ex.c and add_ex.h in the GitHub repository.)


  1. Write a C test bench that tests the C function we are going to compile with Vivado HLS. Put this test-bench file in the test bench directory within Vivado HLS. (See add_tb.c on the GitHub repository.)




Source files and test bench files within Vivado HLS




  1. Run a C simulation within Vivado HLS. This simulation allows us to verify that our C function works correctly. We want to know that the function works in C before we move on to synthesis and Co-Simulation. Within this test bench, we can use the standard techniques that we would in most C test harnesses. As this test bench runs within the HLS debugging environment, we can set breakpoints, examine memory, and step through the program should there be issues with either source or test bench code.





C Simulation and Reported Results in the Console




  1. If we are happy with the results of the C simulation, we can progress to synthesizing the module to generate HDL code for our design. This step will also produce a synthesis report that includes resource estimates and interface parameters.





 HLS Synthesis Report & Output files






Report Utilization Estimate




  1. Once we have the synthesized output, we can run co-simulation, which will apply the C test bench to the generated HDL using the selected simulator (Verilog or VHDL) and will report on the pass/fail criteria we set. This will also produce a co-simulation report and, even better, we can capture waveforms from the simulation and open them in the simulation tool for later inspection.





Co-simulation dialog box allowing us to select Verilog or VHDL HDL





Co-simulation Report





 Screen Shot of Co-simulation waveform results




  1. The final development step is to export the resulting HDL to the Vivado IP library so that we can use it in our designs.




RTL Export Dialog



Overall the Vivado HLS flow is very simple and tightly integrated. However there are other areas we need to look at to use it effectively, which we will do over the next few blogs.


If you want to run through the example with the files from GitHub, you can establish the project going through the screen shots below.


















Code is available on Github as always.


If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.




  • First Year E Book here
  • First Year Hardback here.



MicroZed Chronicles hardcopy.jpg 




  • Second Year E Book here
  • Second Year Hardback here




MicroZed Chronicles Second Year.jpg 




All of Adam Taylor’s MicroZed Chronicles are cataloged here.