A Raspberry Pi In An FPGA

Somehow or another, the Raspberry Pi has become a standardized form factor for single board computers. There are now Raspberry Pi-shaped objects that can do anything, and between the Odroid and bizarre Intel Atom-powered boards, everything you could ever want is now packaged into something that looks like a Raspberry Pi.

Except for one thing, of course, and that’s where [antti.lukats]’s entry for the 2016 Hackaday Prize comes in. He’s creating a version of the Raspberry Pi based on a chip that combines a fast ARM processor and an FPGA in one small package. It’s called the ZynqBerry and will, assuredly, become one of the best platforms to learn FPGA trickery on.

Xilinx’ Zynq comes with a dual-core ARM Cortex A9 running around 1GHZ, and from that fact alone should be about comparable to the original Raspberry Pi. Also inside the Zynq SoC is a very capable FPGA that [antti] is using to drive HDMI at 60hz, and can stream video from a Raspberry Pi camera to a display.

Last year for the Hackaday Prize, [antti] presented some very cool stuff, including a tiny FPGA development board no bigger than a DIP-8 chip. He’s hackaday.io’s resident FPGA wizard, and the ZynqBerry is the culmination of a lot of work over the past year or so. While it’s doubtful it will be as powerful as the latest Raspberry Pis and Pi clones, this is a phenomenal piece of work that puts an interesting twist on the usual FPGA development boards.

The HackadayPrize2016 is Sponsored by:

