TLM2 DMI interface

[rahuljn]

I have a 64K memory in my target, can I read it at once using memcpy through DMI interface ?

Can I also read the same memory using b_trasport call(if DMI is not allowed) ?

 

What is better from the folloiwng(with DMI)

- reading entire memory at once

- or in steps(may be data equals to buswidth at once)

 

and which one is better with b_transport API

 

Thanks

RahulJn

[apfitch]

Yes you can read with DMI using memcpy.

You can also read with memcpy using b_transport.

 

Regarding which is better for DMI, it depends on the level of modelling accuracy you require, and how your model works.

If you are (for instance) modelling the transfer of instruction code from flash memory to RAM at the beginning of your application, then you would be better using DMI and transferring all the data in one go.

 

If you need to model the effect of burst transfers which are interleaved with other initiators, then it might be better to transfer small chunks at a time so you can find interactions between your initiators and fix them.

 

With b_transport, again it depends on the level of modelling accuracy you require (timing accuracy). If you want to model realistic bus bursts (perhaps because you are later going to refine the model to AT) it would make sense to perform small transfers. If you are loading  a RAM from flash, it would make sense to do a long burst.

 

The idea of DMI is it is a performance optimisation which speeds up simulation at the expense of accuracy by minimising the number of function calls.

 

regards

Alan

[rahuljn]

Thanks Alain.

I have one more question related to this.

 

Support I have to transfer 64 bytes using DMI so I will call b_transport first (e.g for first 4 bytes) and if DMI can be done, target set the DMI flag. The on return I will check the DMI flag and if set, get the dmi ptr and use DMI for rest of 60 bytes. To remove the DMI access, tagte calles the invalidate_dmi API.

 

Is it fine ?

What is the use of start and end address in invalidate_dmi API. Can you give  me a small example of  invalidate_dmi API whcih uses these arguments.

 

Thanks

RahulJn

[apfitch]

The idea of the dmi hint is that you can look at it after each transfer. So you might as well send the whole 64 bytes using b_transport (you've got to make the function call anyway, and it's using memcpy). On b_transport's return, if the dmi hint is set, you can then request access to a region of memory. On the next transfer to that same region, you check if the address is in the region that dmi is allowed. If it is, you just do a straight memcpy.

 

Regarding invalidation, you have to remember that multiple initiators may have requested dmi access to the same memory region. So any interconnect may have to forward the invalidate call back to multiple initiators.

 

If you have a single target and a single initiator, it's easier, the invalidate call just goes straight back to the initiator and tells it that dmi access to a particular region of memory is no longer allowed.

 

The start and end address in the invalidate call allows the target to specify a particular region of memory that is invalidated. For instance suppose you have three targets 1, 2 and 3 at locations 0->9, 10->19, 20->29 in the memory map.

 

An initiator could request dmi access to location 15. Target 2 might then say "ok, you can have access to locations 15->19". Then an initiator may request access to location 10. Target 2 may say "ok, you can have access to locations 10->12".

Now if the target for some reason decides to disallow dmi access to locations 10->14, it could send the invalidate addresses between 10 and 14, which wouldn't affect the initiator which had access to locations 15->19.

 

If there's an interconnect in between, then the target 2 would say "I'm invalidating 0 to 4" and then the interconnect would translate it in the memory map 10->14, then forward the call on to *all* initiators that had requested dmi access in memory map locations 10->14.

 

kind regards

Alan

[rahuljn]

Hi Alan

 

Thanks for this detailed explaination.

So if I have to transfer 64K bytes from initiator to target then I can

- call b_transport() with full 64 bytes length

- call get_direct_mem_ptr() and if it returns true then use memcpy

Which one will be faster ?

 

Do I need to call get_direct_mem_ptr() before every transfer to see if DMI is possible or not.

 

Consider invalidate_direct_mem_ptr() call, I am using a flag in initiator to set it inside this. If I have 3 regions then do I need to use 3 flags(one for each range)

 

 

 

Thanks

Rahuljn

[apfitch]

Hi, you don't call get_direct_mem_ptr unless the dmi hint is set. There is an access method to find the dmi hint from the generic payload (is_dmi_allowed or something - I don't have the standard to hand).

 

The idea

 

a) make a normal transfer

if dmi hint is set then call get_direct_mem_ptr with the requested access and address range.

c) if get_direct_mem_ptr returns a valid dmi region, then use it "forever".

 

If an invalidate is received, and it invalidates your current dmi memory, then go back to step a) above.

 

You only need to call get_direct_mem_ptr() once (unless of course you need to retrieve multiple non-contiguous regions of memory).

 

You don't need to call get_direct_mem_ptr() again *unless* the region of memory you are using is invalidated.

 

Regarding your last question, yes the initiator must keep track of all the dmi regions it has requested.

 

regards

Alan

[rahuljn]

Hi

I have one small query related to this, suppose I have to transfer 64k bytes now as per experts suggestions in this post I should call b_transport first and then if target allow DMI,it will set dmi hint and then I use DMI

 

Now for a case where I want to transfer just 64K bytes(after that either I access different memory region or some normal register read-write), and if I call b_transport with full 64k bytes, then even if target allows DMI I can not use DMI as I passed all 64K usiing b_transport.

 

Is there a way to use DMI in this case ?

 

Thanks

[mdamm]

Hi, you don't call get_direct_mem_ptr unless the dmi hint is set.

 

[...]

 

The idea

 

a) make a normal transfer

if dmi hint is set then call get_direct_mem_ptr with the requested access and address range.

c) if get_direct_mem_ptr returns a valid dmi region, then use it "forever".

 

...but this is not a rule, right? As I interpret the standard, an initiator can request DMI access to some memory region as its first action if it wishes to do so.

 

Now for a case where I want to transfer just 64K bytes(after that either I access different memory region or some normal register read-write), and if I call b_transport with full 64k bytes, then even if target allows DMI I can not use DMI as I passed all 64K usiing b_transport.

 

Is there a way to use DMI in this case ?

, suppose I have to transfer 64k bytes now as per experts suggestions in this post I should call b_transport first and then if target allow DMI,it will set dmi hint and then I use DMI

 

As I see it, you could call get_direct_mem_ptr() right away to (try to) get DMI-access right away.

 

I have a question myself: How does an initiator specify the size of the memory region it wants to get access to? With the data length attribute? I couldn't find anything in the standard on this. Or is the idea that the initiator just sends the start address x for the requested region, and the target then grants access to a region [x,x+l] with l as large as the target deems possible?

[apfitch]

Yes you don't have to use the dmi hint - it's just an optimization to avoid repeated polling should the call to get_direct_mem_ptr not return any access. See 11.2.9 in the LRM.

 

Regarding the size of memory request, your second option is the case, i.e. this statement you made...

 

"Or is the idea that the initiator just sends the start address x for the requested region, and the target then grants access to a region [x,x+l] with l as large as the target deems possible?"

 

regards

Alan

[charan]

Hi,

 

I have a query regarding how can i inerface memory to my program , through b_transport.

and am having a traffic_injector also and how can i interface these.....

 

Am going to do read operation and am having length of data ,address,pointer

 

regards,

charan