[x]



JOE: do a search and replace for all “[x]” in this document. Replace it with the appropriate section number.

[x]. Input/Output Controller Module

Introduction:

The Input/Output Controller (IOC) is responsible for bridging the gap between the various peripherals to be used in the vehicle application and the Control Code Processor (CCP). The CCP is designed to be capable of communicating with a wide variety of peripherals, logging sensor information, and making data available to the CCP for use in the Simulink-generated control program. Using a separate, FPGA-implemented I/O controller offloads I/O processing from the CCP and offers parallelization of the I/O control process, thus improving control and I/O throughput. Physical and functional modularization also allows the IOC to be disconnected from, or operated independently of the P10236 CCP. This means that the IOC can operate as a standalone data logger, or be connected to and operate with a future version of the CCP.

Hardware:

The IOC is to be implemented using a Xilinx Spartan3E FPGA as the backbone for peripheral control. The Spartan3E family of FPGAs is chosen because of its relative ease of implementation and competitive price. The XCS500E-PQ208 offers the highest pin count and highest logic size without the requirement of a Ball Grid Array (BGA) package. Use of a BGA package is avoided due to routing difficulties and the inherent requirement of a circuit board with more than 4 copper layers.

Figure [x].1 shows an overview of the IOC hardware and electrical connections. The FPGA is provided two system clocks for internal use. The 50 MHz clock is provided for the internal real time clock as well as all processor control. A second 14.7456 MHz clock is provided for convenient conversion to a wide range of common serial transmission baud rates. The remaining hardware subsystems are described in further detail in the following sections.

[pic]

Figure [x].1: Overview of IOC Hardware

Digital IO

The digital IO ports on the IOP are organized in groups of 8 signals similarly to typical microcontroller IO banks. Two of these groupings are dedicated solely to reading and generating Pulse Width Modulated (PWM) signals for servo actuator control. It is beneficial to be able to read PWM inputs from sources like a hobby radio because a user may want to record manual control inputs, or implement a control mixer in software.

The remaining groupings of digital IO are general-purpose bi-directional banks. Each signal is fed through a TXB0108. This IC is capable of translating the 3.3v FPGA bank levels to a custom logic level (up to 5v) defined by the user. Each bank can be separately configured to operate at a different voltage standard. In addition, the bidirectional voltage translator ICs do not require direction information for the IO signals since they are capable of automatically detecting the direction of the signal drive.

For the MAV set of peripherals to be used, only one general purpose bidirectional bank is required. A target of 5 digital IO banks (not including PWM) is planned (if the FPGA has logical space) for the final implementation of the IOC, which will allow for future implementation in larger systems.

Analog Inputs

The IOP is designed to accept up to 8 simultaneously sampled analog inputs. A 16-bit, 8-channel ADC (ADS1178) is used for this purpose. Since the ADC is capable if accepting differential analog signals, each analog input consists of + and – inputs. As shown in Figure [x].1, the ADC is shown side by side with an 8 bit DAC. This is provided to generate a programmable full-scale voltage reference for the ADC, allowing the user to define the operating range of the analog channels and use the full 16-bit digital span for each signal and maximize digital accuracy of the conversion.

All analog inputs are grouped into a separate analog connector to the IO breakout board. This connection is to be physically separated from the digital signals in order to avoid analog signal corruption.

SD/MMC Card

Along with the multiple IO peripherals provided, the IOP includes a socket for a standard SD card. Communication to the SD card is done using a standard MMC mode over the SPI protocol. The SD card’s primary function is to provide non-volatile removable storage for data and event logging purposes. Since the SPI FLASH module is only used during boot time, the SD card is chained on the same SPI bus, saving FPGA pins for more useful purposes.

Rigidware:

Figure [x].2 shows a detailed overview of the rigidware within the FPGA. (P10236 defines “rigidware” as the logic configuration of the FPGA. This definition will be used for the remainder of the project.) At the center of the diagram is the “Plasma core”. The Plasma core is an open source HDL implementation of a MIPS-I 32-bit processor. This core is chosen because it is open source and can be manipulated to suit the needs of the IOP. Compared to other free controller cores, it provides good documentation and provides an easy to use tool chain for compiling program code.

Outside of the CPU are several peripherals that are mapped to the Plasma core’s address space. This includes approximately 40kB of block RAM that resides within the FPGA as well as 1kB of dual port RAM. The dual port RAM provides the CCP unrestricted access to part of the IOP’s address space without interrupting the IOP’s operation.

The remaining peripherals are discussed in further detail in the following sections.

[pic]

Figure [x].2: FPGA Logic Overview

Dedicated Peripheral Controllers:

Part of the IOP’s peripheral set includes dedicated peripheral controllers: the ADC and PWM Controllers. The ADC controller is responsible solely for communicating with the analog hardware outside of the FPGA. This includes configuring the DAC voltage reference and acquiring channel data from the ADC. The resulting conversion values are stored in registers in the address space. This allows the CPU firmware to access analog signals without consuming time in software to control communication.

