[image] [image] Ressource protégée - Inria - Institut national de recherche en sciences et technologies du numérique [Accéder directement au contenu](#)

[image] [image]

* [Documentation](#)

* FR
  Français (FR)

* Anglais (EN)
  Se connecter

* [Portail HAL Inria](#)

* Recherche
  Loading...

## Recherche avancée

Information de documents

Titres

○ Titres

○ Sous-titre

○ Titre de l'ouvrage

○ Titre du volume (Série)

○ Champ de recherche par défaut (multicritères) + texte intégral des PDF

○ Résumé

○ Texte intégral indexé des documents PDF

○ Mots-clés

○ Type de document

○ Sous-type de document

○ Tous les identifiants du document

○ Identifiant HAL du dépôt

○ Langue du document (texte)

○ Pays (Texte)

○ Ville

○ À paraître (true ou false)

Ajouter
# Towards ASIP Architecture-Driven Algorithm Development

Manil Dev Gomony, Mihaela Jivanescu, Nikolas Olaziregi

► To cite this version:

Manil Dev Gomony, Mihaela Jivanescu, Nikolas Olaziregi. Towards ASIP Architecture-Driven Algorithm Development. 6th International Embedded Systems Symposium (IESS), Sep 2019, Friedrichshafen, Germany. pp.91-100, 10.1007/978-3-031-26500-6_8. hal-04489006

HAL Id: hal-04489006

https://inria.hal.science/hal-04489006v1

Submitted on 4 Mar 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
## Auteur

### Auteur (multicritères)

○ Auteur (multicritères)

○ Auteur : Nom complet

○ Auteur : Nom de famille

○ Auteur : Prénom

○ Auteur : Complément de nom, deuxième prénom

○ Auteur : Organisme payeur

○ Auteur : IdHal (chaîne de caractères)

○ Auteur : Fonction

○ Auteur : personID (entier)

○ Auteur : Identifiant de l'organisme payeur

○ Auteur : Identifiant de la structure

○ Directeur de thèse

○ Éditeur

○ Éditeur scientifique

○ Éditeur de la série

## Ajouter

### Structure

#### Structure (multicritères)

○ Structure (multicritères)

○ Structure : Acronyme

○ Structure : Nom

○ Structure : Code

○ Structure : Pays

○ Structure : Type

○ Structure : État dans le référentiel

○ Structure : Identifiant HAL de la structure

○ Structure/équipe de recherche : Pays

○ Structure/regroupement d'équipes : Pays

○ Structure/laboratoire : Pays

○ Structure/regroupement de laboratoires : Pays

○ Structure/institution : Pays

○ Structure/regroupement d'institutions : Pays

## Ajouter
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
Autres

Champ de recherche par défaut (multicritères)

○ <u>Champ de recherche par défaut (multicritères)</u>

○

○ <u>Revues (multicritères)</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Titre abrégé</u>

○ <u>Revue : Titre</u>

○ <u>Revue : Identifiant interne</u>

○ <u>Revue : Date de début de publication</u>

○ <u>Revue : ISSN électronique</u>

○ <u>Revue : ISSN</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Couleur dans SHERPA/RoMEO</u>

○ <u>Revue : État dans le référentiel</u>

○

○ <u>Colloque (multicritères)</u>

○ <u>Colloque : Titre</u>

○ <u>Colloque : Organisateur</u>

○ <u>Colloque : date de début (Année)</u>

○ <u>Colloque : date de fin (Année)</u>

○ <u>Conférence invitée (oui/non)</u>

○

○ <u>Projets ANR (multicritères)</u>

○ <u>Projet ANR : Acronyme</u>

○ <u>Projet ANR : Acronyme du programme</u>

○ <u>Projet ANR : Code décision (référence)</u>

○ <u>Projet ANR : Nom</u>

○ <u>Projet ANR : Identifiant interne</u>

○ <u>Projet ANR : État dans le référentiel</u>

○

○ <u>Projets européens (multicritères)</u>

○ <u>Projet européen : Acronyme</u>

○ <u>Projet européen : Identifiant de l'appel à projet</u>

○ <u>Projet européen : Référence</u>

○ <u>Projet européen : Nom</u>

○ <u>Projet européen : Date de fin</u>

○ <u>Projet européen : Financement</u>

○ <u>Projet européen : Date de début</u>
# Towards ASIP Architecture-Driven Algorithm Development*

Manil Dev Gomony, Mihaela Jivanescu, and Nikolas Olaziregi

Nokia Bell Labs, Antwerp, Belgium

**Abstract.** Application-Specific Instruction-set Processors (ASIP) are ideal for realizing physical layer signal processing algorithms in communication systems as they offer performance similar to hard-wired datapath implementations, while providing sufficient programmability to adapt with the continuously evolving communication standards. Several design choices need to be made while developing an algorithm for a specific signal processing function, such as the selection of the algorithm itself, choice of the mathematical operations and numerical precision, that affects the throughput, area and power consumption of ASIP implementation. Traditionally, the algorithm development and the ASIP architecture exploration is performed as separate processes resulting in large design time or a sub-optimal solution. This paper presents a simple methodology for the algorithm-ASIP designer(s) to understand the impact of various algorithmic design choices on the ASIP performance and make the right design choices at very early stage, thereby reducing the design time at least by a factor of 2.8x in algorithm research and development.

**Keywords:** Application-specific · Processor architecture · Design-space exploration · Signal processing · Physical layer.

## 1 Introduction

Application-Specific Instruction-set Processors (ASIP) are custom designed processors with an architecture (and instruction-set) optimized for a limited set of applications/algorithms. Hence, ASIPs stand in a better position in terms of power, performance and area (PPA) when compared to a General-Purpose Processor (GPP), and flexibility when compared to hard-wired solutions [6]. ASIPs are ideal for realizing the physical layer signal processing algorithms in communication systems where the PPA is critical, while providing sufficient programmability to adapt according to the continuously evolving communication standards, for e.g. 5G, Wi-Fi, G.fast. Several design choices need to be made while developing a physical layer signal processing algorithm, such as the selection of the algorithm, mathematical operations and numerical precision, that affects the PPA of ASIP implementation.

<footnote>* Supported by Flanders Innovation and Entrepreneurship (VLAIO).</footnote>
○ Projet européen : État dans le référentiel

○ Projet européen : Identifiant interne

○

○ Date de production : année

○ Date de mise en ligne : année

○ Date de publication : année

○ Date d'écriture : année

○ Date de modification du dépôt : année

○ Date de dépôt : année

○ Date de publication électronique : année

○

○ Collection HAL (multicritères)

○ Collection HAL : catégorie

○ Collection HAL : Code

○ Collection HAL : Nom

○ Collection HAL : Identifiant interne

○

○ Identifiant interne du contributeur/déposant

○ Nom complet du contributeur/déposant

○

○ Domaines

○ Domaine primaire

○ Domaine racine

○ Sous-domaine niveau 1

○ Sous-domaine niveau 2

○ Sous-domaine niveau 3

○

○ Statut du document

○ Version du document

○ Type de dépôt

○ Type de document

○ ISBN

○ Numéro - référence

○ Identifiant DOI

○

○ Classification

○ Audience

○ Vulgarisation

○ Comité de lecture - texte (oui ou non)

○ Actes de colloque
The traditional algorithm-ASIP design flow shown in Figure 1, starts with algorithm development, which includes devising the algorithm, system-level performance (e.g. SNR) estimation using high-level models (e.g. in Matlab) and bit-accurate implementation in C/C++. The ASIP architecture is then designed based on past experience and manual analysis of the algorithm, and implemented using a commercially available tool [15, 1, 2], that automatically generates an instruction-set simulator for throughput estimation. The area usage and power consumption of the RTL implementation of the ASIP is then evaluated using a RTL synthesis tool (e.g. Synopsys DC) for a certain technology node. The ASIP architecture is further optimized after manual analysis of the bottlenecks in the architecture, and the performance is estimated again. This manual design-space exploration process is repeated until the performance requirements are satisfied and/or an optimal solution is found, and if not a different algorithm is selected or the existing algorithm is modified and the whole design-space exploration process is repeated. In addition to the modifications on the algorithm, the designer has to explore the computational precision of the algorithm and evaluate the impact on throughput, area and power consumption to identify the optimal precision settings. The traditional design methodology takes significant amount of time as it involves several iterations involving manual implementation/modification of the ASIP architecture and its performance evaluation through synthesis.

<figure><img src="image_3.png" /><figcaption>**Fig. 1.** Traditional Algorithm-ASIP design loop showing the different number of iterations *n*, *m*, *r*, required for algorithm modifications, ASIP architecture design-space exploration and computational precision exploration, respectively. The proposed methodology automates the manual iterations to reduce the overall design-time.</figcaption></figure>

In this paper, we aim to close the gap between the Algorithm-ASIP design loop. The two main contributions in this paper are: 1) A simple methodology combined with a fast heuristic algorithm and an abstract cost model of ASIP
○ Référence interne

○ Financement

○ Collaborations

Ajouter

Lancer la recherche

Recherche experte (SolR)

Recherche experte (SolR)

Lancer la recherche
Vers la recherche avancée

• Déposer

Portail INRIA.HAL.SCIENCE
Les publications, logiciels... des scientifiques Inria

• Accueil

• Publications Inria

○ Consulter les derniers dépôts

○ Par équipe de recherche

○ Par auteur

○ Rapports de recherche et techniques

○ Livres blancs

○ Rapports d'activité des équipes

○ Statistiques

• Boite à Outils

○ X2Hal : importer par lot

○ Logiciels : créer le Codemeta.json

○ Créer mon IDHal

○ Créer mon CVHal

○ Haltools : créer ma page de publications

○ Haltools : extraire des données (réservé Inria)

○ Les bonnes pratiques

■ Comment bien s'affilier ?
to automate the early stage design-space exploration of algorithm-ASIP devel-
opment process, as shown in Figure 1, such that an algorithm-ASIP designer
can make early design choices while understanding the impact on ASIP perfor-
mance. 2) An evaluation of the proposed methodology under different use cases
and different designer experience levels. The rest of the paper is structured as
follows: Section 2 presents related work, Section 3 provides background on ASIP
architecture and Section 4 the proposed methodology for the automated early
design space exploration. In Section 5, we present the experimental results and
the evaluation of the proposed methodology under different scenarios. Finally,
we conclude the paper with future work in Section 6.

## 2 Related work

There is already a large amount of related work [7, 4, 9, 12] on the design-space
exploration of ASIP architectures, that target the entire tool-chain for an opti-
mal ASIP design and implementation, focusing on instruction set and datapath
design, and re-targetable compiler generation. In addition, several automated
framework [13, 11, 8] for early design-space exploration of ASIP instruction-set
and data path architectures has been proposed in the past. The profiling based
design methodology [3] to perform early identification of hot spots in the ASIP
allows algorithm-ASIP architecture co-design. In [5], an architecture and design
methodology for rapid prototyping of VLIW processors for signal processing
application is proposed. To summarize, prior art on the ASIP design methodolo-
gies focus on determining the optimal ASIP architecture for multiple number of
applications that would require continuous profiling with the applications and
needs prior knowledge on ASIP architecture design. In addition, the applications
or algorithms should be known or fixed in advance, and hence, they are not suit-
able to be used in the early design-space exploration by an algorithm designer
during the algorithm development phase.

## 3 Background

The basic building blocks of an ASIP constitute Functional Units (FU), Regis-
ter Files (RF), Load/Store Units (LSU), Data Memories (DM) and a Program
Memory (PM), as shown in Figure 2 [8]. The PM stores the compiled binary
of the application/algorithm, which is used to generate the instructions for the
FUs, RF and LSU. The FUs perform basic arithmetic and logic operations (addi-
tion, multiplication, shifting, etc.) and complex mathematical functions (square
root, division, etc.). One or more FUs connected in series using pipeline registers
to perform a sequence of operations using a single instruction is called an *Issue
slot* [9]. The RF stores the temporary data used by the Issue slots, while the
LSU keeps track of the address to the DM where the data to/from the issue
slots are stored. Determining the architecture of an ASIP includes selection of
the number of issue slots, type and number of FUs in each issue slot, size of RF,
and number and size of DM and LSUs. The selection of these parameters has
■ Quelle version puis-je déposer ?

■ Choisir le bon « type de document »

■ Mettre en valeur ses publications

○ Les tutos IES Inria

■ Lier les notices dans HAL

■ Umbrhal Inria pour l'accessibilité

■ Personnaliser son CVHAL

■ Créer et Personnaliser sa collection

• Documentation

○ Aide en ligne HAL

○ Aide en ligne Haltools

○ Aide en ligne X2hal

○ Tutoriels video HAL

○ Documentation API HAL

○ Ajouter des vignettes

○ Identifiant auteur IdHAL et CV

○ Compléter son dossier ORCID avec ses dépôts HAL

○ Inria et la Science Ouverte

X

X

X

Loading...

X

Le document que vous demandez est en access restreint
jusqu'au 2026-01-01 !

Revenir a la notice

Retourner à l'accueil

Contact

•

Ressources
an impact on the area usage, power consumption and throughput of application execution. Note that the design-space exploration in this work focuses only on the data path elements, i.e., the FU, RF and LSU, however, we plan to include the DM in the future work.

<figure><img src="image_4.png" /><figcaption>**Fig. 2.** Generic ASIP architecture constituting of Functional Units (FU), Register Files (RF), Load/Store Units (LSU), Data Memories (DM) and a Program Memory (PM).</figcaption></figure>

# 4 Proposed methodology

The proposed automated methodology, shown in Figure 3, consists of three steps: Intermediate Representation (IR), Data Flow Graph (DFG) and Architecture (ARCH) generation.

<figure><img src="image_5.png" /><figcaption>**Fig. 3.** Proposed automated methodology for design-space exploration includes generation of Intermediate Representation (IR) of algorithm, Data Flow Graph (DFG), and Design-space exploration using our proposed heuristic ARCH generation.</figcaption></figure>

**IR Generation:** Starting from the algorithm implementation in C programming language, an existing C-compiler, e.g. LLVM or GCC, is used to generate
* Documentation

* FAQ

* API

* OAI-PMH

* AuréHAL

## Informations

* À propos

* Données personnelles

* Mentions légales

* Accessibilité

* Conformité RGAA

## Questions juridiques

* Je publie, quels sont mes droits ?

* Loi pour une République numérique

* Stratégie de non-cession des droits

* SHERPA/RoMEO

## Portails

* Portails institutionnels

* HAL

* HAL SHS

* HAL Thèses

* MédiHAL

## CCSD

* CCSD

* Episciences

* Sciencesconf
the Intermediate Representation (IR) of the application program. IR represents all paths that might be traversed during the execution of a program. In IR, Static single assignment (SSA) form is used where each variable is assigned exactly once and useful for the static analysis of code. During the IR generation, we fully unroll all loops in the code. For example, the IR representation of a C-program performing two multiply-accumulate operations is shown in Figure 4. The different storage required for the program execution, the data types and the basic operations and their dependencies can be identified easily from the IR.

<figure><img src="image_6.png" /><figcaption>**Fig. 4.** Example illustration of a C implementation of a multiply-accumulate operation converted to Intermediate Representation (IR).</figcaption></figure>

**DFG Generation:** The IR of the algorithm is analyzed to identify the FU types and width, RF sizes and width, and a *Data Flow Graph (DFG)* [10, 14] is generated, as shown in step 2 in Figure 5. In the DFG, the FUs and registers represent the nodes and the edges of the graph represents the dependencies between the FUs. The DFG represents the largest un-optimized ASIP architecture called the *best-parallel architecture*. In other words, implementing the best-parallel architecture results in the highest throughput possible for a given algorithm, but consuming the largest area and power. The data types of the variables in the IR are used to determine the size of FUs, RF and DM. Note that the IR Generation and the DFG Generation steps are similar to the prior art on ASIP design methodology, however, the main difference here is that we generate the initial best-parallel architecture after fully unrolling the loops.

**ARCH Generation:** Starting from the best-parallel architecture, our goal is to generate and compare the different ASIP architectures by sharing of computational resources during the execution of the algorithm. This means that the different architectures will have different area usage, power consumption and/or latency, as shown by the example illustration in Figure 5. In the example, the two issue slots on the architecture shown on the left side is merged to a single issue slot to create the architecture on the right side. This is only possible
when the operations in the issue slots are similar. As a result of merging, the
architecture on the right side has lower area usage (and power consumption)
but longer execution latency. Since the mapping of issue-slots on another is an
NP-hard problem, we propose a heuristic algorithm *ARCH GEN* to reduce the
exploration run-time. The basic idea of ARCH GEN is to optimize the DFG rep-
resenting the best-parallel architecture by *shrinking* to identify Pareto-optimal
architectures in terms of power, area and throughput. ARCH GEN performs
shrinking in a step-by-step manner, consisting of three basic steps:

<figure><img src="image_7.png" /><figcaption>**Fig. 5.** Example illustration of a DFG and design-space exploration by shrinking. Two issue slots of the same type are reduced to one that results in an increase of the computational latency (decrease in throughput) and reduction in the area usage and power consumption.</figcaption></figure>

**Step 1: Identify and group issue slots:** By parsing through the DFG, the issue slots (i.e. one ore more FUs with shared input and/or output registers as explained in Section 3) are identified. Issue slots of the same type are then grouped together such that the shrinking can be performed by re-use of (some of) the issue slots for the execution of the DFG. Note that the dependency information of the issue slots is retained for performing the shrinking while maintaining the execution order and to compute the throughput of execution of the DFG.

**Step 2: Reduce issue slots without penalty:** Depending on the algorithm, there might be two or more different paths in the DFG with different latency. In such cases, issue slots of the same type in the shorter (faster) path can be reduced (shared or re-used) during the execution to balance the latency of both paths such that the overall throughput is not affected. Note that for simplicity, we have assumed the reduction of an issue slot does not results in reduction of number of registers required to store the results of intermediate computation (as shown by registers REG 4, REG 5 and REG 6 in Figure 5). However, including the DM
in to the analysis will have an impact in the register file size, which is currently
a limitation of our proposed methodology.

*Step 3: Reduce issue slots with penalty:* The goal of this step to generate DFG architectures with lower power and area usage by trading-off throughput. Once the latency of all the paths in the DFG is balanced without affecting the throughput (Step 2), one of the branches is randomly selected to reduce the number of issue slots. This will reduce the throughput of the execution of the DFG, but the area usage and power consumption will be lower. Step 2 is then repeated, i.e. the issue slots are reduced one-by-one from each other issue slot groups such that the latency of all paths are balanced. Step 3 is repeated until the number of issue slots in each group is reduced to one. This means that the shrinking is stopped when we reduce the DFG to an architecture with the lowest throughput.

During the shrinking Steps 2-3, the area vs. power vs. throughput trade-off of different architectures generated in each step is computed using a cost model that consists of area and power consumption estimates for the FUs, RFs and LSUs. When computing the throughput, the delay (in clock cycles) introduced by each FU is used. The cost model uses area and power consumption estimates for the FU and registers of different sizes obtained by synthesis for a specific process technology. The use of abstract cost model speeds up the design-space exploration process. Note that the absolute area usage and power consumption numbers of FUs are not very relevant and it does not reflect the real implementation measurements as our main goal is to perform a relative comparison between the different ASIP data path architectures.

# 5 Evaluation

We implemented the proposed methodology using LLVM compiler for the IR generation and Python scripts for IR parsing, DFG generation and design-space exploration using ARCH GEN algorithm. For the cost model, we have synthesized the basic functional units, such as adder, multiplier, divider etc., and registers for different widths (precision) using Synopsys DC and TSMC 16nm FinFET standard cell library at nominal operating conditions. Note that the power consumption of the different blocks are estimated assuming average switching activity of 0.125 in the synthesis tool. The Pareto-optimal ASIP architectures for different signal processing algorithms that are typically used in the physical layer of communication systems, such as Matrix multiplication, FFT, Matrix inverse, etc., were generated using the proposed methodology, and we found that the architectural design choices made were similar to those of an expert designer. As an example, the trade-off relation for a 6 × 6 matrix inverse operation using LU decomposition algorithm is shown in Figure 6.

To evaluate the optimality of the proposed ARCH-GEN algorithm, we compared with an exhaustive algorithm that generates all possible issue slot combinations. For each combination of issue slots, a new architecture is generated
<figure><img src="image_8.png" /><figcaption>Fig. 6. Pareto optimal architecture solutions for a 6 × 6 matrix operation using LU decomposition algorithm obtained using ARCH GEN.</figcaption></figure>

by combining the issue slots if they are of the same type. The Pareto-optimal points of the exhaustive algorithm matched with the results of heuristic algorithm. However, the run-time of the exhaustive algorithm increases exponentially with the number of issue slots, as expected. For a DFG having above eight issue slots, it was not possible to find the optimal solution even after few hours, whereas the heuristic algorithm could find the optimal solution in less than a second for algorithms having up to 70 issue slots.

We evaluated the savings in design time using the proposed methodology for both entry-level (0 – 2 years) and experienced (> 2 years) designers. We considered use-cases of both development of new signal processing algorithm and modification of an existing algorithm and for the following scenarios (as shown in Figure 1): Design-space exploration (DSE), Initial prototype (IP) phase of product development, and Research exploration (RE).

For a given algorithm, the time for design-space exploration is given by Equation 1

$$T_{DSEt} = \sum_{i=1}^{m} (T_{arch(i)} + T_{eval(i)}) \quad (1)$$

where $T_{arch(i)}$ is the time taken to design and implement the ASIP hardware architecture, $T_{eval(i)}$ is the time taken to evaluate the throughput, area and power consumption of the ASIP implementation and $m$ is the number of manual iterations needed before converging to a solution, as indicated in Figure 1. The total design time is given by Equation 2

$$T_{Dt} = r \times (n \times (T_{alg} + T_{DSEt})) \quad (2)$$
<figure><img src="image_9.png" /><figcaption>Fig. 7. Design-time speedup for an entry-level and experienced designer using the proposed automated methodology.</figcaption></figure>

where $T_{alg}$ is the time for algorithm selection and implementation, n and r are the number of times the algorithm is modified and the computational precision is modified for each algorithm, respectively. As the time for design-space exploration is less than a second, the total design time using our methodology is given by Equation 3

$$T_{Dp} = r \times (n \times T_{alg}) + T_{arch(1)} \quad (3)$$

We found that for all cases, the design time is reduced with the proposed solution compared to the traditional approach. The speedup achieved by an entry-level and an experienced designer for both scenarios of a new algorithm design or algorithm modification, is shown in Figure 7. As we can see, our proposed methodology results in savings of at least 1.75x in design time in all cases and with different designer experience levels. Our proposed methodology mostly benefits in research exploration for new design of an algorithm and saves over 20 weeks for a signal processing function of medium complexity, where multiple algorithms and precision configurations needs to be evaluated for ASIP implementation. Note that in addition to the savings in design time, our approach results in an optimal algorithm-ASIP implementation, whereas the manual approach might only result in a sub-optimal solution.

## 6 Conclusions and Future work

We presented a simple and effective methodology to assist the algorithm-ASIP designer in understanding the impact of various algorithmic design decisions on ASIP performance. The proposed automated methodology runs in less than a second leading to a reduction in design time of at least 1.75x for designers with different experience levels and under different scenarios, benefiting mostly in research exploration of algorithms. As a future work, we would like to extend the proposed methodology to bring data memory in to the analysis and register file optimization based on data re-use to improve the accuracy of the estimation.
References

1. Cadence Design Systems, Inc.: Tensilica customizable processors. In: https://ip.cadence.com/ipportfolio/tensilica-ip/xtensa-customizable (2019)

2. Codasip Ltd.: Codasip Studio. In: https://www.codasip.com/custom-processor/ (2019)

3. Eusse, J., Williams, C., Leupers, R.: CoEx: A novel profiling-based algorithm/architecture co-exploration for ASIP design. In: Reconfigurable and Communication-Centric Systems-on-Chip (Re-CoSoC), 2013 8th International Workshop on. pp. 1–8 (July 2013). https://doi.org/10.1109/ReCoSoC.2013.6581520

4. Eusse, J., et al.: Pre-architectural performance estimation for ASIP design based on abstract processor models. In: Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS XIV), 2014 International Conference on. pp. 133–140 (July 2014). https://doi.org/10.1109/SAMOS.2014.6893204

