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

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

Integration Schrödinghurts

Major headache with Guillaume today.

We plan on integrating the voxelizer, the 3D simulation and the remote control of LitSpin in one program, LitControl.

While trying to integrate the voxelizer in the 3D simulation, we encountered a nasty bug. Only on some computers, and only when not debugging, the result of the voxelizer is wrong. A nice Heisenbug.

To add to the list of issues, we use opencv in order to extract the frames of an animation and it turns out that the packets are a mess between the different linux distribution (namely arch and ubuntu). Therefore we will probably include opencv as a submodule.… Read more

Highway to hell

Listpin has three types of PCBs:

  • The main PCB, the head
  • The LED bands, the fingers
  • The highway, the spine

The highway connects the main PCB to the LED bands and contains clock buffers in order to duplicate signals while keeping integrity.

I have had a hard time figuring out how to route this PCB. It is a very dense graph of signals that must cross each other. Since the PCB has to be large (over 25 cm in diameter), the long traces adds crosstalk problems to the equation.

An attempt…

After talking with Alexis about this issue, it turns out that the autoroute function will be useful here.I… Read more

FPGA architecture, episode 2

The architecture of the FPGA has evolved since the last post.

General architecture

First, since we don’t plan on controlling the rotation speed from the HPS anymore, this feature has been removed from the architecture.

Moreover, the SCLK and GCLK are now generated by each of the 20 LED band controllers since we have enough ouput pins on the FPGA. This results in a simpler design and better signal integrity on these two signals.

Each LED band controller controls a LED driver. More information on the way this driver works can be found on this post.

For the inner memory of the LED band controller we use a dual port, dual clock synchronous RAM, which is proposed in Intel’s recommended HDL coding style for memory inference.… Read more

A first look at the FPGA architecture

In order to synchronize the LEDs and create a persistence of vision image, we use a CycloneV SOC.

Here is a first idea of the architecture we might use :

The ARM processor fills a buffer with the next image to be displayed, that is then swapped with the second buffer. It can pull this image from the SD card, or from another source such as the text printing function we plan on adding.

The full buffer is then accessed by a Direct Memory Access (DMA) IP that then sends the relevant cylinder (32 * 128 pixels) to each LED band controller that is then stored in their memory.… Read more

Ah, yes. Stereoscopic vision.

This is a follow-up to my previous article, in which we explored the choice of PCB placement in order to get an optimal visibility.

My previous analysis only covered the case of a punctual point of view. However, most people have two eyes, which provide a double point of view and could increase our coverage of space. It is to be pointed out that a point of space seen by one eye does not provide depth information to the brain, however let us assume that our image perception is smart enough to overcome this limit.

In the following simulation, we used a typical eye distance of 6 cm.… Read more

Choosing a shape

As stated in this previous post, we have to compare different PCB dispositions to avoid blind spots. We soon came to realization that we would not be able to get rid of blind spots with our design, but it is possible to study the different ideas we came up with in order to mitigate this issue.

That’s why we created a python program that can simulate :

  • blind spots created by PCBs hiding each other
  • the variations of brightness due to the fact that LEDs can be seen at an angle (which is what created the dark center zone in CyL3D, which we are trying to get rid of)

Stairs : an iteration over CyL3D’s design

To avoid the issue of a dark zone due to all LEDs facing the observer at an angle in the center zone, an idea was to make sure that all LEDs were not facing the same direction.… Read more