In the last few weeks, I was very busy with all kind of things. The two most important ones were to develop my PSHDL Board and the second one was to implement cloud synthesis. In this blog post I want to give some background into why I developed those.
Btw. both were introduced at the 30C3 congress, that I enjoyed very much. There is a recording of that presentation available at youtube my FPGA 101 is also available online. I was very surprised by how much positive feedback I received. Thanks a lot for this! This is very encouraging to continue this work.
When you start developing FPGAs you may wonder yourself: What should I do with them?! And unfortunately there is no single good answer to it. A lot of stuff can be done bei either an µController or a full blown CPU. Not so many people want to perform hardware glitching, sniff high-speed buses, or do the other stuff that FPGAs are good at. Especially since FPGAs are now out of the bitcoin mining league and only ASICs may provide a viable business case. So my idea is to create a little toy that gives an FPGA newcomer something fun to play with for some time. This is why I created the PSHDL board.
The primary thing to play with are the LEDs of course. Each LED Arm contains 4 RGB LEDs that can be controlled individually. With 4 arms, you can already do some pretty sweet looking things. The idea here is that you first learn how to control the LEDs and make them blink, or light in different colors. The next step would then be to create animations, for which you need state machines. After that you can start playing with connectivity or create simple games. You can either attempt to receive data from your PC, or interconnect multiple boards. For interconnection you can stack vertically with a 45° angle, or horizontal via the 4 pin headers at the end of the arm. If all of that gets too boring you can also implement a small CPU and have some fun with that. There is a gallery with pictures available online. I will implement some cool things hopefully soon.
The board itself contains an Atmel XMega, which either will be the XMega32A4u, or the XMega128A4u. The later would have some room for implementing interesting things, while the first is the bare minimum to fullfil its purpose (interfacing with the PC and programming the FPGA). It is also possible to use the ADCs for reading in analog data and passing that to the FPGA, connecting something to the I2C pins or do something entirely different with it. This chip also allows the PSHDL board to be programmed from any operating system.
I created a website where I am asking people what they are willing to pay for the board. The answers look very promising. I think I can realistically build and sell the boards for that price when I am able to sell more than 250, which also appears to be a rather realistic number. If you have not participated you can give your vote here.
One of the major annoyances that keeps me from enjoying programming FPGAs is the fact that you have to install a vendor toolchain. Those are generally available for Linux and Windows. While I don't mind running either of those, I either have to fire up a VM, or use my Windows Desktop machine that is the most silent when it is switched off.
While the best solution would be to simply incorporate an open source synthesis flow into PSHDL, this is unfortunately not realistic. There are academic tool flows that can go down to place and route VTR Rapidsmith, but the one step they are missing is generating the FPGA configuration. The reason why they can't do this is the stubbornness of FPGA vendors. They think that laying open their exact specification for the FPGA configuration would harm their business. I think that is a rather stupid statement. A lot of companies are benefiting from GCC for example and the EDA industry would do good to step up and give developers the spec to implement this last crucial step. It is not like I would care about the state machine for programming the security stuff. I am perfectly fine if only the unencrypted configuration would be possible.
There are people that are reverse engineering some configuration files for some FPGAs, but I think that is the wrong way to do. The tools will always play catch-up with the latest technology and are prone to law-suits. Plus with an incomplete knowledge of the FPGA architecture it is possible to short circuit logic within the FPGA and ultimately damage it.
So how does cloud synthesis then work? Well, it does just hide the invocation of the vendor tool chain by putting it onto a different machine. In order to enable cloud synthesis, you have to attach a so called local-helper to your workspace. This local-helper creates a two way sync between your workspace and a directory. The web client then sends a message to the local-helper which then invokes the synthesis tools with the files it just downloaded. Exactly for this kind of purpose there is a PubSub channel on my REST API. So the machine that the synthesis is running on does not need to have any open ports or alike. It just uses a single SSE connection to the workspace.
Unfortunately this workflow is rather cumbersome right now. I am working on documenting it and increasing the usability. So please give me some time here :)