I am working on an 100BASE-FX (fiber mode) application and am considering the DP83630 PHY to interface to my molex SMI series fiber transceiver. The DP83630 datasheet indicates "In 100BASE-FX mode, the device Receive pins connect to an industry standard Fiber Transceiver with PECL signaling through a capacitively coupled circuit."
The reference design of the transceiver indicates that it supports LVPECL as does the DP83630. The sample schematic of the DP83630 indicates no AC coupling capacitors on the RD- and RD+ pins. The reference design of the tranceiver shows AC coupling capacitors and advises additional buffering depending on the input sensitivity of the PHY.
I cannot find any information as to the input sensitivity of the RD- and RD+ pins on the DP83630??? All the datasheet says is that the RD- and RD+ pins must be biased to 3.3 volts for correct operation.
Can any fiber PHY experts shed any light on this?
Thanks
Rich,
The RD+/- pins are designed to detect LVPECL levels of VDD - 0.9V and VDD - 1.7V. In other words, based on a 3.3V supply, signals above 2.4V would be seen as high and signals below 1.6V would be seen as low. The design has some margin to these values, but these are the nominal thresholds.
For the DP83630 FX interface, the transmit driver does not output LVPECL levels. Therefore, the TD+/- pins must be AC coupled and properly terminated to interface correctly with an LVPECL compatible fiber transceiver. The receiver and signal detect inputs are designed to accept LVPECL levels so AC coupling is generally not necessary for the SD or RD+/- pins.
If you could identify the specific transceiver you plan to use and provide a datasheet or a link to a datasheet, I would be glad to review it and see what recommendations I can make regarding the interface to the DP83630.
Patrick
We are using the Molex 1061083100 which from what I understand is using Firecomms EDL300E/D transceiver. I have attached the app note on this3264.F01469_App_Note.pdf
Thanks for checking this out
Rich
Thanks for sharing the application note on the fiber transceiver. It helps me understand the need to scrutinize these connections. The transceiver uses LVDS levels so the connection to the Phy is not a simple LVPECL to LVPECL connection.
The Phy transmit signaling is typically 0.5V single-ended so that should not present a problem. The signals can be AC coupled to the fiber transceiver. On the Phy side, the signals will be pulled up to the 3.3V supply via 50 Ohm terminations as shown in the datasheet and the reference design schematics. On the fiber transceiver side, the recommendations shown in the application note can be followed.
The Phy fiber receiver expects LVPECL signal levels, but is sensitive enough to detect 550mV signals. Therefore, I believe the simple interface circuit shown in figure 4 (a) of the application note can be used. In this configuration, the signals are AC coupled and terminated with 82 Ohm resistors to the 3.3V supply and 130 Ohm resistors to ground. Note that the standard configuration shown in the DP83630 datasheet and the reference design schematics reverses these termations (130 Ohm resistors to the 3.3V supply and 82 Ohm resistors to ground) in order to keep the DC level below the receiver input level when there is no signaling. This would be something to evaluate during testing.
For the signal detect, you should implement an LVDS to LVPECL converter, something similar to the SN65LVCP23 converter shown in figure 6 of the application note for the receive signals. The fiber signal detect is essentially DC so it cannot be AC coupled, but a direct connection is not recommended based on the different interfaces.
If you are developing a prototype board, you might consider placing footprints for SN65LVCP23 converters for the transmit and receive paths. They should not be necessary, but would give you an alternative for evaluation if you see any issues with the signal levels. Hopefully they could be implemented with a minimum impact on the signal integrity of the transmit and receive paths and ideally they would be unnecessary and would be left out of the final build. That would be the conservative approach, but based on the documentation in the Firecomms application note, it should not be necessary.
Thanks for the info. I will look into your suggestions