Fwd: [lowrisc-dev] Multiple Rockets and Minions memory hierarchy

Daniel Follesø danielfollesoe at gmail.com
Fri Jun 2 16:20:52 BST 2017


Hi again.

FTDI have official custom drivers for their chips. They are called D2XX.
Source:
*http://www.ftdichip.com/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf
<http://www.ftdichip.com/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf>*
*http://www.ftdichip.com/Drivers/D2XX.htm
<http://www.ftdichip.com/Drivers/D2XX.htm>*

Quote from "AN_220_FTDI_Drivers_Installation_Guide_for_Linux":
----------------------------------------------------------------------------------------------
In Linux, the VCP driver and D2XX driver are incompatible with each other.
When a FTDI device is plugged in, the VCP driver must be unloaded before a
D2XX application can be run. Use the remove module (rmmod) command to do
this:
sudo rmmod ftdi_sio
sudo rmmod usbserial
When the FTDI device is power cycled or reset the VCP driver will be
reloaded. The rmmod process must be repeated each time this occurs. It is
possible to write a simple script that unloads the VCP driver before
running the D2XX application.
--------------------------------------------------------------------------------------------
End quote.


The best open documentation of the FPGA side I have found thus far is under
the doc directory of:

*https://github.com/Digilent/vivado-library/blob/master/ip/AXI_DPTI_1.0/
<https://github.com/Digilent/vivado-library/blob/master/ip/AXI_DPTI_1.0/>*

In addition "Adept 2" contains documentation about DPTI and a basic
loopback-test that I have tried.

*https://reference.digilentinc.com/reference/software/adept/start
<https://reference.digilentinc.com/reference/software/adept/start>*


--Daniel




2017-06-01 11:58 GMT+02:00 Dr Jonathan Kimmitt <jrrk2 at cam.ac.uk>:

> 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