This is part 3 of 4 in a series about ESC Chicago and the Sensors Expo and Conference. See previous posts about Day 1 and Day 2.

I imagine if a doctor was diagnosing the medical condition of the embedded community, he would walk into the tiny exam room, take one look at the embedded community sitting there in its socks and underwear on the crinkly disposable exam table cover and say:

“Yup, still fragmented.”

What do I mean by this? It means that even with my posturing about the need for community AND my lack of expertise in the topic, there are some undeniable rifts in the embedded community. And they will always be there. Why?

1. Too many vendors with their own pieces of silicon
   • Guess what? Companies like making money! Amazing, right? I can name at least 5 monstrous companies that produce independent silicon chips, almost always with similar cores that rhyme with “schlARM”. They have their niche areas and peripherals that are used in that segment; examples areas that a vendor might try to target are motor control, display processing, low cost, low power or RF. But in the end, the very things that distinguish them from their competitors and therefore allow them make money, also drives the community apart.
2. Too many closed doors
   • Another problem on the vendor side can be the amount of information provided to the people working on their chips. Without open access to the information, users are forced into the “camps” of the vendors in order to access features buried within the silicon. Less mobility between chips means more fragmentation.
3. Too much software
   • Well what about abstraction? For those out there that are more on the analog side of things, abstraction is writing code that isn’t controlling something directly. Think about it like you’re a teacher. You care a lot about turning the lights off in your classroom and want to teach your kids about why it’s important in order to save energy. In a non-abstracted case, you would tell each of the kids to turn the lights off when it’s their turn. Perhaps Wednesday it’s Johnny and Thursday it’s Susie. So you tell them directly. Abstraction in the simplest sense would be assigning Bobby to remember whose turn it is each day of the week. That way, you only have to tell Bobby to have someone turn off the lights; it’s the same every time. Bringing it back to processors and the embedded community, if things were abstracted, you could always tell “Bobby” to do the same thing and he would have close to the same response each time. Well there is such a thing that even the layman such as me is familiar with: operating systems. But this isn’t like the PC world where the choices have been culled down to a select two or three. There are embedded versions of larger OSes (think Win CE or Embedded Linux) and RTOS (Real Time Operating Systems) which are an even lighter version of their half cousins named previously. Beyond that there are superloops and other small implementations. The point is, there are a lo00000t of choices for software for a looooot  of different processors. It’s fragmented. But why all the trouble? Why do we need so many choices?
4. Too many market segments
   • It’s true. That’s why embedded has been growing steadily for the past 20 years and will likely continue to keep growing. There are a lot of  different needs! I guarantee you that engineers working on high-reliability industrial controls don’t care that much about Android. Sure, it could work, but it’s a new OS with lots of potential bugs and doesn’t really fit the needs. Similarly, handset makers don’t want to use reliable code from 10 years ago because all the reliability in the world doesn’t make a flashy new interface for mobile, web-enabled handsets. Chip vendors pick and choose to play to specific segments, as do the software vendors, creating hundreds of potential combinations; it’s much more likely that whatever current developers are working on though is a much smaller combinatorial subset. And so the fragmentation continues.

I know that analog is my niche and that there are some very compelling cases for using it in different areas of electronics. But I’m not stupid; there was a reason I took interest in the embedded space and why you should do the same. Everyone will continue to expect more from their devices, whether scientific, consumer or somewhere in between; if you’re on the internet reading this post, you’re likely used to the benefits of Moore’s Law and will continue to be.

What I’m trying to say is that there is value in learning about embedded systems; learning about some component of embedded computing is better than ignoring it. As software continues ascending into further levels of abstraction (think Python instead of C), there will be fewer people around that know how to reach down into silicon and flip a bit. Knowing how to do so not only will help you in your day to day tasks, but could make you a very employable engineer/programmer.

And who knows, perhaps embedded design will be the next black magic, much like analog is considered today!

Wow.

What a whirlwind day. I started at 7:30 am and I ended at 10:30 pm, my mind still reeling. I was talking Beagle Boards and Agile processes in the morning and discussing the media (with the media) and visiting hackerspaces in the evening. But the best part about it? I felt like there were a lot of people around me that cared about similar stuff to what I do.

I am lucky enough to work with some of these people as well. But the nerd population in Cleveland isn’t at the critical mass that occurs at conferences nor at hackerspaces. So yesterday was a great opportunity to converse on some of the topics I love with people who were interested to hear it (in person of course, I realize there are many great people who “listen” to me on this site…thanks!).

The theme I kept finding throughout the day (or perhaps was seeking), was figuring out where the communities are and why hardware engineers (or even embedded engineers) don’t seem to congregate in one place. This started in the morning talking to James Grenning, a consultant and coach on Agile methodologies; I got talking to him and found that many of the same issues I’ve seen in trying to find analog communities, he has also seen in the embedded community. “Where are they?” we ask. “Why doesn’t there seem to be as much involvement online from the electronics community?”. James specializes in bringing Agile to the embedded community; easy to find people to speak with about the Agile part, less so for the embedded folks.

Towards the end of the day, I had the opportunity to talk to the folks at Element 14, a new engineering community site. I had heard about them earlier in the day; they were on the conference floor giving away iPads and the usual conference swag.  How does a “community” site have the money to attend a conference though? I later found out that they are a subsidiary of Premier Farnell, one of the top 10 electronics components distributors and recent acquirers of the EAGLE CAD program. As of right now, I’m underwhelmed with the site itself (NI uses the same interface and it’s not all that friendly to the eye nor the user), but not necessarily the content. It seems to have some involvement right now, but not the levels that I really desire (I’m hard to please!); I do like that they have qualified “experts” on hand, but haven’t taken a good enough look at them yet to judge how “expert” they might be (assuming I could even tell something like that). I will keep an eye on Element 14 though, because of one of their innovative programs: linking manufacturers to customers. They offer beta services, as in finding and requesting feedback from users on a range of products. In terms of value a site can have for both the user and the sponsors, I believe this is a strong one.

Next I got to meet Karen Field, the head of the new EETimes community, EELife. While this site hasn’t been released yet, the article I saw on it looked like a fancy implementation of a location to share info with other engineers. In fact, it may have been a little too fancy–the release of the site was pushed out from its proposed date. Still, I’m hopeful that the site could actually bring people together. EETimes has a great following in print and online; if there’s one place that people might think to go to first, EETimes might have the name recognition to do it.

Here’s the thought that keeps irking me though: the corporate world isn’t great at “social”. It doesn’t help that engineers aren’t quite social creatures by nature. Sure, some companies use social media to their advantage, but a lot more are using it wrong.

I got a chance to talk to Jason Kridner about why this might be. Jason is one of the many passionate members behind the Beagle Board group, a high powered open-source hardware board based on the TI OMAP processor (though Jason explained that the Beagle Board is a separate entity in every way from TI). When I asked him why communities such as the Beagle Board developers come together, he stated it simply and succinctly: “They unite behind a common purpose”. In the case of the Beagle Board, it’s about having a high power processor on an open platform (possibly contrasted with a slightly simpler Arduino board using an AVR processor, also on an open platform). And the community shows; there are many open projects you can pull down from the GIT tree and start immediately on your Beagle Board. The ones that excite me most are the DIYdrone types of projects.

At the meet and greet later in the evening, I started talking with some conference attendees that also happened to be members of the local hackerspace. They invited me to attend one of their weekly meetings at their location. The Pumping Station 1 (PS1) hackerspace/makerspace has been around for about 2 years now and is one of the only in Chicago as of now (more are forming). It was great seeing this area of shared tools, DIY projects and a general atmosphere of collaboration, for no reason more than these people wanted to make stuff in their spare time. And one of the things I found most interesting is that many of the projects going on at the space were embedded projects! The desire to have things talk wireless almost demands that you start to delve into low level code and be able to get your device talking to another device. So while I came to learn about the broad range of sensors and embedded devices this week, I ended up finding the lower-end (in terms of system complexity) but used for unique and intricate implementations (they had built their own MakerBot to CNC parts right there in the lab…amazing!).

So what was the conclusion to my small quest for finding community among the different factions of the electronics industry? There isn’t one general location or place to gather. And possibly for good reason. It’s more like a democratic republic in that way, where members get to vote with their feet. Say a platform really starts to bog down and no one is developing on it anymore. People aren’t tied to it because the “community” is locked in; instead they just pick up and move platforms. “Don’t like the PIC anymore? Switch to an OMAP! OMAP too expensive? Switch to an AVR!” So perhaps the real need is instead an active listing of where to find all these different communities, in whatever form they take; message boards, blogs, video tutorials, anything and everything–as long as the list stays current, it will be valuable. In fact it would be much more valuable than trying to pull in every single person into one platform.

I didn’t come to these two conferences for this purpose. I could have looked for it at home while browsing the web (I’ve done that before too). But in the midst of walking among many smart people and many products made by other smart people I’ve collected hints. Where to look and who to talk to in order to find the most people interested in technology, in whatever form or level of complexity it may take.

As more circuits get pushed into SoC (Systems on a Chip), the software that designs them becomes more and more important. Well, it’s been important for a while now. Important enough to be a multi-billion dollar industry. Biiiiig money.

Harry Gries is an EDA consultant with over 20 years in the electronics industry in various roles. He now consults for different companies and also writes a blog about his experience called “Harry…The ASIC Guy”. I love hearing about the different pieces of the electronics food chain and Harry was nice enough to take some time to talk to me about his work. Let’s see what he had to say…

CG: Could you please explain your educational and professional background and how you got to where you are today?

Harry The ASIC Guy (HTAG): My education began when I was raised by wolves in the Northern Territory of Manitoba. That prepared me well for a stint at MIT and USC, after which I was abducted by aliens for a fortnight. I then spent 7 years as a digital designer at TRW, 14 years at Synopsys as an AE, consultant, consulting and program manager. Synopsys and I parted ways and I have been doing independent consulting for 3 years now. A good friend of mine tricked me into writing a blog, so now I’m stuck doing that as well.

CG: What are some of the large changes you see from industry to industry? How does company culture vary from sector to sector?

HTAG: Let’s start with EDA, which did not really exist when the aliens dropped me off in 1985. There were a few companies who did polygon pushing tools and workstations and circuit complexity was in the 1000s of gates. Most large semiconductor companies had their own fabs and their own tools. Gate arrays and standard cell design was just getting started, but you had to use the vendor’s tools. Now, of course, almost all design tools are made by “EDA companies”.

As far as the differences between industries and sectors, I’m not sure that is such a big difference culturally. The company culture is set from the top. If you have Aart DeGeus as your founder, then you have a very technology focused culture. If you have Gerry Hsu (former Avant! CEO), then you have a culture of “win at all costs”.

CG: How hard was it for you to jump from being a designer to being in EDA? What kinds of skills would someone looking to get into the industry need?

HTAG: The biggest difference is clearly the “soft skills” of how to deal with people, especially customers, and understanding the sales process. For me it was a pretty easy transition because I had some aptitude and I really had a passion for evangelizing the technology and helping others. If someone wanted to make that change, they would benefit from training and practice on communicating effectively, dealing with difficult people, presentation skills, influence skills, etc.

CG: With regards to the EDA industry, how much further ahead of the curve does the software end up being? For instance, is EDA working on software necessary to define the 13 nm node currently?

HTAG: As you know, the industry is never at a single point. Rather, there is a spectrum of design nodes being used with some small percentage at the most advanced nodes. Most EDA tools are being developed to address these new nodes, often in partnership with the semiconductor manufacturers developing the process node or the semiconductor designers planning to use them. The big EDA companies are really the only ones, for the most part, that have the resources to do this joint development. Whatever is the newest node being developed, some EDA company is probably involved.

CG: You have written about the nature of the industry and how there being few players affecting the nature of the system. What kinds of limitations do you see in the industry due to the economies of scale (TSMC dominance, for instance)?

HTAG: Consolidation is a fact in any industry and a good thing in EDA. Think of it as natural selection whereby the good ideas get gobbled up and live on with more funding (and the innovators are rewarded); the bad ideas die out. Most small EDA companies would want to be bought out as their “exit”. At the same time, there are some “lifestyle companies” also in EDA where the founders are happy just making a good living developing their tools and selling them without having to “sell out” to a larger company. For all these small companies, the cost of sales is a key factor because they cannot afford to have a larger world-wide sales direct force as the larger EDA companies have. That’s where technologies like Xuropa come into play, that enable these smaller companies to do more with less and be global without hiring a global sales force.

CG: What drives the requirements placed upon new technology in the EDA space? How are the products developed? Are there a lot of interactions with specific big name designers (i.e. Intel) or does it shade more to the manufacturers (TSMC)?

HTAG: In fact, a handful of key customers usually drive the requirements, especially for small companies. When I was at Synopsys, Intel’s needs was the driver for a number of years. Basically, the larger the customer, the greater the clout. Other customers factor in, but not as much. The most advanced physical design capabilities of the tools are often a collaboration between the EDA company and the semiconductor manufacturers (e.g. TSMC) and the also the designers (e.g. Qualcomm). Increasingly, EDA tools are focusing on the higher-levels and you are seeing partnerships with software companies, e.g. Cadence partnering with Wind River.

CG: A good chunk of chip design is written and validated in code. This contrasts with much more low level design decisions in the past. In your opinion how has this changed the industry and has this been a good or bad thing? Where will this go in the future, specifically for analog?

HTAG: Being a digital designer and not an analog designer, it’s all written in code. Obviously, the productivity is much higher with the higher level of abstraction and the tools are able to optimize the design much better and faster than someone by hand. So it’s all good.

For analog, I am not as tied in but I know that similar attempts are being tried; they use the idea that analog circuits can be optimized based on a set of constraints. I think this is a good thing as long as the design works.  Digital is easy in that regard, just meet timing and retain functionality and it’s pretty much correct. For analog there is so much more (jitter, noise margin, performance across process variation, CMRR, phase margin, etc, etc). I think it will be a while before analog designers trust optimization tools.

CG:It seems that the EDA industry has a strong showing of bloggers as compared to system level board engineers or even chip designers. What kinds of benefits have you seen in your own industry from having a network of bloggers and what about EDA promotes having so many people write about it?

HTAG: I think blogging is just one form of communication and since EDA people are already communicators (with their customers), they have felt more comfortable blogging than design engineers. Many of the EDA bloggers are in marketing types of positions at their companies or are independent consultants like me, so the objective is to start a conversation with customers that would be difficult to have in other ways. A result is that this builds credibility for themselves that then accrues to their company. I think there has also been a ton of sharing and learning due to these blogs and that has benefited the entire industry. On a personal level, I know so many more people due to the blog and that network is of great value.

CG: How has your career changed since moving back out of the EDA space and into consulting? What kind of work have you been doing lately?  How has your experience helped you in consulting?

HTAG: It is interesting to have been on the EDA side and then move back into the design side. Whenever I communicate with an EDA company, whether a presentation or a tool evaluation or any conversation, I can easily put myself in their shoes and know where they are coming from. On the one hand, I can spot clearly manipulative practices such as spreading FUD (fear, uncertainty, and doubt) about a competitor and I can read between the lines to gain insights that others would miss. On the other hand, I also understand the legitimate reasons that EDA companies make certain decisions, such as limiting the length of tool evaluations, qualifying an opportunity, etc.

Most recently I’ve been working on some new technology development at a new process node. It’s been interesting because I’ve been able to dig deeper into how digital libraries are developed, characterized, and tested and I’ve also learned a lot more about the mixed-signal and analog world and also the semiconductor process.

Many thanks to Harry for taking the time to answer some questions about his industry and how he views the electronics world. If you have any questions, please leave them in the comments or pop over to Harry’s main site and leave a comment there.

The Digital Switchover.

Not me. I almost did that a while back, but no. Not me.

Television.

Normally I wouldn’t write about it. A digital television standard is long overdue and in the end this will be a good thing. When you compare Analog vs Digital, there are many more benefits on the digital side of things: lower power for transmission, better bandwidth of signal, more bandwidth usage over the spectrum. All of these are good things. I can even talk about how those digital signals still have lots of analog components as they’re transmitted over the airwaves: multipath, signal loss, power calculation, reception problems, etc.

But no. I’d rather point something else out:

Technology adoption is driven by human nature. It must be adopted before it can help people.

Sure, the digital signals will be great. High Definition pictures and you don’t have to give a dime to those lovely cable companies. Lower power generation required to transmit the signals will help save the environment by lowering the carbon footprint. But until the switch actually happens (today…maybe), no one gets the benefits. The switchover has been delayed to now from this past February. Lawmakers deemed the country unready to make the switchover at that time. I mean, if people can’t watch TV, how will the politicians get their message out to the masses?

No matter how many new devices are introduced into the marketplace and no matter how available they make DTV switcher boxes, people still will not change until pushed. They will not go out and get the digital box or call their local politician until one day they turn on their television and the signal is not there. That is what will drive the final changeover. I wouldn’t be surprised if we saw a little bit more leeway from politicians before stations are officially told to shut off the analog transmitters.

This problem isn’t exclusive to television. This has happened for the past 30 years in conservation and renewable energy.  Regardless of how many times climate change experts point out we’re killing the planet, nothing moves until there is a scare that oil is running out (it is) or natural gas won’t always be available (it won’t) or coal is filthy (it is) or the power just goes out. Then people change their tune; they change gears and start thinking about buying that solar array or that home wind turbine. They start recycling again because they think it will start to help (it will, but what about the past 10 years of bottles you put in the landfill?). But the thing is, you need to think about buying the solar cells now, when there isn’t a 6 month backlog of installation requests and prices are jacked up due to demand. And Solar might even already be an affordable option for you.

I’m sure people will say there’s an economic aspect of it for DTV and that the people that use analog signals the most can’t afford the converter boxes. Perhaps that has some truth to it. But the point remains that no matter the technology, until that last group resistant or indifferent to change decides to go out and do something about it, those people can’t be helped.

What about you? Have you made the switchover yet? If not, why? Leave a note in the comments.

If you are an engineer who regularly works with your hands, you likely troubleshoot on a daily basis. It’s just part of the job. Sure, you can say, “I never mess up!”, but hardly anyone will believe you. Because even when your best laid plans go perfectly, Murphy’s Law will soon kick in to balance things out. We learn to deal with these things and have developed tools and measurement equipment to help us diagnose and deal with these problems: Multimeters, Electrometers, SourceMeters, Oscilloscopes, Network Analyzers, Logic Analyzers, Spectrum Analyzers, Semiconductor Test equipment (ha, guess I know a little about that stuff)…the list goes on and on. But what has struck me lately has been that as parts on printed circuit boards get smaller and smaller, troubleshooting is getting…well….more troubling.

1. Package Types — I don’t want to get into another discussion of analog vs digital, but I will say that digital parts on average have many more pins which complicates things. And as the parts get more and more complex, they require more and more pins. The industry solution was to move to a Ball Grid Array package, using tiny solder balls on the bottom of the chip that then line up with a grid of similar sized holes on the board. When you heat up the part the solderballs melt and hold the chip into place and connects all of the signals. The problem is the size of the solderballs and the connecting vias: they’re tiny. Like super tiny. Like don’t try probing the signals without a microscope and some very small probes. But wait, it’s not just the digital parts! The analog parts are getting increasingly small to accommodate any of those now-smaller-but-still-considerably-bigger-than analog parts. You thought probing a digital signal was tough before? Now try measuring something that has more than 2 possible values!
2. Board Layers — As the parts continue on their shrink cycle, the designers using these parts also want to place them closer together (why else would they want them so small?).The circuit board designers route signals down through the different layers of insulating material so that mutiple planes can be used to route isolated signals to different points on the board. So to actually route any signals to the multitude of pins available, more and more board layers are required as the parts get smaller and closer together. Granted, parts are still mounted on either the top or bottom of the board. But if a single signal is routed from underneath a BGA package, down through the fourth layer of an 8 layer board board and then up to another BGA package, the signal will be impossible to see and measure without ripping the board apart.
3. High Clocks — As systems are required to go faster and faster, so are their clocks. Consumers are used to seeing CPU speeds in the GHz range and others using RF devices are used to seeing even higher, into the tens of GHz. The problem arises when considering troubleshooting these high speed components. If you have a 10 GHz digital signal and you expect the waveforms to be in any way square (as opposed to sinusoidal) you need to have spectral data up to the 5th harmonic. In this case, it means you need to see 50 GHz. However, as explained with analog to digital converters in the previous post, you need to sample at twice the highest frequency you are interested in to be able to properly see all of the data. 100 GHz! I’m not saying it’s impossible, just that the equipment required to make such a measurement is very pricey (imagine how much more complicated that piece of equipment must be). High speed introduces myriad issues when attempting to troubleshoot non-working products.
4. Massive amounts of data — When working with high speed analog and digital systems there is a good amount of data available. The intelligent system designer will be storing data at some point in the system either for debugging and troubleshooting or for the actual product (as in an embedded system). When dealing with MBs and even GBs of data streaming out of sensors and into memories or out of memories and into PCs, there are a lot of places that can glitch and cause a system failure. With newer systems processing more and more data, it will become increasingly difficult to find out what is causing the error, when it happened and how to fix it.
5. Less Pins Available out of Packages — Even though digital packages are including more and more pins as they get increasingly complex, often times the packages cannot provide enough spare pins to do troubleshooting on a design. As other system components that connect to the original chip also get more intricate (memories, peripherals, etc), they will require more and more connections. The end result is a more powerful device with a higher pin count, but not necessarily more pins available for you the user/developer to use when debugging a design.
6. Rework — Over a long enough time period, the production of  printed circuit boards cannot be perfect.  The question is what to do with the product once you realize the board you just constructed doesn’t work. When parts were large DIP packages or better, socketed (drop in replacements), changing out individual components was not difficult. However, as the parts continue to shrink and boards become increasingly complex to accommodate the higher pin counts, replacing the entire board sometimes becomes the most viable troubleshooting action. Environmentally this is a very poor policy. As a business, this often seems to be a decent method (if the part cost is less expensive than the labor needed to try and replace tiny components) but if and when the failures stack up, the board replacement idea quickly turns sour.

While the future of troubleshooting looks more and more difficult, there have always been solutions and providers that have popped up with new tools to assist in diagnosing and fixing a problem. In fact, much of the test and measurement industry is built around the idea that boards, parts, chips, etc are going to have problems and that there should be tools and methods to quickly find the culprit. Let’s look at some of the methods and tools available to designers today:

1. DfX — DfX is the idea of planning for failure modes at the design stage and trying to lessen the risk of those failures happening. If you are designing a soccer ball, you would consider manufacturability of that ball when designing it (making sure the materials used aren’t super difficult to mold into a soccer ball), you would consider testability (making sure you can inflate and try out the ball as soon as it comes off the production line) and you would consider reliability (making sure your customers don’t return deflated balls 6 months down the line that cannot be repaired and must immediately be replaced). All of these considerations are pertinent to electronics design and the upfront planning can help to solve many of the above listed problems:
   1. Manufacturability — Parts that are easy to put onto the board cuts down on problem boards and possibly allows for easier removal and rework in the event of a failure. It becomes a balancing act between utilitizing available space on the board and using chips that are easier to troubleshoot.
   2. Testability — Routing important signals to a test pad on the top of a board before a design goes to the board house allows for more visibility into what is actually happening within a system (as opposed to seeing the internal system’s effect on the top level pins and outputs).
   3. Reliability — In the event you are using parts that cannot easily removed and replaced and you are forced to replace entire boards, you want to make sure your board is less likely to fail. It will save your business money and will ensure customer satisfaction.
2. Simulation — One of the best ways to avoid problems in a design is to simulate beforehand. Simulation can help to see how a design will react to different input, perform under stressful conditions (i.e. high temperature) and in general will help to avoid many of the issues that would require troubleshooting in first place. A warning that cannot be overstated though: simulation is no replacement for the real thing. No matter how many inputs your simulation has and how well your components are modeled, no simulation can perfectly match what will happen in the real world. If you are an analog designer, simulate in SPICE to get the large problems out of the way and to figure out how different inputs will affect your product. Afterward, construct a real test version of your board or circuit and make sure your model fits your real world version. By assuming something will go wrong with the product, you will be better prepared for when it does and will be able to fix it faster.
3. Very very steady hands — Sometimes you have to accept the fact that you messed up and the signal traces on your board and you have to rewire it somehow. My analog chip designing friends needn’t worry about trying this…chips do not have the option for re-wiring without completely reworking the silicon pathways that build the chip. In the event you do mess up and have to try and wire a BGA part to a different part of the board or jumper 0201 resistors, make sure you have a skilled technician on hand or you have very steady hands yourself. And in the event you find yourself complaining about how small the job you have to do is, think of the work that Willard Wigan does…and stop complaining.
4. On the Chip/Board tools — Digital devices have the benefit of being stopped and started at almost any point in a program (debug). Without being able to ascertain what the real world output values are though, it doesn’t help too much. If in the event you do not Design for Test and actually pull signals you need to probe to the top level then you create a board then there are a few other options. One option is to try and read your memory locations or your processor internals directly by communicating through a debugger interface. But if you are looking at a multitude of signals and want to see exactly how the output pins look when given a certain input there is another valuable tool known as “boundary scan”. The chip or processor will accept an interface command through a specified port and then serially shift the values of the pins back out to you. Anytime you ask the chip for the exact state of all the pins, an array of ones and zeros will return which you can then decode to see which signals and pins are high or low.
5. Expensive equipment — As mentioned above when describing an RF system measurement needs, there will always be someone who is willing to sell you the equipment you need or work to create a new solution for you. They will just charge you a ton for it. In cases I have seen where a measurement is really difficult to calculate or you need to debug a very complicated system, the specially made measurement solutions often perform great where you need them, but are severely limited outside of their scope. To use the example from before, if you needed a 100GHz oscilloscope, it is likely whomever is making it for you will deliver a product that can measure 100GHz. But if you wanted that same scope to measure 1 GHz, it would do not perform as well because it had been optimized for your specific task. However, there are exceptions to this and certain pieces of equipment sometimes seem like they can do just about anything.

Debugging is part of the job for engineers. Until you become a perfect designer it is useful to have methods and equipment for quickly figuring out what went wrong in your design. Over time you become better at knowing which signals will be critical in a design and planning on looking at those first, thereby cutting down on the time it takes to debug a product. And as you get more experience you recognize common mistakes and are sure not to design those into the product in the first place.

Do you know of any troubleshooting tools or methods that I’ve missed? What kinds of troubleshooting do you do on a daily basis? Let me know in the comments!