Connectivity

[luka_csl]

Hi,

We're trying to build a system with:
    * one master device that uses multiple GTPs, each with it's own Aurora 8B/10B core
    * and multiple receivers that are connected to the master

We want to achieve perfect synchronization on the receiving sides.
eg.: master sends a command, all the receivers have to react at the exact same time.
 
I found some information about latencies in Aurora User Guide, page 107.
It states: "Maximum latency for a 2-byte designs from TX_SOF_N to RX_SOF_N is approximately 52 GTP/GTX transceivers clock cycles in simulation."

Looking at this one would think that SOF_N (Start-of-Frame) command could be used as a synchronization pattern but its latency is described as "approximately" and "in simulation" which isn't deterministic at all.

Based on this I presume that this kind of synchronization is impossible, am I right?
eg.: multiple receivers will produce a bit different delays when decoding SOF_N command and so will recognize this command at different and undeterministic timestamps, correct?

Can this problem be tackled with some other solutions?

 
Thank you in advance for your help.

Message Edited by luka_csl on 01-15-2010 05:29 AM

[kamrank]

So the latency that is described in the User Guide is deterministic and is consistent in normal conditions. Trace delays can add latency to the link. Also if you have multiple receivers you will have to maintain that all the receivers have the same delay to receive data correctly. 

This is possible but you have to plan out links carefully and match or account for any delay between the channels. Branching the links also will cause SI issues at the branch nodes which will need to be investigated. 

[jeanb_deleted]

Hi

Did you had a precise answer to your interesting and important question^

Thank you

[luka_csl]

jeanb, I have then opened a WebCase with the same question. Conclusion was that Aurora is not suitable for applications that require hard deterministic responses on multiple receivers.

We have solved this issue by designing our own custom protocol on top of 8b/10b encoding. We now have complete determinism plus allow transmission of low priority data in the background. All this is full duplex.