Silicon Valley based Blue Pearl Software is the quintessential EDA company: privately held, run by a seasoned team of EDA experts, and with a portfolio that includes tools for generating timing constraints, CDC analysis, both synchronous and asynchronous, RTL verification tools for methodology standards and design rules, and design management tools.
Similarly, Blue Pearl’s Ellis Smith is the quintessential CEO in EDA. Before founding his current company, Smith was CEO and President of Orora Design Technologies, CEO at TransEDA through that company’s IPO in 2000, and CEO at Exemplar Logic through its merger with Mentor Graphics in 1995. His experience also includes a stint as CEO at CrossCheck Technology, and years spent at Duet Technologies, CADAM, Versatec, Dictaphone, and 3M. Pretty much the whole history of the EDA industry in one CV.
It would be an excellent idea to sit down for a very long conversation with Ellis Smith to discuss his take on the history of this oh-so-interesting industry. Unfortunately, time was of the essence when I did get the chance to talk with him earlier this month, and the focus was principally on Blue Pearl.
Are you a requirements engineer but your main goal is to provide well organized documentation? Do you have a great knowledge about the industry, business analysis and systems but you are struggling with the shape and look of your documentation? Do you still hear, for instance, that the specification document is not easy to read and difficult to use?
Requirements first
Requirements are the starting point of all other activities in a project lifecycle. So the specification document is crucial for the project. The document has many audiences such us stakeholders, designers, verification engineers and other groups involved in the project. This forces the author of the document to take care of the structure and organization of the document. It is not a big deal to prepare such a document. The problem is that the document has to be modified many times. The requirements are constantly changing, with new features appearing, some being modified and some being removed. Reclassification and reorganization must be repeated many times. In which case, I am pretty sure you will be contending with issues such as auto numbering, indentation, paragraph styles as well as tables and drawings that just do not fit the page.
Another kind of trouble comes from collaboration. Requirements should be developed by more than one engineer but working together on the same document is really a challenge. Forgetting to enable Track Changes, using the wrong version of a document or even using different version of Office tools are the most common collaboration issues.
Finally, there may be a situation in which you focus on a document’s structure and aesthetics more than its content. In the end your document may be well prepared but there is a serious risk that the requirements will be ambiguous, incomplete and/or inconsistent. This can happen when huge amounts of energy are spent solely on keeping the document organized and current. For the rest of this article, visit the Aldec Design and Verification Blog.