how to get physical address of an allocated memory in ReconOS

[Guanwen (Henry) Zhong]

Dear ReconOSers,

I explain my situation first: I try to build a hw IP. The IP will first read a structure S (by sending its s_address of S with MBOX_GET in hw part) into hw buffer. The structure S contains memory addresses of arrays (for example, a_address of array A). Then the IP will start reading data from a_address of array A with axi burst transfer and do the computation.

I have setup a customized ip core with hls and it passed hw simulation. However, when I ported it and ran on the zedboard, it got stuck on "reading, waiting for data".

The reason I think is that for s_address of S, reconos can automatically translate the virtual address to the physical address and HW IP can get its corresponding data. However, the a_address of array A inside S is still the virtual address. So, I'd like to ask how I can get the physical address of a_address in ReconOS?

Thanks,

Guanwen

[Christoph Rüthing]

Hi Guanwen,

okay, so just to make sure I have understood your problem correctly. You have implemented you own hardware thread which accesses the system memory via the ReconOS memory interface, i.e. it is not a custom ip core having it's own custom interface to the bus. The structures you have described look like the following:

struct S
{
    uint32_t *a_address;
    uint32_t *b_address;
    uint32_t *c_address;
};

uint32_t a[100];
uint32_t b[100];
uint32_t c[100];

struct S s = { &a, &b, &c };

Now you send the address of s (s_address) to the hardware thread via an mbox and read the entire struct via MEM_READ. Later you read an array pointed to by a_address also by MEM_READ, correct?

RAM(uint32, 100, ram);
uint32 s_address = MBOX_GET(resource_...);
uint32 a_address;
MEM_READ(s_address, &a_address, 4); // note, that we currently only support to access whole words (4 byte), also ram needs to be uint32
MEM_READ(a_address, ram, 400);

Thereby, both s_address and a_address are virtual addresses and should be translated by ReconOS automatically. You do not need to worry about physical addresses inside of your hardware thread but should only use virtual ones. The MMU implemented by ReconOS is completely transparent to the hardware thread and has no interface to get a physical address from a virtual one. I am not quite sure why you want to translate those on your own, you can just use the virtual a_address to access the memory via MEM_READ. Or do you want to access the memory without the ReconOS memory interface?

Stucking in "reading, waiting for data" means, that the delegate thread is waiting for any data from the hardware thread, so for example an MBOX_GET to acknowledge a finished processing. If you need further help you might want to share your implementation, so that we can have a look at it.

Yours,
Christoph

--
You received this message because you are subscribed to the Google Groups "ReconOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reconos+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guanwen (Henry) Zhong]

Dear Christoph,

Thanks a lot for your kind reply. :-)

>Now you send the address of s (s_address) to the hardware thread via an mbox and read the entire struct via MEM_READ. Later you read an array pointed to by a_address also by MEM_READ, correct? 

Yes, you are correct. I am doing in this way.

>I am not quite sure why you want to translate those on your own, you can just use the virtual a_address to access the memory via MEM_READ. Or do you want to access the memory without the ReconOS memory interface?

I checked your mmu vhdl implementation this afternoon. It looks like all memory address (virtual) will go to the TLB to find the physical address. So I guess I do not need to worry about the virtual address. You're correct. I am still not quite familiar with all components in ReconOS. :-)

My custom IP works on floating point computation. As you mentioned, ReconOS currently only supports uint32_t. I bypass this issue with a tricky approach and from simulation results, it works.

>Stucking in "reading, waiting for data" means, that the delegate thread is waiting for any data from the hardware thread, so for example an MBOX_GET to acknowledge a finished processing. If you need further help you might want to share your implementation, so that we can have a look at it.

That's great! Appreciate your kind help. :-) As this is a work-in-progress project, I send the source files directly to you.

Best regards,

Guanwen