[This followup was posted to comp.arch.embedded and a copy was sent to the cited author.]
Does anyone have any comments about an idea to utilize RMII PHY chips to create a custom data link between two end points without using an Ethernet MAC as the end point terminations. Is it feasible that an FPGA design could be used to create a simple real time high speed protocol between the two locations? Standard RJ45 MagJacks and Cat 6 cables could be used for the connectivity.
--
Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
Sure! I'm pretty sure Xilinx offers some standard blocks that can fit this (incompletely specified) need. And, IIRC, there may be even a few opencores offerings.
The obvious question is whether this would be cost-effective given the ubiquity of enet solutions (though you may need a special protocol that is incompatible with enet's).
Depending on whether you are trying to *exceed*, e.g., Gb speeds or something far less (10Mb) would indicate the amount of effort you would need to plan in such an undertaking.
I wouldn't be looking for ready made components to "make an Ethernet MAC in an FPGA". As a matter of fact the idea is to stay away from the higher level Ethernet protocols as much as possible.
The idea would be to use the link to repeatedly send some state from one node to the other at regular 100MB rates. The frame rate to be used for the state transfer would want to be as fast as feasible at say 1MHz or so.
The PHY plus a MagJack seems like a low cost way to achieve this as it leverages all the existing art for the physical layer of 100MB Ethernet.
The challenge is to discover what dependencies there are in the RMII to PHY path that are would be specific to Ethernet packet formatting and / or header field contents. Doing detailed reading of PHY data sheets so far has not revealed if there are any such dependences or not. So far I get the impression that a PHY -> MagJack -> CAT 5 Cable -> MagJack -> PHY link should be just a basic data pipe. There would clearly be some first level protocol to deal with such as adding leadin bytes, sync patterns, and error check information but one has those with any transport link.
--
Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
I can't tell you the details here, but I might be able to give some hints as to what to look for.
Auto link negotiation is handled by the PHY by sending particular patterns on the link - you may want to specifically disable this using the MDIO interface to the PHY.
Other than that, there are probably rules regarding runs of equal bits and DC bias which you may need to consider.
Yes, the AutoLink option needs to be turned off via the MDIO interface. Along with that the protocol would be forced to 100Mb by the same access method.
The apparent beauty of using the PHY is that much of the low level details are handled in the component. The typical RMII PHY has these things in its signal path. A 100 MB PHY will implement the following steps on the Tx path - parallel to serial conversion, 4B/5B encoding, scrambling, NRZ-to-NRZI conversion and MLT3 encoding and transmission to the magnetics in the MagJack. On the Rx path the PHY does the opposite including - adaptive equalization, DC restoration (also referred to as baseline wander compensation), MLT3-to-NRZI conversion, de-scrambling,
4B/5B decoding, and serial to parallel conversion.
--
Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
Understood. I was offering pointers to IP that you could
*inspect* to see what is *really* happening in the MACPHY "dialog"... something that isn't readily apparent when using a "canned solution".
OK. To be clear, you're wanting to implement a "smart wire". I.e., you don't plan on sticking a switch in the middle, sharing the (virtual) medium with other nodes, etc. Do you intend to operate this HDX, FDX, simplex, etc.? What happens when/if the link fails?
Many years ago, there was a move to try to leverage enet hardware for TR networks. Same sort of approach (though TR has up- and down-stream links). You might check to see if anything became of that.
There will also be some management issues that need to be addressed (depends on your choice of PHY).
Depending on your level of risk, cost, space, etc. it might be "safer" to use a "hardwired" enet link where the FPGA is just generating frames at an *effective* 1MHz rate counting on the "other end" to extract data and resynchronize with your application's "1MHz" message rate. (at that rate, each "message" is limited to just a handful of octets so encapsulating in
*any* sort of ethernet frame would mean packing more than one message into each frame) Knowing that you aren't sharing the medium means you could design your protocol with the full bandwidth available.
[I am just wary of users deciding that they can treat the physical cable AS IF it is ethernet and connect to it whatever they think is legitimate for "real" ethernet. Will a "non-standard approach" reliably "fail" in such scenarios? Or, could it find itself confused by encountering traffic that it didn't expect -- "/* XXX Can't Happen */"? A lot of that depends on your application and the users to which it will be subjected :-/ ]
I have been having a version of this discussion with a former colleague that at one time actually considered doing a "smart wire" link using a PHY in the manner that I describe. He has told me that I will have to include a block of logic inside the FPGA on each end that "acts like a MAC" because there is a bit more to the MAC PHY handshake than they tell you about in the data sheets.
This means that a good share of the comments you've made are pretty much on target. So my next level of investigation is to look around and evaluate Xilinx or OpenCore type IP for a dedicated FPGA MAC to see about stripping it down to a minimum.
--
Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
Yes, that's what I feared. I think there are things about the ethernet protocol that are so "basic" that they aren't even (consciously?) acknowledged in the designs built atop them. E.g., I suspect that the inter-frame gap is subtly (?) used in the PHYs as it is one "constant". I can't begin to imagine what other "little gotchas" might come in to play. Whether you can afford the time/money/frustration to discover them empirically... There may also be limits on just how long the PHY can operate *without* encountering an IFG. I have no idea how much black magic lies in those "mixed mode" devices!
Poke around the opencores site. There might be something else that you can cannabilize (you'll have to decide what license terms you can tolerate).
I think that once you start looking at it "one layer higher" (in the hardware), there should be enough "padding" in the design for you to figure out what stuff is "unexpected" in the PHY interface -- giving you hints as to *why* it's there.
You're operating point kind of boxes you into a corner. At 1MHz "report rate", you can't step "up" to a real ethernet protocol -- since the IFG's are ~100bit times wide! (100Mb/100b = 1MHz... no bandwidth for *data*!).
Even packing some number of contiguous "reports" into a single packet puts a rather large lower limit on the number of such reports -- lest you find yourself with "runt packets". And, of course, the MTU places limits on the top end.
Regardless, any sort of "bundling" of messages introduces some skew/delay in the communication system (not sure if that is important to you). And, requires buffering before you can resynchronize the reports with the "consumer" (again, assuming there is some timeliness constraint there).
OTOH, it looks like it would be really *fun* to explore! And, the sort of thing that, once working, would be really "satisfying"!
"The Cypress CY7C9689A TAXI-compatible HOTLink® Transceiver facilitates point-to-point data communication over high-speed serial links. Systems built with the CY7C9689A are directly compatible with legacy systems made using AMD TAXI chip devices. The CY7C9689A HOTLink Transceiver is functionally equivalent to an AMD AM7968 TAXI transmitter and AM7969 receiver pair, with numerous technology enhancements and extensions."
formatting link
"This application note outlines an implementation using AMD PHY components found in either the SUPERNET
1 or SUPERNET 2 families to drive and receive signals over shielded twisted pair media. The circuit described meets the electrical specification of the interoperable solution (PID 16011A) endorsed by AMD, Chipcom, DEC, Motorola, and SynOptics. This interoperable solution (IOS) is designed to minimize the cost of FDDI connections confined within 100 meter range by replacing the optical transceiver and fiber with a shielded twisted pair (STP) transceiver and STP cabling. If a design utilizes AMD?s SUPERNET 1 or SUPERNET 2 chipsets, no major changes are required; only a simple interface circuit from the PHY transmitter to the cable and another interface from the cable to the PHY receiver are necessary. The interface can be implemented at minimal cost and with no more board space requirements than available optical Media Interface Connectors (MICs)..."
And, the downside of this is that it now requires knowledge of the FDDIPHY interface protocols...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.