Errors : Add a DMA master device in LowRiSC

[sumancu]

Hello, I'm trying to add simple DMA device to the lowrisc (lowRISC 0-4 milestone release), I'm following the tutorial on the following link: http://www.lowrisc.org/docs/internship-2016/device-tutorial/

But it seems the code there is not compatible with the latest release and the compilation fails, could you please help with the syntax or code that adds DMA device that is working with the latest release?

Errors are:. . . .

[error] (lowrisc_chip/compile:run) Nonzero exit code: 1 [error] Total time: 15 s, completed Aug 23, 2017 1:42:11 PM /home/ssau/lowrisc-chip/Makefrag-build:9: recipe for target '/home/ssau/lowrisc-chip/vsim/generated-src/Top.DefaultL2Config.sv' failed make: *** [/home/ssau/lowrisc-chip/vsim/generated-src/Top.DefaultL2Config.sv] Error 1

[jrrk]

The tutorial mentioned is intended for use with the following example:

git clone -b vga --recursive https://github.com/nbdd0121/lowrisc-chip.git

From that example, you should be able to discover the differences from the v0.3 release (primarily in LowRISCChip.scala)

This code has not been tested with the v0.4 release, but since the changes are minor, it should be possible. However the v0.4 release is heavily packed with logic and it may not easily be possible to add more functionality to it successfully.

I'm sorry Chisel error messages are not more sanitary but this is outside of our control. The fragment you give is insufficient to learn anything.

Regards, Jonathan

On 23/08/17 09:11, sumancu wrote:

Hello, I'm trying to add simple DMA device to the lowrisc (lowRISC 0-4 milestone release), I'm following the tutorial on the following link: http://www.lowrisc.org/docs/internship-2016/device-tutorial/

But it seems the code there is not compatible with the latest release and the compilation fails, could you please help with the syntax or code that adds DMA device that is working with the latest release?

Errors are:.
.
.
.

[error] (lowrisc_chip/compile:run) Nonzero exit code: 1 [error] Total time: 15 s, completed Aug 23, 2017 1:42:11 PM /home/ssau/lowrisc-chip/Makefrag-build:9: recipe for target '/home/ssau/lowrisc-chip/vsim/generated-src/Top.DefaultL2Config.sv' failed make: *** [/home/ssau/lowrisc-chip/vsim/generated-src/Top.DefaultL2Config.sv] Error 1

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/66, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1zaumUFr-dUvhOmCrqM_xM10hS-2ks5sa962gaJpZM4O_pbK.

[jawadhy]

Hi, Could you please explain more about this statement: " the v0.4 release is heavily packed with logic and it may not easily be possible to add more functionality to it successfully"? If we would like to take a lowrisc system and add to it more functionality (e.g. new IPs) then which release you recommend us to use? Isn't 0.4 the release that includes all last features?

Thanks Jawad

[jrrk]

The comment refers to the LUT occupation of the board when the Nexys4-DDR is targeted. If you add more logic there could be problems with place and route with this board. If you only want to try out a DMA master then the v0.3 release might be more appropriate because it is smaller and closer to the tutorial that was mentioned. If you need the latest features in v0.4 you will probably have to leave out something else, such as the L2 cache.

On 23/08/17 17:14, jawadhy wrote:

Hi, Could you please explain more about this statement: " the v0.4 release is heavily packed with logic and it may not easily be possible to add more functionality to it successfully"? If we would like to take a lowrisc system and add to it more functionality (e.g. new IPs) then which release you recommend us to use? Isn't 0.4 the release that includes all last features?

Thanks Jawad

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/66#issuecomment-324386067, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF14n8fIedRP_7qS_bk1b31YoyYn7rks5sbE_jgaJpZM4O_pbK.

[wsong83]

I think we should be clear on this:

There is no limit on what can be added on the lowRISC SoC (to this specific DMA so similar needs).

There is an area limit when the officially supported Nexys4-DDR board is used. And right now this limit is nearly reached by lowRISCv0.4.

[jawadhy]

Thanks both for your answer. How difficult is it to port the lowRISCv0.4 to work with bigger FPGA? was it done by other team?

[jrrk]

Dear jawadhy,

The port to a different FPGA is of moderate complexity depending on the details of peripherals available.

The Kintex series primitives are slightly different to the Artix, which is different again to Ultrascale,

and memory sizes and dynamic memory interfaces differ between boards. Xilinx IP versions and supported Vivado versions need to change.

Sadly not every Vivado release is robust and software support is not available to academic institutions.

