High-Level Synthesis (HLS) is a design flow that compiles a behavioral description written in a high-level language (most commonly C, C++, or SystemC) into synthesizable RTL (typically VHDL or Verilog). The tool infers hardware structure -- pipelines, datapaths, memory interfaces -- from the algorithmic description rather than requiring the designer to specify it directly.
In practice
HLS targets FPGA and ASIC development. On the FPGA side, Xilinx Vitis HLS (formerly Vivado HLS / AutoESL), Intel HLS Compiler, and Mentor Catapult are the most widely used tools. The typical workflow is: write and verify the algorithm in C/C++, add vendor-specific pragmas or directives to guide pipelining and resource allocation, run synthesis, then inspect the generated RTL and timing/resource reports. The output drops into a standard RTL flow (Vivado, Quartus, etc.) like any hand-written module, though integration may require some adaptation (constraints, glue logic, or port matching) depending on the design.
HLS can significantly reduce development time for compute-heavy blocks -- FFTs, FIR filters, matrix operations, image processing pipelines -- where the algorithmic intent is clear but the manual RTL implementation is tedious and error-prone. The synthesized RTL is often competitive with hand-written RTL for well-structured, regular algorithms. The gap widens for control-heavy, memory-access-irregular, or latency-critical designs, where the tool's scheduling and resource-sharing decisions can be difficult to override.
A recurring practical difficulty is that C/C++ semantics and hardware semantics diverge in important ways: pointer aliasing, dynamic memory allocation, recursion, and standard library calls are either unsupported or require significant restructuring before HLS tools will accept them. Designers also frequently find that the pragma-tuning loop -- adjusting PIPELINE, UNROLL, ARRAY_PARTITION, and INTERFACE directives -- is itself a substantial engineering effort, and results can be sensitive to small code changes. Community discussion (see "Little to no benefit from C based HLS" and "[Comments] C HLS Benefits") reflects a real split of opinion on whether the productivity gains hold up outside straightforward DSP kernels.
Verification is a separate challenge. The C/C++ testbench used for pre-synthesis simulation ("C simulation") does not automatically prove the RTL is correct; co-simulation reruns the testbench against the generated RTL but can be slow. For safety- or correctness-critical designs, formal verification or extensive RTL-level simulation is still needed on the generated output.
Frequently asked
What languages can I use as input to HLS tools?
Most commercial tools (Vitis HLS, Catapult, Intel HLS Compiler) accept synthesizable subsets of C and C++.
SystemC is supported by several tools and is commonly used for system-level modeling. A small number of research or niche tools accept subsets of Python or other languages, but C/C++ dominates in practice and Python-based HLS input remains uncommon in production flows. The synthesizable subset excludes dynamic memory allocation, most standard library I/O, recursion in many tools, and pointer arithmetic that creates ambiguous aliasing.
Does HLS replace RTL (VHDL/Verilog) design entirely?
Not in general. HLS is well-suited to datapath-heavy and algorithmic blocks. Many designers use it selectively for those components while writing
RTL by hand for glue logic, interfaces, state machines, and timing-critical paths. Interfaces between HLS-generated blocks and hand-written RTL must be carefully matched at the port level.
How good is the quality of results (QoR) compared to hand-written RTL?
For regular, pipelined DSP-style algorithms (filters, transforms, matrix math), a well-directed HLS flow can produce results within 10-20% of hand-written
RTL in area and throughput. For control-heavy or memory-bound designs the gap is often larger and harder to close with pragmas alone. QoR is also heavily tool- and version-dependent; benchmarks from one tool version do not reliably predict results from another.
What are HLS directives/pragmas, and why do they matter?
HLS tools synthesize a default schedule that may not meet throughput or latency targets. Pragmas (Vitis HLS syntax: #pragma HLS PIPELINE, #pragma HLS UNROLL, etc.) or tcl-based directives instruct the tool to pipeline loops, unroll iterations, partition arrays across BRAMs, or flatten the call hierarchy. Getting these right is often the dominant engineering effort in an HLS project; incorrect directives can silently produce correct-but-slow or area-bloated hardware.
Can I use HLS for ASIC design as well as FPGAs?
Yes. Tools like Mentor Catapult and Cadence Stratus are used in
ASIC flows and support standard-cell library targeting. The methodology is similar to the
FPGA case, but timing closure, power optimization, and library characterization introduce additional
constraints. FPGA-centric tools like Vitis HLS can technically export
RTL for ASIC flows, but they are not optimized for standard-cell power/timing trade-offs.
Differentiators vs similar concepts
HLS is often confused with
HDL (Hardware Description Language). HDLs such as
VHDL and
Verilog describe hardware structure and behavior at the
register-transfer level; the designer explicitly specifies registers, clocking, and datapaths. HLS operates one abstraction level higher: the designer describes an algorithm in C/C++/
SystemC and the tool generates the RTL. HLS is also distinct from hardware description using Python-based tools like MyHDL or Amaranth, which are high-level languages that still target RTL-level descriptions and give the designer explicit control over clocking and structure -- they do not perform algorithmic scheduling the way HLS tools do.
