FPGA GPIO

When I have some spare time, I am still playing with my FPGA board, meanwhile I went through some on line training graciously offered by Altera and also some documents they make available on the web.

Wow, there is A LOT of valuable information available there, thanks Altera!

Fact is that FPGAs are incredibly flexible devices and with flexibility often you get complexity.

To be fair Quartus II partially helps out in dealing with such complexity, provided you are used to the complexity of an Eclipse interface at least!
That said, I must admit it is easy to get lost in the rich menus of the IDE, so I decided to investigate deeper one thing at a time.

A good starting point seemed to be the I/O section.

When, in Verilog, you define a module such as

module pong(clk, vga_h_sync, vga_v_sync, vga_R, vga_G, vga_B, quadA, quadB);
input clk;
output vga_h_sync, vga_v_sync, vga_R, vga_G, vga_B;
input quadA, quadB;

you can place it in the schematic design and verify that it has certain inputs and outputs (as defined in your module declaration)

Those inputs and outputs could be connected to other modules in your design, or they could be routed to connect to the external world (like in my example).
In the latter case, you need to attach them to input or output pins.

Once that is done, you still need to tell Quartus to which physical pins they (the input/output signals you defined) have to be connected on your device.

Turns out this is quite an easy task, in fact once you run the Processing-> Start-> Start Alaysis & Elaboration process, these signals become visible for the Pin Planner tool

The Pin Planner is one of the MANY tools/wizards you will have to deal with in Quartus II, it will allow you to perform two important functions :
1) You can assign your signals (nodes) to specific pins, this is quite straightforward, you have the list of nodes on the left and select the " Location " being the pin you would like to connect.
2) You specify the electrical configuration for your pin (actually for your I/O bank)

The I/O banks are similar to the GPIO ports in microcontrollers.
Typically in an MCU a GPIO port has 8 pins, an FPGA I/O Bank typically has more than that and the device I am using has 8 banks.
Now, one incredibly interesting thing is that FPGAs allow you to configure a bank with different Voltages (might vary depending on the device you are using) allowing you to interface external devices operating at different voltages!

However your settings must be homogeneous within the I/O bank, so you cannot have one pin at 2.5V and another one at 1.8V in the same bank, Quartus would complain about that.
To check your settings are consistent you can run the Processing -> Start - Start I/O assignment Analysis process.

Also the current strength can be configured in the same way :

You would imagine that's the place where you can also set an internal pull-up resistor for your inputs... but nope (according to the docs I found), that's  in the Assignment Editor

...where you can set a ton of parameters, for most of which I have no clue at all, cannot even imagine what they are for.
You can specify more than one parameter for the same Node, however some combinations of parameters are not valid, i.e. you cannot enable a weak pullup and define the pin as differential input (yup, also that!) at the same time.

So, long story short, I/O signals in an FPGA can be way more flexible than those on a MCU, you could probably use an FPGA as an extremely expensive logic level translator!

Experimenting with the FPGA - Configuration Device

Hello again, did not have much time to play with the fpga board, but enough to discover a few things that I thought I may share with you, should you run in the same issues.

First of all, I bought a cheap DEV board, that does not come with any kind of manual (not even a link to download it form the web), but I guess if you need a manual then you should leave these boards alone.

It features a Cyclone IV E, a cheap 622C8N, what else do you need to know, after all? :)

Ok, I tried/studied/experimented with a funny pong game that outputs to a VGA monitor.

I did not connect it to the monitor yet, did not have time to solder a connector, but managed to probe the HSync and VSync signals with my DSO and they are as expected.

So I have been experimenting a bit with little verilog modules in Quartus II etc.
A funny thing I noticed is that each time I power cycled the board (or pressed the reset button), it would revert to the test program that was loaded when I received the board.

It is a bit weird if you come from the MCU world, but if you think it does make sense : FPGAs store their configuration in RAM, meaning that each time you reset them, they are completely blank, you need to pump in the configuration from a serial eeprom.

So, I figured out that each time I was writing the configuration to the RAM and not the eeprom itself, maybe there was some kind of option in the USB Blaster programmer...
Nope, not there, so I started checking the board schematics to see if I could locate the configuration device (the serial eeprom).

Sure enough I found a device in the JTAG section of the schematics that looked like a serial configuration storage, labeled EPCS4S18, which really looks like an Altera code related to Cyclone devices... a quick search on the web confirmed my first impressions.

Now, the interesting part is that my board comes with two programming sockets, with the same 10 pin JTAG standard connector , but only one is labeled JTAG, the other one, as visible in the schematics is labeled "AS".
Even more interesting is that the AS is connected to the EPCS4 device.

So, I figured that if the two ports had the same connector -probably- it was enough to connect the USB blaster on the AS one.
I left the quartus programmer on the JTAG option and obviously it gave me error, fair enough.
So I checked which other options were available and found an "Active Serial Programming" which kind of makes sense having a connector labeled AS, no?

