Colorlight 5A-75E

[derekmulcahy]

I have a Colorlight 5A-75E V7.1 board, this is the board with 16 HUB75 connectors, and I am working on documenting the pinouts. It was going well and I used pin_scan to find the mapping for the HUB75, SDRAM, PHY, LED, BUTTON and flash pins.

I then realized that the pin_scan Makefile defaults to CABGA381 and the 5A-75E uses a CABGA256. I changed the Makefile and altered gen_lpf.py to use column 9 from the CSV mapping file. I cleaned, rebuilt and loaded the bit stream into the FPGA. It doesn't work! I don't see any UART output for the pins. Again, the CABGA381 compiled version works well.

I am perplexed as I wanted to provide an update to this project to support the 5A-75E but I don't know if what I have is reasonable. I have attached the document that I currently have for the 5A-75E.

Cheers, Derek

hardware_V7.1.txt

[nonarkitten]

Curious if this has any finer control on the 5V direction as well?

[derekmulcahy]

Pin 1 (DIR) is linked to pin 20 (Vcc) on all 23 74HC245 chips. So, I think that is a no!

[nonarkitten]

Ah sad. We need one of these manufactures to use a FET bus switch instead for level shifting.

[Disasm]

@derekmulcahy Thank you for the work! I converted your pinout into a CABGA256 pinout with the help of the official pinout description and some Python. Could you check that this pinout is valid? Note that I fixed pin names only in tables. hardware_V7.1_fixed.txt

[derekmulcahy]

@Disasm thanks for the pin translations. I was partially through the translation myself but I got bored. Everything looked good.

The two mapping files are consolidated and attached.

One addition, pin 6 on the SPI flash is CCLK, this is mapped to U3 for the 381 FPGA and N9 for the 256 pin. It is a fixed function for the ECP5 chip and wasn't found by pin_scan.

PHY0 and PHY1: When using pin_scan both RXC and ~RESET are mapped to the same pin (P4 for 381 and P5 for 256). This doesn't make much sense and needs further investigation.

Otherwise I think the file is getting close. Time to write some test programs...

hardware_V7.1.txt

[Disasm]

Oh, thanks! One small fix:

A 25MHz clock is available at 381 pin P6, and is also connected to both PHYs.

It's P6 in the 256-ball package. At least I suppose that's why my blinky works :) Also P6 in 381 has VCCAUX function.

[derekmulcahy]

Good catch. Looks like it is P3 for the 381 mapping and P6 for the 256-ball package. I plan to delete the 381 pin references from this file when it is tested. After all, this board does use the 256-ball package!

[derekmulcahy]

An update, the RXC and RESET lines for the PHY0 and PHY1 are connected together via resistors. I guess that during reset RXC is held low. RESET is connected to RXC on PHY0 via R100 and to RXC on PHY1 via R107. Seeing this has allowed the pins used for RXC to be identified. The updates are in the attached file.

The pins used for RXC are the same V7.0 board and it also has the same resistors. Copy/paste can be good!

hardware_V7.1.txt

[Disasm]

I checked all HUB75 pins and found a few mistakes.

• Connector J5 pin 2 is J5, but it's already used for the C signal (Connector J5 pin 11).
• Connector J9 pin 7 is F7. This pin is VCCIO0.
• Connector J11 pin 2 is F29. Doesn't exist in both packages :)

Other HUB75 pins are ok, I even checked each of the shared FPGA pins on each connector.

Additionally, headers of some tables don't correspond to the titles before the tables. For example, header is J1 Pin and the title is Connector J4.

UPD: found these pins: https://github.com/q3k/chubby75/pull/62/commits/f0013fc6fe8bd1db726ac8df2196629a4e485ebf

[Disasm]

I've updated the litex-boards platform file (https://gist.github.com/Disasm/a1065e609b65c688fc0a30a9cba92e89) and generated SoC with ethernet. SDRAM works (memtest passes), PHY0 seems to be working, PHY1 seems to not be able to receive packet (sending works). This could be due to the timing problems, but still suspicious. At the same time, with this SoC board heats significantly. FPGA and SDRAMs are hot. Buffers are hot and especially hot near the SDRAM chip. I don't know if it's ok or I'm missing something. With the stock firmware the FPGA chip is barely warm, all other ICs are cold.

[tomverbeure]

At the risk of stating the obvious: make sure all unused IO of the FPGA are set to input by default.

I didn't do this for my Cisco board initially, so it booted up with all IOs by default set to output, and it pulled a current 1.5A. After changing the IOs to input, it dropped to 120mA...

[tomverbeure]

More advanced: you could use some JTAG scanning tool with the original firmware to dump the values of the IO boundary scan cells, and see which IOs are set to input or output.

[Disasm]

I think that IO should be configured as inputs if I do not use them explicitly (and in this SoC I do not use all of the HUB75 pins). Probably in this mode they trigger a lot of switching inside the buffers, I should try to configure them all as outputs.

[derekmulcahy]

@Disasm I tried you Litex-boards platform file. It worked well. I didn't have any problems with overheating. I was having odd power supply problems until I powered all the peripherals (FTDI, USB Logic Analyzer) from the same USB hub as the color light. Litex boots and uses ~150mA, --with-ethernet uses ~60mA more. Would configuring the pins as inputs with a pullup or pulldown to prevent switching be a solution to your issue?

[Disasm]

That's super weird. I connected the board power cable through a cheap "charger doctor" and found that consumed power varies from time to time. At the moment I can get 30mA and 150mA with the same litex+ethernet gateware (I mean literally the same, I do not rebuild it). The power consumed is consistent during a single run, but different for different runs (I replug the power cable and reload the gateware). During my previous attempts I even got 240mA with (different) litex+ethernet gateware. At this point I observed significant heating. Everything is powered through the same powered USB hub.

UPD: Connecting through a long USB cable leads to 250mA consumption. Seems like the resulting consumption depends on the voltage provided through a cable. With lower voltage comes higher current. 0.03A, 5.1V 0.15A, 4.92V 0.25A, 4.83V

[derekmulcahy]

I think this issue is closed with the pull request #62