[J-core] USB 2.0 in turtle

Fri Jul 3 08:10:13 UTC 2020

I never clicked "send" on this, did I? Sorry, my bad. Dropped ball...

On 6/23/20 11:40 AM, Tim 'mithro' Ansell wrote:
>     > 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. 

I know it's a spartan 6, but I dunno which variant Martin put on the board.
(There's a couple different speeds and packaging and so on. Plus we've used lx9,
lx25, and lx45. Plus a whole kintex branch but that's not in turtle.)

I know we couldn't clock S6 as fast as we could Kintex, but I dunno what range
of speeds S6 itself has within the Lx45 line. Nor what the actual crowd supply
production run is expected to use. (Parts procurement is an area I smile and nod
and back slowly away.)

> 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.

I forwarded this to people with more relevant domain expertise, but they're hip
deep in a product ship crunch right now...

>     > 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...) 

>From my (admittedly incomplete) look into this, if we _can_ do USB 2.0 I think
we just need to figure out how to make a VHDL data pump the Linux ehci driver
can talk to:

  https://www.kernel.org/doc/html/latest/usb/ehci.html

via a ~300 line glue layer equivalent to any of the ehci-*.c files in:

  https://github.com/torvalds/linux/tree/master/drivers/usb/host

Which mostly means it needs to be able to set transmission speed (alas not
EVERYTHING is 480mbitps) and send and receive data via DMA with interrupt
support. (There may be some realtime packet response plumbing the VHDL side has
to do, but mostly it looks like Linux is handling all the protocol stuff? I know
Linux falls back to the ohci driver for usb 1.1; I don't remember if keyboard
and mouse stuff ever fall back to 1.0...)

>     > 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.

Possibly that was the problem? This was explained it to me once, but "once"
was 2016 and the world's been kind of on fire since then. (Stress from the whole
Twilight Of The Boomers thing has definitely cost me some brain cells...)

>     > 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 believe more sample boards show up in canada on the 6th, and get tweaked and
mailed on from there...

> 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!

They figured out the kernel panic. The test program for cdc-acm created a
corrupted packet (dump attached) which made the distro linux kernel it was
plugged into at the other end crap the second attachment into dmesg. (How to
disable the horror that is modem mangler is already mentioned on
https://j-core.org, but in this case it's mentioned in the dump because it
opened the device thus triggering the exchange of fire and getting caught by
shrapnel. The trigger of the problem, but not the cause...)

> It would be awesome to get j-core into LiteX

Sounds good to me?

> (https://github.com/enjoy-digital/litex/issues/107).

We got kinda distracted by a reorg for a while there. (I spend as little
of my time assuaging capitalism as I can, but unfortunately there's still rather
a lot of it. I just wanna do good work that's useful to people, it would be nice
if we could get all this financial nonsense out of the way, but that's not the
world we live in yet...)

> LiteX already supports
> Linux running on RISC-V 32bit (VexRISCV), RISC-V 64bit (Rocket + BlackParrot),

They've been very good at the fundraising part of technology development, yes.

> 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.

I'm all for it, but I'm 95% a software guy. (I can do some useful vhdl design
work in groups, but still need a lot of handholding that hasn't been available
recently due to coronavirus.) And unfortunately the people I'd normally hand
this off to are trying to Ship a Thing to a Customer by a Deadline.

> 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.

Yes, Jeff keeps emailing me progress update reports on building our stuff with
the fully open toolchain. I keep telling him he should post them HERE...

Here's what he emailed on the 20th (responding to his own message from april):

> On Apr 13, 2020, at 2:04, D. Jeff Dionne <jeff at coresemi.io> wrote:
> 
> > Over the past month (March 2020) the functionality of GHDL + Yosys has reached
> > the point where most designs seem to produce workable netlists.
> 
> Things are now (June 2020) at the point where synthesis results are likely better
> (smaller, faster) by a measurable, and possibly large margin over Lattice own
> tools.  It’s not clear how the Xilinx netlist results would compare yet.
> 
> > In order to complete the loop so that post synthesis simulation is possible,
> > Yosys needs a VHDL backend, which would be a single C++ file.  That can be
> > written starting from the verilog backend, some few 1000 LoC.
> 
> Someone has started slogging through this rather ugly task here
> https://github.com/rlee287/ghdl-yosys-plugin/blob/vhdl_backend/src/vhdl_backend.cc
> It appears quite slow going, with the problem being a reasonable way to exercise
> all of the syntax tree elements and output code paths.  It’s not far enough along,
> his pull requests have been rejected up to now.
> 
> Similarly, someone is working on a (useful) C++ back end, which allows a chip
> design to be compiled into something (usually just a simple loop that advances
> the clock) as a simulation:
> https://github.com/YosysHQ/yosys/tree/master/backends/cxxrtl 
> 
> This C++ backend is in mainline, and FWIW turns a (working) J1 core syntax
> tree into the attached... file ;^)
> 
> J.

His attached C++ file was waaaaaay too big to post here, but in a different
channel Jeff said:

> I think the most important thing that can be learned from that C++ file is
> that the name mangling is a real serious problem for any sort of reading of
> the netlist.  Its not completely clear to me if GHDL did most of the damage
> (maybe when it flattened records / structures into individual wires) or if it
> is more a result of logic minimisation.  In any event, its impenetrable,
> whereas the Xilinx synthesis tools at least retain clear signal naming
> hierarchy.

Cool stuff _is_ happening, just... behind the scenes at the moment.

> Keep up the good work!
> 
> Tim 'mithro' Ansell

Thanks for your interest. Please poke me if I drop the ball here again, I'm
spinning too many plates but _want_ to help...

Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb-dump.jpg
Type: image/jpeg
Size: 178108 bytes
Desc: not available
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20200703/90f28942/attachment-0001.jpg>
-------------- next part --------------
An embedded message was scrubbed...
From: "D. Jeff Dionne" <jeff at coresemi.io>
Subject: Fwd: VPN Hat works... sorta.
Date: Mon, 22 Jun 2020 07:21:18 +0900
Size: 77171
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20200703/90f28942/attachment-0001.eml>