The EDA360 concept of System Realization is all about overcoming hardware/software integration issues. How bad could those be? Well, software is invisible and its operation cannot be probed without appropriate tools. There are myriad pitfalls for software developers trying to write code for direct hardware control including simple typos in the code, misunderstandings of the target hardware, false assumptions about how a hardware block operates, misunderstandings of I/O protocols, failure of the hardware components (or IP blocks) to match their paper specifications, unforeseen timing issues, etc. Any one of these can produce the same symptom: an inert piece of hardware. The hardware/software integration team’s job is to climb over these obstacles as quickly as possible.
My good friend Dave Jones, the energetic host of the EEVblog, is able to demonstrate all of these problems in a real-world example: his ongoing processor-based power supply project. The example for today is a video, Part 8 of his Power Supply Design video series.
There are a couple/three really amazing things I want to especially point out about this video
First, Dave gets you takes the troubleshooting of an awesome number of technical hardware/software integration issues in a short 34-minute video. For such a simple design using just a few ICs and an 8-bit processor, there sure are a lot of problems. Thirty four minutes is really not much time for such a large set of technical troubleshooting topics, so Dave moves fast. So fast, you may need to watch this video a couple of times.
Second, despite the fact that Dave talks at close to the speed of light with an Australian accent, the clarity he brings to his explanations is a testament to how well he understands these integration problems and to his video-editing skills. He challenges you to keep up.
Third, you really should stay tuned to the video’s bitter end. After it appears he’s done, Dave comes back with yet another unexpected hardware/software problem (a latent one) that’s caused by a standard, off-the-shelf component doing something funny—something it’s not supposed to be doing—under firmware control, once again establishing that there are paper specs and then there’s the way this stuff really works. It’s just an aside, tossed in at the last minute, but it represents yet another common, real-world hardware/software integration problem that’s a part of what integration teams face every day.
Here’s the video: