One of the common characteristics of EDA companies is that most often the engineering teams are managed by hardware engineers. The result is that during product development much attention is paid to the problem to be solved and less emphasis is given to the software development methodology used. This to me is the core message of a presentation given at UC Berkeley by two staff members of Blue Pearl Software.

David Wallace and Scott Bloom point out that during their extensive career as product developers for EDA companies, they have experienced a lack of structured programming methodology during software development. The problem is not the lack of t4esting, but how software is architected and tested. It is clear that given schedule pressures have an important role to play in focusing on completing the tool and then testing the entire product as a monolithic entity. The article "How Can We Build More Reliable EDA Software", is, in my opinion, required reading for all development managers in the EDA industry.

Hardware engineers focus on whether or not the requirements are met. Does the tool give accurate and expected results to the engineering problems it is meant to solve? This is the most important question for most managers. No one disputes the fact that the correct answers to these questions are a necessary but not sufficient, according to the authors of the paper, reason to decide that the product is reliable and maintainable during its expected market life.

The paper covers all aspects of structured programming, from its principles of controllability and observability, to unit testing, to reusability, and ends with a report on the experiences gained at Blue Pearl Software. In between the reader will find that the development of a complex software program is dissected into the steps required to produce robust and maintainable code that meets the requirements.

A section of the paper deals with cost versus time and issue always at the forefront of managers. It is obvious that tradeoffs must be made, but one needs to be aware of the implications of such decisions.