ASIP eUpdate August 2025

<p>Synopsys’ solution to efficiently design and implement your own application-specific instruction-set processor (ASIP) when you can’t find suitable processor IP, or when hardware implementations require more flexibility.</p><p>This bi-annual newsletter provides you with easy access to ASIP-related resources.</p>

ASIP Designer

Synopsys’ solution to efficiently design and implement your own application-specific instruction-set processor (ASIP) when you can’t find suitable processor IP, or when hardware implementations require more flexibility.

This bi-annual newsletter provides you with easy access to ASIP-related resources. This issue includes the following topics:


Technology Feature: Hardware Tracing

Hardware tracing provides detailed visibility into the processor’s execution for debugging and performance analysis. The ability to trace the execution at the hardware level enables developers to obtain insights into the behavior of the software running on the processor in real time. Compared to debugging, hardware tracing provides a non-intrusive way to monitor the system. Hardware tracing can therefore be used in situations where it is difficult to reproduce error conditions. The trace data can then be used to run a post-mortem analysis of error causes or of the application’s performance.

When running an application on the hardware in real time, hardware tracing may generate a lot of data. The tracing infrastructure, on the other hand, is limited by the available resources on the chip. To manage the large amount of data, hardware tracing needs to be configurable at several levels:

  1. Application Knowledge. Enable/disable tracing in the application to generate trace data only for certain program parts of interest.
  2. Data Filtering. Configure triggers and filters to capture only specific events or data ranges.
  3. Data Compression. Apply data compression techniques to reduce the size of the trace data.
  4. Packet Encoding. Use efficient packet encoding schemes to minimize the amount of trace data.

ASIP Designer provides the tools to design a tailor-made tracing hardware solution for your custom processor, and to analyze these traces in the ASIP Designer debugger with its profiling capabilities. The tools provide out-of-the box examples as well as support to configure custom trace encoding and decoding and to implement specific tracing optimizations.

ASIP Designer Hardware Tracing Solution Overview

Figure 1: ASIP Designer Hardware Tracing Solution Overview

Figure 1 shows an overview of the ASIP Designer hardware tracing solution. On the hardware side, the processor model is extended with interfaces to support sending raw trace events, including information about executed instructions or data that has been accessed. These raw trace events are compressed and encoded in serializable trace packets. The trace packets are sent to an ATB trace infrastructure in the system. The generated trace packets then can be read out by the host using an appropriate trace probe. On the software side, a trace decoder processes these packets to extract meaningful information for analysis, using the reverse encoding algorithm to reconstruct the original execution flow. The reconstructed execution flow can be inspected in ASIP Designer’s debugger with its rich set of analysis and profiling capabilities.

In the diagram, all blocks highlighted in purple are generated or provided by the ASIP tool, all turquoise blocks are user designed in the ASIP Designer framework. Only the ATB infrastructure and the probe need to be provided externally, allowing it to be shared with other (non-ASIP) cores in the system.

The following sections elaborate the hardware and software aspects of this framework in a bit more detail.

Hardware Components

Figure 2 shows the hardware modules of the hardware tracing solution as they are integrated with the ASIP itself, and the data representation at different stages.

Hardware components of the ASIP tracing solution

Figure 2: Hardware components of the ASIP tracing solution

The Processor Trace Interface is composed of the Instruction Trace Interface and an optional Data Trace Interface. The Instruction Trace Interface determines which instructions must be traced, typically all conditional and control instructions that are not inferable from the application image. A Data Trace Interface is required if information about accesses  to memories or registers, that is, accesses to certain application variables, need to be traced.

The Trace Control Interface implements triggers and filters to allow the user to selectively trace certain instructions or data regions, and it synchronizes the Trace Encoder and the Trace Generator.

The Trace Encoder compresses the raw tracing data into a more efficient format, for example, by caching addresses, using incremental addresses and cycle counts, and efficient encoding. It takes into account the filtering constraints from the Trace Control Interface.

The Trace Generator controls and interfaces with the trace encoder, converting its sparse tracing packets to densely packed, ATB compliant packets.

An optional Trace CDC Buffer can smoothen out large bursts of trace data and connect to a different clock domain of the ATB interface.

