Might of Design Exploration: Deep Dive of Exploration Techniques in Stratus HLS

Stratus HLS's behavioral design methodology enables easy exploration of multiple algorithms and architectures to achieve better trade-offs among area, power, and latency requirements.

In this blog, we'll delve into the various exploration techniques that Stratus HLS provides and how they can revolutionize your design process.

Understanding Exploration Techniques

Exploration techniques in Stratus HLS primarily focus on evaluating microarchitecture decisions as the design evolves, considering trade-offs to produce different solutions. Stratus HLS determines the behavior of a synthesized design from the SystemC source, but there are many ways to transform the same SystemC into RTL. 

Microarchitecture control is how you influence that transformation without changing the source code.

The microarchitecture is controlled by three mechanisms, which can be used independently or together:

1. Synthesis control attributes
2. Synthesis directives and Tcl commands
3. Active module parameters
4. A fourth dimension is configurable I/O interfaces that are managed separately through io_config and the generated Interface library, and controls what the module's ports look like at each abstraction level. A configurable system model enables trade-offs between protocols and data types without modifying the core design.

Let us further explore how to apply these mechanisms.

Synthesis Control Attributes

Synthesis control attributes affect synthesis decisions globally or individually for each hls_config. As tabulated here, there are three different ways to set the synthesis attributes:

Any typical exploration pattern defines a family of configs, then differentiates them. The most frequently used configs are, hls_config, sim_config, analysis_config, cov_config, equiv_config, io_config, logic_synthesis_config, power_config, sim_config, system_config.

These basic setup parameters help in exploring how timing, pipelining, and memory organization interact to shape the final RTL architecture.

• Setting the stage for the HLS: The synthesis setup begins by defining a clock period and a default input delay, thereby establishing the effective timing budget available for internal scheduling and datapath generation.
  • set_attr clock_period 5 
  • set_attr default_input_delay 1.5

• Defining multiple HLS configurations for exploration: This is a classic design-space exploration setup: same functionality, different synthesis strategies. To explore multiple implementation styles of the same design, in this example, four HLS configurations — BASIC1, FLATTEN, UNROLL, and DPOPT are created.
  • define_hls_config dut BASIC
  • define_hls_config dut FLATTEN -- flatten_arrays=all
  • define_hls_config dut UNROLL -- unroll_loops=on
  • define_hls_config dut DPOPT -- dpopt_auto=all

• Other attributes: Multiple such attributes are available in a structured manner to tune the design for better and a balanced tradeoff between area, performance, and timing closure
  • set_attr flatten_arrays all [find -hls_config FLATTEN*]
  • set_attr cycle_slack 2 [find -hls_config *]

The clock period is a primary timing knob used to define the target cycle time for scheduling and datapath synthesis. To go beyond the basic clock setting, Stratus provides additional tuning knobs. These parameters determine how aggressively your logic can be packed, and this flexibility enables you to make your design more or less aggressive in packing logic into clock cycles, ultimately impacting latency, timing closure, and a balanced QoR.

• cycle_slack: Specifies an amount of time in each clock period that is to be reserved for use by downstream tools.
• path_delay_limit: Specifies a variable upper bound of the allowable length of timing paths, true or false, in your design

Here is the differentiation of a design with the application of slack or no slack:

When timing cannot be met, Stratus HLS reports scheduling failures, Loop Carried Dependency [LCD] violations, and resource conflicts. By setting latency constraints, you can explore the impact of different latency values on your design's performance and area. It is important to note that the latency constraints are a major cause of scheduling failure.

Common causes include data dependencies, insufficient operator timing, conflicting protocol boundaries, resource conflicts, and incompatible loop-carried dependencies. When this occurs, Stratus HLS reports minimum achievable latency, and error diagnostics identify blocking constraints. Latency constraints in Stratus HLS specify the maximum number of cycles a region is allowed to consume, guiding the scheduler’s trade-offs among parallelism, resource usage, and performance.

In summary,

• Tighter latency ⇒ More parallel hardware, less sharing.
• Looser latency ⇒ Serialized execution, reduced area.

Synthesis Directives and Tcl Commands

