Real time measurement in Microblaze Processors.

[mdarmanu]

I am working on the Cora-Z7s board. My goal is to measure real execution time in seconds for Microblaze Softprocessor.

I have added AXI timer IP in the hardware design. But from my understanding AXI timer give us the Clock cycle values. We can devide it by the clock speed to get time (it will be theoratical). 

But is there any way to get real execution time in Microblaze processoers?

Edited September 24, 2021 by mdarmanu
Missing tags

[D@n]

@mdarmanu,

How "'real time" do you want your measurement to be?  If you measure clock cycles on a 100MHz clock, the result time 10ns should equal wall time.  In m estimation, the clocks Digilent uses tend to be accurate to within about 1-20ppm or so.

If this isn't "good enough" for you, you'll need to start with a better oscillator.  The GPS PMod can help, but ... it's not perfect.  It will only produce a pulse to lock on to once per second.  For some problems, running the algorithm many thousands of times over and then measuring seconds in this manner may be good enough--but it is a lot harder than the first method.

Bottom line: "It depends" on your requirement, and how accurate you need things to be.

Dan

[zygot]

I frequently instrument my FPGA designs involving a processor, usually a PC, in HDL using a counter. Obviously, you can clock a counter at any frequency to produce a reasonable resolution, what ever that means. But the real question is this: what does the concept of real time measurement mean to you?

Resolution and accuracy are two different but related concepts. For a processor like a PC running Ubuntu or Centos there are a lot of variables that will affect any measurement. So capturing min/max elapsed times over longer sessions is likely to be more accurate than capturing one snapshot and figuring that this value means something. There's also the problem that measuring elapsed time in HDL logic might give a false impression about how often a processor might be able to repeatedly do a particular thing. Really, any such measurement depends on what you are looking for. My point is that however you define "real time execution" the approach, and the interpretation of results is likely to be more complex than you anticipate. This is true even for a soft-processor with no interrupts or OS involving code or data in external memory. There's measuring execution time to perform a task but usually latency between when you make a function call and when the actual task is executed is more important to any assessment of performance; particularly for anything involving USB or PCIe, or SDRAM for a soft-processor in logic, for instance.

Clocking a counter at 100 MHz for microsecond "accuracy" is a way to over design measurement resolution when your measurement unit is seconds. But does it really help with accuracy? Maybe. Likely not. There are measurements that are high resolution.

There are measurements that have high accuracy. There are measurements that have high resolution. And of those, some are useful for drawing a particular conclusion for insight, and others are just misleading. Of course there's the 'other' type of measurement, which is a homework assignment where the goal is to see what the student has learned by presenting a solution to a problem.

Edited September 25, 2021 by zygot