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

Synchronization update

Today with Nathan we spent a lot of time rethinking the work distribution between the synchronizer and the led band controller. I won’t go into details because Nathan already explained it in his last post, but basically the synchronizer will have more work than expected because it will have to generate all the signals needed by the led band controller to output the right bit at the right time. Indeed since every led band has the same display pattern (the leds are all multiplexed the same way on the PCBs), the calculations can be made only once for each led band.… Read more

Let that sync in

After a number of interrocations on the FPGA architecture, we are back to the drawing board.

Indeed, Alexis pointed out that our previous design created a lot of redundancy in the led band controllers. The computation of the current controlled leds, of the current controlled colors and even of the current written bit can be mutualized between each LED band.

That’s why from now on, our synchronization module will have more duties. It will generate :

  • the SCLK and LAT signals (see this post about the LED driver)
  • the current angle
  • the row, color and bit to be sent at any moment

But what does the led band controller do, then?… Read more

Led Band Controller new architecture

In this post, I detailed a new version of the global architecture. In this one, I will detail the V1 of the led band controller architecture.

Led band controller architecture

This version is fully implemented and FC Setter, Multiplexer and Memory submodules were successfully tested.

However, during a small meeting with Alexis, he explained there is a problem in our architecture. Indeed, every submodule is synchronized with SCLK even if it is not completely a clock (this “clock” can be switched off). However, the angle signal is not synchronized with it but with the FPGA clock. So we have two clock domains which can lead to issues.… Read more

V1: Led Band Controller

First organization

I implemented the first version of the led band controller. We divide this controller into 4 submodules:

  • FC Setter: This submodule is used to set the driver FC register
  • Mux: This submodule takes the current led, color, angle, and multiplexing and returns the corresponding address
  • Memory: This submodule represents the double buffer of the controller
  • GS controller: This submodule is used to set the SOUT signal


We have to test this first implementation thanks to a testbench. Firstly, we will test each submodule independently. The FC Setter has been already successfully tested.

FPGA architecture, the end of the trilogy (it maybe is a prelogy we don’t know)

In an FPGA far far away

Since the last episode, a lot of drastic changes occur in the FPGA architecture.

The new global architecture


Those three signals are now generated by the SYNC module. This reduces the number of GCLK, LAT and GCLK sent outside the FPGA. They will be duplicated thanks to clock buffers on the “highway” PCB.

We decided to realize this change to reduce the number of pins used, this will make the main PCB easier to route. Moreover, to ensure proper functioning, the 20 Led band controllers had to send the same SCLK and GCLK and to send all the data for the following LEDs when the previous ones are displayed.… Read more

Eat to live or live to eat ?

The power supply is extremely important and is quite complicated in a Phyllo since there are so many PCB as well as several voltages needed.

Capacitor reliant power supply

We have 79 LEDs working under 600mA which sums to 48A. As we flash 30 times every second and each flash lasts around 100us, the LEDs are on at most 0,3% of the time. Thus the average power supply needed is 0,16A.

We have decided to rely on capacitors to fully provide the LED power supply. There are two main reasons for this choice. First, the LED are switched off most of the time.… Read more

If at first you don’t succeed, try, try again

The roller coaster of the marbles tests

Last time, I wrote on this logbook, we were happy, we find a way to control our marbles without a side effect. But we did not think about one thing. With two marbles, our assembly plan works, however, with 9 marbles, it does not.

As you can see, when we cut the current, the marbles came back to another position

On Friday, after this discovery, I was thinking about this problem in my car: We need to keep the marbles near the metal because, without this, they will affect each other. On the other hand, we need to keep them far from the coils since we need to have some distance to make them flip.… Read more