PROFILPELAJAR.COM

Coarse-grained reconfigurable array

Un coarse-grained reconfigurable array o coarse-grained reconfigurable architecture (CGRA) è una classe di hardware di spatial computing costruita a partire da un numero relativamente grande di processing elements (PEs) collegati tramite un'interconnessione on-chip programmabile, staticamente o dinamicamente reconfigurable. Riconfigurando sia l’operation di ciascun PE sia il routing tra i PEs, una CGRA può essere specializzata per implementare il dataflow graph di una computation, nella maggior parte dei casi il body di un loop performance-critical. Si colloca tra l’adattabilità dei software-programmable processors e l’efficienza energetica del hardware custom.[1][2][3]

Log-scale plot di energy efficiency contro flexibility per hardware classes, con ASICs come più efficient ma meno flexible, CPUs come meno efficient ma più flexible, e CGRAs evidenziate vicino all’estremo efficient e low-flexibility.
Energy efficiency (MOPS/mW, log scale) versus flexibility per le principali hardware classes. Efficiency e flexibility sono in trade-off tra loro, e le CGRAs evidenziate si collocano verso l’ASIC end della efficiency scale, pur rimanendo considerevolmente più flessibili.

I building blocks di una CGRA sono fissati a livello di word e riconfigurati a coarse granularity, il che la distingue da una field-programmable gate array (FPGA). Le FPGAs sono reconfigurable a livello di singoli bit e di singole porte logiche, offrendo grande flessibilità a costo di elevati overheads in termini di area, potenza e tempo di configurazione. Anche i general-purpose processors (CPUs e GPUs) sono highly flexible, ma pagano l’energy cost di fetching e decoding di un instruction stream per ogni operation, mentre un application-specific integrated circuit (ASIC) è l’opzione più energy-efficient proprio perché è specialized per una single application e quindi la meno flexible. Operando a word granularity, una CGRA conserva gran parte del spatial, energy-efficient parallelism del custom hardware pur rimanendo reprogrammable in software.[1]

Le CGRAs furono per la prima volta concepite nel 1960 e assunsero la loro forma moderna a metà degli anni 1990.[4] Da allora sono state applicate a signal processing, wireless communication e machine learning, e compaiono sia in academic prototypes sia in commercial silicon. Eseguire un programma su una CGRA richiede un compilatore specializzato che mappa il dataflow graph del programma sull’array, un passaggio che rimane uno dei principali ostacoli alla wider adoption.[5]

Background

L’interesse per le CGRAs nasce da un divario nell’ecosistema hardware. Con la fine del Dennard scaling e il rallentamento della Moore’s law, che riducono i performance gains che i general-purpose processors un tempo fornivano automaticamente, la computer architecture si è orientata verso la specializzazione per continuare a migliorare le performance per watt, spinta in parte da demanding workloads come le neural networks. A un estremo, i fixed-function ASICs raggiungono la massima efficienza, ma comportano elevati costi di non-recurring engineering e non possono essere modificati dopo la fabbricazione. All’altro estremo, i von Neumann processors sono interamente riprogrammabili ma inefficienti dal punto di vista energetico, mentre le FPGAs rappresentano un flexible but costly middle ground. Poiché la dataflow architecture è reconfigurable a livello di parola, le CGRAs mirano a combinare l'efficienza vicina a quella degli ASIC con la programmabilità post-fabrication.[1]

Storia

L’idea di una macchina la cui struttura possa essere riconfigurata per un calcolo risale al "fixed-plus-variable structure computer" proposto da Gerald Estrin nel 1960.[4] Le coarse-grained arrays nel modern sense emersero a metà degli anni 1990, quando diversi gruppi sostituirono le bit-level cells di una FPGA con word-level processing elements.[5] Il KressArray introdusse una two-dimensional mesh di reconfigurable datapath units; MATRIX combinò un word-level datapath con una configurable interconnect; RaPiD e PipeRench organizzarono le loro cells come reconfigurable pipelines, con PipeRench che raggiunse il silicon; e MorphoSys accoppiò una reconfigurable-cell mesh con un control processor per data-parallel media workloads.[6]

Durante gli anni 2000, i design divennero più grandi e più integrati. ADRES accoppiò un VLIW processor con una reconfigurable matrix, TRIPS esplorò una polymorphous array capace di sfruttare instruction-, thread-, and data-level parallelism, e PACT XPP offrì una self-reconfiguring commercial fabric.[7][8][9] Dagli anni 2010 in poi, la research enfatizzò data movement e system integration: HyCUBE introdusse una single-cycle multi-hop interconnect, Plasticine organizzò la computation attorno a pattern compute e pattern memory units, e il modello stream-dataflow (Softbrain) decoupled memory streaming from the spatial datapath.[10][11][12] Lo stesso periodo vide prendere forma un open-source ecosystem, includendo ultra-low-power edge arrays come OpenEdgeCGRA, integrato con il RISC-V microcontroller X-HEEP nella HEEPsilon platform per dare un complete flow from C code to hardware.[13][14]

Una manciata di CGRAs ha raggiunto il commercial silicon. Il Reconfigurable Processor (SRP) di Samsung, derived from ADRES, è apparso in systems-on-chip e in ultra-low-power biomedical variants;[15][16] SambaNova ha commercializzato la sua reconfigurable dataflow unit (RDU), un large dataflow accelerator costruito da pattern compute e pattern memory units e orientato a machine-learning training and inference.[17]

Struttura dell'architettura

Una CGRA fabric è tipicamente organizzata come una two-dimensional array di processing elements, ciascuno costruito attorno a una arithmetic logic unit (ALU) o functional unit, a un piccolo local register file o a un insieme di pipeline registers, e a uno o più configuration registers che determinano, on a per-PE basis, quale operation eseguire e come gli operands sono routed. I PEs sono collegati da una programmable interconnect, comunemente una mesh, un torus o, per arrays più piccoli, un crossbar switch, che permette agli operands prodotti da un PE di raggiungere i suoi neighbors o, in progetti più ricchi, PEs più distanti. La maggior parte delle CGRAs non è standalone; l’array è coupled a un host o a un control processor, un ruolo storicamente ricoperto da un VLIW o da un core ARM e, in molti recenti progetti open source, da un core RISC-V. A seconda di quanto strettamente l’array sia bound to the host, una CGRA è descritta come tightly coupled se si trova all'interno del processor datapath ed è invocata come istruzione personalizzata, oppure loosely coupled se agisce come acceleratore separato che comunica tramite un'interconnessione on-chip. Il layout a bassa coerenza è il più comune nei moderni sistemi di grandi dimensioni.[18]

Three-panel schematic che mostra una controller-driven array attached to memory, una mesh di interconnected processing elements alimentata da un data manager, e l’interno di un processing element con functional unit, local memory e crossbar.
Una CGRA a tre livelli di dettaglio: l’array driven by a controller e coupled to memory (sinistra), la mesh di processing elements alimentata da un data manager (centro), e gli internals di un PE, cioè functional unit, local memory e crossbar interconnect (destra).

Programmare una CGRA significa caricare una 'configuration' nella configuration memory dell’array: per ciascun PE, la configuration specifica l’operazione (ad esempio add, multiply, shift o compare) e il routing degli input e degli output. Poiché questa configurazione è coarse-grained, una dedicated CGRA può passare a una nuova configurazione in nanosecondi, a un ordine di grandezza più rapidamente di quanto una FPGA possa riconfigurarsi. Una single configuration produce una single spatial "snapshot" del dataflow graph (DFG) in esecuzione. Nelle CGRAs spatial-only, il DFG di un kernel viene unrolled una sola volta sull’array e ciascun PE mantiene la stessa configurazione per tutta l’esecuzione, in modo simile a un systolic array. Nelle temporal o spatio-temporal CGRAs, invece, ciascun PE cycles through una breve sequence of configurations conservate nella local configuration memory, time-multiplexing diversi DFG nodes sullo stesso physical PE attraverso successive cycles.[1][2][5]

La letteratura classifica ulteriormente l'esecuzione della CGRA in base al numero di configurazioni e di data streams che un PE array gestisce contemporaneamente: single-configuration, single-data (SCSD); single-configuration, multiple-data (SCMD), in cui una configurazione viene applicata su tutto l'array; e multiple-configuration, multiple-data (MCMD), in cui diverse configurazioni vengono eseguite in parallelo.[1]

Comparison of CGRAs with other computing architectures
Architecture Flexibility Computation form Execution mechanism
Temporal Spatial Reconfiguration time Configuration-driven Dataflow-driven Instruction-driven
CGRA Domain Si Si ns–μs Si Si (NO)
AI engine (a) Domain Si Si ns–μs Si Si Si
FPGA General (NO) (1) Si ms–s Si Si (NO)
ASIC Fixed (NO) Si (NO) (NO) (2) Si (NO)
CPU General Si Si N.D. (NO) (NO) Si
GPU General Si Si N.D. (NO) (NO) Si
Multi-core processor General Si (NO) N.D. (NO) Si Si

Notes:

  • (a) Con "AI engine" (motore AI) si intende qui un acceleratore AI/ML specifico per dominio, costruito come un array spaziale di tile vettoriali VLIW-SIMD collegati da un'interconnessione AXI-stream programmabile e da memorie locali (ad esempio, l'AMD/Xilinx Versal AI Engine). A differenza di un FPGA o di un fabric CGRA, l'array di AI engine e il datapath di ciascun tile sono fissati in fase di fabbricazione. Ciò che è programmabile a runtime è il software eseguito da ciascun tile (quindi è instruction-driven, cioè guidato da istruzioni) e la connettività di stream e dataflow tra i tile (quindi è configuration- e dataflow-driven, cioè guidato da configurazione e flusso dati).
  • (1) Gli FPGA possono eseguire calcolo temporale, ma farlo non è praticabile dato l'overhead coinvolto.
  • (2) Gli ASIC non supportano la riconfigurazione, sebbene possano comunque contenere codici di configurazione.
  • La voce relativa al tempo di riconfigurazione è indicata come "non applicabile" per CPU, GPU e processori multi-core, poiché si tratta di macchine instruction-driven che non riconfigurano un fabric; la loro latenza per operazione riflette l'issue delle istruzioni, non la riconfigurazione
A two-by-two chart che rappresenta PE composition, da homogeneous a heterogeneous, contro execution model, da spatial-only a spatio-temporal, con difficulty crescente verso il top-right corner.
Il two-dimensional CGRA design space: PE composition (homogeneous ↔ heterogeneous) contro execution model (spatial-only ↔ spatio-temporal). Specialization e mapping difficulty aumentano verso il top-right.

Un’ulteriore distinzione architettonica riguarda se i PEs across the array siano identici o specializzati. In una CGRA omogenea, ogni PE supporta lo stesso insieme di operazioni, il che semplifica il placement and routing durante la compilazione. In una CGRA eterogenea, i PEs sono specializzati: per esempio, solo alcuni implementano un moltiplicatore o un'unità di caricamento/salvataggio della memoria, mentre gli altri gestiscono operazioni aritmetiche e logiche più semplici. Questo riduce l'area e il power per un dato target workload, ma comporta un problema di mapping più complesso, poiché il compiler deve posizionare ciascuna operation su un PE che effettivamente la supporti. L’homogeneous-versus-heterogeneous axis è independent dalla spatial-versus-spatio-temporal distinction, dando un two-dimensional design space che va da simple, easy-to-compile homogeneous-spatial arrays a complex, highly specialized heterogeneous-spatio-temporal ones.[19]

Compilazione e Programmazione

Flowchart che va dal source code a un dataflow graph, poi scheduling e place-and-route sull’array, producendo una configuration, con una feedback arrow che aumenta l’initiation interval quando il mapping fallisce.
Flow di programmazione tipico dei CGRA: il source code viene ridotto a un dataflow graph, che viene scheduled e place-and-routed sull’array per produrre una configuration. In caso di mapping failure, l’initiation interval (II) viene aumentato e il kernel viene rimappato.

Poiché una CGRA esegue un spatial dataflow graph invece di un sequential instruction stream, il suo compiler deve trasformare un programma in una placed-and-routed configuration anziché in istruzioni macchina. Un typical flow parte da un high-level language, solitamente C o C++, identifica i performance-critical loops e lowers ciascuno di essi a un dataflow graph, comunemente attraverso un LLVM-based front end, nonostante alcune novel methodology usino MLIR[20][21]. I loops che contengono conditionals vengono resi spatial convertendo control dependencies in data dependencies tramite predication, whether partial or full, in modo che entrambi i sides di un branch siano computed, e il correct result venga poi selected.[1]

