2010-06-18 05:34:25     BF561 Core B executing slowly

Document created by Aaronwu Employee on Sep 26, 2013
Version 1Show Document
  • View in full screen mode

2010-06-18 05:34:25     BF561 Core B executing slowly

David Brandt (DENMARK)

Message: 90412   




I'm doing a dual core bare metal project on a BF561.


The main part of the code resides i the L2 memory.


During my tests I've noticed that Core B executes code much slower than Core A (roughly a factor of 4 slower).


Is there any way to setup individual core speeds? I would like to get Core B running as fast as Core A. Any thoughs on what could be slowing it down?




2010-06-18 08:55:31     Re: BF561 Core B executing slowly

Jean-Christian de Rivaz (SWITZERLAND)

Message: 90417   


The thread below already show the problem 2 years ago:




As far as I known this was never formally confirmed, but my theory is that the problem is the consequence of how the memory arbiter share the SDRAM between the two cores. It's like if the core A take alway the priority over the core B, and that the core B only take the rest. So the slowdown of the instruction counter of the core B result not from a lower core frequency, but from a increase of stall of the pipeline due to the memory pressure from the core A.


Depending of the code running on the core A, you get a different slowdown on the core B. If nothing heavy is running on the core A, then the core B get the expected performance. In my test load, I was getting half the performance of the core B. In your test load you only get a quarter. You probably heavily use the SDRAM from the core A, even if your core is in the L2. Maybe you use some common resource other than the SDRAM that exhibit the same sharing problem between the two cores.






2010-06-18 09:20:35     Re: BF561 Core B executing slowly


Message: 90418   




As the 561 HRM indicates:




Fig 7-5 shows a common bus between the 2 cores, and L2 memory, which is controlled by an L2 CORE BUS ARBITER.


and goes on to say:




Arbitration for Core L2 port access requests is based on a fixed priority scheme. Core A, Core B, and IMDMA, in order from highest to lowest priority, are the granted requestors of the Core L2 port. There is no arbitration while the current Core L2 bus requestor is performing locked or Cache Line Fill transactions.


Once either Core A, Core B or IMDMA is granted the Core L2 bus, no other user can access this bus until the data transaction is accepted by L2 memory.




So - if both cores are running instruction fetches from L2 memory - Core B will only execute while Core A is stalling...


The keyword is "fixed" - there isn't much to do - execpt move the hot spots to L1, or turn on cache, and see if that helps.






2010-06-18 09:49:52     Re: BF561 Core B executing slowly

David Brandt (DENMARK)

Message: 90420   


Thanks guys.


It seems I have to see if I can fit the hot parts of my Core B code i L1 then.