RMII over FFC - Page 1
Forum section: electronics / projects

author: xgr1279
author_rank: Newbie
timestamp: August 24, 2017, 04:27:45 am
content: I have an application that will have an MCU connected to an Ethernet PHY (100Mb). It would be helpful to have that PHY on a separate board from the MCU, for a few reasons:- There's just plain not a lot of space on the MCU board, so placing an FFC connector instead of the PHY + magnetics would make the layout substantially easier.- Some variants of the final box will not need network at all, some will need just a single port, and others will have a built-in Ethernet switch. Separating the PHY means I can just replace the single-port PHY with a switch controller with an RMII port, or leave the PHY off entirely as needed.- The external network connector can't be on the MCU board anyway due to mechanical constraints--so no matter what, there will be some sort of cable involved in getting Ethernet out of the box.- There will be a PCB with some other interface circuitry located with the network connector anyway, and I can put the PHY on that.The thing that gives me pause is I'm not sure how sensitive the RMII interface ultimately is, and how much of a problem running it over an off-the-shelf unshielded FFC might be. (I would consider shielded, but it doesn't look like shielded FFC cables are something readily bought off the shelf.) I've looked at a handful of different PHY datasheets, and they generally don't give much in the way of AC characteristics on the R/MII side. I guess such things are covered by the IEEE spec--one TI app note(PDF)says that the spec calls for a 68R impedance, and recommends 50R source termination. Some PHYs advertise built-in termination, others don't make any mention of such features. According to another reference, the rise/fall time is meant to be 1-5ns (per the spec? Not sure). That TI app note also suggests that trace lengths should be kept to <6in/150mm and matched to <2in/50mm, which seems to be an awful wide margin for 1ns signals.I think I can keep the total path length from MCU to PHY--including cable--to about 6in. According to published tests by Meritec (PDF), their plain, unshielded 0.5mm pitch FFC, with interleaved signal and ground, has a single-ended impedance of 70R, so that theoretically means I can aim for a continuous ~68R through the whole connection. So, the whole thing doesn't *seem* like such a bad idea, and after all, MII was meant to be run through cables anyway, right? However, I don't have enough experience in high speed signals to be super confident that this will be reliable and not a tremendous EMC problem. I'm also not sure how much I can rely on plain FFC to consistently hit something close to Meritec's impedance spec, particularly across different suppliers (Meritec seem to want a large minimum order, but I can buy off the shelf from Molex and others). The materials and dimensions seem to be fairly consistent across manufacturers, but I haven't seen an actual impedance spec from any other manufacturer.Any key factors I'm missing here? Is running RMII over FFC a bad idea? Or am I overthinking things?

author: AndyC_772
author_rank: Super Contributor
timestamp: August 24, 2017, 07:17:25 am
content: If I recall correctly, RMII has a clock which is centred within the data window, so you have plenty of setup and hold margin, and the length of the cable shouldn't be an issue for that reason. That's also why you can get away with very relaxed length matching, if indeed that's something you need to consider at all.You do need to check the static timing requirements of your chosen CPU and PHY, and work out all your setup and hold margins taking the length of the cable into account.Provided you know the impedance of the FFC, and can more-or-less match it, you shouldn't in theory have a problem with the clock becoming non-monotonic - but this is definitely something you should check if at all possible once you have a prototype. You'll need a very fast scope and an active probe for this.Do consider EMC. An RMII interface on a CPU is unlikely to have output drivers which are well controlled for edge rate, so expect some high harmonics of 50 MHz. Perhaps include sites for some small series ferrite beads, which you can always replace with 0R links if you find you don't need them.If you can't find an FFC with a ground plane, at the very least you should have a ground trace next to each signal trace, even if it's just: G S S G S S G S S G or similar. You might find it's fairly straightforward and inexpensive to have an FPC made to your requirements by a PCB fab, in which case that would probably be a better option than trying to find something off the shelf.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: August 24, 2017, 10:20:57 am
content: RMII is quite benign and forgiving.If you decide to control the edge rates just remember that it's the PHY that generates the clock, not the MCU. You probably know that anyway.Leo

author: AndyC_772
author_rank: Super Contributor
timestamp: August 24, 2017, 10:32:25 am
content: Where does it say that?IIRC the reference clock can be supplied by the MAC, or is an input to both MAC and PHY from an external 50 MHz source.Slightly OT, but the PHY contains a small FIFO used for rate matching, to cope with any slight mismatch between the line rate and the reference clock used by the MAC.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 24, 2017, 10:45:12 am
content: Try it with a 12" cable to be sure you have enough margin for 6"

author: xgr1279
author_rank: Newbie
timestamp: August 24, 2017, 02:25:44 pm
content: Thanks for all the responses so far! I guess I need to look at the setup and hold timing a bit more closely, so that will be the next step.Quote from: blueskull on August 24, 2017, 04:36:25 amThat's a good point, I hadn't considered that aspect of the clocking.Quote from: AndyC_772 on August 24, 2017, 07:17:25 amThe MCU is an STM32F7, which has selectable drive strength, so I have some control there. The prototype would definitely have provisions for additional passives.QuoteI've sketched in a 40-pin FFC, which provides for GSGSG across all of the RMII connections (which is also the configuration that Meritec says gives 70R single-ended) and still has room for a few additional signals I'd want to get to the IO location. The FPC idea is interesting. Looks like I can get ~50R microstrip pretty easily. However I'm not sure how to handle the ground connections. As far as I know, direct FFC/FPC connectors universally make all of their connections, including to any shield, on one side of the FFC/FPC (to accommodate a stiffener on the other side). With a 0.5mm pitch, it doesn't look like I'd be able to fit the vias required to make a ground connection from the top side contact pad to the ground plane next to every signal connection. I could probably do a ground connection every 3rd position, but that would require jogging the adjacent signals around the via and an attendant impedance shift. I guess I'll need to look at the geometry a little more closely, but I'm open to suggestions here. Maybe GGSSGGSS...? That should give enough room for vias at each ground pair.Quote from: AndyC_772 on August 24, 2017, 10:32:25 amNominally, yes, but it seems to be a somewhat common feature in PHYs that they can be configured to provide REFCLK to the MAC from a local 25MHz crystal.Quote from: mikeselectricstuff on August 24, 2017, 10:45:12 amGood idea. The part that most worries me is that it will work fine over a handful of prototypes but then not be reliable in production and necessitate a redesign later on.

author: Scrts
author_rank: Frequent Contributor
timestamp: August 24, 2017, 04:00:49 pm
content: I've had some EMC failures when used crystal to generate the clock for the PHY, so then moved towards the clock supplied by the MAC.

author: xgr1279
author_rank: Newbie
timestamp: August 24, 2017, 05:08:22 pm
content: Do you know why clocking from a crystal on the PHY failed, but clocking from the MAC didn't? I'm not sure why that in and of itself would make a difference.

author: Scrts
author_rank: Frequent Contributor
timestamp: August 24, 2017, 06:22:48 pm
content: It seemed that PHY fired up a generator for the XTAL, which caused increased power consumption and then noise emitted at high frequencies. Supplying that from the MAC resolved the issue.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: August 24, 2017, 08:00:10 pm
content: Quote from: AndyC_772 on August 24, 2017, 10:32:25 amGood question, I have no idea why i said that.I was probably thinking about internal elasticity buffer and clock domain mess in RMII compared to MII.Leo