The concept of System-on-a-Chip (SoPC) has become increasingly popular. With the rapid development of FPGA technology, System-on-a-Chip (SoPC), as a special type of embedded microprocessor system, combines the advantages of both SoC and FPGA, possessing in-system programmability, customizability, expandability, and upgradeability in both hardware and software. It has gradually become an emerging technology direction. The core of SoPC is an embedded microprocessor core implemented on an FPGA. Currently, the main types include Xilinx's 32-bit soft core MicroBlaze, the 32-bit PowerPC series processor hard core PowerPC 405, and Altera's Nios series microprocessor soft cores. This article introduces a system using a PowerPC 405 microprocessor as the microprocessor and an Ethernet interface device based on the VME bus. It achieves real-time data exchange between the VME system and an external local area network through Ethernet and VME bus interfaces. Hardware Development Development was conducted using Xilinx's EDK 7.1 (Embedded Development Kit) and ISE 7.1 software tools. The EDK toolkit integrates a hardware platform generator (Platgen), a software platform generator (Libgen), a simulation model generator (Simgen), a software compiler (Mb-gcc/ppc-gcc), and software debugging tools (Mb-gdb/ppc-gdb). Through the provided integrated development environment XPS, users can utilize all these tools to complete the entire embedded system development process. First, the hardware system framework is generated and the required IP cores are added within the XPS interface. Alternatively, a hardware description file (.MHS file) can be directly written using a text editor. Then, Platgen is used to generate the netlist file (.NGC file) for the embedded processing system. Next, the system software configuration is set using a system-generated or manually edited software description file (.MSS file), and Libgen is used to generate the driver layer and libraries. While the EDK IP library contains some useful functional modules and peripheral interface IP cores, such as DCM (Digital Clock Manager), processor reset, PLB/OPB bus interface, external memory controller (EMC), UART, GPIO, interrupt controller, and timers, fully utilizing these resources can build a relatively complete embedded microprocessor system. However, this is insufficient for many embedded computer systems with specialized dedicated circuits. There are generally two methods for designing user-specific circuits into the EDK system. The first method involves treating the EDK project as a subsystem and generating an ISE project in XPS using Export to PorjNav. Then, in ISE, the dedicated circuit and processor subsystem (system.vhd) are combined into a top-level HDL file (system_stub.vhd). Synthesis and routing are then performed in ISE. Finally, the hardware .bit file is obtained in XPS using Import from PorjNav, allowing for integration, downloading, and debugging with the application software in XPS. The second method involves designing the dedicated circuit as a user-defined IP core and then directly calling it within the system. Custom IP cores are designed using HDL and must conform to EDK specifications, such as having a dedicated directory structure and processor peripheral definition files (.MPD), peripheral analysis definition files (.PAO), etc. If the custom IP core needs to have software drivers, the design must also fully comply with the corresponding PLB or OPB bus interface specifications. After completing the hardware and driver design, an application software project can be added to the XPS project, and the application software can be written. Then, the compiler corresponding to the processor is called to compile it, and the .bit file generated after hardware synthesis is combined and downloaded to the target board for debugging. The hardware block diagram of this system is shown in Figure 1. This design uses the Virtex-II Pro series FPGA chip XC2VP40. The system's program memory and data memory are both implemented on-chip using Block RAM. A DCM module is added to the system to provide the external reference clock at a 4x frequency to the PowerPC 405 as the processor clock, and then divides the frequency before sending it to the OPB bus as the bus clock, reducing the bus speed of slow peripherals and making the system more rationally configured. [IMG=System Hardware Block Diagram]/uploadpic/THESIS/2007/12/2007121209330179972H.jpg[/IMG] Figure 1 System Hardware Block Diagram. The PowerPC 405 is the core of this embedded system. It implements a fast channel to the program memory and data memory through the PLB bus, and implements the on-chip OPB bus through the PLB-OPB bridge. Then, various peripherals are expanded through the OPB bus. The OPB peripherals include an RS232 serial port, an OPB_EMC for expanding the Ethernet controller chip, a GPIO for interrupt requests from the Ethernet controller output, an interrupt controller OPB_INTC to notify the PowerPC 405 of external interrupts input from the GPIO and can set the priority, and a user-defined IP core for implementing the interface circuit with the VME bus. The PowerPC 405 is a high-performance 32-bit PowerPC series processor core specifically designed for embedded applications. For Virtex-II Pro series FPGAs, its implementation model is PowerPC 405D5. The Processor Native Bus (PLB) provides independent 32-bit address and 64-bit data buses for both instruction and data sides. The PLB bus architecture supports multiple master-slave devices. Each PLB master connects to the PLB via independent address, read, and write data buses. A central decision-making mechanism authorizes access to the PLB, allowing masters to compete for bus ownership. The On-Chip Peripheral Bus (OCB) provides separate 32-bit address and 32-bit data buses and is typically used to access low-speed and low-performance system resources. It is a fully synchronous bus but not directly connected to the processor core. The processor core accesses OPB interface peripherals through a "PLB to OPB" bridge and the OPB bus. The network controller uses the Cirrus Logic CS8900A, a general-purpose single-chip 10/100M Ethernet controller. This chip fully complies with the IEEE 802.3 Ethernet standard and supports full-duplex operation. Using the EDK OPB_EMC IP, the CS8900A can be easily expanded into a device on the system's OPB bus. Simply connect the EMC port's address, data bus, and control signals to the CS8900A's address, data bus, and control ports respectively, and set the EMC timing parameters to match the requirements in the CS8900A manual. Additionally, the CS8900A's interrupt output INTRQ is introduced as a GPIO to implement Ethernet interrupt service functionality. The custom IP core content is shown in Figure 2. It uses 64KB of dual-port RAM within the FPGA's Block RAM resources to handle communication and data exchange with other devices on the VME bus. We use the second method described above to embed user-specific circuitry into the microprocessor system. The custom IP mainly consists of an OPB bus interface and user circuitry. We modify the OPB bus IPIF template provided by EDK as the bus interface for the custom IP, while the 64KB dual-port RAM and VME bus interface constitute the actual user circuitry. [IMG=Custom IP Core Structure]/uploadpic/THESIS/2007/12/2007121209331256813R.jpg[/IMG] Figure 2. Software Development with Custom IP Core Structure The Embedded Development Kit (EDK) divides software development into two main parts: the development of low-level system software, primarily fulfilling the functions of the Board Support Package (BSP); and the development of user application software (including user hardware drivers and upper-level user application software). Since the EDK includes many IP cores and corresponding driver software, most of the low-level system software development can be completed using the EDK integrated development environment, such as operating system selection, device driver selection, interrupt/exception handling routine settings, and operating system parameter settings. User application software development, due to the isolation provided by the low-level drivers, offers good portability. The entire user software development and debugging process can be completed within the EDK. Low-level system software development In this design, no operating system is used; instead, a so-called standalone mode is employed, meaning the EDK only provides hardware initialization and boot code. Furthermore, low-level drivers need to be generated for peripherals such as GPIO, EMC, RS232, and the interrupt controller. These can be configured through the EDK integrated environment XPS by selecting the menu Project->Software Platform Settings, as shown in Figure 3. Essentially, this automatically modifies the project's .MSS file. For example, interrupt handling routines can be configured in the interface shown in Figure 4. Alternatively, you can manually edit the .MSS file and set it as follows: PARAMETER int_handler = CS8900A_INT_HANDLER, int_port = IP2INTC_Irpt [IMG=Setting up the operating system and drivers in XPS]/uploadpic/THESIS/2007/12/2007121209331785795K.jpg[/IMG] Figure 3 Setting up the operating system and drivers in XPS [IMG=Setting up interrupt service routines in XPS]/uploadpic/THESIS/2007/12/2007121209332639751L.jpg[/IMG] Figure 4 Setting up interrupt service routines in XPS After setting, run Tools->Generate Libraries and BSPs will automatically generate driver library files using LibGen. The settings, operation function implementations, or definitions of these CPU and peripheral driver libraries can be found in the corresponding module subdirectories under the libsrc directory (named after the processor instance) in the project root directory. Referring to their implementations helps in understanding the actual operations. For example, the interrupt vector table can be found in the xintc_g.c file under the mid-channel vector controller module subdirectory (intc_v1_00_c\src in this example). User Software Development User software mainly operates the network controller, GPIO, RS232 serial port, etc. The program controlling the CS8900A is a crucial part, as it must implement the TCP/IP protocol. All control and data registers of the CS8900A are mapped to a 4K on-chip address space called PacketPage. This 4K space can be mapped to the host address space (memory mode) or accessed through eight 16-bit I/O ports (I/O mode). In this design, the CS8900A operates in I/O mode, using the EDK's OPB_EMC IP as a device on the OPB bus. Address space is allocated to the EMC controller and the mapped device. The program uses `Xuint32 XIo_In32(XIo_Address InAddress); void XIo_Out32(XIo_Address OutAddress, Xuint32 Value)` to read and write to the mapped device. These two I/O functions differ from `*pDestMem = Value` (direct memory read/write operation) in that the former performs read/write synchronization (calling the `eieio` assembly instruction). The CS8900A driver is written based on the chip datasheet, implementing basic I/O operations `CS8900A_SendFrame` and `CS8900A_RecvFrame`. The EDK includes a paid Ethernet IP core and some TCP/IP protocol stacks. This stack implements most common functions, but some important functions are not implemented, such as TCP packet timeout retransmission and interrupt-driven operation for send/receive. By modifying, adding to, and improving these software packages, a network programming interface truly oriented towards higher-level user application software was realized. Some problems encountered in software development The main problems encountered in the software development process are summarized as follows: (1) The IEEE 802.3 network and the network controller CS8900A both use Little Endian encoding, while the processor PowerPC 405D5 contained in the XC2VP40 uses Big Endian encoding. Therefore, a conversion is required during data I/O. (2) The linking process of the application can be controlled by writing a link control script file, thereby controlling the relocation process of the program image in memory. This is sometimes very useful in environments with limited memory resources, such as FPGAs. (3) The default bootloop program provided by EDK should be packaged into the hardware initialization stream. The purpose of doing so is to provide a default program to run after CPU reset, ensuring that the CPU is in a predictable state, rather than in an unknown state due to the execution of random code in memory. System Debugging Methods Since the PowerPC 405 processor core already includes a debug module accessible via a JTAG port, simply adding an IP module called JTAGPPC to the system and connecting it to the PowerPC 405 allows its debug port to be chained into the FPGA's JTAG chain. This way, system software debugging can be completed using only the FPGA's own download cable and JTAG interface without adding any additional circuitry. The EDK provides XMD and GDB as the main software debugging tools. It's worth noting that when downloading the executable image using XMD, the relocation status of each program segment is displayed, and errors are reported when they occur, such as requests for address space exceeding the available address space—errors not visible in the EDK integrated environment. In cases with multiple types of memory resources, writing a link control script to control the relocation process may resolve the aforementioned insufficient address space issue. Debugging of the network communication section is primarily assisted by Sniffer software. GDB, a GNU host-side graphical interface debugging tool included with the EDK, completes graphical interface debugging functions by communicating with XMD. In this case, XMD acts as a host-side debugging agent, with all debugging communication handled between XMD and the target machine. In conclusion, SoPC makes hardware design truly as convenient and rapid as building blocks. Using the EDK development tools, an integrated hardware and software development of an FPGA-based embedded system can be achieved, significantly improving the development efficiency of embedded systems. However, it still has many shortcomings. First, system design is highly dependent on design tool software, which still has many areas that need improvement. Designers inevitably spend a lot of time learning how to use and become familiar with the software. Second, the continuous enrichment and improvement of IP cores is the foundation of SoPC. Expensive paid IP cores are not conducive to the promotion of this technology, especially in China, and designing and verifying user-owned IP cores requires a high level of skill from designers. Nowadays, a complete embedded system runs a real-time operating system; for SoPC to become mainstream, it needs richer RTOS support.