Low-cost, open-source FPGA boards in a tiny form factor with built-in USB, SPI flash, LDO, and MEMS clock.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
I received the TinyFPGA BX pre-production boards a few days ago and have been putting them through their paces. It's all good news so far. I found and fixed a few bugs in the tester firmware and updated the bootloader to use the controllable pull-up resistor and indicator LED.
I broke out all the boards from the panel and tested each one. Every single one passed. All 42 FPGA IOs, 16MHz clock, voltage regulators, and SPI flash are functional on all 20 boards. This means that the TinyFPGA BX project is GO!
This success is a big deal. If you've been following me on Twitter (@tinyfpga) or the logs on this project you know that the BX prototypes are testing a non-standard BGA footprint for the teeny tiny iCE40 FPGA. This footprint allows me to fan-out twice as many user IOs from the FPGA, but it does not follow the recommended guidelines for BGA packages. Getting 20 boards successfully manufactured and assembled gives me confidence that a full production run will have acceptable yield.
I have some plans to clean up the bootloader some more. There are a few bugs that I would like to fix as well as some features to make the "program, test, program, ..." flow more fluid for the user.
If you are interested in buying a TinyFPGA BX stay tuned, I will be launching a campaign on Crowd Supply in the coming weeks.
I had a very exciting few days as I received some TinyFPGA BX prototype boards from oshpark. I didn't really think I'd be able to assemble these first prototypes. I had expected that it would be too difficult to reliably reflow the FPGA onto the new footprint. I also wasn't sure that the boards would be high-enough quality since I was pushing the design to the very limits of what oshpark can do.
So I scrounged up my USB microscope and took a look at the PCBs just for fun.
Ohh my glob. They are perfect. Each one of the 6 prototypes I received from oshpark are absolutely immaculate. This was the first time I ordered 4-layer boards from oshpark and I am impressed. The soldermask pull-back is just 0.05mm. That's just 50 microns. The circular pads are 200 microns in diameter and the pill-shaped pads are about 330 by 100 microns. I realized these boards were good enough to try out.
I had a bad experience using solder-paste and a stencil when I assembled the original B2 prototypes. It was very difficult to get a clean print and then it was difficult to get a reliable reflow. This time I decided to use nothing but flux and a hot-air gun. The flux goes on footprint spread thin, then the BGA package, then the hot air. It took about 30 seconds to reflow. The first board I reflowed using this method was sacrificed for science.
I wasn't sure how well the balls would reflow onto the footprint so I hacked away at the assembled board to get a good shot of the balls.
Looking at the balls we can see one solder ball on the left edge and two on the right edge that are on circular pads. The rest of the balls are on pill-shaped pads pointed towards the camera. You can clearly see the difference in shape. The balls seem to be reflowing onto the pill-shaped pads very well.
I tried sanding and cutting into the BGA package itself to try and get a cross-section of some balls. This didn't work out too well as debris was pushed underneath the package and the solder balls may have been pushed around.
Talking about this on Twitter, there were a few suggestions from the community on better ways to analyze BGA package reflow issues. Without an x-ray, the best option seems to be dying the area under the package and letting it set before pulling the package off vertically. If there is dye covering any pad then you know you have an open.
My next step was to assemble some boards by hand.
I started out by reflowing the FPGAs onto three boards. Without cutting into the board I was still able to spy some very promising connections on all four sides.
This was getting very exciting. I believed this footprint would be very risky, but each board was turning out better than expected. I was interested in testing the basic functionality of the FPGA and the connections to all of IO pins. Testing this basic level of functionality meant that I could pick and chose the critical set of support components necessary to breathe life into the chip. This ends up being the two voltage regulators, their capacitors, some bulk capacitance, resistor for PLL VCC, and the SPI flash. Since I would be assembling these few boards by hand this would save me a lot of time.
I also decided that the first order board I had to bring-up would require a lot of debugging. So I soldered on a full set of BX pins so I could put it into a special breadboard designed for the BX boards.
The breadboard has all of the IOs routed out to their own rows. I soldered on some headers that my logic analyzer and lattice programming cables could attach to. This provided a nice platform for first bring-up.
Here's a close-up of the voltage regulators:
The mini "testbench" with the programmer and logic analyzer connected. The blue wire is soldered onto a test-point used to hold the FPGA in reset. This...
Read more »I've posted details about a new retro-computer project board using the TinyFPGA B2. Check it out on the Hackaday.io project page: https://hackaday.io/project/29526-tinyfpga-computer-project-board
The TinyFPGA BX prototype boards are currently being manufactured. The PCBs have been fabricated and are now waiting for assembly. I should get them back in a couple weeks. At that point I'll be checking them out and developing the pogo-pin tester firmware.
I've been working on a new revision to the B2 board. I am running low on my B2 board stock and need to manufacture more boards. I've been making some big changes that I think will be very welcome improvements on the B2:
I'm very happy with these changes and have ordered 20 assembled prototypes. I'll be posting updates as the boards come back and are tested. I may sell a limited number of prototypes ahead of a bigger manufacturing run.
Sounds great, so what's the caveat? Well...the B-series TinyFPGA boards have always used an unconventional BGA fan-out. The iCE40 parts they use have a tiny 0.4mm ball pitch and this makes them very difficult to use without moving to a very expensive PCB process. This is not a problem for their target market of mobile devices, but does present some challenges for hobby FPGA boards.
The new BX boards are able to fan-out significantly more signals due to a change in how the outer pads are shaped on the board. They've been elongated into a pill shape to allow for some inner signals to be routed out. This is not standard and there is a risk that it won't work out.
I believe there are enough regularly shaped pads to align the BGA balls properly over the pill-shaped pads along the perimeter. This self-alignment along with solder paste on the pads will ensure good contact. The pill-shaped pads have the same surface area as the regular pads, but have a longer perimeter. I believe this will increase the surface tension slightly and may pull the package very slightly closer to the PCB. This should be OK since the layout of the elongated pads is very symmetrical. The BGA package should still be pulled down evenly and should retain the self-alignment properties of a regular BGA footprint.
This is partly why I ordered 20 prototype boards fully assembled from my PCBA manufacturer. I should be able to get an idea of the yield based on this small run. I'm feeling pretty good about the chances and am very excited for the prototypes to be delivered. Stay tuned!
I've documented the bootloader protocol a bit more in the GitHub repo: https://github.com/tinyfpga/TinyFPGA-B-Series/blob/master/bootloader/README.md
If you want to integrate the TinyFPGA B-series into a development platform, you can ideally use the tinyfpgab.py programmer script instead of writing your own. However, there are some cases where it's just not practical or user-friendly to do so. In those cases this README should help along with the reference implementation that tinyfpgab.py provides.
I have pushed an update to the TinyFPGA B-Series GitHub repository with a template for the open source icestormFPGA synthesis flow. Take a look at the new README for detailed instructions.
I've also added support for programming TinyFPGA B-series bitstreams using a command-line interface. Take a look at the READ for instructions on using the command line interface.
I've finally gone over the schematics of all my projects and organized them a little bit so they are nice and easy to follow. For people that don't have KiCad installed, making the schematics available in PDF form is much more convenient and easy to share for quick reference.
You can view the PDF directly on GitHub: https://github.com/tinyfpga/TinyFPGA-B-Series/blob/master/board/TinyFPGA-B.pdf, or you can take a look at the image included below.
I've also started a new Hackaday.io project, #The Hobbyist's Guide to FPGAs. I'll be posting articles, tutorials, and hands on labs using the TinyFPGA boards as project logs. If this sounds interesting to you then follow the project to be updated when new content is posted.
Quantity price tiers have now been added for the TinyFPGA B2 on the Tindie store. For larger orders or resale please contact me directly at luke@tinyfpga.com.
I've updated the getting started guide to include installation of @Paul Stoffregen's Virtual Serial Driver Installer if you use a version of Windows older than Windows 10. If you ordered a TinyFPGA B2 board and are planning on using an older version of Windows, you will need to install the driver in order to program the board.
Windows 10 has a brand new USB serial port driver that works for all CDC class USB devices (USB serial ports). Older versions of windows don't do this because some devices aren't exactly compliant to the CDC class driver and needed special workarounds. The new Windows 10 USB serial driver gets around this by relaxing its standards a bit and letting devices misbehave a little bit. This allows them to default to using the universal driver. Paul's installer installs an INF file that tells windows that any CDC class USB device that doesn't already have a driver specific to its VID and PID can use the generic USB serial port driver.
Paul went through all the work to make this installer and get it signed. Not only does it work for his Teensy boards, it also works for everyone else that makes a generic USB serial device with a different USB VID and PID. Thanks Paul!
Create an account to leave a comment. Already have an account? Log In.
This project seems to have gone dark. I ordered FPGA boards six months ago and I am still waiting for them to arrive. I haven't heard a peep from the supplier or gotten a response to my emails asking for an update. Not encouraging that there are no further updates here, either, or that the European supplier has stopped listing the boards.
I know this is 2 years old... I'm hoping this is seen. How is the bootloader initially loaded? Is that burned into the ROM of the FPGA or are the SPI chips pre-programmed?
do you have a part number for the SMD headers on the bottom of the board?
Awesome project!
I can fit a quad-core 12 MHz forth machine in the B2, and I think I will :)
Cool project !
For C-Series can you put a risc-V and a SD card ?
https://hackaday.com/2017/09/18/a-smaller-cheaper-risc-v-board/
;)
Hey Simon, thanks! I saw the LoFive project and I really like it. I don't think i'll be making a dedicated RISC-V board, but I will be making an inexpensive project board that the TinyFPGA boards can plug into. That project board will have an SD card slot among other things. There is also a project that implements a RISC-V CPU on an iCE40 FPGA similar to the one in the TinyFPGA B2.
If I make a C-Series board it will be a larger FPGA. Right now I'm working on the #TinyFPGA Programmer to support the #TinyFPGA A-Series boards. In fact, I just finished assembling and reflowing 75 programmers. Should be on sale this week!
I was able to fit a picorv32 on the B2 board: https://github.com/cliffordwolf/picorv32
Silly question...(remember this is all new to me)
So, say I want to define a bus, say "inout [8:0] data;"
How is that bus associated to real physical pins? In TinyFPGA_B.v the names "pin4" etc. seem to be already configured in template.edf. So, I'm guessing that this bit of code:
(net pin4 (joined (portRef pin4)
))
is what does the magic of associating a name to a pin?
So then how does one configure a set of pins as a bus?
The edf file you're looking at is generated by the synthesis tool. The actual pin constraint file is https://github.com/tinyfpga/TinyFPGA-A-Series/blob/master/template_a2/template_a2.lpf
In Verilog you can concatenate multiple signals together and treat them like any other vector.
This is a good example for almost exactly what you want to do: https://stackoverflow.com/questions/11111861/direction-of-verilog-concatenation
I'm using a B series board and don't see a similar file in that template. The only thing I see 'sort' of like that is: https://github.com/tinyfpga/TinyFPGA-B-Series/blob/master/template/constraints/pins.pcf .
Thanks for the link :)
I just found the pin constraints editor. Is that where one would set such things?
One thing that might be handy for newbies is some advice for interfacing with 5V (TTL or CMOS) logic. In my case after learning more about FPGA programming I want to try and interface with some retro hardware which uses 74LS series logic.
After doing some research it seems the drive mode of the FPGA pins can be set to TTLLV and the 3.3V 'HI' signaling level should be OK to drive a TTL input directly. For an input on the FPGA one would need to use a series resistor (if the FPGA has built in clamping diodes that are up to the task) or a series diode to get the needed voltage drop. These are cheaper/simpler than a level shifter IC but add more signals delay as you are creating a RC filter of sorts.
Does the above sound correct?
Driving the TTL logic with 3.3 volts should be fine.
However I don't believe using a series resistor on the input will protect the FPGA from 5v input. Instead I recommend using a voltage divider. It requires 2 resistors and will bring the voltage down to 3.3 volts.
Here's a related stack exchange post that has some good details on what can happen if you use a single resistor: https://electronics.stackexchange.com/questions/106849/using-single-resistor-to-receive-5v-signal-on-the-3-3v-rated-pin
Sparkfun has a decent tutorial on the basics of voltage dividers: https://learn.sparkfun.com/tutorials/voltage-dividers. It will tell you the basic idea of a voltage divider and how it works, but it won't help you size the resistors. For that, take a look at the following stack exchange post: https://electronics.stackexchange.com/questions/231616/can-i-use-a-voltage-divider-for-shifing-logic-levels
Good luck with your project and don't forget to post it on hackaday.io!
You can also use open collector gates (e.g. LS06/LS07) as buffer to FPGA with a pull up to I/O rail (e.g. 3.3V, 2.5V etc) as level conversion. The pull up values can around 4.7K (or lower if you want more speeds). This offers a bit more speed than plain resistor dividers.
There are also shifters series chips, 74LVC series 5V tolerant part etc which offer more speed.
TTL VIH high is around 2.0V minimum, so they can be driven even as low as 2.5V I/O from FPGA.
Thanks for all the ideas. My project does not require very fast operation. Recently I found an magazine article from 1990 which had led me back then into making an internal 256K RAM expansion for a C64. I decided to make this again and have laid out the PCB and purchased the 74LS series ICs for the memory controller board.
It also seemed it would be a good time to try and learn something about FPGAs and thus re-implement the memory controller on the FPGA. It is rather simple for an FPGA I think, just 6 ICs and only combinatorial logic. But it should be fun.
On a side note I noticed that if pins 14-17 are grounded the device won't reset into the boot loader mode. I just happened to choose these pins as inputs as they were closest to the DIP switch I plopped onto the breadboard. I assume this is because of the SPI functionality of these pins?
Hey Allen! I'm currently working on getting the #TinyFPGA Programmer out the door. Once I'm happy with the firmware and the production PCB design (which is almost done), then I have a special project using a TinyFPGA B2 board.
The #TinyFPGA A-Series project page has been up for several weeks and has had a few articles written about it, I think that's why it's busier. I'm sure the B-Series won't be quiet forever ;)
Become a member to follow this project and never miss any updates
They seem to be doing a new batch of boards, I have ordered with delivery ?May 2024. Will post again when it arrives.