The XTA timing pragmas are wrong

[shuchitak]

http://bugzilla.xmos.local/show_bug.cgi?id=16234

Peter Hedinger 2014-12-12 14:10:40 GMT
The lib_ethernet/tests/test_4_1_4 is failing now that I enabled filler threads to stress the timing.

The root cause is that the current inter-frame timing pragmas is wrong. The XTA says it will meet timing but in reality it doesn't. This is because the pragmas are wrong, not because of an issue with the XTA.

The timing path of interest is:
#pragma xta command "analyze endpoints mii_rx_eof mii_rx_sof"
#pragma xta command "set required - 1560 ns"

The reason this timing is wrong is that the worst case code actually starts when the DV goes low at the same time as the last byte of a word is received. In that case, the end of frame actually starts going once through the mii_rx_word loop before even starting the inter-frame gap.

With the current code the timing will not be met as the current route only has 168ns slack when it will require 300ns slack:

xta: lib_ethernet/src/mii_master.xc:71: warning: route(2) Pass with 4 unknowns, Num Paths: 12, Slack: 168.0 ns, Required: 1.6 us, Worst: 1.4 us, Min Core Frequency: 446 MHz

Peter Hedinger 2014-12-12 14:12:20 GMT
Looking at this in more detail, the test passes when I make the target a 500MHz part. So, either we are still not exercising the worst-case path through the code or the XTA is being pessimistic.

The question is whether we are able to say that we are only targeting 500MHz parts or whether we must meet timing with 400MHz part?

[shuchitak]

The filler threads are currently enabled in https://github.com/xmos/lib_ethernet/blob/develop/tests/test_rx/src/main.xc and test_4_1_4 is passing with the XCORE-200-EXPLORER target. Since we don't need to support the 400MHz part any longer this issue can be closed after some more investigation into the test.