Role for FPGA or CPLD with Raspberry Pi

That's a terrific system you're building there, with M4 master, M0 supervisor, FPGA, and <= 6 M4 slaves!

I'm intending to play with ARM clusters as well, not just Rpi but also STM32F4 of which I have several.  FPGAs (or at least CPLDs) are quite likely to appear in there somewhere too, as coprocessors or implementing a communications matrix.

It's also one of my strong interests (separate from clusters) to make gate-level programming more approachable by directly attaching either an FPGA or CPLD to Rpi, turning the ARM into a high-level networked peripheral for logic-based design, perhaps a bit like Xilinx's Zynq-7000 in some respects.

As you pointed out, there are no networked debug tools for FPGA work (at least not in my price bracket) ... but we can make the next best thing ourselves with the help of an ARM board, and Rpi is a nice one if you can work within its I/O constraints.

Morgaine.

Hello Morgaine,

I have great hopes for the Zynq - are you going to the Xilinx Xfest in May where there are a whole load of lectures about it ?

Michael Kellett

I wasn't intending to go, just keeping an eye open on progress in the Zynq-7000 area.  It's certain to become the way of the future in my view, assuming that Xilinx hasn't locked everything up in patents.

Which brings me to another interest, which is OpenCores and the democratizing of logic-level design.  If only that project were put on a sounder financial footing, for example by gaining direct support from RedHat or Ubuntu or some other open source supporters with money to spend, the future could look quite different to the one unfolding at the present time.

It interests me because Eben's vision (or "hypothesis" as he called it in the Beeb@30 video) doesn't really go deep enough.  Making kids aware of Python and programming concepts is great, but it shouldn't end there.  Logic-level design is important too, and could be made just as easy with some work along Scratch lines.  What's more, it's poorly served by the open source world currently, so I think that a bit more attention there could be worthwhile.

This is why I think putting even a simple CPLD on an Rpi could be valuable educationally, and even useful for some interesting projects.

In case someone doesn't know what Michael and I are talking about, here are a few links that might help:

    http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm

    http://www.linuxfordevices.com/c/a/News/Xilinx-Zynq7000/

    http://opencores.org/

    http://orsoc.se/openrisc1200-platform-2/

    http://opencores.org/donation

    http://scratch.mit.edu/

    http://info.scratch.mit.edu/Educators

Morgaine.

I like the idea of teaching programmable logic, too.  My intro digital electronics course used a FPGA dev board and VHDL which I found fascinating.  I did somewhat regret missing the experience of having a breadboard full of logic chips, but I don't think I would have had the confidence to experiment with FGPA & VHDL otherwise.

Do you imagine any FPGA/CPLD tools could run on the Pi?  I would guess memory could be an issue.

BTW, I watched this last night which talked about building a system from OpenRISC:

"Videos from #OSHUG #17 - Practical System-on-Chip"

http://lanyrd.com/2012/oshug17/video/

Cheers,

Drew

The major FPGA manufacturers all offer very good tools for free and even better ones for money. All the tools are memory and disk hogs (1Gb free memory min but often need much more) and as soon as you do much they need a really fast computer. The RPi just isn't up to it.

I don't know of any open source small footprint solution to do the whole job (design capture, simulation, synthesis, programming).

Michael Kellett

Ah ok, I was fearing that.  My memories of Quartus were that it brought the PCs in our lab to a crawl during synthesis.

Besides requiring lots of RAM there is also the fact that these programs are compiled for intel CPUs and not for ARM.

Even though the RPI cannot run the synthesis software, the RPI can function as a good intermediary to the hardware. I'm not writing off the RPI for this application just yet.

Good video, thanks Drew.

As Michael says, the FPGA manufacturers provide powerful tools, but they're all closed source package deals and they try to create a captive audience for their products, which is the opposite of where we want to be.  As we try to extend the reach of open source software down into the hardware, it would be incongruous if we then had to use closed source software tools to develop the open hardware.  That's clearly not the way to go.

As Drew's video mentioned, open source tools like Icarus Verilog, Verilator and Gtkwave provide a start towards getting us back into software control there, at least at the front end.  Until the day that we get a open FPGA fabbed, we'll probably have to keep relying on closed back-end synthesis tools from the closed manufacturers, but we should at least try to limit them to the back end, as OpenCores is doing.

Of course a fabbed OpenRISC would be fully open hardware from a programmer's perspective, but if you need closed source tools in its creation and simulation then you don't have a completely open toolchain.

I had  a quick re-scan of open source VHDL tools and they are so limited at the moment - I don't think there is anything like the critical mass to make a "GCC" for FPGA.

as for open FPGA .... only if someone like Intel (with silicon fab and deep pockets and currently showing strange interest in FPGA startups) decides they want to take a swipe at Xilinx and Altera.

On a more promising note, and possibly should be in a new thread, interestng article about I2C isolation, just need to find where to buy them !

http://www.edn.com/article/521380-Optically_isolating_an_I2C_interface_Beware_of_nonlinear_propagation_delays.php?cid=Newsletter+-+EDN+on+Consumer+Electronics

Michael Kellett

Pity that we can't split off the posts where we started talking about ARM and FPGAs into a separate thread.  They clearly have nothing to do with the original poster's topic, lol.  But if we start a new thread now it'll lack the posts above, and will probably dry up immediately by Sod's Law.