Fun fact about me. Often times, to try and find a superior yet simple and elegant solution to a problem, I spend more time searching than doing. The end result is usually that the time I spent searching is less than or equal to the time I could have spent doing and subsequently finishing the original task.
While I do believe that to solve a problem correctly is to grok the problem in its entirety, sometimes the over thinking gets a little ridiculous. Even worse, this time, it's about a subject that is a complete PITA to me ... computer programming.
So, now you all get the background story (lucky you!) ... I'll try to keep it as non-geek and easy-to-read for the layman as possible. I have a task to compile a model of an active device using an industry standard mechanism. So what do you think about when I say the word model ... a train circling around a Christmas tree, a 1968 Ford Mustang die cast, a World War II fighter plane made of balsa, or Heidi Klum? Personally I think about Heidi ... um, I mean my wife ... but that's sadly not what a device model is. To think about it simply, a device model allows someone to know how the device is going to work without actually having the physical device. It's like watching an video of someone skydiving, even if you haven't been skydiving before, after watching the video, you probably know about what to expect ... except for the crapping your pants feeling right before you jump out of the plane.
One question that might come to your mind is how you make the model represent the device accurately? Well, to answer that, you can do a few things:
- You can get a PhD in modeling and device physics from a few of the heavy hitters
- Read decade's worth of books and white papers covering the caveats to the boarder topic
- Lick your right thumb, close your left eye, point your right hand at the screen in a 'thumbs-up' motion, scrunch your lips, and wiggle your thumb from side-to-side ever so slightly while saying "That's about right..."
In all seriousness, leave this one to the pros. But I will tell you that you need to understand how the device works before making something else work 'just like it'. This means, testing, data analysis, data management ... and lots of it!
What compounds my specific problem is one that plagues pretty much everyone that has to do this type of task from time-to-time ... data formatting. It seems that I have been fire fighting these types of problems ever since I started my career in engineering. While other engineers would manually edit all the data to fit the mold, I am a 'cursed' engineer that also can program ... meaning, I find that 'manual solution' very stupid! Besides, with over 1000 lines per data set, I don't want to modify them all by hand ... that would be stupid, boring, and take forever! Really, I did a rough estimate and it would take me about a 40 hour week to do just what I have right now let alone what I obtain next week, the week after, etc.
Off to the reference books I go. Since I am most comfortable programming
Perl, I head to the
Camel and
CPAN for some inspiration, but recently I have been let down by my go-to-language. While I find Perl very easy to write, I find it less easy to read, harder to pick-up again after a few days, and nearly impossible to create a robust system I would want to maintain and let others use. In a nutshell, it's good for smallish-medium sized sloppy hacks that you write and forget all in the same day. While this can encapsulate 70% of most scripting work, the other 30% requires something a bit more fancy ... something that doesn't look like a steeping pile of dog crap next time you crack open the hood. I have been steadily boning-up on
Python to fit that niche for me and I'm hoping to bring that into prime-time for this project.
Python is actually part of the same milieu of programming languages as
Perl. They are both dynamic scripting languages with a strongly typed syntax (although this has been debated into exhaustion all over the internets); they just go about it with a different philosophy. From a pseudo-outsider, that philosophy makes all the difference between maintainable projects and hacked-garbage that people forget about. While I'm not knocking
Perl for its merits like the
TMTOWTDI approach (There's More Than One Way To Do It), superior quick searching a replacing via regular expressions, and the HUGE extensible code archive in the
Comprehensive Perl Archive Network (CPAN), it's just not suitable for large scale work unless you're a
Perl Monk that lives and breathes the stuff everyday of your existence. I'm hoping that the object oriented orthogonal language structure, and Pythonist way of programming brings a level of organization that would otherwise be analogues to
Wild Thing.
So, without a Python Zen Master in my midst, I ride alone. Armed with
Learning Python,
Programming Python,
Komodo, and
RegexBuddy ... I will spend far too much of my free time doing something for work ;(.
-Conte
For undergrad work, the texts tend to use NPN as a learning vehicle. IMHO, this is probably because as ancient_nerd said, negative voltages can be confusing and counter-intuitive. Also, there is not enough time to go over every little thing in an undergrad EE track. The courses you take in undergrad should just supply you with the understanding to interpret new device level interactions when you encounter them.
For a clearer understanding of design application of different devices advanced graduate level courses (VLSI, RFCMOS, BiCMOS, Active Microwave Design (GaAs, InP, InGaP, GaN), Mixed signal design, etc.) and/or on-the-job training are often necessary. Each of these technologies will offer their own way of answering a design problem, and will lead to different circuit topographies.