Why do we need an open source FPGA toolchain?

Let me quote Google:

“If TensorFlow is so great, why open source it rather than keep it proprietary? The answer is simpler than you might think: We believe that machine learning is a key ingredient to the innovative products and technologies of the future. Research in this area is global and growing fast, but lacks standard tools. By sharing what we believe to be one of the best machine learning toolboxes in the world, we hope to create an open standard for exchanging research ideas and putting machine learning in products”

So do we think that it requires a common platform on which innovation in the field of FPGA programming can happen. And for economic and strategic reasons, this common platform must not be owned by one private company, but need to be a common good, open and hackable and affordable for everyone.

 

What are small and slow FPGAs used for (with little SRAM) ?

Today most embedded problems can be solved with a cheap 32bit MCU.

Those are also much easier to program than FPGAs.

But small FPGAs are an absolute must if you have a problem which requires very fast reaction time,

very precise synchronization of multiple sensors or actuators or you need very accurate timing of events.

This is the case when you need fast control loops controlling very fast processes (like controlling fast spinning motors, regulating voltage or electric current, when you want to filter data very fast (like in a logic analyzer looking in real time for a trigger situation) or in driving lots of nozzels in an Injet print-head or the laser in a laser-printer (in case you do not want to have printed trackable documents http://www.net-security.org/secworld.php?id=18995 ).

Precise synchronization you need when you have system with lots of sensors where the data acquisition need to be at the exact same time with precise repetition (=low jitter) to be able to do a good measurement (like in a MRI scanner or phased array antenna).
Here you can find a good video explaining when a FPGA might be a better solution than an embedded controller.

Generate great music
FPGAs are very well suited for high level math operations, especially for complex algorithms or when operating on data streams at a high data rate (in the MHz). The strength of an FPGA is its ability to pipeline operations which means that the algorithm is broken up spatially into different steps. Each cycle new data flows into the top of the pipe and the processed data exits at the end. In this way, each step of the process occurs simultaneously, like an assembly line, so that no single iteration of the algorithm is blocked by the iteration before. By contrast a processor is a sequential machine so each iteration of an algorithm has to wait until the previous one finishes before starting.

A CPU is doing one thing after the other, no matter how fast it is clocked. And high end CPUs are massive pipelines, which increases the latency of any code execution.
FPGA are needed when you want to be sure that things happen exactly at the same time on a microsecond scale.  This might be required treating several sensor inputs (like in a MRI or other sensor arrays where timing is critical) or a phased array antenna, or this might be at the output like controlling several currents and voltages of several motors to generate one smooth and precise movement of one robot arm or CNC machine with minimal electrical loss.

If you want to happen small things really fast (like a trigger at a logic analyzer), CPUs with their task switching and pipeline of instructions just react too slow. You want to have the trigger be implemented in hardware.

If you want things to be reliable and save, then you implement something in hardware. Simple hardware circuits are much simpler to prove to be error free that a whole CPU with its operating system software stack and the simple application on top. Complicated software can not be implemented in hardware, So there you need to “use the complex stack. But if you don’t have a complex problem, you can keep it simple by implementing it in programmable hardware.

Small FPGAs can move closer to the sensors and make the edge smart. This simplifies system design and software development a lot. The signal conditioning and validation and aggregation could be done directly at the sensor.

Very often this could be done by a MCU, but when low latency is important, FPGA are a better choice.

They can be used for indoor navigation system where the run time of radio waves determines the location of devices.

Other Areas

High Performance Computing

Low Latency TradingMulti-core FPGA Prototyping and SoC Prototyping, ASIC Prototyping

Telecommunications

Code verification

Chip design verification and simulation

Cloud computing

Video and Audio compression and filtering

 

Algorithm acceleration

Genomics

Deep Learning

Network Encryption

Network Analysis (deep packet inspection)

Radio Communication (Software defined Radio)

Beamforming

Simulation and supercomputing (Oil and Gas)

High frequency trading (making money out of thin air)

Network Switching (Software defined Networking)

Video processing (Broadcast solutions)

Streamed Data filtering (Cern)

Differentiate Yourself

If you have a project which was done a 100 times before you, then there is a high probability that this use case is very will supported by propriety tools. There might even be a wizards to implement the functionality you need to implement. But at the same time, this feature will not be the functionality that will differentiate your product from all the other products. So the feature you implemented will not add to the differentiation value of the product.

On the other hand, if the feature you are implementing is the essential differentiation because is solves a problem up to now no one was able to solve (maybe because it was too hard to solve), it is very likely that you propriety tool does not very well support you in designing the solution. It might be that it was even impossible to realize a solution because of the limitation of the propriety tools. Therefore researchers in the past had to build their own tools (like Gallileo the first telescope).

With open source, you can extend the tool to your needs. This is especially useful when you start your project and you do not yet have a clear understanding what features you will need from your tools.

You don’t get stuck. If you find out half way into the project that your propriety tool is not up to the task, you need to start over again.

To be competitive in the market requires that you offer products which are different from the products of your competitor. Your offering can be cheaper, can be more easily available, or can have features others do not provide.

An open source FPGA toolchain can help you in all three areas.

When you decide to design a product, you define a feature set your product will offer so that people are willing to pay for it. Then you need to implement this feature set with the tools available to to. With FPGAs this are the tools provided by the manufacturer of the chips.

You might not want to out-compete your competitor to be cheaper by just accepting a lower salary. You need to be able to design faster than your competitor, who is using the same tools as you. Which means that you need to be smarter or more experienced to gain an competitive advantage. Which might not always be the case.

You might want to out-compete your competitor by offering a innovative feature set in your product. As you are the first designer using the FPGa tool set for this new kind of feature, you  will probably discover a lot of bugs in the FPGA tool as noone else before you did use the tool in this new way. But this gives you the possibility to out-compete your competitor by inventing “tool-bug workarounds” and finishing your innovative product. Finding those bugs in the tools and inventing workaround takes a lot of time and cost a lot of money.

Your  experience gained in this process will become obsolete with the next version of the tools because the toolmaker will fix many of those bugs.

If you use an opensource toolchain, you are not bound by the feature set the commercial tool vendor is offering. you can break away from your competitor by extending the open source toolchain in a new creative way. This way you can design products which differ from your competitors products as you use different tools.

For sure, opensource toolchain do not support all the features commercial tools offer today. for for designing a intriguing products, it might be that you don’t need all those features, but only the already available once in the opens source tools and you add one really important feature to design the compelling product your clients are willing to pay for.

Google could have used Windows NT or Solaris to build its search clusters, but decided to use the inferior Linux, as it was a good enough fit, and offered the possibility to adapt it to the specific needs of google to build a large search cluster.

If you can use the open source FPGA toolchain with its limited feature set to build the product you imagine, but you would need to push the limits of the commercial toolchain to realize your innovative product, you are very likely better off using the open source toolchain, because you will not need to work around the bugs in the toolchain, but can hire a toolchain developer to fix and adopt the toolchain to your specific needs, which saves you a lot of time and money.

Therefore, if  using a open source FPGA toolchain can result in a cheaper, earlier and more useful product.

CroG

A lot of devices are accumulated during the existence of a house. Not all devcies to have up to date Internet interfaces. CroG is a gateway between legacy interfaces of houshold installations  and modern data interfaces of IoT solutions.

 

Up to 20 different types of  phyiscal connections can be attached to a CroG at the same time as its physical interfaces consist of PMOD modules.

CroG consists of an icoBoard, PMOD interface modules, software implementing hardware interfaces to connect legacy hardware to the icoBoard and Software implementing clowd protocols for IoT services.

GSoC Google Summer of Code

If you want to work within the Google Summer of Code program, you can find ideas we are interested in under the following links.

Fossi Foundation Yosys GSoC 2016

lowrisc Yosys GSoC 2016

 

The following list are general project ideas

  • Schematic Viewer for Netlists (SVG/JavaScript) Link

  • Porting ArachnePnR to OpenCL 1.2
  • Implementation Client of USB 2.0 of Daisho project  on icoBoard
  • Integrate FPGA tools like FuseSOC, Yosys, AachnePnR and a repository containing tested IP blocks into a webbased SOC generator suite for icoBoard and possible peripherals
  • implement a minion core executing a rump kernel in icoBoard acting as an device or network interface for the RaspberryPi (i2c,TCP/IP, i2s, SPI, CAN, PWM, Position, ..)
  • demo project tracking the position of a wireless microphone by radiosynchronized soundbeacons
  • implement a SDR narrowband modulator/demodulator in Verilog
  • implement a HDR video pipeline with a high speed low resolution camera sensor on icoBoard
  • implement a programmable smart powersupply with FPGA based control loops with icoTC
  • if you are an European Union citizen or from Asia of Africa: reverse and document a modern FPGA
  • Developing a Verilog Block listed here

Timeline

February 2015: Reverse engineering of Lattice ICE40 1k Chip

March 2015: reading of bitstream and conversion into Verilog

June 2015:  generation of Latice compatible bitstream by Yosis/ArachnePnR/ICEstorm

July: reverse engineering of Lattice ICE40 8k Chip

August 2015: porting of complete  toolchain to RaspberryPi, generation of bitstream and programming of Lattice ICE40 8k by RasPi

December 2015:  Presentation of complete solution and making available beta boards at 32C3 Hamburg

January 2016: Timing analysis done

February 2016:  SD support done, porting of micropython to icoBoard/Risc-V begins

June 2016: porting of Contiki OS to Risc-V is done

July 2016: 150 icoBoards have been manufactured and are distributed to developers

icoBoard_starter

This bundle includes:

  • RaspberyPi
  • Wifi dongle
  • 16 GB microSD card containing all software preinstalled
  • icoBoard
  • 8 LED PMOD module
  • 2A powersupply

You only need a USB keyboard, a USB mouse and a HDMI monitor with HDMI cable.

Everything is included so that you can compile your first Verilog example code and blink your first LED within 5 minutes after opening the box.

The bundle does cost 160 Euro and spares you the separate shipping cost for your RaspberryPi and the downloading of the microSD card image.

We plan to have domain specific bundles with all the hardware required to work on usecases in the respective field

icoBoard_radio

will have a SubGHz narrow band transceiver with IQ interface

icoBoard_video

will have a 640*480 camera module

icoBoard_motion

will have a high power driverboard and a 5W brushless DC motor to implement control strategies