Hello!
As written in the MPC5777C RM, the XBAR has 7 master ports and 7 slave ports. In a "theoretical" XBAR, it is impossible that a transaction between a master and slave interferes with a transaction between other master and slave. There are dedicated paths that connect single master ports to single slave ports, being temporal and functionally isolated from each other. However, I found some weird results while performing timing analysis.
1) To mitigate interference, I allocated the PRAMC_0 memory region to core 0 an PRAMC_1 memory region to core 1. Since the cores are connected to different master ports and PRAMC 0 and 1 are connected to different slave ports, I thought that there was not any kind of hardware resource competition between the cores in this scenario. However, when I allocated the data from core 1 to the external RAM through the EBI, the execution time of the task being executed in core 0 decreased. Since, theoretically, there would not be any competition, I expected that nothing happened to core 0 execution time. Why would the execution time decrease in this scenario?
(ps: the same benchmark software was executed in core 0 and core 1 simultaneously, triggered by a global interruption. The execution time measurement unit is microsseconds. WT and WB stands for the write-through and write-back cache policies)
2) Other unexpected result is the little execution time difference between allocating both cores to access the same PRAMC and different ones. I expected that this difference would be bigger, since different PRAMCs would parallelize the accesses, increasing performance. However, it seems that using different PRAMCs does not help so much. A difference of 1-2 us in execution time is negligible in this test. Should this difference be bigger?
Best regards,
Matheus
It is not clear according to your description whether you are measuring data accesses or instruction execution time of code located in SRAM.
I suppose you are executing code from internal FLASH. Flash is accesses over two ports, but parallel accesses may only be to flash controller’s mini-cache (basically pre-fetch buffers). So ideally you should executed the code for measurements directly from cores‘ caches memory to eliminate flash access impact.
Another point crossing my mind is how you measure a time interval. If you toggle pin, it is access over PBRIDGE and it may influence timing if accesses by both cores.