[qwezxcrty]

Not an expert in communications. Would the SerDes be the new bottleneck in the approach? I imagine there is a reason for serial interfaces dominating over the parallel ones, maybe timing skew between lanes, how can this be addressed in this massive parallel optical parallel interface?

[to11mtm]

> timing skew between lanes

That's a big part of it. I remember in the Early Pentium 4 days, starting to see a lot more visible 'squiggles' on PCB traces on motherboards; the squiggles essentially being a case of 'these lines need more length to be about as long as the other lines and not skew timing'

In the case of what the article is describing, I'm imagining a sort of 'harness cable' that has a connector on each end for all the fibers, and the fibers in the cable itself are all the same length, there wouldn't be a skew timing issue. (Instead, you worry about bend radius limitations.)

> Would the SerDes be the new bottleneck in the approach

I'd think yes, but at the same time in my head I can't really decide whether it's a harder problem than normal mux/demux.

[fecal_henge]

SerDes is already frequently parallelised. The difference is you never expect the edges or even the entire bits to arrive at the same time. You design your systems to recover timing per link so the skew doesnt become the constraint on the line rate.

[bgnn]

one can implement SerDes at any point of the electro-optical boundary. For example, if we have 1 Tbps incoming NRZ data from the fiber, and the CMOS technology at hand only allows 10 GHz clock speed for the slicers, one can have 100x receivers (photodiode, TIA, slicer), or 1x photodiode, 100x TIA + slicer, or 1x photodiode + TIA and 100x slicers. The most common id the last one, and it spits out 100x parallel data.

Things get interesting if the losses are high and there needs to be a DFE. This limits speed a lot, but then copper solutions moved to sending multi-bit symbols (PAM 3, 4,5,6,8,16.. ) which can also be done in optical domain. One can even send multiple wavelengths in optical domain, so there are ways to boost the baud rate without requiring high clock frequencies.

[waterheater]

>serial interfaces dominating over the parallel ones

Semi-accurate. For example, PCIe remains dominant in computing. PCIe is technically a serial protocol, as new versions of PCIe (7.0 is releasing soon) increase the serial transmission rate. However, PCIe is also parallel-wise scalable based on performance needs through "lanes", where one lane is a total of four wires, arranged as two differential pairs, with one pair for receiving (RX) and one for transmitting (TX).

PCIe scales up to 16 lanes, so a PCIe x16 interface will have 64 wires forming 32 differential pairs. When routing PCIe traces, the length of all differential pairs must be within <100 mils of each other (I believe; it's been about 10 years since I last read the spec). That's to address the "timing skew between lanes" you mention, and DRCs in the PCB design software will ensure the trace length skew requirement is respected.

>how can this be addressed in this massive parallel optical parallel interface?

From a hardware perspective, reserve a few "pixels" of the story's MicroLED transmitter array for link control, not for data transfer. Examples might be a clock or a data frame synchronization signal. From the software side, design a communication protocol which negotiates a stable connection between the endpoints and incorporates checksums.

Abstractly, the serial vs. parallel dynamic shifts as technology advances. Raising clock rates to shove more data down the line faster (serial improvement) works to a point, but you'll eventually hit the limits of your current technology. Still need more bandwidth? Just add more lines to meet your needs (parallel improvement). Eventually the technology improves, and the dynamic continues. A perfect example of that is PCIe.

[cycomanic]

They are doing 10 Gb/s over each fibre, to get to 10 Gb/s you have already undergone a parallel -> serial conversion in electronics (clock rates of your asics/fpgas are much lower), to increase the serial rate is in fact the bottleneck. Where the actual optimum serial rate is highly depends on the cost of each transceiver, e.g. long haul optical links operate at up to 1 Tb/s serial rates while datacenter interconnects are 10-25G serial AFAIK.