The PWM input and output controllers work similarly to the analog controller. For PWM outputs, all that is necessary to move the connected servo is to write an 8-bit value is a register in the PWM Generator. The PWM reader is responsible for calculating the duty cycle of the input and placing that result in an 8-bit register in the address space. This configuration allows PWM control to be performed without the need for firmware intervention.

Configurable IO Ports:

The remaining peripherals in Figure [x].2 are multiple instances of configurable IO ports. Each IO port is responsible for controlling eight (8) bi-directional signals for multipurpose use. Each of the 8 signals can either be configured to be a general-purpose input, output, or to perform a special function. Special functions include the ability to communicate using SPI protocol, I2C protocol or asynchronous serial protocol (UART). When configured as a special function, that signal becomes connected to the respective communications controller. Figure [x].3 illustrates the operation of each configurable I/O port. Each port can be configured by writing to its respective control register in the address space.

[pic]

Figure [x].3: Detail of Configurable IO Port

Programming Interface

In order to configure the IOC, several steps need to be taken to load the FPGA with its rigidware and the Plasma core with its firmware. The FPGA rigidware is programmed by connecting a JTAG programmer to a header on the IOP bard and uploading a bit-stream to configure the FPGA. Instead of directly configuring the FPGA with the bit stream, the rigidware is saved in an external configuration IC. This allows for the previous bit-stream to be downloaded to the FPGA during every power up. The rigidware includes partially initialized RAM, to which a small boot loader is programmed to load the firmware for the IOC. Because the rigidware configuration and boot loader will not need to change, re-synthesis of the FPGA rigidware is unnecessary for the end-user.

The boot loader is executed at each power up of the FPGA, and is responsible for initializing the rest of the RAM with the current application’s I/O control code. During normal operation, this code is stored on an onboard SPI FLASH IC shown in Figure [x].1. At power up, the boot loader checks the FLASH for an available program and loads it into memory. The boot loader is also capable of reprogramming the FLASH with new program code. This program code is sent to the IOC via the USB interface. A dual USB to UART converter IC is provided on the IOC board to enable easy programming. [The second UART channel on the USB converter IC is routed straight to the CCP for configuration of that device. The dual UART IC eliminates the need for the user to switch physical plugs during configuration of the two devices.]

CCP Interface

In order to take full advantage of using separate I/O control and control code processing systems, a shared dual-port memory block is used. This allows the IOP and CCP to access the same memory space simultaneously, providing a data link between the two systems. In order to facilitate communication between the CCP and IOC, a high speed serial bus similar to SPI will be used where the CCP is the master device. Using this interface, the CCP can request a read or write to specific addresses in the shared RAM. As suggested in Figure [x].1, extra pins and signals are reserved for the future possibility of changing this interface to a higher speed parallel EDMA bus. Due to availability constraints in part selection for the CCP, implementation of the EDMA bus is not currently practical.

Analysis:

Logic Cost Estimation

Table [x].1 shows an itemized breakdown of major components within the IOC rigidware. Using this information, it is possible to conclude that implementing up to 5 configurable IO ports is reasonable for the logic constraints of the FPGA selected. The remaining logic (~20%) is left unused in order to facilitate uncertainties in estimations.

|Plasma Core | | | | |

|Total |2-Stage CPU |Fixed UART |Misc. | |

|3306 |2705 |101 |500 | |

| | | | | |

|High Speed Serial Controller | | | |

|Total | | | | |

|300 | | | | |

| | | | | |

|PWM IO Controller | | | | |

|Total | | | | |

|300 | | | | |

| | | | | |

|Analog Controller | | | | |

|Total |SPI |Control Logic | | |

|230 |130 |100 | | |

| | | | | |

|Configurable IO Port | | | |

|Total |SPI |I2C |UART |Port Config. Logic |

|710 |130 |230 |150 |200 |

| | | | | |

|Number of IO Ports: |5 | | | |

|Total LUTs Used: |7686 (82.5%) | | | |

|Available LUTs |9312 | | | |

|Remaining LUTs |1626 | | | |

Table [x].1: Logic Cost Estimates for Rigidware Subsystems

Throughput Estimation

In order to have confidence in the feasibility of the IOP controller, a basic sampling throughput experiment is conducted using the standard MAV peripheral set as a model. Using information about the protocols used to communicate to the peripherals, a simple dummy program is written that emulates a sampling iteration.

Since the PWM and analog inputs are designed to place resulting values in the memory space, a simple move instruction for each parameter is required. Similarly for PWM outputs, a memory-memory move instruction is performed for each channel. For the IMU, each parameter is read from the device by writing a command word and reading the resulting word. Since the SPI protocol of the IMU can operate at up to 2MHz and each parameter can be passed in 32 clock cycles, the time that the CPU must wait can also be computed. It is determined that each sampling iteration can be performed in approximately 140 clock cycles at 25 MHz. Since the actual control program is likely to have more complex flow control instructions, the value of 140 cycles is tripled as a safety margin. Combining these values results in a theoretical maximum sampling rate of approximately 30 kHz, which is well over the target of 2 kHz.

It is possible that the sampling speed can be improved further since the actual implementation will use interrupts to control peripherals, allowing more efficient multitasking.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download