I was on vacation in Mexico when I wrote this about my transition from college to work.
In the final stages of my thesis I set out to interview at several companies and ended up at Level One Communications. Dave Nack was my manager for my first full-time job after graduating college. Dave was an excellent first manager and I am glad I chose the Level One route. Dave and I didn't always agree, but in the end Dave was always correct. The time period was 1998 pre dot-com bust.
My thesis advisors Stephen Lewis and Paul Hurst were involved in the Sacramento electronics scene since they do research in communications and data converters. Paul and Steve are also two of my key mentors (and more about them later). When a company sponsors university research it gets on the thankful students' radars. I am still very thankful and appreciate the companies who helped fund my interleaved ADC calibration work and decided to target those companies first. Level One was one of those companies.
I recall waiting in SSCRL for the Level One phone screen since I didn't have a cell phone and had to use the community lab wireless phone. 5pm went by and no Dave Nack. He didn't call the lab as he was supposed to. So I got on the lab phone and looked up the phone number for Level One on their (new) website. I called the Level one front desk hoping someone was still there. Once I got a hold of phone operator I asked for them to find Dave Nack. I was then transferred to a lab phone number and Dave was in there busy working. He sad "Dave Nack" and I responded "This is (SSA) and how about that phone screen?" Dave responded "We are going to call you back and setup an on-site. The fact you got a hold of me in the lab means you passed the phone screen. Sorry I forgot."
During the interview process I try to treat the companies basically the same, and of course improve as I go along. I used some of my last money to buy a suit at Mens Wearhouse along with a blue blazer. (I prefer to interview in a blue blazer if I can since its a little less formal than the suit.) I would wear that, dress pants and leather shoes. I also wear a tie normally a muted blue or dark red. My father in-law clued me in on an excellent book titled Sweaty Palms: The Neglected Art of Being Interviewed. In this book the author, H. Anthony Medley, discusses interview behavior, styles, how to dress and also how to behave at meals. He also includes a way to reduce the clammy handshake. You can get that book in Kindle for cheap it could 10X your chances of getting a job, based on my interactions interviewing dozens of interns at a previous company. The more prestigious the school, the more they needed Medley's book or so was the trend. I hear that Silicon Valley is "relaxed" but I still don't buy into that as an excuse to show up in blue-jeans and a t-shirt. (As a manager, personaly your odds reduce to near zero if it appears you are not willing to put the effort into getting the job. Is that also how you do design?)
I always come prepared as much as possible for an interview. Get a good nights sleep beforehand. I bring a folder or a small document bag that contains an engineering notepad and a separate notepad with information about the company (my notes from studying the company and its product lines). In addition I would have a calculator (cell phone with calculator), a pen or mechanical pencil, and an extra copy of my resume. Most engineers I know that do interviews still like a whiteboard or paper. If you handwriting is bad stick to paper. Before the interview I try to get the list of people I will meet ahead if possible so I can study their names and titles. There are memory techniques I learned along the way (Kevin Trudeau's Mega Memory) that enable me to memorize the names of everyone I meet. I use the engineering pad during the interview to solve technical problems. If you are fresh out of college this will be a big part of the interview getting and answering technical questions. (Fresh-outs should bring wit, enthusiasm and energy to an interview. Be careful not to over-do it, read Sweaty Palms) I would only take only brief notes during the interview on my non-engineering notepad. That notepad was most useful after the interview. As soon as possible after the interview its good to write notes about everything you experienced, saw, or messed up and compile notes on the people you met. It may take weeks to get through the whole process, you will meet a number of people and may forget a critical detail, so don't be afraid to write 5 or more pages of notes. These post-interview notes will be combined with my initial notes and later used to help size up the opportunity. In the beginning of your career you should be looking for mentors and some stability. A start-up is normally a bad-idea for a fresh-out, since you will probably be abused or be in an unstable situation and NOT have the street-smarts to know it. Running a good IC company is not just technical, it requires a cohesive team. During your interviews if you meet what looks like a good mentor make a note of it. If you find a jerk also make a note of it. Your school network (IEEE, LAB) may also may have some notes and even example questions from their interviewers assuming those students already have taken jobs or eliminated the company you are interested in. I know the SSCRL lab had example questions from hiring managers including Dave Nack. Often students would talk about their interview experiences giving valuable insights.
I interviewed at just under ten different companies. I learned a lot by checking out many companies at the same time. Companies have personalities like people. Their size, age, product lines and where they are located all all factors. Best was small, stable and growing. Worst was "We can pay you low because our company is great and you are new and not worthy." Not realizing I have a choice. Understanding that I was still new to the business I wanted to observe how companies can make decent money on mixed-signal and analog. It came down to two, Crystal and Level One. Level One was the best fit and ironically didnt require I move . The interview at Level One was actually fun and I didn't want to leave. I liked the people, lots of SSCRL grads (Chuc Thanh, Jim Parker, Charles Cai), the noise level (not too quiet), the company was growing rapidly and appeared to be a fun place to work. I met Perry Heedley during that interview yet another reason to work there. There were also many other good technically excellent (and cool) people. Dan Ray was a big influence he liked the mixed-signal DFE work and adapted the concept to a couple of product lines I would later design a transmitter for.
When I make a career decision after interviews I normally turn to a Excel spreadsheet as a tool. I make a scale from 1-10 and pick a weighting where the topmost items on the list have the highest influence. The most important factors I use are personal and yours should be to. The list can generate a custom score for each company you interview with. This is an example of what my list might have looked like:
#1. Will this job make happy/help to accomplish my career goal?
#2. How does the project and company personality fit your strengths?
#3. How would taking the job affect my Spouse (and children)?
#4. How would taking the job affect my extended family? Travel?
#5. How close is this job to friends or people in your network (other places to work)?
#6. How well do I like my potential manager and his reputation?
#7. How-many good potential mentors available? ( - people you didn't like)
#8. How competitive is the salary offer?
#9. How competitive is the whole compensation including benefits.?
#10. Level of opportunity vs. stability
The list is also important if you have to turn down a company since you would have identified what makes it not a good fit. Politely put negative feedback be can be useful to human-resources and potential hiring managers. How were you treated during the interview? Did you wait around? Did you talk to the people who you were supposed to or substitutes? Is the place a mess? In some cases negative feebdack can open up negotiations since most everything is negotiable during an interview process. Some things are easier to negotiate than others. Post college I have added a "life coach" and discussions with key collegues as well as Paul and Stephen.
Level One clearly passed my spreadsheet and gut test, so I took the job after submitting my thesis to the second of the three professor readers required. Its very difficult to write your first thesis draft while working full-time. You are not paid to do your thesis during work hours, so those are done on your own time. Companies will complain about delays but its not uncommon to negotiate a delayed start of a month for a student to get their studies in line. This brings me to another point that employers interview when they are looking for employees. Once they find someone the position (rec) is normally closed. So if you wait till the very end of your studies to interview you may have to pass up a great opportunity. You also have the freedom to reject the not so good jobs Its better to interview and be honest about your readyness than to wait until its all over since starting dates are negotiable. Collect data. Its not a good idea to interview at a company if there is zero chance you will work there. In those cases, you can offer to do a talk at the sponsor's site, saving a lot of time on both sides of the interview table while gaining respect since time=money.
My first job function at Level One was Electrostatic Discharge protection and pads (ESD) since we had a designer going out on maternity leave. Dave was my manager, mentor and was there when I needed him (Along with lots of help from my new friend and mentor at the time, Perry Heedley). Dave would fight for me and go to bat for me. He focused on culture and efficiency, not just getting the most hours of work during a week at minimal cost. (This required long-term, big-picture thinking and planning on Dave's side.) Dave didn't micro manage (Micro-manage=tell you each thing to do often in a list). Micro-management of highly competent people is bad since it stamps out creativity and eliminates feelings of accomplishment and ownership from a job well done thus leading to lower overall product quality. It was amazing and now in hindsight I had no idea how good he was as a manager. Dave worked hard to make sure I got everything I deserved including publication bonuses for university work that overlapped Level One. I try to copy Dave's style when I manage since it creates the positive karma required for a strong and dedicated team. Dave demonstrated that its not all about one person but building a cohesive team (not unlike a basketball team). The LAN group had career advancement potential all within a motivating environment. The transition from college to work wasn't easy for me and I had to work on my personal interaction style and Dave and Perry were very helpful. The biggest challenge I faced was working as part of the team. Its not efficient to do everything yourself so you need to learn the right times and ways to ask for help. On a healthy team everyone wants the chip to work, so its in everybody's best interest to help out new people.
After a few months of ESD I took over the (Gigabit media independent interface) GMII interface for a gigabit ethernet part. Then we had a labor crunch since the AFE was growing in complexity. Gigabit was a huge change for the company being the most complex SOC in the company at that time. Doing the gigabit Ethernet project was almost like trying to swallow too-big a piece of food. The methods of IC design change with the complexity. A brute-force design process can take much longer than expected and also have collateral consequences to other product lines within the company. If not done intelligently this can add huge amounts of cost and delays. (tape-out is a meaningless milestone..) In hindsight, the greatest cost came from a lack of focus on the primary goal of delivering a working reliable product. To combat the ever expanding schedule I ended up taking over the AGC and eventually the ADC debug. Later I would architect the ADC used for future generation 1G products.
To combat the complexity creep in SOCs we would try to stick to a methodology. Schematic signal flow left-right. Avoid drawing in all your bulk ties since they clutter up the schematic. Names should be clear and should not be mistaken for their complemented counterparts. Name power supplies with a number that represents the voltage with an "a" added to specify analog. Short list of passing names:
vdda2p5
vdda1p8
vssa
vddd
enable
reset
adcdataout<7:0>
Now back do Dave Nack, his schematics were quite horrible to look at. He would often use as few pages as possible but they were huge. Where Dave excelled with interface names. Daves signal names were "the best". This is where I came into conflict to Dave for the first time. I got my first review Dave gave me a "needs improvement" on one item, it was my signal naming convention. It wasn't good enough for Dave.
I used an MDAC or "Multiplying Digital to Analog Converter" for the gain-control in the gigabit. (This was based on a constant return-ratio approach from a paper authored by Bret Rothenberg and Paul Hurst.) Part of the MDAC has sampling capacitor array. The more capacitors that sample the input, the higher the gain. So as a key part of the AGC I had bunch of these little "leaf cells" that had a digital control signal on them called "sample". If sample=1, the capacitor in the cell samples the input. By setting more leaf-cell sample signals to 1, the gain of the circuit increases. The center of the block had a centroided grouping of these unit cells. The AGC had a gain range from like 0.5 to 2.5 or something like that, so some capacitor leaf-cells always had sample=1 to give the gain of 0.5. So on those cells I tied sample signal to VDDA2P5. Dave just wouldn't have that.
"Why would anyone connect a sample to a power supply?" Dave asked. I told him its an MDAC and it samples the input when that signal=1. "But its a sampling circuit".. Dave would reply. It dawned on me that Dave didn't fully understand the MDAC. He was confused by the way the "Sample" signal was used, it was interfering with his ability to understand the circuit. It was making him confused. My choice of signal name was a problem.
So Dave did convince me. If there is a signal name that can be interpreted in different ways, or associated with an unrelated function its name should be changed. Normally these bad signal names give them selves away by coming up in group meetings or discussions. I know digital designers don't like to change signal names, but sometimes the work of a few digital designers changing a port listing is less than hours of wasted time in group meetings. Dave is right, if your schematic port-name is unclear or causing complaints, get over yourself and change it.
I miss Dave as he passed away while at work in Irvine some 5 years after we parted ways. As I type this I am sitting on a ship on the mouth of the Sea of Cortez in Mexico thinking about Dave. Dave had a boat and loved to take it on the Sacramento river. He seemed to be most happy when talking about spending time with wife, son and daughter on the river. Its sad that such a great analog talent had to die so young. Sometimes I wonder what life would be like with Dave around. In some ways, I guess he still is.
Monday, April 15, 2013
Thursday, March 7, 2013
SSA College 1987-1994
Recently I have been made aware of a program called Stay With It. Stay with it encourages engineering students to stick with the difficult curriculum. Going to college with an engineering major is not easy and I couldn't have done it alone. As time progressed classes got thinner and thinner from undergrad through grad-school.
This post is long and about my BSEE and MSEE experience. After high school I attended college in Santa Rosa then later transferred to UC Davis in 1988. During my MSEE I made my income as a TA and RA while doing debug and repair at local recording studios and a laundry mats. I saved money building my own computers.
This post is long and about my BSEE and MSEE experience. After high school I attended college in Santa Rosa then later transferred to UC Davis in 1988. During my MSEE I made my income as a TA and RA while doing debug and repair at local recording studios and a laundry mats. I saved money building my own computers.
In fall of 1986 I started at Santa Rosa Junior College (SRJC). Some people called it 13th grade but my applications to Caltech, Berkeley and Davis were denied in spite of my graduating somewhere in the top 5 students in my high-school class at CGHS in 1986. If I got accepted into those schools I don't how I could have afforded it anyway. My parents made enough money to disqualify me from most scholarships but didn't have (or choose) to support me in college outside of a little help here and there. (I covered some 98% of my total college costs by working multiple jobs, getting grants and awards. I admit it was easier back then..) I think going to the Junior College was the right move and wouldn't do it any other way. SRJC offered a Doyle scholarship that was very helpful and easy to get even if your parents claim you on their taxes. The lower-division class sizes at the JC in Engineering, Physics and Math were small compared to those at UC. The small class sizes (12-20 people) allowed you to stop the professor without worrying about what 100 other people would think. When people asked to stop the instructor normally most of the class was also confused. Also, you got to know your classmates well since there weren't too many. SRJC was close to home and my parents generously let me live rent free while going to school during that time. This helped me to work to pay them back for the car loan which was a "high-school graduation present" to me and twin brother who shared (and repaired) that car for the following four years. I used this period of time living at home to save as much money as possible by doing some electronics repair and working a part time security job.
Books, fees and supplies were shockingly high for physics, engineering and math students. We called it the $70 equation fee, the extra charge for adding one or more math equations to a textbook. The bookstore was a shock and cleaned me out of cash a few times. Even engineering paper seemed awfully expensive but I still carry a pad to this day since its so useful. In general I don't think I ever sold any engineering books back. Sometimes they are good to brush and refresh your mind before starting some technical work. (One time after book shopping at UCD my Dad saw my ATM receipt with a $17 balance and called me on it. "Glad I have a full tank of gas!")
Books, fees and supplies were shockingly high for physics, engineering and math students. We called it the $70 equation fee, the extra charge for adding one or more math equations to a textbook. The bookstore was a shock and cleaned me out of cash a few times. Even engineering paper seemed awfully expensive but I still carry a pad to this day since its so useful. In general I don't think I ever sold any engineering books back. Sometimes they are good to brush and refresh your mind before starting some technical work. (One time after book shopping at UCD my Dad saw my ATM receipt with a $17 balance and called me on it. "Glad I have a full tank of gas!")
There is a club at SRJC called TEC "The Engineering Club" and it was a great place to meet people and do homework. TEC also had great parties I know I used some of my "home repaired" amplifiers (see previous post) to DJ an event or two. Along the way at SRJC I discovered that its easier to learn when you are working with and cooperating with your peers. There were some scholarships you could get through TEC. Not everyone was in TEC some students were more independent and also did well. TEC had fun trips to nearby companies where engineers worked. It was a nice glimpse into the work environment and in one case the contacts I made helped me get a job. TEC makes a point of not bothering companies you visit for internships while on the field trip, however that doesn't mean you cant take the initiative to contact people you meet later on. I interned for two summers in 1988-89 at OCLI (now JDSU) working in the MAC Glass Fab unit at first sanding the edges on front-surface mirrors and then later working with the engineering group improving safety and productivity. So TEC at SJRC helped to make the homework easier, added fun and led to some of my earlier engineering experiences.
At SRJC I learned to use an oscilloscope for the first time it was a huge step from just using a volt meter. The scope-expert trainer prof. Herb Sullivan also introduced me to the IEEE. The IEEE is a big help and I'll get to that. Herb told me to seek out the student chapter of the IEEE once I got into a four year college. There was a "transfer" program at SRJC at that time. Assuming I got a certain GPA in a given set of engineering courses I would have a 100% chance of being accepted into the college of Engineering at UC Davis. Davis was not too far from where I grew up and its engineering program was more quaint than UCB. I liked the attention from the cooperative instructors at SRJC and hoped for that at Davis. I met my GPA goal and moved to Davis in 1988 for my junior and senior year. It was tough saying goodbye to my TEC buddies we went in all directions.
Davis had an "Orientation weekend" before the start of the school year that I found very useful. Tim and I drove out there with our car (without AC) during the hot summer. The campus was overwhelming and it was nice to have someone take you on a guided tour. They were ready for us and had engineering profs. available for us and I got a copy of the course catalog. The prof told me how the catalog worked and I was able to get enough information to plan the first quarter. UCD is on a quarter system which has a pace that is pretty fast. Pretty much immediately I got involved with the IEEE at UCD. It wasn't hard there were posters around the engineering building. There were many organizations in addition to the IEEE, SWE, TMS and PACE come to mind. Later I would get into Tau Beta Pi which would lead to career opportunities later on down the line. SWE and IEEE would have get togethers and it was a great place to connect with like minded students. Not everyone was in an engineering club some students were "too busy" or too introverted. In the workplace its hard to work in a bubble, so the interaction with the clubs at UCD was also good for social skills. Also when it came to picking classes it was useful to talk to your new friends. I saw most the same people in my classes. Near the end of the quarter it wasn't uncommon to hear the "What are you taking?" conversations. Also the club people and classmates helped you pick the "better" professors. (This was 1988-1990 and there was no world wide web at the time so I am pretty sure today the clubs may be virtual and have a presence like Stay With It.) Some of the engineering and math courses were tougher than the others and I got my worst grades in statistics. We all are different and consider your grades as feedback as to what you are best at. You don't have to get A's in everything to be a successful engineer later on, but its easier if you play to your strengths.
During my BSEE I pretty much burned up all the cash I had saved while going to the Junior College. I did have some small savings from my grandparents and money saved from my appearance as "Joey" in the Big Valley episode "The Prize" (google it). In spite of that the money situation was still bad and I needed to do get as much electronic work as possible.
During my BSEE I pretty much burned up all the cash I had saved while going to the Junior College. I did have some small savings from my grandparents and money saved from my appearance as "Joey" in the Big Valley episode "The Prize" (google it). In spite of that the money situation was still bad and I needed to do get as much electronic work as possible.
To graduate in 2 years at Davis I had to take elective classes (in my undergrad minor: chemistry) during the summer. I got my best grades in analog and circuits courses but the job opportunities at the BSEE level in that area were scarce. I got the message the BSEE wasn't enough for interesting circuits. To open the door to more interesting job opportunities I applied for and was accepted into the MSEE program in 1990 without taking any break. I was able to get a TA position for a lab class that paid enough for me to barely live on with two roommates I met during undergrad. Money was so tight that I had to find work during the summers while going to school.
With graduate degrees your choice of a project is very important since it will probably define the initial direction of your career. If you work hard doing research on a tough project (selected by your thesis adviser) you can get paid as a Research Assistant (RA). Being a RA helps you to spend less time as a TA or working part-time jobs off campus. If you pick your own project, professors will normally support this but you may not get a jobs as an RA. The most you are officially allowed to work at the time wast 50%. You could do a full-load of classes with as much as a 20hrs/week of work at UCD. Also it was possible to get the department to pay your registration fees but you are required to pay taxes on the gain. That law was passed during the Bush era since "parents normally pay that tax anyway", not in my case I had to find work to pay it.
It was possible to get scholarships and grants if you look carefully. There are opportunities for all students some more or less depending on your ethnic data. I found that the grant proposals that took a bit more writing were the easiest to get. For example you need to give a budget and write a detailed proposal on what you will do with the money. It takes some time and thought but if you hit one it can make a huge difference. Even with my choppy writing style I got one grant and one award.
The graduate students group Solid state circuits research lab (SSCRL) was originally in Bainer hall then later relocated to Kemper where we spent the most time. Arne, Namdar, Ravi, Tom, Tim, Wes, Bret, Jim(s), Mike(s), Chuc, Charles, Daihong, Jun, Ke, Ozan (who could barely out-solder me) and so many more. Sorry if I left you out were all there. My graduate student friends were a big help in me learning analog and the lab was a temporary home base on campus. I think I learned almost as much from the other students then I did the classes. I also made some really good friends and ironically my manager today is a UCD SSCRL grad.
With graduate degrees your choice of a project is very important since it will probably define the initial direction of your career. If you work hard doing research on a tough project (selected by your thesis adviser) you can get paid as a Research Assistant (RA). Being a RA helps you to spend less time as a TA or working part-time jobs off campus. If you pick your own project, professors will normally support this but you may not get a jobs as an RA. The most you are officially allowed to work at the time wast 50%. You could do a full-load of classes with as much as a 20hrs/week of work at UCD. Also it was possible to get the department to pay your registration fees but you are required to pay taxes on the gain. That law was passed during the Bush era since "parents normally pay that tax anyway", not in my case I had to find work to pay it.
It was possible to get scholarships and grants if you look carefully. There are opportunities for all students some more or less depending on your ethnic data. I found that the grant proposals that took a bit more writing were the easiest to get. For example you need to give a budget and write a detailed proposal on what you will do with the money. It takes some time and thought but if you hit one it can make a huge difference. Even with my choppy writing style I got one grant and one award.
The graduate students group Solid state circuits research lab (SSCRL) was originally in Bainer hall then later relocated to Kemper where we spent the most time. Arne, Namdar, Ravi, Tom, Tim, Wes, Bret, Jim(s), Mike(s), Chuc, Charles, Daihong, Jun, Ke, Ozan (who could barely out-solder me) and so many more. Sorry if I left you out were all there. My graduate student friends were a big help in me learning analog and the lab was a temporary home base on campus. I think I learned almost as much from the other students then I did the classes. I also made some really good friends and ironically my manager today is a UCD SSCRL grad.
In 1991 I met Tom Matthews (now CSUS faculty) who was a member of the SSCRL at UCD. After class I was using the bench for some hobby work and Tom is also a electronics hobbyist and he couldn't help but say hello. Tom is an awesome "hands-on" type of analog guy who was a few years ahead of me in graduate school working on his Ph.D. (He was interested in microphones and loud sound systems at the time, other great stories there.) During one of our conversations he told me that he made some money on the side by doing repair for recording studios. It was decent money and Tom thought I would like it. He introduced me to "Dave" at RNP studios in Sacramento who needed some debug and soldering work done. There were many different debugs at RNP most of them involved things that make strange noises. The studio was open during the day and I was only allowed to work at night after 8pm. The goal was to return the studio to "equal or better" functionality by the time you left so the morning shift can use the gear. The jobs were on reel to reel tape decks up to 32 tracks, two common brands of mixing consoles with dozens of sliders, DATs, VCRs, patch bays and studio tough custom XLR cables. I always made a point to clean up the gear and replace any burnt bulbs. Remove you rings before reaching into an open channel on a hot console.
One debug worth mentioning at RNP was the "noisy chair" problem. During a recording session, if the engineer rolled his chair on the platform around the mixing console static would get into "the mix" and was causing the recording engineers headaches. I took on this problem showing up at 8pm with my toolbox. I entered studio a and sat in front of the console. By wheeling around you could make different noises. It seemed correlated to chair motion. The previous tech thought it was something "loose" in the mixing console and was cleaning the sliders etc. but the problem returned and he gave up. Sometimes when I try to solve a problem I "take a walk" around and think. So I was walking around the studio when all of a sudden the noise happened but without the chair. I looked down and saw "the snake". The connection between the power and the mixing console is often called "the snake". Its large, heavy and is one of the reasons the mixing console is raised with the snake passing underneath the platform. The debug tool was "foot". I kicked the snake and nearly blew the speakers. The connection between "the snake" and the power supply was corroded. I powered down the console and pulled the snake off the supply unit and cleaned and lightly sanded the connections, then plugged it back in. The chair no longer made noise and it took me less than 1 hour but they paid me for 2.
During that time we "made" our own desktop PCs. It was too expensive to by a Compac or a store bought machine so we made our own. Thats when I met Rick D. and Ian M. Both of those guys helped me to learn about building and debugging computers. Ian introduced me to a local Laundry mat (Soap City) owner who had a couple of stores in Davis.
The Soap City automated laundry mat was a decent source of income. The store had an automated system that allowed a person to control coin-op 30 or so washing machines and dryers remotely from a central panel. The guy who invented and supported the system died and the store owner was in a tough spot. The receiver units would fail at high temperatures in the dryer and my jobs was to repair those bad units. The problem there was thermal and by punching holes in the receiver boxes you could more than double their life.
At the completion of my MSEE in 1993 I observed that it wouldn't be too hard to make a living just doing mobile debug/repair for businesses. Not may people do "house calls" on electronics these days it seems. I was able to avoid spending all my small savings on my MSEE which would later get completely wiped out when I focused on the Ph.D.
You can make a very good living with an MSEE these days. If you can handle electronics and want the most money in the shortest period of time, go for the MSEE which opens the door to many more interesting and higher paying jobs than the BSEE. The Ph.D. poses a problem that it delays the start of your career which postpones your savings and debt payoff. Also the salary difference between MSEE and Ph.D. is not huge. It takes many years (if ever) to catch up if you do the Ph.D. path. For this reason I stopped work at the studio and handed off the laundry mat work after getting married in 1995. My lovely wife Geraldine was a huge help since she worked at UCD (still does) and had income which made it easier to get by. For hobby electronics I consider 1995-1998 the "dark ages" since I had to focus. I even backed off 90% on the repair business. I discovered "Quicken" and still used it to track my spending.
One general contrast between college and the work force is that professors are just "giving it away". As professionals we don't share trade secrets or internal processes to our competitors. However in college, if you ask a professor a question they will normally give you an answer or lead you to it. College is the time to absorb knowedge in this type of environment. Once you get in the work force there is considerably less time for learning since you are expected meet a tight product schedule.
At the completion of my MSEE in 1993 I observed that it wouldn't be too hard to make a living just doing mobile debug/repair for businesses. Not may people do "house calls" on electronics these days it seems. I was able to avoid spending all my small savings on my MSEE which would later get completely wiped out when I focused on the Ph.D.
You can make a very good living with an MSEE these days. If you can handle electronics and want the most money in the shortest period of time, go for the MSEE which opens the door to many more interesting and higher paying jobs than the BSEE. The Ph.D. poses a problem that it delays the start of your career which postpones your savings and debt payoff. Also the salary difference between MSEE and Ph.D. is not huge. It takes many years (if ever) to catch up if you do the Ph.D. path. For this reason I stopped work at the studio and handed off the laundry mat work after getting married in 1995. My lovely wife Geraldine was a huge help since she worked at UCD (still does) and had income which made it easier to get by. For hobby electronics I consider 1995-1998 the "dark ages" since I had to focus. I even backed off 90% on the repair business. I discovered "Quicken" and still used it to track my spending.
One general contrast between college and the work force is that professors are just "giving it away". As professionals we don't share trade secrets or internal processes to our competitors. However in college, if you ask a professor a question they will normally give you an answer or lead you to it. College is the time to absorb knowedge in this type of environment. Once you get in the work force there is considerably less time for learning since you are expected meet a tight product schedule.
In the next post I will include a section on "getting that first job".
Wednesday, February 20, 2013
The Early Years of SSA 1984-1990 in The Shack
Over the years I look back on my involvement in electronics. Initially it was a hobby, then as I progressed through college now its a fun and decent way to make a living. I don't do as much hobby work as I used to since I basically do electronics all day now. This post is a brief autobiography covering 1984 to 1990. During that time I worked on analog kits, radios, televisions, consumer electronics and even a Donkey Kong.
My dad was the key founder of my electronics hobby. If you read my Bio he gave me a book in 1979 and built a crystal radio that I listened to the local AM radio station on. Then I moved onto spring-clip electronics kits and a "Science Fair" electronics kit. I would go to garage sales on my bicycle buy up hobby kits, then order replacement parts from radio shack and then wire away. I would then do all the experiments if there was a guide. Afterward I would connect the kits together with a bunch of telephone wire I picked up when they did a splice nearby. I could make an AM radio that could actually drive a speaker at a decent volume. AM stations were not as horrible as they are today and we could listen to AM for hours on a 9V battery.
My twin brother Tim and our friends were key helpers into getting into the electronics hobby. My electronics buddies Rich M the digital guy, Aaron S the tube guy and David B the robot builder. Rich M taught me to solder when I was 10 years old, he was 11 at the time in 1980. In 1982 I saved my money and bought a kit for a home-built Radio Shack analog volt meter 25KOhm/volt. The volt meter kit was a huge leap in terms of making real measurements. (That "kit" volt meter was stolen years later during a Tubes concert at the Phoenix Theater. Aaron S. bought me a DVM to replace it.) Our geeky group didn't fully assemble until 1982 in high-school when I met Aaron S. Aaron had a truck and a drivers license, he was the slightly-older guy in the bunch and had some tech school training in electronics with generally good technique and a fantastic memory. Aaron was a huge help and one of our favorite things to do was taking apart and stressing electronic items with our friends. We would go to a thrift store and buy items cheap. The TVs back then were tube or tube-transistor hybrids. You could fix TVs by purchasing a bunch and a tube manual helps. Then would would repair and sell off the good TVs this was around 1984-87. Sometimes we would get an old 5-tube AM radio with a bad cap or a transistor set with a bad power supply we couldn't find a replacement for. These radios would be crushed and stripped for parts. Selenium rectifiers were shorted and overloaded (stinky). Sometimes fireworks, automobiles and baseball bats were involved. Reading resistor color codes became habit for scavenging. There were those countless hours with the soldering iron soldering lights on robots with Dave B. Those old parts were the source of some fun times. We did a lot of electronic component testing at 120V AC. Don't try that at home. Mostly the parts just piled up. In hindsight only smaller fraction was used for repair or real projects.
The Sony Walkman was very popular back then along with "boom boxes" it was the early 80s. These were a great source of income for me back then. The headphone jack would get loose or the wire would come off the magnetic head that reads the tape. Also the head would go out of alignment or the battery contact would fall off. Knobs and antennas get broken from boom boxes. I have lost track of how many. In 1985 120VAC to 12V DC power supplies were expensive so I used surplus store components to built them for me and friends at cost or for a beer. I called my 12V 10A supply "Nuke". We would use them to run CB radios, car stereos and DC motors.
Radio Shack was a huge source of parts boy I loved that place before 2000. I would spend my money on their books "The Engineer's Notebook" and "555 Timer IC Circuits" and Bipolar design. Me and my electronics buddy Rich would build the circuits on breadboards. Most of the circuits in the books could be made from cheap components hanging on the wall at Radio Shack. We would also buy old "unrepairable" electronics, customer returns and phased out components from Radio shack. They had turntables, amplifiers and toys. Even Tandy's "Surprise Boxes" where I got some great stuff like a stepper motor. My favorite was the stereo amplifier since I like analog audio. Often they had the schematic available and they were not too hard to debug. All you did was to "look for the smokey spot" and then rebuild the circuitry around it. If one channel worked, you could debug the other by comparing DC voltages. During that time period I didn't understand why the schematic looked like it did, I could debug it by comparison. It was always a battle of lack-of information or lack of knowledge (about feedback-stability theory) yet forging on ahead in the debug a by checking connections and keeping notes with observations. Fortunately the circuits were mostly constructed from discrete components with very few integrated circuits. Thru-hole resistors and capacitors were much bigger than today's more popular surface mount components. The older technology help to made learning to debug easier than today.
Around 1987-88 I did some video game repair on some now infamous stand up consoles. It was pretty common for the game "TV" monitor degaus circuit to blow up and take down the monitor. The two machines I saw this on were Donkey Kong Jr and a Donkey Kong. All the parts could be ordered from MCM Electronics. A local movie theater owner discovered I could repair electronics and had me work on those games. The Donkey Kong deal was quick it was back in the theater right away after I fixed a bad thermistor. As for the Junior machine that sat in the garage for a couple months. We had it out in the garage and set it to free play and the locals loved it. It was a sad day for everyone when Dave the theater owner paid up and took away the game.
In 1990 I completed my BSEE at UC Davis and things changed on the hobby front. At the end of the BSEE I was spending time in well outfitted labs, with loads of "free" components and real test equipment. There were profs and TAs that could explain things and give you help if needed. Some of those TAs encouraged me to branch out and make money from doing repair in Sacramento. My home setup of breadboards no longer looked as appealing as my proto-board with an oscilloscope attached on a bench at UCD. The group from the high-school analog days had pretty much gone their ways. I have never lost contact with Rich M who went on to get a degree in computer science at SSU. The completion of my BSEE ended what I call the "just for fun" period and I got more business minded. Debugging automated laundry mats and recording studios repairs were next while I worked on my MSEE, the subject of a future post.
My dad was the key founder of my electronics hobby. If you read my Bio he gave me a book in 1979 and built a crystal radio that I listened to the local AM radio station on. Then I moved onto spring-clip electronics kits and a "Science Fair" electronics kit. I would go to garage sales on my bicycle buy up hobby kits, then order replacement parts from radio shack and then wire away. I would then do all the experiments if there was a guide. Afterward I would connect the kits together with a bunch of telephone wire I picked up when they did a splice nearby. I could make an AM radio that could actually drive a speaker at a decent volume. AM stations were not as horrible as they are today and we could listen to AM for hours on a 9V battery.
My twin brother Tim and our friends were key helpers into getting into the electronics hobby. My electronics buddies Rich M the digital guy, Aaron S the tube guy and David B the robot builder. Rich M taught me to solder when I was 10 years old, he was 11 at the time in 1980. In 1982 I saved my money and bought a kit for a home-built Radio Shack analog volt meter 25KOhm/volt. The volt meter kit was a huge leap in terms of making real measurements. (That "kit" volt meter was stolen years later during a Tubes concert at the Phoenix Theater. Aaron S. bought me a DVM to replace it.) Our geeky group didn't fully assemble until 1982 in high-school when I met Aaron S. Aaron had a truck and a drivers license, he was the slightly-older guy in the bunch and had some tech school training in electronics with generally good technique and a fantastic memory. Aaron was a huge help and one of our favorite things to do was taking apart and stressing electronic items with our friends. We would go to a thrift store and buy items cheap. The TVs back then were tube or tube-transistor hybrids. You could fix TVs by purchasing a bunch and a tube manual helps. Then would would repair and sell off the good TVs this was around 1984-87. Sometimes we would get an old 5-tube AM radio with a bad cap or a transistor set with a bad power supply we couldn't find a replacement for. These radios would be crushed and stripped for parts. Selenium rectifiers were shorted and overloaded (stinky). Sometimes fireworks, automobiles and baseball bats were involved. Reading resistor color codes became habit for scavenging. There were those countless hours with the soldering iron soldering lights on robots with Dave B. Those old parts were the source of some fun times. We did a lot of electronic component testing at 120V AC. Don't try that at home. Mostly the parts just piled up. In hindsight only smaller fraction was used for repair or real projects.
The Sony Walkman was very popular back then along with "boom boxes" it was the early 80s. These were a great source of income for me back then. The headphone jack would get loose or the wire would come off the magnetic head that reads the tape. Also the head would go out of alignment or the battery contact would fall off. Knobs and antennas get broken from boom boxes. I have lost track of how many. In 1985 120VAC to 12V DC power supplies were expensive so I used surplus store components to built them for me and friends at cost or for a beer. I called my 12V 10A supply "Nuke". We would use them to run CB radios, car stereos and DC motors.
Radio Shack was a huge source of parts boy I loved that place before 2000. I would spend my money on their books "The Engineer's Notebook" and "555 Timer IC Circuits" and Bipolar design. Me and my electronics buddy Rich would build the circuits on breadboards. Most of the circuits in the books could be made from cheap components hanging on the wall at Radio Shack. We would also buy old "unrepairable" electronics, customer returns and phased out components from Radio shack. They had turntables, amplifiers and toys. Even Tandy's "Surprise Boxes" where I got some great stuff like a stepper motor. My favorite was the stereo amplifier since I like analog audio. Often they had the schematic available and they were not too hard to debug. All you did was to "look for the smokey spot" and then rebuild the circuitry around it. If one channel worked, you could debug the other by comparing DC voltages. During that time period I didn't understand why the schematic looked like it did, I could debug it by comparison. It was always a battle of lack-of information or lack of knowledge (about feedback-stability theory) yet forging on ahead in the debug a by checking connections and keeping notes with observations. Fortunately the circuits were mostly constructed from discrete components with very few integrated circuits. Thru-hole resistors and capacitors were much bigger than today's more popular surface mount components. The older technology help to made learning to debug easier than today.
Around 1987-88 I did some video game repair on some now infamous stand up consoles. It was pretty common for the game "TV" monitor degaus circuit to blow up and take down the monitor. The two machines I saw this on were Donkey Kong Jr and a Donkey Kong. All the parts could be ordered from MCM Electronics. A local movie theater owner discovered I could repair electronics and had me work on those games. The Donkey Kong deal was quick it was back in the theater right away after I fixed a bad thermistor. As for the Junior machine that sat in the garage for a couple months. We had it out in the garage and set it to free play and the locals loved it. It was a sad day for everyone when Dave the theater owner paid up and took away the game.
In 1990 I completed my BSEE at UC Davis and things changed on the hobby front. At the end of the BSEE I was spending time in well outfitted labs, with loads of "free" components and real test equipment. There were profs and TAs that could explain things and give you help if needed. Some of those TAs encouraged me to branch out and make money from doing repair in Sacramento. My home setup of breadboards no longer looked as appealing as my proto-board with an oscilloscope attached on a bench at UCD. The group from the high-school analog days had pretty much gone their ways. I have never lost contact with Rich M who went on to get a degree in computer science at SSU. The completion of my BSEE ended what I call the "just for fun" period and I got more business minded. Debugging automated laundry mats and recording studios repairs were next while I worked on my MSEE, the subject of a future post.
Monday, January 28, 2013
LC sTank
Recently I have taken on a new project that has LC tank based PLLs on it. The company I now work for has a long history with this type of block, and I appreciate that. I have seen a few bad LC tank PLLs in my time. They can fail in several different ways. The most interesting failures with oscillators is that when they don't.
I have seen ring-oscillator, relaxation-oscillator and LC tank based oscillators used as the time-base for a system on a chip (SOC). The type of oscillator basically comes down to its performance and cost. If you want the best high-frequency reference, the LC tank with its huge die area overhead is hard to beat. The LC tank has a natural filtering property to it that gives it good phase-noise filtering, leading to lower jitter. I have mentioned it before but Hajimiri has a great book "Low Phase Noise Oscillators" which is an excellent read. Hajimiri explains the phase noise filtering and Leeson's equation.
The first chapter of Ali Hajimiri's book is about the "one-port" oscillator. I found it entertaining that an oscillator only has "one port" in terms of energy. In electronic design, a port is a way of electrically interacting with it. A terminal or lead on a chip is an example of a port. Ali explains that an oscillator on a chip will go forever if there were no "real losses". Real losses are where the "power goes". So Ali states, if you add back enough power to a "one-port" oscillator to compensate for its internal "real" losses, then it will oscillate forever. Ali's observation is insightful.
It was around the 2005 time-frame and we had a 90nm test-chip back in the lab with a 3.2GHz LC tank oscillator based PLL on it. The input reference clock was 50MHz or 100MHz and the goal was 1ps RMS jitter measured in band. The clock came back and looked great, phase noise looked "weird", but the jitter was excellent. The phase-noise had a distinct lack of bandwidth, the loop bandwidth was lower than expected. So what was wrong with this one?
We were characterizing the jitter over temperature and noticed something. At temperatures above 120F, the LC tank would stop oscillating. The output signal would fade out. Sometimes you could get it to start by "jacking up" the tank current. On this tank we pushed a adjustable current into a "center-tap" of the dual inductor at the point of symmetry at the center of the tank. The adjustable DC current supplies N-MOSFETS connected in positive feedback that created the regeneration. If we made the current high enough it would oscillate at a higher temperature, but still would die at a slightly higher temperature. Supply voltage was a "weak knob". The oscillator worked great at cold temperature.
Schematic level simulations didn't show any problems with the design over temperature. Even with package models. No problems observed in any corner with interface blocks. Since we were closing in on the oscillator, the next step after that is the "extracted" simulation set. These simulations can take a very long time to run. So. to save time. we broke the PLL layout into "sections". We then swapped in an RC netlist for the "section" of the PLL under study for temperature sensitivity. We rotated through the block and eliminated all the high current blocks (amazingly). Main inductor, power-grid on the main current source, high-frequency divider and the output buffer were all fine layout wise.
So now this is where Hajimiri ties in. The "last" place we looked was the varactor circuit. This was a tricky animal that combined a varactor with a trim-cap array. A trim-cap array is normally used at start-up for an LC tank based PLL to center itself. At start-up the correct number of unit capacitors are selected before the PLL loop is allowed to lock. This "Loop Filter" block is interesting in that it has a "lot of plumbing", and that was the problem. When putting in an RC extraction of the Loop Filter, we identified the bad layout.
It was series resistance to the capacitor "C" in the "LC" tank! A pair of long skinny wires connected the inductor to the Cap. It was the first time I saw a parasitic resistor stop a circuit in its tracks. The resistances in the routing increase with temperature. The real-loss in this poorly routed line was enough to upset the operation of the LC tank. The wire on the chip would heat up and the circuit would stop oscillating. What was interesting, is that the simulation and the lab failed within 10 degrees of each other. It was an amazing correlation. The new simulations also showed the change in phase-noise response, which was the first symptom of the badness. Of course after we identified this the layout fix was easy.
So, in the LC tank PLL, don't spend so much time on L that you forget about C. Real loss is the enemy.
I have seen ring-oscillator, relaxation-oscillator and LC tank based oscillators used as the time-base for a system on a chip (SOC). The type of oscillator basically comes down to its performance and cost. If you want the best high-frequency reference, the LC tank with its huge die area overhead is hard to beat. The LC tank has a natural filtering property to it that gives it good phase-noise filtering, leading to lower jitter. I have mentioned it before but Hajimiri has a great book "Low Phase Noise Oscillators" which is an excellent read. Hajimiri explains the phase noise filtering and Leeson's equation.
The first chapter of Ali Hajimiri's book is about the "one-port" oscillator. I found it entertaining that an oscillator only has "one port" in terms of energy. In electronic design, a port is a way of electrically interacting with it. A terminal or lead on a chip is an example of a port. Ali explains that an oscillator on a chip will go forever if there were no "real losses". Real losses are where the "power goes". So Ali states, if you add back enough power to a "one-port" oscillator to compensate for its internal "real" losses, then it will oscillate forever. Ali's observation is insightful.
It was around the 2005 time-frame and we had a 90nm test-chip back in the lab with a 3.2GHz LC tank oscillator based PLL on it. The input reference clock was 50MHz or 100MHz and the goal was 1ps RMS jitter measured in band. The clock came back and looked great, phase noise looked "weird", but the jitter was excellent. The phase-noise had a distinct lack of bandwidth, the loop bandwidth was lower than expected. So what was wrong with this one?
We were characterizing the jitter over temperature and noticed something. At temperatures above 120F, the LC tank would stop oscillating. The output signal would fade out. Sometimes you could get it to start by "jacking up" the tank current. On this tank we pushed a adjustable current into a "center-tap" of the dual inductor at the point of symmetry at the center of the tank. The adjustable DC current supplies N-MOSFETS connected in positive feedback that created the regeneration. If we made the current high enough it would oscillate at a higher temperature, but still would die at a slightly higher temperature. Supply voltage was a "weak knob". The oscillator worked great at cold temperature.
Schematic level simulations didn't show any problems with the design over temperature. Even with package models. No problems observed in any corner with interface blocks. Since we were closing in on the oscillator, the next step after that is the "extracted" simulation set. These simulations can take a very long time to run. So. to save time. we broke the PLL layout into "sections". We then swapped in an RC netlist for the "section" of the PLL under study for temperature sensitivity. We rotated through the block and eliminated all the high current blocks (amazingly). Main inductor, power-grid on the main current source, high-frequency divider and the output buffer were all fine layout wise.
So now this is where Hajimiri ties in. The "last" place we looked was the varactor circuit. This was a tricky animal that combined a varactor with a trim-cap array. A trim-cap array is normally used at start-up for an LC tank based PLL to center itself. At start-up the correct number of unit capacitors are selected before the PLL loop is allowed to lock. This "Loop Filter" block is interesting in that it has a "lot of plumbing", and that was the problem. When putting in an RC extraction of the Loop Filter, we identified the bad layout.
It was series resistance to the capacitor "C" in the "LC" tank! A pair of long skinny wires connected the inductor to the Cap. It was the first time I saw a parasitic resistor stop a circuit in its tracks. The resistances in the routing increase with temperature. The real-loss in this poorly routed line was enough to upset the operation of the LC tank. The wire on the chip would heat up and the circuit would stop oscillating. What was interesting, is that the simulation and the lab failed within 10 degrees of each other. It was an amazing correlation. The new simulations also showed the change in phase-noise response, which was the first symptom of the badness. Of course after we identified this the layout fix was easy.
So, in the LC tank PLL, don't spend so much time on L that you forget about C. Real loss is the enemy.
Monday, January 14, 2013
The Nickel Philosophy and Transition
One of the purposes of this blog was to help my work associates understand my frustration with the way things were going. I kept seeing people repeat the same mistakes over and over again. So I used this block to "vent". Only so much venting is useful until the root-cause of the problem has to be addressed.
I addressed the root-cause and am now working on high-speed ADCs and communications again like I did from 1995-sh to 2009. I have changed jobs and now work advanced data converters in deep-submicron processes. My previous company had generously lifted me from Davis/Sacramento to the edge of the bay area and I am thankful for that.
I plan to keep up Street Smart Analog. I still plan to eventually write a book on analog design and debug, with this blog as the pre-cursor. Of course, the lack of recent posting is related to my career transition, which is now official.
The world of small component analog design including light sensors is radically different but also challenging. I have the utmost respect for the light-sensor product line and the people I left behind working on it. Those products have a lot of care and effort put into their development and should be the hottest selling sensors out there. However, I couldn't remain working on that product line due to The Nickel Philosophy. One of two things that hang's up in my cube along with the IEEE code of conduct. The sad thing here is that this transition could have been prevented.
I find the "Nickel Philosophy" from Jim Bracher and his associates at the Center for Integrity and Leadership to be a valuable tool in setting priorities. I have used this material of Jim's in Lectures at both UCD and Stanford.
Link: http://www.brachercenter.com/article_nickelphilosophy.html
The list of "effective priorities" called "The Nickel Philosophy". There are two catagories
A. Professional Profits:
#1 Customer service (how you treat your customers and your work mates; how are you treated)
#2. Quality product
#3. Career Opportunity
#4. Motivating Environment
#5. Everything else.. (not worth stressing about)
B. Personal Values
#1. Self/Significant other
#2. Family and Friends
#3. Heath and happiness
#4. Difference and dollars (how you are getting by)
#5. Everything else (not worth stressing about)
In my life at my previous employer I tried to make sure that all the people that reported into me experienced "Professional Profits". There are a multitude of reasons behind this list, its order and how it is presented, please look over the link above. If the place you work at does NOT follow the Nickel Philosophy AND there are other opportunities available, then the right thing to do is to move on, since you will eventually. What is interesting about this list is that Career Opportunity is right under quality product. It does make sense since without a motivating environment why bother about the opportunity. This list is a "person specific" view of the problem to be clear.
Today I saw a link today shared by an HR person from the previous company:
http://www.forbes.com/sites/ericjackson/2012/01/19/why-companies-are-terrible-at-selecting-retaining-and-motivating-their-talent/
Basically this article explains why people leave and is interesting to contrast with "The Nickel Philosophy".
Eric Jackson picks 10 reasons. Some of these items similar to Nickel Philosophy:
#1, 2. HR blame game and Throwing money at the problem doesn't work (Note Personal values #4, money is not listed in Professional profts)
#3,4,5,6: Career Opportunity
#7, 9, 10: Motivating environment
#8: Quality product
So, if you have not done so already, spend the 5 minutes it takes to review the Nickel Philosophy link. If you want to learn more, you can contact Jim Bracher directly through his website. The Nickel Philosophy is also published in Jim Bracher's book Integrity Matters. ISBN 978-1887089036
I addressed the root-cause and am now working on high-speed ADCs and communications again like I did from 1995-sh to 2009. I have changed jobs and now work advanced data converters in deep-submicron processes. My previous company had generously lifted me from Davis/Sacramento to the edge of the bay area and I am thankful for that.
I plan to keep up Street Smart Analog. I still plan to eventually write a book on analog design and debug, with this blog as the pre-cursor. Of course, the lack of recent posting is related to my career transition, which is now official.
The world of small component analog design including light sensors is radically different but also challenging. I have the utmost respect for the light-sensor product line and the people I left behind working on it. Those products have a lot of care and effort put into their development and should be the hottest selling sensors out there. However, I couldn't remain working on that product line due to The Nickel Philosophy. One of two things that hang's up in my cube along with the IEEE code of conduct. The sad thing here is that this transition could have been prevented.
I find the "Nickel Philosophy" from Jim Bracher and his associates at the Center for Integrity and Leadership to be a valuable tool in setting priorities. I have used this material of Jim's in Lectures at both UCD and Stanford.
Link: http://www.brachercenter.com/article_nickelphilosophy.html
The list of "effective priorities" called "The Nickel Philosophy". There are two catagories
A. Professional Profits:
#1 Customer service (how you treat your customers and your work mates; how are you treated)
#2. Quality product
#3. Career Opportunity
#4. Motivating Environment
#5. Everything else.. (not worth stressing about)
B. Personal Values
#1. Self/Significant other
#2. Family and Friends
#3. Heath and happiness
#4. Difference and dollars (how you are getting by)
#5. Everything else (not worth stressing about)
In my life at my previous employer I tried to make sure that all the people that reported into me experienced "Professional Profits". There are a multitude of reasons behind this list, its order and how it is presented, please look over the link above. If the place you work at does NOT follow the Nickel Philosophy AND there are other opportunities available, then the right thing to do is to move on, since you will eventually. What is interesting about this list is that Career Opportunity is right under quality product. It does make sense since without a motivating environment why bother about the opportunity. This list is a "person specific" view of the problem to be clear.
Today I saw a link today shared by an HR person from the previous company:
http://www.forbes.com/sites/ericjackson/2012/01/19/why-companies-are-terrible-at-selecting-retaining-and-motivating-their-talent/
Basically this article explains why people leave and is interesting to contrast with "The Nickel Philosophy".
Eric Jackson picks 10 reasons. Some of these items similar to Nickel Philosophy:
#1, 2. HR blame game and Throwing money at the problem doesn't work (Note Personal values #4, money is not listed in Professional profts)
#3,4,5,6: Career Opportunity
#7, 9, 10: Motivating environment
#8: Quality product
So, if you have not done so already, spend the 5 minutes it takes to review the Nickel Philosophy link. If you want to learn more, you can contact Jim Bracher directly through his website. The Nickel Philosophy is also published in Jim Bracher's book Integrity Matters. ISBN 978-1887089036
Wednesday, December 12, 2012
Analog test-anti-test path
Earlier in Street Smart Analog Lingo I mentioned an analog test-bus or analog test-path. These animals are excellent for debug of silicon, particularly deep-submicron where probe pads are REALLY Huge. A 2u probe-pad was no big deal back in the day but that area is really useful in geometries below 0.13u.
The test-path issue came up recently so I figure I would blog about this useful debug tool.
The Good:
DC analog signals such as currents and voltage references can be sent on/off chip helping to isolate DC bias problems. An "analog mux" is placed on the test-bus normally each block has a little mux that allows a signal to be passed from the INSIDE to a PAD on the outside of the chip. Outside of the chip the appropriate test-device or current/voltage source can be attached to the test pin. This is useful for tuning in band-gaps, bias generators and debugging low-freqency clocks or slow-speed ADCs.
High-speed (differential) signals can also be sent out an analog test-bus. These are trickier to deal with but I have seen an 800MHz test-bus employed on an 12Gbps receiver.
(ISSCC 2006 - Keyeye 12Gbps). That test-bus had a dedicated output buffer created from a thin-oxide PMOS transistor. This was a "source-follower' with the off-chip resistor being a several-K Ohm resistor. With the correct (~10V) power-supply, the circuit could be tuned to an impedance of 50 ohms to match the board trace. The poor-little transistor was biased well beyond 10 year lifetime limits however it allowed us to "tune-in" our analog DFE, NEXT and ECHO cancellers. This circuit also made a fine figure for our ISSCC paper. We achieved about 8 bit linearity with a bandwidth of near 800MHz. If you left it on too-long or raised the voltage too high the chip would blow. The eye got cleaner until it popped. Later on we included EQ on scope capture data to reduce the burn-out problem.
Medium bandwidth signals can also be sent through a mux into a front-end of a receiver. The transformer in an Ethernet chip had a dual-purpose as a balun. You could put a single-ended RF generator (with associated filter network) on the differential input side of the transformer. Then on the "chip side" you could adjust the center-tap to give whatever common-mode was required for the internal block being tested. A "leap-frog" test-path was included to send the signals to the various front-end blocks helping to debug harmonic-distortion problems, AGC ranges, low-pass filter bandwidths and ADC linearity. This path should be simulated before tape-out.
One advantage of an analog test-bus is that you can always disconnect it in a metal-rev, so reliability is not a concern, especially in the early stages of analog-front-end (AFE) bring-up.
The Bad:
I have also seen the analog test-bus cause failures. These are subtle but this is the point of street smart analog. The test-bus needs to be verified like any other circuit. Neglecting to do so can cause bad things to happen.
The ultimate sin of the "test-bus" is to reduce the performance of the circuit's primary function.
Failure #1: Some pads on chips have voltages that go "above the rail". These are called "open-drain" where an off-chip pull-up resistor or transformer is required off-chip to supply current. A common mistake is to connect a PMOS switch to the pad with body tied to the chip supply. If you take a PMOS terminal above the highest supply, a diode will turn on inside the chip and steal current with its characteristic nonlinear temperature dependent way often puzzling the layman. Also these parasitic diodes can blow. We learn in college that the PMOS body needs to be connected to the highest supply. (source-body connections also have pitfalls and are do-able, but tricky and may affect a circuit in its normal mode.) So as a general rule, unless you really have to, never us a PMOS switch, especially if you have an open-drain or a transformer. Dan Ray said "No P on the Pad". Notice my " ad", it has no P.
Failure #2: Bad neighbor behavior. What I mean by this is that several blocks normally share an analog test-bus such as a "DC" bus. There is a desire to prevent noise from coupling back in from the test-bus so often we would employ a "T" switch. This is a switch that consists of a T network with three switches. When the bus is "off", the middle switch prevents noise coupling through. When the test-bus is "on" the middle switch is off and the two outer switches connect internal node to the outside. I have seen a case where someone left out one of the switches in the T. So when the test-bus was disabled, it was pulled to ground preventing other blocks from using it. So if you have an analog test-bus, a "test-case" should include "open". I would do this by loading the test-bus with a 1Meg resistor in sims to a voltage mid-rail in simulations. You can also pull the resistor above the rail (on an open drain pin) to check for P on the pad if that is a concern.
Failure #3: Low priority verification. The first shot at that 800Mhz differential test-bus did not work all that well. We had hired an excellent consultant to design repeater to send a signal to the source-follower pad. This IP never did make the first tape-out. The focus was on tape-out and verification of the main function, but prevented debug later on forcing a quicker spin. So if you are going to put a test-bus in, you should "Do it like you mean it" and verify it too. If there are buffers they should be reviewed and plot reviewed. The test-bus methodology should be done "up front" in the design and not snuck in at the last moment, since it could ruin your floor plan. Thinking ahead and planning are always a good idea when it comes to analog chip design. You can try to substitute long hours but you'll always lose to the thinker-planner. Think tortoise and hare...
Keyeye Ref: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1696054
The test-path issue came up recently so I figure I would blog about this useful debug tool.
The Good:
DC analog signals such as currents and voltage references can be sent on/off chip helping to isolate DC bias problems. An "analog mux" is placed on the test-bus normally each block has a little mux that allows a signal to be passed from the INSIDE to a PAD on the outside of the chip. Outside of the chip the appropriate test-device or current/voltage source can be attached to the test pin. This is useful for tuning in band-gaps, bias generators and debugging low-freqency clocks or slow-speed ADCs.
High-speed (differential) signals can also be sent out an analog test-bus. These are trickier to deal with but I have seen an 800MHz test-bus employed on an 12Gbps receiver.
(ISSCC 2006 - Keyeye 12Gbps). That test-bus had a dedicated output buffer created from a thin-oxide PMOS transistor. This was a "source-follower' with the off-chip resistor being a several-K Ohm resistor. With the correct (~10V) power-supply, the circuit could be tuned to an impedance of 50 ohms to match the board trace. The poor-little transistor was biased well beyond 10 year lifetime limits however it allowed us to "tune-in" our analog DFE, NEXT and ECHO cancellers. This circuit also made a fine figure for our ISSCC paper. We achieved about 8 bit linearity with a bandwidth of near 800MHz. If you left it on too-long or raised the voltage too high the chip would blow. The eye got cleaner until it popped. Later on we included EQ on scope capture data to reduce the burn-out problem.
Medium bandwidth signals can also be sent through a mux into a front-end of a receiver. The transformer in an Ethernet chip had a dual-purpose as a balun. You could put a single-ended RF generator (with associated filter network) on the differential input side of the transformer. Then on the "chip side" you could adjust the center-tap to give whatever common-mode was required for the internal block being tested. A "leap-frog" test-path was included to send the signals to the various front-end blocks helping to debug harmonic-distortion problems, AGC ranges, low-pass filter bandwidths and ADC linearity. This path should be simulated before tape-out.
One advantage of an analog test-bus is that you can always disconnect it in a metal-rev, so reliability is not a concern, especially in the early stages of analog-front-end (AFE) bring-up.
The Bad:
I have also seen the analog test-bus cause failures. These are subtle but this is the point of street smart analog. The test-bus needs to be verified like any other circuit. Neglecting to do so can cause bad things to happen.
The ultimate sin of the "test-bus" is to reduce the performance of the circuit's primary function.
Failure #1: Some pads on chips have voltages that go "above the rail". These are called "open-drain" where an off-chip pull-up resistor or transformer is required off-chip to supply current. A common mistake is to connect a PMOS switch to the pad with body tied to the chip supply. If you take a PMOS terminal above the highest supply, a diode will turn on inside the chip and steal current with its characteristic nonlinear temperature dependent way often puzzling the layman. Also these parasitic diodes can blow. We learn in college that the PMOS body needs to be connected to the highest supply. (source-body connections also have pitfalls and are do-able, but tricky and may affect a circuit in its normal mode.) So as a general rule, unless you really have to, never us a PMOS switch, especially if you have an open-drain or a transformer. Dan Ray said "No P on the Pad". Notice my " ad", it has no P.
Failure #2: Bad neighbor behavior. What I mean by this is that several blocks normally share an analog test-bus such as a "DC" bus. There is a desire to prevent noise from coupling back in from the test-bus so often we would employ a "T" switch. This is a switch that consists of a T network with three switches. When the bus is "off", the middle switch prevents noise coupling through. When the test-bus is "on" the middle switch is off and the two outer switches connect internal node to the outside. I have seen a case where someone left out one of the switches in the T. So when the test-bus was disabled, it was pulled to ground preventing other blocks from using it. So if you have an analog test-bus, a "test-case" should include "open". I would do this by loading the test-bus with a 1Meg resistor in sims to a voltage mid-rail in simulations. You can also pull the resistor above the rail (on an open drain pin) to check for P on the pad if that is a concern.
Failure #3: Low priority verification. The first shot at that 800Mhz differential test-bus did not work all that well. We had hired an excellent consultant to design repeater to send a signal to the source-follower pad. This IP never did make the first tape-out. The focus was on tape-out and verification of the main function, but prevented debug later on forcing a quicker spin. So if you are going to put a test-bus in, you should "Do it like you mean it" and verify it too. If there are buffers they should be reviewed and plot reviewed. The test-bus methodology should be done "up front" in the design and not snuck in at the last moment, since it could ruin your floor plan. Thinking ahead and planning are always a good idea when it comes to analog chip design. You can try to substitute long hours but you'll always lose to the thinker-planner. Think tortoise and hare...
Keyeye Ref: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1696054
Sunday, December 2, 2012
Missing Teeth
With switched-capacitor circuits, one of the most critical parts of the design is the clock generator. As a friend of mine once said:
"When your switched-capacitor circuit doesn't work, check your clocks. After that, check your clocks again." (Perry Heedley-1998)
It was back in 1999 we had our first-generation gigabit SOC back in the lab. The process was 0.35u. Supply 3.3V. We had a strange problem with non-uniform sampling. When we sent the clock out the "test-bus" we saw that it had missing pulses. Missing pulses are not a good thing and the Flash ADC ENOB was terrible. Lots of tones! On the scope the clock looked like a boxer who was missing teeth. We also had supply dependence where high supply and cold spray made it worse. What was going on?
On Friday I met a new friend who had a similar story. (So sorry buddy!) This inspired me to write this blog post on this common screw-up. If I have seen one common mess-up in that the something goes wrong with a reference clock.
In these larger Ethernet chips, we distribute the clock as a differential signal. The advantage of going differential is that the signal is not affected by clock skew and the rise/fall time match perfectly (by design). If you distribute critical clocks with single-ended circuits stop reading now since you are hopeless. The differential approach gives you a uniform sensitivity to noise on the chip and in the environment (see Ali Hajimiri's wonderfully written "Low-Noise Oscillators"). Another advantage of using a differential clock, is that ideally you can send it across power-supply domains. (when things are normal)
Now if you want a good non-overlapping clock its easy to go overboard. Normally you have a "non-overlapping clock generator". Its a circuit who's job it is to make sure a set of clocks do not occur at the same time. A trade-off in those designs is the rise/fall time. If the clock coming out of the block has a fast rise and fall time, the clocks are less apt to overlap. However, this comes at a cost. The designer keeps increasing the size of the generator to make the output edges faster and faster. Eventually coming to a solution. There is a trade off between non-overlap time and Operational Transconductance Amplifier (OTA) settling. It almost always seems easier to use a big clock buffer transistors than to beef-up your amplifier bandwidth.
A huge pitfall of these "massive" clock generators is that they can generate huge amounts of noise and "ground bounce". Or as Stephen Lewis (UC Davis) would say "Making sparks". The huge clock buffer circuits create massive amounts if dI/dT. Huge current spikes with peaks upwards of close to an amp can find there way into your big clock buffer. These currents hit your package (with inductance) which translate them into huge voltage spikes.
When it comes to "noisy neighbors" on a chip, it always takes an aggressor and a receptor. In this case, I was able to debug this animal but putting the clock-generator into a schematic along with a simple package model consisting of package inductance. I then put the clock source on a different power-supply in my schematic to see what happened. I did this by hand in HSPICE since I am not the hugest fan of schematic capture. I did this hand-written test-bench in real time in the lab right next to an oscilloscope with the bad clock on it. It was me, Sailesh Rao, Jim Parker and Dave Nack all gathered around the setup. I kept tweaking the test-bench, and Q factor (4) on the bondwires until BINGO. I was able to match the waveform from the scope in HSPICE. High-five from Dr. Rao! What happened?
The ground-bounce was so big that it was measured in VOLTS. Yes, our 3.3V supply had volts of ground-bounce on it from a huge clock generator. By increasing the temperature or lowering the supply on the clock generator, we could work around the problem. This part wasn't going to sample in this state. The ground-bounce was too big from uber-big clockgen!
The main PLL and the ADC with the uber-clockgen were on different power supply pins. Analog guys like to use A BUNCH of power supplies, normally to keep noise from coupling around. However, this can sometimes backfire. When breaking up power-supplies its important to visualize the return paths of all the currents and how they will affect each-other. In this case, the PLL sent the clock to the ADC who caused so-much ground-bounce that the buffer amplifier receiving the clock in the ADC missed pulses. This happened since the amplifier only had a common-mode range of about a volt, with more than a volt of ground bounce between the supplies.
So now, hopefully everyone knows that you can make a clock-generator "too-big". A technique to finding these is to just turn-on base-layers in your layout and look for huge MOSfets. Always ask yourself why you have a big transistor, since everything in the area will know about it. Also people should be aware that more supplies are not always better.
So what is a solution?
A. NERF your clockgen - Simulate it with bondwires
B. Add on-chip bypass capacitors to prevent dI/dT from hitting the bondwire
C. Improve the common-mode range of your clock buffer.
D. Design a set of inter-supply "repeaters" with huge common-mode range
E. Use DC Blocking capacitors
We solved this one with A and B. The ADC worked much better after we fixed that. We still had more challenges but....
"When your switched-capacitor circuit doesn't work, check your clocks. After that, check your clocks again."
"When your switched-capacitor circuit doesn't work, check your clocks. After that, check your clocks again." (Perry Heedley-1998)
It was back in 1999 we had our first-generation gigabit SOC back in the lab. The process was 0.35u. Supply 3.3V. We had a strange problem with non-uniform sampling. When we sent the clock out the "test-bus" we saw that it had missing pulses. Missing pulses are not a good thing and the Flash ADC ENOB was terrible. Lots of tones! On the scope the clock looked like a boxer who was missing teeth. We also had supply dependence where high supply and cold spray made it worse. What was going on?
On Friday I met a new friend who had a similar story. (So sorry buddy!) This inspired me to write this blog post on this common screw-up. If I have seen one common mess-up in that the something goes wrong with a reference clock.
In these larger Ethernet chips, we distribute the clock as a differential signal. The advantage of going differential is that the signal is not affected by clock skew and the rise/fall time match perfectly (by design). If you distribute critical clocks with single-ended circuits stop reading now since you are hopeless. The differential approach gives you a uniform sensitivity to noise on the chip and in the environment (see Ali Hajimiri's wonderfully written "Low-Noise Oscillators"). Another advantage of using a differential clock, is that ideally you can send it across power-supply domains. (when things are normal)
Now if you want a good non-overlapping clock its easy to go overboard. Normally you have a "non-overlapping clock generator". Its a circuit who's job it is to make sure a set of clocks do not occur at the same time. A trade-off in those designs is the rise/fall time. If the clock coming out of the block has a fast rise and fall time, the clocks are less apt to overlap. However, this comes at a cost. The designer keeps increasing the size of the generator to make the output edges faster and faster. Eventually coming to a solution. There is a trade off between non-overlap time and Operational Transconductance Amplifier (OTA) settling. It almost always seems easier to use a big clock buffer transistors than to beef-up your amplifier bandwidth.
A huge pitfall of these "massive" clock generators is that they can generate huge amounts of noise and "ground bounce". Or as Stephen Lewis (UC Davis) would say "Making sparks". The huge clock buffer circuits create massive amounts if dI/dT. Huge current spikes with peaks upwards of close to an amp can find there way into your big clock buffer. These currents hit your package (with inductance) which translate them into huge voltage spikes.
When it comes to "noisy neighbors" on a chip, it always takes an aggressor and a receptor. In this case, I was able to debug this animal but putting the clock-generator into a schematic along with a simple package model consisting of package inductance. I then put the clock source on a different power-supply in my schematic to see what happened. I did this by hand in HSPICE since I am not the hugest fan of schematic capture. I did this hand-written test-bench in real time in the lab right next to an oscilloscope with the bad clock on it. It was me, Sailesh Rao, Jim Parker and Dave Nack all gathered around the setup. I kept tweaking the test-bench, and Q factor (4) on the bondwires until BINGO. I was able to match the waveform from the scope in HSPICE. High-five from Dr. Rao! What happened?
The ground-bounce was so big that it was measured in VOLTS. Yes, our 3.3V supply had volts of ground-bounce on it from a huge clock generator. By increasing the temperature or lowering the supply on the clock generator, we could work around the problem. This part wasn't going to sample in this state. The ground-bounce was too big from uber-big clockgen!
The main PLL and the ADC with the uber-clockgen were on different power supply pins. Analog guys like to use A BUNCH of power supplies, normally to keep noise from coupling around. However, this can sometimes backfire. When breaking up power-supplies its important to visualize the return paths of all the currents and how they will affect each-other. In this case, the PLL sent the clock to the ADC who caused so-much ground-bounce that the buffer amplifier receiving the clock in the ADC missed pulses. This happened since the amplifier only had a common-mode range of about a volt, with more than a volt of ground bounce between the supplies.
So now, hopefully everyone knows that you can make a clock-generator "too-big". A technique to finding these is to just turn-on base-layers in your layout and look for huge MOSfets. Always ask yourself why you have a big transistor, since everything in the area will know about it. Also people should be aware that more supplies are not always better.
So what is a solution?
A. NERF your clockgen - Simulate it with bondwires
B. Add on-chip bypass capacitors to prevent dI/dT from hitting the bondwire
C. Improve the common-mode range of your clock buffer.
D. Design a set of inter-supply "repeaters" with huge common-mode range
E. Use DC Blocking capacitors
We solved this one with A and B. The ADC worked much better after we fixed that. We still had more challenges but....
"When your switched-capacitor circuit doesn't work, check your clocks. After that, check your clocks again."
Subscribe to:
Posts (Atom)