Hacker News Reader

Comment by vbezhenar | Hacker News Reader

As a hobbyist I wish that electronic gods would invent a way to bit-bang real world protocols. It is possible with simple protocols, but when we move to MHz range, it moves to impossible. Some kind of co-processor which would work at, say, 100 GHz speed with very limited instruction set. So I could implement some simple protocol parsing and buffering for more complex processing at lower speeds. Probably not possible, but who knows...

View on HN

The rp2040 and its newer sibling can be clocked north of 100 MHz and have special hardware called PIO (programmable input/output) that runs at one instruction per cycle and can do multiple IO operations per instruction.

That's a microcontroller. I wonder if more powerful chips can do more.

The main issue with that is that the PIO does not have decent support for external clock inputs, let alone any kind of clock recovery. It can easily send a 100MHz signal, but it can't reliably receive one.

The PIO allows for single-cycle or dual-cycle data output, which essentially just pulls bits from a FIFO and puts them on some pins. The "side-set pin" makes it really easy to generate a clock signal as well. If the target devices samples on rising edge, it becomes essentially "output data, clock low; nop, clock high; implicit repeat" or even "output data; implicit repeat" if the target can do its own clock recovery or uses DDR. This is great, because you can output a lot of data at quite high speeds.

But the opposite is a lot harder. The PIO has no native clock support, so you're left simulating it yourself with a multi-instruction operation. If you need even as little as two instructions to receive a bit, that 133MHz MCU clock already limits you to a 66MHz signal! In theory you could use an external clock input - but those pins are limited to 50MHz. You could also feed the external clock into the main oscillator input - but that breaks a bunch of other functionality, especially if the external clock isn't reliable. Oversampling isn't an option either: you'd have to read the pins at 4x the signal frequency (limiting you to 33MHz) and dedicate a lot of computing resources to that.

In other words, high-speed input is only really an option if you don't care about synchronization, such as a free-running logic analyzer. But bitbanging 100BASE-T Ethernet? Don't count on it. Even the 2-bit-wide 50MHz RMII interface has proven to be quite challenging.

Thanks for the insights. I've only written one PIO program, and it's for a DHT22 sensor. I divided the clock down to 1 MHz so I could count microseconds. Really, CPU bit-banging would have worked fine at those speeds.

Now that I think about it more, you're right. Best case scenario for reading a bit would be to wait for the pin to go high/low, then push the corresponding bit into the input shift register, and have that automatically flush to DMA every 32 bits, say. Can't do better than some fraction of the clock speed because of the multiple instructions needed.

You're basically talking about FPGAs. Sure, for >500 MHz (depending on the FPGA) you'll need to use the integrated transceivers, but they're flexible and support the physical layer of many protocols.

This is basically what FPGAs offer, although above 1GHz the transceiver design becomes difficult and expensive. 1GHz should be possible on hobbyist-priced parts.

100GHz is .. well, can anyone find any part with that capability? Seems to top out around 10GHz for ethernet transceivers.

I think he meant 100MHz. In case he actually meant 100GHz, I would gently remind him that light only travels ~3mm in 10ps

Raspberry RP2040/2350 microcontrollers are more than capable of bitbanging up to 100-300 MHz range by using PIO and HSTX. Higher end with some overclocking.

As others have said, PIO has your back. https://hackaday.com/2022/12/03/bit-banging-bidirectional-et...

What use cases are you imagining where you need arbitrary data output and processing at 100GHz speeds? It's my understanding that even 100GbE is running at a fraction of those frequencies.

To be able to spend multiple cycles for processing a bit. Or process multiple bits arriving at the same time. Also it might be necessary to measure signal multiple times. May be 100 GHz is too much... For example I wanted to bit-bang FM radio by measuring antenna signal, that's around 100 MHz, so I need to probe around 200-300M times per second and perform at least minimal processing, I guess.

I realize FM radio is strictly an example, but would you not rely on bandpass sampling? Where you sample at some multiple of your bandwidth and rely on the spectral replication effect to get your waveform.

Ref: https://en.wikipedia.org/wiki/Undersampling (funny enough, this article explicitly calls out the FM radio use case).

You need a very stable clock for that, which was also called out as a thing. With some PLLs you could lower the needed frequency. I think you're really looking for a small FPGA though.

There's also XMOS (effectively, software defined hardware). But ain't going to do those speeds.

Reply on news.ycombinator.com