Designing with core-based high-density FPGAs

Robert S. Grimes

July 27, 2011

Robert S. Grimes

Other custom peripherals
Other custom peripherals were needed to support system devices, both unique and common. As an example of the former, as I mentioned earlier, the system actually consists of four lasers that are combined to create the final output. In order to generate a coherent pulse, the four must emit their pulses (nearly) simultaneously.

Each laser is sent a "sync pulse" which is used to trigger its Q-switch, and thence, an output pulse; unfortunately, because of mechanical and material differences, the delay between the electrical sync pulse and the output laser pulse varies between the four channels.

To allow us to calibrate the four channels, I designed a custom IP, using the Xilinx EDK new peripheral wizard to connect it to the internal processor bus. This peripheral accepts an externally provided sync pulse, stretches it as required by the Q-switches, and delays each output pulse as necessary to time-align the output laser pulses. In this case, the peripheral was fully custom, though the wizard automated the connection to the processor.

We also had to create custom peripherals for some common devices. For an example, we used a number of Analog Devices' multichannel A/D converters (the 16-channel AD7490) for acquiring sensor data; these were interfaced to the FPGA via a serial peripheral interface (SPI) with multiple chip selects. The A/D converter represented a challenge not well met by the stock SPI controller provided by Xilinx, because it requires the chip select signal to be asserted for the 16-bit transfer for each channel read. The stock Xilinx SPI controller provided by the EDK v9.1i tools supported two modes of chip select operation, namely automatic (per-byte), or manual.

Unfortunately, the SPI controller only supported 8-bit word sizes, which forces the manual mode; this in turn would have required each channel to either be polled or an interrupt for each of 96 sensors (six 16-channel A/Ds were used). This was even more aggravating because the controller had a 16-word FIFO, which was so tempting; if it were 16-bits wide, a single interrupt could be used to read all 16 channels from a single A/D converter.

So, I decided to create a new SPI16 controller, based on the supplied version, and use it for the A/D. This was an example of starting with a supplied IP and customizing it for your purposes.

It should be noted that the SPI16 development was quite trivial, as the supplied SPI IP already had parameters for the width of an SPI word, but they were not exposed to the design environment, so they could not be changed. All I had to do was recode them to 16 bits, make a few other minor adjustments, rename the IP to a unique name, and I was done. Finally, I believe the newer versions of the Xilinx EDK tools provide more flexible SPI controllers, so I would not have had to develop my own.

Software design
The software to support the hardware design in meeting the system requirements consisted of a number of elements, as illustrated in Figure 3. There are two distinct boot-time programs (which I'll describe next), along with a real-time operating system (RTOS)—the Real-Time Executive for Multiprocessor Systems (RTEMS) and its board-support package (BSP). The application programs ("master" and "laser" for the respective processors) use the environment set up for them by MicroMonitor and RTEMS as a framework for implementing the required system functionality.


Click on image to enlarge.