Give Your RPi a Cool FPGA Hat

Need additional, custom IO for your Raspberry Pi? Adding an FPGA is a logical way to expand your IO, and allow for high speed digital interfaces. [Eric Brombaugh]’s Icehat adds a Lattice iCE5LP4K-SG48 FPGA in a package that fits neatly on top of the Raspberry Pi Zero. It also provides a few LEDs and Digilent compatible PMOD connectors for adding peripherals. The FPGA costs about six bucks, so this is one cheap FPGA board.

The FPGA has one time programmable memory, but can also be programmed over SPI. This allows the host Pi to flash the FGPA with the latest bitstream at boot. Sadly, this particular device is not supported by the open source Icestorm toolchain. Instead, you’ll need Lattice’s iCEcube2 design software. Fortunately, this chip is supported by the free license.

Icehat is an open source hardware design, but also includes a software application for flashing a bitstream to the FPGA from the Pi and an example application to get you started. All the relevant sources can be found on Github, and the PCB is available on OSHPark.

While this isn’t the first pairing of a Raspberry Pi and FPGA we’ve seen, it is quite possibly the smallest, and can be built by hand at a low cost.

32 thoughts on “Give Your RPi a Cool FPGA Hat

    1. Haha – I see what you did there.

      I’ve been in touch with the icestorm team regarding support for the iCE40 Ultra family and I’ve started the process of getting the ice5lp4k into the tools. It won’t come easily but the necessary steps are well documented so it’s just a matter of turning the crank.

      In the meantime, the iCECube2 tools are free and will run on most any x86 Linux distro, so it’s not a big deal to get your designs into this chip.

    2. I’m sure the problem is only temporary. Not sure I’d have the skills and I’m not sure what the license for iCEcube2 says about reverse engineering the bitstream, but we have two options for support.

      It’d be nice actually if Lattice could come to the party with a patch that implements some of their other chips. Sometimes these companies are their own worst enemy in terms of getting market share. Want people to learn your chips? Make it easy for people to use them. PIC revolutionised the micro-controller world by making the programming interface open. AVR pushed things further forward due to its gcc port: this is the reason it was chosen over PIC for the Arduino. Expressif are just discovering how the community can help them out.

      Lattice could lead the way to more open FPGAs, if they choose. That would solve the problem in the best way possible.

      The other is for some brave soul to follow in Clifford Wolf’s footsteps and reverse engineer the iCE5LP4K-SG48 bitstream. I say “brave”, as there’s legal issues with doing so depending on where you are and how you go about it.

      1. Clifford has already begun documenting the necessary steps required to get new chips supported in the icestorm tools on his reddit forum and I’ve started to work through those for the Ultra chip I’m using. Once I get further into that process then it will require some more attention from the main contributors to fully integrate.

  1. What kind of bandwidth can you get between the raspi and the hat (and over what kind of interface)? Last time I checked, there wasn’t a good way to get large amounts of data into RAM through peripherals.

    1. At the moment there are only two data channels between the icehat and RPi – a SPI slave that runs at the full rate of the RPi SPI port and the RPi I2S port. The SPI slave is potentially pretty fast so you could see rates up to 2-3MBps. The I2S port is rather slower but isochronous so good for audio or radio baseband data (my interest). My designs use the SPI slave for configuration and control and the I2S port for continuous data but there’s no reason you couldn’t repurpose these channels for other applications.

      1. Good to know, thanks. Sounds like the beaglebone’s PRU GPIOs are still more than 10x faster. We need the popularity and CPU speed of the RPi with the bus speeds and realtime support from the BBB’s sitara (plus gigabit ethernet and a pony)

        1. You guys might be interested in trying out SMI. It’s an peripheral on the BCM2835 has which can talk to NAND flashes or any other register interface over an 8 or 16 bit parallel bus at up to around 50MHz, and has a Linux driver on Raspbian since about a year ago.

          MIPI is currently a bit of a pain in the arse on 2835 due to multiple silicon bugs and a lack of open documentation. Awesome to hear about the CSI driver though.

  2. LE’s? LUT’s? Macro’s? We need a converter. Perhaps call it HDbabeL phish.

    I am keen to get into these Lattice chips but I don’t even PI so I am waiting for a low cost board that works with IceStorm.

    They look like there about the size of a largish CPLD rather than a FPGA.

        1. Yes but is the 8k (lower case ‘k’ for SI units) version supported by IceStorm?

          I mean that board sounds great but I am more interested trying IceStorm than Lattice because it the only open source toolchain that I know of and I think it would be good to support it.

          When I get around to it I will buy the IceStick that someone mentioned unless this 8k demo board is supported by IceStorm. I still have to install and learn the IDE for Cypress PSoC chips which look promising so I have a bit of a backlog.

          1. The HX8K breakout is definitely supported by IceStorm. I have one, and it’s been an absolute pleasure to code and flash. It’s probably easier than bringing up a new microcontroller IMO. IceStorm is a really good toolchain as well, and it’s something like 10X faster than Lattice’s toolchain.

    1. The deviding line between CPLD and FPGA is getting increasingling blurred. Altera’s MAX series of CPLDs seems to have morphed into full FPGAs with the latest MAX10. The ICE series here were originally CPLDs as well.

      As for comparisons, the manufacturers seem to go out of their way to make comparisons hard. LUTs can be wider than the traditional 4 bits, meaning LUT counts aren’t directly comparable. LEs are becoming specialised, and are often quoted as equivalent numbers to earlier generations, rather than the true count. Block RAM and registers get confused. Specific macro blocks are often hard to compare PLL vs timing slices for example, or some FPGAs are now coming with FP math slices.

      Long story short, there isn’t going to be a simple way of comparing them.

    1. The on-chip OTP isn’t the only way.
      These chips are smart enough to talk to an eeprom chip to configure on boot, and then you’re only limited by how many cycles your choice of eeprom chip supports.

      The on-chip OTP is intended for low cost mass production… Although clearly a bit of wishful thinking on behalf of Lattice.
      If you’re going to mass produce an FPGA based product (as opposed to converting the design into an asic for the production run, which gives you about 3 – 30x more performance as well) then you probably want to retain the capability to give your customers upgraded firmwares later on.

    1. On a PCMCIA card with a few megabyte ATA compliant boot device to put a DSL/Puppy type linux for the old 486 laptop you’re sticking it in to boot off and be the front end for the Pi which is running a more fully featured distro…

      … basically turns any PCMCIA capable machine into a graphics terminal for the Pi.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s