Design and Application of a Reconfigurable Embedded system

Eighth International Conference on Intelligent Systems Design and Applications Design and Application of a Reconfigurable Embedded system Ching-Biau Tzeng, Tzuu-Shaang Wey*, Li-Dao Fang Department of Electronic Engineering Kun Shan University, Tainan, Taiwan, Republic of China *Corresponding author : tswey@mail.ksu.edu.tw Abstract In recent years, the Embedded System has become a common goal sought by the academic world such as computer science, electronics, electrical engineering etc or product developers. As we enter into the post-pc era, advances in electronics, information technology, and mobile computing provide the basis for the development of embedded systems and related products. This paper documents all relevant knowledge and procedures related to the modeling of a system structure, from the selection of main hardware control components ARM and FPGA, the construction of a workable hardware system, programming of drivers, implementation of a real-time operating system and the running of applications, to the final hardware and software testing of the entire system. The structuring of a system is not the most complicated, but the most fundamental. Our aim is to provide references for researchers studying in this particular field. 1. Introduction The design of electronic systems essentially includes control components such as CPU and FPGA; the CPU is mainly used in the design for flow control. Due to the rapid advances in the production of semiconductors, high-density circuits are able to be packed into the same space within the FPGA components. The application of FPGA may be extended to communications, videos, system integration, parallel processing etc, or even embedded with a software/hardware CPU. For larger setups, there is greater flexibility in the design of electronic systems since CPU and FPGA may be incorporated into the system with the integration of CPU's flow control and FPGA's parallel processing connected through memory bus. The combination of CPU and FPGA not only improves system flexibility, but also provides expansion options with the upgrade of CPU or FPGA according to our desired functionality. Currently this is one of the many options large systems integrate [1]. Once we had a design for the hardware, we needed an operating system to manage the entire system resources and execute the complex functions the system is designed to perform. If the application demanded immediate response to a certain degree, we need to develop the system using RTOS - Real Time Operation System to meet the requirement of immediacy [2]. Fundamentally, software developers are usually more familiar with the development of operating systems and algorithms, while hardware engineers have extensive knowledge on hardware systems; software and hardware engineers also differ in logical thinking during product development, and problems arise when they try to determine why the system can not perform. If we are able to establish levels of authority within a well-designed software/hardware model, these conflicts may be effectively minimized. In this paper we attempted to build an embedded system incorporating the most basic and workable hardware environment, upon which we can test and develop applications [3]. The definition of an embedded system is commonly available in books and the Internet. Simply put, an embedded system is comprised of embedded hardware and software. Hardware that is specifically built to perform certain tasks within a piece of hardware is called embedded hardware; software that is specifically designed to perform certain tasks on top of the embedded hardware is called embedded software. Operating systems that operate within an embedded system are called embedded operating systems. The main contributions of this paper is to illustrate the integrated design and realization of hardware and software from the perspective of system modeling, the hardware design of an ARM+FPGA structure that can be used for co-verification and operation, and the practical application of a CAN BUS monitor operating under RTOS. 2. Hardware Design of a Reconfigurable System Our system is based on the ARM+FPGA structure. There are three main ways to physically 978-0-7695-3382-7/08 $25.00 2008 IEEE DOI 10.1109/ISDA.2008.309 511

connect the ARM CPU and FPGA [1][4]. Based on the comparison listed in Table 1, it was decided that for our general applications, we would incorporate existing SOC and FPGA components into our design. Taking into consideration the costs, complexity, and applicability involved, we decided to use ARM SOC + FPGA as the main components of our hardware system. This combination is capable of achieving the basic operating environment for hardware/software verification. The hardware system design is illustrated in figure 1 and is divided into ARM and FPGA hardware. The design of FPGA hardware also includes the program configuration of FPGA hardware. Table 1: Strengths and weaknesses of the various ARM and FPGA connection methods ARM SOC + FPGA SOPC (ARM core + ARM Core + FPGA FPGA) Cost Low Average High Bus Memory bus AMBA AMBA Level of basic knowledg e required ARM type Applicatio n Area of expertise Low Average High Physical SOC General system application General system Software-bas ed core Flexible configuration of CPU accessories, integrated custom IP General system/sopc design Physical core excluding peripheral interface SOC verification IC design The CPU we selected is an ARM produced by NXP, model LPC2214 ARM7TDMI (-S). It has a built-in FLASH based ROM of 256Kbytes. External ROM was not required to perform our basic tasks, which thus simplified our circuitry design. Modern digital logic design has evolved from traditional TTL and CMOS IC to the level of digital system design including CPLD and FPGA. There are several FPGA manufacturers on the market, but based on the user-friendliness of EDA software, availability and costs, we chose the CYCLONE series manufactured by ALTERA, the FPGA [5] model EP1C6Q240C8 and ROM EPCS1 for part of the FPGA circuitry design of our system. Our main concerns for selecting the FPGA were its capacity and number of pins. This FPGA has a capacity of 5980LE, equivalent to 120 thousand logic gates, which is sufficient for general use. It is TQFP packaged with 240 pins, the maximum amount available for this packaging, which we were able to fully utilize for our expansion experiments. 3. Software design of the reconfigurable system We used the ARM development tool kit distributed by Keil, as our software development environment. All development environments available today offer project management functions to accommodate the growing complexity in software design, which requires the modulation of software functions for later use. The main function of project management is categorizing software designs into tree diagrams. As illustrated in Figure 2, the c/os-ii core is isolated in a single folder marked as cos2-kernel in the diagram. This folder is the codename for real-time core and is unrelated to the code for CPU. Compilation can be done using virtually any compilers that support ANSI-C. The other folder named cos2-porting is where the implemented code is stored. Fig.1 ARM and FPGA hardware design Fig.2 Tree diagram of the software project uc/os-ii We used a CAN BUS monitor to test whether 512

