Design of Satellite Signal Simulator Based on DSP Embedded PCI Bus

0 Introduction

Satellite signal simulators play an important role in the research and development of satellite navigation, especially in the research and development of multi-mode receivers and high-dynamic receivers. Multi-mode satellite simulators involve a large amount of data transmission. In order to ensure the real-time and accuracy of data transmission between PC and DSP, data transmission is based on the PCI bus interface. The commonly used PCI development uses a dedicated PCI interface chip, but this will add one more chip to the system, which is low in cost performance. TI's TMS320C6416 series DSP has a built-in PCI interface, which reduces the difficulty of hardware development and makes the host's access to DSP resources more transparent. A hardware platform for a PCI bus satellite signal generator based on the TMS320C6416 series DSP and the corresponding PCI interface circuit design are proposed.

1 System structure and implementation plan

1.1 System overall diagram

Figure 1 is the overall structure of the simulator, and its core components include DSP6416, SDRRAM, FLASH, FPGA, D/A, clock and PC. Among them, D/A completes the conversion of digital signal to analog signal; SDRAM is used as an external memory to store data sent by PC; FLASH is used to save the running program of DSP after the system power is off; FP-GA is another core component of the simulator, which mainly completes the communication with DSP, signal synthesis and D/A control; PC mainly completes the digital signal processing of the simulator and the transmission of calculated data between PCI interface and DSP. As a communication bridge between the host and FPGA, DSP mainly completes two tasks: one is to regularly receive various control words and telegrams calculated by the PC, and send the control words of each channel to the FPGA according to the timing requirements; the second is that since the PC calculation is double-precision floating point, and the FPGA can only calculate with integer data, this will inevitably cause a difference in the phase accumulation value of the two. As time goes by, the error will become larger and larger and must be corrected; but if the data accumulated by the FPGA is to be returned to the PC for comparison and correction, the real-time performance cannot be guaranteed, so it is necessary to implement the correction of the frequency word in the DSP.

In the design, SDRAM is used as the off-chip memory of DSP and configured in the CE0 space of EMIFA. FPGA and DSP exchange data through the EMI-FA interface, which is configured in the CE1 and CE2 spaces of EMIFA. CE1 of EMIFB is configured to communicate with FLASH in asynchronous 8-bit communication mode.

1.2 DSP and PCI interface circuit connection design

Since the DSP TMS320C6416 has an internal integrated PCI interface, there is no need for a bridge chip. It is only necessary to design the interface with the PCI motherboard, and there is no need to design the interface between the PCI and the DSP itself. Since the emulator is a multi-power system that can provide 5 V, 3.3 V, and 12 V power supplies, the connector is powered by multiple power supplies. In addition, since the DSP is a 3.3 V system, although its PCI port can withstand 5 V voltage, considering the stability of the system, three voltage conversion chips IDTQS32X2245 are added between the DSP's PCI port and the connector to convert the 5 V voltage into 3.3 V voltage. Since DSP is an integrated PCI interface, its circuit design is relatively simple. The address and data bus of DSP PCI interface are directly connected to the B pin of IDTQS32X2245 chip, and the address and data bus on copper finger are connected to the A pin of IDTQS32X2245 chip. The arbitration signal REQ, GNT, error report signal PERR, SERR, byte enable signal C/BE[3:0], interface control signal FRAM, IRDY, STOP, IDSEL, DEVESEL are also connected to the corresponding position in the same way. Due to space limitations, only the connection diagram of DSP PCI interface and connector is given here, as shown in Figure 2.

2 DSP6416 embedded PCI key registers and its interrupt mechanism

The PCI interface of DSP6416 supports connecting DSP to PCI host through master/slave bus interface. The PCI interface is connected to DSP through EDMA internal hardware. It supports four types of PCI data exchange: slave mode read, that is, external PCI master device writes data to DSP through PCI interface; slave mode write, that is, external PCI master device reads data from device through PCI interface; master mode read, that is, DSP master device reads data to external PCI slave device through PCI interface; master mode write, that is, DSP master device writes data to external PCI slave device through PCI interface.

There are three main types of PCI registers: PCI configuration registers, PCI I/O registers, and PCI registers mapped in the DSP memory space as peripherals. The first two types of registers can only be accessed by external hosts, while the third type of registers can be accessed by both the DSP and the external PCI host.

