Saturday, June 24, 2017

"Hello, World!" A Short Recap of Thoughts on Industry...

Long time no chat 😜

Surprisingly, I am *not* dead (although did I come close during one particularly bad China trip). A lot has happened since undergrad - got my masters, industry-ed for ~3 years, shipped millions, went blonde, etc. Regretfully (or maybe luckily hahaha) most of that can't be shared due to friendly Silicon Valley NDAs :)

As a sort of time capsule exercise, here are a couple of personal realizations amassed thus far.

  1. Life expectancy in the US is about 75-80 years. 
    • Given that I'm in my mid to late twenties while writing this, I have about ~50 years of life left. In which case, 5 year increments are about 10% of my remaining life. 
  2. Industry is almost entirely dominated by the manufacturing machine. 
    • The manufacturing machine feeds on optimization. This in turns means low-risk, high volume, high reliability, fast turnaround. However, this also means that often enough:
      • Priorities are placed on "what" and "how much", less so on "why" and "how come". 
      • Novelly creative designs aren't highly valued (since it may be more risky, slower to manufacture, harder to plan out/around, etc). New ideas are often met with skepticism, but this is understandable. 
        • Nonetheless, make sure you've the right spec/figure of merit priority before heading down any single execution path. Challenge yourself - always think of at least 3 different implementations before settling with any single one. Sometimes your first idea isn't the best.
        • Don't become enamored with one implementation style. "If all you have is a hammer, everything looks like a nail." 
      • The adage "all models are wrong, some are useful" is forever true. People often (accidentally) mislead with data. Always keep a watchful eye out... Double check everyone's data / model / assumptions (including your own!!!) 
      • Don't assume that people understand what you're saying (and don't assume you understand what they mean!). Give your instructions / suggestions / comments, and then ask the person to reiterate what *they think you meant*. Do the same for when you're given task! Most communication problems stem from small misunderstandings.
      • Budget enough time for rigorous analysis beforehand. Problems will haunt you if you don't. 
        • While I understand that *certain* product cycles may not have enough time for full simulations/mock-ups, this "we don't engineer, we make a ton of configs at the build" technique only works for companies with more money than time... 
        • Also the whole "million different configs" method forever involves drama. Limited build quantities means everyone has to share. The worst result is people not getting the right data (either too little or too messy). Other stressful consequences range from overly long builds to overly chaotic build matrices - all with a huge dollop of engineering drama. (Whose units can we use for this config, when are they going to be inputed, who gets the final allocation, is this going to disrupt Reliability's quantities, etc.)
      • No one is above Murphy's Law. 
      • You'll almost always end up regretting shortcuts. The worst shortcuts are the forgotten ones. Those are a nightmare to debug. 
      • People like to say root-cause matters, but often completely forget its importance once there's a tight enough tourniquet around the wound (note: horrible mindset to adopt). 
        • As matter of personal principle, *always* nip failure modes in the bud. What might be a 3-off or 5-off in the first build rapidly grows to become a fail rate of 10%, 30%, 50%, etc in subsequent builds. Early problems often have relatively easy solutions - had you implemented the fix a few builds ago! Never skip your debug/analysis chores. 
        • Occam's razor is sharp. Before going after some crazy, complicated theory, always cover all your basics. Check the obvious things you assume *must* be working. Systems can be majorly screwed from the simplest things. 
        • Divide and conquer. Split your debug tactics logically. Try to check SW then HW then branch down into a decision tree until you know if the issue is either completely SW or completely HW (or somehow tangled in both, although that's extremely rare). Once you've understanding of the true root-cause, *then* brainstorm solutions. Always take the SW fix if you can (then you can avoid waiting for another expensive build, reliability testing, etc)
      • Large scale debug typically consists of data correlations, odd distributions, and borderline rude emails asking why distributions look so bad. 
        • *Always* do the correlation study first. It's cheap (no need for physical hardware, can be done anywhere at any time), relatively fast, and can give you a lot of insight. When starting, just plot everything. True, correlation doesn't mean causation, but sometimes bizarre things end up correlating in ways that do make sense (ex: a high PMU temp correlating to large decreases in battery SOC). Go overboard first, then fine tune. 
        • A few choice CDF plots can save your product.  
      • Your work must be useful to the company/product (this should be self-evident). The only way to get projects you want is to sell them in terms of company/product benefit. This will place artificial limits on what you do with your time. 
      • You wear a lot of hats. Sometimes you'll have to play program manager, test engineer, build lead, statistician, salesman, psychiatric counselor, and lastly electrical engineer all in one day. 
      • Some people genuinely love all of this. Although I may never understand why/how they do, I've come to accept that people exist on axes orthogonal to my own.
  3. Visceral technology consists of improvements in the following: 1) Energy, 2) Time, 3) Space, 4) Mind:Mind Interface, 5) Mind:Machine Interface.
    • If your technology (*cough cough consumer electronic*) doesn't either 1) improve one of those 5 significantly, or else 2) improve at least two of those decently, then it's not going to make much of an impact. At best, it'll be regarded as some weird Silicon Valley toy. 
  4. Having all the money in the world doesn't matter if you don't have time to spend with your friends and family. 
  5. Understand your personal motivations and agenda. Remember, you are not an open-loop system! If you can re-identify your personal motivations and agenda again, you can always negative feedback back. Also, just as the input signal can vary with time, so can you! Don't beat yourself up if your goals have changed/evolved since years and years ago. Just be the very best closed-loop system you can! 
