[SpiROSE] no more EIM and we now have SystemC for testing

Hey, this week we read a lot of FPGA and SBC documentation. The goal was to be sure our project was feasible with the components we chose. We also validated many points on our design.

Choice of RGB versus EIM

It appears that we can’t use the “fast GPMC-like interface”, also known as the EIM on the board. Fortunately, as Tuetuopay explained it, the RGB is doing very well for what we ask it for.

The reason for not using the EIM are very simple : it doesn’t go on the MXM connector. Dot. So now we take a definitive stance on the choice of the communication bus from SBC to FPGA.

SystemC for testing

As written in our previous posts, we were trying to use Verilator as a compiler to SystemC. It is now an almost finished task. Each SystemVerilog file is built with a SystemC testbench and we are currently working on finishing a SystemC TLC5957 driver model and associated utils to produce test sequences and a way to test our driver and LED with C program directly, so as to validate everything. Tests will be done before the end of the week and we have a solid knowledge of the behaviour of the TLC5957.

Only one or two points are still beyond our understanding : the behaviour of XREFRESH also known as auto-refresh is part of them for instance, but we have good hopes to assert its behaviour with the previous library.

The Verilator makefile won’t produce correct dependency files too, but it will be fixed by replacing it by our own rules.

Next steps

There have still some issues with the SBC as it can’t do what we were expected at first.

Next week, we have to finish the tests quickly so as to integrate the FPGA parts into our project. After that we will fix the SBC issue by either finding a way to do what we want (openCL, CPU parts) or by replacing it by another CPU-only algorithm.

[SpiROSE] Continuous integration and the FPGA story

This week, we put a conscientious effort in making the project eventually start its journey in a more peaceful way. We were quite pressured by the choice of the FPGA and SBC as it was impeding the rest of the project and its existence. Now it has been fixed, we can really start to think about the next tasks: developing software and tests.

Even if it is still not perfect, we spent some time in configuring the continuous integration, designing the different steps for each piece of our software. As I spent most of the week doing code review (and FH work about happiness at work, which made me happy about ROSE), I highlighted some points where it failed, like some commits accepted by the tests although some files were missing, or incorrect style not failing the CI, or that the file organization in some subprojects weren’t practical for the integration of tests.

Two things are still missing. On the first hand, we have to save the artifacts so as to show demo easily, but we need more code so that it is useful and easy-to-follow manuals about how to use these artifact (flashing, running configuration, etc.) We expect to have this quickly for the LCD screen and renderer demos. On the other hand, we still don’t have very precise tests on our software, but things are to change quickly as we are writing simulation code in SystemC for the FPGA.

The idea, given by our teachers, is to use Verilator, a SystemVerilog-to-C++-library compiler, to put our FPGA controller into an environment with a simulated SBC input and simulated drivers so as to produce an output image. We will be able to cross-check the protocol used by the drivers in poker mode and check timing constraints. The SBC will generate sample image in the future and we will be able to check that it is correctly rendered by the FPGA.

To use Verilator, we have to:

  • compile each .sv file into a library (or only source/header files)
  • create a top file in SystemC which integrates each piece that we connect to the FPGA
  • monitor the input and output of the FPGA through SystemC stub modules

Eventually, we have to find a way to do the same on the real FPGA so as to have host integration tests.

We received the LED and the driver on Friday, so we didn’t try another experiment of the POV effect, but it will come quickly this week.

[Little Brosers] Finalize the Makefile and setup the CI

Hello there!


Guess what ? This week i’m writing my article from Madrid ! So let’s sum up what happened this week int the Little Brosers project, or at least, what I worked on.


This week was all about designing a compilation environment. First we started from the Nordic’s SDK examples. It gave us a functional Makefile compatible with the design we had in mind.

First idea was to put all make targets (devkit targets, c++ simulation target, custom Little Brosers PCB targets),  in one Makefile. However, it seemed simpler and cleaner to have a Makefile per platform. Thus we now have two Makefiles. One for building a .elf for the DevKit and another one for the C++ simulation.

Those two pick code from three folders:

  • hw : All code here is hardware dependent
  • core : All code here is hardware independent. It’s basically merging Merkle trees algorithms and cryptographic code. No main.c/.cpp should exist here.
  • sim : All code here is used to test the core folder C code. It allows us to get ride of BLE communication constraints to test algorithms.

The C++ simulation Makefile also comes with the linter related targets designed by me and Guillaume Lagrange.
Those are used by ourselves (programmers) before pushing our code and also by the CI to test the code style.

I worked a lot on the C++ Makefile to allow it manage automatically dependencies and put all the .o and .d files in a “build” sub folder. The objective was to never create any file in the src/ folder of the project. Indeed, we have to keep in mind that other Makefile will read files in the src/ folder.


Continuous Integration

This week was also about setting up the continuous integration using GitLab and Docker. This job has been shared between all group members. I took care of the CI artifacts and C/C++ compilation stages. Other group members took care of CI for python, linter and Android mobile app.

See you next week from home this time 🙂

Antony Lopez