Fwd: [lowrisc-dev] Multiple Rockets and Minions memory hierarchy
Dr Jonathan Kimmitt
jrrk2 at cam.ac.uk
Thu Jun 1 10:58:34 BST 2017
See below for clarification about reasons for not changing mode of
hardware communications if we can avoid it...
This my interpretation of the warning from Denis Steckelmacher
FTDI chips present themselves on the USB bus as modem devices, using the
USB CDC class. On Linux, the FT2232H chip exposes two devices,
|/dev/ttyUSB0| and |/dev/ttyUSB1|, one for each channel (the chip allows
two devices to be connected to it, a JTAG programmer and a
general-purpose connection on the Nexys Video). On Windows, |COM1| and
|COM2| are available once a driver is installed.
Opening |/dev/ttyUSB0| and writing to it allows to communicate with the
device connected to the first port of the FT2232H chip using its default
mode, /Asynchronous FIFO/ in the case of the Digilent Nexys Video.
However, there is now way to enable /Synchronous FIFO/ using only this
|ttyUSB0| device, we must use |libftdi|.
|libftdi| is a pure user-space library, built on |libusb|, that allows
to detect FTDI chips, configure their ports, send and receive data. This
library is very easy to use but has one major problem: it unregisters
the USB CDC driver. This means that once a |libftdi| call is made, the
|/dev/ttyUSB| devices disappear and cannot be used anymore. All the
communication with the chip needs to be done using |libftdi|.
It would appear that, once the synhronous FIFO is enabled, it can no
longer act as a Vivado compatible JTAG port. However I have not tried it.
On 01/06/17 10:11, Peter Stuge wrote:
> Dr Jonathan Kimmitt wrote:
>> Thank you for that reference. I was not aware of the DPTI example,
>> however it seems to be quite specific to a certain peripheral of
>> the Nexys-Video.
> Mh. FT245 is a rather common piece of hardware, very easy to get a
> loose board.
>> As we are a small team there is a certain overhead in board
>> specific solutions which we wish to avoid if possible in favour of
>> largely board independent techniques.
> Keep in mind that simple board specific solutions have zero or very
> low overhead. (Or they wouldn't be simple.)
> Rather than having to develop a single board independent solution to
> this problem I think it may worthwhile to consider reusing existing
> (all MUST be simple!) solutions, because the total effort can
> actually end up being *less* as long as they are all simple.
> No doubt there is a slight increase in complexity, but when the
> chosen "one true way" (UART) has problems (boards w/o flow control)
> there is complexity anyway.
>> In particular we have found it to be a great nuisance if a certain
>> solution disables Vivado access to the JTAG port due to a peripheral
>> chip changing modes, as seems to be the case here.
> This sounds like a big problem, but I can't understand exactly what
> you mean. Can you please expand a little on "peripheral chip changing
> modes" ? Thanks.
>> I have noticed that the latest version of OpenOCD support
>> Nexys4-DDR via the Digilent JTAG adaptor, I don't know if the same
>> is true of the Nexys-Video because this part of the schematic is
>> closed source. As well as being open source this software seems to
>> be streets ahead of Digilent's own library in performance, so I am
>> now investigating whether this would make a good debugging solution for
>> the raqnge of boards that we support.
> I was one of several OpenOCD maintainers for a while, and while
> OpenOCD is somewhat flexible, allowing scripting in Tcl, it also does
> have some design limitations. It may well be a good base though.
More information about the lowrisc-dev