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

http://steckdenis.be/post-2016-06-25-fast-usb-connection-on-the-nexys-video-using-ft2232h.html

begin quotation
________________________

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

________________________

end quotation

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



More information about the lowrisc-dev mailing list