papagenoX: Generation of Electronics and Logic for Embedded Systems

from Application Software

Tobias Scheipel

and Marcel Baunach

Institute of Technical Informatics, Graz University of Technology, Graz, Austria

Keywords:

Embedded Systems, Printed Circuit Board, Design Automation, Hardware/Software Co-design, Systems

Engineering, Reconﬁgurable Logic.

Abstract:

Embedded systems development usually starts with hardware engineering based on speciﬁc requirements

of the systems. These requirements are mainly derived from the needs of the not yet developed software

to be executed on the system. This process is predictive and many iterations are thus needed, as new

requirements often arise during the software development period. In the future, the market will demand

more and more sophisticated embedded systems with a much reduced time to market. It will thus be

inevitable that system prototypes and series products will need to be created as fast as possible. To

enable this, we propose a top-down approach termed papagenoX, dealing with the question of “How to

generate all layers X of the embedded systems stack including hardware and reconﬁgurable logic units

from application software?”. The present work is a work in progress and deals with the deﬁnition of

the research questions and several ideas and concepts of how to fundamentally solve them. Hence, it aims

at introducing ideas to create a generator for embedded systems electronics, reconﬁgurable logic and software.

1 INTRODUCTION

There is currently a common trend in embedded sys-

tems software engineering: code generation. Exam-

ples of this include code generation for Application

Software (ASW) and Basic Software (BSW) from

MATLAB models within automotive Electronic Con-

trol Units (ECUs) (AUTOSAR, 2017), and even Real-

Time Operating Systems (RTOSs) can be ported auto-

matically to other platforms by generating code from

formal models (Gomes and Baunach, 2019). In this

work, we propose a concept going a step further and

generating an entire embedded system with its hard-

ware from software, as illustrated in Fig. 1. Hence,

we formulate the overall research question as “How

can we enable automatic embedded systems genera-

tion from Application Software?”. Hardware in this

case subsumes not only reconﬁgurable logic in Field

Programmable Gate Arrays (FPGAs), but also elec-

tronics on Printed Circuit Boards (PCBs).

Our newly introduced process, which is primarily

designed for prototyping, will also help to evaluate

the intended ASW changes after deployment to

https://orcid.org/0000-0003-0691-6119

https://orcid.org/0000-0002-3716-2682

ASW

(impl.)

(A.)

ASW (exec.)

(D.)

PCB

(C.)

FPGA

(B.)

BSW

Figure 1: papagenoX divided into the main parts, shown in

the stack of an embedded system (impl./exec. = implemen-

tation and executable of the ASW).

quantify the consequences on the lower layers and

thus assess their feasibility and cost. This is espe-

cially important to ﬁnd out if hardware changes in

the system are necessary or if the existing system

is still sufﬁcient to execute the ASW. In addition,

the process is generally designed to drive the use of

reconﬁgurable logic by seamlessly integrating it into

the development and maintenance process.

136

Scheipel, T. and Baunach, M.

papagenoX: Generation of Electronics and Logic for Embedded Systems from Application Software.

DOI: 10.5220/0009159701360141

In Proceedings of the 9th International Conference on Sensor Networks (SENSORNETS 2020), pages 136-141

ISBN: 978-989-758-403-9; ISSN: 2184-4380

The present paper presents the work in progress and is

organized as follows: Section 2 motivates the topic of

embedded systems generation from application soft-

ware. In Section 3, the main idea and the scientiﬁc

approach for papagenoX is outlined. In Section 4 all

the envisioned parts of the concept are discussed in

detail and the overall concept is sketched with an ex-

emplary use case in Section 5. The paper concludes

with Section 6, in which the current state, the progress

made and the future work are explained.

2 MOTIVATION

The common process in embedded systems engi-

neering today usually starts with designing the hard-

ware according to requirements deﬁned in natural lan-

guage. Subsequently, based on educated guesses or

best practices, a prototype is assembled, simulated

and tested. After this step, software development on

the prototype can start. As during software devel-

