Remote monitoring system based on FPGA SoC and embedded system

This system is based on the use of the Internet to achieve remote collection of nuclear environmental information. In terms of implementation, an embedded solution based on SOPC technology is adopted. By embedding the NioslI soft-core processor and the IP Core (silicon intellectual property core) of the required peripherals in the FPGA, and then equipping it with the corresponding network interface, information transmission can be achieved using the Internet.

In addition, by developing an IP core for controlling the information acquisition subsystem and utilizing the inherent hardware parallel characteristics of FPGA, this system can achieve true parallel monitoring of multiple information sources, that is, it can acquire information such as gamma rays and temperature and humidity while detecting alpha rays.

1 System Hardware Design and Implementation

In the design of this system, in order to achieve universality, the hardware is divided into two parts in structure, namely, the general network platform for completing on-site monitoring and remote data transmission and the environmental information acquisition subsystem for completing temperature and humidity, liquid level, α and γ radiation total measurement and other tasks. Its structure is shown in Figure 1 and Figure 2 respectively. The two subsystems are connected by a 40-core flat cable. In terms of software, considering the complexity of remote data transmission using the Internet, the use of embedded operating system and TCP/IP protocol stack is an inevitable choice, so the hardware is also designed around this key point.

[page]

1.1 Niosii soft-core CPU

The NiosII soft-core CPU is a general-purpose 32-bit RISC embedded processor launched by A137ERA. It is specially optimized for programmable logic and is equipped with a full-featured development kit, including C/C++ compiler, integrated development environment (IDE), JTAG debugger, etc. It is the core of ALTERA's programmable single-chip system solution.

As a soft-core processor, NiosII provides configurable hardware and software debugging features, including basic JTAG operation control (run, stop, single step, memory, etc.), hardware breakpoints, data triggers, on-chip and off-chip tracking, and embedded logic analyzers. These powerful tools can be used in the development phase and can be removed after debugging to save resources. The NiosII processor also provides three cores with different performances: high, medium, and low. By combining with more than 60 IP cores (UART, clock, DMA, SDRAM, parallel I/O, etc.) provided by ALTERA, designers can easily create a perfect solution in terms of processor, peripherals, memory, and I/O interfaces for specific applications. In addition, NiosII has many other excellent features, such as instruction customization, hardware accelerators, etc.

1.2 Network Interface Unit

The Ethernet interface chip uses SMSC's LAN91C111 Fast Ethernet controller specifically for embedded products. The chip integrates both the Ethernet media access controller (MAC) and the physical layer transceiver (PHY), supporting 10/100M full-duplex transmission mode, automatic negotiation, flow control and other functions. Its host interface has multiple working modes such as synchronous bus and asynchronous bus, which can be easily connected to CPUs of various systems. This design uses the asynchronous bus interface mode, and shares the address line and data line with FLASH, and connects to the Avalon on-chip bus through the adapter module on the FPGA.

1.3 Memory Unit

Due to the need to store the operating system kernel, application code, program data, etc., this system uses a FLASH chip model AM29LV320D. This chip was launched by AMD, has a capacity of 4MB, supports the CFI interface, and its connection with the AvMon bus requires the bus adapter module inside the FPGA to perform timing matching. SDRAM is used to store program code and data during operation. HY57V563220B(L)T is a 16MB SDRAM launched by Hyundai. Since the port width of this chip can reach 32 bits, a single chip can be used in the system. The read and write timing of SDRAM is relatively complex, and a dedicated SDRAM controller IP core needs to be integrated in the FPGA to connect with it.

2 Total Count IP Core

As shown in Figure 2, the signal obtained by the α or γ detector is amplified by a linear pulse amplifier composed of two amplifiers connected in series, and then sent to the discrimination circuit with LM393 as the core for comparison, filtering out noise and outputting a rectangular pulse signal. For the processing of this signal, the traditional nuclear detector with MCU (microcontroller) as the core can only be realized through the existing hardware resources (such as timer) on the MCU combined with software.

This method is limited by hardware resources and the speed of MCU, and it is difficult to process multi-channel signal sources in parallel. In this system, the total count IP core is a hardware specially designed for this problem. It is designed and implemented using VHDL language. Its internal interface complies with the Avalon on-chip bus slave device interface specification and can be easily connected to the Avalon bus as a dedicated peripheral of the NiosII soft core cPu.

The total amount counting IP core is part of the daughter board interface in the network platform FPGA, and its structure is shown in Figure 3. The principle of α radiation total amount measurement is similar to that of γ radiation total amount measurement. The following takes α measurement as an example to introduce its working principle. The clock source module generates a 0.1 second pulse signal by dividing the main clock frequency, which serves as the reference source for the timer timing. The timer generates the required timing information according to the acquisition time transmitted from the command register.

