
|
[si-list]
||
[Date Prev]
[09-2002 Date Index]
[Date Next]
||
[Thread Prev]
[09-2002 Thread Index]
[Thread Next]
[SI-LIST] Re: FW: We ought to address mutual SI-EMI issues in this forum
- From: "Ed Priest" <epriest@xxxxxxxxxxxxxxxxxxx>
- To: <cpad@xxxxxxxxx>, <Roy.Leventhal@xxxxxxxx>
- Date: Wed, 11 Sep 2002 18:06:55 -0700
Chris
Well written and if I may steal and paraphrase what you have written I'd
like to expand its reach.
"The main trick with Engineering
is to know when to include stuff and to equally
know when to leave it out. THAT is the most difficult
part. One wants it complex enough to get meaningful, useful data but
not
so complex to where the data
is meaningless or simply never converges."
If you can learn to be good at that task you will be a good Engineer -
whatever area of expertise you are in. Many smart people never become
good engineers because they can't accomplish that task.
Thanks
Ed
-----Original Message-----
From: Chris Padilla [mailto:cpad@xxxxxxxxx]
Sent: Wednesday, September 11, 2002 5:05 PM
To: Roy.Leventhal@xxxxxxxx
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: FW: We ought to address mutual SI-EMI issues in
this forum
Gentlemen,
A thought provoking discussion.... As an EMC/EMI engineer, I think I
can
add some thought to the thread below.
First, I am a YOUNG EMC engineer...I have 4 short years under my belt at
Cisco Systems and have a master's degree in EE focusing on, what else,
EM. Cisco is my first job out of grad school.
The reason I mention my youth and degree is to point out that I came
from
graduate school heavily involved in EM simulation software and
research--most of it was for microwave frequency work. My job is in EMC
Design for Cisco and I am passionately involved at every step of the PC
design process. I do use simulation software to assist me with my
job. Granted, I do not get to use it as much as I'd like to (the "job"
tends to get in the way some times!) and I do end up spending most of
time
in semi-anechoic chambers scanning systems, using copper tape, changing
out
cap values, adding ferrites/cm-chokes, and playing with all sorts of
filter
designs. I mostly work in the 30 - 10000 MHz region but have lately
been
fighting switching frequencies of power supplies as a source of noise.
It
was interesting to be able to use circuit theory in its most basic form
again without worrying about the inductance of my traces causing problem
but I digress....
There is one company out there that I am aware of that is focusing on
the
needs of EMC engineers and that is a firm called Flomerics. They have
an
EMC tool called FloEMC. It is based on the TLM method (akin to the FDTD
method, time based....) and works very well for us. The main
difficulty,
pointed out clearly already, is the EMC simulation is a system level
phemomenon whereas SI is more of a board level phenomenon. This doesn't
mean one is more complex than the other but from a computer simulation
point of view, system level modeling is significantly more difficult and
consumes vast amounts of computer innards. The main trick with EMC
simulations is to know when to include stuff from a system and to
equally
know when to leave it out to save resources. THAT is the most difficult
part. One wants it complex enough to get meaningful, useful data but
not
so complex that it bogs your poor computer down to the point where the
data
is meaningless or simply never converges. I am quite happy with my
simulation tool and it does help me but we are FAR from being able to
put
in a whole computer's motherboard and pushing a button to tell us if we
are
going to meet FCC Class B. How does one deal with the "variable load"
that
48 Cat5 UTP cables provide when running a Gigabit Ethernet board for
compliance testing in a simulation package? Now THAT is a complex
problem.
Yes, EMC engineers are a skeptical bunch that is hard to please! If I
run
a scan of a system and the results are too good, I am suspicious and if
the
results are too bad, I am equally suspicious! It is a fine line before
we
are no longer suspicious.... With that, I am not too suspicious of my
simulation software as it has proven itself a valuable tools several
times
already.
Thanks,
Chris Padilla
EMC Engineer
Cisco Systems
San Jose, CA
>-----Original Message-----
>From: Roy Leventhal [mailto:Roy.Leventhal@xxxxxxxx]
>Sent: Wednesday, September 11, 2002 4:56 PM
>To: Fred Balistreri; si-list@xxxxxxxxxxxx
>Subject: RE: [SI-LIST] We ought to address mutual SI-EMI issues in this
>forum
>
>
>Fred,
>
>Thank you for your reply. It is well informed , correct and thought
>provoking in every respect. My "Yes, but(s):" do not take exception
with
>your reply. But, they are my questions and thoughts to you and the
SI-LIST
>as to where we are going in the future.
>
>First, there are traditions and history to consider. Simulation does
not
>seem to carry much weight or have much of a following in the EMI
community.
>This, perhaps, is one reason the SI community went its own way from the
EMI
>community because people saw that progress could be made. As you point
out,
>there is work to be done in producing usable data (package data
>particularly) and software programs that do something with it. However,
in
>any died-in-the-wool attitudes against innovation there are always
>individual exceptions and early adopters. I wish they would make
themselves
>known and join in the discussion. Because, I see simulation technology
>positioned for a new period of some progress on EMI simulation.
>
>What I perceive EMI engineers would like to see in the way of
simulation
>would be a virtual test/EMI scan instrument that they can compare
directly
>with their instrument data no matter how large the board or how complex
its
>data patterns. I don't think that will happen anytime soon.
>
>But, I'm sure that SI engineers can learn to use the tools that are
>available to do near field simulations, and think in terms of current
>magnitudes and frequency spectrum content on a trace and radiation from
it.
>Then, based on the principle that you're money ahead if you knock down
hot
>spots on a board, do some intelligent EMI design, re-simulate, etc., to
get
>there. If this encroaches on some traditional EMI engineering turf, so
be
>it.
>
>I would welcome it if EMI engineers want to step up and start driving
>progress on simulating EMI. That doesn't seem to be happening. But, I
know
>they're interested, smart and educated enough to be able to provide
>leadership. Ten years ago I didn't much believe in any simulation
software
>either. But, an inquiring attitude informed by practical experience and
>striving for improvement changed my outlook.
>
>The progress I do see happening in simulation packages includes dealing
with
>non-ideal reference planes, additional high frequency effects such as
>dielectric losses and simulation of both near and far field radiation.
I'm
>sure there are other improvements that can be pointed out and yet to be
made
>if simulator companies believed that the ROI is there.
>
>Package data is missing as you and I have pointed out. Probably, the
>majority of package engineers don't see it of any consequence to SI-EMI
>problems on the board/system or their responsibility to provide it.
But, I
>believe speeds have been high enough for their assumptions and rules of
>thumb to no longer be valid on leading edge technologies. If they opt
out of
>the issue of EMI contribution (and simulation of same) from the
package,
>there will exist an unbridgeable gap between board/system level
simulation
>and measurements. Leading edge companies are realizing this and driving
to
>see that gap filled.
>
>As I've stated, it's not intelligence, experience or anything else that
is
>holding back progress. It is assumptions. It's clear that progress is
needed
>when you consider the usual way products get qualified for
EMI-regulatory
>requirements. It's after the fact and back to the bench. Often with
repeated
>product dooming failures to pass regulatory.
>
>I believe we can do better. I've seen it done better, and in a small
way
>helped make that happen.
>
>Best Regards,
>
>Roy
>
>
>-----Original Message-----
>From: fred@xxxxxxxxxxxxxxxxxxxxxx
[mailto:fred@xxxxxxxxxxxxxxxxxxxxxx]On
>Behalf Of Fred Balistreri
>Sent: Tuesday, September 10, 2002 6:00 PM
>To: Roy.Leventhal@xxxxxxxx
>Subject: Re: [SI-LIST] We ought to address mutual SI-EMI issues in this
>forum
>
>
>Roy, I agree with much of what you say. From an EDA vendor point of
view
>here
>are some of the issues.
>
>1. Methodology; the traditional role of the EMI engineer would be to
>pass compliance.
> As such the tools used by the EMI engineer are more or less lab or
>field instruments
> for measurement. It is the nature that such testing be done at such
a
>time that the
> hardware to be measured already exists. In my experience the EMI
guy
>is the last guy
> to have input on the project and at that it's usually in the area
of
>the enclosure. By
> nature EMI engineers and CAD do not mix well. I grant you that this
>is changing. In
> larger corporations or in companies where the product is very
>expensive to manufacture
> (think 10's of layers) or millions of units in volume, then some
>great efforts are spent
> up front. Usually those companies have three meter rooms and a
great
>deal of time and
> effort goes into the design before the product ever makes it to the
3
>meter chamber.
>
>2. The EMI engineer looks at more or less system level or product
>problems. This usually or may involve
> cables and several grounding systems, boxes etc. The EMI simulators
>today can look at a system
> level problem but at a very rudamentary level. Once we get into the
>details of the IC models,
> packages and lands we are in trouble. Yet it is these very tiny
lands
>and entities that often
> are a cause of problems. The EMI engineer then would like to see
>better coorelation between
> simulation and what is measured in the field. This is something
that
>although sounds good, in
> real life may be impractical.
>
>3. There are lots of technical problems to overcome in order to acheive
>the goals set in number 2
> above. One problem is that today's CAD data does not contain the 3d
>information for the IC packages.
> Although its true that models of the package exist these are
usually
>in the form of LCR discretes
> or transmission lines. They do not contain the x,y, z locations of
>the structures. That information
> is usually contained in a DXF or other 3d mechanical package which
is
>not an integral part of the
> CAD layout program. The CAD program usually has a footprint only.
>Still another nasty problem is
> that the LCR information given is usually for signal nets only. The
>pwr and gnd information is usually
> not avaliable. That is also for a good reason. Unless the package
is
>one that contains internal gnd/pwr
> layers it's not possible to predict the capacitive and inductive
>properties. Those are determined by
> the proximity of a plane, sometimes the plane is on the PCB board
and
>the IC package guy has no idea
> where that plane may be located in the z axis. In other words the
>simulation has to be done on the fly.
> Pre-existing models don't work. And that goes back to the first
>premise. The data is just not avaliable
> in CAD. Another tid bit. The data for some of these packages is
HUGE.
>Still another problem is the IC
> models itself. We have a pretty good grip on the I/O's thanks to
IBIS
>and SPICE. However the internal
> currents are another story. Unfortunately in large LSI designs the
>internal currents are rather substantial
> and can cause tremendous SSI noise if not designed correctly. We
>don't have any idea what these currents
> are and the data for such is very difficult to get. Yet it is this
>switching current that is the source
> of a lot of problems. Needless to say there are other such nasty
>problems that I don't see addressed
> on the grand scale of things. Consider the enclosures which are
also
>designed outside of the PCB CAD.
>
>4. So as to not seem to put the shoe on the other foot. EDA vendors
also
>have had their share of problems.
> Promises, promises and more promises have been meant disappointment
>by the user community. I course
> I would never make such a promise that I can't keep. But in the
heat
>of the battle salesman can slightly
> overstate the capability or functionality of the tools, or make
>claims, promises which cannot be fulfilled.
> EMI engineers are by nature sceptics and there is most definately a
>credability gap which is greater in
> the EMI simulation community than exist in the general EDA world.
>
>Anyway these are some issues at the top of my head at the moment.
>
>Best regards,
>
>Roy Leventhal wrote:
> >
> > All,
> >
> > I'm sending you this message because I believe we need to begin much
>better
> > communications with our co-workers who concentrate on EMI/EMC
issues. You
> > can help by sharing your views. These can be on any subject of
mutual
> > interest between the EMI community and the SI community. But, to
start the
> > ball rolling, please share any of your thoughts on:
> >
> > 1. Productive ways to communicate between the two communities both
at work
> > and in outside venues such as symposiums and publications.
> >
> > 2. Modeling and simulation in SI and EMI and how this facilitates
> > understanding.
> >
> > 3. Measurements and terminology and how this must relate the models
and
> > simulation used across different technical disciplines.
> >
> > 4. How best to draw into this communication other technical areas
that
>will
> > have to be involved in order for any of us to succeed.
> >
> > 5. The role of standards.
> >
> > I agreed to be a point of contact between TC10 and SI-LIST. It is my
aim
>to
> > facilitate communication between the EMI community and the SI
community.
> >
> > For item 4 above I'm thinking of component package design and
modeling for
> > circuits AND EMI effects. Plus, the same issues for the IC chips
>themselves.
> > Plus the participation of the PWB and standards communities.
> >
> > Recently, I attended EMC 2002 in Minneapolis. I sat in on the
meeting of
> > IEEE EMCS Technical Committee 10 (TC10) "Signal Integrity and
> > Microelectronic Technology." It was well attended by your peers with
> > outstanding reputations in EMI who know about SI-LIST, but don't
have the
> > bandwidth to be very active in it. The attendees felt that the two
> > communities are being driven together by the press and progress of
> > technology. They also felt the impossibility of succeeding in
isolation
>from
> > each other. There is a long tradition of interest in EMI in the
IEEE.
>While
> > their evident interest in SI is very recent, I believe it is
genuine. I
> > noted at least 15 papers presented at the seminar that touched on
some
> > aspect of EMI from chips and packages. The IEEE press bookselling
booth
>also
> > had a brand new text:
> >
> > "Signal Integrity Effects in Custom IC and ASIC Designs"
> > Raminderpal Singh
> > IEEE Press & John Wiley & Sons, Inc., c2002
> > ISBN 0-471-15042-8
> >
> > I'll share some of my perceptions and opinions (based on my
experiences)
> > below to start this discussion going. Your experience, therefore
opinions,
> > can be different. So much the better for the sake of the discussion.
> >
> > I believe the relations between the SI community and the
product/logic
> > design community plus the PCB design community already have a good
>teamwork
> > paradigm that allows them to meld together their separate talents
and
>skills
> > in a highly effective way. This work involves a lot of modeling and
> > simulation at the front end, a (virtual) verification of layout and
>routing
> > and as a diagnostic tool of physical board problems. A lot of
>communication
> > goes on between this team to meet their mutual and sometimes
conflicting
> > goals. To simplify a lot:
> >
> > The logic engineer would be happy with logic that is hooked up
correctly
>and
> > has good timing (ideal ones and zeros with infinitely fast edges).
> >
> > The SI engineer wants good clean switching waveforms without noise,
>ringing,
> > etc., for reliable switching. Fast edges often cause problems.
> >
> > The board engineer wants to achieve the above seemingly unreasonable
>demands
> > at minimum cost and maximum producability.
> >
> > Driver strength and speed, physical structures that radiate, support
EM
> > fields, have losses and influence feedback effects insure that what
> > engineers and designers do at every physical scale impacts every
other
> > physical scale. Particularly at today's speeds and complexity.
> >
> > As an SI engineer I've noted that after the product engineer, the
PCB
> > designer and I complete our concurrent tasks the design process
enters a
>new
> > (often excruciatingly painful) phase called "trying to pass
regulatory."
>In
> > this endeavor there doesn't seem to be a lot of modeling, simulation
and
> > communication that goes on between the SI engineer and the EMI
engineer.
>The
> > EMI engineer might be happiest with no fast edges at all and lots of
> > shielding. There also seems to be many iterations of
build-test-find/fix
> > problems-retry. During this phase, if successful, there is a lot of
stress
> > on everyone.
> >
> > I know that EMI engineers are often every bit {and often more)
technically
> > sophisticated as I am. I presume that they would like to see
simulations
>at
> > the system level with multiple boards, different data patterns,
>enclosures,
> > attached cables, etc., that would match their test bench data.
> >
> > For starters there is an extremely important missing area of models
and
>data
> > that prevents this match up between system simulation and test stand
> > measurements. That missing link is the EMI modeling of the chips and
> > components on a board. Without it there is virtually no chance that
> > simulation and measurement will ever match. Package modeling
information
>is
> > often considered competitive and proprietary. However, in the IBIS
>spec/data
> > exchange approach we have the possibility of rendering the
information
> > behavioral and non-process specific as we go up from
> > chip-package-board-system scale.
> >
> > Also, the above complex system level simulation might be impractical
>without
> > a lot more computing power than we have today.
> >
> > Lastly, such a system level simulation involves many different
software
> > capabilities. For example chip, board and system level components
and
> > structures probably involves several different modeling techniques.
For
> > example: SPICE, IBIS, S-parameter models plus different methods to
handle
> > radiation, (TLM, FDTD, MOM, PEEC?) non-ideal grounds, etc.
> >
> > What this really implies is cooperation between several competing
software
> > companies. Because, a company that attempted all this at once would
lack
> > focus and technical excellence. I see a number of such partnerships
being
> > discussed. But, potentially competing companies are just beginning
such
> > discussions.
> >
> > However, we are all missing an opportunity here if we wait for the
system
> > solution.
> >
> > That is an opportunity to inject increased modeling, simulation,
design
> > intelligence and communication into the step between SI and passing
> > regulatory. We need to take the software tools as they are (or soon
will
>be)
> > and use them apriori and diagnostically to knock down EMI risks and
>problems
> > on an individual net level. Then, proceed to feed the behavioral
>information
> > up/down to/from the next level of scale: chip-package-board-system.
> >
> > Simulation is critical in addition to a rules-based approach because
you
> > must get down to predicting/diagnosing what is actually going on
amongst
> > many possible physical mechanisms. The discussions on this list
often
> > involve heated advancement of different theories (rules) unaided by
data.
> > Models used in the simulation must be based on reality and then be
>verified
> > by measurement. Or, the models can be recognized as speculation when
that
>is
> > an appropriate initial problem solving strategy.
> >
> > Design rules and standards have their place in this discussion. We
would
> > like to avoid paralysis by analysis.
> >
> > That which is considered physical is considered behavioral at the
next
> > physical level down. Ohms law (V, I, and R) involves electrons and
>material
> > properties at a more fundamental physical level and is considered
>behavioral
> > down at that level. I believe we need to investigate using voltage,
>current
> > and voltage-time curves plus auxiliary information as the data
exchange
> > format between the different physical scales.
> >
> > I recently participated in an exercise using modeling and simulation
>apriori
> > and diagnostically to knock down EMI risks with a client and their
team.
>It
> > was very successful in terms of time, cost and performance vs. the
> > traditional pass regulatory paradigm. They doubled their clock speed
and
> > were cleaner on EMI emissions than the older product on a much more
> > compressed schedule. They didn't have to add an expensive shielding
box.
> >
> > Simulation and modeling tools do not have to be perfect and complete
to be
> > of great benefit. You do need to know their limitations. All they
have to
>do
> > is to assist you in the steady application of good design
principles,
> > problem solving and the implementation of design intent.
> >
> > The above experience also reinforced my belief that the best
engineers use
>a
> > combination of simulation and measurement to meet their design
challenges.
> >
> > Best Regards to All,
> >
> > Roy Leventhal
> >
> > ------------------------------------------------------------------
> > To unsubscribe from si-list:
> > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
field
> >
> > or to administer your membership from a web page, go to:
> > http://www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> > List archives are viewable at:
> > http://www.freelists.org/archives/si-list
> > or at our remote archives:
> > http://groups.yahoo.com/group/si-list/messages
> > Old (prior to June 6, 2001) list archives are viewable at:
> > http://www.qsl.net/wb6tpu
> >
>
>--
>Fred Balistreri
>fred@xxxxxxxxxxxxx
>
>http://www.apsimtech.com
>
>
>
>
>------------------------------------------------------------------
>To unsubscribe from si-list:
>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
>or to administer your membership from a web page, go to:
>http://www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>List archives are viewable at:
> http://www.freelists.org/archives/si-list
>or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
>Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List archives are viewable at:
http://www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List archives are viewable at:
http://www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
|

|