Binary Synthesis Implementing External Interrupt Handler as
Independent Module
Naoya Ito⇤Kwansei Gakuin University
School of Science and Technology
Sanda, Hyogo, Japan

Yuuki Oosako

Kwansei Gakuin University
School of Science and Technology
Sanda, Hyogo, Japan

Hiroyuki Kanbara

Nagisa Ishiura

Kwansei Gakuin University
School of Science and Technology
Sanda, Hyogo, Japan

Hiroyuki Tomiyama

ASTEM RI Kyoto
Kyoto, Japan

Ritsumeikan University
College of Science and Engineering
Kusatsu, Shiga, Japan

ABSTRACT

1This article presents a method of synthesizing hardware from agiven executable binary code with an external interrupt handler,
where the normal �ow and the interrupt handling are executedby separate hardware modules. Our previous method synthesized
the whole program into a single hardware module, in which register save/restore imposed limitations on the timing to start interrupt handling and also impaired e�ciency of the synthesized
hardware. By executing the two tasks on separate modules, registersave/restore can be eliminated, which allows interrupt handler tostart at arbitrary timing and reduces the response time and cost of
the hardware. By allowing two processes to run in parallel, total execution time is also reduced. An experiment with a simple program
has shown that the execution cycles and the delay were reduced
by about 80% and 20%, respectively, as compared with MIPS CPU.
A motor controller driven by periodical interrupts from a timer
has been successfully synthesized from C and assembly programs,
which runs more than 20 times faster than the MIPS CPU.

While embedded systems are getting increasingly rich in functionality, higher and higher performance is required within limited power
consumption. To implement such systems e�ciently within limited
design periods, there have been a lot of attempts to utilize high-level
synthesis technology [1] to automatically design hardware fromexisting software [3, 4].
Binary synthesis [2] is a kind of high-level synthesis which takes
binary codes, instead of programs in high-level programming languages, as its inputs. Binary synthesis can handle wider range ofprograms than high-level synthesis and hence it is suitable for translating programs originally developed as software into hardware.
However, applications where processors control external devices,the programs contain interrupt processing.
Ando et al. [5] proposed a method of synthesizing dedicatedhardware driven by interrupts from an abstract system model that
captured interrupts, interrupt handlers, and communication amongdevices. Each process may be implemented as either software or
hardware according to the designer’s choice. However, regardlessof the choice, a CPU was always necessary in the resulting system.
On the other hand, in our team’s previous work [6], a method
was proposed which converted a given binary program containing
an external interrupt handler into hardware whose behavior was
equivalent to the CPU running the program. No rewriting was required on the binary program and the resulting hardware ran fasterthan the program on the CPU. However, in this method, jumps tothe handler were allowed only at the end of the basic blocks, whichhinders quick response to interrupts. Moreover, save/restore of registers took time even on the hardware for it resulted in sequential
memory accesses.
We have found that the bottleneck was caused by register save/restore for context switching. Based on this observation, we propose
in this paper a method of extending the previous method so that amain process and an interrupt handler are synthesized into separate
hardware modules. Since the two modules hold their own context,
operations for register save/restore will be eliminated. This allows
the interrupt handler to start execution without waiting for themain process to reach at the end of the basic blocks. Furthermore,
two modules may run in parallel, which drastically reduces thetotal execution time.

CCS CONCEPTS• Hardware → Hardware-software codesign; • Computer systems organization → Embedded hardware;

KEYWORDS
High-level synthesis, binary synthesis, interrupt handling
ACM Reference Format:
Naoya Ito, Yuuki Oosako, Nagisa Ishiura, Hiroyuki Kanbara, and Hiroyuki
Tomiyama. 2017. Binary Synthesis Implementing External Interrupt Handler
as Independent Module. In Proceedings of RSP’17, Seoul, Republic of Korea,
October 15–20, 2017, 7 pages.
https://doi.org/10.1145/3130265.3130317⇤ Currently with Murata Manufacturing Co., Ltd., Nagaokakyo, Kyoto, Japan

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor pro�t or commercial advantage and that copies bear this notice and the full citationon the �rst page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior speci�c permission and/or afee. Request permissions from permissions@acm.org.
RSP’17, October 15–20, 2017, Seoul, Republic of Korea© 2017 Association for Computing Machinery.
ACM ISBN 978-1-4503-5418-9/17/10. . . $15.00
https://doi.org/10.1145/3130265.3130317

92

INTRODUCTION

RSP’17, October 15–20, 2017, Seoul, Republic of Korea
asm

C

gas

gcc

-32756 -32760

library info

+ lw +

optimizationL

objdump

CDFG generator

While ACAP can transform user speci�ed sections of linked
executable code into a hardware accelerator which is tightly coupledwith the CPU, it can also synthesize a whole linked executablecode into a hardware module which is compatible with the CPU
that runs the code. This paper utilizes the the latter mode where
the synthesized hardware module can replace the CPU and the
instruction memory. The source program may be written in C
language or assembly/machine language, and may be linked withstart-up routines and library codes for �oating point emulation,
string processing, etc. Synthesized hardware is expected to run
faster than MIPS, due to instruction level parallelism and operation
chaining. The hardware size is roughly proportional to the numberof instructions in the input binary code, so trade-o�s between
speed-up and hardware cost need to be considered.

CDFGMIPS binary...
lw v1,-32756(gp)lw v0,-32764(gp)nopaddu v0,v1,v0
sll v0,v0,0x2
sw v0,-32760(gp)...

N. Ito et al.

lw

Lschedulingbinding+ addu-32764
<<

+
S

sw

sll

RTL IR
composer
Verilog
HDL

Figure 1: Flow of synthesis in ACAP.

2.2
The proposed method has been implemented on top of binary
synthesizer ACAP [3]. An experiment with a simple program has
shown that the execution cycles and the delay were reduced byabout 80% and 20%, respectively, as compared with MIPS CPU, at
the cost of 40% increase in the hardware cost. A motor controller
driven by periodical interrupts from a timer has been successfully
synthesized from C and assembly programs, which runs more than
20 times faster than the MIPS CPU.

2

BINARY SYNTHESIS OF MIPS INTERRUPTHANDLING
2.1 Binary Synthesis and ACAP
High-level synthesis takes behavioral speci�cation as inputs which
are usually written in high-level languages such as C. However, thebehavior may be speci�ed also in assembly or machine languages,
and such synthesis techniques are called binary synthesis [2]. It
can handle wider range of software programs than conventional
high-level synthesis, although back-end technologies to generate
hardware are common. While binary synthesis can be used to convert some computationally intensive parts of given software programs, it can also convert a whole binary code into a hardware
module which is functionally equivalent to the processor runningthe program.
ACAP [3] is a binary synthesizer which generates hardware from
MIPS R3000 binary codes. As shown in Figure 1, it takes a MIPS
executable binary generated by GCC from C programs or by GAS
from hand coded assembly programs. It disassembles (by objdump)
a binary code to recover an assembly program, and converts it into
a CDFG (control data�ow graph); an instruction sequence in eachbasic block is translated into a DFG (data�ow graph), and jumps andbranches are compiled into transitions among the DFGs (delayedbranches/jumps are properly recognized). Register jumps, used for
multiway branches and return from subroutines/interrupt handlers,
are handled by constructing a table that translates instruction address into the IDs of the corresponding DFGs. ACAP itself does notdistinguish privilege modes; all the instructions might be executed
as if it were in the kernel mode. It then performs scheduling andbinding to generate a Verilog HDL code based on typical high-level
synthesis algorithms.

93

Interrupt Handling of MIPS R3000

MIPS R3000 handles interrupts by using CP0, the system control
coprocessor, which is embedded in the CPU. CP0 has the following
three registers to handle external interrupts.
• EPC registerkeeps the PC (Program Counter) value at which the interrupt
is triggered.
• Cause registerkeeps the information regarding the cause of the interrupt,
i.e., whether it is an external interrupt, an internal interrupt,
or a system call, and also its detailed cause in the case of an
external interrupt.
• Status registerkeeps the system’s status information such as the execution
mode (the user mode or the kernel mode), and the interrupt
mask.
When an interrupt signal is sent from an external device to CP0,
it is handled in the following way. The �ow assumes only singlelevel interrupts; during interrupt handling, all the other interrupts
are ignored.
(1) CP0 saves the PC value and the cause of the interrupt in
the EPC register and the Cause register, respectively, andupdates the Status register so that the system may run in
the kernel mode and the other interrupts will be prohibited.
(2) CP0 sends an interrupt execution signal to the CPU, andwrites the starting address of the interrupt handler into PC
so that the CPU will jump to the handler.
(3) The handler saves the values of the general purpose registers
to the main memory and calls the routine corresponding to
the cause in the Cause register.
(4) After the routine �nishes its task, the handler restores thegeneral purpose registers.
(5) The handler restores the execution mode and clears interrupt
prohibition, and the address in the EPC register is written
back to PC so that the CPU can resume execution (or justjumps to the speci�ed address for error handling).
To handle interrupts, the following instructions are used.
• mfc0 and mtc0 (move from/to CP0)
Instruction mfc0 rt,rd moves the value in a CP0 register rd toa general purpose register rt, and mtc0 rt,rd does the move

Binary Synthesis Implementing External Interrupt Handler as Independent ModuleRSP’17, October 15–20, 2017, Seoul, Republic of Korea
imem

dmem

dmem
dmem

handlermain

HW_sigint_sig
ESTATE

Device...

handler
CPU

CP0

State
MachineDevicemain

Datapath

HardwareHardwareFigure 2: Synthesis from binary code with interrupt handler.

Figure 3: Con�guration of the synthesized hardware in [6].

in the opposite way. Those instructions are used to access to
the EPC, Cause, and Status registers.
• rfe (return from exception)
It is executed at the end of the interrupt handler and restoresthe execution mode and the interrupt permission.

DFG3(Handler)

DFG1

(1)

s0

+

-

s20

+

s1

-

+

s21

-

s2

+

s3

+

s22

Synthesis from Binary Codes Containing
Interrupt Handler [6]-s8(1) The interrupt signal is sent to CP0.
(2) The interrupt execution signal from CP0 is latched in the
int_sig register.
(3) At the last state (s3) of DFG1, int_sig is tested. If it is 1, thenext state of s3 (s8) is saved in the ESTATE register as thereturn state, and the hardware jumps to the starting state(s20) of the interrupt handler (Handler).
(4) At the initial state of the handler, int_sig is cleared.
(5) At the last state (s28) of the last DFG (DFG4) of the handler,
the status is restored and the hardware returns to the state
saved in the ESTATE register.
The proposed method allows jumps to the handler only at theend of the DFG. This is because register save and restore are done
precisely as written in the handler code. However, high-level synthesizers generally generate extra registers to keep intermediate
values, which are not saved nor restored in the interrupt handler.
Therefore, if interrupts occur during execution of big basic blocks,
start of interrupt handling will be delayed.

94

+

+

(3)

DFG2

In [6], a method of synthesizing hardware from programs containing external interrupt handlers was proposed. As illustrated in
Figure 2, it translates a linked executable code including an interrupt handler to a hardware module, which replaces the CPU and
the instruction memory.
The structure of the hardware generated by this method is shownin Figure 3. The hardware has CP0 of MIPS R3000 as a functional
unit along with three registers HW_sig, int_sig, and ESTATE. The
�ow of interrupt handling is as shown in Figure 4. DFG1 through
DFG4 are DFGs (data�ow graphs) corresponding to the basic blocks
of a given program, and s0 through s28 are states (control steps).
DFG1 and DFG2 are for the normal task and DFG3 and DFG4 arefor the interrupt handler. An external interrupt triggered during
the execution of DFG1 is processed in the following way.

(5)

s9
s10

-

(4)

(4)
ESTATE
s8

DFG4
s26

...

2.3

int_sig

(2)

CP0

+

s27

-

-

s28

rfe

jr

+
+

(6)

Figure 4: Interrupt handling in [6].
Moreover, in this method, synthesized hardware must save/restore
registers, just as CPUs. Since this ends up with sequential memory
accesses, even hardware needs almost as much cycles as the CPU.

3

