1.3 What’s New in SmartHLS™ 2025.2

Release Date: December 2025

Software Features and Enhancements

Enhanced Diagnostic Reporting and Message Documentation

We are transiting to a new diagnostic reporting system designated to streamline troubleshooting for users.
As we move to this new messaging system, messages displayed in the updated format will include a unique identifier, enabling users to reference and resolve issues more efficiently.
For example, this is an example of a new formatted message with ID 'SHLS-23'.
```
Info:    (SHLS-23) Partitioning memory 'x' on line 9 of dut.cpp into 10 partitions.
```
The user guide now includes a dedicated Errors and Warnings, which documents selected new messages. This section is intended to help users understand the underlying causes of each message and assist in identifying potential issues within their input design and configuration.
Users can easily search for information about specific messages using the provided message ID.
We will continue rolling out this format for more messages in future releases, further improving support and clarify for users.

New Usage Rule for Top-level Functions

Top-level functions must not be called from hardware design code. Any invocation of a top-level function must originate from software testbench code.
A strategy for porting code that violates this new rule is provided in section SHLS-82.

Improved Type Casting Support

C-style casting from SmartHLS arbitrary precision fixed-point data types (hls::ap_{u}fixpt) to C primitive float and double data types is now supported, providing a more intuitive user experience.
This update deprecates the to_double() member function for hls::ap_{u}fixpt data types, which is more commonly utilized in software testbench code than in hardware design code.

For example, code fragment that was written as:

bool check( hls::ap_ufixpt<8, 4> v ) {
    return v.to_double() == 12.75;
}

can now be rewritten as:

bool check( hls::ap_ufixpt<8, 4> v ) {
    return (double)v == 12.75;
}

Changes and Deprecation

In the <Libero_SoC_Installation>/SmartHLS/SmartHLS/examples directory, the legup.tcl file has been renamed to shls.tcl. However, both filenames remain valid in this release.
The configuration input file specification tag, -legup-config, commonly used in HLS Makefile, has been renamed to -shls-config. However, both tags are supported in this release.
In your old HLS Makefile, please update:
```
LOCAL_CONFIG = -legup-config=<PATH_TO_HLS_CONFIG_FILE>
```
to:
```
LOCAL_CONFIG = -shls-config=<PATH_TO_HLS_CONFIG_FILE>
```
Including Makefile.common is no longer required in the HLS Makefile. Please remove any references to Makefile.common from your existing Makefile. Typically, this inclusion appears as follows:
```
LEVEL = $(SHLS_ROOT_DIR)/examples
include $(LEVEL)/Makefile.common
```

Fixed co-simulation bug on function pipelined HLS cores.
Fixed crash that occurred when the user's requested loop pipelined initiation interval (II) exceeded the maximum total pipeline latency.
Fixed crash resulting from dataflow sub-functions accessing aliased RAMs.
Fixed crash associated with a specific nested call pattern in thread functions.
Fixed incorrect design output caused by typecasting of global array pointers that represent in-core local storage.
Fixed 2 issues in auto-instrumentation: one that caused the 'can't read "merged_file": no such variable' error message, and another that led to missing clken signals.
Fixed a bug in logic_level_histogram related to incorrect handling of the single logic level scenario.
Fixed a script driver issue that caused certain simulations using the HLS core VHDL wrapper to fail on Windows platforms.
Fixed an interface report generation problem where an incorrect report was produced if a top-level function contained a memory interface with the same name as the scalar input of another top-level function.