MPC5777C - Performance Monitor for SRAM accesses

[MatheusFranklin]

Hello!

I need to count the number of read and write accesses to the internal SRAM of the MPC5777C. I raised some options to do so, but I would like to know which one of them is correct and more accurate and if there is any other way to do so in a better way. Consider that in my software architecture the only used XBAR masters are the e200z7 cores, the flash memory stores the instructions and constants, the SRAM stores data variables.

My theories:

SRAM read accesses = Com:87 (BIU data-side requests performance monitor)

or 

SRAM read accesses = Com:57 (DCache linefills performance monitor)

SRAM write accesses = Com:88 (BIU data-side copyback requests performance monitor) [cons: does not count write-through requests]

Best regards,

Matheus

[davidtosenovjan · Accepted solution]

BIU data-side requests would count both accesses, cached and cache inhibited.

Second tho events only cache related.

I cannot tell it what is "accurate" it depends what you wanted to count avtually.

[MatheusFranklin]

1-Does the Com:87 (BIU data-side requests performance monitor) counts only data read operations to the sram or it also counts read operations of constants in the flash?

2-Com:87 count a 4 beat read burst to the SRAM as 1 access or 4 accesses?

3-Does the MPC5777C have any performance monitor that counts all types of writes to the SRAM (copy-back and write through)?


Best regards,
Matheus

[davidtosenovjan]

1) It is needed to realize that performance monitor is tool of the core itself. BIU event are all related to accesses external to the core.

2) 1 access. Also you have event 89 for counting of cycles.

3) Event 88 count copybacks. write-through is normal transaction and will be included in 87/89

[MatheusFranklin]

Thanks for the explanation, David!

A few more questions:

I did not understand what does the following performance monitors measure: Com:86 (BIU instruction-side cycles), Com:89 (BIU data-side cycles) and Com:90 (BIU single-beat write cycles).

Do they count the number of cycles taken to finish each transaction? Is the purpose of this data to extract the variability (i.e., standard deviation) of the cycles taken to attend each transaction?

Do they count the total number of cycles taken to issue all transactions performed until the moment of reading the performance monitor?

Can you give me a practical example of usage of these performance monitors, please?

Best regards,
Matheus

[davidtosenovjan]

Com:86 (BIU instruction-side cycles) - how many clock cycles takes instruction fetch
Com:89 (BIU data-side cycles) - how many clock cycles takes data access
Com:90 (BIU single-beat write cycles) - how many cycles are single beat transfers, i.e. aligned 8/16/32/64 bit writes (not misaligned or bursts)

How performance monitors are used depends on the optimization needs for a particular application. I am attaching screenshots from presentation I have already mentioned in another your thread.