[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
# Transformative Hardware Design Following the Model-Driven Architecture Vision

Zhao Han, Gabriel Rutsch, Deyan Wang, Bowen Li, Sebastian Siegfried Prebeck, Daniela Sanchez Lopera, Keerthikumara Devarajegowda, Wolfgang Ecker

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

## To cite this version:

Zhao Han, Gabriel Rutsch, Deyan Wang, Bowen Li, Sebastian Siegfried Prebeck, et al., Transformative Hardware Design Following the Model-Driven Architecture Vision. 29th IFIP/IEEE International Conference on Very Large Scale Integration - System on a Chip (VLSI-SoC), Oct 2021, Singapore, Singapore. pp.49-70, 10.1007/978-3-031-16818-5_3. hal-04419577

HAL Id: hal-04419577

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

Submitted on 26 Jan 2024

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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_2.png" /></figure>
## 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_3.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>
Transformative Hardware Design
following the Model-Driven Architecture Vision

Zhao Han¹,², Gabriel Rutsch¹, Deyan Wang¹,²,

Bowen Li¹,², Sebastian Siegfried Prebeck¹,², Daniela Sanchez Lopera¹,²,

Keerthikumara Devarajegowda¹, and Wolfgang Ecker¹,²

¹ Infineon Technologies AG, Am Campeon 1-15, 85579 Neubiberg, Germany,
[wolfgang.ecker@infineon.com](mailto:wolfgang.ecker@infineon.com)

² Technical University Munich, Arcisstraße 21, 80333 München, Germany,
zhao.han@tum.de

**Abstract.** Despite the high configurability of Intellectual Properties (IPs) and hardware generators, code modifications are still required to introduce aspect-oriented instrumentation to satisfy emerging aspectual design requirements such as on-chip debug and functional safety. These code modifications escalate development, verification efforts, and deteriorate code reuse. This paper proposes a highly efficient transformative hardware design methodology that leverages graph-grammar-based model transformations. Following the proposed methodology, main design functionalities and aspectual instrumentation are separately developed, automatically integrated, and verified. To demonstrate the applicability, industrial Systems on Chips (SoCs) were transformed to support on-chip debug. Compared to the conventional hardware generation, the proposed transformative methodology required less than 3× Lines of Code (LoCs) to develop and integrate the aspectual instrumentation. In particular, the proposed approach enables high code reusability, as the transformation script is implemented once and is reusable across all evaluated designs. This high LoC reduction and code reuse promote the overall productivity of digital design.

**Keywords:** Electronic Design Automation, Aspect-Oriented Programming, Model-Driven Architecture

# 1 Introduction

With growing complexity in Systems on Chips (SoCs), the hardware development cycle is prolonged and the cost increases. Intellectual Property (IP) reuse is a major productivity booster in hardware development and helps to promote code reuse. Following the IP reuse methodology, designers are encouraged to build configurable IPs that encapsulate verified design implementations. After, IPs are adapted and integrated to build large and complex designs to accelerate the development cycle. For further code reuse, hardware generators are built to
○ 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
encode design knowledge with hardware generation frameworks [1–5]. Hardware generators enable design customization reuse and are implemented with high-level programming languages such as Scala and Python. Making use of modern programming paradigms (e.g. object orientation), hardware generators adapt to highly complex configurations and generate adequate Hardware Description Language (HDL) code.

However, beyond main functionalities, aspectual design requirements such as On-Chip Debug (OCD) [6] and functional safety [7] emerge over the years and are essential for product success. On-chip instrumentation satisfying these design requirements is dependent on core functionality realizations and demands system-wide support. To implement the required on-chip instrumentation, code pieces are scattered across different IPs. For example, to support OCD, not only debug IPs (e.g. JTAG) are integrated, but also special features are needed in existing IPs, e.g. hardware breakpoints in the CPU. But due to the absence of aspect orientation [8] in state-of-the-art HDLs (e.g. SystemVerilog [9]) and hardware generation frameworks (e.g. Chisel [2]), the OCD instrumentation is either always implemented [10] or configurable by increasing the IP generality [11]. The former option results in an additional chip area and introduces possible security breaches, whereas escalated development and verification efforts are expected in the latter one [12]. In this paper, we use the term *design aspects* to describe these scattered and tangled aspect-oriented on-chip instrumentation. Design aspects pose new challenges in hardware development, because the scattering and tangling make the hardware implementations hard to understand, maintain, and reuse.

To address these issues, we propose to introduce aspect-oriented instrumentation by transforming existing designs. The proposed transformative hardware design methodology is built on top of a model-driven hardware generation framework, which follows the Model-Driven Architecture® (MDA®) vision [13]. The intermediate layer of this framework contains platform-independent design models that capture intended microarchitectures. Design models are graph-based: Hierarchical and logic components are vertices, whereas connections among ports and hierarchizations of components are edges. The proposed methodology transforms existing design models to incorporate desired aspect-oriented instrumentation. Model transformations are formalized and guided by graph grammar [14]. Thus, the main contributions of this paper are: (1) Main functionalities and design aspects are decoupled and addressed separately with the proposed methodology. This separation of design concerns promotes modularity, reduces development efforts, and enables high code reuse. (2) For quality assurance, design constraints are developed to validate introduced design modifications. Besides, formal properties are automated to verify transformed designs. (3) One Domain-Specific Language (DSL) is used to construct and transform designs. This consistent design environment prevents semantic gaps and lowers integration and maintenance burdens.
○ 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 ?
The rest of the paper is organized as follows: Related work is discussed in the next section. Section 3 depicts the underlying model-driven hardware generation framework. After, the proposed transformative hardware design methodology is elaborated in Section 4. To demonstrate the applicability, Section 5 presents an industrial case study on RISC-V OCD transformation and discusses the experimental results. The last section concludes the significance of this paper.

## 2 Related Work

High-level languages such as SystemC are used to describe hardware and compiled to HDL to improve design productivity [15]. To further reuse design customizations, hardware generation frameworks such as Genesis2 [1] are proposed. However, they fail to separate design aspects from main functionalities. Designers must consider aspect-oriented instrumentation during the implementation of the main functionality. Consequently, the scattered and tangled-up aspect-oriented instrumentation leads to increased development and verification efforts [12].

Moreover, the intermediate layer of the hardware generation framework used by Chisel is called Flexible Intermediate Representation for RTL (FIRRTL) [3]. FIRRTL enables instrumentation insertion by rewriting its abstract syntax tree. In doing so, simple circuits such as hardware counters can be inserted into designs. Also, PyRTL [4] and PyMTL [5] follow the same idea to enable instrumentation transformation. Furthermore, FTI [16] provides a graphical user interface to assist hardware engineers to harden a design step by step. Internally, FTI translates designs written in VHDL to tree-based AIRE-CE representations [17].

However, there are three main drawbacks of these approaches. First, the underlying tree-based data structure is inappropriate, as it is not the intrinsic structure of circuits, i.e., graphs. As a result, development efforts escalate, which diminishes the gained design productivity. Second, the employment of different languages for design construction and transformation introduces semantic gaps and complicates hardware development. Most importantly, they do not generate verification artifacts to assure the quality of transformed designs.

## 3 Model-Driven Hardware Generation Framework

MDA® [18] established itself as an important part of modern development processes over the last decades. Following MDA®, a model-driven hardware generation framework called MetaRTL has been developed to improve hardware design productivity [13]. With this design-centric framework, designers can focus on design intent instead of implementation details such as code formatting.

MetaRTL consists of three layers: *Things*, *Design*, and *View* (Figure 1). The things layer captures specification items into the *Formal Specification Model*. For satisfying specifications, designs are constructed with the expressive MetaRTL
■ 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 2025-01-01 !

Revenir a la notice

Retourner à l'accueil

Contact

•

Ressources
<figure><img src="image_4.png" /><figcaption>**Fig. 1.** Model-driven hardware generation framework (MetaRTL). The generation framework is extended with the transformative hardware design methodology as depicted in the right part.</figcaption></figure>

DSL [19] and stored as platform-independent *Design Models*. Subsequently, *Target Code Models* are derived for different HDLs and technologies (e.g. FPGA) in the view layer. State-of-the-art HDLs such as VHDL [20], Verilog [21], and SystemVerilog [9] are supported as the possible generator outputs.

A hardware generation flow starts from a formalized specification, which includes all must-have features and properties. In the main stage, i.e., the design layer, the translation from the specification model to a design model is conducted by making use of a design template [22]. Design models are abstract RTL models and include all high-level design details, for instance, port connections among different logic gates. Next, the design model is translated to a target HDL code model by a view template [23], which includes target-specific aspects. Finally, the HDL code is derived from the target code model.

# 4 Transformative Hardware Design Methodology

The proposed methodology is implemented as part of the MetaRTL in Figure 1. The left part in the figure shows the hardware generation flow, whereas the right part addresses design aspects with the transformative hardware design methodology. The proposed methodology integrates aspect-oriented instrumentation by transforming design models leveraging graph grammar. For easing hardware transformation development, various transformation utilities and reusable basic transformations are provided by the hardware transformation system. To assure quality, modified design models are validated with design constraints and transformed designs are verified with automated formal properties.
* 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
## 4.1 Graph-Based Design Model

In the main stage of MetaRTL, platform-independent design models capture microarchitectures. For describing microarchitectures, four types of components can be included in a design model [24]:

- Descriptive components indicate design hierarchies and description styles in the MetaRTL DSL [25].

- Behavioural components describe hardware behavior on a high level, such as finite state machines.

- Sequential components such as register store information, as their outputs depend on past and current inputs.

- Primitive components describe combinatorial logic, such as bitwise AND.

Hardware designs are usually represented as schematic diagrams, which use graphs to depict the instantiated components and connections among them. The design model is graph-based as well. Let LAB be an arbitrary but fixed set of suitable labels. A design model can be formalized with a hierarchical port graph [24]:

$$H = (V, P, E, (s_i, t_i)_{i \in \{G,T\}}, \mathfrak{p}, \mathfrak{t}, \mathfrak{d}, l)$$

- V is a finite set of vertices (components).

- P is a finite set of ports.

- $E = E_G \cup E_T$ are finite sets of graph and tree edges.

- $s_G, s_T$ are source functions for graph and tree edges respectively.

- $t_G, t_T$ are target functions for graph and tree edges respectively.

- $\mathfrak{p}: P \to V$ is a parent function that returns the parent component of a port.

- $\mathfrak{t}: V \to \text{Descriptive} \cup \text{Behavioural} \cup \text{Sequential} \cup \text{Primitive}$ is the type function for vertices (components).

- $\mathfrak{d}: P \to \{\text{In}, \text{Out}, \text{Inout}\}$ is the direction function for ports.

- $l: V \cup P \to LAB$ is a labeling function for vertices and ports.

The hierarchy in design models is a tree spanning over the same set of vertices $V$. This means, some vertices in design models are subgraphs that contain other vertices. These vertices are descriptive components, since they indicate design hierarchies and contain sub-components in design models. Hence, a vertex $v \in V$ can be denoted as

$$v = (V_v, P_v, E_v, (s_{i.v}, t_{i.v})_{i \in \{G,T\}}, \mathfrak{p}_v, \mathfrak{t}_v, \mathfrak{d}_v, l_v)$$

It is noteworthy that $V_v \subseteq V$, $E_v \subseteq E_G$, and $P_v \subseteq P$. Besides, these functions are restricted by the functions of the graph. This means, the global functions apply to subgraphs as well, i.e.,
$$v = (V_v, P_v, E_v, (s_i, t_i)_{i \in \{G, T\}}, \mathfrak{p}, \mathfrak{t}, \mathfrak{o}, l)$$

When a vertex $v \in V$ is not a descriptive component, then it does not contain any sub-component or edge, i.e., $V_v = v, E_v = \emptyset$. In contrast, when a vertex $v \in V$ is the top-level component, then $V_v = V, P_v = P$, and $E_v = E$. The top-level component is not a target of any tree edge.

<figure><img src="image_5.png" /><figcaption>**Fig. 2.** Hierarchical port graph for a half adder. Solid black edges describe connections among ports and dashed grey edges depict hierarchizations of vertices (components).</figcaption></figure>

For an illustrative example, the hierarchical port graph of a half adder is shown in Figure 2. Labels of components and ports are illustrated, e.g. $l(v_0) = “halfAdder”$. The descriptive component $v_0$ indicates a hierarchy, i.e., $\mathfrak{t}(v_0) \in Descriptive$. Where $V_{v_0} = \{v_1, v_2\}$, $P_{v_0} = \{p_0, p_1, ..., p_9\}$ and $E_{v_0} = \{e_0, e_1, ..., e_7\}$. Components $v_1, v_2$ are bitwise XOR and AND respectively.

Ports belong to components, i.e., $\mathfrak{p}(p_i)_{i \in \{0,1,2,3\}} = v_0$, $\mathfrak{p}(p_i)_{i \in \{4,5,6\}} = v_1$, and $\mathfrak{p}(p_i)_{i \in \{7,8,9\}} = v_2$. Directions of ports are: $\mathfrak{o}(p_i)_{i \in \{0,1,4,5,7,8\}} = In$ and $\mathfrak{o}(p_i)_{i \in \{2,3,6,9\}} = Out$. Connections among ports are identified by their source and target ports in the graph:

$$ \begin{aligned} s_G(e_0) &= p_0, t_G(e_0) = p_4 \\ s_G(e_1) &= p_1, t_G(e_1) = p_5 \\ s_G(e_2) &= p_0, t_G(e_2) = p_7 \\ s_G(e_3) &= p_1, t_G(e_3) = p_8 \\ s_G(e_4) &= p_6, t_G(e_4) = p_2 \\ s_G(e_5) &= p_9, t_G(e_5) = p_3 \end{aligned} $$

In a design model, a port might be connected to multiple ports. But connections across hierarchies are forbidden. Therefore, a port such as $p_4$ can only be connected to another port that belongs to the current hierarchy (e.g. $p_0$) or a component in the current hierarchy (e.g. $p_9$). The port direction must be
considered as well. A connection between two ports $p_i, p_j \in P$ is represented as $e_G \in E_G$, e.g. $e_0 = (p_0, p_4)$. Whilst, a tree edge $e_T \in E_T$ describes the hierarchical inclusion between two components $v_i, v_j \in V$, e.g. $e_7 = (v_0, v_2)$.

The uniqueness of labels is only assured inside a design hierarchy and among ports of the same component. Therefore, labels maybe not unique in a design model, e.g. $l(p_4) = l(p_7)$. To locate an exact component, additional hierarchical information is required. To this end, let $\mathfrak{h}$ be a hierarchical path from $v_i$ to $v_j$, where $\mathfrak{t}(v_i) \in Descriptive$. A hierarchical path $\mathfrak{h}$ is a sequence of vertices $v_i, v_{i+1}, ..., v_j$ such that, for any $x = i, i+1, ..., j$, there exists an edge $e_T \in E_T$, that $s_T(e_T) = v_x$ and $t_T(e_T) = v_{x+1}$. That is, the previous descriptive component contains the next component in a hierarchical path.

## 4.2 Design Model Transformation

<figure><img src="image_6.png" /><figcaption>**Fig. 3.** Graph grammar. (a) A rewrite rule consists of a pattern graph $L$ and a rewriting graph $R$. (b) By matching the subgraph $M'$ in host graph $M$ according to the pattern graph $L$, design modifications indicated by the rewriting graph $R$ are inserted automatically to form the transformed graph $N$.</figcaption></figure>

The design model transformation can be referred to as graph rewriting. A graph rewriting is guided by graph grammar, which describes an iterative process of applying a set of rewrite rules on the matched subgraphs in the host graph [26]. For this purpose, the definition of graph morphisms and subgraphs is adapted for hierarchical port graphs.

Let $M$ and $N$ be two hierarchical port graphs. A hierarchical port graph morphism $\mathfrak{f}$ from $M$ to $N$ consists of three functions: $\mathfrak{f}_V, \mathfrak{f}_P$, and $\mathfrak{f}_E$. The interrelations of edges, hierarchical inclusions between components, labels and types of components, labels and directions of ports are preserved, i.e., for any $v_M \in V_M$, $p_M \in P_M$, $e_{M.G} \in E_{M.G}$, and $e_{M.T} \in E_{M.T}$, the following properties hold:

$$ \mathfrak{f}_P(s_{M.G}(e_{M.G})) = s_{N.G}(\mathfrak{f}_E(e_{M.G})) $$

$$ \mathfrak{f}_P(t_{M.G}(e_{M.G})) = t_{N.G}(\mathfrak{f}_E(e_{M.G})) $$

$$ \mathfrak{f}_V(s_{M.T}(e_{M.T})) = s_{N.T}(\mathfrak{f}_E(e_{M.T})) $$

$$ \mathfrak{f}_V(t_{M.T}(e_{M.T})) = t_{N.T}(\mathfrak{f}_E(e_{M.T})) $$

$$ l(v_M) = l(\mathfrak{f}_V(v_M)) \wedge \mathfrak{t}(v_M) = \mathfrak{t}(\mathfrak{f}_V(v_M)) $$

$$ l(p_M) = l(\mathfrak{f}_P(p_M)) \wedge \mathfrak{d}(p_M) = \mathfrak{d}(\mathfrak{f}_P(p_M)) $$
Further, let $M$ be a subgraph of a hierarchical port graph $N$, denoted as $M \subseteq N$, where $V_M \subseteq V_N$, $P_M \subseteq P_N$ and $E_M \subseteq E_N$, and the functions of $M$ are restrictions of those in $N$. For any $v \in V_M$, if $t(v) \in \textit{Descriptive}$, then all sub-components and edges in this descriptive component in $N$ should be included in $M$ as well, i.e., $V_{N.v} \subseteq V_M$, $P_{N.v} \subseteq P_M$, and $E_{N.v} \subseteq E_M$.

<caption>**Algorithm 1: Design Model Transformation**</caption>

**Input** : Host graph $M = (V_M, P_M, E_M, (s_{M.i}, t_{M.i})_{i \in \{G,T\}}, p_M, t_M, \delta_M, l_M)$,
Rules $\mathfrak{R} = \{r_0, r_n, ..., r_n\}$
**Output**: Transformed Graph $N$
Let $N$ be the duplication of $M$
**for** $r = (L, R) \in \mathfrak{R}$ **do**
    $M' = \text{match}(M, L)$
    **for** $v \in V_L$ **and** $v \notin V_R$ **do**
        $V_N = V_N \setminus \{v\}$
    **end**
    **for** $e \in E_L$ **and** $e \notin E_R$ **do**
        $E_N = E_N \setminus \{e\}$
    **end**
    **for** $v \in V_R$ **and** $v \notin V_L$ **do**
        $V_N = V_N \cup \{v\}$
    **end**
    **for** $e \in E_R$ **and** $e \notin E_L$ **do**
        $E_N = E_N \cup \{e\}$
    **end**
**end**
**return** $N = (V_N, P_N, E_N, (s_{N.i}, t_{N.i})_{i \in \{G,T\}}, p_N, t_N, \delta_N, l_N)$

Algorithm 1 describes the graph-grammar-based design model transformation. A graph grammar consists of a set of rewrite rules $\mathfrak{R}$. A rewrite rule $r \in \mathfrak{R}$ consists of two graphs: left-hand-side pattern graph $L$ and right-hand-side rewriting graph $R$ (Figure 3a).

The application of a rewrite rule consists of three steps:

1. *Match* a subgraph $M'$ in host graph $M$ that has a graph morphism from pattern graph $L$ to $M'$ (Figure 3b).

2. *Remove* the components, ports and edges that belong to $L$ but not $R$.

3. *Add* the components, ports and edges that belong to $R$ but not $L$.

In the algorithm, the function `match(M, L)` returns the found subgraph $M'$. During transformations, graph functions such as labeling function $l$ are updated automatically when the host graph is modified.

To find the subgraph $M'$ in host graph $M$, components in $M$ are located for every vertex in $L$ with its hierarchical path, name, and type. Since the name and direction of ports are preserved in the matched subgraph, connections are recognized by locating the linked ports. The located components, ports, and edges compose the matched subgraph $M'$. In doing so, a graph morphism from $M'$ to $L$ is derived. Based on such graph morphism, design modifications described by the rewriting graph $R$ are incorporated automatically to form the transformed graph $N$.
Design construction is a special case of design transformation, where the pattern graph *L* is always a subgraph of the rewriting graph *R* in rewrite rules. That is, the removal of components, ports, and connections is absent in design construction. Inspired by this observation, we use the MetaRTL DSL to not only construct but also transform designs.

## 4.3 Hardware Transformation System

<figure><img src="image_7.png" /><figcaption>**Fig. 4.** Hardware transformation system. Transformation utilities consist of localization, removal, and addition utilities for components, ports, and connections. Making use of these utilities, basic transformations introduce elementary design modifications and are reused to construct complex design-independent and design-specific transformations.</figcaption></figure>

To ease hardware transformation development, a hardware transformation system is developed (Figure 4). Essential operations such as *Localization*, *Removal*, and *Addition* of components, ports, and connections are needed during design model transformations. These operations are performed with the *Transformations Utilities*. Making use of transformation utilities, various *Transformations* are developed. Transformations can be either *Design-Independent* or *Design-Specific* based on their microarchitecture dependencies. In particular, to reduce development efforts, complex design-independent and design-specific transformations introducing systematic design modifications are developed by reusing *Basic* transformations. The basic transformation is developed with high flexibility and introduces the elementary design modification, which affects only a few components, ports, and connections in MoDs.

**Transformation Utilities** During hardware transformation, specific components, ports, and connections are modified to introduce design modifications. For this purpose, hardware transformations start with the localization of target components, ports, and connections. This step is formalized as the first application step of rewrite rules. To assist this step, the MetaRTL DSL offers localization utilities. For example, a simplified component localization function is shown in Listing 1.1.
```python
def componentLocalization(hierarchy, name, comp_type, path, designModel):
    founds = list()
    for comp in hierarchy.getComponents():
        currentHierarchicalPath = getHierarchicalPath(comp, designModel)
        if isinstance(comp, Descriptive):
            foundComps = componentLocalization(comp, name, comp_type, path, designModel)
            founds.extend(foundComps)
        elif currentHierarchicalPath == path:
            if compOSEName == name:
                if isinstance(comp, comp_type):
                    founds.append(comp)
            continue
    return founds
```

<caption>**Listing 1.1.** Component Localization Function. This function localizes a component based on its name, type, and hierarchical path. In doing so, adequate components in the design model are located and returned as a list.</caption>

The shown component localization function has five arguments: the current design *hierarchy*, target component *name*, *comp_type*, its absolute hierarchical *path*, and the *designModel*. First, components under the current design hierarchy are iterated in line 3. The absolute hierarchical path of the iterated component (*comp*) is retrieved with the *getHierarchicalPath* function in line 4. By comparing the retrieved hierarchical path (*currentHierarchicalPath*) to the given path, different steps are followed: If the retrieved hierarchical path is part of the given absolute hierarchical path and the iterated component is a descriptive component (lines 5-6), target components are located in the design hierarchy indicated by the iterated component. Then, the localization process conducts further inside the iterated component in line 7. But if the retrieved hierarchical path is identical to the given absolute hierarchical path, component name and type are then compared (lines 9-11). When all these search criteria are satisfied, the current iterated component is marked in line 12. However, if the retrieved hierarchical path does not satisfy the previous conditions, the component localization function continues to iterate the next component in the current design hierarchy.

After the localization step in model transformations, components, ports, and/or connections are removed from and/or added to located subgraphs to introduce design modifications. During this process, three graph-based operations are observed: remove, add, and replace. The remove and add operations are supported inherently by the MetaRTL DSL [19], while the replace operation is the composition of remove and add operations. For example, an exemplary component replacement function for components with identical port definitions in terms of name, type, and number is shown in Listing 1.2.

The shown component replacement function replaces the *original* component with the *new* component. The target design *hierarchy* is located in line 2. Since both components have identical port definitions, connections linking the ports of the original component are rewired in lines 3-8. To do this, the port *newPort* of the new component is retrieved with the *getPort* function by the name of
```python
def componentReplacement(original, new):
    hierarchy = originalparent
    for port in original.getPorts():
        newPort = newValue=port.getName()
        connections = getConnections(port, hierarchy)
        for connection in connections:
            connection.delConnector(port)
            connection.addConnector(newPort)
    hierarchy.delComponent(original)
    hierarchy.insComponent(new)
```

<caption>**Listing 1.2.** Component replacement function. This simplified function considers only components with identical port definitions in terms of name, type, and number.</caption>

the iterated *port* in line 4. The *connections* linking the iterated *port* under the current design hierarchy are then obtained with the *getConnections* function in line 5. Later, these connections are rewired by replacing the iterated *port* with the *newPort* (lines 6-8). Finally, the original component is removed and the new component is placed under the same design hierarchy (lines 9-10).

Moreover, design details such as the related connections and connected ports of the target port are often required in model transformations. For this purpose, transformation utilities for connections such as *getConnections* in Listing 1.2 are provided. Various transformation utilities are served as the intuitive programming interface for hardware transformation and are the fundament of the hardware transformation system.

**Basic Transformations** Basic transformations introduce elementary design modifications into design models. Exemplary basic transformations are the naming convention transformation and safety mechanism transformations.

A basic transformation for the naming convention has been developed [25] to adapt component and port names to different design projects. That is, specific prefixes and suffixes are often predefined for different design elements to avoid ambiguity and assist readability. For example, ports are named with the prefix “p_”. Also, the name suffix “_i” or “_o” of ports indicates the direction. With this naming convention transformation, component and port names are adapted automatically to meet coding guidelines in the target design project.

Moreover, the transformation system offers basic transformations for various safety mechanisms [27]. Safety mechanisms introduce redundancy into the system to enable error detection (and correction). In doing so, the system is maintained in a safe state and, thus, dangerous consequences caused by malfunctions are reduced. The introduced redundancy has three categories: information redundancy, hardware redundancy, and time redundancy [7]. For introducing information redundancy into the hardware system, basic transformations are provided for parity error detection code, CRC, hamming code, etc. Whilst, basic transformations for hardware redundancy mechanisms such as Dual Modular Redundancy (DMR) and Triple Modular Redundancy (TMR) are also provided. But time redundancy safety mechanisms are software-based [28] and, thus, not offered as basic transformations.
Basic transformations serve as generic transformation building blocks and foster the “transformation library”, since they are developed to encapsulate elementary design modifications with high flexibility. Making use of basic transformations, adequate elementary design modifications are introduced into target microarchitectures, and the complex MoD transformations are developed with reduced efforts.

**Design-Specific/-Independent Transformations** To address aspectual design requirements such as on-chip debug [6] and functional safety [7], design-specific and -independent transformations introduce systematic design modifications to design models. As the name indicates, design-specific transformations are dependent on the microarchitecture and, thus, are applicable to only a set of designs. In contrast, design-independent transformations have no such restrictions and are applicable to all designs.

Design-specific transformations are highly dependent on the microarchitecture. For example, the RISC-V OCD transformation introduces on-chip debug support in a CPU subsystem that implements RISC-V ISA [29]. In this ISA specification, the exception handling and related register behaviors are detailed for RISC-V architecture. If the target architecture does not support the RISC-V ISA, these design details differ and, thus, the RISC-V OCD transformation is not applicable anymore.

In contrast, design-independent transformations are independent of the microarchitecture. For example, a systematic hardware hardening transformation has been developed [27]. This functional safety transformation reuses basic transformations for safety mechanisms to harden sequential components such as registers and memories in a design. Moreover, different design projects may have different coding requirements for e.g. linting checks and code review. Thus, different RTL coding styles may be required. For this purpose, design-independent model transformations have been developed to fine-tune design models to vary IP-coding styles [25].

## 4.4 Quality Assurance

**Model Validation** After transformations, modified design models are validated against design constraints. This validation assures the consistency of design models, which ensures that the generated HDL code is synthesizable. Following design constraints must be satisfied by all design models:

- *Multiple Connections*: For any two connections $e_i, e_j \in E_G$, their source and target can not be identical at the same time.

$$s_G(e_i) = s_G(e_j) \land t_G(e_i) \neq t_G(e_j) \lor$$

$$s_G(e_i) \neq s_G(e_j) \land t_G(e_i) = t_G(e_j) \lor$$

$$s_G(e_i) \neq s_G(e_j) \land t_G(e_i) \neq t_G(e_j)$$
- *Cross-Hierarchy Connections*: Connections across hierarchies are not allowed. To simplify the notation, we introduce a helper function $\mathfrak{s}: V \to V$ that returns the parent component of a component. For any connection $e \in E_G$, its source and target port must belong to the same hierarchy, i.e.,

* if $\mathfrak{t}(\mathfrak{p}(s_G(e))), \mathfrak{t}(\mathfrak{p}(t_G(e))) \notin \textit{Descriptive}$, then

$$ \mathfrak{s}(\mathfrak{p}(s_G(e))) = \mathfrak{s}(\mathfrak{p}(t_G(e))) $$

* if $\mathfrak{t}(\mathfrak{p}(s_G(e))) \in \textit{Descriptive}$ and $\mathfrak{t}(\mathfrak{p}(t_G(e))) \notin \textit{Descriptive}$, then

$$ \begin{aligned} \mathfrak{s}(\mathfrak{p}(s_G(e))) &= \mathfrak{s}(\mathfrak{p}(t_G(e))) \lor \\ \mathfrak{p}(s_G(e)) &= \mathfrak{s}(\mathfrak{p}(t_G(e))) \end{aligned} $$

* if $\mathfrak{t}(\mathfrak{p}(s_G(e))), \mathfrak{t}(\mathfrak{p}(t_G(e))) \in \textit{Descriptive}$, then

$$ \begin{aligned} \mathfrak{s}(\mathfrak{p}(s_G(e))) &= \mathfrak{s}(\mathfrak{p}(t_G(e))) \lor \\ \mathfrak{p}(s_G(e)) &= \mathfrak{s}(\mathfrak{p}(t_G(e))) \lor \\ \mathfrak{s}(\mathfrak{p}(s_G(e))) &= \mathfrak{p}(t_G(e)) \end{aligned} $$

- *Dangling Connections*: For any connection $e \in E_G$, there must exist a source and a target port, i.e.,

$$ s_G(e), t_G(e) \in P $$

- *Valid Connections*: For any connection $e \in E_G$, it must be feasible in terms of port directions. As an exception, a connection is always feasible, if any of the connected ports has the direction "Inout". Thus, following constraints apply to a connection $e \in E_G$ that connects ports with direction either "In" or "Out", i.e., $\mathfrak{d}(s_G(e)), \mathfrak{d}(t_G(e)) \in \{\text{In, Out}\}$.

* If two connected ports belong to components under the same hierarchy, i.e., $\mathfrak{s}(\mathfrak{p}(s_G(e))) = \mathfrak{s}(\mathfrak{p}(t_G(e))),$ then connector directions must differ.

$$ \mathfrak{d}(s_G(e)) \neq \mathfrak{d}(t_G(e)) $$

* If two connected ports belong to components under different hierarchies, i.e., $\mathfrak{s}(\mathfrak{p}(s_G(e))) \neq \mathfrak{s}(\mathfrak{p}(t_G(e))).$ This means, if one of these components is a descriptive component that contains the other connector's parent, then connector directions must be identical.

$$ \mathfrak{d}(s_G(e)) = \mathfrak{d}(t_G(e)) $$

- *Zero-Driven Connections*: Except for input ports of the top component, for any port $p \in P$, there exists $e \in E_G$ such that

$$ t_G(e) = p $$

- *Multi-Driven Connections*: For any two connections $e_i, e_j \in E_G$, they must have different targets.

$$ t_G(e_i) \neq t_G(e_j) $$
- *Unconnected Component*: For any port $p \in P$, it must be connected, i.e., there exists a connection $e \in E_G$ such that

$$s_G(e) = p \lor t_G(e) = p$$

- *Single Hierarchy*: For any component $v \in V$, it must be located in only one hierarchy. This means, for any two hierarchical inclusions $e_i, e_j \in E_T$, their targets must be different.

$$t_T(e_i) \neq t_T(e_j)$$

**Design Verification** To verify the design functionality, two verification suites are employed: existing regressions tests for main functionalities and newly automated formal properties for introduced design modifications.

Existing regression tests consisting of verification artifacts such as testbenches are developed for existing designs. Because the proposed approach targets design aspects, the main functionalities should stay intact. Thus, with adequate additional constraining, transformed designs must behave identically as original designs in regression tests.

Further, a formal property generation framework is used to automate formal properties for introduced design modifications [30]. The meta-information produced by applying a rewrite rule indicates the component and connection modifications. With this information, the property templates developed from design specifications generate suitable formal properties. For example, a rewrite rule is developed to harden a General-Purpose Register (GPR) sp under the register file (RF) with DMR. The DMR inserts a duplicated register sp_copy. A new signal errDet indicates an error when the outputs of sp and sp_copy differ. Afterward, we apply this rule to a design model, where RF is located in the instruction decode stage ID in CPU. Alongside the design transformation, formal properties are generated in SystemVerilog Assertions (SVA) [9] to verify the inserted DMR (Listing 1.3).

```
property RegisterFile_sp_DMR_ErrorFree;
    ( CPU.ID.RF.sp.Out == CPU.ID.RF.sp_copy.Out )
    |->
    ( CPU.ID.RF.sp.errDet == 0 ) ;
endproperty

property RegisterFile_sp_DMR_ErrorDetection;
    ( CPU.ID.RF.sp.Out != CPU.ID.RF.sp_copy.Out )
    |->
    ( CPU.ID.RF.sp.errDet == 1 ) ;
endproperty
```

**Listing 1.3.** Generated properties for DMR transformation. The first property verifies the error-free scenario, whereas the second property is for the erroneous scenario.

By rewriting existing design models following graph-grammar-based design transformations, design aspects are addressed separately from the main functionalities. This separation of design concerns reduces complexity in hardware generators, which can be developed and verified with decreased efforts. Moreover,
the development of hardware transformations is assisted with the transformation utilities and reusable basic transformations provided by the hardware transformation system. After transformation, modified design models are validated by design constraints and formal properties are generated to verify the introduced aspect-oriented instrumentation. In particular, because one DSL is used for design construction and transformation, the proposed approach avoids semantic gaps, lowers integration, and maintenance burdens.

# 5 Case Study

In this section, a case study is conducted on the RISC-V OCD transformation. To demonstrate the applicability, we apply the OCD transformation to different industrial SoCs. Resource utilization and the time to conduct hardware transformations are discussed. Subsequently, the achieved code reusability and required development efforts are analyzed.

## 5.1 RISC-V On-Chip Debug Automation

With the increasing complexity of chips and stringent time to market requirements, post-silicon firmware debug solutions such as In-Circuit Emulator (ICE) becomes rapidly unfavorable because of the high monetary cost and long development time. Whereas, with inexpensive hardware probes, OCD instrumentation provides dedicated debug circuitry for a reasonable area increase. An OCD system provides advanced functionalities such as hardware breakpoints, single stepping, register, and memory accesses [6]. To support these OCD features, system-wide design modifications are required. For instance, the CPU needs to allow external register accesses and the bus matrix needs to support external memory accesses. It is important to note that these design modifications are highly microarchitecture-specific. To separate these design concerns, OCD automation is developed following the proposed transformative hardware design methodology.

<figure><img src="image_8.png" /><figcaption>**Fig. 5.** RISC-V on-chip debug specification metamodel. This metamodel captures the main features of the debug transport module, debug module, and required system-wide support.</figcaption></figure>
For formalizing the OCD requirements, the *On-Chip Debug* metamodel is abstracted from the RISC-V debug specification [6] (Figure 5). Other than design-specific information such as the *Debug Transport Module* (DTM) instruction register length (*IR_Length*), memory offset and size, and the *Number* of supported *Hardware Breakpoints*, *Debug Accesses* can be configured as well. That is, the *Debug Module* (DM) may support different debug accesses: *AbstractCommand*, *ProgramBuffer*, and *SystemBus*. Since it is mandatory to support the GPR access with the abstract command, these debug accesses differ in terms of Control and Status Registers (CSRs) and memory access methods. In this case study, abstract-command-based OCD implementation is used as an example.

The OCD transformation consists of basic transformations for enabling external register access, inserting hardware breakpoint CSRs, supporting breakpoint exception in the exception pipeline, etc. These basic transformations target different system parts and insert design modifications depending on the microarchitecture. In this paper, we focus on basic transformations for two essential design modifications: *register access* and *hardware breakpoint (HWBP)*.

<figure><img src="image_9.png" /><figcaption>**Fig. 6.** On-chip debug transformation of RISC-V CPU. The CPU has a superscalar five-pipeline-stage architecture [31]. For simplicity, only transformation-related design details in the Decode and Execute stages are depicted.</figcaption></figure>

The register access transformation adds several multiplexers for accessing the *GPR and CSR Units* (Figure 6). The GPR unit supports two concurrent register read accesses. These registers are addressed by the *rs1_addr* and *rs2_addr* ports. Ports *rs1_data* and *rs2_data* output respective register data. The write access is supported by the *rd_addr*, *rd_data*, and *wr_en*. They carry the address, data, and write enable signals respectively. In contrast, the CSR unit supports only one concurrent read or write access. Thus, the CSR unit has a much simpler interface: *addr*, *wdata*, *wr_en*, and *rdata*.

The transformation that enables external GPR access is shown in Figure 1.4. In the *transformGPRUnit*, the exception pipeline (*EP*) and GPR unit (*GPRUnit*) are first located in lines 2-3. The signal *bp_sig* provided by the exception pipeline
```python
def transformGPRUnit(designModel, debugModule):
    EP = componentLocalization(designModel, "ExceptionPipeline")
    GPRUnit = componentLocalization(designModel, "GPRUnit")
    bp_sig = EPValue('bp')
    transform_dict = {'rs2_addr': "GPR_addr",
                       'rd_addr': "GPR_addr",
                       'rd_data': "GPR_wdata",
                       'wr_en': "GPR_wr_en",
                       'rs2_data': "GPR_rdata"}
    for orig_sig, debug_sig in transform_iteritems():
        target_port = GPRUnitValue('getPort(Name=orig_sig))
        mux = Mux(Name="{}-mux".format.orig_sig), Sel=bp_sig, parent=GPRUnit
        .Parent)
        connection = getConnection(target_port, GPRUnit._Parent)
        connection.delConnector(target_port)
        connection.addConnector(mux.addIn())
        debug_port = debugModuleValue('getPort(Name=debug_sig))
        mux.addIn().connect.debug_port)
    rs2_data = GPRUnitValue('getPort(Name="rs2_data")')
    GPR_rdata = debugModuleValue('getPort(Name="GPR_rdata")')
    rs2_data.connect(GPR_rdata)
```

**Listing 1.4.** Register accesses transformation of the GPR unit. This transformation locates and rewrites the rs2 and rd of the GPR unit for the read and write access respectively.

indicates whether the CPU enters debug mode or not (line 4). Signals such as `GPR_addr`, `GPR_wdata`, `GPR_wr_en`, and `GPR_rdata` belong to the *debugModule* and indicate the current debug GPR access. For allowing the external GPR access in CPU, a mapping of ports of the GPR unit and DM is defined in lines 5-9. Based on this port mapping, target input ports of the GPR unit are located and their connections are reworked (lines 10-17). In doing so, the target inputs of the GPR unit are re-connected to insert several multiplexers (*mux*). These multiplexers are controlled by the *bp_sig*. That is, when the CPU enters debug mode, the GPR unit is accessed by the DM, otherwise, by the CPU. After, the *rs2_data* signal is connected to the *GPR_rdata* (lines 18-19). Following similar steps, the external CSR access is enabled.

Furthermore, the HWBP transformation transforms specific CSRs [6] in the *CSR unit*: `tselect`, `tdata1`, `tdata2` (Figure 6). The `tdata1` stores the configuration of an HWBP, whereas the `tdata2` stores the comparison data, e.g. target instruction address. For supporting multiple HWBPs, the `tdata1` and `tdata2` are designed as virtual CSRs, where multiple CSRs are accessible with the same CSR address. The `tselect` CSR determines the current accessible HWBP CSRs.

Figure 1.5 illustrates the HWBP transformation in the CSR unit. In this transformation, the target design hierarchy (*CSRUnit*) and `tselect`, `tdata1`, and `tdata2` CSRs are located in lines 8-11. By replacing these original CSRs with the instantiated HWBP CSRs according to the *DebugMoT*, the HWBP transformation is complete (lines 12-14). The component replacement utility (*componentReplacement*) is part of transformation utilities.

Following the transformative hardware design methodology, the OCD transformation serves as the single source for implementing and integrating design-specific OCD support. The proposed approach enables modular OCD development.
<figure><img src="image_10.png" /></figure>

**Listing 1.5.** Hardware breakpoint transformation of the CSR unit. This transformation is simplified, since it only considers the scenarios, when inadequate hardware breakpoint CSRs are already implemented.

ment and, thus, prevents the scattered and tangled design aspects in hardware generators.

## 5.2 Results

Five industrial 32-bit RISC-V SoCs with different feature sets targeting the powertrain market are evaluated. Besides peripherals such as Serial Peripheral Interface (SPI) and timers, the supported ISA extensions differ as well. Other than the base integer instruction set, SoCs may support standard extensions such as compressed instructions [29]. Additionally, customized multiply-accumulate instructions can be supported to boost the execution of machine learning applications. The more features are supported, the more complex is the design as shown in Figure 7.

Since the GPR and CSR units in evaluated SoCs have the same interface, the register access basic transformation introduces the same design modifications. To diversify the inserted design modifications, different amounts of HWBPs are enabled in SoCs, i.e., 4 HWBPs are enabled in SoC¹, SoC² and SoC³, whereas SoC⁴ and SoC⁵ are enabled with 8 and 12 HWBPs respectively.

The resource utilization of SoCs is reported by the Vivado® v2018.1 design tool targeting the Arty-7 FPGA board from Xilinx®. All experiments are conducted on an Intel Xeon CPU E5-2690 v4 machine.

**Design Area** Figure 8 shows the register and Look-Up-Table (LUT) utilization for the SoCs with and without OCD respectively. Resource utilization indicates the design area. A similar design area increase is observed in SoC¹, SoC² and SoC³. With more HWBPs supported, SoC⁴ and SoC⁵ require more resources. The area penalty introduced by OCD cannot be neglected, which implies the importance of the RISC-V OCD automation.
<figure><img src="image_11.png" /><figcaption>**Fig. 7.** Design complexity of experimented SoCs. The complexity is indicated by four factors: the number of components, LoC of the code base, bit width of input, and output ports.</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>**Fig. 8.** Resource utilization before and after RISC-V On-Chip Debug (OCD) transformation. Light colors show the resource utilization of experimented SoCs, whereas dark colors depict utilization changes after RISC-V OCD transformation.</figcaption></figure>

**Transformation Time** The time consumption of transforming an existing design model into a new design model is defined as the transformation time (Figure 9). In general, more components and LoC of an SoC indicate a more complex graph representation in terms of vertices, ports, and edges. The increasing graph elements complicate the first step of the rewrite rule application, i.e., subgraph matching. However, around 1.1s was used to enable external register access for SoCs with different design complexity. The reason is that the proposed approach can match a subgraph efficiently with hierarchical information. Furthermore, a proportional relationship is observed between the number of enabled HWBPs and the transformation time. This shows, the transformation time for HWBPs increases linearly with introduced design modifications and is independent of the
<figure><img src="image_13.png" /><figcaption>**Fig. 9.** Transformation time to apply rewrite rules. The hardware breakpoint rewrite rule introduces more design modifications when more hardware breakpoints are enabled. Whereas, the register access rewrite rule introduces the same design modifications in experimented SoCs.</figcaption></figure>

design complexity of target SoCs. This observation confirms the scalability and efficiency of the proposed methodology.

<table><caption>**Table 1.** On-chip debug development efforts (LoC)</caption><thead><tr><th>Methodology</th><th>SoC<sup>1</sup></th><th>SoC<sup>2</sup></th><th>SoC<sup>3</sup></th><th>SoC<sup>4</sup></th><th>SoC<sup>5</sup></th></tr></thead><tbody><tr><td>Generation</td><td>13.0k</td><td>13.1k</td><td>13.3k</td><td>15.5k</td><td>15.7k</td></tr><tr><td>Transformation</td><td>3.8k</td><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

**Development Efforts** Table 1 shows the required LoCs for hardware *Generation* and *Transformation* developed in the MetaRTL DSL. Following the proposed transformative design methodology, 3.8k LoCs are required to implement the RISC-V OCD automation. Whilst, at least 13k LoCs need to be revisited to implement and integrate the RISC-V OCD instrumentation for evaluated SoCs in the hardware generator. As a result, an LoC gain of more than 3x is observed. Further, the scattered and tangled design aspects are replaced with the proposed design transformation, which promotes further modularity and automation in hardware development. Finally, the development efforts with the proposed approach are shown only for SoC¹ in the second row. This means, the transformation script requires only one-time implementation efforts and is reusable across all evaluated SoC models.
# 6 Conclusion

In this paper, we propose to satisfy emerging aspectual design requirements such as On-Chip Debug (OCD) and functional safety with the transformative hardware design methodology. The proposed methodology is supported by graph-grammar-based model transformations that are implemented as part of a model-driven hardware generation framework. The model transformations enable aspect orientation in the conventional hardware generation. The aspect orientation separates design concerns and assures high modularity in hardware development. As a result, the complexity of hardware generators is reduced since their focal point is the core functionalities. Whilst, the aspect-oriented instrumentation is separately developed and automatically incorporated with model transformations. For easing transformation development, transformation utilities and reusable basic transformations are provided in the hardware transformation system. To assure quality, introduced design modifications are validated against design constraints and formal properties are generated to verify the transformed designs. Of note, we use one DSL to construct as well as transform designs, which prevents semantic gaps and lowers integration and maintenance burdens in hardware development. To demonstrate the applicability, the RISC-V OCD transformation was implemented and applied to different industry-strength SoCs. Compared to the conventional hardware generators, the LoC to develop and integrate the OCD instrumentation is reduced by more than 3x with the proposed transformative methodology. In particular, the transformation script is implemented once and reusable for different SoCs. The achieved high LoC gain and code reuse improve the overall productivity of digital design.

# ACKNOWLEDGEMENTS

The work described herein is partly funded by the German Federal Ministry of Education and Research (BMBF) as part of the research project Scale4Edge (16ME0122K). It has its roots in the BMBF funded projects SAFE4I and COMPACT.

# References

1. O. Shacham, S. Galal, S. Sankaranarayanan, M. Wachs, J. Brunhaver, A. Vassiliev, M. Horowitz, A. Danowitz, W. Qadeer, and S. Richardson, "Avoiding Game Over: Bringing Design to the Next Level," in *DAC Design Automation Conference 2012*, pp. 623–629, IEEE, 2012.

2. J. Bachrach, H. Vo, B. Richards, Y. Lee, A. Waterman, R. Avižienis, J. Wawrzynek, and K. Asanović, "Chisel: Constructing Hardware in a Scala Embedded Language," in *DAC Design Automation Conference 2012*, pp. 1212–1221, IEEE, 2012.
3. A. Izraelevitz, J. Koenig, P. Li, R. Lin, A. Wang, A. Magyar, D. Kim, C. Schmidt, C. Markley, J. Lawson, et al., "Reusability is FIRRTL Ground: Hardware Construction Languages, Compiler Frameworks, and Transformations," in Proceedings of the 36th International Conference on Computer-Aided Design, pp. 209-216, IEEE Press, 2017.

4. J. Clow, G. Tzimpragos, D. Dangwal, S. Guo, J. McMahan, and T. Sherwood, "A Pythonic Approach for Rapid Hardware Prototyping and Instrumentation," in 2017 27th International Conference on Field Programmable Logic and Applications (FPL), pp. 1-7, IEEE, 2017.

5. S. Jiang, P. Pan, Y. Ou, and C. Batten, "PyMTL3: A Python Framework for Open-Source Hardware Modeling, Generation, Simulation, and Verification," *IEEE Micro*, vol. 40, no. 4, pp. 58-66, 2020.

6. N. Tim and W. Megan, "RISC-V External Debug Support Version 0.13.2," tech. rep., SiFive, Inc., 2019.

7. ISO, ISO26262, "26262: Road Vehicles-Functional Safety," *International Standard ISO/FDIS*, vol. 26262, 2011.

8. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin, "Aspect-Oriented Programming," in *European Conference on Object-Oriented Programming*, pp. 220-242, Springer, 1997.

9. S. Marconi, E. Conti, P. Placidi, J. Christiansen, and T. Hemperek, "IEEE Standard for SystemVerilog-Unified Hardware Design, Specification, and Verification Language," 2013.

10. A. Traber, F. Zaruba, S. Stucki, A. Pullini, G. Haugou, E. Flamand, F. K. Gurkaynak, and L. Benini, "PULPino: A Small Single-Core RISC-V SoC," in *3rd RISCV Workshop*, 2016.

11. K. Asanovic, R. Avizienis, J. Bachrach, S. Beamer, D. Biancolin, C. Celio, H. Cook, D. Dabbelt, J. Hauser, A. Izraelevitz, et al., "The Rocket Chip Generator," *EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2016-17*, 2016.

12. D. D. Gajski, A. C.-H. Wu, V. Chaiyakul, S. Mori, T. Nukiyama, and P. Bricaud, "Embedded Tutorial: Essential Issues for IP Reuse," in *Proceedings of the 2000 Asia and South Pacific Design Automation Conference*, pp. 37-42, 2000.

13. W. Ecker, K. Devarajegowda, M. Werner, Z. Han, and L. Servadei, "Embedded Systems' Automation following OMG's Model Driven Architecture Vision," in *2019 Design, Automation & Test in Europe Conference & Exhibition (DATE)*, pp. 1301-1306, IEEE, 2019.

14. H. Ehrig, A. Habel, and H.-J. Kreowski, "Introduction to Graph Grammars with Applications to Semantic Networks," *Computers & Mathematics with Applications*, vol. 23, no. 6-9, pp. 557-572, 1992.

15. M. Moiseev, R. Popov, and I. Klotchkov, "SystemC-to-Verilog Compiler: A Productivity-Focused Tool for Hardware Design in Cycle-Accurate SystemC," in *Design and Verification Conference and Exhibition (DVCon) Europe*, 2020.

16. C. López-Ongil, L. Entrena, M. García-Valderas, and M. Portela-García, "Automatic Tools for Design Hardening," in *Radiation Effects on Embedded Systems*, pp. 183-200, Springer, 2007.

17. M. H. Reshadi, A. M. Gharehbaghi, and Z. Navabi, "AIRE/CE: A Revision Towards CAD Tool Integration," in *ICM 2000. Proceedings of the 12th International Conference on Microelectronics. (IEEE Cat. No.00EX453)*, pp. 277-280, 2000.

18. A. G. Kleppe, J. Warmer, J. B. Warmer, and W. Bast, *MDA Explained: The Model Driven Architecture: Practice and Promise*. Addison-Wesley Professional, 2003.
19. Z. Han, K. Devarajegowda, M. Werner, and W. Ecker, "Towards a Python-Based One Language Ecosystem for Embedded Systems Automation," in *2019 IEEE Nordic Circuits and Systems Conference (NorCAS): NORCHIP and International Symposium of System-on-Chip (SoC)*, pp. 1-7, IEEE, 2019.

20. I. Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board, "IEEE Standard VHDL Language Reference Manual," *IEEE*, 2000.

21. S. Sutherland, "The IEEE Verilog 1364-2001 Standard What's New, and Why You Need It," in *9th International HDL Conference (HDLCon)*, 2000.

22. J. Schreiner, R. Findenigy, and W. Ecker, "Design Centric Modeling of Digital Hardware," in *2016 IEEE International High-Level Design Validation and Test Workshop (HLDVT)*, pp. 46-52, IEEE, 2016.

23. J. Schreiner, F. Willgerodt, and W. Ecker, "A New Approach for Generating View Generators," in *Design and Verification Conference and Exhibition (DVCon)*, Feb 2017.

24. Z. Han, D. Wang, G. Rutsch, B. Li, S. S. Prebeck, D. Sanchez Lopera, K. Devarajegowda, and W. Ecker, "Aspect-Oriented Design Automation with Model Transformation," in *2021 IFIP/IEEE International Conference on Very Large Scale Integration (VLSI-SoC)*, IEEE, 2021.

25. Z. Han, K. Devarajegowda, A. Neumeier, and W. Ecker, "IP-Coding Style Variants in a Multi-layer Generator Framework," in *Design and Verification Conference and Exhibition (DVCon) Europe*, 2020.

26. F. Drewes, B. Hoffmann, and D. Plump, "Hierarchical Graph Transformation," *Journal of Computer and System Sciences*, vol. 64, no. 2, pp. 249-283, 2002.

27. V. B. Bavache, Z. Han, H. Hartlieb, E. Kaja, K. Devarajegowda, and W. Ecker, "Automated SoC Hardening with Model Transformation," in *2020 17th Biennial Baltic Electronics Conference (BEC)*, pp. 1-6, IEEE, 2020.

28. E. Dubrova, *Fault-tolerant design*. Springer, 2013.

29. A. Waterman and K. Asanović, "The RISC-V Instruction Set Manual, Volume I: Unprivileged v," July 2020.

30. K. Devarajegowda, W. Ecker, and W. Kunz, "How to Keep 4-Eyes Principle in a Design and Property Generation Flow," in *MBMV 2019; 22nd Workshop-Methods and Description Languages for Modelling and Verification of Circuits and Systems*, pp. 1-6, VDE, 2019.

31. D. A. Patterson and J. L. Hennessy, "Computer Organization and Design: the Hardware/Software Interface," 2012.