50 thoughts on “A Raspberry Pi In An FPGA

      1. We too. This feature isn’t as interesting as lattice ice40 which now has an open source flow which can easily run on a raspberry pi.

        Raspberry pi is available, well documented, with a great deal of open source software and cheap.

        And can program FPGA already.

        This project literally adds nothing and loses a lot of that.

          1. Yes, when I see those kind of titles in Faceb**k, I just go to the comments to see if it was worth following the link.
            The comments often contain the “spoiler” that could have just as easily been in the original posting.

        1. ARM has a history of shutting down open, synthesizable implementations of their architectures on OpenCores. I’m sure they can provide an FPGA core if you pay them enough, but they will not allow anybody to release such thing for free, because it would be a direct threat to their business model.

        2. All Cortex cores have been designed as synthesisable (aka ‘soft-IP’) and are put into FPGAs as part of the design testing process (okay, they’re large, multi-FPGA behemoths that cost moon+stick). The closest to allowing consumers access to a synthesisable core was the Cortex-M1 (essentially an M0 optimised for FPGA logic primitives).

  1. “…ARM Cortex A9 running around 1GHZ…”
    “…is using to drive HDMI at 60hz…”
    Ok, maybe it’s nitpicking but symbols of units are case sensitive 60s is a one minute, 60S is 60 Siemens. So please, use proper “Hz”.

    1. Yes. Normally I am not interested in such spelling discussions, except when it comes to units. Like people talking about “4mbit/s” Internet, meaning MEGA bit/s, not milli bit :-)

      1. +1000! I could not care less about most grammatical differences, but a mispelled unit completely changes the meaning! Its the same as mis-typing the actual number that the units accompany. Might as well be useless info.

        Seconds and Siemens get swapped all the time and it drives me crazy. Same with bps and Bps…
        /rant

  2. I don’t get it. The only thing special about a RPi is price. There have been far more capable boards all along. A Zynq isn’t close to any RPi in terms of total price tag. A Parallela board is the most inexpensive Zynq @ $100 w/ 7010 and 16-core Epiphony. But I suspect it’s heavily subsidized by Adapteva.

    The only thing RPi-like about this project is the form factor & pin-outs. As if either were that great and expansive to begin with.

    1. Which more capable boards do you have in mind?
      Odroid boards are a big no-go either when you need to do anything creative with Linux kernel (like modify or write a new driver) or when you try to do anything more with GPU other than watch a movie.
      Regarding graphics and maybe also upstream kernel there are little pricier Dragonboards but that’s all IMHO.

    2. I would tell that the only special thing about Raspberry Pi is that it has amazing software support at that price. You can find a lot of SBC with great specs but with horrible software. And that is the real deal to me.

      1. But the RPi has dire performance when it comes to moving large amounts of data about. It is crippled by it single real USB 2.0 port out of which basically everything (excluding) hangs.

    3. The Snickerdoodle is cheaper than the Parallela ($72 for the 1GB Zynq 7010 version). You used to be able to get the 512MB version for $55, but they sold out. Zynq is actually not too expensive when you buy large quantities.

      With that said, I fully agree that sticking to the same formfactor is a bit pointless. Like all those Arduino-compatible boards that retain the horrible half-pitch spacing on one of the headers. Did anyone actually use Arduino add-on boards with them?

      The ones I’m keeping an eye on are the cheap-ish Zynq Ultrascale modules. Quad-core ARM, plus a Mali 400 GPU, plus a decent FPGA (even the smallest is significantly larger than the Zynq 7020) – and pricing doesn’t seem to be much higher than for the standard Zynq.

  3. Although it’s an interesting project, I think it’s a waste for the zynq, as it has hundreds of pins available and would be limited by the Raspberry Pi GPIO socket. Snickerdoodle (or Parallella) would be a better option, as it makes those accessible and at a reasonable price. With respect to software support, I used the Zynq at work and it was easy to work with, as Xilinx provides support for a yocto based linux distribution (Petalinux), with latest linux kernels (they publish everything open-source on github) and can use u-boot (which the rpi afaik can’t).

      1. The value is a supported fully working starting point to extend the system from with features impossible to integrate on simple SoC platforms. For example multiple synchronous camera interfaces with high speed image pre-processing. Or Managing multiple high speed synchronous ADC with some DSP processing before CPU consumption. Or integrate a OFDM modem with a single external AFE chip to communicate over client specific very unusual media. When you do this kind of extra features, you don’t wan’t to spend time to simply get the usual standard peripherals working to the level found out of the box on most SoC. Every specific feature need to be maintained.

        If almost all projects use a different HDMI and CIS implementation for about the same result, then a lot of work is duplicated for no value, the average quality will be lower, and the community support impossible. The project could be the starting point of a community support for the basic peripherals that allow to directly get a basic standard system to life in no time. Then you can concentrate to the added values features required by your clients.

    1. Unfortunately, the Scarab board had a lot of problems getting some traction. Their forum has new post only once every month. I think there is a lack of commitment from the funder too.

  4. WTF? They are using a USB to 100 Mbit Ethernet like the Raspberry… really??? The Zynq has Gbit Ethernet onboard, why they are not using this native and faster interface?

  5. Kudo for that project. The Zynq is a amazing chip to integrate capabilities not available on others SoC, but I lacked a cheap starting platform directly compatible with one of the leading ARM Linux board out there. The value for me is that every basic peripherals are already working so that I can extend the platform with special extra features based on already exiting and tested peripherals.

    Now if only the Zynq would get a first class support for a clean Debian armhf instead if the completely obsolete Petalinux layer over Yocto layer over Openembedded recipes for bitbake tool. This would allow to easily get a lot of quality packages without having to fetch and build them. The package integration would also benefit from the leading Debian quality control and community support. Compared to Debian, Petalinux is a bad joke.

  6. Has anyone noticed that FGPA boards keep coming along and failing to gain traction? Although I love the idea of playing with FPGA, I couldn’t find a real “hacker” use for it. Most of what I need to do can be covered by software with standard CPUs. I understand their value in a commercial or industrial environment but would be interested to know what sort of things hackers are doing with FGPAs that can’t be done sufficiently well in another, simpler, way.

    1. You know how when you get two motors, that one motor runs faster than the other? I’m trying to use an encoder signal (quad encoder on each motor) to auto-compensate for their differences. I’m having trouble reading the encoders reliably on an AVR, but my little ice40 stick could handle this seamlessly. And transparently to SW – SW wouldn’t even need to know.

    2. FPGA’s excel at high speed parallel operation and it’s easy to implement clock cycle accurate designs on them.
      As such they are way more suited for processing multiple high speed data streams such as audio, video, ethernet etc. then microcontrollers.

      FPGA projects can be ported to different models or brands without loss of clock cycle accuracy which tends to be impossible on microcontrollers because to make a project portable you need to write it in a high level language but to achieve clock cycle accuracy you need a low level language.

      Depending on your requirements FPGA’s can be significantly easier to use then microcontrollers. I would say that the only thing that’s difficult to make on a FPGA are big state machines, not because a FPGA can’t handle them well but they are a big nuisance to implement especially if you need to insert a delay between one state and the next.

      I find it easier to implement a VGA controller that can switch resolutions on the fly then an I2C controller on a FPGA. The opposite is however true when I’m programming a microcontroller.

      Some practical examples that are ‘simpler’ to implement on a FPGA are;
      * VGA controller
      * Multi channel synth with Amplitude- and Frequency modulation, variety of waveforms and filters.
      * Logic glue e.g. translating data between incompatible buses.

      As to why FPGA boards keep failing to gain traction I think it’s because they try to gain appeal by using popular board form factors from products such as arduino that don’t really suit FPGA’s. Experienced FPGA people stay away from them because they have different demands and new people get frustrated because they see an arduino form factor and try to use it as such. (e.g. If it looks like a hammer but it’s actually a screw driver, people will think it’s a bad hammer)

      Because the experienced people stay away there aren’t enough people to supply insights and support on forums and the community ends up dying eventually.

      Do yourself a favor and get a DE- dev board from terasic (or a good clone) and enjoy the benefits of a experienced stable community if you want a great start in FPGA’s.

    1. Actually the purpose of this project is to program the Zynq to be mostly compatible (but the GPU) with the Raspberry PI peripherals. So the title is no so wrong from this point of view.Then you can extend the project like a FPGA attached to the Raspberry PI CPU (but with greater performances). Finally you can buy that chip to implement a custom design, unlike the Raspberry Pi Broadcom SoC that is impossible to buy outside of the context of mass market projects.

      1. A little bit of reading on the HaD.io page and you would realize the intent (at least thus far) is NOT to create RPi peripherals in the PL fabric. All of the implemented RPi-similar I/O has been done with Xilinx/Zynq specific methods and drivers thus far. The project does not aim to achieve drop-in software compatibility with stock RPi distributions. Its only aim is to provide connector and header compatibility with RPi-1 form-factor and pin-outs – which were rather limited to begin with.

        1. Depend from the level of the observation: the Linux kernel main purpose is to abstract the hardware, so from the userspace application point of view it’s mostly like a raspberry PI (with some advantages and some limitations). Yes this is limited to especially the connectors, but so far I know no other Zynq project that give a such valuable starting point that includes tested HDL blocks for HDMI and CSI (without extra converter chip like on the Zedboard for example).

  7. While I appreciate the idea of an FPGA on the same chip as a processor, I find it more exciting to read about a processor that can program it’s own FPGA. To that end, the work on the Lattice chips outweighs the benefits of Zynq.

    Unless, of course, Xilinx now have a stripped down version of Vivado that runs on ARM Linux? What about Altera/Intel ?
    [Hey, this room seems awful quiet all of a sudden]

    1. What you describes could be see as a 3 steps process:
      1) Synthesize the netlist on the target CPU: Yosys already support limited support to runs netlist synthesis for Xilinx FPGAs, see http://www.clifford.at/yosys/cmd_synth_xilinx.html
      2) Place and route to generate the binary file: AFAIK there is currently no solution for armhf target CPU.
      3) Programming the binary file into FPGA on the fly using the target CPU: already done, see http://www.wiki.xilinx.com/Programming+the+Programmable+Logic

      From my point of view, the really nice feature would be to have some kind partitions of the FPGA area so that multiples synthesis peripherals could be synthezied and reprogrammed on the fly independently. I mean, if the FPGA contain for example a frame buffer with HDMI and a camera serial interface, and that you want to add a OFDM modem, you don’t really have high value to re-generate and re-program the FB+HDMI and CSI each time you iterate your OFDM design. The ultimate goal would be that the Linux driver itself program his related FPGA partition, but AFAIK this is years ahead what the current tools can currently do.

    2. Thats why I quit before starting with fpga’s years ago. The lack of tools to synthesize it in an easy way (vivado/ise are not an option). I think an open source toolchain is what is really needed. I will look for news on Lattice:)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.