This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Arm11 clock

Note: This was originally posted on 13th October 2008 at http://forums.arm.com

Hello,

Does anyone know if there is a timestamp clock in Arm? Something like the RDTSC in intel?
Or some other high frequency clock?
I need a clock to mesure performance of my linux kernel (and I use the RTC for something else).

Thanks everyone!
  • Note: This was originally posted on 13th October 2008 at http://forums.arm.com

    I will look more deeply in the CP15 documentation, maybe this will be my answer.
    Thank you.

    About the note: I need to test the linux kernel for a hard real time system. The RTC will cause an interrupt every 1 sec, but I need to see the biggest latecy that occur, and this how I could know how fast an interrupt will handle on the system .
    I need to know exacty how many microseconds it takes.
  • Note: This was originally posted on 13th October 2008 at http://forums.arm.com

    Hi,
    Thank you for your response and for the links.
    I looked it up, and this is not exactly what I need.
    I need to measure the latency of an interrupt (in my case, the interrupt caused by the RTC). So I need another clock to see how much time it took from the interrupt till I was able to read this clock.
    I found a code that do exectly this, but use the RDTSC and I need to replace it with some kind of a clock in Arm.
    Do you know this kind of clock?

    Thank you very much,
    Liat
  • Note: This was originally posted on 13th October 2008 at http://forums.arm.com

    Thanks for the info. We know that linux isn't perfect for hard real time, but we would like to test it and see maybe it will be good enough for us.

    What do you think is the best way to measure the latecy of the interrupt?

    Thanks,
    Liat
  • Note: This was originally posted on 13th October 2008 at http://forums.arm.com

    If your SoC wires up the PMIRQ signal to the interrupt controller, you can use the performance monitor cycle counter to generate an interrupt on overflow.

    The performance monitor cycle counter wraps on overflow, so you can measure how long it takes from the time the overflow occured (PMIRQ asserted) to the time that it was serviced.
  • Note: This was originally posted on 13th October 2008 at http://forums.arm.com

    Linux is not ideal for hard real-time systems - even with the RT patch.

    For an ARM11 processor worst case for something as large as Linux is exceedingly variable, and depends on things like whether the IRQ handler is in cache or not, and other memory system related activities.

    Personal experience shows that interrupt latencies on Linux are in the order of 5000 cycles  on an ARM1176 with a 2:1 core to bus memory ratio, and only a single layer of cache. A real platform might be significantly more cycles if the memory system is slow compared to the core.
  • Note: This was originally posted on 13th October 2008 at http://forums.arm.com

    You can use the System Control Coprocessor (CP15) to perform performance monitoring. Under Linux, you'll need to do this from a driver so that you have access to a privileged execution mode.

    Documentation for CP15 in the ARM1176 can be found [url="http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333g/Bgbgbgeb.html"]here[/url]. If you're using a different ARM11 (such as the ARM1136), you'll need to look around to find it.

    [url="http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333g/Bahcaafe.html"]This page[/url] provides an overview of the performance monitor, but you'll need to fish around the CP15 documentation in order to find out how to use the registers.

    Let me know if that's what you're after,
    Jacob
  • Note: This was originally posted on 13th October 2008 at http://forums.arm.com

    I'm surprised that CP15 doesn't do what you want, but I must admit that I haven't used the performance monitor stuff before.

    It's likely that your processor has counter peripherals which may be configurable to do what you want, but you'll have to look at the documentation for the particular chip you have as I don't think that's architectural.

    On another note: RTCs typically have an accuracy of milliseconds at best, and many RTCs only give a resolution of 1 second anyway. Does the interrupt latency really matter in such a situation? Consider a very slow system: A 100MHz ARM11 core with a 1000 cycle interrupt latency. 1000 cycles at 100MHz is just 10 microseconds.