Hi, all.

I have a general question about MII compatibility between different
PHY chips. I have a design that follows the AT91SAM7X-EK schematic,
but with a micrel part (KSZ8041) substituted for the Davicom part used
on the EK. I've used the MII interface because, apparently, the RMII
interface doesn't work (per the errata).

Can I expect this to just "plug-and-play" with applications based on
the EK design, or are there specific things I need to watch out for?
In general, is MII enough of a standard that it truly is
inter-operable, or is it one of those "kinda-sorta" standards?
Thanks for any info.



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

I think MII is relatively standardized, and are you say, RMII is broken on the '7X.

I used the same schematic as a starting point, but used an intel (now Cortina) LXT-972A PHY. There were very few design changes needed but the pinout was totally different. I found plenty of hints from intel on how to use their part. Driver-wise the Sam_emac7.c driver from Atmel was very close. The main differences were the PHY chip ID and a couple of private registers I needed to initialize. I was careful to keep the MII traces all the same length (and short) and put plenty of decoupling on the PHY. Unfortunately it is rather power hungry. With FreeRTOS and UIP, everything worked day one except for mis-numbered pins on the RJ45 jack.

Oh, one thing - you might want to put the PHY's reset line on a PIO line instead of NRST. Otherwise you can't control the PHY reset, which is sometimes necessary.
----- Original Message -----
From: twgbonehead
To: A...@yahoogroups.com
Sent: Thursday, February 07, 2008 12:03 PM
Subject: [AT91SAM] MII Compatibility
Hi, all.

I have a general question about MII compatibility between different
PHY chips. I have a design that follows the AT91SAM7X-EK schematic,
but with a micrel part (KSZ8041) substituted for the Davicom part used
on the EK. I've used the MII interface because, apparently, the RMII
interface doesn't work (per the errata).

Can I expect this to just "plug-and-play" with applications based on
the EK design, or are there specific things I need to watch out for?
In general, is MII enough of a standard that it truly is
inter-operable, or is it one of those "kinda-sorta" standards?

Thanks for any info.



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

> I think MII is relatively standardized, and are you say, RMII=20
> is broken on the '7X.=20

The first FreeRTOS.org demos for the 7X used RMII, but I was informed by
Atmel that there was a timing issue that meant it should not be used
(although it seemed to work fine for me). These were pre-production chips
though, so I don't know if the issue was fixed for production devices, or
became an errata item.
Regards,
Richard.

+ http://www.FreeRTOS.org
14 official architecture ports, 5000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T=DCV as meeting the requirements for safety related systems.

=20

=20


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Has anyone had to battle any EMI/EMC issues using the AT91SAM family of devices? I am currently doing testing and wanted to hear people's experiences.

Thanks.

-Henk

To: A...@yahoogroups.com
From: c...@delise.com
Date: Thu, 7 Feb 2008 12:45:07 -0500
Subject: Re: [AT91SAM] MII Compatibility

I think MII is relatively standardized, and are you
say, RMII is broken on the '7X.

I used the same schematic as a starting point, but
used an intel (now Cortina) LXT-972A PHY. There were very few design changes
needed but the pinout was totally different. I found plenty of hints
from intel on how to use their part. Driver-wise the Sam_emac7.c driver from
Atmel was very close. The main differences were the PHY chip ID and a couple of
private registers I needed to initialize. I was careful to keep the MII traces
all the same length (and short) and put plenty of decoupling on the PHY.
Unfortunately it is rather power hungry. With FreeRTOS and UIP, everything
worked day one except for mis-numbered pins on the RJ45 jack.

Oh, one thing - you might want to put the PHY's
reset line on a PIO line instead of NRST. Otherwise you can't control the PHY
reset, which is sometimes necessary.

----- Original Message -----
From:
twgbonehead
To: A...@yahoogroups.com
Sent: Thursday, February 07, 2008 12:03
PM
Subject: [AT91SAM] MII
Compatibility

Hi, all.

I have a general question about MII compatibility between
different
PHY chips. I have a design that follows the AT91SAM7X-EK
schematic,
but with a micrel part (KSZ8041) substituted for the Davicom
part used
on the EK. I've used the MII interface because, apparently, the
RMII
interface doesn't work (per the errata).

Can I expect this to
just "plug-and-play" with applications based on
the EK design, or are there
specific things I need to watch out for?
In general, is MII enough of a
standard that it truly is
inter-operable, or is it one of those
"kinda-sorta" standards?

Thanks for any info.

_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

> Has anyone had to battle any EMI/EMC issues using the AT91SAM
family of devices? I am currently doing testing and wanted to hear
people's experiences.
>
> Thanks.
>
> -Henk

Hi Henk,

what issues are you looking at? Specific chip?

Our expeprience with sam7s256 is positive.
We ran through EMC compliance testing already.
Surprising to me that a faster 32bit chip like the sam7s is much
lower in noise than a c51 which we looked at before.

Same with EMI.

We were using 16kHz Crystal. In my opinion a better choice than what
Atmel is suggesting (18.xxx) - PLL issue, getting more MIPS out of
the thing.

Highly recommended a 4Layer design. The Atmel EK design is not bad.
But there are better ways.

Regards
Thomas



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Thomas,

The chip I am using on my board is the AT91SAM9261.

The issue for our emissions testing is that we are seeing problems at 96 MHz and 192 MHz which correspond to the main clock and PLLB frequency.

During the testing we sniffed the board using a near-field probe to pinpoint trouble areas. When we were directly beneath the AT91SAM9261 BGA the signal strength display on the spectrum analyzer went through the roof!

If I were to run things at a slower speed would that bring down some of the EMI issues? Or would it just shift the problems over in frequency?

Thanks for any suggestions.

-Henk

To: A...@yahoogroups.com
From: t...@schulte-universe.com
Date: Fri, 8 Feb 2008 12:20:18 +0000
Subject: [AT91SAM] Re: EMI/EMC AT91SAM9261

> Has anyone had to battle any EMI/EMC issues using the AT91SAM

family of devices? I am currently doing testing and wanted to hear

people's experiences.

>

> Thanks.

>

> -Henk

Hi Henk,

what issues are you looking at? Specific chip?

Our expeprience with sam7s256 is positive.

We ran through EMC compliance testing already.

Surprising to me that a faster 32bit chip like the sam7s is much

lower in noise than a c51 which we looked at before.

Same with EMI.

We were using 16kHz Crystal. In my opinion a better choice than what

Atmel is suggesting (18.xxx) - PLL issue, getting more MIPS out of

the thing.

Highly recommended a 4Layer design. The Atmel EK design is not bad.

But there are better ways.

Regards

Thomas

_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

--- In A...@yahoogroups.com, HENK VISSER wrote:
>
> Thomas,
>
> The chip I am using on my board is the AT91SAM9261.
>
> The issue for our emissions testing is that we are seeing problems
at 96 MHz and 192 MHz which correspond to the main clock and PLLB
frequency.
>
> During the testing we sniffed the board using a near-field probe to
pinpoint trouble areas. When we were directly beneath the AT91SAM9261
BGA the signal strength display on the spectrum analyzer went through
the roof!
>
> If I were to run things at a slower speed would that bring down some
of the EMI issues? Or would it just shift the problems over in frequency?
>
> Thanks for any suggestions.
>
> -Henk

I don't have much first hand experience with EMI testing or design,
but I took a course in high speed digital design where this was
discussed. EMI can be minimized by keeping the traces low impedance.
Mostly that means keeping your dielectric layers in the PCB very
thin. This keeps most of the energy in the trace rather than being
radiated. If you use 0.005" thickness in your board stackup between
the ground and power planes as well as the high speed signal traces,
this should help a lot. I am betting that your stackup uses much
thicker layers or maybe you are routing the high speed signals on the
top/bottom layers with power/ground on inner layers that are not close
to the top/bottom layers.

It is also very important to use very short traces to connect ground
and power pins to their planes. The power planes can provide a very
low impedance path for noise caused by the fast edges of the clocks.

It is likely that slowing the clocks will do nothing for EMI since it
is the edge rates and not the clock rate that results in EMI. In
fact, that presents another solution to the EMI issue. If you are
running the clock to other chips on the board, you might want to use a
series resistor to match the output impedance to the trace impedance
(which should be around 50 ohms).

Does any of this sound right to you?



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

--- In A...@yahoogroups.com, "twgbonehead" wrote:
>
> Hi, all.
>
> I have a general question about MII compatibility between different
> PHY chips. I have a design that follows the AT91SAM7X-EK schematic,
> but with a micrel part (KSZ8041) substituted for the Davicom part used
> on the EK. I've used the MII interface because, apparently, the RMII
> interface doesn't work (per the errata).
>
> Can I expect this to just "plug-and-play" with applications based on
> the EK design, or are there specific things I need to watch out for?
> In general, is MII enough of a standard that it truly is
> inter-operable, or is it one of those "kinda-sorta" standards?
> Thanks for any info.
>

Hi

The uTasker project has builds for the Davicon and the Micrel parts
(for ATMEL and OLIMEX eval boards) - the differences are very small.
There is a discussion here:
http://www.utasker.com/forum/index.php?topic=161.0
Typically the pull up resistors in the SAM7X require a reset to be
generated to control the default PHY configuration (it is possible to
generate a pulse on the NRST line) - more details in the link.