The PCI configuration register contains standard PCI configuration information (device identification, manufacturer identification, classification code, base address, etc.); PCI I/O registers are located in the I/O space of the PCI host. The host can only access them in: Base1 and Base2. The PCI I/O registers include HSR, HDCR, and DSPP. As shown in Figure 3, the HSR register indicates the status of the host. Its INTSRC bit and INTAM bit are crucial for interrupt processing. When the INTAM bit is 1, it can mask the interrupt sent by the DSP. When the bit is 0, only. When the DSP sets the INTREQ bit in the RSTSRC field, PINTA can be enabled, that is, the host can respond to interrupts at this time. When the INTSRC bit is read as 0, it means that PINTA has been invalid since the last clear. When it is read as 1, it means that PINTA is in the enabled state. Writing 0 to this bit is invalid, and writing 1 clears the enabled state of PINTA. For HDCR, the PC generates a host interrupt by setting the DSPINT bit to 1. DSPP mainly defines a storage space together with Base0.

The PCI memory-mapped peripheral registers are mainly used to control the PCI interface, which can be accessed by the host and DSP. Among these registers, the most important one is the RSTSRC register, as shown in Figure 4.

DSP generates interrupt by setting INTREQ in RSTSRC register to 1; PC and DSP clear interrupt by setting INTRST to 1. This is very important in driver development because the interrupt generated by DSP is a level interrupt type. If the interrupt is not cleared, it will remain valid. This will cause the interrupt response function to be called continuously, resulting in a crash.

The PCI port has full access to the DSP's memory map through three base address registers.

Base0: 4 MB of pre-accessible space. All DSP memory spaces are mapped by setting the DSP page registers. Pre-fetch reads make all bytes valid.

Base1: 8 MB non-prefetch address map corresponds to all DSP memory spaces, non-prefetch support byte enable.

Base2: PCI's 16MB I/O includes I/O registers.

These three registers belong to the PCI configuration registers. The PCI host can access the 4 MB DSP memory mapped in the PCI memory space. The PCI port contains a PCI I/O register (DSPP register) mapping from PCI address to DSP address. This mapping mode is used when the DSP is a PCI local bus slave; when the PCI base address register on the DSP is configured as an 8 MB non-prefetchable area, the memory space is mapped to the DSP memory mapping register (0180 0000h). Bits 22:0 of ​​the PCI address are connected to a fixed offset to map the Base 1 access to the memory register; the Base Address Register 2 configures the 16 BI/O space so that the PCI host can access the PCI I/O registers.

3 Development of emulator program and driver

3.1 Selection of drive tools

There are three commonly used development tools for developing WDM PCI drivers. One is to use Windows DDK or WDK tools directly; the second is to use DriverStudio; the third is to use WinDriver. The first method requires knowledge of Windows architecture, device driver architecture, etc., and the development difficulty is relatively high; the second method encapsulates DDK, and although the difficulty is reduced, it is still not small, and due to the encapsulation problem, some bugs may be introduced, which may lead to project failure; the third method overcomes the shortcomings of traditional development tools, such as long driver development cycle, low efficiency, and the need for DDK and kernel program development experience, which greatly simplifies the development process of hardware device drivers such as ISA-BUS and PCIBUS. WinDriver also provides a kernel plug-in function, which allows developers to debug code in user mode and then move the debugged code to kernel mode. Therefore, using WinDriver is simple, fast, and efficient.

3.2 Working Principle of WinDriver

Figure 5 is the architecture diagram of WinDriver, and the shaded part is the components provided by WinDriver. WinDriver provides a driver stack layer with WinDrvr6.sys as the bottom layer, which directly interacts with the hardware, avoiding the complexity of hardware operation for users. To develop drivers, users only need to call WinDriver user mode API functions in the application. These user mode functions call WinDriver Kernel Module functions to access the hardware. For some hardware drivers with higher requirements (such as requiring the interrupt response speed to be fast enough), if the driver developed in user mode cannot meet the requirements, the developer can put the debugged code in user mode into WinDriver Kernel Plugin module, so that the driver development can be carried out in user mode, and the efficiency of the developed driver is completely comparable to that of the driver in kernel mode.

