Re: 8b/10b and EMI
Ben and all,
Any portion of a data stream any where in the system that is repetative will
show as a narrow band contributer to EMI. If you repeat the sequence below,
with the exception of the A, you will see the spectral content I presented
last week. When I finish the data on 64b66b, you will also see the narrow
band contributer from the 01/10 added to each 64bit segment. Ed also
pointed out that 1394 has some ways of dealing with this. I think Tom
Truman and Kamran Azadet would offer "why even encode then if you are going
to scramble anyway?" And to that, I would have to agree in theory. I will
describe more in a minute.
Ed's reply to Henning regarding the trace geometry and concerns with the
non-differential nature of a differential pair is very much true. Too bad
Ed couldn't take four or five more pages of email to describe the effects of
the routing to and through connectors, as well as the barrel geometry and
pad geometry. I don't really want to write four or five pages myself :).
And wether the nets are edge coupled or broad side coupled, the
non-differentialness exists. The fact is the variances in the driver, the
receiver, the board fab, board construction, power, etc, all factor in to
how differential something really is. And in the real world, 5 or more
percent of the wave time on a differential pair can be even mode.
What I don't agree with is Ed's reply that EMI should be fairly easy to
resolve because we are exiting with fiber. So let me put my four or five
pages here :) ......
- Looking at gig ethernet, most optics have a nose guard on them to help
shield the EMI. The radiated contributers have been sourced from a few key
areas. The primary is the clock source in the system seen as narrow band
and very easy most of the time to find and resolve, second is the logic
switch rate seen as narrow band, but can be 5mhz in width depending on the
fpga technology used, usually easy to find and is the result of poor routing
or poor/none termination schemes, and the third is broad-band noise on the
optic transceiver ground passing right out the hole as the result of poor
grounding or the non-differentialness of the source signal. This last one
is pretty tough to fix. It is further compounded by the site, which I will
get into in a minute.
- There are other cables exiting a system that are not going to be fiber.
The most obvious is the power, ac or dc, and the ground line. Sure, you can
add a power filter to resolve the noise transfer on the S21 and S12, but
most people ignore the filter response to the S22 side that can cause more
noise on the ground floor, thus further complicating the resolution. Power
and ground are so difficult to deal with anyway. In any design I am
invovled with, I agonize for days trying to explore every way possible the
ground scheme could become victimized by a known contributer. In my
opinion, the key is to make sure the ground is as clean as possible, ground
loops can not exist, and the noise generated from the non-differentialness
of pairs is minimized. Ed pointed out a key statement everyone needs to
remember - you are not just worried about the differential termination or
Zodd, but the even mode termination or Zeven, as well. Failure to observe
this in speeds beyond 1gigabit can result in a noise floor on the ground
growing exponentially with speed.
Now the touchy subjects.
- Site to Site variance for the emissions sites can be +/-4dB, so one site
can vary from another by 8dB (as of the last time I read the spec). So, not
only do I have to resolve to pick my personal limit (usually 6dB below the
limit for every contributing component found), but I have to figure out if
my box will pass at sites in China, Japan, Germany, and all over
Canada/USA. This is most frustrating, especially in the hub market. I know
this because I once took several products and stapled them down to a board,
then went to several sites to determine the results. All I will say is "it
was worse then my wildest dreams". So, when we discuss EMI compliance, what
we are really discussing is what site was it verified to pass at and is it
repeatable at that site. Fortunately, C63.4 is trying to make testing fair,
but they can only make it fair if the engineer testing the product has the
drive to look for what is not there, what is not expected, what is not
planned for. In other words, at an EMI test site, I am my companies own
worst nightmare because I will look for what I don't think should be there.
What C63.4 has tried to do is establish testing on the worst case for any
equipment. For ITE, it is the worst pattern. For 100mbit ethernet, this
pattern and load was easy to find with a smartbits. For any 8b10b code, it
will always be the idle pattern. I have yet to see any 1gig ports really
pass data at a test site - usually the equipment is made to pass idles
because the test operator has determined that this is the best way to find
an escaping contributor.
- Board design and mechanical enclosures are difficult to seal up tight.
Regarding the board, there are several issues, a few of them being:
multi-point vs single point ground, fringing at the planes, power supply
noise, too thin of ground planes, lack of emi stratedgy. Regarding the
chassis, Jonathan once pointed out in one of the meetings as a reminder that
10gig and 2.5gig can escape some very small holes. These huge boxes, and
even small ones are getting tough to build. Yes, we can seal boxes with
gaskets, but most gaskets have yet to be verified outside of a chamber to
10ghz. As of 6months ago, there was only one supplier that had really done
the verification across several samples, temp, lifecycle, etc, and is still
putting the data together.
In my opinion, sealing up a box is very difficult to do and compliance is,
at best, very difficult to repeat. So rather then get into issues of "I can
do EMI and you can't" (and I am not saying anyone said this, I just really
want to go a different direction), I am moving forward with the following
plan to present in May:
1. I can not speak for the packet construction, but I believe scrambled
data shows great promise in the areas of overall system cost. Slowing down
the speed means we can all get some of the budget back to reduce pressure in
areas we each are concerned with. Changing the signaling method means
changing the EMI testing game. Changing the speed to something slower means
less work at the board design, easier constraints on the board shop,
slightly cheaper test equipment and slightly less painful measurement
methods ........ In my view in analog architecture, everything is slightly
easier. It may not be on the digital side and we all have to look at that,
too.
2. What I can do is design two systems. One a very delicate design and one
a very sloppy design using the easiest constraints for my suppliers to
meet. I will then compare various coding methods at various speeds to show
performance, noise - common and differential, and open air EMI. What I hope
to achieve is that there will be a cost advantage in terms of relaxed design
parameters for using a slower speed scrambled code.
Yes this is a lot of work, but I feel right now that there is a tremendous
amount of effort to keep a costly system adder in tact because we are all
comfortable with it. If I can show that there are cost advantages to the
signal method change, then maybe we can consider moving forward in other
inovative directions.
Also, forigve my wording. My six year old did a high fly leap onto my back
this morning and I have not yet recovered.
Joel
------------------------
"Benjamin J. Brown" wrote:
> Ed,
>
> I picked up on your very last paragraph:
>
> Ed Grivna wrote:
> >
> > The 8B/10B code, when sending random data, has a fairly wide emissions
> > spectrum (which is what you want), but if you sit on the same
> > character or small group of characters, you can see the discrete
> > spectral peaks quite clearly.
> >
>
> When we look at the idle sequence for HARI, it looks like a
> stream of /K/R/K/R/ with an occasional /A/. Is this the type of
> thing you are referring to when you say small group of
> characters?
>
> Ben
>
> --
> -----------------------------------------
> Benjamin Brown
> Router Products Division
> Nortel Networks
> 1 Bedford Farms,
> Kilton Road
> Bedford, NH 03110
> 603-629-3027 - Work
> 603-629-3070 - Fax
> 603-798-4115 - Home
> bebrown@nortelnetworks.com
> -----------------------------------------
--
Joel Goergen
Member of Technical Staff
High Speed Communications VLSI Research
Bell Laboratories, Lucent Technologies
10250 Valley View, Suite 113
Eden Prairie, MN, 55344
Email: goergen@lucent.com
Direct: (612) 996-6932
Cell: (612) 670-5930
Fax: (612) 996-6995