5. Hoare, R.R., et al.: Rapid VLIW Processor Customization for Signal Processing Applications Using Combinational Hardware Functions. EURASIP J. Appl. Signal Process. **2006**, 67–67 (Jan 2006). https://doi.org/10.1155/ASP/2006/46472

6. Ienne, P., Leupers, R.: Customizable Embedded Processors: Design Technologies and Applications. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA (2007)

7. Jordans, R., Diken, E., Jozwiak, L., Corporaal, H.: BuildMaster: Efficient ASIP architecture exploration through compilation and simulation result caching. In: Design and Diagnostics of Electronic Circuits Systems, 17th International Symposium on. pp. 83–88 (April 2014). https://doi.org/10.1109/DDECS.2014.6868768

8. Jordans, R., Jóžwiak, L., Corporaal, H.: Instruction-set architecture exploration of VLIW ASIPs using a genetic algorithm. In: 2014 3rd Mediterranean Conference on Embedded Computing (MECO). pp. 32–35 (June 2014). https://doi.org/10.1109/MECO.2014.6862720

9. Jozwiak, L., et al.: ASAM: Automatic architecture synthesis and application mapping. Microprocessors and Microsystems **37**(8 PARTC), 1002–1019 (2013). https://doi.org/10.1016/j.micpro.2013.08.006

