ASIP eUpdate, April 2019

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: Architectural Exploration

A key challenge for system-on-chip (SoC) designers is to introduce differentiating advantages within the target product's market window.  Designers therefore need to be able to rapidly explore the impact of architectural choices upon their ASIP, by doing three things:

 

1. Define benchmarks

Benchmarks must be representative of the end application, to enable a quantitative comparison of the architectures being considered. A benchmark must have:

  • A functional specification, describing the application kernels that need to be implemented. Benchmarks are usually represented in C for ease of implementation and architectural independence
  • An environment describing the stimuli that exercise the benchmark
  • Performance metrics such as power, performance, and target frequency

 

2. Describe a candidate architecture

Request: Designers need a quick and easy way to define a candidate architecture, ideally using a modelling approach that avoids specifying deep implementation details early in the design process.

Solution: In ASIP Designer, the ASIP is described using nML, a structured architecture description language that efficiently and concisely describes processor architectures at the same level of abstraction as a programmer’s manual. The language is used to define the structural characteristics of the design (registers, functional units, signals, etc.) and the instruction-set architecture. nML also enables users to describe the cycle- and bit-accurate behavior of the datapaths and I/O interfaces.

 

3. Explore the design space

Design exploration involves evaluating each candidate architecture against the defined benchmarks. There are two main steps to this, described below:

Compiler-in-the-loop

Request: Designers need to use a compiler to run benchmarks onto each candidate architecture, rather than trying to use time-consuming and error-prone assembly language. It’s also useful to have a cycle-accurate instruction set simulator (ISS) and a profiler to analyze results.

Solution: In ASIP Designer, an ASIP’s nML description is used as an input to the retargetable SDK, which automatically adapts to the defined processor architecture (step 1 in Figure 1). The SDK includes an optimized C/C++ compiler, assembler/disassembler, linker, cycle-accurate as well as instruction-accurate instruction-set simulator with powerful profiling capabilities, and graphical debugger.

It is possible for the compiler to adapt to the details of each candidate’s architecture because its compiler optimizations are implemented in a generic way. Other compiler frameworks, such as GNU’s GCC, need an architecture-specific compiler backend for each candidate. The immediate availability of a compiler is the key enabler for rapid architectural exploration and iteration.

Having a compiler in the loop also means software authors can provide feedback to the ASIP designer, and the processor’s dynamic performance can be studied and optimized (step 2 in Figure 1). Making these kinds of adaptations and trade-offs at this level of abstraction is much more efficient than trying to do it once an RTL description has been generated.

Synthesis-in-the-loop

Request: to avoid surprises late in the development process, it is desirable to quickly analyze the hardware cost and characteristics of a candidate architecture in terms of its operating frequency, area, and power efficiency.

Solution: ASIP Designer will translate the nML model into fully synthesizable Verilog or VHDL, with full cycle-accurate and bit-accurate control of the hardware (step 3 in Figure 1). Design and verification tools, such as Synopsys’ Design Compiler and VCS, can then be used to implement the ASIP. For example, Design Compiler can be used to check timing closure, and to generate a gate-level description that can be used to predict the circuit’s power requirement and area. Design Compiler will also provide insight into possible routing congestion that may be present in the design, but even a complete physical synthesis including place and route with IC Compiler is possible at strategic points during architectural exploration.

This “synthesis-in-the-loop” approach enables educated decisions and avoids surprises later in the design process. If there are problems with the design during implementation, developers can go back to the nML description and adjust it to address the issue (step 2 in Figure 1). Because of the single-source entry in nML, the SDK and RTL will remain in sync.

 

Figure 1: ASIP Designer tool flow

What’s New in ASIP Designer?

2019.03 Release Update

In March 2019, we launched the latest release of ASIP Designer, providing a number of enhancements and extensions. The following is an extract, sorted by categories (please refer to the official Release Notes for the comprehensive list).

Example Models

  • A new demo illustrating the integration of a vector processor into a SystemC based platform, featuring the TLM2 interface has been added. The example shows how ASIP models that often use word-enable with arbitrary word-size can be integrated with the standardized TLM2 interface, which only supports byte-enable in the transaction payload.

Processor Modeling

  • The PDG language that captures behavioral elements of the nML processor model now supports a more modular code style. Instead of only having a fixed set of process functions, it is now possible to define an arbitrary number of functions, which enhances readability and maintainability.

