XMOS Static Timing Analyser - Designing With XMOS

[jason]

RSwWpPobA_0

Join Kris Jacobs and David May, as they discuss one of the key features the free XMOS design tools - the static timing analyser.

One of the very important features of XMOS processors is its ability to behave in a very predictable and deterministic manner. You can now accurately predict exactly how long it will take to get from one point in a program to another point in a program - in our example we show how this is particularly important when implementing Ethernet. Watch the video to learn more and see it in action.

You can download our desktop tools for free right now and try out the static timing analyser for yourself at: http://www.xmos.com/

[lilltroll]

I should test out the timing analyser with my prototype for fast "Softfloats" since the f-ADD is based on if() statements. Maybe I should add 'nop' statements in such a way that the call/function/method always takes the exact amount of time, independent of it´s inputs.

With the determenistic way you can really use the threads to the maximum load.
I have tested with FIR filters for the fixed point case, using like 218 TAPS at high speed without any glitches or problems, but 219 taps totally gets starved out of time.

[jason]

Sounds like a good idea - let us know your experience with it!

[Heater]

This is awesome. I have not worked with a software tool chain that can tell you the execution time of you code since working with the Lucol language in avionics systems. There we were only dealing with meeting 10 or 100 millisecond deadlines. It was neat how the Lucol compiler would print out the min and max execution time of a module or a collection of modules every time they were compiled.

Now, there must be limits to this timing analysis. Code with loops can make analysis impossible. At what point does it give up?

[andrew]

Thanks. As you would expect there are limits to what you can analyse. Currently you cannot time across threads and if you have a top level function that has an enormous call graph then the memory requirement are high.

Code with loops however present it with no problem, also the compiler will detect some of you loop counts automatically while others will have to be configured manually.

The version you'll be running is very memory inefficient. With the nearing release you will be able to time almost anything with a massively reduced memory footprint. We've been working on it a lot so it will be a notable improvement.

We're happy you like it.

[jonathan]

Code with loops however present it with no problem

I'm assuming that rather than having solved the halting problem, you are talking about those loops where static analysis of the bounds can be successful.

Does it fail gracefully when static analysis fails?

[Heater]

"Code with loops however present it with no problem"

Well the problem will be loops where the loop count is an unknown input or when I throw the Mandlebrot set at it:)

So guess the answer is in the "manually" part of it.

Does this work with both C and XC ?

[andrew]

We have designed the static analysis to never fail during analysis but the tool cannot always detect the number of iterations a loop takes. For this reason sometimes the user is required to tell the tool the number of time a loop iterated. For example, if a loop iterates a number of times that is derived from the input of a port then the tool requires that the user enter a worst case.

The XTA works from the binary in order to accurately model the instruction buffer. For this reason any binary will work regardless of the language it was derived from. However, the XC compiler emits a bunch of data for the XTA that tells it certain properties of the binary. Without this extra data the results cannot be as accurate. In the future our LLVM compiler which supports C will also emit this.

[jonathan]

I guess I should just try it, but what does it do with code like this?

Code: Select all

#include <stdio.h>

int i = 0;
int x = 1;

int main () {

 while (i < x) {
  x = x + 1;
  i = i + 1;
 }

 printf("%i",x);

}

[jonathan]

I guess I should just try it, but what does it do with code like this?

Code: Select all

#include <stdio.h>

int i = 0;
int x = 1;

int main () {

 while (i < x) {
  x = x + 1;
  i = i + 1;
 }

 printf("%i",x);

}

OK, it just says loop iterations are unknown. I'm just interested in what point it decides to give up trying to find the number of loop iterations.