the application was executable on the RTOS we have implemented. The main function of a CAN BUS monitor is to monitor data that flows through CAN BUS and display the data onto a 20 x 4 LCD text display. In our programming we created three tasks to perform this function. These were AppTaskStart(), AppTaskCanMcp2515(), and AppTaskLcd(). The communication of data between tasks AppTaskCanMcp2515() and AppTaskLcd() was through a global variable array. Figure 3 illustrates the operations between these three tasks. When the program proceeded from bootloader to main() function, it first initialized all relevant peripherals and finally creates the task AppTaskStart(). Two more tasks AppTaskCanMcp2515() and AppTaskLcd() were created within task AppTaskStart(), and the task AppTaskStart() was associated with the LED flashing at once per second to indicate whether the system is currently running. The main function of task AppTaskCanMcp2515() was set to capture data on the CAN BUS once per 0.5 seconds and store it in the global variable array. Since the data is captured sequentially, the capture cannot be interrupted or the data becomes corrupted; therefore we had to disable the interrupt with OS_ENTER_CRITICAL() during the capture and resume with OS_EXIT_CRITICAL() once completed. This ensures that a complete series of data is captured in full. The function of task AppTaskLcd() was to read data from the global variable array and display on the LCM module every second; the LCM module will then be able to show the data currently captured from CAN BUS and its ID. Similarly, to make sure that a series of complete data is displayed, we disabled and resumed the interrupt using OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL() functions. This application is programmed to perform three different functions through three tasks. 4.1 Program downloading and writing First we proceeded with the program writing and downloading. Generally, in a FPGA system, the FPGA program needs to be developed before writing the ARM program. During the development of the FPGA program, we first wrote the file *.sof into the internal SRAM for testing, through the JTAG pin using the JTAG mode as illustrated in Figure 4. Once development is complete, we then wrote the program into the designated ROM through the AS pin using the AS mode as illustrated in Figure 5. This allowed the ROM to initiate communication with the FPGA upon system startup and download the program into the SRAM of the FPGA for execution. Fig.4 JTAG download mode Fig.5 AS download mode Before writing the completed program into the internal ROM of the ARM, we first connected the JTAG wire and the writer properly as illustrated in Figure 6 then set the writing parameters as illustrated in Figure 7: 1. Set the capacity to 256Kbytes. 2. Execute the write command. 3. Details of the writing process are displayed in the message window. Fig.3 Operation status between tasks 4. System Test Fig.6 ARM JTAG pin diagram 513

4.3 Testing the MCP2515 control board Fig.7 Setting and executing the writing of ARM program 4.2 Testing the peripheral of FPGA The next step was the testing of FPGA accessory components. We tested the read/write of each accessory connected to FPGA to make sure that the basic read/write passed before proceeding with further development. The result of the write test is shown by LED. The LED address decode is defined as 0x80100000 in the FPGA program, therefore all our ARM program needs to do is write 0xAAAA into this address and the LED will display the test result. As illustrated in Figure 8, only 6 bits of data were displayed since we only had 6 LEDs. Fig.8 Testing the FPGA write function The next step was to test the MCP2515 CAN BUS controller. This part tested the simulation of SPI protocol using GPIO by the ARM program to control the read/write of the MCP2515 IC. The controller included buttons for testing data reading and a LED for data writing. The test of the write function was programmed to the MCP2515 BFPCTRL(0x0C) register to output data values to the pins. Figure 10 shows the actual testing. Because the lighting of the LED had a low electric potential, its two pins were defined as bit4 and bit5 of the BFPCTRL register; therefore the electric potential is opposite to the LED status. Fig.10 Write in test The test of the read function was programmed to read the MCP2515 TXRTSCTRL(0x0D) register for button status. Figure 11 shows the button values captured by the program, before and after the button was pressed. We set a break point in the program to better observe the data display. From left to right, the button statuses are reflected in bits 3, 4, and 5 of the TXRTSCTRL register. The electric potential was high before the button was pressed, and when the button was pressed we read a low electric potential value of 0. The basic input of FPGA includes a flick switch and buttons. Input address decode is defined as 0x80F00000. If the ARM program reads from this address as illustrated in Figure 9, it will capture the flick switch and button values. Here we tested the read function using the flick switch. Fig.11 Read out test Fig.9 Testing the FPGA read function 4.4 Operating the CAN development kit In order to test whether the system we designed was able to run the application on top of the RTOS, we used a CAN BUS monitor. We also needed a tool to send packets of data through CAN BUS to verify whether the system could receive data from another CAN node. Here we used a CAN development kit by Microchip. Figure 12 shows 514

