How to read the MPC8245 Data Cache-Line "MEI State" Metadata?

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

How to read the MPC8245 Data Cache-Line "MEI State" Metadata?

1,942件の閲覧回数
eric_d_peterson
Contributor I

Greetings! 

We have a need to write a utility to determine the number of dirty “modified” MPC8245 cache-lines when it's called ;  using a hook the utility will be called during supervisor state as Green Hills INTEGRITY-178 partitions are swapping.

Looking over the MPC8245UM documentation did not yield any obvious way to do this:

  • The cache lines are not fully memory mapped, the metadata is hidden, so I can't just read the MEI State and extract the the "M" (modified) status. 
  • There don't appear to be any dedicated cache specific assembly instructions to read the MEI State out for each cache line. 
  • There don't appear to be any SPRs that get updated with MEI State data when assembly instructions related to data cache lines are executed. 
  • Considered using the Performance Monitor, but can't determine which of the possible events gets triggered upon each write-back of a dirty cache lane to main memory. 

If you have any other alternative ideas for methods to achieve this goal, or other useful information that might make one of the possible approaches above work let me know.

Regards,

-Eric 

タグ(1)
0 件の賞賛
返信
5 返答(返信)

1,888件の閲覧回数
eric_d_peterson
Contributor I

I realize I'm likely being overly optimistic given the age of this processor, but does anyone have any ideas? 

So far there doesn't seem to be any straightforward directly supported ways to do these measurements. 

I have come up with an indirect multi-step process that might work:

  • In a dedicated cache Unit Test measure the worst case time to write a full dirty data cache write-backs to main memory.
  • In a companion Worst Case Execution Time (WCET) test that puts the Flight SW under a Worst Case scenario measure the time to do the write-backs as the SW is running. 
  • Lastly, predict the number of dirty cache lines written back to main memory during the WCET test by interpolating using the measured WCET time and the Unit Test Time as inputs. 
0 件の賞賛
返信

1,862件の閲覧回数
yipingwang
NXP TechSupport
NXP TechSupport

I agree with you, no direct exact method due to inability to read tags/status of cache lines. Besides to your idea, one possible time lengthy estimation method and will have side effect of invalidating cache lines is to:

1- use the dcbf instruction in a loop that spans the address space that the code is allowed to use.
2- after the loop count how many cast outs or writes been done to SDRAM (pages) which represent all data cache lines that were modified [do math]

===============================================
remember that for the dcbf:
• Coherency required
— Unmodified block—Invalidates copies of the block in the data caches of all processors.
— Modified block—Copies the block to memory. Invalidates copies of the block in the data caches of all processors.
— Absent block—If modified copies of the block are in the data caches of other processors, causes them to be copied to memory and invalidated in those data
caches. If unmodified copies are in the data caches of other processors, causes those copies to be invalidated in those data caches.


• Coherency not required
— Unmodified block—Invalidates the block in the processor’s data cache.
— Modified block—Copies the block to memory. Invalidates the block in the processor’s data cache.
— Absent block (target block not in cache)—No action is taken.
======================================================

0 件の賞賛
返信

1,838件の閲覧回数
eric_d_peterson
Contributor I

Hello,

Thanks for getting back to me so quickly!

Any suggestion as to how to implement this? "after the loop count how many cast outs or writes been done to SDRAM (pages)" 

I'm planning to do the math to predict the number of dirty cache lines based on the timing of the flush() loop as an aggregate because I will know how long it takes to do the same loop over a clean cache. 

Is there a Performance Monitor event that can be used to count the write-backs that I can check after the loop exits? Or, by [do math] are you referring to something like I'm already proposing? 

0 件の賞賛
返信

1,816件の閲覧回数
yipingwang
NXP TechSupport
NXP TechSupport

Thank you for the follow up. Please see some inline answers in Below:

 

Q1)Any suggestion as to how to implement this? "after the loop count how many cast outs or writes been done to SDRAM (pages)"

A1) I was thinking possibly SDRAM event # 0x66 [Total number of hits to page 0, 1, 2, and 3, pipelined and non-pipelined] , assuming no other master besides to core is accessing SDRAM. In the code loop if the generated addresses are aligned with cache line boundaries [one per cache line] then if the cache line was valid and modified then it will be flushed to some SDRAM pages, thus get caught by event # 0x66. So the 'do math 'comment was meant for you to correlate cache line flush with the event counter increments. This is just an idea and i do not have code for it.

 

Q2) I'm planning to do the math to predict the number of dirty cache lines based on the timing of the flush() loop as an aggregate because I will know how long it takes to do the same loop over a clean cache.

A2) that idea sounds with assumption of no other master is doing SDRAM access and so on.

 

Q3)Is there a Performance Monitor event that can be used to count the write-backs that I can check after the loop exits? Or, by [do math] are you referring to something like I'm already proposing?

A3)  Please see A1.

0 件の賞賛
返信

1,878件の閲覧回数
yipingwang
NXP TechSupport
NXP TechSupport

Discussing with the AE team, will provide more update later.

0 件の賞賛
返信