ECPi Clocks

In order for the ECP5 and the RPI0 to work together their pixel clocks needs to be synchronized and in phase. If the pixel clocks are even slightly different frequencies, over time they will drift apart, there will be too much or too little data provided, and the HDMI timing requirements will be violated. The image may scroll and wrap. If the signals are out of phase, the setup and hold times will be violated leading to metastability.

For low frequencies the ECP5 can just use the RPI Zero's pixel clock. By the time it runs through the ECP5's clock tree, there will be a phase difference, but the ECP5 has dedicated circuitry to correct for that.

This page describes the different standard HDMI screen sizes, the pixel format and the required pixel clock frequency.

If that approach does not work, one could transmit the RPI Zero's oscillator to the FPGA, and have both chips generate clocks in phase at the same frequency. In this case, there are two relevant clocks: the oscillator and the pixel clock. The RPI0 19.2 Mhz oscillator can be published on general purpose clock ports such as pins 4, 5 and 6. Ideally, it should be input into the dedicated FPGA clock input ports from which it is fed directly to the PLL. It can also be routed through the FPGA fabric, but the quality degrades. Since the IcePi Zero does not hardwire the RPI0 oscillator output port directly to the FPGA PLL input port, we will be sending the signal through the fabric.

Once the two chips share an oscillator signal, we need to synchronize their pixel clocks which are generated by the two PLLs. PLLs work by first multiplying the frequency and then dividing it. The RPI0 PLL works by first multiplying the oscillator frequency by a fractional number up to many GigaHz, and then dividing it. It can be divided 3 times. The ECP5 FPGA PLL is more limited than the RPI PLL. The Lattice FPGA PLL documentations says that it also multiplies the oscillator frequency by a number but only by integers from 1 to 128. The resulting signal should not exceed 800 Mhz. That signal is then divided by a number between 1 and 128. To keep the two pixel clocks synchronised, we need to use the same multiply and divide frequencies. The resulting Pixel clock frequency should then be as close as possible to the number specified by the VESA display standards.

A 640 * 480 HDMI has a pixel clock of 25.175 Mhz. Look at the Discrete Monitor Timings (DMT) column. The RPI clock is 19.2Mhz.

This tool shows us that if we multiply by 21 and divide by 16, we get a frequency of 25.2 Mhz. Quite close to 25.175 Mhz. It is quite confusing because they call them frequency dividers, they are dividing each square wave into multiple square waves, but they actually increase the frequency.

The good news is that we can set the RPI display frequency (page 5) to be a legal FPGA frequency, and it should generate the correct multiplies and divides. We can then query what the frequency is.

vcgencmd measure_clock dpi

If you are not sure what are the legal pixel clocks, here is the video timing calculator.

The ULX3S ECP5 VHDL DVI RTL also provides some hacks if the default PLL values do not work. I wonder why those hacks work.

The ECP5's PLL does include phase adjustment circuitry, so its pixel clock can be in phase with the RPI0's output pixel clock.

There is also an issue that it may not be possible to both publish RPI0 RGB788 and the oscillator signal at the same time . The documentation warns about this,focusing on the PWM. and SPI signals. Some testing and more reading will be required.

There may be an issue with how the clocks are generated.

And of course how to configure displays has changed. I am not at all sure that one can switch one of the pins to be a clock gpio. Maybe this Korean pages says what needs to be done.

The first project will be to connect a RPI0 to an oscilliscope and see if the data is available. Can anyone recommend a USB 3 oscilliscope? Maybe time to join hackerspace Krakow.