HLS Synthesis Subset API and Portability Field Guide

How to Read This Lesson

SystemC for simulation and SystemC for synthesis are related, but not identical. Simulation asks, "does this C++ model behave correctly under the SystemC kernel?" Synthesis asks, "can a tool infer stable hardware from this subset?"

Standard and source context

Use Docs/LRMs/SystemC_Synthesis_Subset_1_4_7.pdf. For implementation context, also keep the core datatype and process lessons nearby because synthesis tools still rely on the public SystemC API shape.

Process Subset

SC_METHOD, SC_THREAD, and SC_CTHREAD are all legal SystemC concepts, but synthesis tools usually prefer clocked, statically analyzable structure. SC_CTHREAD, wait, reset_signal_is, and async_reset_signal_is are common in HLS-style examples because the clock boundary is visible.

Use static sensitivity for combinational SC_METHOD blocks. Use clocked threads or cthreads for state. Avoid dynamic process creation in synthesizable blocks.

Ports and Hardware Boundaries

sc_in, sc_out, sc_inout, sc_signal, sc_clock, sc_in_resolved, sc_out_resolved, sc_in_rv, sc_out_rv, and related port names describe hardware boundaries.

For synthesis, ports are contracts. A port is not just a convenient way to pass a C++ value; it implies direction, timing, and possible hardware interface shape.

Datatype Subset

sc_uint, sc_int, sc_biguint, sc_bigint, sc_signed, sc_unsigned, sc_fixed, sc_ufixed, sc_fix, sc_ufix, sc_lv, sc_bv, sc_lv_base, sc_bit, and sc_logic give you bit width, signedness, four-state logic, or fixed-point behavior.

The synthesis subset also talks about sc_signals as a family concept, not only one class name. Read it as the signal/channel boundary where hardware-like communication becomes visible to the tool.

The trap is performance and portability. A bit-accurate type is the right choice when the hardware contract needs bit accuracy. It is not automatically the right choice for high-level algorithm exploration.

Bit Select, Range, and Concatenation Names

sc_bitref_r, sc_concatref, sc_concref, sc_concref_r, sc_int_bitref, sc_int_bitref_r, sc_uint_bitref_r, sc_signed_bitref_r, sc_signed_subref, sc_signed_subref_r, sc_unsigned_subref, and sc_unsigned_subref_r are the proxy names behind bit selects, ranges, and concatenations.

sc_unsigned_bitref_r is the read-side unsigned bit-reference variant. It is the sort of helper that appears when a synthesizable expression selects or forwards a single bit from a wider unsigned value.

These are useful because hardware code often manipulates slices. They are also a reminder that C++ syntax may expand into library proxy objects. Keep expressions simple when synthesis readability matters.

Fixed-Point Policy Names

sc_fxcast_switch, sc_fxnum_bitref, sc_fxnum_subref, sc_fixnum, sc_numrep, and fixed-point quantization/overflow policy names belong to numeric control.

When reviewing HLS code, ask whether the numeric policy is an engineering decision or an accidental default. Bit width, quantization, saturation, and rounding should be written down.

Trace and Non-Synthesis Names

sc_close_wif_trace_file, sc_close_isdb_trace_file, and tracing APIs are simulation/debug aids. They are useful in testbenches but should not be mistaken for synthesizable hardware.

Likewise, dynamic allocation, unbounded loops, host I/O, file access, unrestricted pointers, and data-dependent recursion are usually outside a practical synthesis subset.

Senior Review Checklist

• Is every hardware state update clocked?
• Are resets explicit and tool-supported?
• Are loops bounded or intentionally pipelined?
• Are bit widths and fixed-point policies documented?
• Is TLM isolated from synthesizable datapath code?