Il core del flow è il mapping problem: binding ogni DFG node a un PE e routing ogni data dependency attraverso l’interconnect, subject alle operational capabilities dei PEs, all’interconnect topology e alle timing constraints.[2][10][20][22] Questo problema è NP-complete ed è solitamente diviso in due sottoproblemi collegati: scheduling, che assegna a ciascuna operation un time slot, e placement-and-routing, che bind operations a PEs e riserva risorse di interconnect. Per i loop pipelined, la key quality metric è l’initiation interval (II), ovvero il numero di cicli tra lo start di due iterazioni successive del loop, che determina il throughput. Software pipelining tramite modulo scheduling cerca un mapping valido al II minimo raggiungibile, aumentando l'II e rescheduling ogni volta che il mapping non è valido. I mappers descritti nella literature usano heuristics, simulated annealing, integer linear programming, graph-theoretic formulations come maximal-clique search, e, più recentemente, learning-based e hierarchical methods.[22][23]

Selected open-source CGRA design and compilation frameworks
Framework First release Origin Input / front end Mapping RTL generation Simulation Distinguishing features
CGRA-ME[24][25] 2017 (v2.0, 2024) University of Toronto C via LLVM; custom architecture description Architecture-adaptive; ILP and simulated annealing Verilog Si (from v2.0) Models homogeneous spatio-temporal CGRAs; limited handling of control divergence
CCF 2018 Arizona State University C with #pragma CGRA (Clang/LLVM) Graph-based; partial predication No Cycle-accurate (gem5, CPU + CGRA) CPU-coupled accelerator; MiBench, Parboil and Rodinia benchmarks
OpenCGRA / CGRA-Flow[26] 2021 Pacific Northwest National Laboratory / Northeastern University C/C++ loop; optional GUI Operation-centric; supports control divergence, recurrences, multidimensional loops Verilog (FPGA-synthesizable) Si (user-provided test benches) GUI front end (CGRA-Flow); parameterizable interconnect generator
Morpher 2022 National University of Singapore C via LLVM Architecture-adaptive; heuristic, simulated annealing, and learning-based (LISA) Si (via Pillars/Chisel) Cycle-accurate with automated validation Learning-based (LISA) mapping; automated validation flow

Questi frameworks differiscono principalmente lungo quattro assi: se generano automaticamente un DFG a partire da una source o richiedono all’user di fornirne uno; se il loro mapper è "architecture-adaptive", cioè in grado di retargettizzare una nuova interconnect o un mix di PE senza code changes; se emettono RTL sintetizzabile; e se includono un integrated cycle-accurate simulator. Comparative studies typically report achievable initiation interval, mapping success rate e compilation time across standard loop-kernel benchmark suites come PolyBench.[27]

Challenges

Nonostante i loro vantaggi in termini di efficienza, le CGRAs rimangono un'open research question, con limitazioni di programmabilità e di produttività ancora da risolvere.[1]

Mapping and scheduling

Mappare il dataflow graph di un kernel sull’array e il routing delle sue dipendenze attraverso l’interconnect è un problema combinatorio difficile. Il compiler deve soddisfare simultaneamente le constraints di PE-capability, di routing/adjacency e di timing, e la difficoltà aumenta quando i PEs sono eterogenei o la topologia di interconnessione è irregolare. Un mapping che funziona con un kernel può non funzionare con un kernel leggermente diverso sulla stessa fabric.[2]

Control flow

Le CGRAs si mappano più naturalmente su kernel affini, loop-dominated e data-parallel espressi come grafi di dataflow. Irregular control flow, come data-dependent branches, function calls e pointer chasing, non si traduce cleanly su una spatial fabric, sia che quella fabric sia statically o dynamically scheduled, e gestirlo efficiently rimane un active research problem.[28]

Configuration memory overhead

I design temporali e spatio-temporali richiedono abbastanza memoria di configurazione (context) on-chip per mantenere ogni configurazione attraverso cui un PE dovrà passare.[1] Tenere more than one distinct configuration resident at once, cioè il multiple-configuration, multiple-data, o MCMD, execution model, costa più di questa memory rispetto alla condivisione di una single configuration across the array, come nel single-configuration, multiple-data (SCMD) model. Tale capacità si traduce direttamente in area e power, un costo da valutare rispetto al modello di esecuzione di cui un dato workload ha effettivamente bisogno.

Toolchain fragmentation

A differenza di CPU e GPU, le CGRAs non hanno uno standard, un compiler ampiamente adottato né un ecosistema di descrizione hardware. La maggior parte degli academic e industrial designs si basa ancora su bespoke, architecture-specific toolchains, che limitano reproducibility e rallentano adoption oltre il gruppo che ha costruito una data fabric.[1][26]

Applications

Le CGRAs sono progettate per compute-intensive, loop-dominated kernels con dataflow regolare, e la loro storia di applicazione riflette questo.[3] Le early arrays puntavano a digital signal processing, multimedia, e image and video processing, dove le stesse operations sono applicate a streams of data. Lavori correlati li hanno applicati alla wireless baseband e alla software-defined radio, sfruttando la reconfigurabilità per lo switching tra gli standard.[1]

Più recentemente, il driver dominante è stato il machine learning.[3] CGRAs e CGRA-like dataflow accelerators sono usati per deep neural network inference and training, da large commercial systems che eseguono transformer e large-language-model workloads fino a ultra-low-power arrays at the edge. Altri domains includono scientific and high-performance computing, embedded bio-signal processing per wearable and near-sensor devices,[29] e error-tolerant workloads affrontati tramite approximate computing variants che trade accuracy for energy.[30]

Implementazioni note

La seguente tabella elenca representative CGRA and CGRA-like designs dall'accademia e dall'industria, coprendo le ere descritte nella sezione Storia.

Representative CGRA implementations
System Year Origin Type Notable for
RaPiD[31] 1996 University of Washington Academic Linear, pipelined reconfigurable datapath
ADRES[7] 2003 IMEC Academic VLIW host tightly coupled to a reconfigurable matrix
PACT XPP[9] 2003 PACT XPP Technologies Commercial Self-reconfiguring dataflow fabric
TRIPS[8] 2004 University of Texas at Austin Academic Polymorphous array (ILP/TLP/DLP)
Samsung SRP[15] 2010s Samsung Commercial ADRES-derived; used in systems-on-chip
DySER[32] 2012 University of Wisconsin – Madison Academic Reconfigurable array embedded in a processor pipeline
HyCUBE[10] 2017 National University of Singapore Academic Single-cycle multi-hop interconnect
Plasticine[11] 2017 Stanford University Academic Pattern compute and pattern memory units
Renesas DRP[33] 2018 Renesas Commercial Dynamically reconfigurable processor for embedded AI
SambaNova RDU[17] 2021 SambaNova Commercial Plasticine-derived AI dataflow accelerator
OpenEdgeCGRA[14] 2023 EPFL Academic Resizable ultra-low-power edge array (HEEPsilon / X-HEEP)
UbitiumCGRA[34] 2026 Ubitium Commercial First CGRA to run linux without a processor as controller

