FBus: Open FPGA Realtime Bus

Defining and implementing a bus protocol that is built around low-cost FPGAs to enable modular and affordable control and DAQ systems.

Similar projects worth following
Data Acquisition Systems (DAQs) are either notoriously expensive or not very capable even though the operations they perform are rather basic. These systems will usually run on specialized proprietary bus protocols and most of them are optimized to operate in a master / slave logic where one board acts as a CPU and talks to the other boards via a memory like interface.

This project is here to put an end to all of that.

The FBus will be based around FPGAs which will be used rather different from the traditional approach. Usually FPGAs serve as kind of upgradable ASICs, i.e. their bitstream usually stays static in between firmware versions. Building the bus around the awesome SymbiFlow toolchain ( will allow reconfiguration tailored to the specific mode of control or measurement.

But Why?

This project is the ultimate tool to combine general purpose modules to specific complex projects.
Some examples:

Inverted Pendulum:

This is an actual example I work on at the moment, you can find details in the the project updates

You want to perform a basic controlling task such as controlling an inverted pendulum? Just grab the Analog Input Card to read out an optical encoder, and combine it with the Stepper Controller Card. Implement your control system using XCos, upload it to the FBus and there you go.


You want to use an oscilloscope in your electronic project but not include it permanently? Just take the precision Analog Input Card, combine it with the HDMI Output Card and some auto-generated interface logic and voila - you have your oscilloscope. 

CNC Motion Controller:

You want a CNC motion controller? Just hook up three Stepper Motor Controller Cards with the USB Interface Card, combine it with some control logic - you have your CNC motion controller.

Other ideas? Leave them in the comments! :-)

Planned Cards

To enable a wide range of projects to be implemented I plan to implenet a full range of daughter Cards enabling all kinds of control an measurement setups an non exhaustive list of cards I am working on or thinking about:

To make use of FBus in a wide range of controlling and measurement applications, I plan to build various daughter cards:

  •      Precision Analog Input and Output Card
  •      Fast Analog Input and Output Card
  •      Amplifier and Analog Frontend Cards
  •      General Purpose IO Card
  •      Logic Analyser Card
  •      HDMI In and Output Card
  •      Arduino compatible Card
  •      Stepper Motor Driver Card
  •      Brushless Motor Driver Card
  •      High Frequency Cards (like signal generators, counter, mixer)
  •      Any other ideas or wishes? Leave it in the comments!

The Components of the FBus

The Configurator

In order to allow dynamic configurations of all the parts of the bus we need to talk to all of them. This is the Job of the Configurator which will have one UART channel to each of the bus members to upload bitstreams, make firmware updates, or check for general health of the bus participant. It has one reserved Slot on each FBus backplane. It self does not act like a master of the bus as it has no access to the actual data lines. It will communicate to the outside world using an ethernet base protocol and is explicitly only for configuration purposes and can not perform realtime critical tasks.

The Bus

These are the slots where the actual functional Nodes are located. Each will usually contain an SymbiFlow-compatible FPGA and a small Microprocessor to load the bitstream for it. It taps into up to all of the 40 differential communication lines. But if it does not require that much data throughput it can just stick with one or two or just as many as are necessary.

The Timekeeper

The FBus is designed to be synchronous in order to guarantee hard realtime properties. Therefore there will be one timekeeper per backplane that contains a set of PLLs with the ability to phase adjust the clock for each Node so that all boards on the bus are perfectly in sync.


The FBus uses the physical PCI-e connector for connecting the Nodes and the Timekeeper and the Configurator with a backplane. In this first version the Lines are designated to allow differential routing on a two-layer backplane. The data part of the PCI-E connector contains 40 differential Data Lines, one differential clock line, a TX/RX UART channel, a 5V Supply, a system voltage supply (can be anything from 5V to 24V). In the supply part of the PCI-e connector are 16 general purpose lines intended for supply of analog...

Read more »

plain - 3.52 kB - 04/21/2019 at 12:24


  • 1 × ECP5-12K SymbiFlow compatible FPGA on a bargain with a lot of IO
  • 1 × SAMD10D13 leightweight ARM

  • Bitstream Configuration via MQTT

    flow05/14/2019 at 22:21 0 comments

    I finally managed to upload the FPGA bitstream via MQTT.

    At the moment I use a protocol in which I publish the bitstream split up into messages of 128 byte each into a different topic and let mosquitto (the MQTT Broker) ensure that they all arive. At the moment the bottleneck is the Serial Port between the ARM board and the configuration Controller but in the next days I am going to work on sppeding that up.

    Now I will start working on the bitstream that will go into the FPGA that configures all the other boards on the bus.

  • Ethernet is Working & a Nice Enclosure

    flow05/02/2019 at 22:32 0 comments

    I finally managed to get the ethernet chip running i suspect that the crystal had a bad contact. From there on I managed with the help of the pubsubclient library to get the thing talking. Also I managed to score a really nice enclosure for the project on ebay.
    I decided to use MQTT for the configuration of the system because it is so leightweight, easy to implement, and well established.

  • Some trouble with the CPU board

    flow04/30/2019 at 21:30 0 comments

    The first problem I had whil working on the CPU board is that I locked out my self. I should have added an erase button. Which was easily made good for with some hot glue.

    Now I am struggeling with the W5100 that I want to use for the ethernet communication and the upload of the bitstreams. The Oscillator doesn't start unless I touch the oscilator circuit with my finger. So I presume something is off with the capacitors. If somebody has debugged something like this before I would be happy about some pointers. (So far I never took to much care about Crystal resonators and they always worked out)

  • The Shield Board (Arduino-Compatible) works.

    flow04/28/2019 at 14:34 0 comments

    I just put together the first usefull Board that can go into the FBus. It has a SAM3X8 and Arduino-Compatible footprints for shields, so now you can hook up any shields to the FBus. Now I will start working on the ethernet interface. I hope that it soon will be possible to upload the bitstreams and firmware images via ethernet.

  • It's Alive.

    flow04/26/2019 at 22:04 0 comments

    A little bit of verilog

    module blinky(CLK50, PW39, NW39);
      input CLK50;
      output PW39;
      output NW39;
      reg [24:0] count;
        always @(posedge CLK50) begin
          count <= count + 1;
      assign PW39 = count[24];
      assign NW39 = count[24:13] < count[12:1];

    The SymbiFlow toolchain and a lot of serial interface debugging and the FPGA finnaly shows some life:

  • The Backplane PCB Arrived!

    flow04/25/2019 at 23:19 0 comments

    Today the Backplane PCB arrived. I soldered a few PCIe connectors and let me tell you soldering 4 times 164 pins takes quite some time... But I can communicate with the bootload Microcontroller! So it worked :-)

  • The Inverted Pendulum: Some Control Engeneering

    flow04/21/2019 at 14:16 0 comments

    At the moment I am home for Easter so I cant work on the physical parts of the project. Nevertheless, I used a little spare time to think about the control system for the inverted pendulum. I started off by constructing the equations of motion for the pendulum using Mathematica and transfering them to XCos my first atempt while somewhat asthetically pleasing took far to long to implement:

    Also I wanted to keep the process more open so I opted out of Mathematica and instead wrote a small Python script that uses the sympy library to construct the equations of motion using Lagrangian mechanics and generates the code to be directly dumped into a XCos Scilab function block. And TADDA it swings:

    Then I refreshed my controll theorey memories with this awesome tutorial: and implemented linearization and poleplacement for the controll loop in the same Python script:

    With that in place I was able to run the first simulation of the inverted pendulum in the upright position:

    In the beginning the pendulum recovers from beeing in a slightly of vertical angle. Afterwards it performs a controlled movement of the Wagon on which it is mounted forward and backwards.

    I am really looking forward to implement this in real life! :-)

  • Second Board Soldered & a Manual Stencil Holder

    flow04/17/2019 at 18:20 0 comments

    Unfortunately I forgot to select the option to get the solder stencil cut to size. So It was quite uncomfortable to work with. And on the first Board it often slightly warped away from the Board an caused solder paste leaking around the pads. I tried my best to hold the stencil down with my hands but one corner would always eventually lift. To combat that I laser cut a small U-shape from Plywood to have a more easy way to hold the stencil down. With that I experienced no more leaking solder pads.

    Probably I was just reinventing the wheel. Nevertheless, with this thing I managed to solder the second board and it turned out perfect except for two little tombstoned 0402. And there it is:

  • A Target: an Inverted Pendulum

    flow04/15/2019 at 20:12 0 comments

    Working on electronics only gets a little bit dry so I decided to make a small example project using the actual FBus system. I settled for the most popular example to apply control theory: the inverted pendulum. The first parts for it already arrived :-).

  • First Board soldered

    flow04/08/2019 at 22:34 0 comments

    The first Board is soldered :-). On this board I did not populate the DDR2 memory or the associated power supply to reduce the total points of possible failure.

    As a first test I flashed a bootloader on the SAMD10 and it worked :-). In the next days I will implement bitstream loading for the Lattice ECP5.

