Detailed explanation of SoPC application system design based on μClinux

Embedded systems generally consist of four parts: embedded microprocessors, peripheral hardware devices, embedded operating systems, and user applications. Their development is mainly reflected in the progress of chip technology, as well as the progress of algorithms and software under the limitations of chip technology. With the development of chip manufacturing technology, the structure of embedded systems has also undergone major changes, from embedded systems based on microprocessors to embedded systems based on microcontrollers, and then the programmable logic PLD (Programmable Logic Device) technology was introduced into embedded system design, and then developed into SoC (System on Chip), and finally PLD was combined with embedded processors to become SoPC (System on Programmable Chip), making SoPC a development trend in embedded system design.

This paper uses the 32-bit soft-core processor Nios embedded in SoPC to implement a converter between UART serial port and Ethernet interface (hereinafter referred to as the converter), and develops an application based on μClinux transplanted by Microtronix for Nios processors.

1 Construction of embedded hardware platform based on SoPC

Different from embedded systems based on processors or controllers and SoC, embedded systems based on SoPC are configurable and do not include any dedicated peripherals. Instead, peripheral interfaces can be flexibly constructed in an FPGA as needed.

Embedded systems based on SoPC are mainly composed of a core chip SoPC and off-chip devices, as well as some related interface devices. The converter to be implemented in this paper is composed of Altera's Cyclone chip and peripheral circuits, including 2 512 KB SRAMs, 1 8MB Flash, UART electronic converter and 1 Ethernet controller LAN91C111. The

SoPC chip has a built-in soft-core processor Nios. In addition to the CPU, the SoPC chip can be equipped with system components such as on-chip ROM, internal timer, UART serial port, SRAM, Flash interface, etc. These components are all implemented in the form of programmable logic components. The internal component structure of the chip is shown in Figure 3. The CPU and all components are connected together through the Avalon bus.

The system module and Avalon bus module in the SoPC chip are automatically generated by the SoPC Builder tool. The logic design and pin definition of the chip can be realized by using the Qualtus II integrated development environment. After compilation, a hardware image file with the suffix .sof is generated and downloaded to the Cyclone chip of the target board through the ByteBlasterII cable, or the .sof file is converted into a .flash file and downloaded to the Flash of the target board. In this way, the hardware design of the converter is completed.

2 SoPC application development based on μClinux

Application development can be carried out directly on the hardware platform, but it is necessary to understand the details of all hardware components and write corresponding driver subroutines. The software design difficulty and workload are large, and the portability is poor. For applications based on embedded operating systems, all hardware details are shielded from users. The underlying drivers that directly control the hardware are encapsulated in the operating system and completed through the device driver interface. Users only need to program at the high level through the system calls provided by the operating system. μClinux is an embedded Linux operating system for the control field, suitable for microprocessors/microcontrollers such as Nios processors that do not have a memory management unit (MMU). To develop based on the operating system, the operating system needs to be loaded into the hardware platform. μClinux can be integrated into the SoPC system as a component.

2.1 Steps to load the μClinux system

When loading μClinux onto the SoPC target board, a cross-compilation environment needs to be provided. The hardware requirements include a PC workstation with a serial port, a SoPC target board based on the Nios processor, and a ByteBlasterMV cable. Software requirements include Windows NT v4.0, Windows 2000 or Windows XP, the Nios GNU Pro tool provided in the Altera Nios development kit NDK 3.0, the cygwin installation provided by the Ahera Nios development kit, and the Quartus II programmable logic development tool V2.2.

2.1.1 Create and load the kernel image

To create and load the μClinux image file, perform the following steps to configure and build the kernel.

[Linux Developer]…μClinux／:cd linux

[Linux Developer]…linux／:make xconfig

[Linux Developer]…linux／:make clean

[Linux Developer]…1inux／:make dep

[Linux Developer]…linux／:make

[Linux Developer]…μClinux／:make linux.flash

The generated linux.flash file is the μClinux kernel image. When the SoPC target board is powered on and the GERMS monitoring program in the on-chip ROM is running, type nios-runlinux.flash under [Linux Developer]…μClinux／: to download the linux.flash file to the target board and complete the loading of the kernel image.

2.1.2 Create and load the root file system

In addition to loading the kernel, the root file system must also be loaded. μClinux uses the romfs file system, which requires less space than the general ext2 file system.

