Colorlight 5A-75B as a FPGA Development Platform

In this thread I want to discuss hardware designs and toolchains that could turn the Colorlight 5A-75B LED receiver card [1] into a usable FPGA development platform. In the start of 2020 people on twitter discussed the reverse engineering of this board which resulted in a GitHub repo with pictures, pinouts and example code.


The Colorlight 5A-75B is an interesting target because of its low price [2], DSP and SERDES capabilities, high IO count and pre-installed preipherals:

  • 1 25Q16 serial PROM for FPGA configuration
  • 2 1M x 16bit SDRAMs
  • 2 1Gb Ethernet PHYs

Enable Input

TL;DR without modding the board, the pins are output only.

The problem with this board is that all pins of the HUB75 connectors are connected to the outputs of signal buffer, meaning that they are all output only. If one were to lift the direction pin of the buffers and turn them into an input, they would output +5V to the FPGA which would kill it. Do not attempt!

My current approach [3] is to desolder the buffer ICs and replace them with PCBs that simply connects each input to the corresponding output.

Hardware Design


As a basis for hardware designs I measures the positions and angles of the connectors on the board and transferred them to a KiCAD PCB layout.


Since iceprog is a simple programming tool for FTDI-based Lattice iCE programmers, I added a FT2232H for programming (and maybe even debugging ?) capabilities.
It is directly connected to the JTAG interface of the FPGA. Additionally we could connect two pins for UART.


There are 56 individual signals available from the eight HUB75 connectors. I regrouped them into seven Pmod connectors. The ones on the side are spaced in a way that this board provides two double Pmods and three single Pmods.

Another Idea is to design a board for human interface devices. With connectors for video, audio and input devices (e.g. USB, HDMI, VGA, PS/2, LVDS etc.). This may require measuring delay in signals and tuning the length of the traces.


There already is a LiteX platform file [4] for the Colorlight. LiteX is written in Migen, but I would like to use nMigen.
Currently I’m trying to write a nMigen board file based on the LiteX Migen file.

If someone is interested, I can clean up and upload the CAD files to GitHub :slightly_smiling_face:

As a first time poster, I can only add two links and one image :confused: I add the other links and imaged in the thread.

1 Like

[1] colorlight-5a-75b
[2] aliexpress


1 Like

[3] chubby75/issues/37


1 Like

Hey @marble,

Thank you for sharing this. I love those tiny bridge PCBs to replace the buffers. Have you looked into castellated holes? If I see it correctly your solution solders under the board right? Essentially like A PGA (Pad Grid Array) but only two row? Castellated bridges might be easier to handle, but I guess if you reflow your adapters it probably does not change much.

I made a castellated board adapter before. It was an adapter from the TI JTAG connector to a normal ARM Cortex Debug connector. The pitch of the connector is 1.27mm so it is not as fine as those SOICs but who knows it might still be possible…

From that project I would recommend to manufacture the boards in 0.5mm or 0.8mm thickness instead of the standard 1.6mm thickness. It makes soldering and access of the castellations easier.

Additionally I think it might be worth it to make an adapter that orients the Pmods at the edge of a board. This would allow the use of dual Pmod boards.

What are your thoughts about syzygy connectors?


1 Like

I’m not sure what iceprog does here. That’s for ice40 based boards, this is an ECP5. Technically you could use it to program the flash directly but (1) those pins aren’t broken out and (2) you explicitly mention that it’s connected to JTAG. You’ll need something like Greg’s ecpprog instead or maybe openFPGA loader.


Hey @esden,

Have you looked into castellated holes?

I tried to do castellated holes, but no fab does them with such a small pitch. I guess the plating would be just ripped away when the router cuts the hole in half. Hence the current solution.

Most vias aren’t plugged. You also get a Moiré effect with the footprint pads below, which seems to be good enough for alignment.

From that project I would recommend to manufacture the boards in 0.5mm or 0.8mm thickness instead of the standard 1.6mm thickness.

Yeah. The ones in the pictures are 0.8mm or something - I bought the flattest option that didn’t increase the price.

What are your thoughts about syzygy connectors?

I think that would be cool, but also kind of overkill at this moment. Plus they are pretty pricey. I think, before moving to a better connector, the relative delay between each signal has to be measured and compensated for by meandering.

1 Like

Ah, you’re right. It’s all a while back.

I think I used openocd when I first flashed the ECP5 successfully. In that regard I think just about any USB-JTAG IC could be installed.
I personally have had good experiences with FTDI ICs, but also would like to have something more open source in it’s place.

Are there any “good” :copyright: open source USB-JTAG implementations? Maybe something with and STM32? To be viable it would need to be about as cheap as the FTDI, which is ~7€ :confused:

1 Like

I could add an STM32 running BMP as mentioned in Debugger Hardware

Or maybe I should remove all the USB stuff and just add a standard JTAG header…

1 Like

I just had a successful run with versaloon. I simply checked out v1.0 of the repository and flashed it to a blue pill board. After checking that the device get recognized by my computer with dmesg and lsusb, I connected the JTAG signals and 5V power.