SYNTHESIZING INTERRUPT HANDLER
INTO SEPARATE HARDWARE
3.1 Overview
In order to solve the problem, we propose in this paper a binary
synthesis method that synthesizes an interrupt handler into a separate hardware module. Henceforth, we will call a hardware module
to compute normal execution �ow the main module, and a module
to handle interrupts the handler module. The both modules holdtheir contexts in their own register sets so that register save/restore
operations will be eliminated and the handler module can start
execution at an arbitrary timing. Moreover, the main module may
continue its execution while interrupts are being handled.
In this paper, we assume binary programs for MIPS R3000, andmake the following assumptions.
• Only external interrupts (hardware interrupts) are supported.
Internal interrupts (software interrupts) are out of the scopeof this paper. However, system calls can be synthesized toenable mutual exclusion.
• The interrupt handler cannot refer to the instruction address
where the interrupt occurred nor access to the instruction
memory.

RSP’17, October 15–20, 2017, Seoul, Republic of Korea

N. Ito et al.
handler module

dmem
CP0
HW_sigint_sig

Device...

CP0

Devicek0StateMachine(3)
set

int_sig

(4)

Data
path
handler module

s20

+

s21

-

s22

(5)
Data
path
main module

+

DFG4
s26
s27

Figure 5: Con�guration of the hardware synthesized in the
proposed method.

clear

s28

+

(5)

...

State
MachineHardware

(4)

DFG3

(2)

k1

(1)

s0

+
-

rfe

Figure 6: Interrupt handling in the proposed method.
• Multilevel interrupts are not supported. Any other interrupts
during interrupt handling are ignored.
Basically, binary programs are synthesized into hardware without rewriting, but user must specify which parts of the input program are assigned to the handler module. This is speci�ed by meansof pragmas in the assembly code (obtained by disassembling the
input binary).

3.2

Flow of Interrupt Processing

The con�guration of the hardware synthesized by the proposed
method is shown in Figure 5. Like in the previous con�guration, it
has CP0 along with the registers HW_sig and int_sig. Each of themain module and the handler module has an independent set of a�nite state controller, a datapath, and registers. For the purpose of
sharing data on system calls, two registers k0 and k1 are provided.
The �ow of interrupt processing is shown in Figure 6, where
DFG3 and DFG4 are of the interrupt handler and s0 ⇠ s28 are states(control steps). Basically, the handler module runs independently ofthe main module. Detailed steps for interrupt handling is as follows.
(1) The handler module waits at the initial state s0, polling the
int_sig register.
(2) The interrupt signal is sent to CP0.
(3) The interrupt execution signal from CP0 is latched in the
int_sig register.
(4) As soon as int_sig becomes 1, the handler module jumps tos20 and executes DFG3 and DFG4.
(5) When interrupt handling is �nished (at s28), the handler
module resets int_sig and returns to s0.
Unlike the method in [6], the main module may continue its
execution while the handler module is running. If there is a needfor serialization or mutual exclusion between the main moduleand the handler module, we assume that it is implemented in themachine program by using system calls, as explained in the next
subsection.

3.3

Mutual Exclusion and System CallIn the MIPS R3000 convention, mutual exclusion is realized bydisabling interrupts (CPU lock). This is done via the system call
instruction (syscall). The syscall instruction switches the CPU state95

to the kernel mode and transfer control to the interrupt handler,
where interrupts are disabled by updating the Status register.
In the case of single core execution, syscall will never be executed by the main routine during a certain external interrupt ishandled by the interrupt handler (because the main routine is idle
while the interrupt handler is running). However, in the case of ourhardware con�guration, this may happen, because two modules
may run in parallel. In order to guarantee the equivalence of the behavior between the original machine program on the CPU and thesynthesized hardware, we let the main module postpone executionof syscall until the handler module completes its task.
This is implemented by translating syscall into the three state
operations.
(1) Test if the handler module is executing its task. If yes, goto(2). Otherwise goto (3).
(2) Wait until the handler module completes its task and thengoto (1).
(3) Wait until the handler module to complete the task for syscall,and goto the next state. All the external interrupts occurring
during this state are ignored.
We assume a calling convention that the kernel stack pointeris passed in register k0 and the syscall function is speci�ed in k1.
In our method, where the two modules have independent register
sets, we somehow transfer data in the two registers. We do this
via two external registers, depicted as k0 and k1 in Figure 5. After
CDFG generation, operations to store k0 and k1 to the two externalregisters are inserted just before syscall operations in the main
module, and operations to load the two registers are added in thehead DFG of the handler module.

3.4

Deletion of Save/Restore Codes

