[lowrisc-dev] Nexys debug communication [was: Multiple Rockets and Minions memory hierarchy]

Peter Stuge peter at stuge.se
Tue Jun 27 19:19:11 BST 2017

Stefan Wallentowitz wrote:
> > Stefan Wallentowitz wrote:
> >>> FT245 async mode yields 10-12 MByte/s throughput so it's slower than
> >>> sync, but it is reliable
> > 
> > Ok - so that's still usable throughput? Then we should give this a go.
> Why not sync mode? The reference sheet says it has a 60MHz clock, so we
> should be able to reach 60MB/s, right?

Sync mode is indeed faster, but the FT2232H (maybe all FTDI chips)
disables channel B when channel A operates in sync mode. Second best
is the async FIFO mode.

> This would be awesome, USB3 currently yields 2-4 times that, but
> not requiring an extra board is great.

When we get to the FT600 I expect to get all 32*100Mbps throughput,
which compared to FTDI sync mode 8*60Mbps is factor 6.67 faster. But
only half of that for the 16-bit board.

> >>> I am happy to write software to make debug communication over
> >>> channel A work in parallell with Vivado JTAG if there is interest.
> >>
> >> That would be awesome.

Where does the debug communication terminate on the PC side?

Is there existing software to hook this channel into, or do we start
with a new, minimal tool?

> > the first thing to investigate would be whether Vivado cares
> > about channel A.
> > a small program claim.c
> I ran the tests now, it works nice. I cannot claim interface 1 once
> vivado is connected, but interface 0 can still be claimed.

That's great! Vivado is staying out of the way, and we have access.

> Next steps are then an FT245 backend to glip. I assume the steps
> are simple:
> - Configure it to FT245 sync fifo
> - Exchange data with the endpoints in this interface
> Is that right, Peter?

Yep, except async FIFO mode.

> I will prepare the backend (mostly copying stuff).

The fx2 backend sw in glip gets almost everything right - but has one
issue: it doesn't saturate the USB with transfers, which costs throughput.

Then, the USB remains idle between when one transfer has completed
and when the next transfer is submitted. This is "long" in bus time.

It's important to submit multiple transfers at once, so that the host
controller always has pending transfers in both directions scheduled.

ftdi_readstream() in libftdi1 ftdi_stream.c does that, but libftdi1 is LGPL.

libftdi1 doesn't mention async fifo mode so we may have to look at what
the vendor software does on the bus in that mode.


More information about the lowrisc-dev mailing list