You will need a different configuration of DDR controller in most cases, it is unlikely the video and keyboard peripherals will be compatible, which will mean a certain amount of rewriting. Also the XCF file also has to be changed, because signal names and pins change with different packages and boards.

UART to USB interfaces differ a lot between boards and while it is relatively easy to emulate a PC interface at 115200 baud, it could be difficult to get the trace interface working at an effective speed. For this reason we have not included a port to the KC705 since moving to debug-v0.3.

Not every board has a SD-card interface, on some boards you may be able to work with an external adapter.

Work has started on updating the KC705 support for debug-v0.3 on the kc705_update branch and previous mention of VC707 support has been discussed on this list. Also the Zedboard port was provided by a third party.

The Nexys4_video board was purchased of part of a plan to provide more capacity, but turned out to be disappointing due to a lack of flow control signals on the UART. Obviously hardware designers have conflicting demands on them for different features when designing boards and this results in them dropping features which they consider low priority. Another issue is the lack of USB support in the FPGA on most boards. USB endpoints tend to terminate in off-chip IP, whereas what we would like is to implement the USB in the FPGA (subject to area constraints).

Looking ahead we would like to support Ethernet but there are many different PHY chips on the different boards with multiple different interfaces. Another annoying problem is that multiple high-speed interfaces can interfere with each other if used simultaneously, due to noise considerations, bond wire inductance, and the generosity of decoupling provided.

The decentralized nature of the git repositories makes it relatively easy for a third party to contribute a board port.

Regards, Jonathan

On 24/08/17 02:45, jawadhy wrote:

Thanks both for your answer. How difficult is it to port the lowRISCv0.4 to work with bigger FPGA? was it done by other team?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/66#issuecomment-324509022, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF13qH99zdM4NntBaLz08gtim3uWVLks5sbNWtgaJpZM4O_pbK.

[clare7]

Hi,

When I tried to adapt the changes to LOWRISCv4.0 but there seems to be issue after that, in LowRISCChip.scala.

if(p(UseVideoCtrl)) {
    **val videoctrl_axi = Module(new TileLinkIONastiIOConverter()(coherentNetParams))**
    videoctrl_axi.io.nasti <> io.nasti_videoctrl_dma
    uncached_clients :+= videoctrl_axi.io.tl
  }

during compilation, the error pointed to code line (in bold) and tracking back, it seems there is incompatibility with the videoctrl_axi declaration: val nasti_videoctrl_dma = new NastiIO()(p.alterPartial({case BusId => "mem"})).flip

where I notice there error message indicated that the parameter BusId is not undefined.

any advice?

[wsong83]

@clare7 I am not sure I understand you. What exactly have you changed and what is the error message?

indicated that the parameter BusId is not undefined

So is it defined or not defined? By a quick look, I think both BusId and "mem" are defined and actually used in current minion-v0.4.

[clare7]

Oh so sorry for the typo. The error is that the parameter BusId is not defined.

I agree with you that both BusId and "mem" are actually defined in current minionv0.4

In fact I didnt change any other code apart from adding those that are needed to add in IO slave and DMA master (according to the vga example given and also the tutorial steps in lowrisc.org)

I kind of suspect the declaration of

val videoctrl_axi = Module(new TileLinkIONastiIOConverter()(coherentNetParams))

is not compatible with

val nasti_videoctrl_dma = new NastiIO()(p.alterPartial({case BusId => "mem"})).flip

As the error message from the compilation keep pointing to this two lines. Both are needed for the following connection.

videoctrl_axi.io.nasti <> io.nasti_videoctrl_dma

And again Im not sure

[clare7]

Hi, I have checked once again and notice that

val coherentNetParams = p.alterPartial({ case TLId => l1tol2TLId }) in LowRISCChip.scala (minion-v0.4)

did not define the parameter case BusId. and then I change the line of code and the compilation works now. It should be: val coherentNetParams = p.alterPartial({ case TLId => l1tol2TLId; case BusId => memBusId })

[wsong83]

I think what you did is OK.

coherentNetParams is used to identify the parameters needed for the coherent Tilelink bus which has no AXI ports. So it is actually all right without setting a BusId.

But the TileLinkIONastiIOConverter does need BusId to identify the parameters for the AXI port. Adding BusId definition to coherentNetParams probably is not the cleanest way to do but it is OK, as nothing on the coherent TileLink bus actually use BusId.

[wsong83]

Feel free to reopen the issue if further questions remain.