Prev: F.S. Xilinx FPGA evaluation kit
Next: Possible memory leak in xst in ISE 11.3
From: Bob on 8 Dec 2009 12:06
I am having problems reading from the Ethernet PHY chip on both my
custom board and on the Xilinx ml403 board, both of which use the same
part (Marvell 88E1111) and design.

Background: For our custom board, the Ethernet PHY chip incorrectly
detects and enables its crossover feature approximately 50% of the
time. The solution is to disable this feature, as we have no need for
it. However, to do so, I must read and write to the PHY registers.

Using EDK 11.3i, I can indeed correctly read and write these
registers, and implement a software fix. However, this is an old
design, and the project is in the "end game". Therefore, there is
much resistance to changing the EDK version at this late stage;
everything else works, there are a number of custom IP that would need
to be updated, and of course, drivers would need to be updated or re-
written. So, I've tried the same approach with our existing 9.1i
tools, but reading and writing works sporadically.

The easiest example of the problem are the two PHY ID registers (2 and
3), that should always return the values $0141 and $0cc2 respectively,
and that for the 9.1i version, they are both read incorrectly the
first time, and then correctly the second time! Specifically, I read
0x0000 and 0x0400 the first time (both incorrect), and later, read
0x0141 and 0x0cc2 (both correct). There are other examples, but this
is the most obvious.

Note that this occurs even when building a design for the ml403, using
the Base System Builder.

I'm thinking some constraints might be needed on the signals of the V4/
PHY interface, but I don't know how to specify them. Has anyone an
example or a reference to guide me? Or am I missing something else?

Thanks,
-Bob
From: MM on 8 Dec 2009 14:58
I have this working in both 8.2 and 10.3. I've never tried 9.1. I suspect
however that this is a software porblem. Make sure that PHY is not being
reset when you try to read it the first time. If that's not the case perhaps
the MDIO interface is not reset properly before the first read... If the
behaviour consistent you could just ignore the first read as a simple
workaround.

/Mikhail



"Bob" <rsg.uclinux(a)gmail.com> wrote in message
news:bd19585a-98ee-461f-a18f-8389ba0d3b67(a)p30g2000vbt.googlegroups.com...
>I am having problems reading from the Ethernet PHY chip on both my
> custom board and on the Xilinx ml403 board, both of which use the same
> part (Marvell 88E1111) and design.
>
> Background: For our custom board, the Ethernet PHY chip incorrectly
> detects and enables its crossover feature approximately 50% of the
> time. The solution is to disable this feature, as we have no need for
> it. However, to do so, I must read and write to the PHY registers.
>
> Using EDK 11.3i, I can indeed correctly read and write these
> registers, and implement a software fix. However, this is an old
> design, and the project is in the "end game". Therefore, there is
> much resistance to changing the EDK version at this late stage;
> everything else works, there are a number of custom IP that would need
> to be updated, and of course, drivers would need to be updated or re-
> written. So, I've tried the same approach with our existing 9.1i
> tools, but reading and writing works sporadically.
>
> The easiest example of the problem are the two PHY ID registers (2 and
> 3), that should always return the values $0141 and $0cc2 respectively,
> and that for the 9.1i version, they are both read incorrectly the
> first time, and then correctly the second time! Specifically, I read
> 0x0000 and 0x0400 the first time (both incorrect), and later, read
> 0x0141 and 0x0cc2 (both correct). There are other examples, but this
> is the most obvious.
>
> Note that this occurs even when building a design for the ml403, using
> the Base System Builder.
>
> I'm thinking some constraints might be needed on the signals of the V4/
> PHY interface, but I don't know how to specify them. Has anyone an
> example or a reference to guide me? Or am I missing something else?
>
> Thanks,
> -Bob


From: Bob on 9 Dec 2009 09:58
Hi Mikhail - thanks for your response.

I don't think it is software because the high-level code is the same,
unless it is in the Xilinx low-level code, which looks fine.

Also, I just added a loop with a one-second delay. In it, I read and
display the two ID registers, then pause; even after five times
through, I still get the invalid values. Actually, what appears to
get it to read the ID registers correctly is the code to reset the PHY
by setting bit 15 in the control register; after this, the ID
registers work correctly, as do many of the others, but not the
register that controls the crossover feature!

I'm starting to wonder about how the PHY is reset. I don't have any
physical access to that signal, so I cannot view it on a scope. But
the PHY data sheet states it must be at least 10 ms long, and remain
active for at least 10 clock cycles. Could that be different?

