That's a question that various editors of ISD have debated for years. But as more and more chip designs include embedded processors, the issue is gathering about it urgency and persistence.

One approach would be to put our collective editorial head in the sand for a while and see if software goes away. After all, there are plenty of important topics in just the hardware portions of the design flow. But in a way, that last sentence explains why we cannot ignore software: It is no longer a separate subject, but an increasingly integral part of the total chip design flow.

It's obvious that if a chip includes a processor, there will be some hardware-dependent software to be written. And given the legendary communications problems between chip designers and programmers, it is the hardware folks who usually end up writing anything that requires more than a quick-reference-card familiarity with the hardware.

Ideally, that would mean drivers-little routines that interface a set of clearly defined registers on the chip to a set of clearly defined system calls in the RTOS. I hear you snickering. More often than not, according to our research, hardware dependency-or at least the need to understand the hardware in detail-leaks through the driver layer and the RTOS to the application software itself. So readers of ISD end up writing application code.

Another issue has been growing in parallel with this one. That is the need for chip designers to take part in the software-verification process, such as it is. We are all pretty familiar with what verification is coming to mean for hardware designers. For the software folks, it often simply means running the code with a bunch of different inputs to see if it appears to do the right thing-very much the state that hardware verification suffered in the early days of logic simulation.

Trouble is, most of the software folks won't have sufficient knowledge of the chip design to understand the results of their runs, unless everything appeared to work perfectly. So, once again hardware designers get involved in the software side of the design flow, setting up simulation models or emulation systems for software runs, and interpreting the results.

Finally, a third issue is emerging. There is growing interest, as our cover story this month illustrates, in starting out a design with a software-based functional model, free of not only timing information, but even any implicit assumptions about hardware vs. software implementation. This model is verified against the design requirements, and then incrementally refined into an implementation.

Indications are that the language for this model will be a conventional programming language, such as C++ or Java. And much of the early work-including the vital step of refining parts of the functional model so that the code is suitable for translation into something synthesizable-will require both hardware design knowledge and programming skills.

So do we write about software? Yes, we must, because certain facets of software design have become inextricably woven into our design flow.

http://www.isdmag.com

© 2001 CMP Media LLC.
11/1/01, Issue # 13149, page 6.