Note

  1. ^ a b c d e f g h i j Leibo Liu, Jianfeng Zhu, Zhaoshi Li, Yanan Lu, Yangdong Deng, Jie Han, Shouyi Yin e Shaojun Wei, A Survey of Coarse-Grained Reconfigurable Architecture and Design: Taxonomy, Challenges, and Applications, in ACM Computing Surveys, vol. 52, n. 6, 2019, p. 118:1–118:39, DOI:10.1145/3357375.
  2. ^ a b c d Artur Podobas, Kentaro Sano e Satoshi Matsuoka, A Survey on Coarse-Grained Reconfigurable Architectures From a Performance Perspective, in IEEE Access, vol. 8, 2020, p. 146719–146743, DOI:10.1109/ACCESS.2020.3012084, ISSN 2169-3536 (WC · ACNP).
  3. ^ a b c Cristina Silvano, Daniele Ielmini, Fabrizio Ferrandi, Leandro Fiorin, Serena Curzel, Luca Benini, Francesco Conti, Angelo Garofalo, Cristian Zambelli, Enrico Calore, Sebastiano Schifano, Maurizio Palesi, Giuseppe Ascia, Davide Patti e Nicola Petra, A Survey on Deep Learning Hardware Accelerators for Heterogeneous HPC Platforms, in ACM Computing Surveys, vol. 57, n. 11, 2025, p. 286:1–286:39, DOI:10.1145/3729215, ISSN 0360-0300 (WC · ACNP).
  4. ^ a b Organization of computer systems: the fixed plus variable structure computer, Papers Presented at the maggio 3–5, 1960, Western Joint IRE-AIEE-ACM Computer Conference (IRE-AIEE-ACM '60 (Western)).
  5. ^ a b c Coarse grained reconfigurable architectures in the past 25 years: Overview and classification, 2016 International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation (SAMOS).
  6. ^ Hartej Singh, Ming-Hau Lee, Guangming Lu, Fadi J. Kurdahi, Nader Bagherzadeh e Eliseu M. Chaves Filho, MorphoSys: an integrated reconfigurable system for data-parallel and computation-intensive applications, in IEEE Transactions on Computers, vol. 49, n. 5, 2000, p. 465–481, DOI:10.1109/12.859540.
  7. ^ a b ADRES: An Architecture with Tightly Coupled VLIW Processor and Coarse-Grained Reconfigurable Matrix.
  8. ^ a b Karthikeyan Sankaralingam, Ramadass Nagarajan, Haiming Liu, Changkyu Kim, Jaehyuk Huh, Nitya Ranganathan, Doug Burger, Stephen W. Keckler, Robert G. McDonald e Charles R. Moore, TRIPS: A polymorphous architecture for exploiting ILP, TLP, and DLP, in ACM Transactions on Architecture and Code Optimization, vol. 1, n. 1, 2004, p. 62–93, DOI:10.1145/980152.980156.
  9. ^ a b V. Baumgarte, G. Ehlers, F. May, A. Nückel, M. Vorbach e M. Weinhardt, PACT XPP—A Self-Reconfigurable Data Processing Architecture, in The Journal of Supercomputing, vol. 26, n. 2, 2003, p. 167–184, DOI:10.1023/A:1024499601571, ISSN 1573-0484 (WC · ACNP).
  10. ^ a b c HyCUBE: A CGRA with reconfigurable single-cycle multi-hop interconnect, Proceedings of the 54th Annual Design Automation Conference (DAC '17).
  11. ^ a b Plasticine: A Reconfigurable Architecture for Parallel Patterns, Proceedings of the 44th Annual International Symposium on Computer Architecture (ISCA '17).
  12. ^ Stream-dataflow acceleration, Proceedings of the 44th Annual International Symposium on Computer Architecture (ISCA '17).
  13. ^ An Open-Hardware Coarse-Grained Reconfigurable Array for Edge Computing, Proceedings of the 20th ACM International Conference on Computing Frontiers (CF '23).
  14. ^ a b X-HEEP: An Open-Source, Configurable and Extendible RISC-V Platform for TinyAI Applications, 2025 IEEE Computer Society Annual Symposium on VLSI (ISVLSI).
  15. ^ a b Changmoo Kim, Mookyoung Chung, Yeongon Cho, Mario Konijnenburg, Soojung Ryu e Jeongwook Kim, ULP-SRP: Ultra Low-Power Samsung Reconfigurable Processor for Biomedical Applications, in ACM Transactions on Reconfigurable Technology and Systems, vol. 7, n. 3, 2014, p. 22:1–22:15, DOI:10.1145/2629610.
  16. ^ Young-Hwan Park, Jaehyun Kim, Minsoo Kim, Wonchang Lee e Shihwa Lee, Programmable multimedia platform based on reconfigurable processor for 8K UHD TV, in IEEE Transactions on Consumer Electronics, vol. 61, n. 4, 2015, p. 516–523, DOI:10.1109/TCE.2015.7389807.
  17. ^ a b SambaNova SN40L: Scaling the AI Memory Wall with Dataflow and Composition of Experts.
  18. ^ G. Abarajithan, Zhenghua Ma, Ravidu Munasinghe, Francesco Restuccia e Ryan Kastner, CGRA4ML: A Hardware/Software Framework to Implement Neural Networks for Scientific Edge Computing, in ACM Transactions on Reconfigurable Technology and Systems, vol. 19, n. 2, 2026, p. 1–33, DOI:10.1145/3801097, ISSN 1936-7406 (WC · ACNP).
  19. ^ Building an Open CGRA Ecosystem for Agile Innovation, 2025 IEEE/ACM International Conference on Computer-Aided Design (ICCAD).
  20. ^ a b Yixuan Luo, Cheng Tan, Nicolas Bohm Agostini, Ang Li, Antonino Tumeo, Nirav Dave e Tong Geng, ML-CGRA: An Integrated Compilation Framework to Enable Efficient Machine Learning Acceleration on CGRAs, in 2023 60th ACM/IEEE Design Automation Conference (DAC), luglio 2023, p. 1–6, DOI:10.1109/DAC56929.2023.10247873.
  21. ^ Tianyi Yu, Omar Ragheb, Stephen Wicklund e Anderson, MLIR-to-CGRA: A Versatile MLIR-Based Compiler Framework for CGRAs, in 2024 IEEE 35th International Conference on Application-specific Systems, Architectures and Processors (ASAP), luglio 2024, p. 184–192, DOI:10.1109/ASAP61560.2024.00045.
  22. ^ a b Morpher: An Open-Source Integrated Compilation and Simulation Framework for CGRA (PDF), Fifth Workshop on Open-Source EDA Technology (WOSET).
  23. ^ CCF: A CGRA Compilation Framework (PDF), Design, Automation and Test in Europe Conference (DATE) 2018, University Booth.
  24. ^ CGRA-ME: A unified framework for CGRA modeling and exploration, 2017 IEEE 28th International Conference on Application-specific Systems, Architectures and Processors (ASAP).
  25. ^ CGRA-ME 2.0: A Research Framework for Next-Generation CGRA Architectures and CAD, 2024 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW).
  26. ^ a b OpenCGRA: Democratizing Coarse-Grained Reconfigurable Arrays, 2021 IEEE 32nd International Conference on Application-specific Systems, Architectures and Processors (ASAP).
  27. ^ Modeling and Mapping of Regular Nested Loops on Processor Arrays: CGRAs vs. TCPAs, 29. Workshop Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen (MBMV 2026).
  28. ^ Shangkun Li, Jinming Ge, Diyuan Tao, Zeyu Li, Jiawei Liang, Linfeng Du, Jiang Xu, Wei Zhang e Cheng Tan, NEURA: A Unified and Retargetable Compilation Framework for Coarse-Grained Reconfigurable Architectures, in Proceedings of the ACM on Programming Languages, vol. 10, PLDI, 2026, p. 953–979, DOI:10.1145/3808285, ISSN 2475-1421 (WC · ACNP).
  29. ^ Loris Duch, Soumya Basu, Miguel Peón-Quirós, Giovanni Ansaloni, Laura Pozzi e David Atienza, i-DPs CGRA: An Interleaved-Datapaths Reconfigurable Accelerator for Embedded Bio-Signal Processing, in IEEE Embedded Systems Letters, vol. 11, n. 2, 2019, p. 50–53, DOI:10.1109/LES.2018.2849267, ISSN 1943-0663 (WC · ACNP).
  30. ^ PX-CGRA: Polymorphic approximate coarse-grained reconfigurable architecture, 2018 Design, Automation & Test in Europe Conference & Exhibition (DATE).
  31. ^ RaPiD – Reconfigurable pipelined datapath, Field-Programmable Logic: Smart Applications, New Paradigms and Compilers (FPL '96).
  32. ^ Venkatraman Govindaraju, Chen-Han Ho, Tony Nowatzki, Jatin Chhugani, Nadathur Satish, Karthikeyan Sankaralingam e Changkyu Kim, DySER: Unifying Functionality and Parallelism Specialization for Energy-Efficient Computing, in IEEE Micro, vol. 32, n. 5, IEEE, 2012, p. 38–51, DOI:10.1109/MM.2012.51.
  33. ^ New Generation Dynamically Reconfigurable Processor Technology for Accelerating Embedded AI Applications, 2018 IEEE Symposium on VLSI Circuits.
  34. ^ (EN) Ubitium Becomes the World’s First CGRA to Execute Linux Without a Host – Ubitium, su ubitium.com, 27 aprile 2026. URL consultato il 2 luglio 2026.

Voci correlate

Collegamenti esterni

  Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.