opment, new requirements can arise, this process is

prone to require multiple iterative redesign cycles in

order to result in a suitable hardware solution. In this

context, software development is much more dynamic

and ﬂexible than the new development of hardware

prototypes. As a result, the prototypes are used for

as long as possible in order to avoid the time and ef-

fort involved in hardware redesign. In some cases,

however, the redesign becomes inevitable, resulting in

many different prototype variants with diverse prop-

erties. AS a result the state of the art is what we

call software development following hardware design

(“software follows or adjusts to hardware”).

With our contribution, we intend to invert the pro-

cess of embedded systems design towards “hardware

follows software”, introduced in detail in the follow-

ing Section 3.

3 SCIENTIFIC APPROACH

WITHIN papagenoX

In order to tackle the problems that arise as described

above, we intend to derive the requirements of a

system under development directly from previously

implemented application code in order to automati-

cally generate suitable and optimized lower layers.

As application code does not explicitly specify dis-

crete components but only functional requirements

(FRs), the analysis shall also consider additional non-

functional requirement (NFR) (e.g., communication

load, data retention time).

We have given our concept the name papagenoX,

an abbreviation for Prototyping APplication-based

with Automatic GENeration Of X, where X is for the

name of the corresponding layer (cf. Fig. 1).

The following structure is proposed to achieve the

envisioned goal: The process starts with ASW de-

velopment (implementation), followed by a thorough

analysis of all its FRs and NFRs. Based on this anal-

ysis, and a library of available hardware and soft-

ware modules, a conﬁguration or selection space can

be opened over all these components, modules, and

possible interconnections. As this selection space can

still contain system conﬁgurations not suitable for the

objective (e.g., due to the unavailability of compo-

nents), further ﬁltering towards special design deci-

sions must be applied. This yields several potential

conﬁgurations composed from different components

that can be optimized again in order to achieve the

best system that is suitable for all requirements. Of

course, optimization and selection metrics are also

based on FRs and NFRs (e.g., cost, size, energy

consumption, Electromagnetic Compatibility (EMC)

characteristics). This process is applied to all three

layers depicted in Fig. 1 in different extent and is ex-

plained in the following sections.

In this work, we additionally envision the use of

FPGAs or System on Programmable Chips (SoPCs)

to build hardware acceleration units by synthesizing

complex algorithms in logic (proper interfacing

included) to add further adaptability.

The fundamental paradigm shift towards “hard-

ware follows software” is mandatory to enable the ut-

most ﬂexibility when designing future embedded sys-

tems. Since we understand established development

methods as being there for a reason, we will also re-

search methods to quantify the suitability of previ-

ously generated hardware conﬁgurations after soft-

ware changes, including possible necessary system

modiﬁcation proposals.

4 ENVISIONED PARTS OF

papagenoX

The toolchain of the papagenoX concept will con-

tain a number of powerful features that facilitate au-

tomatic systems generation. This set of tools can be

divided into four main parts, being (A.) ASW analy-

sis, (B.) BSW generation, (C.) FPGA generation, and

(D.) PCB generation. All those parts are depicted in

Fig. 1 and are discussed in detail below. This work

presents solely the ideas of from a work in progress

concept and only few new ﬁndings at this stage.

papagenoX: Generation of Electronics and Logic for Embedded Systems from Application Software

137

4.1 ASW Analysis

Starting from the analysis of applications, the re-

search question to deal with is “Which information

needs to be included in ASW including NFRs to allow

the creation a embedded system?”. This means that

the requirements of the software to the system must be

extracted and forwarded to the next parts. Since the

ASW to be analyzed does not have to be a stand-alone

executable, the executable part must also be extracted

(cf. dotted arrows in Fig. 1).

The requirements analysis derives a selection

space by using constraint solving and design

space exploration strategies (Saxena and Karsai,

2011)(Nethercote et al., 2007) and logical expression

matching. This selection space contains multiple pos-

sible overall structures of the entire embedded sys-

tem:

