Tiny, inexpensive, open source FPGA boards with MachXO2 and iCE40 FPGAs

[lukevalenty]

Hello All!

I would like to share my latest projects with this community.  Ever since I discovered Paul Stofgren's Teensy boards I have been infatuated with teeny tiny microcontroller boards.  A couple years ago that infatuation intersected with FPGAs when I found the similarly sized TIF board.  Unfortunately it has been difficult to get these boards as they are now special order and only in large batches. 

So I set out to design my own FPGA boards that are tiny, low cost, and open source.  In the end I've developed two different boards.  A bare-bones A-series with MachXO2 FPGAs and a more featured B-series with iCE40 FPGAs.

For a quick overview check out the website: tinyfpga.com.

TinyFPGA A-Series open source files:  https://github.com/tinyfpga/TinyFPGA-A-Series

TinyFPGA A-Series Hackaday Project page (in case you want to make your own): https://hackaday.io/project/25958-tinyfpga-a-series

TinyFPGA B-Series open source files: https://github.com/tinyfpga/TinyFPGA-B-Series

Ohh yeah... the A-Series is bare-bones, it's programmed via JTAG.  A little inconvenient but it really helps lower the cost enough to make them easy to leave in a project.  The B-Series on the other hand supports programming over USB.  In order to keep the costs low I implemented a USB device in the FPGA itself to act like a boot loader.  When the board is powered on the bootloader waits a moment to see if it's attached to a USB host.  If it is, it will wait for a user design to be downloaded.  Once the user design is downloaded to a seperate section of the SPI configuration memory the board reconfigures itself with the user design.

If the board is powered on and is not connected to a USB host it will automatically time out and boot into the user design.

I haven't yet designed a dedicated USB-JTAG programmer for the A-Series but I am currently thinking of using a PIC16F1455 and programming it with a simple bit-bang FW.  Then I can add A-Series support to the python programmer application I already have.  Any JTAG protocol bugs will be fixable in the python code and won't require users to reflash their programmer hardware.  That PIC is cheap and doesn't require a crystal for USB.  Should help me make a cheaper JTAG programmer than even the lattice imitation programmers for sale on ebay.

I would love to get some feedback of the designs.  The PCBs are designed in KiCAD. the B-Series bootloader is written in verilog.  The programmer software for the B-Series is a python application. 

I have a batch of B-Series boards in production, but I have a few hundred A-Series boards already finished, tested, and ready to ship if anyone is interested.  I have a store on Tindie if you want to buy one: https://www.tindie.com/stores/tinyfpga/

As for the B-Series boards...I have a few prototypes I made by hand.  They were difficult to assemble by hand due to the 0.4mm pitch BGA package of the FPGA.  However, if anyone is interested in some serious testing and evaluation of a B-Series prototype board I may be willing to send a couple out.  When I get the production boards back I may send out more or create a discount code for them.

If you do wish to buy an A-Series board, the first 20 people to use the EEVBLOGROCKS discount code before August 4 will get 20% off their order.

[Someone]

Nice bootloader implementation

[David Hess]

Those look cool.

Are all of the supply voltage details handled on the module so that only a single external supply voltage is needed?  How are the different I/O voltages supported?

The edge speed on the I/O pins must be pretty good to support the performance of the FPGAs.  Are there enough ground or supply pins to prevent excessive bounce?  I only see one supply and one ground.

[lukevalenty]

Thanks for taking the time to look at my projects and providing feedback/questions, I really appreciate it.

For the A-Series boards with the MachXO2 FPGAs they use 3.3v for both core and all IO banks.  Lattice has an application note for decoupling capacitors on their FPGAs that I attempted to follow the best I can.  The boards themselves only have one 3v3 supply pin and one GND pin, but all of the supply pins of the FPGA package are decoupled and the ground pins of the FPGA package are connected to the ground plane on the bottom layer.  I used 100nf and 10nf decoupling caps with relatively thick traces connected to each supply pin.  The 4 0603 parts at the top of the board are in this order: 10uf, 1uf, 100nf decoupling capacitors, and one ferrite bead in series.  I think this power distribution network should take care of the power needs of the FPGA.

All the connections on the board for IO are through a standard 2.54mm pitch through-hole header for use in a breadboard, socket, or parent PCB.  I figured extra work put into impedance matching differential pairs would pretty much be ruined by those connections.  Maybe in a next revision I can clean up the differential pairs just in case.

All this said, I have had no issues with running the JTAG interface at 30MHz with logic analyzer probes connected and about 10 inch long wires on the JTAG programmer all connected to the board through a breadboard.  That's not quite high speed IO, but it's the most I have tried so far.  I'll see if I can't figure out a way to try higher speeds with the gear I have.

Also, the numbers on the board are the pin numbers of the TinyFPGA board itself, not the pin names of the FPGA package.  The template projects in the GitHub repository provide an empty top level verilog module that represents the board with all its pin names matching along with a constraint file to connect those ports to the correct IOs on the FPGA.

I'll cover the B-Series boards in another reply...gotta take care of my little one in the mean time. 

[David Hess]

