The walking LED

I started to work on the SOM with Romain a few weeks ago. My objective is simple: we need to be able to test our modules while we wait for our PCBs.

It’s alive !

For this purpose, I took my favorite necromancy book and proceeded to revive CyL3D.

I used this opportunity to get familiar with the tools we use to program the FPGA. I forked the reference project from Aries and tried to communicate with the drivers using only the FPGA.

However I was not able to control the drivers properly, more debugging has to be done. In order to accomplish this debugging, I need to control the our modules using the HPS.… Read more

Let’s test all the benches !

Good news today. I completed the testbench connecting the synchronizer and led band controller modules.

This global testbench allowed me to discover and fix new bugs, mainly in the synchonizer module. Everything seems to work as intended now.

The test consists in writing a random frame of data on the led band controller and checking if the simulated driver contains the proper data at the time it should be displayed.

I also tried to change the multiplexing groups, which is an important parameter we will have to set later, and everything still works. I only hope we won’t have too many surprises on the finished product.… Read more

FPGA/HPS: to pin or not to pin?

After talking with Tarik, it seems our approach to FPGA/HPS communication was a bit off.

We wanted to use one data bus for writing on the LED band controllers and use GPIOs for the other signals coming from the HPS. It turns out that the GPIOs of the HPS cannot be directly connected to the FPGA, and according to Tarik the workaround are a bit sloppy.

So instead we decided to use the second data bus to write on registers in the FPGA, which will create the needed signals. The first bus will stay dedicated to the DMA module which transfers RAM data to the LED band controllers.… Read more

Simulacra and Simulation

I’ve been working for a few days on a global testbench of the system. I am making progress while at the same time integrating the fixes and design changes we decided to make.

This is almost done. Simultaneouly, Romain tests the behaviour of our module on a DE1-SOC dev board, everything is looking good so far.

It’s good to see the synchonization music in action.

QsIssues

After having tested the implementation of the Led Band Controller. I decided to create an IP on QSys. However, we had some problems with that.

Localparam issue

The first problem is a consequence of the use of local parameters. Every interface signals which depend on a local parameter have a length of -1 like angle for instance:

parameter NB_ANGLES = 128;
localparam ANGLE_WIDTH =   $clog2(NB_ANGLES);
input wire [ANGLE_WIDTH - 1:0] angle;

So I would like to know if someone knows how to deal with this problem.

hps_io conduit issue

This problem is a smaller one and has a way to fix it but it is not very clean.… Read more

Make Led Band Controller Great Again

I finished programming the Led Band Controller and its testbench.

Test realized

I realized different kinds of test:

  • Writing test only: this test is here to confirm we can write correctly in both buffers. This test writes random values in the RAM.
  • Read test only: this test is here to confirm we can read correctly in both buffers. This test reads 1000 random bits in the RAM.
  • Writing and reading test: This test is here to confirm we can read and write at the same time in the RAM. Each buffer is written with random values while the other one receives 768 random access.
Read more

Sync me a song

The implementation of the synchronizer is done. The architecture did not change much from this post.

I did unit tests on the submodules of the synchronizer. However a question came to my mind when it comes to testing the global module. How to test such a module without basically reimplementing it in the testbench ?

For the moment I just took a look at the output and checked that it seemed correct. Here is a look at the little music it produces:

Turn timescale
128th of a turn timescale
One multiplexing group writing cycle
One bit for each LED writing cycle

Next, we will have to test if the sync and led band controller modules play nice with each other.

There’s some sync inside you, it’s hard to explain

The synchronizer module

As stated in my previous post as well as Salomé’s post, the synchronization module has to do some heavy lifting.

It must indeed control the timing of data sent on all led band controllers. Basically, we need two state machines: one for the function control, the other for the grayscale data. I started to implement the GS state machine today, but this will need extensive testing.

Furthermore, we need to generate the essential SCLK and GCLK signals (see the led driver description), this is done using two clock dividers. I implemented this module, but the division factors are still to be discussed.… Read more

New implementation

I implemented the new version of the led band controller by following the new architecture explained in this post. This version is simpler than the previous one. With the new version, a huge part of the computing is inside the Synchronisation module.

Small problem with the angle

We split a turn into 128 parts. However, we have 20 PCBs and 20 doesn’t divide 128. 128/20 = 6.4. So we decided to take the nearest integer for the ANGLE_PCB parameter of the Led Band Controller. The worst case is a difference of 0.4. This represents a difference of 1.125° and that represents for the outermost PCB a gap of 1.8mm… Read more