FPGAs for the average engineer

October 4, 2016

You know Raspberry Pi, Arduino, Throw them away, these are toys for children. System on Chips are for adults.

Ishtar Plasmaantenne

FPGAs to power a plasma source

I am kidding, I love the Raspberry Pi, but what the SoC offer opens a new dimension. Let’s take the example of the Red Pitaya: its two main features: A zynQ 700 which combines a FPGA with a double core CPU and 2ADC-2DCA at 125 megasamples per second which make you possible to receive and emit signal in the MHz range. For a price of around 300 euros. This means first that you have a fast digitizer available and you can play in the radio range. And second, this digitizer is connected to a FPGA so that you can do processing operations like FFT, filtering and so on at MHz speed! This is really a great tool, not only to learn but also for practical applications. I use it for instance to generate a signal, which is amplified by a 1kW amplifier and injected in a plasma to investigate the propagation of waves in it. This is super easy to code in C and python, you can use the GPIO to get trigger signals or activate other systems, you can integrate easily in a global control system. I use it as well to measure high frequency instabilities in a tokamak plasma with a realtime FFT to reduce the required amount of data to store.

In standard, it comes with a free version of Vivado (i.e. missing all high level features but fine you do not really need them). The most difficult part is to install it and to support its xxx GB of required space. The program itself is not buggy (at least, not at the level I use it) and you can really learn how to code hardware in Verilog or VHDL: this is rather exciting when you understand how it works and that you start to see gates and flip-flops through the code.

The big advantage of the Redpitaya is that it is open source. Vivid and Xilinx provide also a lot of documentation. So, when a problem occurs (which happens every two minutes at the beginning), you have resources to find the solution rather easily. I would like to give here the most interesting links where to learn about the hardware:

  • Red Pitaya Notes by P. Demin: this is the big big big reference. There is a bunch of interesting projects, with SDR, even nuclear magnetic resonance and a clean, version-controlled method to manage the FPGA code and the associated linux ecosystem.
  • Vivado’s youtube tutorial by M. Sadri: everything about Vivado from simulation to debugging. It takes time to get through them but this is no loss of time
  • Building Linux on Zynq: this basically teaches you how to install an embedded Linux and the roles of the different components from the boot to the shell.

Beyond that, you can start to have very interesting stuff: building bare metal applications which do not require an OS, you can try to use Rust to gain in security and develop your own flexible and optimized PLC that suits your needs and not the bank account of big instrumentation companies.


A glimpse in the future of scientific publishing

February 19, 2016

You have certainly heard about the discovery of the gravitational waves. There is of course the press coverage offering the big picture to a wide audience. Maybe you were curious enough to dig a bit more in the details of the measurement. The natural way is to read the official scientific publication under the form of an article in the Physical Review Letters. Usually four pages long (here a bit more, probably due to the importance of the discovery), rigorously written, based on numerous references, in a very concise but accurate style. Briefly, this is the summum of publication in physics.

But this time, the authors have released their results in another form: a Jupyter notebook. You can find the result here. Do you see the difference? Yes, it is interactive. You can just follow what the authors wrote, but you can also modify the code, do tests, torture the data. Compare both publications and try to see where you understand better. What is interesting is that you do not see only a finite product but also a big part of the process to reach it. It is a big progress on the road to reproducibility and a great instrument to learn a topic (did you notice that you have sounds included in the notebook?).

Of course, this is a first step: several aspects can be improved but Jupyter offers already a vast potential to enrich the publication process. But all the same imagine one big potential: Jupyter is based on a three tiers architecture: a kernel to do the calculations, a frontend in html/javascript (with a backend.js to insure the communication with the kernel) and a server based on Tornado (with ZeroMQ for the communication with the kernel). In the present example, the LIGO team released only a notebook which is self contained: it needs only standard libraries and can run with python kernels available with the Jupyter distribution.  The data are independently downloaded through a server. Now imagine that the team gives access, in addition to the notebook, to a kernel equipped with their specialized libraries and all the tools they use for refined analysis; a kernel which has directly access to the data, all the data, not only the good ones. So the notebook, instead of connecting to the local kernel, connects to the remote kernel. In this case, and if you have the required experience, you are able to work almost in the same conditions than the discovery team.

One step further, imagine that you can comment below each cell, compare your modifications with the ones brought by other persons on their own version of the notebook, you will increase and (if the noise controls are good) improve the level of discussion on each paper. These extensions could be based on an extension of Jupyter Hub, which manages from one single point the access to notebooks for a group of user.

One last step in the future and you imagine that the kernel, instead of being a coding language, is a machine: a raspberry pi, an arduino, a digitizer, the controller of an experiment. Instead of programming code, you program remotely from your notebook. It is a bit far fetched for the moment, but imagine that you can enter your own program of observation for LIGO directly from the notebook. The kernel takes in charge of queuing the requests from all the notebooks, the experimental team prioritizes these requests and you get notified when the results you asked for are available. Science from your bed!

This is the kind of stuff that Jupyter starts to make possible. And don’t be surprised, the futures comes very fast.

Scratching the surface of coding

February 9, 2016

I am playing with my children with Scratch, the famous graphical intuitive programming language from MIT and I must say that I am impressed. First, impressed by the quality of the interface and the capabilities of the language. Second, impressed by how fast it helps children to learn the programming patterns of visual, event-driven languages. I mean, when you are able to code in Scratch, you are basically able to code in Labview. It is why hardware manufacturer starts to use similar types of language to set up their hardware (see for instance the redpitaya).

What makes attractive, in addition to its intuitive approach of programming structures like events and loops, is its library of sprites, backgrounds and sounds, which avoids to create them and to directly focus on their interaction.

OK, it is a language for learning and it may be painful in the end to move icons to create mathematical expressions. But, again, it does not disturb thousands of Labview developers who do that on far more complex architectures. I am not a big fan of these graphical methods for professional development (try to check your code when you do not have a 20 inches screen with Labview installed) but it is totally funny to help children to learn. So, I recommend it warmly.

It is available on the Raspberry Pi with direct manipulation of the GPIO signals, which opens the access to the real, physical world. And it is really fascinating to see how the children (and I) enjoy to see the LED blink when the ball hit the wall in our improvised Pong. However, the interface is not yet polished: the signals are accessed through broadcasted messages and have complicated names (try to explain to a non english-speaking child what gpio10off means!). But I am pretty sure that it is a question of months before we get an interface naturally integrated in Scratch.

To conclude, if you want to become a Labview developer and do not know how to code yet, start with Scratch.

%d bloggers like this: