By Chris Giles • November 15, 2021
Reaching into the part of my brain where the memories are still on paper, stuck in file drawers in metal filing cabinets, covered with dust, indexed by cryptic number/letter combinations that pretty much ensure I have almost no recall, I find a memory of a former colleague who referred to himself as “non-stick surface man”. (Actually he referred to himself with a trademark but I don’t want to get him into trouble so – let’s just non-stick with Non-Stick Surface Man, or Mr. NSSM for short.) He called himself this because it was his design goal that his code be perfect when he brought it to be integrated into the broader design and tested. It was a badge of honor he held over the rest of us heathens who dared bring a bug to the party. Of course, you can imagine that the rest of us on the team were overjoyed (well, that might be a bit much – let’s just say “happy”) when a bug actually turned out to be in his code. There were lots of false alarms, moments of panic in his eyes that he missed something, followed by louder and louder self-proclamation of his Mr. NSSM status when proven innocent. Ultimately, bugs did happen in his code – but in fairness – there weren’t many.
So how did Mr. NSSM achieve his status? Well, he invested a lot of effort meticulously planning and coding and reviewing and cross-checking – so much so that he was also sometimes one of the last to bring his code into integration. I can’t say for sure but I also believe he did some bit-wiggling in a simple testbench before checking anything in as well – just to be sure. The key is that he understood how a single bug in RTL, not found until verification, slowed projects down. He invested effort up front to make sure he wasn’t the person we all pointed to when we had to call home that night and say we’d not be home for dinner or bedtime (back when you went to work in a building, not the next room, or worse, the chair on the other side of your room).
Read the entire blog post >
By Jake Wiltgen • September 20, 2021
ISO 26262 remains the state of the art standard guiding the development of electronic and electronic systems destined for the automobile. By 2030, some estimate that the BOM of a vehicle will be 50% electronics and electronic components. Regardless, ISO 26262 has solidified itself as the backbone of the safety lifecycle for semiconductor companies. The standard is far reaching, delivering guidance from concept to decommission across OEMs, Systems Integrators and Suppliers. For suppliers, the guidance is focused into three areas:
- Lifecycle Management: The process and governance required within the lifecycle
- Systematic Failures: The activities and work products required to ensure the component operates per the requirements
- Random Failures: The activities and work products required to ensure the component fails safely when a random failure occurs
Lately, much of the attention is given to the activities surrounding Lifecycle Management and Random Failures (also known as Random Faults). This is likely due to these two pillars being new challenges for many semiconductor companies moving into the automotive market. However, it is important to not discount the challenges faced within the systematic failures pillar, especially as the exponential growth in IC complexity challenges even the most veteran IC teams in delivering a bug and defect free device. As a recap, systematic failures are failures which are due to design bugs, manufacturing defects, missing functionality, etc…
Read the entire blog post >
By Chris Giles • September 14, 2021
Several years ago, I posted a job opening for a Design Engineer. To my surprise, a few of the responses I received were from individuals in the fashion industry, looking for a fashion design position. Apparently, I didn’t write the job description well enough. Actually, on second thought, I think I did but those fashion types who applied probably assumed that I mistakenly listed the job as microprocessor design and that the job really was about designing pants. But I digress. Design is admittedly a very vague word. It means a lot of things to a lot of people. So, let me be perfectly clear – in the context of the rest of this entry, when I say design, I mean digital hardware design. Clear?
Moving on, I’d like to propose that most of us know bad design when we see it. The Tacoma Narrows Bridge comes to mind. Or the 8-track tape. Or bell-bottom pants. But I digress. So, why do we know bad design when we see it? Probably because it fails to achieve its intended purpose – sometimes spectacularly. We don’t often notice good design because it just does what it’s supposed to do. We only really notice good design if it does what it is supposed to do exceptionally well! But bad design – in the least it’s annoying and at its worst the result is magnificently expensive in one of many possible ways.
Read the entire blog post >
