How to benchmark code on FVP_MPS2_Cortex-M4 simulator?

Hi Ronan

Thanks for your answer. My reason for wanting the counter is to provide a clock source for the C++ std::chrono library. I will investigate whether they will work together. BTW what do you mean by 'thread mode'?

Best regards

David

Hi Toshihisa

Thanks for your answer. 

> Which version of FVP do you use?

I am using:

FVP_MPS2_Cortex-M4 --version

Fast Models [11.14.21 (Mar 16 2021)]
Copyright 2000-2021 ARM Limited.
All Rights Reserved.

> BTW, FVPs and Fast Models aren't suitable for performance measurement 

What should I look at to provide cycle-accurate simulation?

Best regards

David

Hi Toshi and Ronan, thanks for indicating that the issue is fixed in 11.15. I downloaded 11.16 and, indeed, it does look fixed.

Can you tell me, please, how to determine the clock frequency of the FVP_MPS2_Cortex-M4 simulator?

Best regards

David

Hi David,

Thanks for the updates. I am glad that now you can see it works.

The core (Cortex-M4) in the FVP_MPS2_Cortex-M4 is running at 25 MHz and SysTick timer in the FVP is running at 25 kHz. These clock frequencies are hard-coded in the FVP so they cannot be changed. FYI, I've checked this in the source code of the FVP.

Kind regards,

Toshi

Hi Toshi

Thanks for your reply, I confirmed your figures by executing:

OS_Tick_GetClock() = 25000000 =25Mhz  ('OS Tick time clock frequency in Hz')

OS_Tick_GetInterval() = 25000     therefore, tick freq is 1kHz, i.e. 1ms period

So that is consistent with what you wrote.

However, I then measured the elapsed clock cycle count and tick count for osDelay(10000) which gives a delay of 10s (confirmed by stopwatch).  If found:

Elapsed cycle count = 31327755           which suggests an interval of 31327755/25e6=1.2531s @25MHz

Elapsed tick count (start-stop): 5010     = 5.01s @1ms tick

So the cycle count appears to be running 8x slower than the system clock and I can't explain the tick count.

Here is the code I used:

  	#define CM_DEMCR               (*((volatile unsigned int*)0xE000EDFC))
	#define CM_TRCENA_BIT          (1UL<<24)

	#define CM_DWT_CONTROL         (*((volatile unsigned int*)0xE0001000))
	#define CM_DWT_CYCCNTENA_BIT   (1UL<<0)

	#define CM_DWT_CYCCNT          (*((volatile unsigned int*)0xE0001004))
  
  void start_cyccnt()
  {
    CM_DEMCR |= CM_TRCENA_BIT;
    CM_DWT_CONTROL |= CM_DWT_CYCCNTENA_BIT;
    CM_DWT_CYCCNT = 0;
  }

  unsigned int stop_cyccnt()
  {
    CM_DWT_CONTROL &= ~CM_DWT_CYCCNTENA_BIT;
    return CM_DWT_CYCCNT;
  }
  
  
  printf("10s start\n");
  start = OS_Tick_GetCount();
  start_cyccnt();
  osDelay(10000);
  printf("10s cyccnt: %d\n",stop_cyccnt());  
  stop = OS_Tick_GetCount();  
  printf("10s tick count (start-stop): %d\n",(start-stop));
  printf("10s stop\n");

and my results:

10s start
10s cyccnt: 31327755
10s tick count (start-stop): 5010
10s stop

Can you explain these figures please?

Best regards

David 

Hi Toshi and Ronan

I'm still struggling with obtaining meaningful timing info from CM_DWT_CYCCNT.  I wrote a simple loop and timed it using the start_cyccnt() and stop_cyccnt() functions that Ronan suggested above. Here are the code and the results:

As you will see, the values seem increasingly meaningful as the total loop count increases, but the numbers are meaningless for a loop count of 75 or lower. Also, given that this is a cycle count, i.e. at least one cycle per instruction, a count of 1040 must be wrong for a loop count of 1000.

I wonder if the simulator is working correctly?

Do you have any thoughts on this, or any suggestions for an alternative timing method, please? (RTOS tick would be too coarse).

Best regards

David

Hi David, this is not totally unexpected, and goes to the same issue that Toshi said earlier, that Fast Models are not 100% cycle accurate.

I think what you are seeing here is an affect of the 'quantum' of instructions that Fast Models use to accelerate execution. If you single step though the loop with low cycle count, do you get different numbers?

Hi Toshi and Ronan

Thanks for your replies. It's pretty clear that FVP and fast models aren't suitable for my purposes. Does ARM offer a cycle accurate simulator for Cortex-M4? I realise it may be slow but we could tolerate that. If so, could you please tell me where I can obtain it?

Best regards

David

I've started a new thread 'Cycle accurate simulator for Cortex-M4?' as this one seems to have run its course.