But even today, some designs don't require top-down methodology or bottom-up verification. Examples include simple analog designs or designs with no feedback between the analog and digital sections. In either case, traditional analog design and verification practices would suffice for successful implementation.
Just as with any new process, converting to a top-down design methodology takes concerted time and effort to change. To switch to this new methodology, companies must embrace it and promote it throughout their enterprises—with support, time, and training. Even though there's an additional investment in building models top-down, it pays for itself in verification and in designing the next iteration of the product.
Designers also have to realize the value of top-down design and push for ever more tools and support. The potential rewards are huge for designers, companies, and end users of electronic products—the consumers.
Design is the fun part of programming, but debugging is the painful part. In debugging, we essentially find the underlying mistakes and assumptions that turned our beautiful free-flowing code into a stagnant swamp.
Today, debugging remains an art form, one not changed much over time. We still use Microsoft/Borland-like IDEs and debugging techniques familiar to yesteryear's programmers. Perhaps the time has come to develop better debugging tools and methodologies.
The rise of the Internet and its appliances and servers could be the catalyst. Of course, remote Internet debugging is a lot like past Ethernet-linked debugging. But today's ubiquitous Web browsers and servers place many more resources and interactivity in our hands for more effective debugging.
First, though, we should know where today's debugging tools and methodologies come up short. A while back, I talked with a project manager developing microcontroller software to coordinate multiple yacht engines. This major mathematical and software task had a 9- or 10-person team working on it.
Due to all of his coding and such, the project manager ended up with a bad case of carpal tunnel syndrome and had an operation. So, he was limited in his computer typing. But there was a silver lining in this dark cloud. His wife, a secretary, typed in his code and found most of his errors upon entering it.
Moreover, because of limited typing capacity, he started analyzing the errors more instead of just charging off with his IDE, trying various fixes and traps. He thought the problem through and worked from the execution symptoms to a solution. It worked. He was debugging problems in one-fourth to one-third of the usual time!
Another story concerns one of the best programmers I ever met. He almost never used the standard IDE debugger technique of rerunning and breakpointing, of moving up the code from symptom to error. Instead, he would look at the error, perhaps get a little more corroboration, and then examine the underlying data structures, variables, and threads. By all accounts, this technique solved problems very quickly.
Yes, we need better debugging tools and techniques. Yet as these stories imply, perhaps more of the same won't solve our problems, but only give us more to do. Maybe we would be better off with tools that are a bit more global, tools that integrate thread-level debugging with the program's overall structure, its variable-state machine, and underlying data structures. More focus on analysis and structure and less on IDE activity might be the necessary ticket.