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

Peter Stuge peter at stuge.se
Thu Jun 1 10:11:45 BST 2017

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 mailing list