View all 11 project logs

Enjoy this project?



Antti Lukats wrote 07/13/2019 at 15:29 point

We have similar setup being used in customer projects, 64 lines in the backplane, one host board with ZYNQ7000, all slave boards having Lattice XO2. Flexible allocation of backplane signals between slave slots, in standard 19 inch rack.

  Are you sure? yes | no

flow wrote 07/14/2019 at 09:39 point

Oh thats interesting! Are you allocating the direction of the backplane signal during a configuration statically or do the data directions change within a configuration?

And do you try to run the designs in the different FPGAs sychronous?

(I am asking because these are the challanges on which I am currently working)

  Are you sure? yes | no

Antti Lukats wrote 07/14/2019 at 09:44 point

actually we have 2 different systems, one has "parallel bus" as your, there we have one large FPGA with set of IP cores, and and IP core to IO multiplexer, the slave have small FPGA that does IO muxing and some limited local processing, everything is synced here to the process in the main FPGA. The other system uses point-to-point backplane with 2 LVDS lanes from main CPU to each device slot, again all synchronized.

  Are you sure? yes | no

Tony.wu wrote 07/11/2019 at 13:27 point

I really like your project, I also have similar research, but my mechanical design ability is not good, there is no way to design the outer box, I don't know if you would like to share your mechanical structure drawings of the outer box, thank you, look forward to your reply.

  Are you sure? yes | no

flow wrote 07/14/2019 at 09:29 point

The outer box is an old version off a schroff europac, I did not design it myself...

  Are you sure? yes | no

edmund.humenberger wrote 06/06/2019 at 07:10 point

How about a brushless motor driver board with sensor interface?

  Are you sure? yes | no

flow wrote 06/06/2019 at 17:01 point

I have an 4 channel mosfet driver board (so that it can handle both stepper and brushless motors) in the pipeline.

I am planning to put neccessary sensor interfaces on a seperate card, because there is a wide variety of different sensors and I see no reason to fix the board to a single fixed one of these.

  Are you sure? yes | no

edmund.humenberger wrote 04/30/2019 at 20:09 point

I like the idea of this self configuring bus very much. The different cards need to identify them self to the other cards with their capability so that each card can configure itself in a way how it want to communicate with the other cards. Seems to be a hard problem. Each microcontroller on each card can rewrite the bitstream of the FPGA on the fly. 

  Are you sure? yes | no

flow wrote 04/30/2019 at 20:19 point

Yes that is the Idea! :-)

In order to keep the real-time critical communitcation and the setup communication seperated each card has a dedicated UART Channel over which the configuration Microntroller can communicate with the software that synthethises the bitstreams for the FPGAs.

What I have in mind right now is that the cards only advertise theire capabilities such as : "I have a 10MSPS 14bit ADC channel" and for the final project the user than wires up the different modules probably using some Python script. But you are right there is a lot of work to do on the bitstream synthesis part of the project.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates