[lowrisc-dev] MP-Rocketchip system communication

Wei Song ws327 at cam.ac.uk
Wed Mar 9 17:11:43 GMT 2016


Hello Stefano,

I think you will get better hints on this issue by posting your question
on the RISC-V hw-dev mail list.
We, members of the lowRISC project, are not the original developers of
the Rocket chip.

We have recently removed the host target interface, so my memory for
host target interface is becoming vague now.
I am not sure how you changed the address space.
The size of available memory to Rocket is hard coded in the
htif::mem_mb() function.
The sequence you see for htif is the way how htif works.
Host target interface sends packages to the Rocket HTIF, which then
reads/writes memory.
So the address you see probably is the memory mapped address of the htif
port (I could be wrong).
The actually memory address is encapsulated in the htif package.
The address space separation (ARM and Rocket share the same DDR memory)
is hard wired in the rocketchip_wrapper.v
Should be this line:
assign S_AXI_addr = {4'h1, mem_req_addr[21:0], 6'd0};

I should also point out, host target interface is going to be removed as
well in the Rocket-chip by the RISC-V team.

Best regards,
Wei

On 09/03/2016 16:51, Stefano Cillo wrote:
> Good afternoon,
> we are trying to implement a generic Rocketchip multiprocessor system with 
> accelerators, interconnected by a NoC.
> We are currently designing the system on the Zedboard and trying to understand 
> the communication between the ARM core and the Rocketchip through the frontend 
> server. We'd like to put two (or more) Rocketchips on the AXI bus with 
> different addresses and configure them to execute different programs using 
> separate DDR spaces.
> The problem is that if, in Vivado, we change the Rocketchip memory address 
> space from 512MB to 256MB it doesn't work. Therefore we are analyzing frontend 
> server code to understand where the RISC-V executable is loaded (in the fesvr-
> code, and exactly at which address). We found the LOAD_ELF macro inside 
> elfloader.cc, which calls memif->write, which in turn calls htif->
> [read|write]_packet, which finally calls htif_zedboard->write: this last 
> function however seems to write always to the same AXI address, that is the 
> Rocketchip starting address on the AXI bus.
>
> We then would appreciate any hint on the files or functions responsible of the 
> ELF load address and the starting address of the Rocketchip execution, in order 
> to be able to change that address for each different Rocketchip and make the 
> cores run in parallel executing different programs.
>
>
> We are aware that the fesvr is capable to run only one Rocketchip at a time, 
> and solve its system calls, but we will consider that problem later on.
>
>
> Many thanks,
> Stefano Cillo
>
>




More information about the lowrisc-dev mailing list