10. Kato, T., et al.: A CDFG generating method from C program for LSI design. In: APCCAS 2008 - 2008 IEEE Asia Pacific Conference on Circuits and Systems. pp. 936–939 (Nov 2008). https://doi.org/10.1109/APCCAS.2008.4746177

11. Lapinskii, V.S., Jacome, M.F., De Veciana, G.A.: Application-specific clustered VLIW datapaths: Early exploration on a parameterized design space. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems **21**(8), 889–903 (2002). https://doi.org/10.1109/TCAD.2002.800451

12. Meloni, P., Pomata, S., Tuveri, G., Secchi, S., Raffo, L., Lindwer, M.: Enabling fast asip design space exploration: An fpga-based runtime reconfigurable prototyper. VLSI Des. **2012**, 11:11–11:11 (Jan 2012). https://doi.org/10.1155/2012/580584, http://dx.doi.org/10.1155/2012/580584

13. Pomata, S., et al.: Exploiting binary translation for fast ASIP design space exploration on FPGAs. 2012 Design, Automation & Test in Europe Conference & Exhibition (DATE) pp. 566–569 (2012). https://doi.org/10.1109/DATE.2012.6176533

14. Rosien, M., Smit, G., Krol, T.: Generating a CDFG from C/C++ code, pp. 200–202. STW Technology Foundation (10 2002), imported from DIES

15. Synopsys Inc.: Synopsys IP designer. In: https://www.synopsys.com/dw/ipdir.php?ds=asip-designer (2019)