Cloud native EDA tools & pre-optimized hardware platforms
This bi-annual newsletter provides you with easy access to ASIP related resources. This issue includes the following topics:
Using ASIP Designer™, designers can implement processor architectures tailored to application-specific requirements. For an ASIP to be accepted by embedded software users, it needs to be possible to program such specialized processors in C and C++ using a compiler. This obvious request represents a significant challenge, though, as the compiler needs to be adapted to the specialized architecture.
A compiler is typically composed of a frontend and a backend. The frontend reads in the high-level language, performs certain architecture-independent optimizations, and maps the information to an intermediate representation (IR). The backend transforms the IR into machine code. This involves resource and storage decisions, such as deciding which variables to fit into registers or memory, and which addressing modes to use, as well as the selection and scheduling of appropriate machine instructions.
Traditionally it is assumed that for every processor architecture, a different backend will be needed. An open-source compiler technology such as LLVM offers a framework to develop such custom backends. This might sound appealing in the first place, but the development remains a time consuming and tedious process that requires a lot of compiler design expertise. Once the backend becomes operational one may realize that the initial ASIP architecture wasn’t the right one, and a new alternative is to be explored, which triggers the need for a new or modified backend. The complexity in compiler backend design has long been the biggest hurdle to adopt an ASIP approach. Indeed, many ASIPs contain architectural features, like irregular register structures linked to irregular instruction-level parallelism, that require coupled and specialized register allocation and scheduling passes which are not readily available.
ASIP Designer overcomes this hurdle, by providing a unique retargetable backend, which reads in the specification of the processor architecture expressed in the nML processor description language, and automatically adapts itself to this model of the architecture. The details of this backend will be subject of a future article.
But what about the frontend? By definition it is not target-specific, so at first glance it should be possible to use popular open-source technology such as LLVM. The LLVM community has put a lot of effort into implementing the C/C++ frontend called Clang, offering full C++ language support and powerful high-level optimizations, representing hundreds of person years of compiler expertise. Taking a second look, however, the standard distribution of Clang is not sufficient for an ASIP approach. What is needed is an extension to the LLVM frontend, that keeps the benefits while still enabling the power of the specialization that goes into ASIP architectures.
Figure 1 shows the approach that Synopsys has chosen for the compiler in its ASIP Designer tool suite. The right-hand side of the figure shows the compiler flow, with its intermediate representations and the retargetable backend. The left-hand side of the figure zooms in on the frontend that supports C, C++ and OpenCL C. It combines ASIP Designer’s original language front-end that implements many powerful optimizations for signal processing applications, with a version of LLVM’s Clang extended to support ASIP architectures.
Figure 2: Architectural Options
1. Flexible Data Type Systems
The ability to define a data type system, combining data types and operations, tailored to the application, and tailored to the underlying processor architecture, is a key element of an ASIP design flow. A compiler frontend needs to implement these custom types and associated operations as efficiently as the C built-in types and operations.
Linked to byte-addressable memory spaces, the standard distribution of Clang assumes bit-widths for the C built-in types that are a power of two. In addition, the floating-point types are restricted to the IEEE floating point formats.
ASIP Designer extended the LLVM frontend such that the built-in integer types can have any width, and custom floating-point types can be defined, deviating from the standard exponent and mantissa widths. Use cases might be audio applications using 24-bit integers stored in 24-bit elementary memory fields, or AI applications where floating-point types with reduced bit width can be a key optimization.
ASIP Designer’s extended LLVM implementation automatically adapts to the data type system defined in the processor model, including fractional types, custom floating-point types, custom vector (SIMD) types where the element type can be integer/fractional/floating-point, but also more abstract application types such as pixels, RGB vectors, or voxels.
2. Memory Architecture
ASIPs allow for distributed registers, connected to specific functional units. Also, it is very common for an ASIP to have multiple memories and address spaces. These memories can have different properties, like a scalar byte-addressable memory combined with a vector memory, where the addressable units are complete vectors.
3. Frontend Infrastructure
ASIP Designer offers a light-weight version of the standard C++ library in the LLVM distribution, called libc++lite, tuned to embedded applications, offering most of the C++ library functionality while avoiding the code bloat in the standard version. Notwithstanding all the extensions described above, ASIP Designer’s extended LLVM frontend follows the latest LLVM standard distribution. With the 2020.03 release of ASIP Designer, the extended LLVM frontend is built on top of LLVM release 10. This way users can be sure to have the best of both worlds, the latest enhancements that go into the standard LLVM distribution, combined with ASIP Designer’s powerful extensions that make it applicable for an ASIP design flow.
2020.03 Release Update
In March 2020, we launched the latest release of ASIP Designer, providing various enhancements and extensions. The following is an extract, sorted by categories (please refer to the official Release Notes for the comprehensive list).
Each of these four models can optionally be extended with RISC-V ISA compliant compressed instructions, zero-overhead hardware loops and indirect addressing modes with post-modification.
As with all example models, these come in nML source code and can be modified by the user. They serve both as a reference to explain how certain processor features can be modeled in nML, as well as a starting point for customer-specific modifications and extensions.
Simulation and Debugging
RTL Generation, Verification, and Synthesis Support
Online training for ASIP Designer has seen strong adoption by new users. Additional recordings have been added. Register here 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.
Designing Application-Specific Processors for Smart Vision Systems: A High-Performance SLAM Case Study
Depth-sensing camera technology is literally adding a new dimension to the world of computer vision. Affordable high-resolution depth-sensing cameras will change the way we interact with our mobile devices, enable augmented reality in visual communication and gaming, and lead to the deployment of intelligent robots and drones in daily life. To make such camera systems future-proof, while keeping the system cost low, the sensor outputs need to be processed close to the image sensor under software control.
Application-specific instruction-set processors (ASIPs) are an ideal technology to add intelligent processing to such sensor systems, at the lowest power and cost. Synopsys' ASIP Designer tool suite enables system and chip designers to create their own ASIP in a short time, with the exact forms of parallelism and specialization required by their applications.
This webinar will show how the ASIP Designer tool suite was used to design an ASIP for a dense grid-based Simultaneous Localization And Mapping (SLAM) algorithm, for 3D reconstruction of dynamic environments from depth-sensing camera images. The ASIP, of which the architecture was designed in four person-months, is estimated to consume 4 orders of magnitude less power than a conventional GPU solution, in a fraction of the silicon area.
“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.
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.