ECPi Details

ECPi Clocks.    View      

All you will need to know about the clocks on the Raspberry Pi Zero and the ECP5 FPGA working together. Right now, I still need to know more!

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 slightly different frequencies, they will drift apart and the HDMI timing requirements will be violated. There will be too much or too little data provided. The image will scroll and wrap. If the signals are out of phase, the setup and hold times will be violated leading to metastability. To deal with the phase problem, one could do Clock Domain Crossing (CDC) with Fifo queues, but I suspect that it is easier to just align the clocks on both chips using the FPGA's phase adjustment circuitry.

There are two relevant clocks: the oscillator and the pixel clock. The RPI0 19.2(?) Mhz oscillator can be published on dedicated clock ports. 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 PLL clock input port to the RPI0 clock output port, we will be sending the signal through the fabric.

Once the two chips share an osciallator signal, we need to synchronize their PLLs. PLL's work by first multiplying the frequency and then dividing it. The RPI0 Pixel clock is generated by first multiplying the oscillator frequency by a fractional number up to many GigaHz, and then dividing it. The ECP5 PLL is more limited than the RPI PLL. The FPGA PLL 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.

The RPI0 OS calculates the PLL multiply and divide numbers based on available information. Setting FPGA compatible values may require hacks to the RPI0 Linux Kernel. The ULX3S ECP5 VHDL DVI RTL also provides some hacks if the default PLL values do not 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.

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.

Over time, I expect that this page will be expanded with more details. Particularly with the different screen resolutions. and their required PLL settings. As I read lots of different documents, useful bits and pieces will be found and added to this page.

Raspberry Pi Chips.    View      

This page evaluates the Raspberry Pi Chips from the perspective of a MIPI CSI to DPI bridge. Turns out they all work fine.

RGB788 Works on all RPI chips.

The gpio directive allows GPIO pins to be set to specific modes and values at boot time in a way that would previously have needed a custom dt-blob.bin file. Each line applies the same settings (or at least makes the same changes) to a set of pins, addressing either a single pin (3), a range of pins (3-4), or a comma-separated list of either (3-4,6,8).

GPIO Documentation

BCM2835 used in the Raspberry Pi Zero, Raspberry Pi Zero W, Raspberry Pi Zero. The data sheet now does not even list the alternative functions.

RP3A0 used in the Raspberry Pi Zero 2 W, Raspberry Pi Zero 2 W with headers. The GPCLK0-2 overlap with the DPI0-2. Are those he high order bits, and there is a problem, or the low order bits and all is well. But it does not matter, they do that thing where the frequency jumps by 1 bit.

BCM2711: used in the compute module 4. Datasheet The GPCLK0-2 overlap with the DPI0-2. Are those he high order bits, and there is a problem, or the low order bits and all is well.

BCM2712 is the 16nm application processor used in Raspberry Pi 5, 500, 500+, and Compute Module 5.

Here is the documentation

Raspberry Pi Zero or Zero 2W?.    View      

This 12 minute video is an excellent technical comparison of the two products.

Raspberry Pi Zero Details.    View      

Lots of technical details and links about the Raspberry Pi Zero.

There are multiple versions of the Raspberry Pi Zero (RPI0). We recommend using the 32 bit $10 Raspberry Pi Zero which has one BCM2835 core, running the ARM1176JZF-S cpu and using these peripherals. One core is enough for this application. It is the GPU which does all of the work.

The RPI0 has a 19.2Mhz Oscillator which can be read from the GPIO clock ports. I cannot find the documentation for how the HDMI clock is generated. Maybe the oscillator is divided to several giga herz and then multiplied to the required hdmi pixel clock frequency.

More information about the internal details can be gained from the [C++ Circle library] (https://circle-rpi.readthedocs.io/_/downloads/en/48.0/pdf/#24#6) for bare metal RPI applications.

You could also choose to use the $15-20 Raspberry Pi Zero 2W w which has 4 cores using more power, but it is a 64 bit machine so its code takes up more space leaving less room for your application. Designations "H" or "with headers" means that the part comes with presoldered headers.

The Raspberry Pi form factor header has 40 header pins, with 12 power and ground pins leaving 28 pins for the 24 bit DPI output, clock, horizontal sync, vertical sync and blank. That supports RGB888.

Almost Perfect! The problem is that then the RPI0 and the FPGA are in different clock domains, and will drift apart. HDMI has tight specs, they cannot change or one risks loosing the lock. Over time the image would drift up or down on the screen and wrap. Not good. To keep the two chips in phase, they need to be driven by the same oscillator.

RPI0 can output a low-jitter 19.4Mhz clock on 3 of the low order pins. That clock can be routed to the FPGA's PLL. So in practice the MIPI CSI to FPGA DPI bridge allows RGB788, RGB878, RGB887. SInce humans are more sensitive to green, it is recommended to use either the blue or red low order pins for the clock. There is a lot of blue in the sky and in the ocean, so we are choosing red for the 7 bit color.