Or to beat on recalcitrant young whippersnappers. Roy Leventhal wrote: Aaargh! I've been stabbed! I knew it would happen. Touché. A slide rule is an ancient weapon sometimes employed to beat on recaltriant problems. Best Regards, Roy -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx[1]]On Behalf Of Ken Cantrell Sent: Friday, September 13, 2002 9:08 AM To: Roy.Leventhal@xxxxxxxx; vishrampandit@xxxxxxxxxxx; cpad@xxxxxxxxx Cc: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: We ought to address mutual SI-EMI issues in this forum Roy, Excellent summary and opinion, I'm sure all agree. I've got just one question: what is a slide rule? Ken -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx[2]]On Behalf Of Roy Leventhal Sent: Thursday, September 12, 2002 5:26 PM To: vishrampandit@xxxxxxxxxxx; cpad@xxxxxxxxx Cc: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: We ought to address mutual SI-EMI issues in this forum Vishram and Chris, You both make excellent points. Simulators need to be reliable, easy to use and their complexity/detail needs to match (or be adjustable to a matching level) the complexity/detail of the problem. You pay a premium in time, money and missed schedules if they are too complex and detailed. You can be seriously mislead if they oversimplify the issues involved. The same is true of the models used in the simulator and your choice of what is important or not. The same is true whether you are talking SI, EMI, analog, logic or anything else. The same was true when I was using a slide rule to analyze single stage amplifiers, 3-stage IFs, etc. I recently listened to a good friend's technical presentation on simulating an EMI problem at our local IEEE chapter meeting. He is a VERY experienced and senior engineer in this area. He delivered a strong message on the need to make the right simplifications. At which point an experienced person can "almost" see the solution. For me one of the marks of a good engineer is that he or she knows the what, when, etc., of both measurements and simulation/and analysis. That, and the engineering judgment to know how to simplify a problem are some of the chief value-added contributions they can make to a project's success. So far I hope that I have reflected and reinforced your ideas. But, beyond that I think there is something else. What happens when theory don't match? Does the engineer understand theory well enough to know what to expect from a simulation? Can they apply that understanding as soon as they see the simulation results and give a rational explanation for those results? Can they move ahead with imperfect models and simulation engines? Do they have a feeling of when they are way beyond the capabilities of a tool or model to provide reliable results? These are the challenges I set myself. I don't always meet them. But, to do otherwise - well I might as well shrug my shoulders and say "It's what the simulator gives me." and let it go at that. Sometimes it takes quite a while to track down an answer. I'm never happy until I do. Because, I believe one of the marks of a good engineer is to contribute understanding. And, that is chiefly gained through modeling (expaining with a story that can be expressed mathematically) and simulation. So, I proceed. I believe in my simulation and I build my product. And, it doesn't behave as expected. What have I missed? What is simply missing from or wrong in the model? Am I using it beyond its specified range? Do I understand process variation and have I modeled it? The earliest (BJT) transistor models included basically 2 elements: an input resistance and dependent (controlled) output generator. When the first narrow-base planar process transistors were measured they didn't match the model. Two elements - an output impedance and a dependent/controlled (feedback from output to input) generator on the input were added. I.e., the 4-element, 2-Port, black box (y, z, h, abcd, etc.) transistor model. From that the device physicists went to work trying to explain what was going on and the SPICE program, it's a computer program not a model, incorporated their improved modeling. So, models and simulation must always proceed from trying to explain and predict reality, i.e. measurements. As technology changes we've got to expect to have to fix and extend the models and the calculation engines that use them. We should be working on that in EMI/EMC. When engineers who rely primarily on EMI measurements get a product that doesn't behave as desired well, I doubt they shrug their shoulders and say "Well it's what the measurements say." and let it go at that. Modeling, measurement, a desire to understand and a willingness to push into uncharted territory all belong in an engineer's tool bag. Best Regards, Roy -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx[3]]On Behalf Of Vishram Pandit Sent: Thursday, September 12, 2002 12:42 PM To: cpad@xxxxxxxxx; Roy.Leventhal@xxxxxxxx Cc: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: We ought to address mutual SI-EMI issues in this forum Hello, I would like to express my views on this thread. I work for Hughes in EMC/SI department. I had been looking for an EMC simulation tool for a long time. We finally acquired a Signal and Power Integrity simulation tool that is very helpful for EMC. As discussed earlier, EMC phenominon is very complex to simulate as the following factors contribute to it: 1] Originating sources 2] Coupling elements 3] Final Radiating elements. Ideally, you need a simulator that includes all these, and still it will be inadequate for certain situations (e.g., dynamic load, cable arrangements, etc.). SI analysis and EMC analysis go hand in hand. With the SI simulation you can predict signal quality fairly accurately (in absolute gauge), while with the EMC simulation you can only perform a relative analysis. You cannot directly compare it to the FCC/EN limits. Of course, the simulation is only board level, and coupling elements and radiating element are not considered. The approach I use is attack the originating sources. Using my simulation tool I try to improve the signal and power integrity on the board. Power Distribution System plays a vital role in EMC. For signal analysis, only certain nets are considered at a time, and the radiation effect of those nets can be simulated (without the enclosure). Of course, when the board comes out, I have to tweak the decaps and ferrites, etc. But the debug time is considerably less for a board which has been simulated for signal and power integrity earlier. Comments are welcome if anyone has some other methods! For a true EMC simulator, it may be a good idea to have a board level analysis (including transmission line, circuits and field simulation) and ability to apply the factors for external coupling elements and shielding effectiveness for the enclosure. AS Chris mentioned, it needs to be simple and reliable. May be we can take the corner cases and worst case coupling and worst case shielding effectiveness. Again, it will be valid only for those nets for which analysis is done. It needs to be performed separately on different sets of nets. Thanks, Vishram Pandit Hughes Network Systems (301)212-7932 >From: Chris Padilla <cpad@xxxxxxxxx> >Reply-To: cpad@xxxxxxxxx >To: Roy.Leventhal@xxxxxxxx >CC: <si-list@xxxxxxxxxxxxx> >Subject: [SI-LIST] Re: FW: We ought to address mutual SI-EMI issues in >this forum >Date: Wed, 11 Sep 2002 17:04:56 -0700 > > >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[4]] > >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[5]]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: > > > //www.freelists.org/webpage/si-list[6] > > > > > > For help: > > > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > > > > > List archives are viewable at: > > > //www.freelists.org/archives/si-list[7] > > > or at our remote archives: > > > http://groups.yahoo.com/group/si-list/messages[8] > > > Old (prior to June 6, 2001) list archives are viewable at: > > > http://www.qsl.net/wb6tpu[9] > > > > > > >-- > >Fred Balistreri > >fred@xxxxxxxxxxxxx > > > >http://www.apsimtech.com[10] > > > > > > > > > >------------------------------------------------------------------ > >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: > >//www.freelists.org/webpage/si-list[11] > > > >For help: > >si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > > >List archives are viewable at: > > //www.freelists.org/archives/si-list[12] > >or at our remote archives: > > http://groups.yahoo.com/group/si-list/messages[13] > >Old (prior to June 6, 2001) list archives are viewable at: > > http://www.qsl.net/wb6tpu[14] > > > >------------------------------------------------------------------ >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: >//www.freelists.org/webpage/si-list[15] > >For help: >si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > >List archives are viewable at: > //www.freelists.org/archives/si-list[16] >or at our remote archives: > http://groups.yahoo.com/group/si-list/messages[17] >Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu[18] > _________________________________________________________________ Join the world?s largest e-mail service with MSN Hotmail. http://www.hotmail.com[19] ------------------------------------------------------------------ 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: //www.freelists.org/webpage/si-list[20] For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //www.freelists.org/archives/si-list[21] or at our remote archives: http://groups.yahoo.com/group/si-list/messages[22] Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu[23] ------------------------------------------------------------------ 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: //www.freelists.org/webpage/si-list[24] For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //www.freelists.org/archives/si-list[25] or at our remote archives: http://groups.yahoo.com/group/si-list/messages[26] Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu[27] ------------------------------------------------------------------ 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: //www.freelists.org/webpage/si-list[28] For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //www.freelists.org/archives/si-list[29] or at our remote archives: http://groups.yahoo.com/group/si-list/messages[30] Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu[31] ------------------------------------------------------------------ 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: //www.freelists.org/webpage/si-list[32] For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //www.freelists.org/archives/si-list[33] or at our remote archives: http://groups.yahoo.com/group/si-list/messages[34] Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu[35] -- Todd R. Grey 214-480-0693 office TI Broadband Product Engineering 469-831-1672 cell t-grey2@xxxxxx nbsp214-480-3443 fax 4698311672@xxxxxxxxxxxxxxx text msg --- Links --- 1 mailto:si-list-bounce@xxxxxxxxxxxxx 2 mailto:si-list-bounce@xxxxxxxxxxxxx 3 mailto:si-list-bounce@xxxxxxxxxxxxx 4 mailto:Roy.Leventhal@xxxxxxxx 5 mailto:fred@xxxxxxxxxxxxxxxxxxxxxx 6 //www.freelists.org/webpage/si-list 7 //www.freelists.org/archives/si-list 8 http://groups.yahoo.com/group/si-list/messages 9 http://www.qsl.net/wb6tpu 10 http://www.apsimtech.com 11 //www.freelists.org/webpage/si-list 12 //www.freelists.org/archives/si-list 13 http://groups.yahoo.com/group/si-list/messages 14 http://www.qsl.net/wb6tpu 15 //www.freelists.org/webpage/si-list 16 //www.freelists.org/archives/si-list 17 http://groups.yahoo.com/group/si-list/messages 18 http://www.qsl.net/wb6tpu 19 http://www.hotmail.com 20 //www.freelists.org/webpage/si-list 21 //www.freelists.org/archives/si-list 22 http://groups.yahoo.com/group/si-list/messages 23 http://www.qsl.net/wb6tpu 24 //www.freelists.org/webpage/si-list 25 //www.freelists.org/archives/si-list 26 http://groups.yahoo.com/group/si-list/messages 27 http://www.qsl.net/wb6tpu 28 //www.freelists.org/webpage/si-list 29 //www.freelists.org/archives/si-list 30 http://groups.yahoo.com/group/si-list/messages 31 http://www.qsl.net/wb6tpu 32 //www.freelists.org/webpage/si-list 33 //www.freelists.org/archives/si-list 34 http://groups.yahoo.com/group/si-list/messages 35 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: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //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