Let the FPGA experiments begin - Part 1

Tinkerings with FPGAs

Shortly before finishing the "Z80 Minisystem" I read about FPGAs and for the moment I thought that these devices are "the most awesome thing you ever see in your life". So of course I wanted to do a project with them. Again I was inspired by phil from retroleum as I instantly became a fan of his work.

So how do you start? I was so crazy I didn't even thought about buying a evaluation kit! I've discovered that you can get a simple FPGA like the XC3S50 (Spartan-3) from Xilinx inside a QFP144 package. I never etched a printed circuit board before as I always worked with strip boards. Also I didn't wanted to start etching. So a solution for this has to be found...

And I went simply nuts as I got myself some solder adapters from Elk-Tronic to solder the FPGA onto it. After that, some really dirty work started as I took this naked adapter board and connected it with a lot of wires to a strip board having the power supply (3.3v,2.5v,1.2v) and a little bit of sram.

Now we are talking about tinkering (25.2.2009)

It's like a chip with pink tentacles attacking the stripboard (25.2.2009)

The programming over the "Slave Serial"-mode of the spartan-3 was done using a simple parallel cable and a self written Linux driver. The protocol is a very simple serial clocked one that can be implemented rather fast. But the transfer rate was slow because of the bit-banging. So I created a serial variant using a PIC.

But as you might know a FPGA loses it's configuration without the power supply. Normally you would buy some xilinx platform flashes to save the configuration. But I had a better idea. I got myself some XC3S50AN (Spartan-3AN) FPGAs which do offer an internal SPI flash that can be used for configuration.

So fragile... :'-(

Luckily I got a reason for desoldering the FPGA for a new one as at this point my workplace started being possessed by an evil demon that causes my Spartans to be killed....

Naah of course not! Sooner or later you will discover that FPGAs are rather fragile components. They break very easily. Let me list some reasons:

• unstable power supply
• the core voltage is 0.05v to high
• mistakes inside the datasheet 
• floating inputs
• the weather is cloudy
• it's friday
• because they want to

As it turned out the power regulator (LM117) that was in use for generating the 1.2v core voltage delivered 1.25 volts. This was too much for this little thing and it just died .... :'-( .... I burned just 15€.
So I removed it with a hot air gun and soldered a new one. As I didn't knew the fault was inside the power supply I just continued using it and ... after a few days I got the dead FPGA number 2 ....
The fact that this was causing it was clouded by the fact the FPGA can run with 1.26 at maximum. But it seems the regulator was just to unstable for this purpose. So i got myself some expensive ones that gave exactly 1.19v.

So I continued working on it and guess what. A copper wire broke of and this was an input on the FPGA. As the driver was missing a got an antenna and you know what this means..... floating inputs lead to higher current inside the chip and the next FPGA was destroyed. Just by open inputs. At this time I got really depressed for losing all my money on this stuff.... but I of course bought another one. (At this point I wasn't aware of the feature that you can enable internal pull-ups)

In midtime I switched from the XC3S50 to the XC3S50AN with integrated flash. These also don't need the 2.5v supply anymore which is great. What I didn't knew is that the I/O has changed in matter of clamping diodes. As you might know the Spartan-3 is a 3.3v only device. When interfacing 5v you need to levelshift. If you have a device with clamping diodes on it's input you can apply a 5v signal with a resistor in series. The voltage that is too much will overflow into the 3.3v supply and just disappears (talking simple). These clamping diodes are removed at Spartan-3A and Spartan-3AN devices which is not told explicitly inside the datasheet. So.... I burned about two devices until I read about it.

My working place became some sort of graveyard for spartan devices. I was sure that the Spartans from the movie 300 were a lot more resistant.

Back to work

After telling you about all the dying Spartans in my room lets continue on our journey.

Before buying all this stuff I experimented a little bit with the webpack edition of Xilinx ISE (version 10.x at this time if I remember....). But of course for development you need a language.

Choosing a language

At this time we hadn't any courses in university about "hardware description languages" so I was not biased.

If you look around there are two important languages: Verilog and VHDL. At this time I only knew that Verilog is more used in America and VHDL in Europe. I looked at both languages and tried to decide. I don't want to start a flamewar here as this is a well and emotionally discussed topic in forums.
But for myself I decided that Verilog is the better language as the Description of behaviour seemed to take a lot less code lines and the code itself was not very blown up. If you look at VHDL you have to write a lot of code to accomplish your task.

So I went for Verilog and studied it. Today I do believe that this choice maybe was a mistake as I live in Europe in which VHDL is the preferred language. It may be more difficult to get a job If i tell my hypothetical boss that I learnt Verilog in university :-D. But this is just a wild guess. The truth is these languages are very similar. If you understand Verilog you can read VHDL with ease most of the time. It's like reading C++ with Java knowledge.

At this point I will make a break as some of the last posts are just to big to be readable.