[J-core] USB 2.0 in turtle

[Tim 'mithro' Ansell]

On Mon, 22 Jun 2020 at 20:34, Rob Landley <rob at landley.net> wrote:

> On 6/22/20 2:57 AM, Tim 'mithro' Ansell wrote:
> > On Sun, Jun 21, 2020, 7:59 PM Rob Landley <rob at landley.net
> > <mailto:rob at landley.net>> wrote:
> >
> >     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.
> >
> >
> > Which Spartan are you using?
>
> The numbers on the chip say: XC6SLX45 CSG324DIV1713 D5388641A 2C
>

That is a Spartan 6. The Spartan 6 SLX45 is the same as what is used on
both the Digilent Atlys and Numato Opsis board.

The Opsis board also has a Microchip USB3340 and you might find joris_vr -
http://jorisvr.nl/usb/ and https://github.com/lambdaconcept/lambdaUSB useful
too.

> On the sending side, any IO pins on the Spartan 3 can go up to
> 750mbit/sec and
> > the Spartan 6 can do up to 1250mbit/sec. Spartan 7 can do 1500mbit/sec
> on every
> > pin with a tiny bit of overclocking.
>
> This is a Jeff question. (Or Arakawa-san, or...)



> The receiving side is a little bit harder unless you have a good reference
> > clock. On the Spartan series it is reasonably hard to get the
> 4x oversampling of
> > a 480mbit/sec required to do proper clock recovery otherwise but there
> are some
> > tricks using the IO delay phasing in a differential pair.
> >
> > It is likely we will explore some of this in the Luna stack
> > (https://github.com/greatscottgadgets/luna) in the future.
>
> Cool. Right now he's trying to get the parallel thing working. (He made a
> USB
> gadget, plugged it into his linux laptop to see if it would enumerate, and
> linux
> on the laptop crapped a null pointer dereference stack dump into dmesg. So
> we
> should probably report that to the kernel guys. I'm told his mac just
> times out
> instead...)
>
> I still haven't got a copy of this HAT hardware to play with yet...
>

I would highly recommend getting a board to Kate Temkin from Great Scott
Gadgets who is working on LUNA, it is very likely she will add support for
your board (she has been adding support for everything recently!). She is
also very good at debugging USB issues and has a lot of tools to help
figure out what is going on. I'm also sure she would love to explore
another new architecture with an interesting history too!

It would be awesome to get j-core into LiteX (
https://github.com/enjoy-digital/litex/issues/107). LiteX already supports
Linux running on RISC-V 32bit (VexRISCV), RISC-V 64bit (Rocket +
BlackParrot), PowerPC (microwatt) and OpenRISC1000 (mor1kx). This would
open up a *lot* of potential FPGA boards to use j-core on -- see the repo
at https://github.com/litex-hub/linux-on-litex-vexriscv for a list.

With ghdl + yosys starting to support more VHDL, it might even be possible
to have a fully open source toolchain here. Microwatt which is also VHDL
works some of the time.

Keep up the good work!

Tim 'mithro' Ansell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20200623/a7c2d61a/attachment.html>