Unfortunately as soon as I switched to Active Serial, a warning popped out telling me that I had no devices listed in the programming window that supported such mode.
The only device I had in my list was the Cyclone IV... but wait, I was actually trying to program the eeprom this time, not the fpga!
Clicked on "add device" (after accepting the Active Serial option which removed the FPGA device from the window) and there I found my beloved EPCS4!!
Now, I just needed to point to the binary file to be loaded... doh! The open file dialog filters for a different binary format called POF (instead of the common SOF used to program directly the FPGA chip).

Some more googling led me to this document which explains that serial configuration devices use Active Serial (which is supported by USB Blaster) to be programmed and they need this POF thing that is actually generated in Quartus II (File -> Convert Programming Files).

The process is quite straightforward :

1) Select your configuration device  (EPCS4 in my case)
2) Click add File
3) Select the SOF file generated by the compiler
4) Click "Generate"

Then, in the programmer tool :

Make sure you connected your usb blaster to the AS port (if you have  a board similar to mine), add the EPCS4 device, tag the program/configure option and finally "start".
The process is way slower than configuring the RAM, but it worked for me, and after resetting the board, the newly created configuration was active.

My first FPGA test - It worked!

I received today my cyclone IV basic dev board and I immediately tested the "my first FPGA" tutorial available on the Altera website.

You can find it here and it can be a very good way to test your new board and/or your software setup.

I followed the step by step process and I must say I understood most of it (still a few grey areas about timing constraints... need to review them a bit and check some literature maybe).

I had to cross reference the schematics of my board to identify the pins, took me a while -ehm, like 2 or 3 minutes actually- to identify the correct pin for the oscillator signal (it was not displayed on the main chip in the schematics).
Lol, I just noticed that on the board itself you can read "Clk=Pin25" and it is even printed in a quite visible font :)
As a general suggestion, if you buy a generic cheap board like I did, make sure you can find and download the schematics, you will definitely need them for the pin mapping!!

Anyhow, it all sounded pretty new to me, so I was quite sure there were about zero chances to see the binary counter running at the first shot.

Turns out I was wrong (oh, I really love to be wrong this way!! :) ).

100% completed, green is nice, but what actually was shocking was the view of the binary magic on the leds installed on the board (yeah, we geeks can spend hours watching a binary led clock).

I know, this post was not that informative, just wanted to share that I am happy that my FPGA "hello world" worked.
That's  the beauty of technology after all (for those who love it), it can surprise you every single day and you can count on the fact that tomorrow you may start playing with something new you don't know anything about.
Ain't it amazing?

An LED bus
blinks its four bits,
the MSB goes off, it starts again.
All in all  happiness 
is something little  (that blinks)


Originally Trilussa (a poet from Rome) wrote :

A bee settled
on a rose petal.
It sipped, and off it flew.
All in all happiness
is something little

My first FPGA is on its way

I couldn't resist.
I am already busy with many other things (but my laser is now sat up in a lab some 100s Km from me now, to be used to run some tests), but it's  quite some time I am curious about FPGAs.
Every now and them I found myself thinking : "I should get myself an FPGA DEV board and start playing with it", then I would normally try to stick my fingers in my ears and say out loud : "lalalalalalala!".
It actually worked for a while, till a few days ago when I bought a Cyclone IV dev board.

Argh, I knew it would have happened sooner or later, I wonder if there is some kind of therapy for us geeks, to keep our urges of technology under control.

Funny enough this is one of the times where I do not have an application in mind that might justify the acquisition of the mentioned technology... it is simply curiosity at its finest.

I started reading about FPGA, downloaded the free software from the Altera website while my board is traveling from mighty China to the Swiss mountains where I play with cheese, lasers and bits.

So, if you know already a bit FPGAs, then you will not find a lot of valuable information here : I am just discovering (still you are welcome to post your comments, they might help me out in my discovery process).
On the other hand, if you are like myself, maybe a bit skilled with MCUs etc, but never played with FPGAs, then this article might actually spare you a bit of googling around and help you decide if you want to give them a try or not.

Field Programmable Gate Arrays are "a different animal" if you are coming from microprocessors or MCUs.
These devices don't come with any specific functionality.
Sounds weird, right?
I mean, when you buy an MCU, you select it for the number of bits it has, the clock frequency, internal peripherals such as serial ports, ADCs, timers etc,
None of that is available in an FPGA.

So, what do you get?
You should expect a high number of pins that can be configured as inputs or outputs, cool, but honestly not really enough.
Then you can connect those pins internally with sequences of logic gates (remember the old 74xx TTL stuff? Those, but smaller and with no need of wires or pcb traces to connect them!).

I know it does not seem much, but it turns out to be a big deal in the end.
Now, imagine you have several thousands of those Logic Elements (LE), which to be fair are a bit more flexible that the old 74xx gates.
You know that a microprocessor is just a bunch of those properly connected, right?
Technically these LEs are arranged in an Array and an internal RAM stores how they should be configured and how they should be interconnected.
Did I say RAM?
Yeah, I did, and that does mean that every time you turn off an FPGA it goes back to be a bunch of non configured and non connected LEs just the same way it was shipped out of the production line.

This means you need an external EEPROM or similar device to store the configuration that allows the functionality you planned for your project and, when the FPGA chip is powered up, this configuration data is sent with a serial protocol.

