High-Level Synthesis is a good candidate when a block is dominated by algorithmic computation, has measurable throughput and latency goals, and can be described with clear data movement and numeric behaviour. It is less compelling when the value lies mainly in intricate cycle-exact control, undocumented legacy behaviour, or manual circuit structures that the HLS tool cannot express. The reliable answer comes from a bounded feasibility study: implement a representative path, verify it, synthesise it against the real target, and compare the evidence with agreed acceptance criteria.
Read the diagram as steps
From uncertainty to a decision
- Candidate boundaryRepresentative compute, state, memory and interfaces.
- RequirementsFunction, power, performance, area, traffic, target and sign-off needs.
- Architecture experimentsExplore pipelines, parallelism, data types, buffers, memory and interfaces.
- Downstream evidenceCorroborate with co-simulation, synthesis and implementation evidence.
- Go
- Refine
- Stop
The initial suitability test
A promising HLS block usually has a stable mathematical or algorithmic contract: a filter, transform, codec stage, packet calculation, cryptographic primitive, image pipeline, inference operator, or similar workload. Loops, arrays, streams, fixed-width arithmetic, and exploitable parallelism give the tool meaningful architectural choices. The designer can then explore pipelining, unrolling, resource sharing, memory banking, and interface synthesis without changing the functional intent.
Suitability is not the same as “the algorithm compiles.” The block must fit its system. A study therefore asks whether input bandwidth can feed the proposed datapath, whether output backpressure is safe, whether state and memories map cleanly, and whether reset, clocking, interrupts, configuration, and error behaviour can be integrated. If the block combines a large datapath with a small cycle-sensitive controller, a mixed HLS-and-RTL architecture may be the clearest answer.
Inputs needed for the study
The fastest route to a useful result is a compact, testable design brief. It should contain:
- Functional intent: a specification and, ideally, an executable reference model with representative and corner-case vectors.
- Performance contract: clock target, sample or transaction rate, acceptable latency, burst behaviour, and rules for stalls or backpressure.
- Numeric contract: input ranges, required accuracy, overflow and rounding policy, and any floating- to fixed-point conversion constraints.
- Interfaces and memory: protocols, bus widths, ordering, buffering, external memory traffic, on-chip memory assumptions, and clock/reset domains.
- Target context: ASIC library and downstream flow, or FPGA family, speed grade, resource budget, and relevant hard blocks.
- Verification and sign-off: golden outputs, tolerance rules, coverage expectations, lint or CDC requirements, and the evidence needed for approval.
Missing information is itself a study finding. Assumptions should be written down and sensitivity-tested, because a design that passes only under optimistic memory or traffic assumptions is not yet a sound commitment.
Evaluation steps
- Define the decision. Agree what “feasible” means and identify the risks that could change the architecture or invalidate HLS.
- Establish a trustworthy baseline. Run the reference model and preserve tests that cover nominal, boundary, reset, stall, and error behaviour.
- Select a representative slice. Prototype the dominant compute and memory path, plus enough interface behaviour to expose real bottlenecks. Avoid a toy kernel that omits the difficult part.
- Explore architectures. Compare credible pipeline, parallelism, resource-sharing, data-type, buffering, and memory-partition choices. Record constraints and tool versions so the experiments are repeatable.
- Verify generated RTL. Reuse the functional tests in C/RTL co-simulation and investigate mismatches, deadlocks, reset behaviour, and protocol timing. For the full methodology, see verification for HLS designs.
- Check downstream reality. Use RTL synthesis and, where the decision requires it, implementation-aware timing, area/resource, power, congestion, and memory evidence. HLS estimates alone should not settle a high-risk physical question.
The study should also compare HLS with the actual alternative. For a new algorithmic block that may be hand-written RTL; for an existing block it may be maintaining the current implementation. If legacy RTL is the starting point, separate behavioural preservation from architectural redesign; our RTL-to-HLS migration guide explains that distinction.
Worked example: a streaming FIR filter
Illustrative engineering example. The requirements below are assumed. The calculations are arithmetic bounds, not client results or measured HLS, FPGA, or ASIC performance.
Start with the contract
Consider a direct-form, 32-tap finite impulse response (FIR) filter with arbitrary, non-symmetric coefficients. Assume a required sustained input rate of 25 million samples per second and a target clock of 200 MHz, with no input or output stalls during the throughput measurement.
The available budget is 200 MHz ÷ 25 MS/s = 8 clock cycles per input sample. This constrains the sustained initiation interval; the first output may take more than eight cycles to emerge. A separate latency limit would still be needed.
For this example, samples and coefficients are signed 16-bit integers. Keep the full product sum in a signed 37-bit accumulator, return that full-precision result, and initialise the sample history to zero on reset. This makes the expected arithmetic and startup behaviour explicit before considering a narrower, rounded or saturated output.
Use a lower bound to select experiments
Each output requires 32 multiply-accumulate operations. If each lane can accept one such operation per clock, the arithmetic alone requires at least ceil(32 / lanes) cycles per output. This assumes that memory, accumulation dependencies, and interfaces can keep every lane supplied.
| MAC lanes | Minimum cycles per output | Throughput ceiling | Decision for this study |
|---|---|---|---|
| 1 | 32 | 6.25 MS/s | Cannot meet 25 MS/s under these assumptions. |
| 4 | 8 | 25 MS/s | Smallest arithmetic candidate; no spare issue capacity. |
| 8 | 4 | 50 MS/s | Compare as a candidate with more arithmetic capacity and a higher resource cost. |
The first decision is to investigate four and eight lanes. Neither row proves feasibility. Check how coefficients and delayed samples reach those lanes, how partial sums are combined, and whether the schedule sustains an interval of eight cycles or less. Limited memory ports can prevent a requested interval from being achieved; AMD demonstrates this in its array-partitioning example.
Define what would count as evidence
- Arithmetic: compare impulse, step, alternating-sign, extreme-value, and seeded random sequences with an independent full-precision reference. Check reset and startup history explicitly.
- Scheduling: synthesise both candidates for the selected target and record the achieved initiation interval, operator allocation, memory organisation, and latency.
- RTL behaviour: reuse the vectors in C/RTL co-simulation, add input gaps and output backpressure, and check ordering, output stability during stalls, and reset recovery.
- Implementation: confirm the 200 MHz timing target and the agreed resource budget in the downstream flow before accepting the architecture.
The result of this paper exercise is a bounded experiment plan. A go decision would require passing the functional checks, sustaining at least 25 MS/s under the stated traffic conditions, and meeting timing and resource limits on the real target.
Decision criteria
| Decision area | Evidence to review | Question to answer |
|---|---|---|
| Function | Reference comparison and corner cases | Does the implementation preserve the required numeric and state behaviour? |
| Performance | Initiation interval, latency, clock, and stall analysis | Can it sustain the system workload under realistic traffic? |
| Cost | ASIC area/power evidence or FPGA resource use | Does it fit the agreed budget with suitable margin? |
| Integration | Interfaces, memory traffic, reset, CDC, and backpressure | Can the block be integrated without hiding risk elsewhere? |
| Maintainability | Source structure, constraints, tests, and automation | Can the team reproduce, modify, and verify the result? |
ASIC studies should use the intended standard-cell and memory context as early as practical, because clock uncertainty, RAM choices, and physical effects shape the result. FPGA studies should account for the chosen device's DSP, block-memory, routing, and interface resources rather than treating generic operation counts as final utilisation.
Deliverables
A decision-grade study should leave reusable engineering assets, not only a slide deck. Typical deliverables include the synthesizable C++ or SystemC prototype, reference model and self-checking tests, build scripts and constraints, generated RTL for the evaluated configuration, synthesis and verification reports, an architecture and interface description, and an assumptions-and-risks register.
The conclusion should identify the recommended architecture, tested alternatives, acceptance-criteria status, unresolved questions, and a scoped path to production. It should also state which modules remain in RTL and which tests and sign-off tasks are still required. These artefacts can form the first increment of a full HLS design and implementation engagement rather than being discarded after the decision.
Red flags and stopping conditions
- No agreed reference behaviour, numeric tolerance, or representative workload.
- Required bandwidth exceeds the available interface or memory architecture.
- The claimed result depends on idealised traffic, zero stalls, or unavailable memory ports.
- Most complexity is cycle-exact protocol control with little algorithmic datapath to optimise.
- Correctness depends on unsupported language behaviour, hidden state, or undefined arithmetic.
- The target power, performance, and area (PPA) can be met only with constraints or IP that cannot be used in production.
- Generated RTL cannot be reproduced, verified, or passed through the required downstream flow.
A red flag is not automatically a rejection. It is a reason to change scope, use a hybrid architecture, improve the specification, or run a focused experiment before investing further. For background on schedules, interfaces, directives, and verification, start with our introduction to High-Level Synthesis.
Frequently asked questions
How long should an HLS feasibility study take?
A useful feasibility study lasts only as long as needed to retire the main technical risks. Its scope should be set by the block's uncertainty, available reference material, tool access, and the fidelity required from downstream ASIC or FPGA estimates; there is no universal duration.
Can an HLS report alone prove that a block is feasible?
No. HLS reports are useful for comparing architectures, but feasibility should be judged with the appropriate downstream evidence. That may include RTL synthesis, implementation or place-and-route estimates, memory mapping, interface checks, and representative verification results.
Do we need working C++ before starting?
Not necessarily. A trusted executable reference is ideal, but a specification, RTL implementation, or model in another language can be enough to begin. The study must reserve time to establish expected behaviour and representative test vectors before comparing hardware results.
What is a successful feasibility-study outcome?
Success is a defensible decision, not a forced recommendation to use HLS. The outcome may be to proceed, proceed with conditions, keep selected control logic in RTL, change the architecture, or reject HLS for this block, with evidence and unresolved risks recorded.
Sources
- AMD Vitis HLS User Guide: Building and Running an HLS Component — official design, C simulation, synthesis, co-simulation, and analysis flow.
- AMD Vitis HLS User Guide: Interfaces of the HLS Design — official guidance on interfaces, memory layout, execution, and reset behaviour.
- Siemens EDA: High-Level Synthesis and Verification — official overview of ASIC/FPGA synthesis, architecture exploration, and verification capabilities.
- Cadence: Stratus High-Level Synthesis — official overview of SystemC/C/C++ synthesis and downstream digital-flow integration.
