DOCSLIB.ORG

A Java Processor Architecture for Embedded Real-Time Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Downloaded from orbit.dtu.dk on: Oct 01, 2021 A Java Processor Architecture for Embedded Real-Time Systems Schoeberl, Martin Published in: Journal of Systems Architecture Link to article, DOI: 10.1016/j.sysarc.2007.06.001 Publication date: 2008 Document Version Early version, also known as pre-print Link back to DTU Orbit Citation (APA): Schoeberl, M. (2008). A Java Processor Architecture for Embedded Real-Time Systems. Journal of Systems Architecture, 54(1-2), 265-286. https://doi.org/10.1016/j.sysarc.2007.06.001 General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. A Java Processor Architecture for Embedded Real-Time Systems Martin Schoeberl Institute of Computer Engineering, Vienna University of Technology, Austria Abstract Architectural advancements in modern processor designs increase average performance with features such as pipelines, caches, branch prediction, and out-of-order execution. However, these features complicate worst-case execution time analysis and lead to very conservative estimates. JOP (Java Optimized Processor) tackles this problem from the architectural perspective – by introducing a processor architecture in which simpler and more accurate WCET analysis is more important than average case performance. This paper presents a Java processor designed for time-predictable execution of real-time tasks. JOP is the implementation of the Java virtual machine in hardware. JOP is intended for applications in embedded real-time systems and the primary implementation technology is in a field programmable gate array. This paper demonstrates that a hardware implementation of the Java virtual machine results in a small design for resource-constrained devices. Key words: Real-time system; Time predictable architecture; Java processor 1. Introduction Due to compilation during runtime, execution times are practically not predictable 1 . Compared to software development for desktop sys- This paper introduces the concept of a Java processor tems, current software design practice for embedded [51] for embedded real-time systems, in particular the real-time systems is still archaic. C/C++ and even as- design of a small processor for resource-constrained de- sembly language are used on top of a small real-time vices with time-predictable execution of Java programs. operating system. Many of the benefits of Java, such as This Java processor is called JOP – which stands for safe object references, the notion of concurrency as a Java Optimized Processor –, based on the assumption first-class language construct, and its portability, have that a full native implementation of all Java bytecode the potential to make embedded systems much safer instructions [30] is not a useful approach. and simpler to program. However, Java technology is Worst-case execution time (WCET) estimates of seldom used in embedded real-time systems, due to the tasks are essential for designing and verifying real-time lack of acceptable real-time performance. systems. Static WCET analysis is necessary for hard Traditional implementations of the Java virtual ma- real-time systems. In order to obtain a low WCET chine (JVM) as interpreter or just-in-time compiler are value, a good processor model is necessary. Tradition- not practical. An interpreting virtual machine is too ally, only simple processors can be analyzed using slow and therefore waste of processor resources. Just-in- practical WCET boundaries. Architectural advance- time compilation has several disadvantages for embed- ded systems, notably that a compiler (with the intrinsic 1 One could add the compilation time of a method to the WCET memory overhead) is necessary on the target system. of that method. However, in that case we need a WCET analyzable compiler and the WCET gets impractical high. Preprint submitted to Elsevier 12 June 2007 ments in modern processor designs tend to abide by Even simple processors can contain an instruc- the rule: ‘Make the average case as fast as possible’. tion prefetch buffer that prohibits exact WCET This is orthogonal to ‘Minimize the worst case’ and values. The design of the method cache and the has the effect of complicating WCET analysis. This translation unit avoids the variable latency of a paper tackles this problem from the architectural per- prefetch buffer. spective – by introducing a processor architecture in (xi) Good average case performance compared to which simpler and more accurate WCET analysis is other non real-time Java processors. more important than average case performance. (xii) Avoidance of hard to analyze architectural fea- JOP is designed from ground up with time predictable tures results in a very small design. Therefore an execution of Java bytecode as major design goal. All available real estate can be used for a chip multi- function units, and especially the interaction between processor solution. them, are carefully designed to avoid any time depen- In this paper, we will present the architecture of the dency between bytecodes. The architectural highlights real-time Java processor and the evaluation results for are: JOP, with respect to WCET, size and performance. We (i) Dynamic translation of the CISC Java byte- will show that the execution time of Java bytecodes can codes to a RISC, stack based instruction set (the be exactly predicted in terms of the number of clock microcode) that can be executed in a 3 stage cycles. We will also evaluate the general performance pipeline. of JOP in relation to other embedded Java systems. Al- (ii) The translation takes exactly one cycle per byte- though JOP is intended as a processor with a low WCET code and is therefore pipelined. Compared to for all operations, its general performance is still impor- other forms of dynamic code translation the tant. We will see that a real-time processor architecture proposed translation does not add any variable does not need to be slow. latency to the execution time and is therefore In the following section, related work on real-time time predictable. Java, Java processors, and issues with the low-level (iii) Interrupts are inserted in the translation stage as WCET analysis for standard processors is presented. In special bytecodes and are transparent to the mi- Section 3 a brief overview of the architecture of JOP crocode pipeline. is given, followed by a more detailed description of the (iv) The short pipeline (4 stages) results in short microcode. In Section 4 it is shown that our objective conditional branch delays and a hard to analyze of providing an easy target for WCET analysis has been branch prediction logic or branch target buffer achieved. Section 5 compares JOP’s resource usage with can be avoided. other soft-core processors. In the Section 6, a number (v) Simple execution stage with the two topmost of different solutions for embedded Java are compared stack elements as discrete registers. No write at the bytecode level and at the application level. back stage or forwarding logic is needed. (vi) Constant execution time (one cycle) for all mi- crocode instructions. No stalls in the microcode 2. Related Work pipeline. Loads and stores of object fields are han- dled explicitly. In this section we present arguments for Java in real- (vii) No time dependencies between bytecodes result time systems, various Java processors from industry and in a simple processor model for the low-level academia, and an overview of issues in the low-level WCET analysis. WCET analysis that can be avoided by the proposed (viii) Time predictable instruction cache that caches processor design. whole methods. Only invoke and return instruc- tion can result in a cache miss. All other instruc- tions are guaranteed cache hits. 2.1. Real-Time Java (ix) Time predictable data cache for local variables and the operand stack. Access to local variables Java is a strongly typed, object oriented language, is a guaranteed hit and no pipeline stall can hap- with safe references, and array bounds checking. Java pen. Stack cache fill and spill is under microcode shares those features with Ada, the main language for control and analyzable. safety critical real-time systems. It is even possible, and (x) No prefetch buffers or store buffers that can intro- has been done [60,8], to compile Ada 95 for the JVM. In duce unbound time dependencies of instructions. contrast to Ada, Java has a large user and open-source 2 code base. In [64] it is argued that Java will become the Table 1 JOP and various Java processors better technology for real-time systems. Target Size Speed The object references replace error-prone C/C++ technology Logic Memory (MHz) style pointers. Type checking is enforced by the com- piler and performed at runtime. Those features greatly JOP Altera, Xilinx FPGA 2050 LCs 3 KB 100 help to avoid program errors. Therefore Java is an at- picoJava [58,59] No realization 128 Kgates 38 KB aJile [1,19] ASIC 0.25µ 25 Kgates 48 KB 100 tractive choice for safety critical and real-time systems Cjip [18,25] ASIC 0.35µ 70 Kgates 55 KB 80 [56,26]. Furthermore, threads and synchronization, Moon [62,63] Altera FPGA 3660 LCs 4 KB common idioms in real-time programming, are part of Lightfoot [9] Xilinx FPGA 3400 LCs 4 KB 40 the language.
Recommended publications
  • Microprocessor Architecture

    Microprocessor Architecture

    EECE416 Microcomputer Fundamentals Microprocessor Architecture Dr. Charles Kim Howard University 1 Computer Architecture Computer System CPU (with PC, Register, SR) + Memory 2 Computer Architecture •ALU (Arithmetic Logic Unit) •Binary Full Adder 3 Microprocessor Bus 4 Architecture by CPU+MEM organization Princeton (or von Neumann) Architecture MEM contains both Instruction and Data Harvard Architecture Data MEM and Instruction MEM Higher Performance Better for DSP Higher MEM Bandwidth 5 Princeton Architecture 1.Step (A): The address for the instruction to be next executed is applied (Step (B): The controller "decodes" the instruction 3.Step (C): Following completion of the instruction, the controller provides the address, to the memory unit, at which the data result generated by the operation will be stored. 6 Harvard Architecture 7 Internal Memory (“register”) External memory access is Very slow For quicker retrieval and storage Internal registers 8 Architecture by Instructions and their Executions CISC (Complex Instruction Set Computer) Variety of instructions for complex tasks Instructions of varying length RISC (Reduced Instruction Set Computer) Fewer and simpler instructions High performance microprocessors Pipelined instruction execution (several instructions are executed in parallel) 9 CISC Architecture of prior to mid-1980’s IBM390, Motorola 680x0, Intel80x86 Basic Fetch-Execute sequence to support a large number of complex instructions Complex decoding procedures Complex control unit One instruction achieves a complex task 10
  • What Do We Mean by Architecture?

    What Do We Mean by Architecture?

    Embedded programming: Comparing the performance and development workflows for architectures Embedded programming week FABLAB BRIGHTON 2018 What do we mean by architecture? The architecture of microprocessors and microcontrollers are classified based on the way memory is allocated (memory architecture). There are two main ways of doing this: Von Neumann architecture (also known as Princeton) Von Neumann uses a single unified cache (i.e. the same memory) for both the code (instructions) and the data itself, Under pure von Neumann architecture the CPU can be either reading an instruction or reading/writing data from/to the memory. Both cannot occur at the same time since the instructions and data use the same bus system. Harvard architecture Harvard architecture uses different memory allocations for the code (instructions) and the data, allowing it to be able to read instructions and perform data memory access simultaneously. The best performance is achieved when both instructions and data are supplied by their own caches, with no need to access external memory at all. How does this relate to microcontrollers/microprocessors? We found this page to be a good introduction to the topic of microcontrollers and ​ ​ microprocessors, the architectures they use and the difference between some of the common types. First though, it’s worth looking at the difference between a microprocessor and a microcontroller. Microprocessors (e.g. ARM) generally consist of just the Central ​ ​ Processing Unit (CPU), which performs all the instructions in a computer program, including arithmetic, logic, control and input/output operations. Microcontrollers (e.g. AVR, PIC or ​ 8051) contain one or more CPUs with RAM, ROM and programmable input/output ​ peripherals.
  • Assignment Solutions

    Assignment Solutions

    Week 1: Assignment Solutions 1. Which of the following statements are true? a. The ENIAC computer was built using mechanical relays. b. Harvard Mark1 computer was built using mechanical relays. c. PASCALINE computer could multiply and divide numbers by repeated addition and subtraction. d. Charles Babbage built his automatic computing engine in 19th century. Solution: ((b) and (c)) ENIAC was built using vacuum tubes. Charles Babbage designed his automatic computing engine but could not built it. 2. Which of the following statements are true for Moore’s law? a. Moore’s law predicts that power dissipation will double every 18 months. b. Moore’s law predicts that the number of transistors per chip will double every 18 months. c. Moore’s law predicts that the speed of VLSI circuits will double every 18 months. d. None of the above. Solution: (b) Moore’s law only predicts that number of transistors per chip will double every 18 months. 3. Which of the following generates the necessary signals required to execute an instruction in a computer? a. Arithmetic and Logic Unit b. Memory Unit c. Control Unit d. Input/Output Unit Solution: (c) Control unit acts as the nerve center of a computer and generates the necessary control signals required to execute an instruction. 4. An instruction ADD R1, A is stored at memory location 4004H. R1 is a processor register and A is a memory location with address 400CH. Each instruction is 32-bit long. What will be the values of PC, IR and MAR during execution of the instruction? a.
  • WCET Analysis of Java Bytecode Featuring Common Execution Environments

    WCET Analysis of Java Bytecode Featuring Common Execution Environments

    WCET Analysis of Java Bytecode Featuring Common Execution Environments Christian Frost, Casper Svenning Jensen, Kasper Søe Luckow, Bent Thomsen Department of Computer Science, Aalborg University Selma Lagerlöfs Vej 300 DK-9220, Aalborg East, Denmark {chrfrost,semadk,luckow,bt}@cs.aau.dk ABSTRACT 1. INTRODUCTION We present a novel tool for statically determining the Worst Java in its traditional form, has inherent issues that makes Case Execution Time (WCET) of Java Bytecode-based pro- it less suitable for development of hard real-time embedded grams called Tool for Execution Time Analysis of Java byte- systems such as the lack of the notion of a deadline and code (TetaJ). This tool differentiates itself from existing high-resolution real-time clocks. To accommodate these, a tools by separating the individual constituents of the execu- variety of initiatives such as the Real-Time Specification tion environment into independent components. The prime for Java (RTSJ) [23] and related profiles: Safety Critical benefit is that it can be used for execution environments Java (SCJ) [16] and Predictable Java (PJ) [9] have been featuring common embedded processors and software im- initiated. These specify certain alterations to the under- plementations of the JVM. TetaJ employs a model checking lying Java Virtual Machine (JVM) and various extensions approach for statically determining WCET where the Java through libraries that, when adhered to, creates a program- program, the JVM, and the hardware are modelled as Net- ming model that can be used for real-time systems devel- works of Timed Automata (NTA) and given as input to the opment in Java.
  • Introduction to Cpu

    Introduction to Cpu

    microprocessors and microcontrollers - sadri 1 INTRODUCTION TO CPU Mohammad Sadegh Sadri Session 2 Microprocessor Course Isfahan University of Technology Sep., Oct., 2010 microprocessors and microcontrollers - sadri 2 Agenda • Review of the first session • A tour of silicon world! • Basic definition of CPU • Von Neumann Architecture • Example: Basic ARM7 Architecture • A brief detailed explanation of ARM7 Architecture • Hardvard Architecture • Example: TMS320C25 DSP microprocessors and microcontrollers - sadri 3 Agenda (2) • History of CPUs • 4004 • TMS1000 • 8080 • Z80 • Am2901 • 8051 • PIC16 microprocessors and microcontrollers - sadri 4 Von Neumann Architecture • Same Memory • Program • Data • Single Bus microprocessors and microcontrollers - sadri 5 Sample : ARM7T CPU microprocessors and microcontrollers - sadri 6 Harvard Architecture • Separate memories for program and data microprocessors and microcontrollers - sadri 7 TMS320C25 DSP microprocessors and microcontrollers - sadri 8 Silicon Market Revenue Rank Rank Country of 2009/2008 Company (million Market share 2009 2008 origin changes $ USD) Intel 11 USA 32 410 -4.0% 14.1% Corporation Samsung 22 South Korea 17 496 +3.5% 7.6% Electronics Toshiba 33Semiconduc Japan 10 319 -6.9% 4.5% tors Texas 44 USA 9 617 -12.6% 4.2% Instruments STMicroelec 55 FranceItaly 8 510 -17.6% 3.7% tronics 68Qualcomm USA 6 409 -1.1% 2.8% 79Hynix South Korea 6 246 +3.7% 2.7% 812AMD USA 5 207 -4.6% 2.3% Renesas 96 Japan 5 153 -26.6% 2.2% Technology 10 7 Sony Japan 4 468 -35.7% 1.9% microprocessors and microcontrollers
  • Renesas Technology and Hitachi Announce Development of SH-2A 32-Bit RISC CPU Core for High-Performance Embedded Sysytems

    Renesas Technology and Hitachi Announce Development of SH-2A 32-Bit RISC CPU Core for High-Performance Embedded Sysytems

    Renesas Technology and Hitachi Announce Development of SH-2A 32-Bit RISC CPU Core for High-Performance Embedded Sysytems Approximately 3.5-fold improvement in processing performance plus improved program code efficiency and real-time capability, ideal for high-performance real-time control systems for automotive, consumer, and industrial products Tokyo, April 19, 2004 Renesas Technology Corp. and Hitachi, Ltd. (TSE:6501, NYSE:HIT) today announced the development of a 32-bit RISC (Reduced Instruction Set Computer) CPU core, dubbed the SH-2A, for use in control devices in the automotive, industrial, and consumer fields. The SH-2A is the successor of the SuperH™*1 RISC microprocessor SH-2 CPU core, and offers a major increase in performance together with improved program code efficiency. The SH-2A is designed for products requiring real-time capability, and is ideal for use in single-chip microcontrollers and SoCs (Systems on Chip) in automotive engine control systems and consumer and industrial products such as printers and AC servos. < Background > Automotive engine control has become more complex with the recent emphasis on environmental conservation and improved fuel consumption, while at the same time there is a trend toward the development of large-scale systems in short time-frames through the adoption of autocode technology*2 driven by improvements in development tools. The field of industrial products such as AC servos is also witnessing advances in system precision, while more and more consumer products such as printers are appearing in the form of multi-function systems. For example, there is a demand for faster processing providing coupled printing control while executing high-speed computational operations on image data from a DSC or scanner, and control system in these fields require microcontroller that offer high speed, high performance, and large-capacity on-chip ROM.
  • Design Decisions for a Java Processor

    Design Decisions for a Java Processor

    Design Decisions for a Java Processor Martin Schoeberl JOP.design Strausseng. 2-10/2/55, A-1050 Vienna, AUSTRIA [email protected] Abstract The paper is organized as follows: Section 2 gives an overview of the architecture of JOP. In section 3 some This paper describes design decisions for JOP, a Java design decisions for the implementation in an FPGA are Optimized Processor, implemented in an FPGA. FPGA described. One example of the flexibility of an FPGA density-price relationship makes it now possible to con- based architecture is given in section 4. sider them not only for prototyping of processor designs but also as final implementation technology. However, using an FPGA as target platform for a processor dif- 2 Overview of JOP ferent constraints influence the CPU architecture. Digi- tal building blocks that map well in an ASIC can result Figure 1 shows the datapath of JOP. In the first pipe- in poor resource usage in an FPGA. Considering these line stage Java bytecodes, the instructions of the JVM, constraints in the architecture can result in a tiny soft- are fetched. These bytecodes are translated to addresses core processor. in the micro code. Bytecode branches are also decoded and executed in this stage. A fetched bytecode results in an absolute jump in the micro code (the second stage). If 1 Introduction the bytecode has a 1 to 1 mapping with a JOP instruc- tion, a new bytecode is fetched, resulting in a jump in Common design praxis for embedded systems is us- the micro code in the next cycle.
  • Anatomy of Memory Corruption Attacks and Mitigations In

    Anatomy of Memory Corruption Attacks and Mitigations In

    Anatomy of Memory Corruption Attacks and Mitigations in Embedded Systems Nektarios Georgios Tsoutsos, Student Member, IEEE, and Michail Maniatakos, Senior Member, IEEE Abstract—For more than two decades, memory safety viola- deploy additional protection mechanisms. In this article, we tions and control-flow integrity attacks have been a prominent review memory corruption threats to embedded processors and threat to the security of computer systems. Contrary to regular summarize contemporary mitigation techniques. systems that are updated regularly, application-constrained de- vices typically run monolithic firmware that may not be updated Memory Safety. In embedded system programming, memory in the lifetime of the device after being deployed in the field. corruption remains a major class of memory safety violations Hence, the need for protections against memory corruption that could enable attackers to subvert the legitimate program becomes even more prominent. In this article, we survey memory safety in the context of embedded processors, and describe behavior. Using programming languages that provide unlim- different attacks that can subvert the legitimate control flow, ited freedom on how to data are handled, such violations can with a special focus on Return Oriented Programming. Based be attributed to programmer errors or improper input validation on common attack trends, we formulate the anatomy of typical [1]. Consequently, memory safety violations comprise a broad memory corruption attacks and discuss powerful mitigation range of software problems that could enable unauthorized techniques that have been reported in the literature. access to sensitive information resources, escalate privileges, Index Terms—Memory safety violations, control-flow integrity modify the program control flow or allow execution of arbi- protections, buffer overflows, return oriented programming.
  • JOP: a Java Optimized Processor

    JOP: a Java Optimized Processor

    JOP: A Java Optimized Processor Martin Schoeberl JOP.design, Strausseng. 2-10/2/55, A-1050 Vienna, AUSTRIA [email protected] Abstract. Java is still not a common language for embedded systems. It posses language features, like thread support, that can improve embedded system de- velopment, but common implementations as interpreter or just-in-time compiler are not practical. JOP is a hardware implementation of the Java Virtual Ma- chine with focus on real-time applications. This paper describes the architecture of JOP and proposes a simple real-time extension of Java for JOP. First applica- tion in an industrial system showed that JOP is one way to use Java in the em- bedded world. 1 Introduction Current software design practice for embedded systems is still archaic compared to software development for desktop systems. C and even Assembler is used on top of a small RTOS. The variety of embedded operating systems is large and this fragmenta- tion of the market leads to high cost. Java [1] can be a way out of this dilemma and possess language features not found in C: - Object-oriented - Memory management with a garbage collector - Implicit memory protection - Threads Memory management and threads are (besides device drivers) the main compo- nents of embedded operating systems. Finding these features in the language embed- ded systems can be programmed in Java without the need of an operating system. Java on desktop systems comes with a large library. However, if Java is stripped down to the core components it has a very small memory footprint. With careful pro- gramming (like using only immortal memory as in [2]) the garbage collector can be avoided.
  • A Hardware Abstraction Layer in Java

    A Hardware Abstraction Layer in Java

    A Hardware Abstraction Layer in Java MARTIN SCHOEBERL Vienna University of Technology, Austria STEPHAN KORSHOLM Aalborg University, Denmark TOMAS KALIBERA Purdue University, USA and ANDERS P. RAVN Aalborg University, Denmark Embedded systems use specialized I/O devices to interact with their environment, and since they have to be de- pendable, it is attractive to use a modern, type-safe programming language like Java to develop programs for them. However, standard Java, as a platform independent language, delegates access to I/O devices, direct mem- ory access and interrupt handling to some underlying operating system or kernel, but in the embedded systems domain resources are scarce and a Java virtual machine (JVM) without an underlying middleware is an attractive architecture. The contribution of this paper is a proposal for Java packages with hardware objects and interrupt handlers that interfaces to such a JVM. We provide implementations of the proposal directly in hardware, directly as extensions of standard interpreters, and finally with an operating system middleware. The latter solution is mainly seen as a migration path allowing Java programs to coexist with legacy system components. An important aspect of the proposal is that it is compatible with the Real-Time Specification for Java (RTSJ). Categories and Subject Descriptors: D.4.7 [Operating Systems]: Organization and Design—Real-time sys- tems and embedded systems; D.3.3 [Programming Languages]: Language Classifications—Object-oriented languages; D.3.3 [Programming Languages]: Language Constructs and Features—Input/output General Terms: Languages, Design, Implementation Additional Key Words and Phrases: Device driver, embedded system, Java, Java virtual machine 1.
  • HARVARD ARCHITECTURE Von Neumann Architecture Harvard Architecture

    HARVARD ARCHITECTURE Von Neumann Architecture Harvard Architecture

    FPGA HARVARD ARCHITECTURE Von Neumann Architecture Harvard Architecture Memory CPU Data Memory CPU (Data and Control Control Program) ALU Program Memory ALU Input Input Output Output • Shared memory space • • CPU to memory is bottleneck Separate memory spaces • Data and instructions access can • Data and instructions have to happen at the same time share the memory interface • • The basic word size is the The basic word size can be different for data and instructions same for data and instructions Modified Harvard Architecture Memory Memory Data Memory Cache CPU (Data and interface Control Instruction) Instruction Memory ALU Cache Input Output • Common Main memory space • CPU to memory bottleneck only for things not in the cache • Separate memory spaces for data cache and instruction cache • Data and instructions access can happen at the same time • The basic word size can be different for data and instructions • Most modern processors use this approach inside the CPU chip Linear Sort in FPGA The instruction memory is completely separate from the data memory Data & I/O Data Memory Data address Interface Interface Control Pocket A Interface Pocket Memory Control Logic Program Logic Memory Address system Pocket B Interface Memory Logic Sequencer Instruction Memory FPGA Performance Comparison of Linear UBXSort vs C++ std::sort() • UBXSort is our patented sorting algorithm, US patent # 5,278,987 • It has a complexity of O(N) • Typical conventional sorting algorithms have complexity of O(N * log(N)) • The larger the dataset size, the more advantageous
  • Application Experiences with a Real-Time Java Processor

    Application Experiences with a Real-Time Java Processor

    Proceedings of the 17th World Congress The International Federation of Automatic Control Seoul, Korea, July 6-11, 2008 Application Experiences with a Real-Time Java Processor Martin Schoeberl ∗ ∗ Institute of Computer Engineering, Vienna University of Technology, Austria (e-mail: [email protected]). Abstract: In this paper we present three different industrial real-time applications that are based on an embedded Java processor. Although from different application domains all three projects have one topic in common: communication. Today’s embedded systems are networked systems. Either a proprietary protocol is used due to legacy applications or for real-time aspects or standard Internet protocols are used. We present the challenges and solutions for this variety of protocols in small, memory constraint embedded devices. 1. INTRODUCTION JOP is implemented in a field-programmable gate array (FPGA). The logic resource consumption is configurable Embedded systems in the control and automation domain in the range of 2000–3000 logic cells (LC). That size is 1/3 become more and more complex. In the desktop and of the soft-core RISC processor LEON, see Gaisler (2002), server domain the increasing complexity of systems can that is used by ESA for space missions. be handled by advanced programming languages. Java has Implementation of a processor in an FPGA is a little bit been seen as a very productive object-oriented language. more expensive than using an ASIC processor. However, In this paper we show that Java can also be used in the additional application logic, such as a communication embedded domain. We present three real-world embedded controller or an AD converter, can also be integrated applications written entirely in Java.