Timer Tile Offset?

[gerrykurz]

Can anyone explain what this function does and how it works?

From the ethernet_rx_client.xc source file:

Code: Select all

void mac_get_tile_timer_offset(chanend mac_svr, int& offset)
{
  unsigned server_tile_id;
  int other_tile_now;
  int this_tile_now;
  timer tmr;

  send_cmd(mac_svr, ETHERNET_RX_TILE_TIMER_OFFSET_REQ);
  mac_svr :> server_tile_id;
  mac_svr :> other_tile_now;
  tmr :> this_tile_now;

  if (server_tile_id != get_tile_id_from_chanend(mac_svr))
  {
    offset = other_tile_now-this_tile_now-3; // 3 is an estimate of the channel + instruction latency
  }
  else
  {
    offset = 0;
  }
}

[gerrykurz]

So what it does it seems to do is measure the timer offset between tiles, is this correct?

How does it do this?

How can I do this if I am not using this library?

[gerrykurz]

More specifically to my application, I have two L16 chips running off the same clock and reset.

What would be a reasonable expectation of the timer offset between all four timers and how could I determine the offset?

[larry]

Correct, this function measures the timer offset to the tile where Ethernet MAC is running. It's 0 if it is the local tile.

The implementation is simply for the MAC side to sample its timer and return the value. You can see this in ethernet_rx_server.xc where the ETHERNET_RX_TILE_TIMER_OFFSET_REQ command is handled.

Timer offset between two L16 devices will depend on the order and timing of their power up.

[gerrykurz]

How can I measure the timer offset between two L16 devices?

Or more specifically, how does the timer tile offset function actually work?

[gerrykurz]

Never mind, I think I can see how it works...

[myndideal]

hi,
i guess, the timer values can be different even if two tiles are built on the same chip.

The chip with two tiles, uses one PLL block wich is reachable from the one switch subsystem. (one pswitch control register we have) but different tiles can start the boot procedure on different clock pulse.

The easiest situation if software reset occures. Becasue of the software reset is relating to only one tile. I dont know if there are other exact reason, but probably could be... (I.e. different codes running if one is booted from flash or xlink. I dont know if the brown out logic is doubled or not, etc... But nevermind... )
The two tile's timer registers values are not the same theoretically, at all.
Rather the delta(timer) values of the same chip are the same, because these are running on the same (I hope) clock. Which is good information for us...

So , two tiles must calculate a common/general time value if it is necessary for the application.
And if two tiles are on the same chip, it is only a mathematical addition, but if these are on a xlink bw defferent devices , they must syncronize its clocks periodically because of the xtal clock drift can be a problem in long runtime ..

In situation a) the problem is not difficult, we have to send a channel message between local tiles once (or rearly). Assume we have a master and a slave tile, the master could use local timer value, the slave will calculate its own, rather than simple read the register. It needs to add the drift of the remote time - message time. Message sending time depends on switch subsystem, we hope it is a constant value... Or somehow we can measure it.

In situation b) there are two problems. The message arrival time can be a variable . And the two different hw clock/pll could add a jitter. (theoretically) This two variable needs to measure by tiles runtime and periodically.
The basic idea is the syncronization have more than one steps. We sends message between tiles, we have a book keeping about the other tiles. The message contains not only the remote time, but we have to send back the arrival timestamp too. It helps on calculation of the message transmitting time (drift bw the sender and arrival). The different clock rates and the message arrival time together can be calculated. (no need to implement a division to your mathematical form) So after that, all of the information is ready for calculating a common time value, which is accessable by the application.
The application still able to use local timestamp, and hw support for it, but it have to calculate by a fn call, which add the actual drift to the global time to get the local time value...

There is some protocol, but I did not tested/seen yet. Practically it would be nice if we have a simple library for this above tasks. :) I think that app notes have to have some soloution for this, which are demonstrates remote audio streams...

[gerrykurz]

Thanks for the feedback.

In my application, both chips are running off the same 25 MHz clock so there should be no drift between the two parts.

So it is simply a matter of reading the timers off both tiles and getting the difference, allowing for the instruction latency of doing this.

In the avb ptp code, the instruction latency is estimated to be 3 but I have measured it to be in the 10 to 12 range so I am using 11. The only unknown is the latency in setting up the routing between two tiles as I did the latency measurement on a single tile.

If anyone knows what the difference in latency is between sending a packet between two channels ends on a single compared with sending a packet between two channels ends on different tiles (using the router and xlinks), I would appreciate knowing that.

[gerrykurz]

If anyone has an idea of how to solve this issue, it would be appreciated.