Microprocessor logic expansion and verification of FreeARM7 IP core

1 Introduction to FreeARM7 IP core
The ARM7 series of FreeARM microprocessors (FreeARM7 for short) was first released on www.socvista.com. It was developed by Free-arm and other ARM enthusiasts based on the ARMv4 architecture. The entire
IP core code is described in synthesizable Verilog HDL, with simple interfaces and concise descriptions. The total code does not exceed 2000 lines. In terms of overall design, a three-stage pipeline and Harvard structure are used, which are fully compatible with various interrupts and operation instructions (except Thumb and coprocessor instructions). After evaluation, it can be seen that the IP core has good implementation results based on FPGA and SMIC process libraries.
The FreeARM7 interface definition is listed in Table 1, which can be summarized into 4 categories:
◆ System interface, providing system control signals;
◆ Interrupt source, providing 5 interrupt signals required by the ARM architecture;
◆ ROM interface, the interface between the ROM that provides instructions;
◆ Single-port RAM interface, the interface for data interaction between the single-port RAM and peripherals.

Among them, the single-port RAM interface can achieve two types of uses: 1. Attaching a single-port RAM allows FreeARM7 to read and write data correctly; 2. Attaching peripherals allows FteeARM7 to operate peripherals correctly.

2 Microprocessor Improvement and Logic Expansion
The structure of the microprocessor improvement and logic expansion based on FreeARM7 is shown in Figure 1. The expected implementation goal is: after the embedded program is compiled into machine code on the host, it is transferred to the dual-port RAM through the USB 1.1 device controller. In the microprocessor code download mode, the code download control logic loads the machine code in the dual-port RAM into the ROM, and then starts the normal working mode of the microprocessor. The microprocessor executes the embedded code in the ROM, receives the parameter value transmitted by the host through the USB, and returns the operation result to the host through the USB.

When implementing based on Cyclone II FPGA, ROM, RAM and dual-port RAM are all instantiated using the MegaWizardPlug-In. Manager tool in Quartus II software to instantiate the corresponding storage modules, while other hardware logic extensions are in the form of IP cores (Verilog descriptions). [page]

2.1 Improvement of Microprocessor IP Core
The FreeARM7 IP core is the core part of the microprocessor and cannot be used directly as a microprocessor because the data bus needs to read the data in the ROM. This paper selects the Philips 32-bit ARM7 microprocessor LPC2101 as the prototype design. LPC2101 has appropriate storage resources, embedded with 2 KB on-chip static RAM and 8 KB Flash memory, and has good software portability and reliable operation. Referring to the working principle of LPC2101, when the highest 4 bits of the FreeARM7 output signal ram_addr are 4'b0, it means that the data bus needs to read the ROM data. To solve this problem, a wrap file lpc2101_arm.v is added to complete this function. Its function is: when ram_addr[31:28]==4'b0, the logic directly reads the ROM data from the interface of rom_en, rom_addr, and rom_data and sends it to ram rdata.
2.2 USB1.1 device controller
The USB device controller selected in this paper is one of the early projects of the research group. It is improved from the primary open source version provided by the Opencores website. Its structure is shown in Figure 2. The IP core supports low-speed and full-speed modes, with a total of 1 control transfer endpoint (EP0) and 7 other configurable endpoints. It can respond to the host's enumeration of the device even without a microprocessor. The transceiver circuit mainly completes the analog/digital signal conversion, that is, in the OUT transaction, the analog signals D+ and D- are converted into digital signals rxd, rxdp and rxdn that can be recognized by the serial interface engine module, and in the IN transaction, the digital signals txdp and
txdn are converted into analog signals D+ and D- under the control of the enable signal txoe; the serial interface engine module mainly completes the transmission and reception of packets, which can be divided into reception and transmission according to the transmission direction, mainly including bus detection, synchronization detection, clock recovery, non-return-to-zero reverse encoding and decoding, bit filling and bit removal, and serial/parallel conversion of data; the protocol layer includes the protocol engine state machine, packet assembly, depacketization, and FIFO controller; the endpoint O controller is mainly responsible for responding to the host standard request; the descriptor RAM stores various descriptors of the device; other endpoint controllers and FIFO provide configuration interfaces, the purpose of which is to reserve them for developers to transplant IP cores.

2.3 Code download control logic
The main function of this logic is to transfer the assembly program in the dual-port RAM to the ROM in the code download mode. Its main task is to generate the enable signal and address signal for reading the dual-port RAM, as well as the enable signal and address signal for writing the ROM. It is implemented in the hardware logic through a counter. When the system is reset or exits the code download mode, the counter: rom_wr_cnt is cleared, otherwise when the USB receives a packet (64 bytes), the counter enable signal cnt_vld is set valid, and rom_wr_cnt starts counting. cnt_vld is directly used as the enable signal for reading the dual-port RAM, and cnt_vld is used as the enable signal for writing the ROM after two levels of caching. At the same time, the lower 8 bits of rom_wr_cnt are directly used as the address signal for reading the dual-port RAM, and the calculation result of rom_wr_cnt is used as the address signal for writing the ROM after two levels of caching. When the 64 bytes are transferred, cnt_vld is invalidated. At this time, rom_wr_cnt latches the current value and waits for the next packet to be received before setting cnt_vld valid again. The code download control logic appends the data of the next packet to the ROM. Repeating this process completes the download of the code to the ROM via the USB interface.

3 Embedded Code Development
3.1 uVision3.63 Environment Settings
Use μVision3.63 to create a new project, select the device type as the LPC2101 of the NXP (founded by Philips) series, and make the following confirmations based on the default project environment:
① Select "Create HEX Flie" in the "output" tab to ensure that machine code is generated for download.
② Select Code Generation as "ARM-Mode" in the "Target" tab to ensure that machine code is generated based on the ARM instruction set.
③ Select "EnableARM/Thumb Interworking" in the "C/C++" and "Asm" tabs respectively to ensure that the generated code contains only ARM instructions. [page]

3.2 Bootloader Setup
Bootloader startup is generally divided into two stages. The first stage mainly contains the code that depends on the hardware initialization of the microprocessor architecture, sets the stack and jumps to the entry point of the C program in the second stage, which is usually implemented in assembly language. The second stage is usually completed in C language to achieve more complex functions and make the program more readable and portable. In the sample project "Hello" that comes with the μVision3.63 software, the following three lines of code are used to implement the work handover of the two stages:

Since the microprocessor discussed in this article is just some basic extensions based on FreeARM7, the architecture hardware of the microprocessor is single, so the first stage is mainly to set the stack position and size. The initialization of the USB interface is carried out in the C program of the second stage. The initialization program is as follows:



4 Functional verification of the microprocessor
After completing the previous work, the microprocessor was functionally verified with the help of FPGA. The DE2 development board of Altera Company was selected as the implementation carrier of the hardware logic. The working clock of the microprocessor IP core is the 27 MHz crystal input on the development board, and the working clock of the USB controller IP core is the 27 MHz crystal multiplied to 48 MHz. The functional verification process is shown in Figure 3. After the verification program is written and compiled on the host using μVision 3.63, the microprocessor enters the download mode to receive the code downloaded by the host to the device, and then enters the user mode to receive the verification program parameter values ​​transmitted by the host. After running the code, the execution result is returned to the host, and the purpose of verifying the microprocessor operation result is achieved by comparing it with the host software simulation result.

[page]

4.1 Verification Program Development
The Data Encryption Standard (DES) is a well-known symmetric key block cipher defined by the US standard FIPS 46-2. Based on the ARM7 instruction system, the C language implementation of DES is not difficult, but it is a comprehensive test of the working ability of the IP core. The DES algorithm is decomposed into a key generation algorithm and an encryption and decryption algorithm, corresponding to the two sub-functions in the verification program. The final code implementation framework is as follows:


4.2 Host driver and communication software development
The Windows Driver Model (WDM) aims to provide a flexible way to simplify the development of various drivers, support new hardware, and reduce the complexity of driver development. Based on WDM, using Driver Studio to develop a USB driver will automatically generate a driver framework. On this basis, adding read and write pipes can complete the development of the driver. The
USB communication software is written in MFC, and its main functions are: sending .hex files to USB in hexadecimal form, receiving USB returned data, and displaying it in hexadecimal form. The DES program standard test vector is used, where the initial key K=1A624(289520DEC46, plain text P=748502CD38451097, cipher text C=DDOCFEB783CF3FDE, and the code download and verification data transmission and reception in the communication software are shown in Figure 4. According to the above principle, several other verification programs are also written and downloaded to the ROM, and the execution results of the microcontroller are all correct.