[J-core] USB 2.0 in turtle

[Rob Landley]

Sorry for the radio silence, we got buried in $DAYJOB work again. But here's an
issue I've been meaning to document:

Although the USB 2.0 spec maxes out at 60 megabytes/second (480
megabits/second), both rounds of turtle board prototypes we did only have USB
1.1 wired up to the USB switch chip that goes to the 4 ports. This doesn't cause
a compatibility issue (the switch chip upconverts the USB 1.1 signal to USB 2.0
as switches do), but the max bandwidth to the j-core SOC through this connection
is only 1.5 megabytes/second (12 megabits).

The reason for that limitation is the spartan FPGAs can't actually generate a
USB 2.0 signal because it can't clock one pin fast enough. It can do 12mhz
serial output fine, but 480 mhz straight from an FPGA pin ain't happening.

But then we made a turtle hat that _can_ do the full 60 megabytes/second, using
a parallel to serial converter chip to take multiple gpio pins and turn them
into a single faster serial connection:

  http://ww1.microchip.com/downloads/en/DeviceDoc/00001783C.pdf

The reason we didn't do that _inside_ the turtle is the FPGA chip we chose has a
limited number of pins on it, and we had to choose between "having enough pins
to wire up GPIO for hats" and "using a bunch of FPGA pins as a parallel bus into
a converter chip to do full speed USB 2.0". That switch chip wants a 12 pin
interface (8 data pins, 3 control pins, 1 clock pin).

With the "reasonably priced FPGA" chip we chose, we didn't have enough pins to
do both, and this design is erring on the side of having fewer chips in it
anyway. (One of the crowd supply setup todo items is writing up a page listing
every chip on the board, what it does, and why it's there, with of course the
picture-and-arrow diagram of where to find the chip on the board.)

A similar issue exists with the sd card: when we shipped the first and second
VHDL tarballs, the patents on SDCard 1.0 hadn't quite all expired yet so we
implemented the ancient (out of patent) spi-mmc protocol:

  http://elm-chan.org/docs/mmc/mmc_e.html#spimode

which uses a single data line, and since this is a backwards compatibility mode
you can't even reliably clock it very fast or some cards don't work. That's why
the sdcard performance UTTERLY SUCKS in those versions. (Plus we hadn't hooked
up DMA in those releases so using the sdcard under Linux pegs the CPU while
doing the slow transfers.)

But since then, A) the SD 1.0 patents expired, B) we added DMA. (Although we
still need to send support upstream to the vanilla kernel.) SD 1.0 uses 4 data
pins and you can clock it at 25 mhz (which our FPGA can do), which means for
only 3 more pins we can get 12.5 megabytes/second bandwidth. (And those pins we
_did_ spend and wire up, because it was the patent stopping us from using the
newer protocol at the time.)

Rob