Figure 6 shows the API function calling relationship within the PCI driver developed using WinDriver.

Normally, these API functions are not called directly in an application. Instead, through secondary development, these API functions are encapsulated in a dynamic link library DLL, and then the application calls the encapsulated functions in the DLL.

3.3 Satellite signal simulator application program block diagram and key code analysis of the corresponding PCI driver

According to the overall design of the simulator, two functional modules need to be implemented on the PC;

Digital signal processing module is the core module of the simulator, which simulates navigation messages in real time, calculates satellite pseudorange, frequency words and code control words of each channel, etc.

[page]

Communication module: This module mainly transmits the relevant information calculated by the PC to the DSP through PCI.

Considering the real-time nature of the data required by the entire simulator, the interrupt function is used to implement data transmission in the PC program. When the DSP needs data, an interrupt signal is generated by writing 1 to the INTREQ bit of the RSTSRC register and sent to the PC. However, to make the interrupt effective, the INTAM bit in the host status register (HSR) must be 0. Therefore, in the host program, the interrupt enable bit must be turned on during the initialization phase. The structure of the application is shown in Figure 7.

The interrupt processing steps are as follows:

(1) The application turns on the interrupt enable and the system waits for the interrupt;

(2) If an interrupt occurs, clear the interrupt flag and cancel the interrupt source;

(3) Execute data transfer in the interrupt function;

(4) After the data transmission is completed, an interrupt is sent to the DSP to implement the handshake with the DSP;

(5) Re-enable the interrupt source.

Steps (2) and (5) are implemented in the interrupt enable function.

The key codes of the interrupt response function are as follows:

The PCI host sends an interrupt to the DSP by setting the DSPINT bit of the HDCR register to 1. It should be noted that the effective prerequisite for generating this interrupt is that the HOSTSW bit of the PCI interrupt enable register (PCIIEN) is enabled, that is, HOSTSW=1.

In order to facilitate the use of PCI driver functions and the need for future driver release, the driver functions are encapsulated in the dynamic link library DLL. The key codes of their main functions are as follows:

In order to enable the PC to correctly capture the interrupt sent by the DSP, the interrupt transfer command in kernel mode must be set in the dynamically linked DSP6416_IntEnable() function, because its priority is higher than the interrupt response function in user mode. Therefore, once the DSP generates an interrupt, the interrupt transfer command in kernel mode is executed first. Since the interrupt generated by the embedded PCI of DSP6416 is a level-sensitive interrupt, it will remain valid if the interrupt is not cleared, which will cause the interrupt response function to execute continuously and crash. Therefore, the interrupt transfer command must be set in the interrupt enable function. In this example, a DWORD is first read from HSR, and then the CMD_MASK bit is set in the interrupt transfer command. If the value read from HSR is 0x04, the interrupt generated by the DSP is masked, otherwise the mask command is not executed, and then 0x10 is written to the RSTSRC of the DSP in the interrupt transfer command to clear the interrupt. The two functions of disabling interrupt enable and closing device used in Figure 6 can be implemented by calling WDC_IntDisable(), WDC_PciDe_viceClose(), WDC_DriverClose() functions in WinDriver. In addition, before calling these functions, it is necessary to determine whether the interrupt exists and whether the device is turned on, otherwise serious errors will occur.

3.4 Satellite signal simulator experimental verification

Set up the satellite signal simulator scenario: the user location is 60°00'00"N, 100°00'00"E, 300 m altitude, and stationary. The solution result of the GG24 receiver is shown in Figure 8.

The result of the GG24 receiver solution is 59°59'59.867 52"N, 99°59'57.636 24"E, and 308.02 m in elevation, which is quite consistent with the set scenario, i.e. 60°00'00"N, 100°00'00"E, and 300 m in elevation. Therefore, this shows the correctness and effectiveness of the simulator.

4 Conclusion

The data transmission hardware platform and driver development solution based on the embedded PCI of DSP6416 designed here have been used in the multi-mode satellite signal simulator. The data transmission of this solution is stable and fast (up to 115 MB/s). The WinDriver software toolkit is used to develop the embedded PCI device driver of DSP6416, which can not only greatly shorten the development cycle, but also improve the development efficiency and overall performance of the satellite signal simulator.