Routing USB and switching from Host to Device

[SpacedCowboy]

I have a project ongoing that has a Tang nano 9K as the main part of it. The board has a USBc port on one end which it can use to be programmed with, or as a serial port. I'd like to keep that functionality but I'd also like to minimize the number of ports on the outside of the box. It's early stages yet, but the basic design looks like below (board.png), I have yet to fit in USB and ethernet, and I really only have the back of the board (the edge with the button on) to play with

I have two plans to choose from:

• Get something like this and mount it on the chassis above or below the other board-edge components
• Get something like this mating to this instead

The second option is more complicated but would let me mate the USBc from the FPGA to the main PCB, and then I was thinking I could do something like shown in USB-routing below. The idea here is that the switches would default to the blue path...

• FPGA routed out via the hub to the single port
• RP2040 routed out via the hub to the single port, as device

but if the RP2040 flipped the 'select' switch, then the FPGA gets routed from switch #1 through to switch #2 (which changes the RP2040 connection), and the RP2040 enters host-mode, thus letting it program the FPGA over the USB:JTAG bridge, which would be awesome because the RP2040's DFU mode is particularly friendly, so updating the FPGA bitstream would become a lot easier

I've only ever really routed USB directly from chip to USB-socket, so this is all new, but the FSUSB43 seems to indicate it's bidirectional so hopefully it could work. The FSUSB43 says it's optimized for 480mbps<-->480mbps and 480mbps<-->12mbps, and this would be 12mbps<-->12mbps in all cases, but I assume if it can handle 480<->12 it ought to be able to handle 12<->12.

Any thoughts on whether this setup is likely to work ?

[ebclr]

Why do you need the RP2040 ?

The tang nano 9k has many resources to make a soft processor inside, with no more than 10% of the available resources, to handle the eventual process rp2040 will handle.

This will void all the USB mess you are planning to make.

[SpacedCowboy]

I have plans for the tang's 9k of resources, and I'm actually not sure there'll be enough - there'll be at least 3 chips being emulated inside the FPGA, plus the HDMI output, a frame buffer, and the PSRAM memory interface. It also has to look after the bus-snooping, parse out video fetches from the 6502C instruction stream. If I have space I want to create a 6502 in there as well, and have a "turbo" mode

The RP2040 will handle ethernet and TCP/ip, digitize incoming audio and pass onto the HDMI output (as soon as I can figure out how to get that working, anyway), and as I said, has far easier update possibilities than the tang (hold a button, plug USB into a computer, drag the firmware file to the  USB-disk that just appeared, done). It also handles the boot process, making the device very difficult to "brick". I'm basically using the RP2040 as a 'system-controller' type chip for pretty much everything these days. I just wish it had more pins.

[SpacedCowboy]

Hmm.

To cover bases, I just tried a simple instance for the RV32 from Gowin using the IP configurator. It comes by default with a UART, I asked it to give me a SPI and an I2C (both of which I will need from the RP2040).

Code: [Select]


module top
    (
    input                     clk_in_i,
    input                     resetn_in_i,

    output                  ser_tx_o,
    input                   ser_tx_i,

    input                   wbspi_master_miso_i,
    output                  wbspi_master_mosi_o,
    output                  wbspi_master_ssn_o,
    output                  wbspi_master_sclk_o,

    inout                   wbi2c_sda_io,
    inout                   wbi2c_scl_io,

    input                   jtag_TDI_i,
    output                  jtag_TDO_o,
    input                   jtag_TCK_i
    );

    ////////////////////////////////////////////////////////////////////////////
    // Instantiate the CPU
    ////////////////////////////////////////////////////////////////////////////
Gowin_PicoRV32_Top rv32_inst (
.ser_tx(ser_tx_o), //output ser_tx
.ser_rx(ser_rx_i), //input ser_rx
.wbspi_master_miso(wbspi_master_miso_i), //input wbspi_master_miso
.wbspi_master_mosi(wbspi_master_mosi_o), //output wbspi_master_mosi
.wbspi_master_ssn(wbspi_master_ssn_o), //output [0:0] wbspi_master_ssn
.wbspi_master_sclk(wbspi_master_sclk_o), //output wbspi_master_sclk
.wbi2c_sda(wbi2c_sda_io), //inout wbi2c_sda
.wbi2c_scl(wbi2c_scl_io), //inout wbi2c_scl
.jtag_TDI(jtag_TDI_i), //input jtag_TDI
.jtag_TDO(jtag_TDO_o), //output jtag_TDO
.jtag_TCK(jtag_TCK_i), //input jtag_TCK
.jtag_TMS(jtag_TMS_i), //input jtag_TMS
.clk_in(clk_in_i), //input clk_in
.resetn_in(resetn_in_i) //input resetn_in
);