While the Trace Interfaces and the Trace Encoder are modeled in PDG, the Trace Generator and the Trace CDC Buffer are generated by the Go RTL Generator. A subtle detail of Figure 2 is that the blocks with sharp edges represent modules that are modeled as I/O interfaces.

This partitioning of the components allows re-use of the submodules in various processors. It also supports the use of third-party implementations of one or more of the components.

Software Components

As shown in Figure 1, the trace encoder hardware is complemented with a user-supplied software decoder which can reconstruct the entire program flow from the encoded trace. This software is split up into two components.

The Trace Decoder decodes the binary trace packets, taking into account all optimizations that have been implemented to compress the output format.

The Trace Reconstruction API is used to convert the decoded packets into corresponding simulation events that can be processed by the debugger.

User control, Visualization and Analysis

Figure 3 shows how hardware tracing is controlled, visualized and analyzed in the ChessDE debugger.

As the trace controller is configured using memory mapped registers, hardware tracing can be controlled and configured from within the application code by accessing the appropriate memory domains. Alternatively, it can be controlled by the debug client using OCD commands.

After reading in the generated trace, the program flow is reconstructed and based on this, function and instruction profiling reports can be generated, and the program can even be replayed by using reverse debugging. If data tracing is supported by the trace encoder and decoder, also storage accesses can be inspected. By selecting filters to trace certain parts of the memory, important variables can then be traced and debugged.

Hardware Tracing in the ChessDE Debugger

Figure 3: Hardware Tracing in the ChessDE Debugger

Examples and More Information

More details about ASIP Designer’s hardware tracing support can be found in a new “Hardware Tracing Manual” that has been added to the tool documentation.

The functionality related to hardware tracing requires a license for the ASIP Designer Tracing Add-On product.

For licensees  of the ASIP Designer Tracing Add-On product, all user defined blocks of the ASIP Designer hardware tracing solution come with ready-to-go examples in the example models library that is shipped along with the tool, which are available in source code and fully customizable.

What’s New: ASIP Designer X-2025.06 Release

Since the last edition of this newsletter, we have launched a new feature release for ASIP Designer in June 2025, offering various enhancements and extensions. Below is a categorized summary of these updates (ASIP Designer customers can refer to the official Release Notes for a comprehensive list of details). 

Click on each tab for additional information about that new feature

Example Processor Models

The following updates have been made to the library of example processor models: 

  • The Trv (RISC-V ISA) educational models have been extended with:
    • An example showing code patching of ROM code
    • Examples demonstrating the acceleration of FFT, secure hashing, and keyword spotting, by adding custom instructions to a RISC-V base model.
  • A loop-peeling tutorial has been added, demonstrating advanced C++ template programming to peel the initial or final iterations from a loop, with guaranteed optimization of the conditions that become manifest after the loop peeling.

Processor Modeling

  • Support for structs in the PDG language has been finalized, including struct register expansion and direct access to struct members in RTL. 
  • Support to use a single unified chess_rewrite rule for several application types represented by the same primitive type.

C/C++ Compiler

  • Safe interaction between aggressive scheduling and multi-cycle functional unit operations.
  • Support for a response file option (@file) in chesscc (for example, useful for CMake integration on Windows).
  • Improved compilation results in the LLVM flow for control code resulting from short-circuit evaluation, by a more efficient representation for the Chess backend.
  • More aggressive interpretation of the duplicate-at-use and keep-with-operand operation properties to better interact with the LLVM optimizations.
  • The Chess LLVM front-end switches to LLVM version 20.0.
  • The LLVM library stacks switch to version 20.0.

ChessDE GUI, Instruction-Set Simulation and Debugging

 
  • The NI (No Interface) simulation mode, which was introduced in Release W-2024.12, has been extended with block-level JIT.
  • Support for the DWARF-5 debug format.
  • Improved support for real-time hardware tracing in on-chip debugging, including E-trace encoding. For more details, refer to Section “Technology Feature:  Hardware Tracing” above.

RTL Generation, Verification, and Synthesis Support

  • Support for synthesizable SystemVerilog features in RTL output.
  • Formal ISA Verification, which was introduced in Release V-2023.12 as part of the Advanced Verification Add-On product, now includes improved model checking with VC Formal FPV, and support for the VC Formal apps FTA, SEQ, FCA/UNR, and DPV.

 

Additional Resources

Training and Tutorial Videos


Events and Webinars


White Papers and Articles