⚡️[OPTIMIZATION] Do NRZI encoding in TX PIO

[raphlinus]

Hi! I'm studying this library carefully, considering doing an independent re-implementation in Rust (see https://wiki.thejpster.org.uk/index.php?title=USB). I'm very impressed overall, but am looking at possibilities for doing things more efficiently.

One such optimization is doing NRZI encoding in the TX PIO instead of in software. There is an encoding step, expanding each bit of the input to two bits sent to the PIO (thus leaving 00 available to represent EOP), but that's lightweight and could easily be done with a byte or nibble lookup table. This could also be done on the fly, possibly interleaved with CRC calculation, replacing DMA with pushing into the TX FIFO from the CPU, much as is already done on RX.

Below is the PIO program I came up with. The x scratch register represents the current line state, and y is the bit stuffing counter. I haven't run this yet, so it's quite possible I made a mistake, but I believe the concept is sound.

// encoding: 00 = stop, 01 = bit 1, 11 = bit 0

eop: 
    jmp eop_impl [1]
bit_one: 
    jmp y-- nostuff [2]
    nop
bit_zero: 
    set y, 5
    jmp !x j_zero
start:
    set x, 0 side J
    out pc, 2
j_zero:
    set x, 1 side K
nostuff:
    out pc, 2
eop_impl:
    nop side SE0 [7]
    nop side J [3]
.wrap_target
    set pindirs, 0
.wrap

As a side note, I believe the description of the K/J polarity is wrong in the code; I believe the PIO_USB_TX_ENCODED_DATA enum has K and J swapped, and also that FJ_LK should just be J and correspondingly FK_LJ should just be K, as it seems to me the selection of lines for these states is done in configure_tx_program rather than in encoding; the latter would be almost ok except for the fallthrough from the SE0 state to J. Of course, it's also possible I'm missing something.

Let me know if these kinds of musings are welcome. I'm also looking at trying to get RX to work at 48MHz, which I think may be possible if more work is transferred to the CPU. My motivation here is largely other constraints on sysclk for correct DVI video timing.

[raphlinus]

An update: in trying to run this, I'm realizing I misunderstood "side", that it's actually required for each instruction as opposed to being optional. That's obviously a problem. I think the idea can be recovered, but it won't be trivial.

[shreeve]

Whoa! Sounds very cool. Do you have a link to what you're working on or is it the link you sent in your email?

I've worked on a pure RP2040/RP2350 version that doesn't require PIO at:

https://github.com/shreeve/picousb

It just uses the pico's on board support to offer USB host (which I haven't seen anywhere else).

You may find some alternate RP2040/RP2350 PIO code from Alex Taradov (he's got several projects online) at:

https://github.com/ataradov

I'm interested in what you come up with.

Cheers,

Steve Shreeve

[raphlinus]

@shreeve The project I'm working on is pico-dvi-rs, and I'm targeting the Adafruit Fruit Jam board, which is the main reason I'm interested in PIO. Using the USB peripheral also has compelling advantages, not least of which is being able to use the 48MHz clk_usb reference without constraining the sysclk, and I do have that working using cotton_usb_host (see usb branch of that repo). I haven't posted any pio code yet, at this point I'm just experimenting.

Another update: you can indeed set sideset to be optional, and the above code does work. However, I've since come up with a more refined approach, using two techniques. One is to use mov pins, !pins to toggle, rather than using the x scratch register, saving a cycle. The other is to length-prefix the packet so there's no need for any encoding at all. Here's the resulting PIO:

    jmp x-- bit_zero
    jmp x-- bit_one
    set pins, SE0 [7]
    set pins, J [3]
.wrap_target
    set pindirs, 0
.wrap
bit_zero:
    mov pins, !pins
    set y, 5
nostuff:
    out pc, 1
bit_one:
    jmp y-- nostuff [1]
    jmp bit_zero
start:
    set pins, J
    set pindirs, 0b11
    out x, 32
    out pc, 1

I have run this and validated that it works correctly. You push the number of bits (8 * byte count), the bytes without any additional encoding, then a final 1 to kick off EOP (it's possible to get rid of the need for that, but with some tradeoffs; it's a pretty small additional burden compared with computing crc). Also note, if input is inverted (as is done for RX), then the toggle becomes mov pins, pins.

[shreeve]

@raphlinus - Ah, excellent! I will check out the link. This could be very helpful for other projects like Embedded Zig, TinyGo, Pico Ruby, etc.

Your PIO updates look great... it is INCREDIBLE that such power can come from these tiny opcodes!

[raphlinus]

More updates as I continue to experiment with this. I now have successful TX/RX loopback with rewritten PIOs. The code is at https://github.com/DusterTheFirst/pico-dvi-rs/tree/pio_usb.

One concern is the total number of instruction slots. I think I am resigned to juggling, in other words having the RX and TX programs overlap, and setting the instructions in the overlap region when switching between the two. Currently I have tx down to 10 instructions with a 1 bit encoding, and 8 instructions with a 2 bit encoding (so juggling would not be needed in the latter case, and there is even 1 slot leftover), and RX down to 23 instructions. The RX program does require the IN_COUNT feature which is rp2350-only; not a problem for what I'm doing, but I know there are a lot of people who want to use RP2040.