According to the timing information of the timer and the command of the command register, the control counter counts the pulse signal transmitted from the α measurement module to obtain the count value of the total radiation, which is stored in the FIFO; on the other side, the NiosIICPU writes the corresponding command word to the command register of the IP core through the Avalon bus to control each channel, such as starting the total count, turning off the total count, setting the acquisition time and clearing the FIFO.

It is worth noting that the α or γ counting pulse from the discrimination circuit is an asynchronous signal with the working clock of this IP core, and the value of the counter needs to be stored in FIF0 in the end. Therefore, the α or γ counting pulse is latched and shaped twice with the main clock, so that each asynchronous counting pulse generates a synchronous pulse that only lasts for one main clock cycle. Counting with this pulse not only solves the problem of asynchronous signal synchronization, but also effectively filters out interference pulses, making the count value accurate. [page]

3. System software structure

In order to realize remote data transmission by using Internet, this system transplanted MicroC/OS2 real-time operating system and LWIP (Lightweight IP Protocol Stack) on NiosII and then developed information collection software on it.

3.1 MicroC/OS2 and LWIP porting

This part of the work is mainly to transplant the specific hardware of this system and write various drivers required such as the temperature and humidity sensor SHT75, the total amount counting IP core, etc. Therefore, in-depth understanding of the structure and details of each layer of the software is the key to successful transplantation.

HAL, or hardware abstraction layer, is part of the NiosII development kit and is provided by ALTERA. It encapsulates the relevant details of the hardware operation in the system, and the driver is also part of it. HAL abstracts six device models, including character mode devices, timer devices, file subsystems, Ethernet devices, DMA devices, and Flash devices, and provides a series of unified initialization functions and access function interfaces for each type of device. In this way, HAL provides a POSIX-like API interface to the upper layer, namely the hardware abstraction layer application programming interface.

Software development for NiosII is actually built on HAL, rather than directly targeting NiosII hardware itself. The interface IP cores corresponding to the measurement module of this system are all character mode devices, so the driver needs to be written according to the character mode device model in HAL.

MicroC/OS2 is a preemptive real-time operating system suitable for small microcontrollers. It supports 56 user tasks, and its kernel is preemptive. It supports a variety of commonly used inter-process communication mechanisms such as semaphores, mailboxes, and message queues, through which it provides the required multi-tasking environment for applications. Since MicroC/OS2 itself does not have a protocol stack, it is necessary to transplant a TCP/IP protocol stack LWIP, thereby providing an interface similar to UNIX sockets to the upper layer. LWIP supports the following network protocols: IP, ARP, ICMF, UDP, TCP. The protocol stack requires 20KB of code storage space and 4KB of data storage space. At the same time, a timer dedicated to its use needs to be added when building the system.

Figure 4 shows the startup process of the system software obtained through analysis. In this flowchart, alt_sys_init() is used to initialize the devices in the system, and the initialization program provided by the device driver is called during this process. Lwip_stack_init() is used to initialize the TCP/IP protocol stack. And tcpip_init_done() is a function called after the protocol stack is initialized, and the communication server task is also created in it. One thing to note is that all tasks based on LWIP should be created using the sys_thread_new() function instead of directly using OSTaskCreate(). Finally, after all the initializations are ready, OSStart() is called to start the RTOS for task scheduling.

3.2 Design of information collection program

As a task, this module runs on the MicroC/OS2 real-time operating system to complete the measurement and control of each detection subsystem based on strategy or remote instructions. The acquired information is saved in the specified memory buffer and the results are returned to the remote host as required. For temperature and humidity measurement, since the humidity output of the SHT75 sensor is nonlinear, in order to obtain accurate data, the acquired data needs to be corrected according to the given formula, while the temperature output does not need to be compensated. The digital output can be converted into the actual temperature value. For details, see the SHT75 data sheet. For the processing of total count, this module simply packages the data and hands it over to the communication server to transmit it back to the remote host.

3.3 Communication Server

This task is created through the sys_thread_new() function. It listens to the agreed port as a server, waits for the connection from the remote host, extracts the commands from the remote host, and sends the obtained commands to the information collection task through the message queue. At the same time, it also sends the various data obtained by the information collection task back to the remote host according to the requirements.

LWP provides a standard Berkeley socket programming interface, which provides three types of sockets. Stream sockets are used here, which is a connection-oriented reliable data transmission service, that is, the TCP protocol is used. Usually, when a server receives a concurrent service request, it activates a new process to handle the client request. However, for the sake of system resources and simplified design, the server can only accept one connection request at a time. This simplification can actually meet the design needs.

This system uses FPGA-based system-on-chip technology and embedded system technology to connect intelligent nuclear instruments to the Internet. It also realizes partial hardware reconfiguration. By adding or deleting peripheral IP cores in FPGA as needed, the system can be changed in function and performance. At present, this system has been used in radioactive sample storage rooms, and its functions and performance meet the requirements of the actual environment. Since the network platform of this system is designed as a relatively independent subsystem, it only needs to develop a specific detection subsystem to be applied to various corresponding fields that require remote monitoring.