100BaseFX Ring with Ethernet Synchronus mode of clocking

This is an interesting application, but certainly not a standard implementation that was considered during the design of the parts.  As such, some of these questions have not been explored and I may not be able to offer firm technical guidance on some aspects of your design.

The Synchronous Ethernet functionality in the DP836x0 devices was conceived for point to point connections over CAT-5 cables, but should operate similarly over fiber optic cables.  The data presented in the Synchronous Ethernet application note, AN-1730 / Literature Number SNLA100 (http://www.ti.com/litv/pdf/snla100) should still be applicable. 

As shown in the application note, it is possible to achieve 1ns peak-to-peak synchronization between the master and the slave in a point to point application. No data exists on the additive nature of this synchronization in a ring or how many nodes in a ring can be supported. 

The only tolerance or stability specifications provided for the crystal oscillator are those in the datasheet.  Those specifications are determined based on the needs for meeting IEEE 802.3 specifications. 

I'm not sure I understand the question on connecting TX_EN to RX_DV.  Could you please clarify?  Are you only intending to receive data at each slave node and pass it along to the next slave node?

Patrick

Hello Patrick,

My concern is about the possible cumulative build-up of jitter if the 25 MHz recovered RX_CLK of the phy is used as internal transmit clock of the same phy when used in Sync Ethernet mode and this is done successively at each node. If the build-up of jitter is unacceptable, how to avoid it? A way out could be to to use two phy in a node instead of one? The first phy only receives, then its RX_CLK is dejittered, and then used as "Crystal" clock of the second phy, which only transmit data. In this case Sync Ethernet mode is not needed as first phy at the node only receives, and second phy only transmits.

Also, the idea in using RX_DV as TX_EN comes from the fact that all the ethernet frames will be of the same size - with drop-insert of data being done by the user logic at successive slave nodes. But for this the RX_CLK of phy receive  has to be synchronous with TX_CLK. Will this be so if Syn Ethernet mode is selected?  However, any need to dejitter the RX_CLK will not allow RX_DV-TX_EN synchronization, and possibly a FIFO will need to be used.

Hoping to see your comments.

Hemant

I apologize for the delay in getting back to this.  We have done some testing of systems using Synchronous Ethernet mode, but have not done significatn testing while daisy chaining multiple devices in series to evaluate the cumulative build-up of jitter.  I believe additional clean up of jitter would be required if more than one device was daisy chained. 

One way to think about this is to consider the relative synchronization and jitter through one device and the allowable input reference jitter for the next device.  While we have not measured this extensively, we do have some data to help us bound this to the first order. 

For operation over CAT-5 copper cables, we have measured the transmit jitter at the cable relative to jitter on the input reference clock.  The IEEE specification for maximum transmit jitter in 100Base-T is 1.4ns.  In our testing, we have determined that our devices can meet this 1.4ns spec with 800ps of jitter on the reference clock.  For more details, you can refer to our reference clock jitter tolerance application note (http://www.ti.com/litv/pdf/snla091a).  For this reason, we recommend a maximum of 800ps of jitter on the input reference clock. 

As reported in our application note on Synchronous Ethernet Mode (http://www.ti.com/litv/pdf/snla100), we have measured synchronization of <1ns peak-to-peak from from an upstream master reference clock to a local or downstream SyncE recovered clock. In limited testing, I have also measured the short term and long term jitter of the local SyncE recovered clock and found it to be comparable (<1ns) to the synchronization measurements.  I believe the accumulated jitter would quickly exceed the allowable limits over multiple hops.

Patrick

Patrick,

I am opening this topic again as we are actually into the implementation of a synchronized ethernet ring. I have a few questions.

1. You have mentioned earlier post that CLK_OUT pin of P83620 can output receive recovered clock if we want to use it for dejittering and supplying to X1 clock of a subsequent stage.  I suppose even the RX_CLK signal can be used directly for this purpose. Please clarify.

2. We are using on-chip PLL of Lattice XP2 FPGA to dejitter the recovered clock from DP83620 for the above mentioned purpose. Do you think that should suffice if we were to supply the PLL output to a subsequent stage's X1 input of DP83620?

3. When we do chaining in this way, data transmission seems to get affected in one direction (in the direction in which we use a XP2 PLL to dejitter recovered clock  at every stage and give it as X1 clock of the next stage). However in the reverse direction (i.e. the direction of Synchronous ethernet loop clocking at every stage)  we observe no data errors in as many as 16 stages. Do you have anything to say here? Would you like to say that the internal dejittering by DP83620 of its own recovered clock for using it  internally for synchronous ethernet loop clocking to transmit data in reverse direction will be better than the  dejittering of RX_CLK through an XP2 based  PLL? But if such is the case, the subsequent stages will also suffer as it is the XP2 PLL output that acts as X1 clock input to the subsequent DP83620 stage, and hence should equally affect the Synchronous ethernet loop clock in the subsequent stage of the chain.

4. Do you think that if XP2 PLL does not provide sufficient dejittering, a use of two cascaded PLLs will improve the dejittering performance? Our XP2 FPGA has two PLLs, and both are available.   

5. Otherwise can you suggest  any other circuit or IC for this dejittering?

Hemant