Anyway, I'm planning to blog again because I miss the virtual ether of the internet. 

See you all soon! 😊

Monday, December 31, 2012

I'm a Beardy-Weirdy?

S'up guys,

This was my year of being old and cranky (senior fall), so I decided to become a beardy-weirdy (analog-esque EE). For some reason, I always associated analog people with old engineers probably because I once saw a picture of Bob Pease and assumed all analog-ers looked like this.

"My favorite programming language is ... solder"  
Unfortunately, this gave me the impression that if I were to become an analog EE, all the people in my life would be sarcastic, scraggy Santa Clauses...(someone is going to kill me for this comment so here's my pre-emptive apology). While I'm sure Bob Pease was a creative man and had a dry sense of humor, you could imagine how this could put off a naive, girly-as-hell EE. In no way am I saying Bob Pease wasn't freaking baller nor am I saying there are no female and/or young analogs. Just not many...

(Btws, this was before I realized that Prof Roberge used to look like James Bond back in the day, so clearly there was evidence of well-dressed analog people)

Regardless, I decided to brave the challenge, so I signed myself up for MIT's 6.301 (Solid State Circuits). Glad I did, because that class was awesome!

First off, my main gripe with MIT undergraduate classes is that they aren't very "design-y". 6.301 is a grad class, but I wish more of my undergrad had been like it. For the most part, I felt like I was always learning fancier and fancier math, but never how to create with it. , In my opinion, a lot of the 6-1 (EE) curriculum consists of churning math out. It's basically the opposite of creative. You learn a protocol, you apply that protocol to constrained examples in homework and tests, then you're done. What I hate about this is that you're not given an opportunity to be particularly creative. You don't jump and apply concepts from one field to another (well I sort of did in 6.021 (BioEE) - fun class), but for the most part, you don't really even apply it outside of that week's lecture. This is why I've built things outside of class, because I couldn't stand this system. I've always thought the best way to prove myself that I've learned something is to use it. I'm afraid most undergraduates aren't taught to be innovative. That scares me! We might graduate more and more engineers, but we'll only make limited progress if we can't be creative. People must to learn to imagine what does not yet exist...although I admit it's a daunting task.

6.301 is quite different! Instead, you learn a bunch of design ideas for why certain topologies are good/bad, what are trade-offs between them, etc. Sometimes we would go through a specific design in a series of lectures and see how a designer might conclude with that circuit through various estimations/intuition. There are also these excellent course notes by Kent Lundberg which are super awesome. During the course, you get to run wild and design three circuits from scratch.

Anyway, long rant short, I wanted to summarize the things I designed for 6.301. I really loved this class :D

Lab 1:

Oh man, my first circuit with BJTs that didn't catch on fire! Previously, anything I ever built with BJTs somehow, at least once, caught on fire. Don't ask why. Too embarrassing :X I did always fix them though. This is also my least elegant circuit probably because it was my first. Everyone's gotta start out somewhere...

I'm derpy.

The goal of this lab was to make a 3-stage amplifier that met these specs:

We were learning about common-emitter amplifiers, and so the smart thing to do was put caps on the emitters to make the AC voltage gains super high. It's still nice to have emitter resistors to set Ic, and, more subtlety, set a DC gain. At DC, your caps should theoretically be open, so then you have common-emitters with degeneration. So, if your resistor divider sucked or some weird stuff, your DC voltage would be amplified by much less than your AC. Yay! This knowledge really isn't terribly useful in this circuit because your DC is pretty set by that voltage divider and nothing in this 3-stage should be seriously gross because you only go to ~150 kHz. 

I made my circuit and it met spec in spice, and I was super happy until this really weird thing happened. 

You'll notice in the spice sim that the upper 3dB point is about ~165 kHz. Er, somehow when I made it on my breadboard, my upper 3dB was at 1.2 MHz.

Confusing to say the least.

Another kid had this problem too and the TAs said this did happen although they didn't figure out why. That kid was also a total jerk! He condescendingly asked me why I was even in 6.301 "to make clothes out of transistors?"


Just because a female EE dresses well doesn't mean that's all she does. Man, that almost made me fear all hopeful analogs were morons...

Anyway, back to the point, what actually occurred was that my circuit was resonating. One way to check is by sending a DC signal through your amplifier and seeing if you get some oscillation on the output. My resonating problem was due to this attenuator which we had to build for our signal generators because they couldn't put out a low enough voltage. 

Note: we have the 50 Ohms to make a nice, nonreflecting transmission line when your signal generator is set to 50 Ohm output. However, we weren't going fast enough in this lab for it to really matter. Nice info to know though (for say, an internship maybe). 

I had accidentally set the 1k going to my circuit (the rightmost one) as 10k. This didn't change my overall gain, but it did make my circuit resonate just enough to make my upper dB look like it was 1.2 MHz. Wonky stuff. 

Lab 2:

This was definitely a more challenging one. We had to make a wide-band amplifier that met these specs:

Because I wanted to be hardcore, I wanted to use less than 6 transistors and use less power. My final product ended up with 5 NPNs (originally designed for 4 NPNs but I ran out of time to bootstrap out the breadboard capacitances).

I wanted to cry because my first version had 4 NPNs :( My final (this one) had 5. 
To begin, because of the 3 MHz, I knew it had to be fast. So what are fast? Well cascodes! Hence, I knew I needed at least 2 cascodes to get that gain (you can, I think, do it in one but you consume more power. You could also do a super decked-out tall cascode). Emitter-followers are also fast, so I kept that as backup. 

The first thing I thought of when I encountered this lab was the obvious. Now, you've probably just read my thoughts on "churning out engineering", so I didn't want to do the cookie-cutter method. The most obvious design to me was a +15 to -15 rail with 6 BJTs divided like my above circuit except with an additional emitter-follower. You could put this extra emitter-follower on the output so you never have to worry about your scope capacitance and output resistance being a low-pass filter on your overall signal. You could also put this extra emitter-follower at the beginning before your first cascode to reduce that open time constant. However this, to me, seemed power-hungry and since we only needed 1V peak to peak, I knew you could run this whole thing on 5V to GND. Also I didn't think it needed that many transistors because I thought without some emitter followers, you might still be fast enough. Here was my thought process:  
  • +/-15V rails means 6x the power of one 5V to GND. We need 1 Vpp, can probably use 5V.
  • Emitter-Follower at the beginning probably not needed because cascode is fast enough on its own. 
  • Might not need emitter-follower buffer in the middle either unless the second cascode's input resistance drags the whole thing down. 
  • Emitter-Follower at the end of the second cascode might not be needed if I keep in mind our upper 3 dB is at 3 MHz. Need to make sure time constant of 10pF * output resistance cuts it for 3 MHz (hence, my max output resistance must be < 5k).
  • Since I don't know how to do feedback circuits yet, why not do the whole different DC gain from AC gain so I don't have weird stuff. Let's put caps across some of my resistors in my cascode to set a higher AC gain than DC. Note: these caps should always go to ground because switching power-supplies are noisy...
With these things in mind, I drafted up my first lab 2,

I'm so baller because I have 4 transistors! 

Boy does that just graze 3 MHz...

Er, my first draft met sim...barely. So, with a doubtful heart, I made it on a breadboard. Its bandwidth (without bootstrapping) never went more than 2.2 MHz which was sad since it was designed for a little over 3 MHz...

Now normally, I probably would've brought out the big guns and bootstrapped that circuit to death, but this was hell week at MIT, so the physical circuit was due in less than 6 yeah....

I then went back and thought of the emitter-followers I removed. I realized that because I was hitting the limit of my gain-bandwidth product, I had to separate my gains of my cascodes more (because the second cascode loaded down the first). So, I threw a quick emitter-follower in the middle and used it as a voltage buffer and voila. Yay magic!

Again, my final design from before.
That magical feeling of meeting spec because your sim spec is way bigger!
P.S. it also took 5mW power. SO PROUD :D

Lab 3/Final Design Project:

For our final project we had to design a transimpedance amplifier (which is NOT an op amp). The cool thing about transimpedance amps is that their gain and bandwidth are decoupled! You can set them individually, which you can't in an op amp! Also they have no slew rate limit because you supply your own current input! Hence, they are super hella-fast. However, because they're low-impedance input & high-impedance output, you can't do nice things like integrators, differentiators, etc. 

You can't have everything in life. Boo. 

For the circuit, we were pretty much given an outline beforehand. 

Specs were:

Now the main deal about the design project was that you could either build it or write a project. I was obviously going to go for build (hence a nice thing about this post is that I remember what I did) :P

The whole diamond circuit buffer input we were given, so we couldn't change that, and we were told to bias it at 1mA. The main things we could pick were the mirrors and our output buffer. 

There were a few subtle things about this amplifier. First off, normal current mirrors don't have a high enough output impedance to provide a 200k node at DC. You have to use something else, so I picked Wilson mirrors. There were weird things about them though... 

Final Transimpedance Amp

First off, if you used a modified Wilson on the bottom NPN current mirror, it brought the open loop DC output bias from 13V to 3V. I think this had to do with transistor matching because the PNPs and NPNs were pretty unbalanced in not only the 301 models, but also ltspice's default ones (I sim'ed them in both because I got confused over some of these irregularities). A better way to get rid of these mirror discrepancies is to use emitter degeneration (which I didn't) to match them better (because closed loop testing hides your sins). 

Also, the output resistances of the Wilson mirrors were beta*R_out. Normally, these should be (beta*R_out)/2. I still am not quite sure why that occurred. I'm guessing that because they attach onto the original diamond, the left branches of the mirrors are technically stacks of 2 or 3 transistors, so the overall output of the mirrors are beta*R_out. This is just my intuitive guess though... 

Another thing I did was make the output buffer not a kosher diamond circuit. The obvious thing (since you were already given a diamond to begin with) is to stick another diamond at the end since it is a +1 buffer. However, the output buffer circuit I used consumes less power, forces Q9 and Q10 to never saturate, and bootstraps those transistors as well. A word of caution though - you can't use the output buffer as a replacement for the input diamond circuit. This is because the input and output are tied together (hence you get some bootstrapping and V_ce = ~.6V). When you use a buffer as the input for your transimpedance amp, you take the normal "output" and the normal "input" and use them both as inputs so you can get at least one low-impedance node. 

Now, the problem is that because your "input" and "output" are tied in the last stage's buffer, I feel that you're going to get weird, coupled problems if you use that buffer topology as an input. It's perfectly fine as an output though, because you leave its "output" alone. When you couple them together, you might get a weird V_be offset from +Input to -Input as well. Since this would be placed in the very inputs of your overall amplifier, even in closed loop, that offset would be amplified through the whole system and show up on your output. Gross :( 

Also, one last thing about the transimpedance amp is that I could've used better current sources. Every .6V you put across one V_be leg for a mirror, the other leg outputs 10x as much current. Hence you can save power by having one leg be 0.1mA and the other be 1mA. I did this with resistors, but you could do it another way. You also don't need 1mA to bias your buffers (you can cheat power with less and it'll still be fine). 

Here's my super cute hipstergram of my transimpedance amp :P

Analog Hipster

I deadbugged the main "compensation"-esque capacitor from the mirrors to the output buffer to maximize my bandwidth. I also used fingernail polish to paint my PNPs (pink) and NPNs (blue) so I wouldn't go insane! I even put the numbers of my transistors from my spice model so I could easily debug if needed, but luckily enough, it worked the first time :D YAAAAAAAAAAAAAAY



Well, that document's this year's transition into beardy-weirdiness. I feel like this is sort of an abrupt ending, but oh well. Hopefully I'll have another long rant to give you all next semester.