C/C++ Compiler

  • ASIP Designer’s C/C+ compiler features a language front-end taken from LLVM, extended to support the broad architectural scope of ASIPs.  The new release offers new extensions of the LLVM front-end, beyond the standard distribution, to increase the performance for DSP-centric code:
    • We generalized the support of the C restrict keyword. In DSP code, restrict is essential to express independent memory accesses, for example, to arrive at maximal software pipelining of loops. In the standard LLVM distribution, restrict has only minimal support, while this release implements restrict correctly for local pointer variables and for struct member pointers.
    •  We provided a set of new LLVM options, to optimize the interaction between the LLVM front end and ASIP Designer’s compiler back end for DSP centric code, containing nested loop kernels.
  • Software pipelining of (nested) loops has been further improved. New loop directives are available to adjust software pipelining of inner loops to improve the software pipelining result of the next loop level.

  • ASIP Designer’s C compiler supports aggressive scheduling. This means that instructions can be scheduled in parallel, in a way that exploits the exact pipeline stages in which data is produced and consumed, resulting in very compact schedules of non-interruptible code. The new release enhances this functionality, by allowing negative flow-dependencies in addition to negative anti-dependencies.

  • ASIP Designer’s compiler directives are now also available in the new C++11 attribute style, increasing portability of the application code.

  • The compiler’s LLVM-based front-end has been updated to the most recent LLVM version 8.0.

Simulation and Debugging

  • Automatic source code coverage during simulations has been added. Coverage results are reported both in text format (also as the accumulated result from multiple simulation sessions) and interactively in the GUI.

RTL Generation, Verification, and Synthesis Support

  • A new option in ASIP Designer’s RTL generator enables better control on the hierarchy of the generated RTL implementation.

Additional Resources

ASIP Designer Online Training

Online training is now available for ASIP Designer. Register for access to the training modules, which provide a deep dive into the concepts, languages, and files that are used to capture a processor design.

Customer References

“To meet our customer-specific requirements, we are developing specialized processors and programmable accelerators that are fully optimized for performance, power, area, and code size, while offering the required flexibility,” said Thierry Brouste, Manager, Embedded Computing Solutions, STMicroelectronics. “Using ASIP Designer as our tool of choice gives us a significant competitive advantage, because it enables us to quickly develop complex and highly differentiated application-specific processors, while maximizing our design team’s efficiency through design automation and architecture exploration.”

RIKEN’s drug discovery molecular simulation platform team utilizes leading computational technologies using large-scale, high-speed supercomputers, specifically for molecular simulation technologies. These molecular simulators are used to identify drug behavior at the atomic level and help predict what structural formulas make for highly effective and selective drug candidates. Molecular dynamics (MD) simulations are computationally intensive and need petaflops of processing performance. RIKEN recognized that a general-purpose processor would not deliver the required performance, and so they decided to develop their own specialized custom processor using Synopsys’ ASIP Designer tool, and integrated 17 instances of the processor in a custom multicore chip.

White Papers   

Over the past decade, the trend in SoC design has been to add more functionality into software. There are several reasons for this, including (a) software is easier and faster to fix and update, (b) evolving trends and not-yet fully specified standards require flexibility since the final functionality might not be known at the time the hardware design must be locked down, and (c) the desire to reuse SoCs for different products and derivatives, improving the return on investment (ROI) for a single design. Read the white paper to find out how ASIPs can contribute and what it takes to develop them.

In order to develop a proprietary processor that can stand the test of time, a highly functional SDK must be developed. The complexity, cost and duration of SDK development vary depending on the architecture of the processor and the skillset of the SDK developers. In this paper, we analyze the requirements for an SDK. We then introduce a tool-based methodology for SDK development based on Synopsys’ ASIP Designer tool suite.

Architectural exploration is at the heart of any ASIP design approach. Designers need to rapidly explore the impact of different architectural choices on power consumption and performance, ideally using real-world application C-code as part of the design flow. This white paper explains the architectural tradeoffs that are available to an ASIP designer, how to trade off performance vs. area, and why an ASIP design can still maintain full C-programmability while being optimized for a certain application domain.

For the SoC implementation of SDR baseband, most or all of the fixed-function logic blocks for physical layer processing are replaced by software running on processor(s). Heterogeneous multicore architectures are deemed better suited for SDR SoCs since they require less silicon area and consume less power.

Modern SoCs integrate dozens of complex system functions, each requiring its own optimal balance of performance, flexibility, energy consumption, communication, and design time. The traditional model of a (configurable) general-purpose processor core with a number of fixed hardware accelerators no longer suffices. ASIPs can offer the best balance for each system function, and thus form the basis of new generations of multicore SoCs.

More