• suitable computing platform module(s) and

• other hardware components/modules alongside

their interconnections

• BSW modules and drivers for hardware modules

Furthermore, this step also performs a pre-selection

of algorithms within the code, which are best suited

for mapping to reconﬁgurable logic (FPGAs) in part

(C.).

The results of the requirements analysis is for-

warded to the following parts.

4.2 BSW Generation

The next part deals with BSW generation and the

question on “How can we derive the needed BSW

features from ASW?”. To deal with this question,

we base our approach on our own RTOS, MCS-

martOS (Martins Gomes et al., 2017), as it can

be used with different computing platforms (e.g.,

MSP430 (Texas Instruments, ), RISC-V (Chen and

Patterson, 2016)). This operating system must in-

clude a generic driver management concept enriched

with non-functional properties to allow modular com-

position of hardware modules including resource

sharing mechanisms. Furthermore, such a manage-

ment concept enables optimization towards different

functional and non-functional requirements (e.g., se-

lectable resource management strategies or schedul-

ing algorithms). The output of this part is a BSW tai-

lored to the ASW’s needs.

4.3 FPGA Generation

Parallel to the previous part, the FPGA genera-

tion starts based on the ASW analysis. Here, the

question “How can we extract application speciﬁc

logic and automatically map it to FPGAs?” is ad-

dressed. As software functions are commonly exe-

cuted on Microcontroller Units (MCUs), our contri-

bution aims at hosting application-speciﬁc logic com-

ponents on FPGA platforms, exemplarily depicted as

ﬁlled squares connected to a soft core MCU in the

FPGA module in Fig. 2.

The ASW analysis must discover mapping can-

didate software functions (via, e.g., heuristics) in or-

der to enable this functionality within our generator.

Research is on deciding which functions should be

transferred from software to hardware and how to

generate or interface them with respect to FRs and

NFRs of the ASW (e.g., by transforming a function

call to on-chip I/O operations). We will also inves-

tigate suitable ASW design patterns and program-

ming paradigms to facilitate this process. There-

fore, the entire concept is supported by research on

the creation of a ﬂexible soft-core MCU architecture

for hosting application-speciﬁc logic (based on e.g.,

mosartMCU (Mauroner and Baunach, 2018), RISC-

V (Waterman et al., 2016)). The goal is to work on

consistent development processes, where all system

functions and algorithms are still developed in soft-

ware, but then automatically mapped to on-chip ex-

tensions during compilation and synthesis and inter-

faced accordingly. We are also working on partial

reconﬁguration support at runtime to achieve more

hardware ﬂexibility and simpliﬁed adaptation. In the

expectation of more dynamic software updates, we

must also consider modiﬁcations to the soft-core ar-

chitecture. This is also important because modiﬁable

hardware will be available in the future, but there is

hardly any runtime support for it.

MCU

FPGA

soft

core

PCB

I/O

Figure 2: Hosting application-speciﬁc logic within an em-

bedded system.

4.4 PCB Generation

The part dealing with the lowest layer in the embed-

ded systems stack is sketched in this section. The

SENSORNETS 2020 - 9th International Conference on Sensor Networks

138

attempt is made to answer the questions “What in-

formation is needed to automatically generate PCBs

from ASW?” and “How can this information be used

to generate a PCB prototype matching all ASW re-

quirements?”. These questions can be answered in

two sub-parts by utilizing dedicated hardware mod-

ules as abstractions. The generated board is either a

motherboard, where these modules can be plugged in,

or a single PCB in which all the necessary electrical

components are integrated.

The ﬁrst of the two sub-parts deals with the trans-

lation of constraints to a selection space of possible

system conﬁgurations. This is an abstract process and

does not deal with any electrical properties yet. To

do so, enriched module deﬁnitions must be created.

Our deﬁnitions are based on generic JSON (ECMA

International, 2017) descriptions including not only

their functional, but also their non-functional proper-

ties. This approach allows for possible systems con-

ﬁgurations to be established and a set of suitable con-