the appearance of the control panel. The panel has other functions, what the figure displayed was its main functions. Fig.12 Control board of the CAN development kit between nodes. Since both the system and the CAN controller used 16MHz oscillators, we set the SJW to 1. We can see from the left window of Figure 14 that the CAN controller was in configuration mode when we set the parameters; if it was in normal mode the software would have displayed a warning message to remind users to switch to configuration mode. Register values set under any other modes are invalid. As we can see in the right window of Figure 14, the CAN controller of this panel went into normal mode when Go On Bus is pressed, and users could then receive or send data; however we were only using this panel to send. Here we can see the CAN controller switching to Normal Mode as illustrated in the bottom right window of Figure 14. Once hardware was connected properly, we opened the controlling software included in this kit: CANKing, from the PC end. Only through this software were we able to control CAN related functions and settings. As Figure 13 illustrated, we selected the template then MCP2510 evaluation board to enter the control window. Fig.14 Settings of CAN baud rate (left) and connection (right) Figure 15 shows the control panel of the software CANKing; some of the functions and the switching between windows are operated through this screen. Other than the opening of templates with default windows and settings, we may also save the current settings to another file for later use. Fig.15 Control panel Fig.13 settings for the software open The next step was the setting of CAN baud rate as illustrated in the left window of Figure 14. Baud rate was set at 125Kbps with sampling point=62.5% and SJW=1. The sampling point was generally set at 60-70% to assert a logic level. SJW stands for synchronization jump width, whose main function is to synchronize the difference in the clock frequency Figure 16 is the data settings window and is where CAN data is sent. Here we were able to specify CAN ID (CAN envelope), data length (DLC), and value (Line0-7). Once the setting was done, the data could be sent through the CAN BUS by pressing Send. The message output window simultaneously displayed the values sent as illustrated in Figure 17. 515

5. Conclusion and future prospects Fig.16 Data settings window Fig.17 Message output window Once we connected the hardware and wrote the programs into ARM and FPGA, we started transferring data through CAN BUS into the tested system using the software package CANKing. If the system was set up correctly, it would display the data sent through CANKing as illustrated in Figure 18. Our comparison found that the data settings in Figure 16 matched the data and ID displayed on the LCM screen of the system. This method would verify whether the system was able to correctly receive data transmitted from another CAN node. Fig.18 Receiving CAN data transmitted from PC Figure 19 is a diagram of the entire hardware structure. Figure 20 is the actual appearance. Although the hardware and software functionality of the system testing platform we built was limited, it contained the absolute basic workable environment that can be used for learning hardware/software verification and RTOS programming. Based on the application of a "CAN BUS monitor", we illustrated the structuring of an embedded system from the hardware design of ARM+FPGA, development of BSP drivers, implementation of RTOS, to the programming of an application. The outline structure was complete, and the following developments can be generalized into two directions: first is enhancing the applicability of this system. How are we able to utilize the characteristics of this system for wider applications? Other than improving our aims, we may also attempt to develop various applications on top of this platform. Second is further in-depth research on RTOS or the CAN BUS protocol. The application of this system platform was based on ARM+FPGA hardware structure, which offers extensive capabilities including the development and configuration of ARM system programs, RTOS, and FPGA programs etc. We could even execute some of the ARM program computations inside the FPGA and evaluate whether this improved system efficiency and achieves our goal of co-verification and operation. In addition we could also raise our CPU and FPGA levels according to the complexity of the system to perform more complex verifications and applications. 6. References Fig.19 The connection diagram for the system architecture [1] hang-ji Chang, Masters thesis on Hardware / Software Co-Designing Platform for Embedded Signal Compression System, National Yunlin University of Science and Technology, 2003. [2] hing-long Lin, Masters thesis on Development of DSP-Based RTOS Core, National Yunlin University of Science and Technology, 2004. [3] hien-shing Huang, Masters thesis on Design and Construction of DSP/CPLD Digital Circuits Development System, Chung Yuan Christian University, 2002. [4] hing-long Su, Structuring and Design of a System-On-Chip Prototype Development System, 2007 System Prototype and Innovative Circuitry Design Forum, Tainan County, ROC on 28th September 2007 [5] Cyclone Device Handbook, Altera, 2007 Fig.20 Hardware structure and testing environment of the entire system 516