I tested the setup with the pin-scan example. Since I had a different version of the board than the author did, I hat to make some changes to the code.

git diff
diff --git a/5a-75b/pin-scan/Makefile b/5a-75b/pin-scan/Makefile
index 2a870ce..a8978b6 100644
--- a/5a-75b/pin-scan/Makefile
+++ b/5a-75b/pin-scan/Makefile
@@ -7,7 +7,8 @@ top.json: $(SYNTH_SRCS) name.hex
        yosys -p 'read_verilog $(SYNTH_SRCS); synth_ecp5 -top top -abc9 -json $@'

 top.config: top.json top.lpf
-       nextpnr-ecp5 --25k --package CABGA381 --speed 6 --lpf top.lpf --json top.json --textcfg top.config --freq 65
+       #nextpnr-ecp5 --25k --package CABGA381 --speed 6 --lpf top.lpf --json top.json --textcfg top.config --freq 65
+       nextpnr-ecp5 --25k --package CABGA256 --speed 6 --lpf top.lpf --json top.json --textcfg top.config --freq 65

 top.svf: top.config
        ecppack --input $< --svf $@
diff --git a/5a-75b/pin-scan/ b/5a-75b/pin-scan/
index 5b6d44f..365443c 100755
--- a/5a-75b/pin-scan/
+++ b/5a-75b/pin-scan/
@@ -15,7 +15,8 @@ with open(sys.argv[2], 'w') as lpf, open(sys.argv[3], 'wb') as rom:
        for l in cr:
                if not l[0].isdigit():
-               if not l[7].isalnum():
+               # if not l[7].isalnum():
+               if not l[9].isalnum():
                if l[1][0:2] not in ('PT', 'PB', 'PL', 'PR'):
@@ -23,7 +24,7 @@ with open(sys.argv[2], 'w') as lpf, open(sys.argv[3], 'wb') as rom:

                name = l[1]
-               pad  = l[7]
+               pad  = l[9]

                lpf.write('LOCATE COMP "pads[%d]" SITE "%s";\t# %s\n' % (i, pad, name))
                lpf.write('IOBUF PORT "pads[%d]" PULLMODE=UP;\n' % (i,))

I also had to copy and modify an openocd config for the target platform

transport select jtag
adapter_khz 200

jtag newtap lfe5u25 tap -expected-id 0x41111043 -irlen 8 -irmask 0xFF -ircapture 0x05

svf -tap lfe5u25.tap -quiet -progress top.svf

The programming is then done with OpenOCD.

$ sudo openocd -f interface/vsllink.cfg -f chubby.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
adapter speed: 200 kHz
Info : Versaloon(0x15)by Simon(compiled on Jul 26 2020)
Info : USB_TO_XXX abilities: 0x00000208:0x010001E3:0xC0000007
Info : clock speed 200 kHz
Info : JTAG tap: lfe5u25.tap tap/device found: 0x41111043 (mfg: 0x021 (Lattice Semi.), part: 0x1111, ver: 0x4)
Warn : gdb services need one or more targets defined
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 lfe5u25.tap            Y     0x41111043 0x41111043     8 0x05  0xff
svf processing file: "top.svf"
Time used: 0m50s625ms
svf file programmed successfully for 620 commands with 0 errors
shutdown command invoked
1 Like

My current idea is to add the FTDI and the STM32 as well as a TC2030 footprint and a “standard ARM Cortex-M SWD and JTAG interface” (2x05 1.27mm pitch pin header).

To select between the FTDI and the STM32 I want to use a PI3USB102G. This is a USB 2.0 High-Speed switch with ESD protection. The control input will be connected to a pull-up resistor and a solder jumper.

1 Like

To prevent spamming this forum, I created a project on

1 Like

I assembled the first prototypes over the weekend. I found some mistakes and also released some magic smoke, but overall it seems promising.
Now there also is a GitHub repo containing the source and gerber files.

Currently I’m waiting for my new bridge PCBs to arrive. If they work out, I will also upstream them.
In that regard it’s also worth to take a look at this issue thread. Disasm came up with the brilliant idea to use flex PCBs and cut their edges off to turn the pads into castellated holes.

1 Like

In the Discord Stary mentioned this tweet by Claude Schwarz. He replaced the octal buffer drivers with SN74CBT3245APW octal FET switches.
According to the datasheet, they have a maximum resistance of 15Ω and propagation delay of 350ps.

On LCSC they only cost about 0.24€ per piece.
I recently ordered five panels of bridge PCBs with castellated hole for $81.97 (~70€) including shipping. One panel holds 100 PCBs. That puts the price at about 0.14€ per piece.
But since you only need to replace 12 bus driver ICs, it’s more sensible to order some FET switch ICs with your next parts order, instead of ordering 500 PCBs :smiley:

I forked the nmigen-boards repo to add a board description for the Colorlight + Adapter. To test this I wrote some (ugly) code that displays text onto these cute tiny HPDL-1414 sixteen-segment LED displays. There was enough space on the PCB to glue one of the small breadboards I had laying around in place.

The board description contains resource definitions for the HUB75 as well as for the Pmod connectors.

1 Like