Week2: PIC18 Schematic, SPI Bus and ICSP Header

After some more thought and discussion with my supervisor, it was decided that we should program the Spartan-6 FPGA using the Slave Serial method. This would be slightly easier to implement and is closer to the original design brief, which is to have a master PIC18 and slave Spartan-6 during configuration. However, given the considerable overlap between Slave Serial and SPI configuration pins, there is still some room for changes at a later date if necessary.

This week, my task was to create the preliminary schematic for the PIC18F67J60 we are using for Aeste’s development board. There is a lot of information to cover in this week’s report, but I will be focusing on a few key points: the Arduino form factor, shared devices, SPI bus and the ICSP header. Once again, skip to the bottom to see the summary.

Arduino Form Factor

From very early on in the conceptual phase, Aeste’s product was decided to have match the Arduino form factor for compatibility’s sake. Like the popular Arduino Uno dev board, the product will have constrained physical dimensions and will need to have at least 6 analogue and 14 digital I/O pins (6 of which have PWM function). Less like the Uno, there should be an additional ICSP header, a microSD slot, an ethernet (RJ45) socket and a micro-USB port on the board.

Clearly, accommodating everything on the palm-sized board would be a non-trivial exercise.

Shared Oscillator

Normally, only the device acting as the master would be generating clock signals on the board, but the PIC18 and Spartan-6 swap roles pre- and post-configuration. If possible, both devices should share the same crystal clock. Instead of using individual quartz crystals for both devices, a single external 25MHz crystal oscillator IC will be used to drive them, thereby conserving circuit-board space.

An initial idea was to “daisy-chain” the oscillator to the Spartan-6 and then to the PIC18. A simple clock design could be loaded onto the Spartan-6 initially (using the PIC’s 33kHz internal oscillator) and used to drive the main configuration process. However, this was deemed overly complicated and unfeasible since the Spartan-6 LX9 in use did not have any reconfiguration function.

Hence, the straightforward solution was to simply let a crystal oscillator chip drive both Spartan-6 & PIC18 simultaneously. The only difference before and after configuration is which device gets control over the on/off pin. The added bonus is that there will (hopefully) be less synchronization issues during operation.

Shared microSD

Likewise, the microSD card is controlled by the PIC18 and the Spartan-6 pre- and post-configuration respectively, which presents interesting problems when wiring the SPI bus.

As mentioned before, the PIC18 needs to read the 2.7Mbit file stored in the microSD card and send it to the Spartan-6 via a separate synchronous serial interface during configuration (see Fig. 1). Fortunately, the pins of the Spartan-6 at start-up are floating, so there is not much to worry about, and the problem with routing is less obvious.

Figure 1: During configuration.

In usual operations, it will be the (SPI master) Spartan-6 that is accessing the (slave) PIC18 and microSD as in a conventional “independent slave” SPI setup. It starts to become clear that the circuit is problematic since the DO & DI pins of the microSD are not wired to the MISO & MOSI pins respectively (see Fig. 2) as supposed. This setup is adequate for data transfer between the PIC18 and Spartan-6, since the DO & DI pins are left floating when CS is high. However, in order to access the microSD, the Spartan-6 has to take an additional step.

Figure 2: Data transfer between Spartan-6 (master) and PIC18.

One solution is to create a separate SPI bus between the PIC18 and microSD only for use during configuration, but the device only has one SPI module and that would again consume more valuable board space/ IO pins. A proposition from my supervisor is to “flip” the MOSI & MISO pins of the Spartan-6 (see Fig. 3). Swapping I/O pins cannot be done with any of the other devices, but for an FPGA it is quite easy to accomplish. Disabling SS (slave select) on the PIC18 will cause SDO to become a floating as well, so there is no issue of SDO and MOSI driving the DI pin of the microSD at the same time.

Figure 3: Data transfer between Spartan-6 and microSD. Note that MISO and MOSI have been swapped.

ICSP Header

The 6-pin ICSP header is not a crucial part of the product, but it can offer more programming options to experienced users. Although usually associated with the PIC, the header on the board will serve primarily as a unique JTAG connector to the Spartan-6, allowing readback & custom configuration. Nevertheless, according to initial design the user should also be able to use the same interface to program the PIC18.

This is challenging but not impossible with careful assignment of pin functions; the JTAG connection requires 4 pins but ICSP only needs 3, plus 2 voltage reference pins. The pinout table is as below:

Pin type (relative to device): P=Power, I=Input, O=Output

It is not possible to have separate chip select pins, but by separating the clock pins for each mode, it would be possible to program one device while leaving the other in a “frozen” state. The assignment of pins may yet change at a later date.

These blog posts are turning out to be tad longer than I plan! Regardless, the product has been designed to share most devices and on the board with a tricky SPI bus design and a dual-function ICSP header. The end result is the schematic shown in Figure 4, which shows Bank 2 of the Spartan-6 and the PIC18.

Figure 4: Schematic of PIC18 microcontroller and Bank 2 of Spartan-6 FPGA.

Once again, it must be stressed that this is a very early version of the schematics; expect more revisions as the project trundles forward. Next week, we will cover more details on the Spartan-6 schematics well as integration with the PIC18 in terms of I/O, power management and other modules.