ﬁgurations can be ﬁltered out by the toolchain. The

result is an intermediate system deﬁnition. This is be-

cause the electrical feasibility of the connections be-

tween the modules has not yet been considered, and

no dedicated PCB has been generated yet.

In this second sub-part, the interconnection on

electrical level is being dealt with. As stated

in (Scheipel and Baunach, 2019), this sub-part uses an

interconnected intermediate system deﬁnition to con-

vert it into a PCB. Several different inputs are neces-

sary for this:

• hardware module deﬁnition ﬁles and their corre-

sponding design block schematics and board lay-

outs,

• all necessary interface deﬁnitions to adequatly in-

terconnect the previously deﬁned hardware mod-

ules, and

• one dedicated system deﬁnition ﬁle which repre-

sents the overall structure of the embedded system

(cf. ﬁrst sub-part).

With these input ﬁles, schematics and board plans

can be generated. In the ﬁrst step, the output of our

approach is based on the EAGLE (Autodesk, Inc., )

XML format.

5 USE CASE EXAMPLE

An idea to create an embedded system shall be de-

rived from the need of observing or controlling some

speciﬁc (physical) process. In our case, it starts with

the need of “measuring distances for further process-

ing in a car”. This requirements deﬁnition in natural

language spans a selection space of a great number

of components and software possibilities for imple-

menting our system. As the engineer knows that there

is a need to “measure distance” (I.) and send the dis-

tance values to be “further processed in a car” (II.),

application software development for the use case can

start by using generic Application Programming In-

terfaces (APIs):

1: [...]

2: read_distance(&distance,

SensorType.Automotive);

3: send_data(&rec, &distance,

CommType.Automotive);

4: [...]

This piece of pseudo-code written by the engi-

neer to meet the requirements in language speciﬁes

these requirements in more detail, narrowing down

the list of components to be considered. In line 2,

distance data is read from an automotive-grade sensor

(requirement I.; technology need not be speciﬁed in

detail). Subsequently, it is sent to the recipient rec

over some automotive in-car communication technol-

ogy (requirement II.; again, not speciﬁed in detail) in

line 3. These abstract requirements could also be lists

of requirements for further speciﬁcation.

The next few lines try to give an impression on

how papagenoX tackles the automatic system gener-

ation. Part (A.) has already started with the use of

certain APIs and is carried out ﬁrst (cf. Fig. 1). It se-

lects a suitable BSW with drivers and services for part

(B.), and selects hardware components for part (D.).

In the analysis part (A.), the requirements are

examined more closely in order to obtain a better

overview of the actual needs of the ASW. The analysis

goes hand in hand with the other parts of the concept.

Subsequently in (B.), the BSW containing an Op-

erating System (OS) is assembled, including all APIs

and necessary drivers to use the hardware components

selected in part (D.). A tailored version of MCS-

martOS with a generic driver platform is utilized for

this reason. The set of features to enable this func-

tionality is currently under development.

In part (D.), from the set of all possible hard-

ware components and modules several possible sys-

tem conﬁgurations can arise. To simplify the explana-

tion of our use case, the PCB generation part then se-

lects a system containing: a ultra-sonic sensor of type

HC-SR04 (Cytron Technologies, 2013) for require-

ment (I.), and a CAN (International Organization for

Standardization, 2015) transceiver with a controller

for requirement (II)., both connected to a MSP430

LaunchPad™ (Texas Instruments, 2017) as a comput-

ing platform.

Finally, the requirement “measuring distances for

papagenoX: Generation of Electronics and Logic for Embedded Systems from Application Software

139

MSP430 LaunchPad

CAN Transceiver

CAN Controller

ULTRASONIC-HC-SR04

Figure 3: The generated PCB with module placeholders of the explained use case for measuring distances in a car.

further processing in a car” and two lines of code cre-

ate the embedded system depicted in Fig. 3.

6 CONCLUSION AND FUTURE

WORK

In the course of this work we presented a novel ap-

proach on how to generate an entire embedded system