The boards themselves only have one 3v3 supply pin and one GND pin, but all of the supply pins of the FPGA package are decoupled and the ground pins of the FPGA package are connected to the ground plane on the bottom layer.

One supply and one ground pin may be a problem.  See below.

All this said, I have had no issues with running the JTAG interface at 30MHz with logic analyzer probes connected and about 10 inch long wires on the JTAG programmer all connected to the board through a breadboard.  That's not quite high speed IO, but it's the most I have tried so far.  I'll see if I can't figure out a way to try higher speeds with the gear I have.

The JTAG interface has its own ground connection.

The problem is not so much the frequency of operation as the rise and fall time needed to support the highest possible I/O pin toggle frequency.  Even 1 Hz can be a problem if the signal edge has enough bounce to cross the logic threshold twice.  For example this was a problem with 74AC logic chips where the ground and power pins were at the corners of the package.

You might not have any problems but the lack of ground pins would worry me.

[lukevalenty]

The problem is not so much the frequency of operation as the rise and fall time needed to support the highest possible I/O pin toggle frequency.  Even 1 Hz can be a problem if the signal edge has enough bounce to cross the logic threshold twice.  For example this was a problem with 74AC logic chips where the ground and power pins were at the corners of the package.

Gotcha.  I remember seeing some bounce when I had my digital scope connected but it didn't seem too bad.  I'll take a closer look tonight and post some data.  I only have a "400MHz" USB scope.  We'll see if that does the trick.  Any particular type of test you would like to see: what frequencies, multiple pins toggling, attached load resistance/impedance/capacitance?  If anyone has a good scope for characterizing rise/fall times and bounce I would gladly ship a board in exchange for that data on the various IO pins.

[David Hess]

Gotcha.  I remember seeing some bounce when I had my digital scope connected but it didn't seem too bad.  I'll take a closer look tonight and post some data.  I only have a "400MHz" USB scope.  We'll see if that does the trick.  Any particular type of test you would like to see: what frequencies, multiple pins toggling, attached load resistance/impedance/capacitance?  If anyone has a good scope for characterizing rise/fall times and bounce I would gladly ship a board in exchange for that data on the various IO pins.

Worst case will be I/O pins furthest from the ground and power pins.  (1) Multiple I/O pins toggling or driving heavy loads make things worse.  Where this really matters is any I/O pin used as a clock and any I/O signal edges which are closely aligned with the setup and hold times of the clock.

Notice that the MachXO2 parts themselves have either 8 or more grounds or the exposed die pad also serves as a ground.  Lattice did not use potential I/O pins as grounds without reason and they are not there for carrying extra current; the same parts only have 2 power pins.

Measurement can be tricky because of the probe grounding and load.  This is one of those measurements where an active differential probe would be considered.  Since I have never had one to use, I have gotten by with careful design which exceeds the signal integrity requirements.  When I was really paranoid, I placed a ground or bypassed power connection adjacent to every I/O signal.  Some of that paranoia was for EMC and EMI compliance though; it was just easier to prevent these kinds of problems than track them down and fix them later.

A 400 MHz oscilloscope might not be fast enough in this case to see some problems but it is a good start.  A 100 MHz oscilloscope would be useless.

(1) This statement is a little deceptive.  I/O pins close to the power and ground pins can provide more drive through their lower parasitic inductance and that can *pull* the ground pin further away from true ground causing other signals to be corrupted.

[lukevalenty]

A 400 MHz oscilloscope might not be fast enough in this case to see some problems but it is a good start.  A 100 MHz oscilloscope would be useless.

It's even worse.  Turns out it's 100MHz sample rate with 50MHz analog bandwidth...It's the DSCope from DreamSourceLab.  Useless for this purpose.

In desperation I turned to my logic analyzer.  I can feed an external clock into it.  Or so I thought...it only takes an external clock up to 50MHz.  Also useless.

Finally...I switched the logic analyzer to 400MHz/4ch mode and cajoled a 199.5 MHz clock out of the internal oscillator + PLL in the FPGA.  With this hack I was able to get a clean digital waveform ~400ns at a time, at which point the 400MHz of the logic analyzer and the 199.5 MHz of the FPGA would be too far out of alignment and I'd get some noise.

So what did I learn?  I learned that I need a better scope
 

[David Hess]

You could do a functional test.  I suspect there are better ones than the one I describe below but it gives the general idea.

Configure all but two if the I/O pins and any clock input as outputs and attach something like a 22pF load to each of them.  Toggle them all using the clock or maybe toggle them from a linear feedback shift register for random outputs.  Configure the last two I/O pins so the output pin replicates the input pin.  Apply a variable DC voltage to the input pin.

Now you can adjust the input voltage to determine the bounds of logic high and logic low by monitoring the output pin.  Somewhere the datasheet says what the limits should be.  Excessive ground bounce will degrade the noise immunity of the input and be seen as output pin state changes.  In extreme cases, the output will change no matter what the input is.

The input and output pins could be fed into an exclusive-or gate and then the gate's output monitored with an oscilloscope to see when they differ and for how long.