The Search for the Executable Specification
Gabe Moretti, Senior Editor
One of the Holy Grail of EDA is to find a way to specify a design in such a way that the specification itself could be synthesized into an architecture so that one would be assured that the design met the requirements by construction. Work in the area has been going on for a long time, VHDL being the most significant language developed with the support of the US Department of Defense. Unfortunately, the language was understood and immediately used as a design implementation tool and thus overtaken in popularity by Verilog which is a true design implementation language.
The EDA community has continued to look for a way to write a specification in a language that is unambiguous, that can be modeled, and can be synthesized. Judging by the results, failure is consistent. Even great language architects, have not found a solution. The latest attempt, Rosetta, has been almost totally ignored. The problem, of course, is that no one wants to learn another language in order to write a specification, or build a tool for a language that may not be used or used so infrequently to be an economic failure.
But I think the answer is under our noses. It is being talked about, but the concept is so foreign to the design and marketing communities that it has not been recognized. It all started with the discussion about using Agile methods for hardware development. There are many reasons for not applying the Agile methods used in software development literally to hardware development, but surprisingly there is one that not only fits beautifully, but also solves the problem of developing a way to represent a design specification in an executable manner. And that is the test suite.
Of course I am not suggesting that Marketing learn to write tests, and thus ambiguity could still creep in at the beginning, but it would become obvious much sooner in the development project and thus more easily resolved as soon as a first level architectural implementation was tested.
A test suite properly constructed does in fact represent a specification for functional behavior. It defines a series of transformations that must be executed by the design in order to produce desired measurable states. By describing a set of input values and their sequence in time, as well as the expected outputs, one in fact describes a functional specification.
In addition, such test sequence does follow the Agile intent of continuous refinement, as more is known about the behavior of the desired product the test suite can be expanded accordingly and the resulting design incrementally modified. The result is that at all stages of development the design is testable in a consistent manner. Even better, if the results of a test are different from what was intended, the specification itself can be changed and the test file(s) updated.
A Universal Test Methodology (UTM)
A UTM would offer a methodology to group test suites addressing both functional and physical characteristics of the design into a manageable data base of stimuli and responses that, taken together, constitute the entire design specification, including timing, power, manufacturability and so on.
In an age of big data, tools are available to manage all the relevant information about a given design, and the data can be presented in a number of ways appropriate to the expected reader.
The design community is developing expertise in porting tests among specific tools required to analyze and verify different aspects of a design so the UTM does not represent such obstacle to timely implementation. And here again the Agile methodology of sequential refinements applies. Let’s start using what we know and expand and refine it to meet the requirements.