when only having application code at hand. All the

ideas presented are from our current work in progress.

As our approach aims at inverting the state-of-the-art

process of embedded systems design from “software

follows hardware” to “hardware follows software”,

this opens up new questions in the context of soft-

ware analysis, and hardware, logic and software gen-

eration.

Since this is a work in progress, not all of its

parts have yet been implemented. To date, hardware

generation on PCB-level is already implemented and

partially published, but there is room for improve-

ment throughout the concept. Future steps include

the improvement of constraint matching mechanisms

for hardware module selection, the improvement of

the requirements analysis and the entirety of the re-

conﬁgurable logic generation part. Also, the BSW

layer must be constantly improved in order to meet

the future demands on the concept. As papagenoX is

generic and module based, it can be easily adopted to

different domains in the future. Lowering of the mod-

ule granularity to, e.g., electrical components level

(resistors, capacitors, integrated circuits, and so on)

is possible. The next steps in this work are to ﬁnish

the PCB generation alongside the ASW analysis for

FRs and NFRs.

REFERENCES

Autodesk, Inc. EAGLE. [retrieved: Nov, 2019].

AUTOSAR (2017). Classic platform release 4.3.1.

Chen, T. and Patterson, D. A. (2016). RISC-V Geneology.

Technical Report UCB/EECS-2016-6, EECS Depart-

ment, University of California, Berkeley.

Cytron Technologies (2013). HC-SR04 User’s Manual.

ECMA International (2017). ECMA-404: The JSON Data

Interchange Syntax, 2 edition.

Gomes, R. M. and Baunach, M. (2019). Code generation

from formal models for automatic rtos portability. In

2019 IEEE/ACM International Symposium on Code

Generation and Optimization (CGO), pages 271–272.

International Organization for Standardization (2015). ISO

11898: Road vehicles – Controller area network

(CAN) , 2 edition.

Martins Gomes, R., Baunach, M., Malenko, M.,

Batista Ribeiro, L., and Mauroner, F. (2017). A Co-

Designed RTOS and MCU Concept for Dynamically

Composed Embedded Systems. In Proc. of the 13th

Workshop on Operating Systems Platforms for Em-

bedded Real-Time Applications, pages 41–46.

Mauroner, F. and Baunach, M. (2018). mosartMCU: Multi-

Core Operating-System-Aware Real-Time Microcon-

troller. In Proc. of the 7th Mediterranean Conference

on Embedded Computing, pages 1–4.

Nethercote, N., Stuckey, P. J., Becket, R., Brand, S., Duck,

G. J., and Tack, G. (2007). MiniZinc: Towards a Stan-

dard CP Modelling Language. In Bessi

ere, C., edi-

tor, Principles and Practice of Constraint Program-

SENSORNETS 2020 - 9th International Conference on Sensor Networks

140

ming – CP 2007, pages 529–543, Berlin, Heidelberg.

Springer Berlin Heidelberg.

Saxena, T. and Karsai, G. (2011). A meta-framework for

design space exploration. In 2011 18th IEEE Interna-

tional Conference and Workshops on Engineering of

Computer-Based Systems, pages 71–80.

Scheipel, T. and Baunach, M. (2019). papagenoPCB:

An Automated Printed Circuit Board Generation Ap-

proach for Embedded Systems Prototyping. In ICONS

2019 - The Fourteenth International Conference on

Systems, pages 20–25.

Texas Instruments. MSP430 ultra-low-power sensing and

measurement MCUs.

Texas Instruments (2017). MSP430F5529 LaunchPad™

Development Kit (MSP--EXP430F5529LP).

Waterman, A., Lee, Y., Patterson, D. A., and Asanovic, K.

(2016). The RISC-V Instruction Set Manual, Vol-

ume I: User-Level ISA, Version 2.1. Technical Report

UCB/EECS-2016-118, EECS Department, University

of California, Berkeley.

papagenoX: Generation of Electronics and Logic for Embedded Systems from Application Software

141