Source-linked AI summary
Agile SoC Development with Open ESP
Paolo Mantovani, Davide Giri, Giuseppe Di Guglielmo, Luca Piccolboni, Joseph Zuckerman, Emilio G. Cota, Michele Petracca, Christian Pilato, Luca P. Carloni
TL;DR
As heterogeneous SoCs increasingly rely on specialized accelerators, open-source efforts have offered less support for large designs with loosely coupled components. ESP combines a modular architecture with flexible design flows, and its agile flow has rapidly prototyped complex SoCs on FPGA.
Problem
Open-source efforts have offered less support for large SoCs combining RISC-V cores with many loosely coupled accelerators connected by a NoC.
Source: §1 · p. 2Method
Results
The agile ESP flow rapidly prototyped many complex SoCs on FPGA, including computer-vision accelerator, Linux SMP, and NVDLA-based systems.
Source: §4.3 · p. 8Takeaways & Limitations
ESP supports open-source SoC development with a flexible methodology for integrating heterogeneous components into scalable architectures.
Source: §6 · p. 8NoC topology customization is not automated, so architects must modify router instances and header-flit generation logic to explore alternatives.
Source: §2.1 · p. 2
Abstract
from arXiv · showhide
ESP is an open-source research platform for heterogeneous SoC design. The platform combines a modular tile-based architecture with a variety of application-oriented flows for the design and optimization of accelerators. The ESP architecture is highly scalable and strikes a balance between regularity and specialization. The companion methodology raises the level of abstraction to system-level design and enables an automated flow from software and hardware development to full-system prototyping on FPGA. For application developers, ESP offers domain-specific automated solutions to synthesize new accelerators for their software and to map complex workloads onto the SoC architecture. For hardware engineers, ESP offers automated solutions to integrate their accelerator designs into the complete SoC. Conceived as a heterogeneous integration platform and tested through years of teaching at Columbia University, ESP supports the open-source hardware community by providing a flexible platform for agile SoC development.
1 INTRODUCTION
ESP is an open-source platform for heterogeneous SoC design, motivated by the growing use of specialized accelerators. Its flexible design flows target a gap in open-source support for large SoCs with loosely coupled components.
1 INTRODUCTION
- Specialized accelerators are increasingly used for energy-efficient performance across heterogeneous systems, from embedded devices to data centers.The cited application areas include mobile electronics, automotive, language processing, and graph analytics.Source: §1 · p. 1
- ESP supports accelerator creation through diverse design flows and languages, then integrates the resulting components into its tile-based SoC architecture.Supported options include HLS, machine-learning frameworks, and RTL languages.Source: §1 · p. 1
- ESP automates Linux device drivers and parameterized NoC generation, while platform services support accelerator configuration, memory management, and DVFS.The NoC can accommodate many processors, tens of accelerators, and distributed memory.Source: §1 · p. 1
- ESP's open-source release targets a gap: few efforts address large SoCs combining RISC-V cores with many loosely coupled accelerators connected by a NoC.Earlier OSH work had focused mainly on processor cores and small SoCs with tightly coupled units.Source: §1 · p. 2
2 THE ESP ARCHITECTURE
ESP combines a heterogeneous tile-grid architecture with modular sockets that separate tile design from system integration. Its platform services support scalable interconnect, memory and accelerator integration across processor, memory, accelerator and auxiliary tiles.
2 THE ESP ARCHITECTURE
- Tiles combine a heterogeneous grid with modular sockets that decouple tile design from system integration and support IP reuse.The architecture is system-centric, gives processors and accelerators equal importance, and allows services to be selected at design time and reconfigured at runtime.Source: §2 · p. 2
2.1 System Interconnect
- The six-plane NoC uses paired proxies to route master requests to remote slaves; its topology is not yet customizable through the automated integration flow.Multiple planes support protocol-deadlock prevention and bandwidth for cache-coherence, DMA and short-message traffic.Source: §2.1 · p. 2
- ESP architects may explore alternative NoC topologies, but must modify router instances and packet-header generation logic themselves.These topology changes are not automated in the current SoC integration flow.Source: §2.1 · p. 2
2.2 Processor Tile
- Processor tiles can use either supported core, both of which run Linux without ESP-specific boot patches, and provide a configurable private L2 cache.The processor socket implements directory-based MESI coherence and forwards memory-mapped I/O requests to the IO/IRQ NoC plane.Source: §2.2 · pp. 2–3
2.3 Memory Tile
- Memory tiles connect to external DRAM, automatically partition addressable memory transparently to software, and provide configurable LLC partitions with directories.The LLC supports Linux symmetric multiprocessing and runtime-reconfigurable accelerator coherence.Source: §2.3 · p. 3
2.4 Accelerator Tile
- Accelerator sockets provide configuration, address translation and coherence services, and enable direct point-to-point data exchange between accelerator tiles.Third-party accelerators can use services for interrupts, configuration and DMA, but must manage shared resources and implement their own hardware-software synchronization.Source: §2.4 · p. 3
- ESP supports non-coherent DMA, fully coherent access, LLC-coherent DMA and coherent DMA; software must acquire locks and flush private caches for non-coherent and LLC-coherent modes.Fully coherent and coherent DMA are handled in hardware by the ESP cache hierarchy.Source: §2.4 · pp. 3–4
2.5 Auxiliary Tile
- The auxiliary tile hosts shared peripherals and system utilities, while its socket provides proxies for their services and a local shortcut between otherwise disconnected masters and slaves.The frame buffer supports processor and accelerator writes through memory-mapped I/O and non-coherent DMA paths.Source: §2.5 · p. 4
3 THE ESP SOFTWARE STACK
ESP’s software stack lets applications invoke accelerators through a lightweight API backed by automatically generated Linux device drivers. Its memory allocation and sharing support allows accelerator and processor data to be shared without copies.
3 THE ESP SOFTWARE STACK
- A single esp_run() call can replace a computationally intensive software kernel with accelerator execution configured through a data structure.The API exposes three functions and delegates invocation to automatically generated Linux device drivers.Source: §3 · p. 4
- The API can target existing applications or a compiler, making accelerator invocation transparent to application programmers.Figure 4 illustrates an application with four kernels, two in software and two implemented with accelerators.Source: §3 · p. 4, Figure 4 · p. 4
- ESP’s esp_alloc() and esp_free() support data sharing between accelerators and processors without copies.Allocation is designed to improve accelerator memory access without compromising software performance.Source: §3 · p. 4
4 THE ESP METHODOLOGY
ESP's flexible, largely automated methodology separates accelerator-IP creation from SoC integration and supports multiple specification languages and synthesis flows.
4.1 Accelerator Flow
- ESP supports HLS design exploration through templates, skeletons, tutorials, and transformations that preserve function while exploring RTL cost-performance tradeoffs.Supported specifications include C/C++ and SystemC; HLS-ready kernels benefit from limited pointers and no dynamic allocation or recursion.Source: §4.1 · pp. 4–6
- ESP accelerators use a shared interface for CPU configuration, DMA or accelerator interaction, data exchange, and completion notification.Their execution proceeds through configure, load, compute, and store phases; load and store can overlap computation.Source: §4.1 · p. 5
- Accelerators can exchange data through external memory or point-to-point NoC links, with P2P matching producer stores to consumer inputs at finer granularity.Memory contention can delay DMA; P2P can improve latency and throughput, but requires accelerator designs to accept each producer store as a valid consumer input.Source: §4.1 · p. 6
- An accelerator skeleton generator provides a testbench, synthesis and simulation scripts, bare-metal and Linux drivers, and a sample application.Designers customize computation and validation, and may extend communication and PLM structure for complex data access patterns.Source: §4.1 · pp. 6–7
- The embedded machine-learning flow generates the accelerator, software drivers, application, tile socket, and accelerator wrapper from a neural-network model.This domain-specific flow is fully automated [25].Source: §4.1 · p. 7
4.2 Third-Party Accelerator Integration
- The third-party integration flow skips new-accelerator design and automates SoC integration after designers provide IP metadata, source files, and a wrapper.ESP supplies adapters for AXI and AHB masters and AXI-Lite or APB slaves; the flow was used to integrate NVDLA.Source: §4.2 · p. 7
4.3 SoC Flow
- The SoC GUI selects tiles, accelerator design points, processors, cache configuration, clock domains, and monitors, then generates RTL and system configuration artifacts.A single make target generates FPGA bitstreams for supported boards and modules.Source: §4.3 · pp. 7–8
- FPGA prototypes included a 12-computer-vision-accelerator SoC, Linux SMP SoCs with tens of accelerators, and RISC-V systems with multiple NVDLAs.The authors report that the agile flow enabled rapid prototyping of these complex systems.Source: §4.3 · p. 8
5 RELATED WORK
ESP is situated among open-source SoC platforms, with a system-centric emphasis on heterogeneous integration and loosely coupled accelerators.
5 RELATED WORK
- Open-source SoC projects described include Rocket Chip, Chipyard, Celerity, HERO, and OpenPiton, with differing processor, accelerator, and interconnect designs.Celerity combined five Rocket cores, 496 simpler RISC-V cores, and an HLS-designed BNN accelerator in a 385-million-transistor SoC.Source: §5 · p. 8
- Blackparrot supports two of the four cache-coherence options available in ESP: fully coherent and non-coherent.Source: §5 · p. 8
- Unlike platforms with a processor-centric perspective, ESP emphasizes a system-centric scalable NoC architecture and integration of heterogeneous components, especially loosely coupled accelerators.Its methodology accommodates varied specification languages and synthesis flows while promoting HLS for accelerator design and integration.Source: §5 · p. 8
6 CONCLUSIONS
ESP aims to support open-source SoCs that integrate more heterogeneous components through scalable architectures and flexible design flows.
6 CONCLUSIONS
- ESP's flexible methodology accommodates different specification languages and design flows for heterogeneous SoC integration.Source: §6 · p. 8
- The platform is conceived as a heterogeneous integration platform and was tested through years of teaching at Columbia University.Source: §6 · p. 8
- ESP aims to foster collaborative SoC engineering across the open-source hardware community.Source: §6 · p. 8