endmodule


It gave a pretty underwhelming fMax of 19.8MHz on the GW1N-LV9QN88C6/I5 part that (I think) is the one on the Tang Nano 9k. It also used up about 67% of the logic resources.

Just to check, I even took out the SPI and I2C - even though I want them there - and ran it again. I actually got a lower fMax (16.8MHz) and the utilisation only dropped a little (to 60%).

I think the RP2040 (dual core, easily handles 200MHz, costs $1) is safe for now...

As an aside, I also built Arlett Ottens 6502 core and it gave an fMax of 40MHz with a utilisation of 10%.

[ebclr]

Did you considered tang 20 K, Or even tang 4k, that have arm core inside

Maybe an esp32 can handle everything alone, What is the job of the FPGA you have in mind, What is the full project goal, those mixed architectures push a layer of complexity that can be unnecessary if you chose a single architecture to solve all.

If you really wanna go on the double architecture patch, A USB hub chip, will not be an easier solution,  than USB switches? At least will be transparent on the software side of things

[SpacedCowboy]

I like the Tang 20K - I have a few of them - they’re great value in relative terms, and come with DDR3, not to mention a faster fabric (the pico-rv32 gets 42MHz on the 20K) and of course there’s a lot more space. The sticking point there is the price: by the time I’ve added the DIMM connector and an HDMI port, we’re at 2x that of the 9K. Relatively-speaking, still great, but still 2x the price.

It may come down to using the 20K, but I want to see if it can be squeezed into the 9K first. I don’t think there’s any chance of getting the logic I want inside the 4K.

As for what I’m doing, if you look at my comment here you’ll get an idea. I have a small (~40ns) window of time to read a bus, do a lookup, and assert 1 or 2 signals. Alongside that, I want the data on the bus decoded and parsed so that embedded video fetches can be extracted and used to construct an HDMI framebuffer, I want an ethernet interface, and I want a chunk of RAM (8MB is fine) to be available to the host. There are other ancillary tasks, but those are the main things.

I did consider doing it with an MCU, but the requirements are extreme, I think it could be done with an STM32H7{A|B}, running at 550MHz, with interrupt routines in ITCM for the bus monitoring and the LTDC to an ADV7511 to produce the display, quad-SPI or Hyper-ram for the memory, and the built-in ethernet controller (though that would limit me to 16-bit RGB)… but here we run into the price wall again.

The rapid-response needed for the hard timing-requirements for the bus-snooping coupled with the relatively high bandwidth requirements for video and megabytes of memory is a tough nut to crack when price is a factor. You either run the bus snooping on interrupts (which means fast interrupt response to hit that 40ns window) and run the rest of the code “normally”, or you get into time-management hell with everything that can happen being slaved to the 558ns-period external clock.

As for just using a hub, I don’t think that will work, will it ? AFAIK, hubs expect everything on the “down” links to be devices (or more hubs) and the “up” link to point (maybe eventually) to a host. In this case there are two connections (RP2040, FPGA) which are normally devices, so they could both go behind a hub, but if the RP2040 turns into a host so it can connect to the FPGA to program it over JTAG, it can’t sit on the device side of the hub and expect that to work, at least that’s my understanding. The point of the switches (one for the FPGA, one for the MCU) is to allow that path to work and provide the path from  FPGA-as-device to RP2040-as-host.

[edit: having said all that, it does occur to me that the cost of all these USB switches, cables, connectors and hub might in fact be a significant chunk of the price difference between the 9K and the 20K tangs. There’s a lot more io pins on the 20K as well, so no games to play with time-multiplexing the bus snooping. I’ll have to run the figures and see if it’s just worth switching up]

[ebclr]

Now I get it