Still on a high from my last success, I moved onto testing the FPGA. The only way this would work at the moment, is through the JTAG port. The software that will eventually configure the FPGA through the fast passive parallel port is not ready, and there’s a lot to learn first, so I’m going to leap frog that and use the JTAG port to configure the FPGA to get the LED to blink.

Just like this :

Soldering very fine wiring to the JTAG TDO/TDI/TMS/TCK pads was pretty tricky, so I first tested the process on one of the other two boards manufactured by OSH Park. My solder reel is pretty old and the flux core generally hasn’t worked too well in the past, so I used some solder paste blobbed on the pad and pushed the wire into the blob while heating with my iron. This melted the solder paste and the abundant flux in the paste ensured the solder and wire stuck together.

I then used the same technique to solder the wire to two 5 pin connectors to plug into the Altera USB Blaster. With my mistake on the bottom of the board not providing +3.3v then I had to take both ground and +3.3v from the Atmel ICE extra 0.1″ connector, seen top left of the image above. A mere 6 pins gets me access to every pin on the FPGA to either test or drive to logic levels. If you don’t know what JTAG is, have a look at the write up on FPGA4FUN. It also has great information on FPGAs.

The wire and solder connections are extremely delicate, but only need to survive until I’ve validated that all of the configuration pins are connected between the Atmel SAM4 chip and the Altera FPGA. Once, I’ve confirmed this connection I’ll move back to writing the software to manage the programming of the FPGA.

However, today’s task was to get blinky to work. I wrote a simple Verilog program to toggle the LED port, noted as GPIO1 on the schematic:

module blinky(output LED);
 wire clkout;
 reg [25:0] cntr;

 osc o(1'b1, clkout); 
 assign LED = cntr[25];
 
 always @(posedge clkout) cntr = cntr + 1'b1;
 
endmodule

A few notes on the program above. “osc” is the Altera internal configuration oscillator that provides approximately 50MHz – 100MHz clock to the module. The 26 bit counter can count up up to about 65 million, so this should cycle the LED from on to off at about 65/100 of a second. However the internal oscillator is extremely dependent upon temperature and voltage, so can vary widely. The data sheet says is can run as low as 60MHz or up to 100MHz. From the video you can see it’s probably on the lower end because it’s blinking at about 1Hz.

I connected the USB Blaster and configured it for upload of the generated SOF file, then my heart in my mouth, I clicked the “detect” button in the JTAG chain. It immediately detected the chip! Success again! I clicked on the start button to upload the bitstream to the FPGA and you can see the result in the video above.

I just want to pause here and describe the incredible sense of satisfaction in creating something that I’ve read about for years, but this is the first practical implementation of that learning. Knowing that I’d interpreted the data sheets correctly, correctly selected the right regulators, smoothing inductors and ripple capacitors, wiring these to the correct lines at the correct voltages to make the chip start up, was incredibly satisfying and made the previous failure fade away. My wife thought I’d gone crazy as I leaped around the room. Theory is one thing, but actually building something and have it fire up for the first time is almost indescribable.

So now, I knew the main parts of the FPGA were working. I still have some reservations and did some follow up research, that I probably should have done before I put this together.

The blue LED is extremely bright when it’s in the ON state. This led me to worry about the current it’s drawing through the FPGA output driver. I read the spec sheet of the LED and it says at 5mA, 2.85v is dropped by the LED. Using ohms law I calculated the internal resistance to be 570 ohms (R = 2.85 / 0.005). The relationship between voltage and current isn’t linear, but I’ll use this as a starting point. So at 3.3v, it would draw 5.8mA (I = 3.3v / 570). Way to high for the FPGA output drivers, who limit the current to 4mA for TTL and 2mA for CMOS at 3.3 volts. I anticipated this and included a resistor, but unfortunately probably too low a value. I used 100 ohm resistor, making the total resistance 670 ohms for a current of 4.9mA. To keep it to the 2-4 mA that the FPGA prefers, I probably should have used between 1080 ohm and 255 ohm. Now, this probably won’t be a problem for a single gate as the other output drivers are ‘cold’ and can dissipate the heat generated from a single driver. My preference is to use 4mA and set the pin to be a LVTTL pin, to keep the intensity of the LED. I’ll replace the resistor at some point with a 300 ohm part. In the meantime, I’ll use PWM to reduce the total power through the gate, while keeping the brightness as high as possible.

This got me thinking about overall power of the FPGA an I remembered that Altera provides an early power estimator spreadsheet to calculate thermal power and current on each of the power supply lines. Just for fun, I completed this spreadsheet to see what I could expect the current to be when it’s fully up and running and hosting logic.

I put in the worst case scenario, 100% logic usage, memory usage, IO usage, at maximum speed of 400MHz with no thermal solution, such as heatsink on the chip.

To my horror the report page of the spreadsheet showed the 1.1v line drawing over 500mA. The 1.1v regulator is limited to 300mA! This is always a risk as an appparently stable system running with little logic fails when it’s started to be loaded with content, with random crashes and resets. I used a more realistic profile where most of the cores run at 48MHz, with just the video and SDRAM running at 166Mhz (about 40% of total resources). This brought the 1.1v line down to about 200-250mA, so within spec.

In addition, the worst case scenario can generate temperatures of about 20C at full operation and added to the ambient temperate makes this chip run at 40C – 50C. That’s pretty warm for the device and will affect reliability. Adding a heatsink will help, but so too will reducing the speed of the cores inside the FPGA.

At this point, I decided to call it a night, satisfied that at least I can be confident in moving to the next step. What I’ll cover next time is the process of toggling the lines between the SAM4 microcontroller and the FPGA and watching these signals on the JTAG debug port. Once I’ve seen these lines toggle correctly and without shorts, I’ll work on the software that lives in the SAM4 “supervisor” chip that will upload a raw binary image (RBF file) to the fast parallel port (FPP).

The next step may be tricky, as I need to get a number of technologies to work together, such as the USB port to receive the file, the flash memory chip to store the RBF image and the inter-IC connections to the FPP port. I had some preliminary success just getting the Flash memory to store some data using the ASF, so it’s just pulling these together in a bootstrap harness.

Bootstrapping a completely new system is one of the hardest tasks to do as there are no existing tools to help, but I cannot rate highly enough Atmel’s ASF framework as it takes all of the hard work out of creating software to manage peripherals. With the basics out of the way, it’s just a matter of focusing on code that unique to this project.

Look out for my next update when I report the status of the inter-IC lines and hopefully have some success in storing an FPGA image in flash and uploading it using the FPP port.