Digital display output options for >30MHz pixel clock

kuba

I was looking into avenues of digital display output comparable to the 100+MHz pixel rates we get for VGA (c.f. Chip's enormous portrait display). I've found several approaches, at vastly different complexity levels.

1. Faster HDMI using a TMDS serializer, e.g. TI's TFP410P goes up to 165MHz pixel clock (1.65Gbit per lane), see https://www.ti.com/product/TFP410 - $6 each in qty 100. It's easy to use, runs on 3.3V and takes 3.3V inputs, would take minimal changes to the VGA object. Takes either SDR 24-bit parallel input, or DDR 12-bit parallel input if pins are to be conserved. DE input line - high for video data, low for HSYNC/VSYNC and control signals. I2C interface exposes useful configuration registers. DE can be internally generated, based on programmed timings relative to HSYNC and VSYNC leading edges - something like a CRTC, except that you still have to provide video data when expected. Interfaces directly to an HDMI connector. Can be implemented in a day or so, once the chip is on a plug-in board.
2. DisplayPort using a generic serializer e.g. TI's TLK3131, up to 375MHz symbol rate, https://www.ti.com/product/TLK3131 - $14 each in qty 18. The VESA DisplayPort 1.2 spec is dense reading, but there isn't anything fundamentally Earth-shattering there other than the typical baroque over-engineering. One fundamental difference from HDMI is that the signaling rate is decoupled from pixel rate - there's additional pixel-rate-sync information passed along as control signaling. Took me several readings until it started to sink in. For P2, we only need a single data lane. Less of the spec applies than if you were, say, designing some generic FPGA IP for 4 lanes and a multitude of video and audio formats. Looks like a minimally functional implementation to show something on a DP monitor (or through a DP-to-HDMI converter) would take a couple man-months of focused effort, assuming good familiarity with the standard.
3. An HDMI (TMDS)-to-DP converter chip. Those only have abridged public datasheets, and you have to basically beg your way in to get the full sheet. I don't think that being on someone's whim to that extent is viable, so I only mention this because those chips can be easy to use - of course we'd need to generate fast HDMI first, so at that point you can get an external converter with one of those chips built-in, and call it a day. There are some parallel-to-DP interface chips out there. I looked at all that are still in production and had sent datasheet inquiries for each. Not too hopeful of hearing back.

DisplayPort requires two signal processing modes on the fast lanes - in addition to a slow AUX lane used for control traffic (think T1 D-channel except on a dedicated wire).

• For video ("data"), the bytes are scrambled (four CRCNIBs to update scrambler state, or a XOR with prescrambled half-long), then 8b/10b ANSI encoded using the data symbols (D), then serialized down the lane. Scrambler state reset points are well specified. Multiple cogs are likely required for 50MHz output of arbitrary pixels if 8b/10b encoding is also to be done on P2 side.
• For control signals, there's no scrambling, and the 8b/10b control symbols (K) are used - but those don't overlap with anything else that's common, so we can't directly reuse e.g. an Ethernet serdes, or an 8b/10b serdes for some other protocols. There's quite a few - every one uses a different set of K symbols, at most partially overlapping others, so no reuse can be possible - that's probably a feature, not a bug :(. Yeah, I read the all the specs I could find - no overlap with the minimal set of K symbols needed to support DP - not even minimally. Bummer.

Some serializers, like the mentioned TLK3131, support both 8b/10b-encoded and unencoded (raw, fast shift register) operating modes. Mode switching can only be done via the MII serial interface, though, and that runs up to 10MHz on that chip. It'd remain to be seen whether deriving MII clock from symbol clock would allow a deterministic switchover between 10b straight-through and 8b/10b D encodings, without generating invalid symbols - none of it is in the datasheet, since I bet nobody has ever used that chip for DP and thus there was no need to switch modes on the fly while transmitting. Other chips may be more cooperative in this respect. The one relevant hardwired mode control pin, called CODE , unfortunately only enables/disables the 1000Base-X PCS subsystem, and can't be used to control the 8b/10b encoding, and its timing relative to the serialized bitstream is not specified - seems like it's there to pin-strap the chip.

So, we have HDMI and DP, but we also can transport those over USB-C (without data nor signal translation!). Note:

1. USB-C doesn't imply superspeed USB signaling - a USB 2 high speed data path is sufficient IIRC as far as the USB side of things goes, and P2 supports that. You can have a USB-data-less power-only functionality of course, on either end of the cable.
2. Thus USB-C has mandatory PD (Power Delivery - a big misnomer) signaling used to establish all the other links, including power transmission, if any. This is a slow (300kHz bit clock) channel used to negotiate the function of all other channels/paths. Directly after connecting both ends of the cable, only this side channel can be active.
3. PD has an "escape" mechanism for vendor-specific messages, and those messages can be used to establish alternate modes.

An alternate USB-C mode is where the superspeed data lanes are configured for some other use. You could, technically, with two cooperating link partners, establish, say, RS-485 over each lane - the physical layer can be anything as long as it stays within the EMC and voltage limits for the superspeed data lanes. Those vendor-specific modes are supported by the standard by the way of a hand-off, but of course not further specified. You don't lose USB-C compliance just because you feel like running RS-485 on the same cable, that is. There perhaps can be some imaginative new uses of this aspect of USB-C.

Two "wholly specified" alternate USB-C modes of note are the HDMI and DP modes. They let you carry HDMI or DP physical layer over the USB-C cable. Negotiation is done using HDMI- and DP-specific messages - those are not a part of the USB spec, but are given in the relevant HDMI and DisplayPort standards (both behind a tall paywall).

I've inquired a bit and checked a bunch of devices with USB-C connectors on display at a few local electronics stores - USB-C HDMI alt mode seems useless. It's fully specified and can be used in bespoke devices, but you won't send video data to a monitor that way, since no monitor will take it. No new source devices I checked would successfully negotiate HDMI alt mode - an old laptop or two did, though. Only a couple off-brand TVs that had an unexpected USB-C connector in the back would successfully negotiate as HDMI alt mode sinks. That line of pursuit is dead unless you're implementing both the source and the sink.

On the other hand, USB-C DP alt mode is widely supported, and pretty much every laptop with USB-C supports it, and lot of PCs as well, although it seems that most often it can only transport video from motherboard-mounted GPUs (be it integrated or discrete) via motherboard-mounted USB-C ports. Plug-in USB-C cards don't generally support USB-C DP alt mode (at least nothing consumer-grade I had access to).

So, USB-C DP is a possibility as long as we can implement DP signaling. Thankfully, there is enough open source material out there to figure out the DP-specific PD (power delivery) packet exchanges needed to negotiate DP alternate mode with a sink. Google has BSD-licensed USB-C PD open source stack with DP alt mode magic baked in - I've adapted it to chat with various endpoints, it can be made to run on a small ARM MCU and coaxed into chatting via GPIO. Neither USB-C PD messaging nor DP AUX messaging has to be done at nanosecond timescales, and most likely could be done from SPIN, MicroPython, or what have you.

Those are the my thoughts so far. DP seems grotesquely overengineered on the side-channel side, especially next to, say, gigabit Ethernet. Speaking of that - after the DP deep dive, supporting GMII for 1000Base-X seems like it wouldn't be a stretch, but I'm not quite sure what would be the use other than low-latency transfers at low average throughputs, or something like high-resolution VNC that could be generated on the fly, or converted from something else (e.g. a digitized video input). With either 100Base RMII or 1000Base GMII, P2 could do some cool low-bandwidth but hard-low-latency things like low-jitter clock transfer via Ethernet. It'd need to run off an external VCO with PLL disabled, and could phase lock to a PTP grandmaster (probably down to a nanosecond or two).

Glossary: SDR - single data rate, input clocked on a single selectable clock edge (either rising or falling). DDR - double data rate, input clocked on both clock edges (rising and falling).

rogloh

I think option 1 with the TMDS transmitter is your simplest bet to achieve over 30MHz dotclocks if you wish to remain digital all the way through. Of course you need to burn lots of P2 pins for the parallel RGB output when done that way.

The other way which does work but includes some analog is to use the VGA->HDMI converters. In my VGA/DVI P2 video driver I've achieved 1080p output from the P2 that way and the converter boxes are dirt cheap (~AUD$14 IIRC, google CM201). Output looks reasonable and was stable. If you can determine the type of chip they use inside these boxes and they are available to use you could have one of those on your board. It also saves P2 pins too. Of course I know this is not a "pure" solution, but at the very least it is a readily achievable way to get high resolution P2 video output into HDMI display devices.

Wuerfel_21

I admittedly haven't tried any, but given my experience with LCD VGA monitors, I am skeptical of VGA-to-digital conversion without manual calibration. I've never seen a monitor calibrate clock and phase just right on it's own, always needed a checkerboard test card and/or manual adjustment.