Regards,
-Bob

On Dec 8, 2:58 pm, "MM" <mb...(a)yahoo.com> wrote:
> I have this working in both 8.2 and 10.3. I've never tried 9.1. I suspect
> however that this is a software porblem. Make sure that PHY is not being
> reset when you try to read it the first time. If that's not the case perhaps
> the MDIO interface is not reset properly before the first read... If the
> behaviour consistent you could just ignore the first read as a simple
> workaround.
>
> /Mikhail
>
> "Bob" <rsg.ucli...(a)gmail.com> wrote in message
>
> news:bd19585a-98ee-461f-a18f-8389ba0d3b67(a)p30g2000vbt.googlegroups.com...
>
> >I am having problems reading from the Ethernet PHY chip on both my
> > custom board and on the Xilinx ml403 board, both of which use the same
> > part (Marvell 88E1111) and design.
>
> > Background: For our custom board, the Ethernet PHY chip incorrectly
> > detects and enables its crossover feature approximately 50% of the
> > time. The solution is to disable this feature, as we have no need for
> > it.  However, to do so, I must read and write to the PHY registers.
>
> > Using EDK 11.3i, I can indeed correctly read and write these
> > registers, and implement a software fix.  However, this is an old
> > design, and the project is in the "end game".  Therefore, there is
> > much resistance to changing the EDK version at this late stage;
> > everything else works, there are a number of custom IP that would need
> > to be updated, and of course, drivers would need to be updated or re-
> > written.  So, I've tried the same approach with our existing 9.1i
> > tools, but reading and writing works sporadically.
>
> > The easiest example of the problem are the two PHY ID registers (2 and
> > 3), that should always return the values $0141 and $0cc2 respectively,
> > and that for the 9.1i version, they are both read incorrectly the
> > first time, and then correctly the second time!  Specifically, I read
> > 0x0000 and 0x0400 the first time (both incorrect), and later, read
> > 0x0141 and 0x0cc2 (both correct).  There are other examples, but this
> > is the most obvious.
>
> > Note that this occurs even when building a design for the ml403, using
> > the Base System Builder.
>
> > I'm thinking some constraints might be needed on the signals of the V4/
> > PHY interface, but I don't know how to specify them.  Has anyone an
> > example or a reference to guide me?  Or am I missing something else?
>
> > Thanks,
> > -Bob

From: MM on 9 Dec 2009 13:26
> I'm starting to wonder about how the PHY is reset. I don't have any
> physical access to that signal, so I cannot view it on a scope. But
> the PHY data sheet states it must be at least 10 ms long, and remain
> active for at least 10 clock cycles. Could that be different?

I believe I measured this at some point in the past and found that it was
much much shorter and did not meet the spec of my PHY. However, the PHY I am
using doesn't seem to care... On the other hand I remember having a problem
similar to yours when TRST pin of the PHY wasn't grounded.


/Mikhail


From: Bob on 9 Dec 2009 15:09
On Dec 9, 1:26 pm, "MM" <mb...(a)yahoo.com> wrote:
> > I'm starting to wonder about how the PHY is reset.  I don't have any
> > physical access to that signal, so I cannot view it on a scope.  But
> > the PHY data sheet states it must be at least 10 ms long, and remain
> > active for at least 10 clock cycles.  Could that be different?
>
> I believe I measured this at some point in the past and found that it was
> much much shorter and did not meet the spec of my PHY. However, the PHY I am
> using doesn't seem to care... On the other hand I remember having a problem
> similar to yours when TRST pin of the PHY wasn't grounded.
>
> /Mikhail

After my last email, I decided to control the reset line myself, and
unfortunately, no improvement.

Then, on a tip, I tried V3.00.a (instead of V3.00.b) of the hard_temac
IP, and the reading improved dramatically. At first, I thought it was
fixed, but looking real close, I noticed there were still a few bit
errors.

However, it occurred to me that, because I only need to modify two
registers after reset, and they are both well-defined, I didn't
actually need to read them. Once I get past the reset, I have no need
for any interaction with the PHY's registers. So, I modified my code
thusly, and lo and behold, it works! So at this point, I am happy...

Thanks for the insight, Mikhail!

-Bob
 |  Next  |  Last
Pages: 1 2
Prev: F.S. Xilinx FPGA evaluation kit
Next: Possible memory leak in xst in ISE 11.3