Hello everyone,I am facing the following problem:I have two boards: The ML505 (XC5VLX50TFFG1136) and the XtremeDSP (XC5VSX50TFFG1136) which use the same Marvell 88E1111 chip as Ethernet physical medium.I have built a design based on Ethernet Mac core (Opencores) so that I set up a communication demo, where PC is donloading some RAW frames to FPGA, FPGA is processing and returns the results to PC. The demo is fully functional on the first board (ML505), whereas in second board (XtremeDSP), the Marvell chip does not perform auto-negotiation.Have anybody face a same situtation? The schematics of these two boards are almost the same (same pinout of marvell chip and same connections of every signal to PCB board.) Also I have checked the on-board jumbers that enable the MII mode.
![](/uploads/1/2/6/5/126578888/683668013.jpg)
(actually they are the same on two boards.)Why the physical medium is not operating with the same chip? Do I have to set up the mode (MII) manually, i.e. By using MDIO commands.
The efficient design of the Marvell Alaska® Gigabit Ethernet (GbE) PHY 88E, 10// BASE-T PHY with multiple MAC Interfaces, Technical Marvell phy 88e1111.
Where can I find such an example/tutorial?Thanks,Dionysisp.s. By faulty auto-negotiation I mean the fact that neither led-blinking in both PC and FPGA is happening when I insert the ethernet cable (as happening with ML505 board), nor the PC can bind a connection with the FPGA through device driver. PC seems to not recognize any NIC when I plug the ethernet cable in XtremeDSP (in contrast to ML505). The 88E1111 has a number of strapping options to set up the device. That beingsaid, it usually takes very little for the 88E1111 to link up with the PC (a bit moreto link up with the FPGA's MAC). If you're not getting a link, I'd first check that the88E1111 is getting a clock and all required voltages, then check that the jumpersare set for the correct physical layer (I'm guessing twisted-pair copper?).Also make sure that your magnetics are wired the same as the ML-505.
Be carefulif you use a Mag/Jack (integrated magnetics RJ45 jack) as different brands haveslightly different wiring even when they have the same magnetics circuits. Did youdesign the board yourself or is this another eval board / kit?- GaborEdit Check out this thread. Hello everyone, many thanks for the replies.@joelby: u remeber right. It has negative logic reset.
That was also my first hope for the faulty operation, but after all my operational design (on ml505) was exactly the same with XtremeDSP, and two boards have the same PHY chip (and negative reset logic).@gszakacs: I found out that indeed there was a problem with the clock. The auto-negotiation solution came when I switched SW6 to '10101010' (depicted below) which makes frequency synthesizer (ICS843001-21) to ouput 100MHz, as described in ML505 manual, page 47, table 1-31. However in the same manual there is NOWHERE written that MII Ethernet mode needs such a configuration. Even this configuration applies to PCI-Express application according to table 1-31.By carefully examining the ML505 schematics, one can see that the appropriate clock for MII mode is only 25MHz clock (XTAL1 = CLK25MHZENET) generated by IDT5V9885 EEPROM programmable clock generator. Thus it is not clear how the configuration of ICS843001-21 chip affects the operation of 88E1111 chip in MII mode (but it does!).So, now that I have a working XtremeDSP board (which is actually ML506 I have a worst problem again with 'devil' Marvell 88E1111 chip in a Virtex-6 board (Specifically the PHY chip seems to be dead. There is no auto-negotiation operation. No led-blinking, no connection recognition by PC (as happens with ml505, ml506).
I spend several weeks in trying found if something happens with the clock (the problem with ML506 board above). I made several measurements to the clock and voltages of this chip (actually 2 chips since this board has two ethernet ports - same problem with both of them), and it seems that there is no problem.Can anyone help me understand what does the following Tables means. (These tables from ml50x and HTG manual respectively)From ml50x manual:From HTG manual:Where bit0. Bit1, and bit2 applies to? Apart from the jumbers for MII mode, I cannot find any other jumbers related to those pins.
However I still cannot understand what this CONFIG options means. From the link that gszakac provided there is a similar problem, but still it cannot help me, so guys HELPP!!Does anyone have a way to read the internal registers with MDIO commands (VHDL??), since I understand from 88E1111 manualsomeone needs accurate clocking commands to do that. Any template???Thanks,Dionisis. From my board's sxhematics (1st image below) I undestand that I can only drive CONFIG4 and CONFIG5, since all other CONFIG pins are hard-wired to 2V5 or ground, is it right?Now, regarding CONFIG4 and CONFIG5, i am getting the following information from 58e1111 datasheet (I have authorized access for it):, but nowhere else does the HWCFGMODE referred in the datasheet.In the following picture (HTG board schematics), is the Bit2:0 column in the left Table corellated to Bit0,Bit1,Bit2 columns in the right table?Finally, the 'address bits' to which bus are referred?Many thanks,Dionysis. Hello, from the last table I uploaded (configuration options) in previous post, can anyone help me understand which of the two following jumber settings are correct for MII mode (A or B)?I understand that on configuration 'B', the jumper J39 does not has any physical scope (2V5 to 2V5), but we've seen same default (factory) connections on HTG board.The similar connection on ml505/ml506 boards is very well documented and it is shown below. It is clear that on ml50x boards, the CONFIG4 is connected to VCC2V5 and CONFIG5 is connected to VCC2V5 for MII mode. Thus we cannot understand what is the right connection of jumpers.Thank you,Dionisis.
If you are one of the lucky owners of one of the Altera’s development kits with Marvell’s software-programmable 88E1111 Ethernet PHY then you know it’s a bitch. The problem is not really in a PHY itself — it’s not a bad piece of hardware at all. The problem is that Altera provides literally zero support or documentation with it. Go figure.
As it turns out, the PHY’s default settings after the hardware reset is to work in center-aligned mode, whereas the default mode for FPGA data-transfers is edge-aligned. On top of that, some kits have a bug and the PHY must be reset two or three times in order to become operational.
The quick fix to get the I/O between FPGA and the PHY working without software-programming the PHY is to shift the clock 90°. That can be done with PLL. There are two problems with this approach however —it makes it a lot harder to time-constrain the design and it introduces an extra clock while the PHY is fully capable of working in edge-aligned mode. If only you knew how to set it up…
![Marvell 88e1111 Phy Driver For Mac Marvell 88e1111 Phy Driver For Mac](http://www.dot-aster.com/DaughterCard/pics/DC_Marvell_phy_pic001.jpg)
As it turned out, the only way to get the documentation for the PHY is to sign an NDA with Marvell. It sounds as ridiculous as the need to sign a NDA in order to get an owner’s manual for the car you have just bought. I didn’t want to do it and “picked the red pill.” ¡No pasarán!
After a few hours of searching through the darkest corners of the forum archives and reading a somewhat messy Altera’s Triple-Speed Ethernet drivers code, I finally came up with a piece of magic that properly resets the PHY and makes it use edge-aligned clock. It assumes that “base” is a memory address of the MAC’s MDIO space (see Table 6-1 of the TSE User Guides for details), a user-space Linux running on x86_64 (though can be easily ported to kernel mode):
Some of the logic and magic masks I dug out of the TCL script written for JTAG System Console that I stumbled upon in a N647_TSE_Single_Port_RGMI_Dev_AIIGX_ACDS reference design.
Hope it helps!
![](/uploads/1/2/6/5/126578888/683668013.jpg)