In the end, programming an FPGA simply means storing the configuration data into the non volatile memory that will feed the device at power on.

With that clarified, how do we create a complex logic (i.e. a microprocessor) using just basic gates?
I am sure there are out there skilled professional that could design a CoreI7 with a bunch of 74xx chips, and actually that would be one way (not the easiest) to go.
In fact you can design the schematics and place all your lovely AND, NAND, XOR etc in it, place the wires, connect stuff to pins and probably invent the next gen CPU with that.

I surely hope this is not the only or easiest way to go... apparently my hopes are not placed in vain.

It is possible to "describe" the hardware using a Hardware Description Language such as Verilog or VHDL.
If you are reading this post, chances are you are familiar on how source code normally looks like, so you could see the example below (VHDL snippet) and still feel you are in your comfort zone.

Ok, cool, we have code blocks with begin / end (Pascal anyone?), we have IFs.. meh, looks like source code.
What's  special there?
I guess many things, but the one that shocked me at first is that instructions are not necessarily executed in a  sequence.

Let me give you an example :
Imagine you are using an MCU, reacting to an Interrupt, you received a command over the UART and now you want to turn on an LED on pin P1.1, check the value  of pin P2.1 and if this is equal to 1 then turn on a fan connected to pin P1.2.

So you would get something like this :
..
gpio_P1_1 = 1;
if (gpio_P2_1==1) gpio_P1_2 = 1;

Technically this gets compiled and a series of instructions are executed sequentially, if we use the debugger we can clearly see thew first line being executed and the LED turning on, then the second one and eventually the fan turning on.
What happened in our MCU is that the same hardware (registers, whatever) meaning the same transistors in the chip where used to execute the two lines and when they were busy taking care of line 1, line 2 was waiting.

In an FPGA you do not (necessarily) create a sequence of instructions, so the same task would be accomplished by describing what should happen when the command is received.
The two lines would be executed simultaneously because they would actually be implemented by separate transistors in the chip.
Those transistors would have one single job : to deal with that specific instruction, anytime needed and regardless of any kind of clock.
A block of gates, interconnected to absolve some dedicated function is then considered a sort of black box with inputs and outputs that allow it to interact in a bigger design,

Basic and complex blocks are available in libraries, which also contain a free microprocessor (called NIOS II) that can be implemented in your design, you can even run a Linux Kernel on it (yup, with a bunch of 74xx style toys, not bad eh?).

To embed some specific and existing designs you may need to pay licenses (Intellectual Property) to the creator, at this time I am not aware of that ecosystem, so it might very well be that you can find free stuff for most of the needs or not.

Normally FPGA devices include also some memory blocks (RAM) and PLL circuitry to create clock signals you may need for the logic you implement.

But then if an FPGA is in general an empty canvas, why are there so many models?

There are different manufactures (not many actually) each one of them offering different families of devices.
Every family has some peculiarity : power consumption, input output configuration (some have high speed transducers),  maximum speed achievable, eventual internal HW CPU (typically a cortex A9 or similar) embedded etc.

Then , within a family there are plenty of models which have two main variables :
Number of LEs and Speed Grade.

Why number of LEs is important?
My dev board is equipped with a small Cyclone IV (Cyclone IV is the family), I am saying small because it has only about 6200 LEs, while the big devices might have 350.000 of them (115.000 max currently in the Cyclone IV family).
The more complex your design is, the more logic it needs which translates in a higher number of LEs required.
I think I found somewhere that, depending which configuration you need, a NIOS II processor would require from about 600 LEs.
[more info here]
Now, if you consider that my small device has 6200 of them, you can put things into scale.

The second parameter is the speed grade, I imagine that would greatly affect the maximum clock frequency you could use in your internal logic (i.e. in the NIOS II processor).

There are then some other details such as number of PLL circuits, number of internally available memory blocks etc.

The beauty of this is that, say you start your design with a small device and then it gets more complex over time, you just need to switch to a device that has more LEs (might impact your pcb tho, as number of pins might also change).

In conclusion, I cannot say I learnt a lot so far, but the few things I saw are making me more and more curious and eager to start experimenting.

I found the Altera website quite good to find resources, there is a training section which has plenty of good (and free) online training resources.

I cannot endorse one brand or another, looks like for beginners the two most obvious options are Altera and Xilinx, and I decided I'd  give Altera a go first as there are plenty of cheap and simple DEV boards on the market, lot's of literature etc.
I think that even porting from a brand to another might be quite easy, since by itself an FPGA does not provide any specific functionality, you just need enough room for your design, silicon that reacts fast enough and eventually amenities such as RAM and PLLs.

This article is already quite long, so I am cutting it here and I am not describing how the LEs work (which is quite fascinating), how they use the LUT etc.
While I might expand that in a future post, if you are curious, you can find   a lot of info here

Update : I just received the board, you can see it here (top board) compared with the Stellaris Launchpad (bottom one).
The USB Blaster manages the JTAG interface, tiny device actually and you need to install the driver found in the Quartus software distribution (also in the free one) as explained here

Should you be interested, you can find some boards here :