Regards

Mark

www.uTasker.com



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Henk,

I agree with Rick's comments, here's a few of my own:

At these frequencies, most of the loading on signals is capacitive.
Therefore, lowering the frequency should lower your total emissions;
at these frequencies it's probably almost directly proportional to 1/f.

Since most of the troublesome emissions are coming at the fundamentals
(this seems to be what you're saying) softening the edges probably
won't help much (except for clock lines that need to travel long
distances). Compact layout, short traces, plenty of bypass caps
(including high-quality tantalums) will all help. If possible, put a
cap or two on the underside, in the center of the chip, and use that
center area for extra ground plane, top and bottom, with plenty of
stitching. When placing bypass caps around something like the micro,
it's often better to "point" the cap toward the power pin (i.e. with
one end of the cap close to the pin, and the back end further away)
rather than "broadsiding" it.

Place your components in order of their speeds, and put all the
high-speed stuff as close together as possible. Again, if you can use
both sides of the board for components, this can help a lot with
density. Pay attention also to part orientations when placing them,
sometimes turning a part around will cut trace lengths considerably.

Route your traces in order of frequency as well, giving preferential
treatment to the highest-frequency stuff. While routing, keep
evaluating your placement to look for ways to improve it (another
reason to route the high-speed stuff first; less to rip up when you
discover non-optimal placement issues). Try to run pairs (for example,
the two sides of your xtal) side-by-side, as close together as
possible to minimize loop area.

Also, keep an eye out for your via placement. Often, it's tempting to
bunch vias for a group of connections together (i.e. that neat
diagonal line) but this can wind up chopping slices into your ground
and power planes; often it's better to space out the vias (or at least
randomize them). When you're done, take a look at just the ground
plane (and just the power-plane) and look for weak spots.

Although it often isn't practical, top-and-bottom ground floods can
help (usually, however, with stuff of this density there just isn't
any room left over!). If you can identify problem traces, you can
sometimes find the room to "cuddle" them with ground traces. In any
case, if you have blank areas of PCB, it rarely hurts to flood them,
even if they aren't right in the middle of the "hot zone".

If you can constrain the high-frequency stuff to a relatively small
area of your board, you might consider isolating the power plane, and
bridging it with a ferrite bead (or several, around the perimeter).
This forces the high-frequency currents to come locally (from the
bypass caps) and traps them within the isolated plane section.

If you really need a fair amount of real-estate (or perhaps even if
you don't) you might consider going to a 6-layer (or higher) board,
and sticking all the high-speed stuff that has to travel any distance
in the middle. (IIRC, Atmel's 9263-EK is actually an 8-layer (more?)
board with a couple of ground planes).

Hope this helps!

--- In A...@yahoogroups.com, "Rick Collins" wrote:
>
> --- In A...@yahoogroups.com, HENK VISSER wrote:
> >
> >
> >
> > Thomas,
> >
> > The chip I am using on my board is the AT91SAM9261.
> >
> > The issue for our emissions testing is that we are seeing problems
> at 96 MHz and 192 MHz which correspond to the main clock and PLLB
> frequency.
> >
> > During the testing we sniffed the board using a near-field probe to
> pinpoint trouble areas. When we were directly beneath the AT91SAM9261
> BGA the signal strength display on the spectrum analyzer went through
> the roof!
> >
> > If I were to run things at a slower speed would that bring down some
> of the EMI issues? Or would it just shift the problems over in
frequency?
> >
> > Thanks for any suggestions.
> >
> > -Henk
>
> I don't have much first hand experience with EMI testing or design,
> but I took a course in high speed digital design where this was
> discussed. EMI can be minimized by keeping the traces low impedance.
> Mostly that means keeping your dielectric layers in the PCB very
> thin. This keeps most of the energy in the trace rather than being
> radiated. If you use 0.005" thickness in your board stackup between
> the ground and power planes as well as the high speed signal traces,
> this should help a lot. I am betting that your stackup uses much
> thicker layers or maybe you are routing the high speed signals on the
> top/bottom layers with power/ground on inner layers that are not close
> to the top/bottom layers.
>
> It is also very important to use very short traces to connect ground
> and power pins to their planes. The power planes can provide a very
> low impedance path for noise caused by the fast edges of the clocks.
>
> It is likely that slowing the clocks will do nothing for EMI since it
> is the edge rates and not the clock rate that results in EMI. In
> fact, that presents another solution to the EMI issue. If you are
> running the clock to other chips on the board, you might want to use a
> series resistor to match the output impedance to the trace impedance
> (which should be around 50 ohms).
>
> Does any of this sound right to you?
>



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )