I have a ASIC chip which has a Ethernet MAC MII interface (10/100 speed) and it needs to talk to a CPU (NXP i.MX6 processor family) which also has a MAC MII interface & USB2 interface. I've read that you can't connect MAC MII to MAC MII directly without a PHY - the protocol won't work. Is that true? Basically I need an expert on Ethernet IEEE 802.3.
I have read on some forums where MAC-MAC connections (RMII, RGMII, SGMII) without PHY may have worked though.
Direct MAC-MAC connection to Ethernet switch without a PHY
mac to mac connection,bandwidth 10Mbits/sec
Otherwise I have read this on direct MAC-MAC physical connections. But I don't know if this has ever been tried.
http://caxapa.ru/thumbs/414271/Schematic_Design_Guideline%2C_MAC-to-MAC_M.pdf
Otherwise I need some sort of 'bridge' chip to connect the two together.
I think there are two possible solutions:-
1) Use a 2-port ETH Switch chip and connect the PHY's together. Therefore ASIC MAC MII to ETH SW MAC MII, short both PHY outputs together, then ETH SW MAC MII to CPU MAC MII. Possibly NXP TJA1102.
2) Use a USB2 to PHY bridge. Though I can't find one that outputs a MAC MII interface. I presume I have to connect it to another single port ETH PHY/MII chip (i.e. similar to option 1 above).
Notes:
1) ASIC VIO is 1.8V
2) The EMAC IP core used in the ASIC is Overview :: 10_100_1000 Mbps tri-mode ethernet MAC :: OpenCores , this does NOT produce a 25MHz ref CLK. Therefore an external one is required.
Summary of Direct ETH MAC MII to MAC MII connection without a PHY.
In the end I abandoned this idea so never attempted it.
However if someone wants to do this, then these are the key points to consider:-
1) IEEE802.3 spec does NOT support direct MII-MII connections, therefore you have to 'hack' your system to get it to work (note: but other direct connections are supported, eg RMII, GMII, RGMII etc).
2) Some IC's have 'MAC-MAC' mode, which should in theory allow MII-MII. These are typically found on ETH peripherals like ETH Switch's or ETH PHY. They are mainly there for test/debug purposes. You don't usually find them on the host IC's, ie CPU's or FPGA's (unless the IP core supports it). So its a matter of digging deep into datasheets and software drivers.
3) You must use full-duplex mode.
4) Clock delay: below shows the physical MII-MII connections with a external 25MHz ref CLK. Note that both CLK's need to be delayed by ~2ns. However this would equate to 12 inches of copper tracking (based on the 6in/ns FR4 rule of thumb)! Therefore it would be wiser to use a CLK delay/phase delay chip instead - unless this CLK delay is support internally by the IC's, but BOTH need to support that feature.
So in theory if you connect it up as shown, set both IC's to MAC-MAC mode, with CLK delay and as full-duplex - it should work.
Summary of Direct ETH MAC MII to MAC MII connection without a PHY.
In the end I abandoned this idea so never attempted it.
However if someone wants to do this, then these are the key points to consider:-
1) IEEE802.3 spec does NOT support direct MII-MII connections, therefore you have to 'hack' your system to get it to work (note: but other direct connections are supported, eg RMII, GMII, RGMII etc).
2) Some IC's have 'MAC-MAC' mode, which should in theory allow MII-MII. These are typically found on ETH peripherals like ETH Switch's or ETH PHY. They are mainly there for test/debug purposes. You don't usually find them on the host IC's, ie CPU's or FPGA's (unless the IP core supports it). So its a matter of digging deep into datasheets and software drivers.
3) You must use full-duplex mode.
4) Clock delay: below shows the physical MII-MII connections with a external 25MHz ref CLK. Note that both CLK's need to be delayed by ~2ns. However this would equate to 12 inches of copper tracking (based on the 6in/ns FR4 rule of thumb)! Therefore it would be wiser to use a CLK delay/phase delay chip instead - unless this CLK delay is support internally by the IC's, but BOTH need to support that feature.
So in theory if you connect it up as shown, set both IC's to MAC-MAC mode, with CLK delay and as full-duplex - it should work.
