Martin Geisse

The same discussion has been there for Arduino, and I don't think there is value in repeating it here. Nevertheless, Papilio seems to present itself as an "Arduino for FPGA", so whether or not you like the Arduino approach, I think Papilio is currently not quite reaching that goal. I would be surprised if all that works without downloading gigabytes of IDE and jumping through hoops to get a license file...

That's exactly my point. The time required to get a simple tutorial to work with Arduino is not half a day plus a dirty hack, it's more like ten to twenty minutes and works out of the box. The concepts are indeed harder than software, but not at all as bad as usually described. In fact, the quality of the tools (such as bad error messages) contribute a lot to it. Try programming C with a compiler that outputs useless messages instead of GCC. That's fine in many cases where performance is not your primary concern. The Arduino isn't exactly a candidate for high-performance computing either. Take for example a pin that could be a loadable output, PWM or delta-sigma, serial port (shift register), and so on. Another mux in that path doesn't matter because none of that is time-critical down to a single clock cycle. The really critical parts are things like Ethernet, video signal and memory controllers. These tend to be fixed paths on the PCB for the same reason and thus could be hardcoded in a board-specific configuration, which is written once and compiled the traditional way (xst, ngdbuild, par, bitgen). In the end, most of what you say comes down to goals and priorities. My comment was aimed at Papilio being a competitor to Arduino for special-case applications where an MCU doesn't cut it. Most of what you say more applies to the design of a traditional FPGA development board.

Hi Jack (and everyone else), first of all, two thumbs up on your effort to make FPGA development easier. I'd like to throw in my two cents since I think the approach isn't quite getting near an "Arduino for FPGA", which seems to be the goal. The Arduino has an extemely low barrier to entry, which the Papilio is missing. Some time ago me and some colleagues took an Arduino and built some cool stuff within minutes, despite me having never worked with a microcontroller. Download the IDE, copy&paste an example from the net, run it, modify a few things, run again -- there it is, the first blinking-LED program I built on my own. Everyone was enthusiatic about it. Contrast that with the up-front effort needed to do the same with an FPGA. I tried to bring an FPGA into the mix the same day, just for fun, and we gave up before we finished installing ISE. Despite me having build a CPU clone in Verilog before, so it was definitely not lack of skill. Despite the Verilog code for a few blinking LEDs is no more complex than doing the same in C. Despite the others being programmers who, even without experience in hardware, would have grasped the way Verilog works easily. It was just the artificial barrier to entry that was too high compared to Arduino: get an ISE license (on some unmaintained legacy licensing site), download ISE (way too big), install ISE (doesn't run on MacOS X), use ISE (I hope the guys who built that got fired). My take is to start with the premise that the barrier to entry must be as low as for Arduino. That likely means to remove ISE from the loop -- even with a cloud-hosted version, asking people to register on the Xilinx homepage and obtain a license file just for the sake of it is exactly what should NOT happen. Without ISE, things are obviously getting harder. The most obvious approach would be to build a (large!) series of "batteries included" FPGA configurations, synthesize yourself in ISE (or command-line xst, ngdbuild, par, bitgen), and make them available as bitstream files. Then, just like now, let the user select one of pre-built bitstream files and write software for it. This is not VHDL development, but offering a large number of pre-built FPGA configurations comes closer. Building these from common code can be done in scripted builds. The next step would be to make large parts of these configurations run-time configurable through (Verilog-defined) programmed registers, BlockRAM contents, etc. This gets even closer to hardware design. Except for the high-performance stuff, most parts don't mind including yet another mux to make the design more flexible. As a further tool, these "soft" configuration parts can be patched into an existing bitstream. The locations of BlockRAM and LUT contents are well-known enough to do that. Again, just my opinion. Greetings, Martin