In Defense of A conversation with Andrew Piziali
"Language shapes the way we think and determines what we can think about." Benjamin Lee Whorf Natural language is what you and I use to communicate with each other. It's our vernacular. We use it to articulate everything from instructions to the baby sitter, to chatting with the auto mechanic, to yelling at the credit card company because there's a charge on the bill that shouldn't be there. In most cases, natural language is also what we use to describe to our fellow employees what our next product is going to be what the next electronic system or sub-system we're about to design and produce is gong to do, look like, cost, and how it's going to perform. To say natural language is important is about as informative as saying air is important. Of course air is important. Of course natural language is important. Nobody's saying it isn't. However, there's a debate underway today about natural language with respect to electronic design. Actually, it's a debate that's been underway for some time and it centers on the role natural language should or shouldn't play in describing systems at the outset of a project. Many feel that using natural language to delineate system specifications is a messy business. Natural language is not necessarily highly structured although it does have some structure including vocabulary, grammar, syntax, and convention and therefore all kinds of nuances and ambiguities can be introduced into a design when it's specified using natural language. For some people that's a bad thing, however for Verisity's Andrew Piziali that's a good thing. Andrew thinks that natural language is exactly the paradigm within which electronic systems should be specified. He celebrates the ambiguities, commends the nuances, and says, "Design intent is something that's conceived in the human mind by a single architect or a group of people and natural language is the best way to reflect that intent." "We conceive of our ideas in natural languages. We discuss those ideas among our colleagues, and we write our initial specifications in a natural language be it English, Hebrew, Italian or whatever. Even though there are ambiguities [in natural language specs], which can introduce problems, those ambiguities actually contribute a great deal more to the problem formulation than they detract from the process, and are therefore important. Most importantly, the significance of natural language specs derives from the ability to functionally verify that system in the end, without over-specifying the system at the outset." Lately however, according to Andrew, there's been a move to replace natural language formulations as the paradigm for system description with more formal, structured constructs like property specification languages. Per Andrew, using those languages to produce "a math document, or a list of properties, that can be specified using some automated tool and then proved later on in RTL is problematic. It's only through the use of natural language, with its inherent ambiguities, that designers can still have access to the multiple degrees of freedom they need to design a system. If the requirements for a design are designated as absolute at the outset, choices that could or should be made further downstream in the design process are determined too soon." Andrew says that attributes such as power, performance, noise, and thermal characteristics are not functional in nature. "It's best that these choices be left unwritten or otherwise unstated in the initial specs, so that they can be determined at a later, more appropriate point in the design process by the more appropriate individuals." This is the most important aspect of writing system specifications in a natural language, according to Andrew. "The various requirements of a device should be addressed in a specification document, but things like interfaces, internal structures, timing, etc. should not to be addressed in such a document. Therefore, it's important that the specification document be written without a specific class of reader in mind. For instance, there are those readers who are verification engineers who are going to look at each implementation proposed and the document needs to be accessible to them. But then there are also the embedded software developers who are going to write the applications for that system, and certainly the specification document should be written from their perspective, as well." "When I was a young engineer at IBM in the 1970's, we had a document The S/370 Principles of Operation, affectionately call the "PoO" which specified the IBM S/370 architecture. It was 8-1/2 by 11, and 6 inches thick. The document had to meet the needs of diverse populations the programmers, the operating system developers, the applications developers, and the peripheral device implementers. All of these points of view were represented in that specification the authors had everyone covered." "From the perspective of an external peripheral designer, for instance, the document said something like: 'If an interrupt is asserted, that peripheral will observe the interrupt.' Or it said, 'From the perspective of CPU-0 interacting with CPU-1, it will be observed that this or that will occur.' Those are examples of functional specifications that respect the needs of multiple parties. And these were nuances in the system that couldnt be captured using formal properties." Andrew says that what is needed for designs today is a similarly well structured natural language specification document. The project team needs to proceed from that document to a property set that defines the system in static specifications, which will allow for the proving or disproving of various properties delineated in the specs. If specific properties are included in the first-cut natural language specification, however the natural language ambiguities minimized or eliminated those properties will over-specify the requirements of the design. "There's just no substitute for the ability of a human to read a natural language specification, to determine the properties necessary to fulfill those specs, and to determine what should be included in a formal document of those specifications," according to Andrew. "If a mechanical process is achieved which can embody a model checker, the challenge remains to compare the formal properties with the natural language specs. Clearly, there's an absolutely unavoidable human element in this because, as I said earlier, design intent originates in the human mind." Past IBM, Andrew's career also took him to Texas Instruments: "At TI, we would have these long discussions about design intent and the process often included a white board where the design propositions would first start out. That process made it very clear that there's no substitute for the light bulb that goes on in the human mind when a system is conceived of that can a) be implemented, and b) include specifications that can be preserved for comparative purposes at a later point." Andrew contrasts the two different ways of selecting a final implementation for a design. "Either we're going to move from the white board, to a natural language specification, to a formal specification, and on to an implementation. Or, we're going to eliminate the natural language specification [part of the process], but I'm arguing that choice eliminates the necessary and sufficient ambiguity in the project to allow optimal design choices at the appropriate steps in the process. Things like how wide the registers should be or the depth of the pipelines from the end-user perspective and data sheet perspective on the final product, these choices should not be made too early on in the process." "The thing to note here is that various players contribute to the refinement of a design. From abstraction to the ultimate realization, each have expertise, and that expertise needs to be able to further refine and further disambiguate. So, the original system architect for the design should only be writing with respect to system-level requirements. They should not touch on the implementation. Then, the senior designers should look at a second spec a functional specification. Then, there are the micro architectural specs. Those specs address and consider a number of different implementations and choose the optimal one." Andrew says the efficacy of the process is reflected in the efficiency of the designers: "If you have a specification, and you hand it to the designers and they say, 'This is great. I can meet these specs and add some functional stuff that you haven't even thought of.' then you've got a great spec. If, however you hand the designers a spec that's over-specified, they'll struggle a great deal just to meet the minimum requirements of the spec. As a verification engineer in CPUs all these years, I see designers going back to the system architect time and again and asking, 'Why did you say this needs to be a 6-stage pipeline? You're making implementation choices for us that don't need to be made.'" "I do clearly see why those who are pursuing statistical verification methods at least in their marketing literature want to reduce the specification options to a specific set of allowed parameters. Harry Foster, for instance at Jasper, and I disagree about this. I think Harry would like to fully specify the functional requirements of a design in a formal property set. I think, however, as I said earlier that we would then be specifying things in too much detail and we'd be capturing requirements of the design that are better left to those more knowledgeable farther down the process." "If I were debating with Harry, I would say that a property set will be essential they're already being used and have a lot of value today in that they help us to state specific behavioral requirements of a design and they allow tools in a methodical fashion to demonstrate if a logic block, for instance, can meet those requirements." "However, those properties cannot be stated at the top of the process. They need instead to come from people knowledgeable in writing properties after the analysis and review of the natural language specification is complete." Which augments even further Andrew's defense of the use of natural languages: "Another advantage of natural language for system specification is that everybody from the marketing guy to the cell designers can read the document and understand what we're looking to accomplish. If you're going to write your spec in PSL, then you have to accept the fact that only a small number of individuals on the team can actually participate in the design refinement process." "Clearly, if you go with the natural language spec, you can use a horizontal participatory process for design refinement. You may specify something at a higher level that simply can't be implemented, and you'll discover that a whole lot sooner if your entire team can access the specs equally. In fact, that's one of the big dangers of what is referred to as a vertical design flow the danger being that you introduce re-work because someone at the beginning of the specification process has written requirements of which, perhaps, only 15 or 20 percent can be implemented. Your team is far more effective if you implement a horizontal collaborative effort." From the structure of the design team to the advantages of ambiguities, Andrew's firmly planted in his language camp: "With 3 million words in a natural language, you are afforded huge degrees of variants in describing a concept each one of those variants replete with a variety of nuances. Compare that opportunity to the process of using an artificial language such as PSL, and suddenly you dont have anything near that level of flexibility." "You've got to look at the history of programming languages. Look at C, or COBOL, or FORTRAN there were many implementation languages written to restrict and/or eliminate the possibilities within a design. But when a question about the proposed design was posited, there was only one way to frame the answer. That was by reverting back to natural language to hash out disagreements. That's still the situation today." ************************** Editor's Note: If you would like to engage Andrew further on this topic, he would be happy to hear from you. Here is his contact info: Andrew Piziali **************************
Peggy Aycinena owns and operates EDA Confidential. She can be reached at peggy@aycinena.com
|