When the First HLS Successes Stop Scaling

The view from the Watchtower

Catapult helped prove an important point to the semiconductor industry: higher abstraction can deliver real engineering leverage. For many teams, the first HLS-based design delivered tangible benefits. A block moved faster. A team got more done. A schedule looked more manageable. But in 2026, that is no longer the only question. The more important question is this: what happens after the first win, when HLS has to scale across real programs, multiple blocks, changing specifications, and more than a handful of experts?

That is where the ROI conversation starts to change.

The first HLS win was real

A lot of the early HLS value proposition was about possibility. Raise the level of abstraction. Move faster. Let engineers work closer to intent than implementation. For the right classes of designs, that promise still matters. But once a company has already proven that HLS can work, the conversation shifts. It becomes less about whether abstraction is useful and more about whether the current flow is still the best economic choice for the next stage of growth. That shift is especially visible in AI, networking, video, DSP, and other data-heavy silicon programs where architectural exploration is no longer optional. It is the work.

When ROI starts to erode

Teams start noticing patterns like:

• Iteration loops that feel too long relative to the value of each change.

• QoR that looks acceptable in the HLS environment but becomes harder to trust once it reaches downstream synthesis.

• A growing dependence on a few specialists who know the right pragmas, workarounds, and tuning tricks.

•  Small source changes create far larger downstream churn than expected. 

• Architectural exploration is slowing down because too much of the team is waiting on the tool instead of using the tool.

At that point, the issue is not simply runtime. It is program economics. Every extra loop taxes schedule, staffing, and organizational confidence.

Why this matters more now

Modern silicon programs are not getting simpler. They are becoming more data-intensive, more heterogeneous, and more schedule-sensitive. New accelerator blocks, changing memory assumptions, late architecture updates, and tighter power-performance targets all increase the number of design decisions teams need to evaluate before RTL hardens. If each iteration is slow, opaque, or dependent on tribal expertise, HLS stops feeling like leverage and becomes a bottleneck. The very abstraction layer that was supposed to accelerate design becomes another place where time disappears. That is why some engineering leaders are reevaluating their HLS stack with a much more practical lens: not feature breadth, but time-to-decision. Not abstract productivity claims, but whether the flow can keep up with modern architectural pressure.

What teams are really evaluating

When companies reopen the HLS conversation, the questions are usually more disciplined than emotional. They sound like this:

• How quickly can we get to a first analyzable result?

• How tightly does the output correlate to our downstream synthesis reality?

• Can RTL engineers work in the flow directly, or does it remain confined to a small HLS specialist group?

• How much manual tuning is still required before the design becomes trustworthy?

• If we compare one real HLS-generated block side by side with a conventionally created block, do runtime, predictability, and engineering effort materially improve?

Those are not theoretical questions. They are the questions teams ask when they are deciding whether HLS is compounding productivity or quietly consuming it.

Where Rise enters the picture

This is where Rise Design Automation becomes interesting. Rise complements existing HLS environments while also lowering the barrier for teams evaluating HLS for the first time. Many organizations that previously stayed with pure RTL workflows are now reconsidering whether higher abstraction can fit naturally into their existing engineering practices. Rise is aimed at teams that already understand the value of higher abstraction and now want a more scalable, synthesis-grade path forward. The practical appeal is straightforward: faster iteration, tighter correlation with downstream synthesis, support for high-level SystemVerilog so RTL teams can participate more directly, and a lower-friction evaluation model built around side-by-side comparison on an existing block. That framing matters. The strongest path to making the right decision is based on a controlled ROI question: if the same design and the same constraints can produce a faster, more predictable engineering loop, what is that worth to the program?

The Watchtower view

The first wave of HLS adoption rewarded possibility. The next wave will reward predictability, organizational scalability, and iteration economics. Not because the first generation of HLS failed. But because the standard for success has changed. In modern silicon programs, getting one win is not enough. The flow has to keep winning as complexity rises. This is why another parallel thread is emerging: engineering teams still committed to a traditional RTL flow are asking another question altogether: whether the time has finally come to introduce HLS into programs that historically stayed entirely in RTL. We will explore that question in a subsequent Watchtower blog. 

If your team is already using HLS and asking whether the iteration math still works, that is not a sign of dissatisfaction. It is a sign of maturity. And it may be exactly the right moment to measure the next alternative against the workload that matters most.

For more posts like this, go here: AI TechSales Blog AKA The Watchtower Brief