non_axi4_bridge_read/write address translation

[rag...@vt.edu]

Hi Jon,

For OS boot, in files "non_axi4_bridge_read/write.v" , I see "virt_addr" is passed as is as awaddr/araddr. I see out of range addresses to DRAM , eg 0x80000040, it seems it is getting wrap around on DRAM address bus width of 30 bit. Was it intended? Why don't we have actual physical address after NoC router or axi noc bridge? I noticed this even when SD image gets copied to DRAM.

My design worked fine with UART pitonstream test, because you do "storage address translation" which maps address to physical space which was my understanding. I expect physical address after NoC router.

Can you please give little details here?

Thank you!,

Raghav

[rag...@vt.edu]

Hi Jon,

I did subtract DRAM START ADDRESS =0x80000000 from the address that NoC AXI bridge gives, then SD card copy and OS got booted fine. Because my custom design which sits before memory controller expects within the range physical addresses (that is 0x0000,0000 to 0x4000 0000  for 1GB DRAM or 0x0 to 0x8000,0000 for 2GB DRAM space).

But I am still curious to know why that is not the case in normal openpiton design. It is NOT affecting baseline openpiton functionality because DRAM address bus width is of 30 bits for 1GB DRAM on genesys2, so higher bits gets truncated.

Thanks,

Raghav

[Jonathan Balkind]

Hi Raghav,

 

Yeah I'm pretty sure the expected functionality is wrapping. Ariane's memory base being set to 0x80000000 wouldn't have caused issues for the boards we normally run on and I think the behaviour for F1 with larger memory is totally different (it has that f1_mc_top).

 

Out of range accesses when not using pitonstream will be caught by the packet_filter anyway so this shouldn't break for any peripheral kind of stuff.

 

Probably the wisest thing for us to do would be to use the XML to pass in the memory base and subtract that out as you did, but we haven't needed to change this for any boards so I'm not sure if it's worth the effort. We'd need to make sure we caught all the places we needed to do the substraction and hope that the tool could mostly optimise it out so as not to affect timing.

 

Thanks,

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/822d51f2-53f3-47fd-8a7f-da6be6815bdfn%40googlegroups.com.