The target directory of Linux on the host represents the root directory under μClinux. The current scripts and tools can convert the target directory into an image file (romdisk.flash). Follow the steps below to create it:

[Linux Developer]…μClinux／: make clean_target

[Linux Developer]…μClinux／: make romfs

Then type the following command:

[Linux Developer]…μClinux／: nios-run romdisk.flash

This will download the romdisk.flash file to the target board and complete the loading of the μClinux root file system. [page]

2.1.3 Loading Applications

User applications can be loaded into the root file system through the target directory, and the romdisk image can be rebuilt as needed. The application is in the userland directory. After compiling and generating the run file, it is copied to the target directory tree, and the romdisk.flash file is created based on the content of the target directory. To create a new application, first open a LinuxDeveloperBash window, create a directory app in the userland directory, store the application source files in this directory, and then create a makefile in userland/app/.

The Makefile content is as follows, where appfile is the application name.

STACKSlZE=8192

include..／..／Rules.make

all：appfile.relocbflt

SOURCES=appfile.c

install：

$(ROMFSINST)appfile.reloebfh

$(ROMFSDIR)／bin／appfile$(EXECSUFFIX)

clean：

rm-f *.[iods]core appfile appfile.*elf appfile.*bflt

Run make to compile the application and modify the userland/.eonfig and /userland/Makefile files. In the userland/.config file, add a line CONFIG_MY_APP=y, in the userland/Makefile file, add dir_$(CONFIG_MY_APP)+=app, enter the userland subdirectory, run make, and the application will be installed in userland/bin, and the application binary will be copied to the target directory according to the instructions of the corresponding variables in the userland/.config file.

Finally, type the following command to rebuild the romdisk image file (romdisk.flash) and download it to the target board.

[Linux Developer]…uClinux／：make clean_target

[Linux Developer]…uClinux／：make romfs

[Linux Developer]…uClinux／：nios-run romdisk.flash

2.1.4 Run μClinux

After the μClinux kernel and file system are loaded, μClinux can be run. Type g800000 (800000 is the startup code address, set in SoPC Builder), μClinux automatically completes the initialization process, the user enters the login username nios, password μClinux, and the μClinux prompt # appears, indicating that the μClinux operating environment has been entered.

2.2 Implementation of the Converter Application

The converter application system mainly completes the data transmission between the network interface and the serial interface.μClinux operating system provides network driver and serial port driver, and provides multi-thread support.

The serial port data reception and transmission and the network port data reception and transmission in the converter application system are asynchronous and can be treated as a task respectively. The tasks are concurrent, so multi-threaded programming technology can be used to achieve concurrent execution of multiple tasks.

There are 4 tasks in this application system, and 4 threads are created respectively: network receiving thread, network sending thread, serial port receiving thread and serial port sending thread. These 4 threads can be executed concurrently. Because there is a difference between the network speed and the serial port speed, it is necessary to set up a corresponding buffer to buffer the received and sent data. Two circular buffers are set up in this application system, as shown in Figure 4, where nctrv_uartsd_buf is used to receive network data and store data received from the network port, and then the serial port takes out data from this buffer and sends it. Another buffer uartrv_netsd_bur is used to receive serial port data, and then the network port takes out the data in this buffer and sends it out.

Threads need to communicate and synchronize with each other. The shared buffer must be executed both mutually exclusive and synchronously. Its operation follows the producer and consumer model. Mutual exclusion operations between threads are implemented using mutex. Synchronization between threads is achieved by setting two pointers, one is the read pointer and the other is the write pointer. The write pointer points to the head of the queue and is initialized to 0. The read pointer points to the tail of the queue and is initialized to BUFSIZE-1. When writing data, compare whether the read and write pointers are equal. If they are equal, the write thread is blocked; if they are not equal, write data and then increase the write pointer by 1. When reading data, increase the read pointer by 1, and then compare whether the read and write pointers are equal. If they are equal, the read thread is blocked; if they are not equal, read out data.

The network sending thread and the serial port receiving thread share the ring buffer uartrv_netsd_buf. The serial port sending thread and the network receiving thread share the ring buffer netrv_uartsd_buf. The relationship and processing between the two threads are similar to the network sending thread and the serial port receiving thread.

3 System test

After completing the software and hardware design of the converter, connect the system to perform the data transmission test of the converter. Run the serial port transceiver program on PC A, and run the Ethernet transceiver program on PC B. After testing, the data transmission is correct.