Directives and Tcl commands target specific objects in the source: loops, arrays, regions, and ports. They are the mechanism for fine-grained microarchitecture control. In HLS, elaboration is the stage where the design hierarchy, loops, variables, interfaces, and internal structures are fully understood by the tool. 

When to use:

1. Use synthesis directives when you are working with the source code. Let us see an illustration of the usage as a source directive in the code.

   while (1){

   HLS_PIPELINE_LOOP (HARD_STALL, 1, "MAIN_LOOP");

   vin = din.get();

   vout = f( vin );

   dout.put( vout ); }

2. Use Tcl commands, when keeping synthesis policy separate from behavioral specification, or when you need to vary the policy per hls_config. 

             In the project file:

             define_post_elab_tcl {

pipeline_loops -type HARD_STALL -initiation_interval 1 [find -loop MAIN_LOOP] }

             In the source code:

MAIN_LOOP: while (1){

vin=din.get(); vout=f(vin); dout.put(vout);}

Several synthesis directives and their equivalent TCL commands are available. You can refer to the HLS reference guide for further information on these.

The table lists several key directives and their microarchitectural effects.

Configurable I/O Interfaces

In High-Level Synthesis, your algorithm stays the same, but the way it talks to the outside world is completely configurable. Configurable I/O interfaces are managed separately from the microarchitecture controls above.

If you need,

• Low latency? Use direct IO.
• Safe communication? Add a handshake.
• Processing large data? Go memory or streaming.

This means the same design can plug into completely different systems just by changing the interface configuration. You can control the abstraction level and protocol of the module's ports without changing the DUT or testbench code.

Stratus HLS introduces the following interface types to optimize your design.

• An ‘io_config’ to control which ports and channels are used to connect modules in the system.
• There are predefined i/o configs:
  • PIN Level: Pin-accurate protocol; synthesizable; cycle-accurate
  • TLM: Transaction-level modeling; loosely timed; faster simulation
• An interface generator (bdw_ifgen) that produces C++ interface classes from interface definitions (.bdl files).

How to Use Compile-Time Configuration and Abstraction to Make a SystemC Design Adaptable Across Multiple Data Types

In SystemC-based HLS flows, developers often work with multiple numeric types such as sc_int, sc_bigint, and ac_int. Each has different precision capabilities, performance implications, and synthesis characteristics. Without abstraction, switching between these types means rewriting large portions of code.

Data types in the source code - defines.h;

Data types in the source code - file.h;

Data types in the source code - file.cpp

The image depicts the way of configuring the design interfaces for the above-defined data types

Exploring Using Pipelining Constraints

Pipelining constraints are one of the primary exploration axes in Stratus HLS because they directly trade off throughput vs. area, latency, resource sharing, and clock frequency feasibility. Through pipelining, Stratus HLS allows designers to generate multiple microarchitectures from the same source code, where a single untimed algorithm can yield multiple microarchitectures, each with vastly different performance and cost, simply by tuning pipelining.

What Do the Pipelining Constraints Help Resolve?

When pipeline constraints are applied, Stratus HLS may report that a requested initiation interval is not achievable, that Loop-carried dependencies prevent pipelining, or that resource or memory conflicts stall the pipeline.

These reports help identify and, in turn, resolve:

• Algorithmic bottlenecks
• Refine pipeline constraints
• Adjust loop structure or memory layout

Applying pipelining constraints transforms sequential algorithms into high-performance hardware pipelines while allowing designers to navigate a wide design space using Initiation Interval, Stall modes, as prime parameters.

The image indicates the area numbers for different configurations.

Active Module Parameters

Active module parameters are a configuration-level abstraction. It does not require any Tcl scripts or source directives. Internally, these parameters translate into synthesis directives at post-elaboration. For training and design-space exploration, Active Module Parameters are particularly valuable because they let you create configuration variants, all without touching the source code.

Active module parameters are specified in define_hls_config using forms such as:

• -parameter = value
• -parameter:object = value

 These parameters execute Tcl bodies that generate the underlying Stratus directives automatically. Example usage of the parameters is as shown:

• define_hls_config mymod CFG1 -main_latency=10
• define_hls_config mymod CFG2 -pipeline_loop:my_loop=1

Here is the table listing the parameters that allow you to steer the micro‑architecture without rewriting the source code — shifting your role from coder → architect.

Stratus HLS Integrates with Cerebrus for Automated Exploration

Cadence Cerebrus is a design optimization tool that applies machine learning (ML) to achieve optimal PPA. When applied to Stratus HLS, the goal is to produce the optimal RTL from a behavioral model rather than to optimize a fixed RTL. The Stratus-Cerebrus integration automates exploration and guides it with ML to converge on an optimal result.

Cerebrus is configured with a set of primitives that define the space to be explored and a cost function that determines how PPA will be evaluated. Based on the metrics and primitives set for those scenarios, Cerebrus learns which primitives move the results closer to an optimal target. Cerebrus further explores the values of the enabled primitives and seeks the set that yields the best PPA. Stratus HLS provides utilities for specifying project primitives.

The image illustrates the power of using Cerebrus to explore a design.

How Is HLS Design Space Exploration Performed with Cerebrus Primitives?

HLS is not just about writing SystemC code, but about exploring architectural choices intelligently. And Cerebrus is used in Stratus HLS to accelerate the production of the optimal RTL, rather than to optimize a particular RTL. The flow begins with an hls_config that successfully produces RTL, but that does not yet yield optimal PPA. Here are the key advantages of using Cerebrus for exploration:

• No code changes required
  • All design exploration is controlled externally via Cerebrus scripts
  • The original SystemC/HLS design remains untouched
• Exploration-driven optimization
  • Each setup defines a search space of architectural and synthesis choices
  • Includes constraints and goals for PPA evaluation
• Automated iterative flow
  • Cerebrus repeatedly runs the Stratus HLS synthesis flow
  • Automatically adjusts configurations between runs to explore better solutions
• Scenario-based exploration
  • Each combination of settings creates a unique design scenario
  • These scenarios are stored as hls_configs in the Stratus database
• Seamless integration with Stratus
  • Generated scenarios behave like standard HLS configurations
  • Can be further analyzed using the Stratus IDE
• Real-time tracking and analysis
  • Cerebrus UI provides visibility into:
    • Exploration progress
    • Scenario completion status
    • Comparative evaluation of results

This image illustrates the typical inputs known as primitives in Cerebrus. The details defined by the "max_scenarios" option in the init_cerebrus script help in exploring the design, including the other parameters.

This is design space exploration for multiple combinations of timing constraints, scheduling strategies, and resource optimizations automatically explored by Cerebrus. Instead of manual tuning, exploration is automated, and the design space is covered efficiently, leading to faster identification of optimal architecture.

This image depicts the five design exploration scenarios (scenario_1 → scenario_5) evaluated against a base configuration.

Cerebrus rapidly explores multiple HLS optimization strategies and automatically converges on configurations delivering ~25% better QoR without increasing runtime.

The images show the results indicating the best design, enabling optimal tradeoff decisions

Conclusion

Stratus HLS is a game-changer in the world of digital design. The exploration techniques provide unparalleled flexibility and control, allowing you to optimize your designs for area, performance, and power. Exploration is achieved by defining multiple hls_config and systematically varying synthesis attributes, directives, scheduling contexts, datapath partitions, interfaces, and parameters, manually or via Cerebrus, to analyze and compare QoR trade-offs.

Explore deeper insights into Stratus HLS and digital design methodologies:

Stratus HLS - Digital Design - Cadence Blogs - Cadence Community

Enhance your expertise through the following relevant training:

SystemC for High-Level Synthesis Training Course

Stratus-HLS Basic Training

Cadence Cerebrus Intelligent Chip Explorer

What is Accelerated learning? Take the Accelerated Way.

The faster you finish your online training, the sooner you can claim your Digital Badge. Want to know how accelerated learning works? Our video walks you through the pre-quiz, navigation, and essential features. We're regularly adding new Accelerated Learning titles.

Accelerated Learning courses are marked with this symbol   in our Learning Maps.