Its interesting how history tends to repeat itself. People hire me on to help them out on their data converters, and then for one reason or another not take advantage of my knowledge. "We got that data converter guy, now what?" .. Its funny how much people will pay you to hang around. History repeats..
So this first happened while I was working at a previous large company not known for analog. There was a group of experts working at a remote design center in Israel. I was told "these guys are experts at math" and mixed-signal circuits so for me that should make the job easier. Math can solve an argument in any language, doesn't matter what language you think in if the math works.
The design was an 8 bit low-power ADC for a gigabit Ethernet chip. (over Copper in 2000) The gigabit version of the Ethernet standard still uses time-domain templates and is a PAM 5 solution. Of course, you need to transmit more levels than that since there is a transmit low-pass filter. Link margin was low and in the standard a DFSE and a Viterbi were used. What this all means is that the "eye" at the input of the receiver is a mess. It has a bunch of intersymbol interference and echo. (Echo is the transmit signal reflecting back into the receiver). So basically this IEEE standard requires an ADC instead of a simple slicer at the receiver input. Of course, some analog pre-processing can reduce the spec on the ADC, but you still can't ever get rid of it. So you have to build it. (Paper on Gig RX)
So its my duty to "architect" and lead a team to "design" this ADC. The schedule is short, just a few months, which is not long for an ADC. There was all kinds of things we could do to reduce the area and power of that ADC, but given the tight schedule and 20+hrs/wk in meetings, we had little choice but to go bare bones, a non-scaled pipelined ADC. No problem for this fine team (Link to Paper) who ended up building lowest power embedded ADC at the time later published by Springer thanks to Perry's help. So I put together an error and power budget, broke the design into subsections and staffed it with a team who comprise the author list on the Springer paper. The capacitor array layout was drawn and balanced perfectly by Mel Sparkman.
During the development of this ADC it was important for the Israeli design team to be involved in all the steps of the process. "ADCs are magical things" is what some people think even as recently as maybe a week ago before I typed this. There is fear and confusion on many electrical engineers about data converters, error correction and calibration. I admit they are tricky and combine system expertise along with circuit knowledge. System level specifications end up setting the size of capacitors, transistors and amplifier architectures inside the ADC. Several times during my career, people from the sidelines try to get involved an micro-manage the design process to "make sure" I am doing the right thing. I don't mind people watching me, I think I know what I am doing but it does slow me and the team down to explain everything. You want an ADC or a lecture?
So I put together a block diagram and wrote the behavioral model in C. The Israel team also put together their own "matlab" model to confirm my results. During the first meeting there was "a problem" with my ADC. For some reason I was accused of "sandbagging" my design. It was always my fault.
"How much margin do you put in your design, SSA?" - asks senior architect
"Normally I don't comment on design margin, but there is some" - SSA
"I think your ADC is WAY better than what you state - why so much margin?" --asks senior architect
"Show me the data" - SSA
So he brings out a MATLAB result, showing our 8Bit ADC with an SNDR of 59dB. Now, there is an equation for ENOB (Effective Number of Bits). The math is:
6.02(ENOB)+1.76 = SNDR
So for SNDR=59dB, N=9.51
Its an 8 bit ADC so theoretical max SNDR = 8*6.02+1.76 = 49.9dB
59dB(result) > 49.9dB (Theoretical 8 bit)
So it did appear that I had~10dB of margin? He got "better than theoretical" performance..
The SDNR values are affected by things in the test-vectors going into the ADC (or out of a DAC). There are underlying assumptions, that when violated can give you better than theoretical results.
"Ahh I see, you have higher than theoretical, so you have a problem in your test vector" - SSA
"What do you mean, I am a mathematical expert with much more experience.. etc" -Senior arch
SSA Responds:
There are assumptions behind 6.02(ENOB)+1.76.
1. The input signal is a sinewave, this formula ONLY works for sine-waves (first non-streetsmart mistake)
2. The quantization noise is a "uniformly distributed" random variable with the width of one of the "stair steps" of the ADC or LSB
20*Log10(Signal_rms/Quant_noise_rms)=6.02(ENOB)+1.76
Quant_noise_rms = LSB / Sqrt(12) - which is the Standard deviation for a uniform Probability density function. LSB = VFS/2^8 for an 8 bit ADC
Now a common mistake is to violate the Quantization noise uniform PDF criteria.
"What input signal frequency did you use?" - SSA
Answer: Fs/4, or 0.25* Sample rate. - Senior Arch
So now SSA knows your problem. "I know your problem"
For Fs/4, the ADC pattern is +1, 0, -1, 0, +1, 0
So the quantization error is: e1, e2, e3, e2, e1, e2... (repeating... thats NOT random!!!)
So a couple weeks ago, it happened again with a senior expert showing greater than theoretical ENOB... and it reminded me of this. All the guy had to do was call or ask, but what would I know soaking up that paycheck as a data converter expert...
So Fs/4 is a bad test-signal for ENOB since it violates the "uniform probability density" assumption in the quantization noise power calculation. Fs/4 is not bad for debug, if you are trying to isolate a bad code, so don't get me wrong. There is a time and place for everything.
So how should we pick the input signal?
Thats based on a "sentence" in my mind. If we pick a signal that is related to the sample rate by a prime-number, we know we will break up that "pattern" and whiten the PDF of the quantization noise. It goes like
"In 2^N samples I want a prime number of input signal periods"
2^N * Ts = Prime * Tinput
2^N is desired # of data points
Ts = Sample Period
Prime = A prime number, 3, 5, 7, 11..
Tinput = Period of input signal
This can be "re-written" as the form found in Maxim and ADI Appnotes:
Finput = Prime * Fsample / 2^N
So this where the Prime # Table comes in!!!
If your Input frequency meets the above equation, I promise you will NEVER get better than theoretical SNDR. Especially with larger prime #s. A popular one was suggested..
Fin=20.20263672MHz
Prime = 331
Fsample=125MHz
2^N=2048
Notice that I had to carry all those digits. This is one of those cases where you need to key in all those digits. To this day nearly 14 years later I still have that frequency memorized, we used it during simulations, verification and validation in the lab.
Senior Architect guy plugged in the above numbers, and lost about 11dB in SNDR. Oh well, I could have just acted like I could architect a better than theoretical ADC.
So this is the reason I have a prime number table on my desk. I need it to set signal frequencies for test-vectors that do not violate the assumptions of the ENOB equation. All data converter experts should have a prime table. They are free, and available via Google.
If you ever see higher-than theoretical ENOB (or SNDR) for a data converter, then there is a violation of the assumptions underneath. This means the ADC was not being "exercised" fully and the results are invalid. (You could always look at a code histogram). If you are an experienced guy and show better than average ENOB, then you will no longer look experienced in front of your peers.
Tuesday, August 5, 2014
Wednesday, June 11, 2014
Building an Analog Team
Recently I have been tasked with adding staff to our design team. Like a normal product design team, there is always pressure to get the part done right in zero time. Of course, real analog circuits take time to build, often underestimated by non-experts. Of course most schedule problems come from non-experts making schedules with other experts resigned to pushing back.
So you want to build up your team? Who do you hire? This is a really tough question in reality it depends on what you are doing and what are the key constraints. Is it time to market? Risk? High mask cost? All of the above? Are you adding to a team or creating one from scratch?
In the Radar business the process technology is very advanced and the related costs are high. There also appears to be an unrealistic expectation that first silicon is product worthy. Although real chip designers know this to be unwise, staffing can mitigate the risk of an imperfect chip. The first ingredient is finding someone who has made a mistake and willing to admit it. These characters tend to be older, more mature, have advanced degrees (Ph.D. or MSEE), and have lots of different product experience. The problem with this description is that the older more experienced designers understand unrealistic expectations better than younger engineers. This can help to set expectations. Recently I have phone screened candidates that are afraid of the position I am trying to fill because their perceived interpretation of the risks is too high.
Super senior analog designers often reflect their past. This shouldnt be a surprise, since we are the sum of our experiences. I met one analog designer today who new Verliog, Verilog-A and system Verilog which can be considered "younger engineer" type of skills. Analog was not taught before 2000 with a bent toward system level verification. Chips were small and simple and as the industry has changed more towards system-on-a chip (SOC) these verification tools have increased dramatically in value. However finding an engineer with modern skills who has designs in over 100,000,000 shipped parts/components (for example) is nearly impossible as far as I can tell. This is a message to my mid-career colleagues that its important you pick up these newer verification skills. They are easier to learn than trying to convince a young hard-headed designer to abandon an unreliable circuit or poor layout.
Where is your team? That is also important. Ideally everyone should in the same physical location, but that is no longer realistic. Companies are now keeping track of "High cost centers" such as San Jose where the cost of doing business is high. The value add at these centers needs to justify the high costs. My expectations of engineers in Silicon Valley are high. You should know architecture, circuit design, basic cad and have good communication skills. If you are going to work with remote sites to take advantage of outsourced or "lower cost centers" you need to have good communication skills. I have met some very good technical people recently in my search for staff who have difficult communicating. I don't want to have to have a note-pad to communicate basic concepts.
Team balance is very important. Too many super senior guys can lead to a lower-energy environment. Also not everyone can do the big architectural tasks, so you need a mix of people ideally. I recall discussing this year ago with my friend Perry Heedley using the basketball team analogy. People need to play different cooperative roles working together to get things done. There needs to be trust in the team so I am very sensitive to anyone who may have a reservation about a candidate. This could be technical or personality but there is not any room for a player to bring down the rest of the team. Its not uncommon for me to go through 50 resume's before I get a candidate that fits the team, often with compromises. I am most sensitive to candidates that make me nervous for any reason. I understand people really want a job these days. On Linked-in recently there have been some good short postings in my feed about how to interview. As a hiring manager I read these and a key failing I have seen recently is a candidate trying to "take over" the interview. That doesn't work well with me.
Is the person temporary or full-time? Temporary help (contractors) should be good at communication. Ideally they "get" the idea that they are in themselves a company. The best contractors see themselves as "their own brand" with a service to sell. This includes building the brand reputation including advertising. Some of the best contractors have been high-level managers or people that own their own companies. These guys understand that its not all technical! Problems need to be solved, instructions followed, problems found that are clearly communicated. Not all tasks are have the same cost, the goal is primarily to deliver service. If I can't understand a contractor's English or they are unwilling to come out on-site that is a problem. Also their rate, does it justify what needs to be done? There level of experience? Are they working for a contract house, then why? The absolute best analog engineers I know of all have full-time employment. Recruiters ask me to refer people but the best guys always have a job. Time in-between jobs is also very short in duration, often set by the engineer.
When do you need the person? Good, Cheap, Fast pick two of three. If you need a good person on short notice it will cost a high dollar. If you are willing to put in the time, which is the most realistic approach, you have to staff way in advance of a crisis, otherwise you will sit helpless with a stack of resume's. So planning here and listening to your people's needs are critical.
I am sure a few candidates I have interacted with recently would benefit from this blog. Also there are some good books and references on how to interview. Candidates looking for a job should seek these out, since these interviewing books help the job seeker to understand the position the guy on the other side of the table is. Don't add more work by having a sloppy, long and confusing resume with charts and graphs on your employment history. Don't share too much, make me want to call you! Also, when you do show up, you should have some idea what is expected and what we are doing. This is where the standard preparation helps. What you show up to an interview (empty handed?) will affect my decision to hire you or not. Its important you understand that I am trying to help run a profitable business.
So you want to build up your team? Who do you hire? This is a really tough question in reality it depends on what you are doing and what are the key constraints. Is it time to market? Risk? High mask cost? All of the above? Are you adding to a team or creating one from scratch?
In the Radar business the process technology is very advanced and the related costs are high. There also appears to be an unrealistic expectation that first silicon is product worthy. Although real chip designers know this to be unwise, staffing can mitigate the risk of an imperfect chip. The first ingredient is finding someone who has made a mistake and willing to admit it. These characters tend to be older, more mature, have advanced degrees (Ph.D. or MSEE), and have lots of different product experience. The problem with this description is that the older more experienced designers understand unrealistic expectations better than younger engineers. This can help to set expectations. Recently I have phone screened candidates that are afraid of the position I am trying to fill because their perceived interpretation of the risks is too high.
Super senior analog designers often reflect their past. This shouldnt be a surprise, since we are the sum of our experiences. I met one analog designer today who new Verliog, Verilog-A and system Verilog which can be considered "younger engineer" type of skills. Analog was not taught before 2000 with a bent toward system level verification. Chips were small and simple and as the industry has changed more towards system-on-a chip (SOC) these verification tools have increased dramatically in value. However finding an engineer with modern skills who has designs in over 100,000,000 shipped parts/components (for example) is nearly impossible as far as I can tell. This is a message to my mid-career colleagues that its important you pick up these newer verification skills. They are easier to learn than trying to convince a young hard-headed designer to abandon an unreliable circuit or poor layout.
Where is your team? That is also important. Ideally everyone should in the same physical location, but that is no longer realistic. Companies are now keeping track of "High cost centers" such as San Jose where the cost of doing business is high. The value add at these centers needs to justify the high costs. My expectations of engineers in Silicon Valley are high. You should know architecture, circuit design, basic cad and have good communication skills. If you are going to work with remote sites to take advantage of outsourced or "lower cost centers" you need to have good communication skills. I have met some very good technical people recently in my search for staff who have difficult communicating. I don't want to have to have a note-pad to communicate basic concepts.
Team balance is very important. Too many super senior guys can lead to a lower-energy environment. Also not everyone can do the big architectural tasks, so you need a mix of people ideally. I recall discussing this year ago with my friend Perry Heedley using the basketball team analogy. People need to play different cooperative roles working together to get things done. There needs to be trust in the team so I am very sensitive to anyone who may have a reservation about a candidate. This could be technical or personality but there is not any room for a player to bring down the rest of the team. Its not uncommon for me to go through 50 resume's before I get a candidate that fits the team, often with compromises. I am most sensitive to candidates that make me nervous for any reason. I understand people really want a job these days. On Linked-in recently there have been some good short postings in my feed about how to interview. As a hiring manager I read these and a key failing I have seen recently is a candidate trying to "take over" the interview. That doesn't work well with me.
Is the person temporary or full-time? Temporary help (contractors) should be good at communication. Ideally they "get" the idea that they are in themselves a company. The best contractors see themselves as "their own brand" with a service to sell. This includes building the brand reputation including advertising. Some of the best contractors have been high-level managers or people that own their own companies. These guys understand that its not all technical! Problems need to be solved, instructions followed, problems found that are clearly communicated. Not all tasks are have the same cost, the goal is primarily to deliver service. If I can't understand a contractor's English or they are unwilling to come out on-site that is a problem. Also their rate, does it justify what needs to be done? There level of experience? Are they working for a contract house, then why? The absolute best analog engineers I know of all have full-time employment. Recruiters ask me to refer people but the best guys always have a job. Time in-between jobs is also very short in duration, often set by the engineer.
When do you need the person? Good, Cheap, Fast pick two of three. If you need a good person on short notice it will cost a high dollar. If you are willing to put in the time, which is the most realistic approach, you have to staff way in advance of a crisis, otherwise you will sit helpless with a stack of resume's. So planning here and listening to your people's needs are critical.
I am sure a few candidates I have interacted with recently would benefit from this blog. Also there are some good books and references on how to interview. Candidates looking for a job should seek these out, since these interviewing books help the job seeker to understand the position the guy on the other side of the table is. Don't add more work by having a sloppy, long and confusing resume with charts and graphs on your employment history. Don't share too much, make me want to call you! Also, when you do show up, you should have some idea what is expected and what we are doing. This is where the standard preparation helps. What you show up to an interview (empty handed?) will affect my decision to hire you or not. Its important you understand that I am trying to help run a profitable business.
Wednesday, March 26, 2014
EE Conference user guide
I like to go to IEEE conferences whenever I can get away which works out to about once a year. My favorite is ISSCC since its in San Francisco and I can BART or drive and some of the worlds best analog designers meet there every year in February. If you are not in IEEE you can still go it just costs a couple hundred dollars more. I have gone 14 out of the last 15 years and realized I have a whole method of getting a lot out of the conference. This blog post is to share some of these observations. Where to stay, how to pick what papers and events, evening panels and finally social hour.
We all are busy as analog designers I doubt many of us work less than 50 hours a week. We are often optimizing what we do. Some of us are more frugal than others it all depends on what is important. To me the important thing is that during the conference "life" is going on and that includes analog. A positive change to your work environment is a nice thing. For adding considerable enjoyment to the event I prefer to stay in the hotel hosting the conference. If my company doesn't want to pay it I will then offer to chip in the difference. If they refuse then I pay out of pocket . Having a room at the event is great since you can setup a remote office there to get things done and keep up back at the plant. I room on a high floor is better since its quieter and the views are better. You normally have to ask at the Marriott for a higher floor. Its easier to get one if you arrive the afternoon or evening before the conference starts after making reservations a couple months in advance.
Day one is when you need to make your schedule final. To leverage the event you may have made a plan with other workmates on what papers sessions to cover. Before the ISSCC this is a first-order plan based on terse descriptions of the papers to be presented. A drawback (or feedback to IEEE) is that its hard to tell if the paper is really interesting or related to what you are looking to learn about at the conference until you get there. The early descriptions are so short that you are forced to show up. Maybe that is the idea anyway. Only after seeing the actual proceedings, now made available online just before the conference, can you really pick what papers to attend. Well you need to check your plan or make your plan by flipping through the papers. Look for easy to read text, clear figures and solid technical content. University papers written by students and their professors are often the best written and easiest to follow. The university papers often don't have the same performance as their commercial counterparts, but the ideas can be easily just as clever. For performance pick the industry papers but you may not get all the detail and there are sometimes empty boxes in diagrams. So I sort through the papers looking for understanding and/or performance and then pick a path through the sessions where the papers are presented. This takes me about an hour to make my plan for the next few days.
Attending the papers is not very easy/relaxing for me. There is a huge amount of information presented. Several years of a persons work (doctoral research) is boiled down to a ~20 minute talk. It takes skill to ramp-up quickly and follow these talks. Sometimes you need to suspend disbelief and re-engage in the end. If you second guess the paper you could miss a few key facts while you ponder. I make a point to write directly on the paper proceedings notes and comments during the papers. I also write down Q/A for papers I particularly like. Q/A can reveal information not in the publication and can also help you learn about other engineers. For example if Dave Robertson of ADI asks about an ADC you need to think about what it was and why. If you wanted to introduce yourself to him for a potential gain in knowledge and opportunity, then you now have a reason. When in school professors scoop knowledge on the students, after graduating it takes effort to keep up and read papers. Working on a network with other engineers is key in maintaining growth and an edge over the other guy.
Yes, analog electronics is one of my favorite hobbies but my love of it is not enough to endure 8 hours of solid technical papers. Maybe a handful of guys out there could attend the entire conference and congratulations. For normal human beings I find it critical to put a break in the day. Normally I schedule a daily nap around 2pm depending on what sessions I go to. I plan my naps on the first day. This is also where the conference hotel really helps out. The nap in the afternoon is critical for me. The talks end as late as 4:30-5pm so a 1 hr nap is not too-long and I bounce back. This is important because after these papers is when things get social when rest is needed.
Ok, I do realize analog guys are not all the most social bunch so we start with a disadvantage. You then combine awkwardness with a wide age spread of attendees, free snacks, wine and beer. Fatigue also is setting in later in the day especially if you didn't have a nap. Part of my writing this post was learning that some engineers are petrified of the social hour. My wife showed me a newsgroup where some people are paralyzed by the idea of going down on the social floor of conferences like these. This is the StreetSmart part of the post, how to do the social hour. Some of the social tips follow.
Advances in technology (text messaging) are not doing well with the age gap issue at ISSCC. Some of the most experienced and distinguished engineers may not use text messages since the go through most all of their lives without it. The younger the engineer the more tech savvy. Its my observation that the youngest engineers rarely interact with the most experienced senior designers. Also, some of the other-way around exists, some older engineers avoid the younger and its sad. When approaching a professor or famous circuit designer you need to approach them in a way that is most comfortable. Don't interrupt but wait to be invited into a conversation. If you want to talk to someone its better if they are finishing up talking to someone else or not talking to someone you do not know. Make eye contact that is normally enough to let someone know you are interested chatting. Also asking if they have time is nice, since if they are busy they will appreciate it. When you see them next there is a much higher chance they will engage. Be aware of people around you who may also want to talk to the same person, be polite and watch body language. If their feet or body turn away its time to wrap it up. Its important you have a reason to talk. The easiest conversation starter is to ask about a paper presented earlier in the day or made during paper Q/A. Poster session reactions work too. Ask what they thought of it. Alternatively you can ask about a paper, presentation or book written by the designer. Author interviews are also a great place to meet people and will give you a connection.
Whatever you do DO NOT drink too much at social hour. Sipping one glass of wine or having a beer is fine but more than two and there is trouble. You are interacting with some really intelligent people and its a rare opportunity. The impression goes both ways, if you drunkenly stumble into someone you are not going to make a friend. This is a common mistake since the free-beer thing takes a little will power for frugal engineers. Some engineers wrap a paper bar napkin around the beer and carry it around. I know of at least one famous professor who does that too. The bar napkin is good since it helps you to NOT peel the label making it less obvious that you are "carrying the beer around". Tired and tipsy is not a good combination for making it easy to meet new people. If you are part of the text-message generation or new to the United States then I suggest you observe before engaging. Most engineers are there to have a good time so project positive energy and things should go well. At the social hour I normally make dinner connections. After the social hour is the time to have a few drinks and talk about circuits.
The evening panel sessions occur after dinner. These vary in content some being more serious than others. The best are the debugging/analog guru sessions with the colorful characters of the analog integrated circuit community. Young and old I often wonder what it takes to get on one of those panels it seems like a strong network helps. Panel arguments about tubes vs. transistors or BJTs vs. FETS can get spicy and absolutely hilarious. The analog community respects and laughs at itself in these sessions.
After the conference is the best time to write down any final notes. Life is busy and its easy to forget the details or interesting techniques learned during the conference. Not all from the papers, some from fellow engineers. Take inventory of business cards, you can write notes on the back about the people. This information helps later the following year since you can build on the history. People like to hear about themselves, its all good.
Going to a conference can be an expensive and take a chunk of time. If you plan your time well you can make the conference a fun, educational and rewarding experience. Be careful to pace yourself since the material can overload even the most experienced engineers. Use the social hour to connect, challenge yourself to meet someone new and don't drink too much at the social. The IEEE has been continuously improving the conferences over the years, so if you have not been to one in a while it may be time.
We all are busy as analog designers I doubt many of us work less than 50 hours a week. We are often optimizing what we do. Some of us are more frugal than others it all depends on what is important. To me the important thing is that during the conference "life" is going on and that includes analog. A positive change to your work environment is a nice thing. For adding considerable enjoyment to the event I prefer to stay in the hotel hosting the conference. If my company doesn't want to pay it I will then offer to chip in the difference. If they refuse then I pay out of pocket . Having a room at the event is great since you can setup a remote office there to get things done and keep up back at the plant. I room on a high floor is better since its quieter and the views are better. You normally have to ask at the Marriott for a higher floor. Its easier to get one if you arrive the afternoon or evening before the conference starts after making reservations a couple months in advance.
Day one is when you need to make your schedule final. To leverage the event you may have made a plan with other workmates on what papers sessions to cover. Before the ISSCC this is a first-order plan based on terse descriptions of the papers to be presented. A drawback (or feedback to IEEE) is that its hard to tell if the paper is really interesting or related to what you are looking to learn about at the conference until you get there. The early descriptions are so short that you are forced to show up. Maybe that is the idea anyway. Only after seeing the actual proceedings, now made available online just before the conference, can you really pick what papers to attend. Well you need to check your plan or make your plan by flipping through the papers. Look for easy to read text, clear figures and solid technical content. University papers written by students and their professors are often the best written and easiest to follow. The university papers often don't have the same performance as their commercial counterparts, but the ideas can be easily just as clever. For performance pick the industry papers but you may not get all the detail and there are sometimes empty boxes in diagrams. So I sort through the papers looking for understanding and/or performance and then pick a path through the sessions where the papers are presented. This takes me about an hour to make my plan for the next few days.
Attending the papers is not very easy/relaxing for me. There is a huge amount of information presented. Several years of a persons work (doctoral research) is boiled down to a ~20 minute talk. It takes skill to ramp-up quickly and follow these talks. Sometimes you need to suspend disbelief and re-engage in the end. If you second guess the paper you could miss a few key facts while you ponder. I make a point to write directly on the paper proceedings notes and comments during the papers. I also write down Q/A for papers I particularly like. Q/A can reveal information not in the publication and can also help you learn about other engineers. For example if Dave Robertson of ADI asks about an ADC you need to think about what it was and why. If you wanted to introduce yourself to him for a potential gain in knowledge and opportunity, then you now have a reason. When in school professors scoop knowledge on the students, after graduating it takes effort to keep up and read papers. Working on a network with other engineers is key in maintaining growth and an edge over the other guy.
Yes, analog electronics is one of my favorite hobbies but my love of it is not enough to endure 8 hours of solid technical papers. Maybe a handful of guys out there could attend the entire conference and congratulations. For normal human beings I find it critical to put a break in the day. Normally I schedule a daily nap around 2pm depending on what sessions I go to. I plan my naps on the first day. This is also where the conference hotel really helps out. The nap in the afternoon is critical for me. The talks end as late as 4:30-5pm so a 1 hr nap is not too-long and I bounce back. This is important because after these papers is when things get social when rest is needed.
Ok, I do realize analog guys are not all the most social bunch so we start with a disadvantage. You then combine awkwardness with a wide age spread of attendees, free snacks, wine and beer. Fatigue also is setting in later in the day especially if you didn't have a nap. Part of my writing this post was learning that some engineers are petrified of the social hour. My wife showed me a newsgroup where some people are paralyzed by the idea of going down on the social floor of conferences like these. This is the StreetSmart part of the post, how to do the social hour. Some of the social tips follow.
Advances in technology (text messaging) are not doing well with the age gap issue at ISSCC. Some of the most experienced and distinguished engineers may not use text messages since the go through most all of their lives without it. The younger the engineer the more tech savvy. Its my observation that the youngest engineers rarely interact with the most experienced senior designers. Also, some of the other-way around exists, some older engineers avoid the younger and its sad. When approaching a professor or famous circuit designer you need to approach them in a way that is most comfortable. Don't interrupt but wait to be invited into a conversation. If you want to talk to someone its better if they are finishing up talking to someone else or not talking to someone you do not know. Make eye contact that is normally enough to let someone know you are interested chatting. Also asking if they have time is nice, since if they are busy they will appreciate it. When you see them next there is a much higher chance they will engage. Be aware of people around you who may also want to talk to the same person, be polite and watch body language. If their feet or body turn away its time to wrap it up. Its important you have a reason to talk. The easiest conversation starter is to ask about a paper presented earlier in the day or made during paper Q/A. Poster session reactions work too. Ask what they thought of it. Alternatively you can ask about a paper, presentation or book written by the designer. Author interviews are also a great place to meet people and will give you a connection.
Whatever you do DO NOT drink too much at social hour. Sipping one glass of wine or having a beer is fine but more than two and there is trouble. You are interacting with some really intelligent people and its a rare opportunity. The impression goes both ways, if you drunkenly stumble into someone you are not going to make a friend. This is a common mistake since the free-beer thing takes a little will power for frugal engineers. Some engineers wrap a paper bar napkin around the beer and carry it around. I know of at least one famous professor who does that too. The bar napkin is good since it helps you to NOT peel the label making it less obvious that you are "carrying the beer around". Tired and tipsy is not a good combination for making it easy to meet new people. If you are part of the text-message generation or new to the United States then I suggest you observe before engaging. Most engineers are there to have a good time so project positive energy and things should go well. At the social hour I normally make dinner connections. After the social hour is the time to have a few drinks and talk about circuits.
The evening panel sessions occur after dinner. These vary in content some being more serious than others. The best are the debugging/analog guru sessions with the colorful characters of the analog integrated circuit community. Young and old I often wonder what it takes to get on one of those panels it seems like a strong network helps. Panel arguments about tubes vs. transistors or BJTs vs. FETS can get spicy and absolutely hilarious. The analog community respects and laughs at itself in these sessions.
After the conference is the best time to write down any final notes. Life is busy and its easy to forget the details or interesting techniques learned during the conference. Not all from the papers, some from fellow engineers. Take inventory of business cards, you can write notes on the back about the people. This information helps later the following year since you can build on the history. People like to hear about themselves, its all good.
Going to a conference can be an expensive and take a chunk of time. If you plan your time well you can make the conference a fun, educational and rewarding experience. Be careful to pace yourself since the material can overload even the most experienced engineers. Use the social hour to connect, challenge yourself to meet someone new and don't drink too much at the social. The IEEE has been continuously improving the conferences over the years, so if you have not been to one in a while it may be time.
Monday, January 20, 2014
Uneasy Pease
From my bad interview at a no longer existing analog company along in 1993 along with a downturn in the economy I decided to focus my education in the California central valley and everything related to it. (..."Please wait for the CEO he will see you next", that was after a long afternoon of technical interviews without even a snack break, with low blood sugar, I responded "Don't bother", took off my badge and walked out the door and back into graduate school) I had my electronics hobby kits, the recording studio work, automated laundry repair etc to deal with so I wasn't into Bob Pease and the analog scene being (heavily influenced) by National Semiconductor in the early 1990s. I noticed in my visits to National that they had excellent analog designers and I will mention a few. Its been flattering to hear feedback that my posts remind them of Bob's writings so I thought its time to "dig up" Bob.
This posting is basically an old school book review of Bob's Kindle book on Troubleshooting analog circuits. With practice my writing should get better and become more like Bob's. But first more about Mr. Pease.
I recall a SSCRL (UCD Seminar) where we had a guest speaker Bob Pease (1994?). A somewhat frail looking graying and bearded man with numerous cutout foils for the overhead projector. His presentation was about a front-end of some kind I recall he was interactive and asked questions to the group as he went along. In a mechanical fashion he would uncover paper to reveal new information in the overhead transparency. (In the old days we had these projectors with this clear film...it was analog...) His talk was pretty good, low-tech and down to earth entertaining. Bob was an expert interacting with other engineers and there were more than a few laughs while he disarmed difficult to gather analog concepts. His talk was second best unfortunately that year beat out by Rich Reay who gave out a six-pack for nailing the old common-emitter gain problem.
My next interaction with Bob was when I visited National Semiconductor as a scholarship award winner. Bob wanted to meet us it was important to everyone including Bob. Funny I remember the museum they had in the building with old electronics that was really cool. Glass cases with old shiny analog guys like me like that stuff. The door gift for the awards was an analog clock. I recall the clocks all lined up with their hands in different random times at the beginning of the event. Then the clocks were passed around to me and the other award winners. As we left on a tour a looked back in the room and all the clocks were correctly set.... engineers and OCD. Then a couple years afterward there was my interview at NSC in 1998 where my visit to Bob required me to brave his "dual cubicle" and find him in the corner between stacks of papers. He shook my hand, promptly reached into a corner and pulled out a poster of "Bob Pease Lord of the Bandgap" which he promptly signed and sent me on my way. My friendly host Pat Tucci and the creative Sing Chin made for a good day of data converters and at least one display chip. My Bob Pease poster was donated to the Lab and I don't think it was unique.
Now some 16 years later I had a credit on Amazon so I purchased a rather expensive Kindle book "Troubleshooting Analog Circuits" by Robert A. Pease ISBN 0-7506-9949-8 c 1991 for $37.54 soft-copy. You would think this would be an enjoyable read for many but this was my first exposure to Bob's writing and how his mind works. His writing and reasoning are amazingly clear following a logical progression. He comes to good conclusions with his solid understanding of the underlying physics of electronic devices. When it comes down to it we electrical engineers just apply physics to make money for our employers. Bob's book can be summarized as observe, be aware and think. Seek out the physics as to "why".
The book is quite excellent including photos and clearly drawn schematics. Some books don't look as clear in their Kindle form but this is an excellent conversion including the figures. In the first chapter he covers cost oriented test equipment. Good advice of course about getting the most accuracy out of meters. Choose the right tool for the job its basic to Bob he was trying to do the best at bench analog. His test instruments are cheap and aimed more at low-frequency DC/DC converters and the like, its important to understand what Bob was working to get the most out of it. It also helps if you have seen some of these old components before, you should know a 2N3055 in a TO-3 will leave a welt if it hit you on the head. A TO-220 has a screw tab on it, so on.
Bob covers passives in chapters 3 and 4 including noisy resistors, film, wire-wound with their smokey charred failure mechanisms. (He didnt mention you can identify the bad component by the smell, so basically many analog gear-heads know what different parts smell like when they burn such as the fishy burnt aluminum electrolytic.) The inductor section actually hurt to read. Yes the saturation current of an inductor decreases at temperature. No, the inductor is not the same after you hammer it with current, that took me and a team of guys at least a week to figure that one out. Bob could have saved me a weeks there and at least of lab pain. (abused inductors can de-solder themselves) Dried capacitors (seen that) bad electrolytics without bias, oil filled, anything with "ene" is high performance and tantalum caps suck for Q. Type of capacitor dielectric hurt too (I know guys who have spent weeks debugging poor choice of dielectric in a DSL application) they could have benefit from these two chapters. I think I could have saved a few gray hairs and months of debug over the years had I got this book earlier. Bobs chapters here remind me of Henry Ott's book on Noise Reduction Techniques in Electronic Systems (1988 John Wiley ISBN 0-471-85068-3).
His section on board issues has a bit of the self inflicted in it. Bob lived on the board, 3-d circuit design-fly wire. Air is an excellent dielectric seems more of an excuse to stay with what works. This is the way he understood things. He wasn't into the SSA "the three views" (covered in a an earlier post) wherein the text-netlist can be hacked like his 3-D circuits. Hacking the input simulator input netlist (ASCII) is akin to his 3D lab experiments but in a sterile environment. This power would scare Bob for sure with his dislike of computers, however if he were to have leveraged his approach on the simulator who knows where we would be. (No I am not saying bench work is obsolete.) I my work I try to avoid situations where the physics is so sensitive that a single fingerprint or a misting of flux can wipe out the performance. Physics will dictate exactly what your circuit does, always. From a street-smart standpoint it sounds to me like it may be a good idea to integrate sensitive electronics since the package will protect the internal high-impedance nodes. Put thermally sensitive stuff close together. What matters to the customer most is the solution in the end. Having circuit boards so sensitive makes me wonder about how robust board will be in the long run especially when you don't know what the customer is going to do with it. I think of random environments such as a guy who travels frequently with the equipment to a smoggy desert, then a dry polar cap all along blowing cigar smoke at the installed board. Of course Bob would just put the board in the dishwasher that should clean off the smoke.
He covers wearing out Zener diodes, how Zeners actually avalanch over 3V, ok following been there but key to understand. (Michael Altmann taught me a few things about Zeners he may have learned from Bob before going back to Intel.) Bob next talks about finger debugging, the capacitance of a finger loading a circuit, yes fingers are useful in debugging and I have had my share of shocks and burns, still Bob keeps going down the practical debug path. Even with a stocked lab Bob would use everything in his arsenal to debug. The fuse section is excellent I think many of us don't know AC vs DC and fuse ratings this was good. We have all seen transistors sacrifice themselves to protect a valuable fuse, not much on that in the book though but it seems like something Bob would write about. Resistive diodes, blown bipolars and MOS we have all have seen our share of those. The leaky 1N914 section was excellent while not a big surprise to hear about since I preferred the germanium diodes in crystal radios since the gave more volume than the 1N914. Bob is an expert at DC DC converters (ironically my least-favorite circuits) having fixed numerous bad boards stuffed with non typical components required for typical designs. He reminds me again and again of how I don't like those circuits (because often their failure can be catastrophic). Its hard to debug a chip when you pour its innards out of the package into a heap of glass after a fail. (no, it didn't melt-down when I was done with that circuit but the horror) Some DC DC converter issues are audible but that part of my hearing was blown out long ago by stress testing audio power amplifiers with Led Zepplin, The Who and sonic holography experiments involving reproducing actual recordings of freight trains (the Mach 5 experiments~1990). Bob doesn't mention audibles his hearing was worse than mine.
So in general if you have not read Bob's book I highly recommend it. This is especially true for "non-hobby" types or people who have picked up their analog later in life. The years have changed analog and those old exposed connections are now buried inside some little device or surface mount pc board. We in the industry have been working hard to make sure new hobby guys find analog as intimidating as possible with microscopic difficult to deal with components. If this is your first exposure to practical electronics is the university you should rush to by Bob's book, although it does show some age. One thing to consider is that the knowledge in the book is decades of experience so the $37 for a Kindle but is a steal! (I sadly estimate Bob's book could have saved me 100s of hours. Some hours, in a crunch time for example, you can never get back!)
Reading Bob's book made me wonder how relevant it will be another 10 years from now. Its doing very well by the way as the entire industry is changing. (Physics doesn't change fortunately). We are trying to get the human out of the system as much as possible since we are imperfect, make cold solder joints occasionally and miss a color code multiplier. Bob's techniques of circuit analysis and phase margin checking are useful but few people now build up something without simulating it first. Do not let that the simulator think for you but help you think. You can still ponder what is going on and why the result may or may not be accurate. In fact its critical you do so. Do I believe the result? That is a key reason why we go to school and learn physics and engineering. Those people who work along side me know I distrust new tools and flow without independent verification. I hate tool and software changes. Bob had it correct that simulators can impair circuit thinking if abused. Simulations are garbage without thought. If anyone from Cadence is reading this please allow us to purchase a release with only bugfixes and NO new features to break and or screw up other working features. We are not allowed to re-compile our multi-million dollar masks its hardware.
Personally I am a big fan of the simulator since when driven by an expert it can enhance understanding. We take it for granted that we can look at any signal in the simulator and get a waveform representing what is happening at that spot with respect to time. After working on a circuit the designer gets an expectation of what to see at various points. After a while, this gets committed to memory and we can be "surprised" when we don't see an expected result we understand. After years of staring at simulator outputs and anticipating results I can now see waveforms in my mind. (My internal transient simulator I call it I am not unique in this ability since many of us have it). I can debug circuit problems anywhere even while driving or on a cross country flight. Often I have a parameter sheet from the process so I can do hand calculations. For me as a simulator all I need is rest, a good meal and time to focus. The biggest challenge is the latter.
Using Bob's analog "3D cloud of circuits" approach on the bench is akin to an expert hacking on a netlist input to an analog simulator. At this point in my career I can visualize a smaller circuit in my mind and write an HSPICE deck off the cuff to simulate it. There is an added advantage here with a simulator since the elements are ideal, don't require soldering and infinite component values are available. This sounds harder than what Bob due to the open ended flexibility but it all depends on your perspective. I am not alone in this ability visualize circuit netlists as circuis and most good people I know debug or track down issues in an any of the three views. In simulators tolerances can be checked in sim cases, voltage sources are perfect as are current sources, volt-meters have no load at all. If desired, devices can be matched perfectly. All connections are perfect in a simulator making soldering skill a moot point. You can quickly and perfectly connect any two or more nets with a few lines in a SPICE deck.
In an enlightening section in the second half of his book Bob demonstrates how difficult a reliable test-board can be to produce. I take this as a challenge as an engineer to make the final product as insensitive as possible to external elements (within reason). Bob has some good points but if you can pull sensitive components inside the chip there is much to be gained in terms of resistance to handling. If the passive device is not present it can't mess up or go bad.
The scale of electronics is changing. The discrete components are expensive for our customers and take up valuable board space. Complicated circuits (such as a calibrated ADC) cannot be hacked together on the bench easily. The simulator has its purpose. Bob's book is still useful today because the physics of the analog situation has not changed. As long as the physics remains so will Bob's book. Buy it, Read it, Live it!
-----------------------------------------------------------------------
SSA Announcements:
Saturday 1/25/2014 San Francisco Yacht Club
UC Davis Engineering Awards on January 25th in San Francisco where Stephen will accept his teaching award.
February 2/9/2014 through 2/12/2014 ISSCC 2014 San Francisco
I will be attending the ISSCC 2014 in San Francisco from 2/9 through 2/12. I will be staying at the hotel.
-Ken
Subscribe to:
Posts (Atom)