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.
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 ?
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:
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"
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).
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 !
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.
Pity #2 that both cost and real-estate constraints are unlikely to allow optoisolation and/or buffering of signals on the GPIO connector even in future redesigns. So many poor little Raspberry Pi's are going to die in the name of education and experimentation. I guess it's a worthy cause at least, they will be remembered.
PS. The article you linked is a real eye-opener, Michael. The real world is so hugely different to the cosy theoretical model of a simple bus with pullups.
Hi Morgaine - good point that this discussion merits a separate thread. I can branch as admin, but what do you think would be the best point to do so? Maybe http://www.element14.com/community/message/48868#48735?
Oh, excellent Drew if you can do that, thanks! We went seriously off the OP's topic by several miles, lol, but hopefully it was still useful material for Rpi-related development and education.
I think it was Michael's very interesting description of his cluster incorporating an FPGA --- http://www.element14.com/community/message/48733#48733 --- which greatly sparked my interest and the subsequent detour. Perhaps that would be a good branching point?
Thanks, let me know if the subject should be tweaked.
Interesting - we obviously move in rather different circles despite being in the same business:
Take the current project:
One master processor (ARM Cortex M4 with ARM serial debugging port and 4 wire trace, Ethernet, USB and serial for debugging)
One supervisor processor (ARM Cortext M0 with ARM serial debugging port)
FPGA with JTAG port
Up to 6 slave processors (ARM Cortex M4s with ARM serial debugging ports)
All in one little box about 25cm x 160cm x 5cm
Now to bring up the Ethernet on the master processor I can use its serial port for "printf" error messages (from the Ethernet/TCP/IP library) and the ARM debugging port to load/run/trace the processor. The ARM trace interace box (Keil Ulink Pro) is a USB interface to the development PC.
The superivisor processor is connected via another Ulink to another PC.
The FPGA JTAG interface is USB to yet another PC.
The fourth PC runs Wiresharc and is connected by Ethernet to see what's coming out.
It would be nice if the debug tools had Ethernet rather than USB interfaces but they don't.
I could isolate the serial debug port but since I must have three other non-isolated connections it's not worth the effort.
This system is all quite low power - so certainly safe to humans and fairly safe to computers. (The really exposed parts are the debug interfaces and there is nothing to be done about that since they need fast conenctions to the hardware.)
In the last 10 years I've lost one debugger and one PC due to my mistakes and in the same time at least 10 PCs have just died (as they do) so it's a cost effective approach.
Of course when these things connect to external systems handling real power different rules apply.
(AFIK most Ethernet interfaces are not specifically tested for mains safety - either during qualification or as part of normal regular safety checks (and the flash test requirement for Ethernet magnetics is 1500V AC which is OK for some equipment but not for all)).