Categories

[SpiROSE] Driving the LED Drivers with the FPGA

This week was dedicated to writing the SystemVerilog code for driving the TLC5957 LED drivers. The first issue was to get some SystemC tests ready to use. While the tests where being written by someone else, I started writing the SystemVerilog code. Now the code is ready and have been tested on the drivers, but the timings are not correctly set, so the drivers are being incorrectly driven and behave pretty randomly.

The FPGA development have been delayed in order to get the schematics ready quickly. During the same time a more precise analysis of the available encoders have been done, including the mechanical restrictions, connector, communication protocol, etc.

Next week will be dedicated to the shematics and datasheets reading.

[SpiROSE] Mechanical construction, various tests and FPGA design

This week was full of various little tests and tryouts: Power input, Motors, LEDs,  LED Drivers, etc. It was also a week used for designing the FPGA internal architecture and final adjustments for mechanical construction.

 

Mechanical construction

The mechanical design have been updated due to the lack of some materials in our distributor. The design have been checked and validated back with the mechanics, and the materials have been ordered. The mechanics will start the construction on next week. The motor and his controller have been ordered too.

The updated mechanical design is available here.

FPGA Design

The FPGA architecture have been finished, including clock domains, I/O count, main modules definition, RAM layout, data input specifications, synchronization constraints and drivers control logic. The chosen FPGA (Cyclone III with 40KLE) have been validated to work with this architecture and next week will be used for starting developing on it, to check the timing requirements. The rotative base station schematics can now start.

A note about RAM: last week a basic estimation was done to see if an FPGA could internally store a whole 3D image, but the calculus was erroneous, which leaded us to think that the Cyclone III FPGA was capable of it. The reality is that it can store up to 18 ‘slices’ (we call these micro-blocks), so synchronization is needed.

 

Various experiments

The LED drivers have been soldered on breakout board, as for the LEDs, and some motors we had have been tested. The goal was to validate our choice of components. Due to mechanical construction starting soon, we ordered the final motor and controller just after the tests in order to have it when the construction starts.

 

Now the schematics of the rotative base station are ready to start, and the FPGA code have to be written.

See you next week for more details!

[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.