In our method, the handler module does not have to save/restore
registers. However, the save/restore codes are written in the given
input binary codes, which must be deleted during the synthesis.
This is done just after the CDFG generation.
• Register save operations

Binary Synthesis Implementing External Interrupt Handler as Independent ModuleRSP’17, October 15–20, 2017, Seoul, Republic of Korea(1) In the head DFG of the handler module, all the store operations that attempt to store unde�ned registers are recognized as save operations and are deleted.
(2) All the operations, whose destinations are temporary registers (created during CDFG generation) and are not referred
to afterwards, are also deleted.
• Register restore operations(1) In the DFGs that contain rfe operations, all the load operations that attempt to load to registers which will neverbe referred to are regarded as restore operations and aredeleted.
(2) All the operations, whose destinations are temporary registers and are not referred to afterwards, are deleted.

01 #include interrupt_lib.h02
03 void filtering(int width, int height);
04 void int_getpixel(void);
05 void int_average(void);
06
07 #include pixel.h08
09 int filter[3][3]={10 {0, 1,0},
11 {1,-4,1},
12 {0, 1,0}13 };1415 unsigned char pixel_out[MAX_Y][MAX_Y];
16
17 volatile int in_x1=-1,in_y1=-1,in_x2=-1,in_y2=-1;
18 volatile int output=-1;
19
20 int main(void) {21 init_interrupt();
22 register_exc_handler(EXC_Int0,int_getpixel);
23 register_exc_handler(EXC_Int1,int_average);24
25 filtering(MAX_X,MAX_Y);
26
27 return 0;28 }29
30 void filtering(int width, int height) {31 int i,j,h,w,buf;
32 int filter_len=sizeof(filter[0])/sizeof(int);
33 int outer=filter_len/2;
34
35 for (i=0;i<height;i++) {36
for (j=0;j<width;j++) {
37
if (
38
(outer<=i&&i<height-outer)&&39(outer<=j&&j<width-outer)
40
) {
41
buf=0;
42
for (h=0;h<filter_len;h++) {43
for (w=0;w<filter_len;w++) {44
buf+=pixel[i+h-outer][j+w-outer]*filter[h][w];
45
}
46
}
47
pixel_out[i][j]=48(buf < 0) ? 0 :49(buf > 255) ? 255 :50(unsigned char)buf;
51} else {52
pixel_out[i][j]=pixel[i][j];
53
}
54
}
55 }
56 }
57
58 void int_getpixel(void) {59 if (
60!((0<=in_x1&&in_x1<MAX_X)&&
61(0<=in_y1&&in_y1<MAX_Y))62 ) {return;}
63
64 output=(int)pixel_out[in_y1][in_x1];
65 }66
67 void int_average(void) {68 int i,j;
69 int sum=0;70 int count=0;
71 if (
72!((0<=in_x1&&in_x1<=in_x2&&in_x2<MAX_X)&&73(0<=in_y1&&in_y1<=in_y2&&in_y2<MAX_Y))74 ) {return;}
75
76 for (i=in_y1;i<=in_y2;i++) {77
for (j=in_x1;j<=in_x2;j++) {78
sum += pixel[i][j];79
count++;
80}81 }82 output=(int)(sum/count);
83 }4 EXPERIMENTAL RESULTS
4.1 Synthesis
The proposed synthesis method has been implemented on top ofbinary synthesizer ACAP. It is implemented by Perl5 and runs on
Linux and Mac OS X, and outputs RTL description in Verilog HDL.
The test program is shown in Figure 7. Function main (lines
20–28) calls function �ltering (lines 30–56) which performs Laplacian �ltering (the function is called just once for the purpose ofmeasuring execution cycles). Functions int_getpixel (lines 58–65)
and int_average (lines 67–83) are service routines for external interrupts; int_getpixel returns the pixel value of a speci�ed coordinate,
and int_average the average pixel values in a speci�ed rectangle
region. The coordinates are given in variables in_x1, in_y1, in_x2,
in_y2 and the result is stored in variable output.
The program shown in Figure 8 is the interrupt handler [6].
When an external interrupt occurs, CPU �rst jumps to the top of
the handler. The handler 1) saves the general purpose registers,2) saves the return address, 3) calls the interrupt service routine
function, 4) restores the general purpose registers, and 5) returns
from the interrupt.
The program shown in Figure 9 is a collection of library functions
for interrupt handling which is written in C and inline assembly [6].
Function init_interrupt (lines 7–12) registers interrupt service routine execution function run_exc_handler (lines 21–42), which arecalled from the interrupt handler, and a routine run_syscall_handler(lines 44–54) for system call (EXC_Sys). Function int_prohibition(lines 56–60) is an interface function to set interrupt prohibition bycalling run_syscall_handler through system call and then, calling
int_prohibiton_func (lines 62–69). Function int_permission (lines
71–76) sets interrupt permission.
All the programs were compiled/assembled and linked into asingle binary code executable on MIPS R3000 processor. After con�rming the behavior of the program by running the processor in
RTL simulation where external interrupts were given from the
testbench, hardware is synthesized by extended ACAP. It was con�rmed that the memory dumps of variable output obtained by the
MIPS processor and by the hardware agreed. It was also con�rmedthat the main module continued its execution while the handler
module was processing its tasks.

