In my last post I pushed a ‘Hello World’ configuration to the FPGA through the JTAG port. Since then, I’ve been working on the Altera Fast Passive Parallel configuration ports. The intention is use the microcontroller to manage the register transfer logic (RTL) configuration of the FPGA. Essentially this means the Altera SAM microcontroller can load a ‘personality’ for the dongle. Personalities will be stored in the Flash memory, loaded as required and pushed to the FPGA.

I wrote very simple data transfer program to ensure a correct transfer from the PC to the microcontroller.In the first step, I’m not storing it in the flash, but programming it directly from the USB. This saves the flash wear while I’m rapidly prototyping. The protocol is fairly simple across the COM port:

1. Send STX (character 02)
2. Send size of packet (1-256)
3. Send the packet data (up to 256 characters)
4. Send a CRC32
5. Send ETX (character 03)

The dongle then sends back an ACK/NAK byte (character 06/21).

If NAK is sent, then the packet is resent, otherwise it moves onto the next packet. The other key part of the protocol is that all the data sent are readable characters, because sending binary data can be tricky, especially sending character 0. The data is base64 encoded before it’s placed into the packet, so 256 payload bytes are about 192 bytes of data.

I wrote the client side to run under Cygwin, so that connection to the COM port is as easy as referring to /dev/ttySx. Here’s the finished upload screen and the connection to the COM port to see the result in putty:

This pushes the data in the RBF file through to the FPP data port on the FPGA. I struggled to get the FPP working initially and no matter what I sent or how I sent it, the FPGA refused to release the CONF_DONE line and remained unconfigured. I was using the same image created for the HelloWorld RTL in my last post, so I knew the file should work. I was trying to use an uncompressed image, thinking this was the simplest. It was odd that the uncompressed file image was 20 bytes short according to the Altera documentation. I wonder if there was some issue with uncompressed files. No matter what I tried, I couldn’t get this file to work. Reversing the bit order, changing the programming settings in Quartus, additional DCLK’s while nCONFIG was low and none of it worked. To understand what I’m talking about, you’ll probably need to read chapter 7 of the Cyclone V Device Handbook and the Cyclone V Device Datasheet.

I tried the compressed image and tried again and it worked fine. Compressing the image requires two DCLKs per data byte, but this was straight forward to do, the data lines don’t need to change, just DCLK needs to go low-high-low-high-low before moving to the next byte.

After the last byte was loaded I toggle two mode DCLKs as per the specification and the device started up. The configuration is set up to use the internal oscillator for configuration start-up, so I don’t need to toggle the DLK once the program is loaded.

It took 60 seconds to upload 765121 bytes for a production build, but 2:30 for an unoptimized development build. As this image gets bigger, it will take longer to upload, so I may need to look at alternative upload arrangements. The speed is not limited by the serial bit rate in the windows device settings as I first thought and is entirely dependent upon the speed of the receiving application. So as I optimised the application, I saw faster speeds. The speed is simply send to the device using the serial control channel, for the device to process. The speed of USB doesn’t change remaining at 12MHz and neither the Atmel software framework, nor Windows enforces this speed. Sending maximum size packets (64 bytes) will increase the performance of this transfer process up to an equivalent of 512Kbps (64 bytes per packet x 1000 times per second x 8 bits per byte). This will be a much more complex transfer mechanism though, so I’ll come back to that later as the RTL image gets bigger.

I’ve uploaded the source code to GitHub if you want to see how it’s done. Using compressed images really is as simple as the data sheet shows, but if you want to see sample source code for your own project, take a look here.

Now that I can upload an image using the supervisor chip, I no longer need the delicate JTAG connection, although I’ll hang onto this in the short term until I’ve improved the performance of the upload.

So now, I have a reliable mechanism to upload an image to the FPGA so the next step is to develop the controller software to:

1. Manage the Flash and the MRAM, including a flash translation layer.
2. Manage the uploading of FPGA images to both the Flash and to the FPGA directly.
3. Manage requests through the SPI port from the FPGA for Flash data (likely to be a later phase).
4. Manage a debug communication channel through to the FPGA.

More to come.