Can anybody explain the XMOS Timing Analyzer to me?

[Interactive_Matter]

I have to confess I really like the XTA. But I do not really get it and the documentation is not helping me either - or at least I am too dumb to understand.
What I understand is that I can time a programm and that does not really help if it is the Release Version since there are the line numbers missing so that the XTA cannot time from a certain point in source to a certain time in source.

It puzzles me that XTA is never able (or at least XTA pretends) to time a given piece of code. Since it does not know how much time it takes to read from a channel (esp. if streaming), read from a timer, wait for a timer and so on.
Is there any list of timings to assume for those things?
I know you cannot know how long it takes to read a value from a streaming channel. But how long does it take for an X if we assume that it is there.
I asumme if I add all the assumptions as defines the XTA will be able to analyze my code. Right?

But what information does the 'Trace in console provide?

Is there a way to analyze best case scenarios? Since the XTA should be able to calculate these.

Why can't it analyze how long the code waits for a timer? It is not possible for XTA if not all assumptions about unknown timings are given - but once they are there it should be able to calculate how long the waiting will be. Or am I completely on the wrong track?

Thanks

Marcus

[kris]

Hi Marcus,

Well, in terms of documentation, we are a little lacking at present, but the xta reference manual will be released soon (within the next couple of weeks), so hopefully this will answer some of your questions. However, in the meantime...

In terms of timing from source level, the compiler supports a number of pragmas which can be used, and are maintained even in release mode. e.g. '#pragma xta endpoint "start"'

Currently, if you time a chunk of code that includes i/o operations, the xta flags these as warnings as in general, it will not be able to work out how long each one will pause for. However, there are some cases where it can know (e.g. waiting on a timer), and it should be extended to deal with these cases in the future. The current use case is mainly geared toward timing between i/o operations though.

The trace in the xta conosle gives the instuction trace (+ instruction timings) of the worst case path bewteen the 2 points. It can also be configured to display the best case path.

Along with the worst case, the best case timing is also currently displayed. However, it only calculates the timing for the two extremes, i.e. not all the ones in between. However, in the xde, the timing distribution view attempts to give a visualisation of the distrubution of the timings of all the paths.

Hope this helps,
Cheers,
Kris.

[Interactive_Matter]

Hi Marcus,

Well, in terms of documentation, we are a little lacking at present, but the xta reference manual will be released soon (within the next couple of weeks), so hopefully this will answer some of your questions. However, in the meantime...

Good to know and keep up the work. Even for my daddling around I would like to use the timing analyzer more often.

In terms of timing from source level, the compiler supports a number of pragmas which can be used, and are maintained even in release mode. e.g. '#pragma xta endpoint "start"'

good to know.

Currently, if you time a chunk of code that includes i/o operations, the xta flags these as warnings as in general, it will not be able to work out how long each one will pause for. However, there are some cases where it can know (e.g. waiting on a timer), and it should be extended to deal with these cases in the future. The current use case is mainly geared toward timing between i/o operations though.

Is there any kind of list how long typical 'unknown' operations take - so that I can make more elaborated guesses as my 'dunno - it is one cycle so fill in 10ns'?

The trace in the xta conosle gives the instuction trace (+ instruction timings) of the worst case path bewteen the 2 points. It can also be configured to display the best case path.

OK, just have to read the output a bit more carefull - is there any difference in the calcuation to the timing in the IDE? Or the other way around do I get meaningfull numbers from one method if I do not get them from a second method?

Along with the worst case, the best case timing is also currently displayed. However, it only calculates the timing for the two extremes, i.e. not all the ones in between. However, in the xde, the timing distribution view attempts to give a visualisation of the distrubution of the timings of all the paths.

Hope this helps,
Cheers,
Kris.

Just a suggestion: is'nt is possible to use some kind of debugger integration to really measure the timing? Because if the program runs in the debugger the real timing should be known.

But thanks for the answer. They will certainly help me to use it better and come up with more questions! ;)

Marcus

[kris]

Hi Marcus,

Generally, when the xta flags an unknown, this is due to finding an instruction that can potentially pause on the worst/best case path. As to typical timings, these could be just about anything, as it depends whats on the other end of the port/channel/etc. However, the tool assumes a pause time of zero (on top of the time taken to execute the instruction itself), so if you know that the data at the other end of the port/channel is always ready, then the warnings can safely be ignored.

The trace timings in the xta console should be identical to those reported in the routes view of the XDE, as both come from the xta. Hopefully (in the cases where the xcore does not pause) these should also match the timing reported in the simulator output also..

We could try to integrate the timings from the debugger/simulator into the xta. However, the
the problem with this is that it is dynamic, thus will only tell you the time taken for whichever path you are currently executing. The benifit of the xta is that it is static thus attempts to confirm that the timing requirements are met for all possible paths.

Cheers,
Kris.

[Interactive_Matter]

Hi Kris,

thanks for the elaborate answer. I am a bit puzzled since very often my XTA displays a lot of warnings (which is understandable since my code can get chatty from time to time). But in the path view I nearly always see 0 for all blocks - even though in the instruction structure view on the left I get real timings. This puzzles me a bit. I think the path view is quite nice to understand and therefor I ask myself how to get the numbers in there.

The analysis of a program at run time would be an addition from my point of view. So that you can get worst/best case/ distribution timing e.g. from running the program for a minute or so. By that you can easily verify the assumptions you have made for the timing of certain unknowns. But this is really a nice add on and no functionality I am really needing.

Thanks for you help

Marcus

[kris]

Hi Marcus,

Not sure about the difference in the reported timings in the different views.
They should just be diffferent ways of displaying the same information, thus
should be the same. Could you maybe attach a screen shot of what you are seeing?

In terms of runtime profiling, the simulator supports gprof output + the trace gives
the cycle sounts for each instruction. On the hardware, xscope is probably the closest thing
to code profiling we offer at present.

Cheers,
Kris.