96

Figure 7: Test program.

4.2

Performance Evaluation

Logic synthesis was performed on the Verilog HDL description
generated by ACAP. The logic synthesizer was Xilinx ISE 14.3 andthe target was FPGA Xilinx Spartan-3E.
The result is shown in TABLE 1. “MIPS” indicates software execution on MIPS softcore processor, “HW [6]” and “HW (proposed)”stand for synthesized hardware by the method in [6] and the proposed method, respectively. “Slices” of MIPS includes estimatedcost of the instruction memory; one instruction (32bit) is assumed
to cost one slice. “Delay” is the critical path delay. Subcolumn “total(0)” under “Cycles” is the total number of execution cycles when the

RSP’17, October 15–20, 2017, Seoul, Republic of Korea

N. Ito et al.

; 1) Storing values of general registers
80000080: lui k0,0xc000
80000084: ori k0,k0,0x90
80000088: sw at,4(k0)8000008c: sw v0,8(k0)80000090: sw v0,12(k0)...
800000f8: sw sp,116(k0)800000fc: sw s8,120(k0)80000100: sw ra,124(k0); 2) Storing the return address
80000104: mfc0 ra,c0_epc
80000108: nop
8000010c: sw ra,0(k0); 3) Calling the interrupt service routine execution; function
80000110: lui ra,0xc000
80000114: ori ra,ra,0x2c
80000118: lw t0,0(ra)8000011c: nop
80000120: beqz t0,80000134
80000124: nop
80000128: jalr t08000012c: nop
80000130: nop; 4) Recovering values of general registers
80000134: lui k0,0xc000
80000138: ori k0,k0,0x90
8000013c: lw at,4(k0)80000140: lw v0,8(k0)80000144: lw v1,12(k0)...
800001b0: lw sp,116(k0)800001b4: lw s8,120(k0)800001b8: lw ra,124(k0); 5) Returning from the interrupt
800001bc: lw k0,0(k0)800001c0: nop
800001c4: jr k0
800001c8: rfe
800001cc: nop

Figure 8: Interrupt handler [6].
main routine in Figure 7 was executed without any interrupt. Subcolumns “int (1)” and “total(1)” are for the cases where interrupts for
int_getpixel were raised 1,000 times; “int (1)” is the average numberof cycles taken from the occurrence of an interrupt to �nish the task
for the interrupt, and “total (1)” the number of the total execution
cycles. Subcolumns “int (2)” and “total(2)” are for the cases whereinterrupts for int_average for 40 ⇥ 30 pixels were raised 10 times.
As in “int (1),” our method took much less execution cycles than
MIPS and the previous methods. This is considered mainly because
register save/restore operations were eliminated and partly becauseinterrupt handler starts at any time other than the end of DFGs.
Our method is especially e�ective in reducing interrupt latencies
of light and frequent interrupts.
The total execution cycles of our method in “total (1)” and “total(2)” are fewer than those of [6] and more than 80% fewer thansoftware execution. This is because of the fast interrupt handlingand also because of parallel execution of the main and the handler
modules. Especially in the case of this experiment, where there
was no critical section and there was no need for mutual exclusion,interrupt handling did not increase total execution time.
Hardware cost (“Slices”) is higher than that of MIPS (which
includes estimated memory size for 1,753 instructions) by 41%, but
this would be reasonable considering the improvement of the speed
performance.

4.3

Synthesis of Motor Controller

As a more practical example, a controller of a motor driven bya timer is synthesized from a C program. The overview of thecontroller is shown in Figure 10 (a). It controls the rotational speedof a brushed DC motor by changing supply voltage. The control issensorless; it does not use a speed sensor but estimates the speed

97

01 #include interrupt_lib.h02
03 extern void *interrupt_call;04 extern void (*exc_handler[24])();
05 extern void *_reg_store;
06
07 void init_interrupt(void)
08 {09 (*((unsigned int*)&interrupt_call))10= (unsigned int)run_exc_handler;
11 register_exc_handler(EXC_Sys, run_syscall_handler);
12 }13
14 void register_exc_handler(unsigned int exc, void (*f)(void))
15 {16 if (EXC_MOD <= exc && exc <= EXC_Int5) {17
exc_handler[exc] = f;
18 }
19 }
20
21 void run_exc_handler(void)
22 {23 int i;
24 unsigned int cause_reg, exc_code, int_field;
25 void (*handler)() = 0x00000000;
26
27 asm( mfc0 %0, $13 : =r (cause_reg));
28 exc_code = (cause_reg >> 2) & 0xf;
29 int_field = (cause_reg >> 8) & 0xff;
30
31 if (!exc_code) {32
for (i = EXC_Sw0; i <= EXC_Int5; i++) {33
if (int_field & 0x1) {34
handler = exc_handler[i]; break;
35}
36
int_field = int_field >> 1;
37}38 } else {39
handler = exc_handler[exc_code];40 }41 if (*handler) {(*handler)();}
42 }43
44 void run_syscall_handler(void)45 {46 unsigned int reg_k1;
47
48 asm( add %0, $0, $k1 : =r (reg_k1));
49
50 if (reg_k1 == 1) {51
int_prohibition_func();
52((unsigned int *)&_reg_store)[0] += 4;
53 }
54 }
55
56 void int_prohibition(void)57 {58 asm( addiu $k1,$0,1 );59 asm( syscall );60 }61
62 void int_prohibition_func(void)63 {64 asm( lui $8, 0xffff );65 asm( ori $8, 0xfffb );66 asm( mfc0 $9, $12 );67 asm( and $9, $9, $8 );68 asm( mtc0 $9, $12 );69 }70
71 void int_permission(void)72 {73 asm( mfc0 $8, $12 );74 asm( ori $8, $8, 0x1 );75 asm( mtc0 $8, $12 );76 }Figure 9: Library for interrupt handling (interrupt_lib.c) [6].
by a motor simulator. The voltage is periodically adjusted uponinterrupts from the timer.
The detailed block diagram of the transfer function for the PID
control, with a motor model inclusive, is shown in Figure 10 (b)[7]. Three elements PID, Gain, and Limiter constitute the controller,
which receives the target angular velocity ⇤ and decides the voltage x1 to drive the motor. The value of x1 as well as is computedby expressing the transfer function by an ordinary di�erential equation and numerically solving it by the Runge-Kutta method.
A C program is described in the same framework as in Figure 7
through Figure 9. In this example, the main routine does nothing(just busy-loops) after initialization, while the handler is activatedby the periodic interrupts from the timer.
A synthesis result is shown in TABLE 2. The logic synthesizer
and the target FPGA are the same as those in TABLE 1. Note that
our MIPS core was equipped with only �xed point arithmetic units

Binary Synthesis Implementing External Interrupt Handler as Independent ModuleRSP’17, October 15–20, 2017, Seoul, Republic of Korea
Table 1: Experimental result.

MIPS
HW [6]HW (proposed)

SlicesDelay [ns]3,559 (1.00)
5,937 (1.67)
5,014 (1.41)

25.24 (1.00)
18.86 (0.75)
20.16 (0.80)

total (0)458,326 (1.00)
110,467 (0.22)
110,467 (0.22)

int (1)155 (1.00)
136 (0.88)
72 (0.46)

Cyclestotal (1)604,189 (1.00)
242,467 (0.40)
100,467 (0.17)

int (2)
11,494 (1.00)
7,812 (0.68)
7,747 (0.67)

total (2)573,116 (1.00)
188,537 (0.33)
100,467 (0.18)

Logic synthesizer: Xilinx ISE 14.3, Target device: Xilinx Spartan-3E. Slices include estimated instruction memory size.

Table 2: Synthesis result of motor controller.
MIPS
HW (proposed)

Slices4,872 (1.00)
13,231 (2.72)

Delay [ns]22.47 (1.00)
22.16 (0.99)

Cycles
23,001 (1.00)
871 (0.04)

Period [ µ s]
516.8 (1.00)
19.3 (0.04)

Logic synthesizer: Xilinx ISE 14.3, Target device: Xilinx Spartan-3E. Slices include estimated instruction memory size.

DC brush
motor

timer

controlmotor
simulator

motor controller(a) Timer-driven sensorless control(b) Block diagram of PID control [7]Figure 10: Sensorless control of DC motor.
so �oating point operations were carried out with GNU soft-�oatlibrary, while the hardware had �oating point units and ACAP converted the calls to the soft-�oat library by �oating point arithmetic
operations. As compared with software on the MIPS, the numberof execution cycles (“Cycles”) is drastically reduced, though circuit
size (“Slices”) is 2.72 times larger. The minimum period for the motor control has been reduced to 20.6 [µs], which enables extremely
precise control.

5

CONCLUSION

This paper has proposed a method of synthesizing given binary
programs with external interrupt handling into hardware where thenormal task and the interrupt handler are implemented as separate
modules. E�cient hardware compatible with the CPU runningthe binary code is generated without any rewriting on the binary
code except for adding pragmas to specify which part should besynthesized as the handler module.
Future work includes extension of this method to multilevelinterrupts and application of this method to other processors thanMIPS.

ACKNOWLEDGMENTS
We would like to thank to Mr. Takayuki Nakatani who was with
Ritsumeikan University, Mr. Masaharu Yano who was with Kyoto

98

University, Mr. Shimpei Tamura who was with Kwansei Gakuin University and all the members of Ishiura Lab. of Kwansei Gakuin University for their discussion and advices on this research. This work
is partly supported by JSPS KAKENHI under Grant Nos. 16K00088,
16K01207, and 15H02680.

REFERENCES[1] Daniel D. Gajski, Nikil D. Dutt, Allen C-H Wu, and Steve Y-L Lin. 1992. High-Level
Synthesis: Introduction to Chip and System Design. Kluwer Academic Publishers.
[2] Greg Stitt and Frank Vahid. 2007. Binary synthesis. ACM Transactions on Design Automation of Electronic Systems 12, 3, Article 34 (August 2007), 30 pages.
DOI:http://doi.org/10.1145/1255456.1255471[3] Nagisa Ishiura, Hiroyuki Kanbara, and Hiroyuki Tomiyama. ACAP: Binary Synthesizer Based on MIPS Object Codes. In Proceedings of International TechnicalConference on Circuit/Systems, Computers and Communications (ITC-CSCC 2014).
(July 2014), 725–728.
[4] Seiya Shibata, Shinya Honda, Hiroyuki Tomiyama, and Hiroaki Takada. 2010.
Advanced System-Builder: A Tool Set for Multiprocessor Design Space Exploration.
in Proceedings of International SoC Design Conference (ISOCC 2010). (November2010), 79–82. DOI:http://doi.org/10.1109/SOCDC.2010.5682967[5] Yuki Ando, Shinya Honda, Hiroaki Takada, and Masato Edahiro. 2015. Systemlevel Design Method for Control Systems with Hardware-implemented Interrupt
Handler. IPSJ Journal of Information Processing, 23, 5 (September 2015), 532–541.
DOI:http://doi.org/10.2197/ipsjjip.23.532[6] Naoya Ito, Nagisa Ishiura, Hiroyuki Tomiyama, and Hiroyuki Kanbara. High-Level
Synthesis from Programs with External Interrupt Handling. in Proceedings of theWorkshop on Synthesis And System Integration of Mixed Information Technologies(SASIMI 2015). (March 2015), 10–15.
[7] Hisashi Takahashi. 2017. Introductory Lecture in Motor Control by the C Language(in Japanese). Denpa Publications, Tokyo, Japan.