eIA^S-:? ~~ 1717,h

HARDWAREDESCRIPTION LANGUAGES:Voices from the Tower of Babel*G. J. LipovskiThe University of Texas

Introduction

A hardware description language can be used to describethe logic gates, the sequential machines, and the func-tional modules, along with their interconnection and theircontrol, in a digital system. In a general sense, Booleanequations, logic diagrams, programrning languages, andPetri nets are hardware description languages: they canbe used to describe some aspect of hardware and theyhave definable syntax and semantics. Specifically, what ismore commonly referred to as a hardware descriptionlanguage is a variation of a programming language tunedto the overall needs of describing hardware. This articlewill discuss the rationale for using such languages in thefirst place, identify the problems attendant upon theirproliferation, and describe the measures being taken toachieve a solution.

Why hardware description languages are used

An LSI circuit has about a thousand gates on less than a1 centimeter by 1 centimeter dice of silicon. LSI circuitsare far cheaper and far more powerful, and have potentiallyfar more use than previous digital packages. In the digitalelectronics business, LSI means revolutionary growth.But to the designer LSI means large scale insanity! Becausemore circuitry is inside the package than outside it, thelogic diagrams he is familiar with convey less information.They show the type number of the device and the pinconnections. They do not show the function being per-formed, nor do they indicate legal and illegal connectionsand signals, nor do they convey principles of operation.They are useful to the technician, because he can tellwhich integrated circuits to put in and where to put them,and how to wire them up. But they are useless to thedesigner, because they do not show how to effectivelyinterface to the logic, or how to utilize its features. More-

14

over, they do not tell the technician how to troubleshoot adefective system. Although catalogues indirectly give thisinformation through the type number, it is difficult tounderstand a circuit with some 10 LSI circuits, keepingfingers in 10 catalogues. Because high-level programminglanguages have powerful operators and techniques forabstraction, they offer some hope to the abashed designerand overpowered technician. Although hardware designersand technicians have rather shied away from softwareconcepts, they are being hurled that way by the onslaughtof microprocessors which are programmed by languageslike PL/M. Because of the need to describe and documenthardware, hardware description languages are becomingincreasingly more important.LSI has further borne the microcomputer, and the

microcomputer further requires hardware descriptionlanguages. Actually, LSI economics show that the firstcopy of any LSI circuit is very expensive, whereas latercopies are less and less costly. So, one aims to design"universal" LSI circuits that will be widely used. Which,in fact, is what the microcomputer is: a "universal"LSI chip.Two problems related to description arise with its

introduction: Since the microcomputer is fundamentallyan alternative to hardware, hardware-software tradeoffscan be effected nicely with it. A description technique isneeded to show either hardware or software or combinedhardware-software designs. Indeed, a hardware descriptionlanguage is needed. Moreover, in quite another problem,some 44 microcomputers are being manufactured now andmore are expected every day. To select one that is suitablefor his application, the designer writes programs called

*Thig article was extracted from "Hardware DescriptionLanguages," which has been submitted for publication in TheEncyclopedia of Computer Science and Technology (Jack Belzeret al., eds.), published by Marcel Dekker, Inc.

COMPUTER

benchmarks in each machine.' But it is hard to keep theinstruction sets of these machines straight. A concise butprecise hardware description language is invaluable forbenchmarking microcomputers in particular and anycomputer in general.Regarding the last two points, it is interesting to relate

two anecdotes that show how bad the problem is. Duringthe design of the Motorola M6800, some features werecopied from the PDP-1 1, including the conditional branchinstructions. The BIl instruction was defined as LOC-*PCif both C and Z = 0.2 The M6800 programming manual3interprets this as C . Z = 0 while the M6800 applicationsmanual' interprets it asZC Z = 1. Another anecdote comesfrom Don Lancaster's TTL Cookbook,' where the 74956 iscredited with being a left shift-right shift register, likethe 74194. In fact, it is not. By external connections it iscapable of functioning so, but it is not intrinsically so. Thisis not meant to impugn Digital Equipment Corporation,who has designed a superb minicomputer, nor Motorola,who has manufactured a fine microcomputer, nor DonLancaster, who has authored many excellent books forelectronics technicians. It merely serves to show thathighly respected, competent people are having difficultydescribing hardware and understanding those descriptions.

Ah! The programming language designers wouldjump to the rescue.

One of the most significant uses of hardware descriptionlanguages is as a means of input to a simulator. Logicsimulators can be used to verify a design before the partsare assembled and wired. They can also be used to modelfaults so that procedures to test the device can be selectedand verified. Some logic simulators also model very lowlevel gate delays and asynchronous (unclocked) circuitbehavior, but many simulators are geared to study thefunctional behavior of synchronous (clocked) systems,and some are oriented to study the behavior of the instruc-tion set of a microcomputer or computer. The hardwaredescription languages used by these simulators conveythe appropriate information; low-level simulators arecharacterized by having delay operators (among others)while instruction-level simulators have means to effectivelydescribe floating point operations (as well as otheroperations).Computers can be used to aid the design of many things.

But computer-aided design has been of little use indesigning computers (with the notable exception of simu-lation). This somewhat embarrassing phenomenon is

attributable to two description problems. First, languageis needed to convey the problem from the designer to thecomputer, and vice versa. Graphical languages like logicdiagrams are effective when used with expensive graphicsterminals, but textual languages are better able to expressvariations and subtleties than graphical languages can

express them by shapes and sizes of figures alone.There is some argument as to whether textual or

graphical languages are more powerful. Historians tell ulsthat our alphabet evolved from a language of shapes andfigures. Evidently, the Greek merchants first used theshape of a cow's head to denote "cow." Shapes were useduntil too many shapes were required, so the "cow" shapewas tilted to become the letter "A." A textual languagehad to be created to describe the large variety of ideas.Similarly, although shapes were suitable for a few logicelements-AND, NAND, etc.-the large variety of MSIand LSI logic elements forces us to repeat history-touse a textual language in lieu of drawing shapes andsymbols. Others argue that two-dimensional (graphical)

June1977

languages are more powerful than one-dimensional (textual)languages. Perhaps we need a mixed graphical-textuallanguage, in which the combined language can be used ongraphics terminals and the textual part is rich enough topermit input-output using inexpensive text-formattedterminals.But the crux of the problem is arriving at an adequate

definition of the textual language. Simple languages likeBoolean equations cannot convey enough informationabout today's LSI designs. Even simulation languagescannot articulate the intent of a designer to a powerfulcomputer-aided design program. That is, current languagesdo not have the capabilities to inform a computer-aideddesign program of the extent to which substitutions canbe allowed in the designer's initial description of thesystem. Secondly, digital design is very much an art.As in any art, it is easy to show the end productbut difficult to show the reasons behind the designchoices that produced it. So, very little has been publishedthat can be used to model programs after the way gooddesigners design systems. We just do not know enoughabout how to write design programs, because no languageexists to build up a body of knowledge on the art ofdesign. Computer-aided design has included useful simu-lation techniques to verify a design before the hardwareis built. But because of the two problems just cited, ithas had little other impact on designing computers. Clearlythere is a need for a powerful, high-level language todescribe hardware.Ah! The programming language designers would jump

to the rescue. Indeed, several papers have suggested thata conventional high-level programming language shouldbe used to describe hardware. APL7 has been particularlystrongly recommended. These languages have significanttechniques - PL/I's structure is useful for namingvariables in a modular system, Algol's block structure isuseful in structuring control procedures, and APL'scompact vector notation is useful to define replicatedhardware (e.g., 16 AND gates that AND a control scalarvariable with each of 16 different elements of a busvector variable). However, no known language has allthese techniques, and all languages omit some very impor-tant techniques. For example, most hardware operationsare triggered by using a falling edge of a signal, as in"ENTER THE VALUE B INTO A WHEN C FALLS:FROM 1 TO 0." Or they are defined by a level, as in"ENTER THE VALUE B INTO A AS LONG AS C IS 1."And many hardware operations are triggered simultaneouslyto be executed in parallel. Parallelism is a way of life forhardware designers, and their language must certainlyreflect it. But parallelism is very weak in high-levellanguages. Augmenting a programming language toinclude various parallelism techniques and other specialsymbols would so radically affect its syntax as to make acompletely new language. Future high-level languages forprogramming supercomputers that consist of an aggregateof microcomputers may find new need to express paral-lelism, so that the highly parallel hardware descriptionlanguages may be their paradign. Although programminglanguages offer many useful techniques, simply copyingthem or slightly extending them will not produce a goodhardware description language.

Problems with hardware description languages

Languages for describing hardware have existed sincevon Neumann described his computer architecture8 usinga hardware description language to define his instructionset. Since then, over a hundred papers have introduced orelaborated on hardware languages, and muc-h has been

15

published on the subject.9 One of the key problems in theproliferatioii of rather ineffectual hardware languages hasbeen the success of simulation as a design or analysistool. Anyone who. writes a simulator feels entitled to designhis own4language. It is difficult to read two or threepapers on diffet-ent languages, so that a designer wouldrather reinvent techniques he needs than to bother readingsomeone else's papbrs to obtain them. Not only are manyof the languages rather weak, being reinvented over andover, but languages that address significant descriptionproblems are too often rejected or ignored because nosimulator has been written for them. We seem to beconfounded in our own Tower of Babel-everybody istalking a different language but nobody is communicating.And like medieval alchemists who trafficked in oil ofvitriol, muriatic acid, eye of newt, etc., we design withUARTs, ALU's, and distributed architectures. Indeed, weare more like alchemists than chemists: each person useshis own notation, and communication is difficult. As com-plex organic molecules forced chemists to recognize theneed for a common language, complex LSI chips are forcingus to develop a language that all hardware designers canuse. But since most of us are quite comfortable with ourpeculiar notations, attempts to lead us out of the "darkages" are likely to meet considerable resistance.

We seem to be confounded in our own Towerof Babel.

A few hardware description languages have emerged tobecome reasonably well known.9 Y. Chu's CDL, orComputer Design Language,'0 appeared in 1965 and isextensively used, particularly in Europe. DDL, or DigitalDesign Language," was introduced in 1967 by D. L.Dietmeyer and his student J. R. Duley and is widely usedin U.S. industry. ISP, an instruction set processor lan-guage, and PMS, a process-memory-switch language,'2 wereintroduced by C. G. Bell and A. Newell in 1971 to describethe instruction set and interconnection of modules in acomputer and are popular with Digital Equipment Corpora-tion, as well as other manufacturers and universities.AHPL, or A Hardware Programming Language,"3 wasintroduced by F. Hill and G. Peterson in 1971, and isgaining acceptance as a powerful description languagebased on APL. There are numerous other excellentlanguages, but these are most well known in the UnitedStates. For an introduction to these languages, refer tothe December 1974 issue of Computer dedicated to hard-ware description languages. Upon comparison of theselanguages the reader might be struck with the similarityamong them. They all contain terms that respond to thedesigner's need to express parallelism, special hardwarefunctions, and control sequencing as well as hardwareinterconnection. And yet they all use different, kinds ofsymbols and constructs to express these concepts.But more to the point ot design methodologies, the above-

mentioned languages have flourished because they fill aneed in design. Top-down design is a preferred methodologybecause it defines the problem first and then derivesthe solution. A top-down design methodology selects theorganization, or block diagram, and gross control se-quencing, then the registers and transfers of databetween registers, and then the gates, IC's, and theirinterconnection. Although one can make the case that anysuccessful language can be used at all levels, CDL isparticularly simple and attractive for gate and registerdescriptions, DDL is more suited for descriptions oftransfer of data between registers in larger modules, AHPL

16

has powerful APL operators for descriptions of morecomplex modules, PMS is a superb language for showingthe organization of the hardwarev and ISP is the mostsuitable of the current languages for stating the problemat the top level. The point is that different languageshave strengths a designer would like to have at differentlevels of design. However, a designer cannot be expectedto be fluent in several languages. Even if he were, theimmediate design problem at any design stage would bespecified in one language and the solution presented inanother. Since languages use different symbols, anycommentary is likely'to be confusing, say if the commentaryuses, the symbol + which means "ADD" in one languageand "OR" in another language. So designers stay withone language and try to accommodate to its limitations.

Toward a consensus language

Recognizing the existence of many useful design toolsand the unnecessary variation among the conventions usedto implement them, a group of about sixty investigatorshave formed an ad hoc organization known as the "Confer-ence on Digital Hardware Languages." The conference,similar in structure to the Codasyl or the Algol Committee,aims to develop a common syntax and set of conventionsfor the various useful design techniques. In effect, thiswould permit one to use more than one technique in statingand in solving a design problem. The result would be a"consensus language" which would be able to express theessential concepts that are in common languages.

One disadvantage of a standard of any kind isthat it generally freezes further research.

This consensus language is going to have to be quitelarge to encompass all the useful techniques. Therefore, tomake it learnable, it will be divided into sublanguages,rather like those already in use. For example, there could bea "consensus-CDL" similar in scope and philosophy toCDL. However, it will be easy to learn a "consensus DDL"so that if a problem is better analyzed in the scope andphilosophy of DDL, one can use it without learning a lotof contradictory conventions. Also, one can mix the twolanguages without ambiguity, since they will be sub-languages of the same general consensus language. Wesuspect, too, that this consensus language will be, in asense, a standard language suitable for documentationand the literature. Here, it would fulfill a great need tosuppress the amount of room in a paper that is needed toaccurately describe the hardware, the problem, and thesolution, so that more room in the paper can be dedicatedto explain the reasoning behind the design.One disadvantage of a standard of any kind is that it

generally freezes any further research. This language iscalled a consensus language to draw similarity to theconsensus concept in switching theory: a consensus termis a term hidden in the intersection of two known terms.The conference aims to specify symbols for operators thatare used by two or more languages - consensus operators-and specify syntax for constructs that are used by twoor more languages - tonsensus constructs. However,individual languages can have special operators orconstructs other than consensus operators or constructs,provided they use the approved symbols and syntax forthe latter. It should be easier for a language designerto show a new language that addresses some new problemsbecause common operators and constructs will be familiar,and new operators or constructs will be more easily seen.

COMPUTER

But it will be harder for the language designer to expresshis artistic flair in molding the language to his taste. Weare willing to pay that penalty to correct the current"Tower of Babel" wherein anyone who writes a simulator,a paper, or a description of a device feels entitled to definea new language, and where, it seems, everyone is talking adifferent language and nobody is listening.Founded at an IEEE Computer Society - ACM

cosponsored workshop on computer description languagesheld at Rutgers in 1973, the Conference on Digital Hard-ware Languages has so far opted to maintain its inde-pendence from any group to avoid biasing the language,and to avoid pressures to produce it before it is ready. How-ever, it is informally supported by the Computer Society,ACM, and IFIP. The first two years saw considerableactivity through a system of ballots by mail. Everymonth, a memo and ballot were sent to the members.Scope, objectives, and inclusion of consensus operatorsand constructs were determined by the votes on theseballot questions. At the third annual meeting of thisgroup, held during the 1975 International Symposiumon Computer Hardware Description Languages in NewYork, the members felt a subcommittee, a working group,should digest the results of the ballots. The workinggroup-Robert Piloty (chairman), Dominique Borrione,Yaohan Chu, Don Dietmeyer, Fred Hill, and Pat Skelly-have funded their meetings by jointly giving a seminar onhardware description languages-at Bell Northern, Ottawa,Canada, and Sperry-Univac at Blue Bell, Pennsylvania.They are looking for future sites to hold a seminar thatwill make future meetings possible. Please contact theauthor if you have any questions or suggestions. Theworking group is currently digesting the ballots andbreaking new ground not covered by the ballots. We hopethey will have a preliminary consensus language by mid-1978. The entire conference will then examine and modifythe language. When it is adopted it will be publishedand promoted by the conference. Hopefully it will makehardware description languages even more useful. U

Acknowledgments

I would like to express my appreciation of the supportof members of the Conference on Digital Hardware Lan-guages, and in particular of Gordon Bell, Yaohan Chu,Don Dietmeyer, Fred Hill, and Dan Siewiorek in preparingthis atticle. Finally, I am indebted to Chuck Roth for avaluable review that provided final corrections and refine-ments.

References

1. G. J. Lipovski, "Digital Computer Architecture," Ency-clopedia of Computer Science and Technology, Vol. 6,Marcel Dekker Inc., New York, 1977.

2. Digital Equipment Corporation, The PDP-11 Handbook,Maynard, Mass., 1969, p. 25.

3. Motorola, Inc., "M6800 Microprocessor ProgrammingManual," Phoenix, 1975, pp. 4-11,

4. Motorola, Inc., "M6800 Microprocessor ApplicationsManual," Phoenix, 1975, pp. 1-39.

5. D. Lancaster, TTL Cookbook, Howard Sams, Inc., NewYork, 1974, p. 85.

6. Texas Instruments, Inc., The TTL Data Book for DesignEngineers, 2nd ed., Dallas, 1976, pp. 7-89.

7.- K. E. Iverson, A Programming Language, Wiley, NewYork, 1962.

June 1977

8. A. W. Burks, H. H. Goldstein, and J. von Neumann,"Preliminary Discussion of the Logical Design of anElectronic Computing Instrument," from Taub, A. H. (ed.)Collected Works of John von Neumann, Vol. 5, pp. 34-79, MacMillan, New York, 1963.

9. S. Y. H. Su, "A Survey of Computer Hardware Descrip-tion Languages in the U.S.A.," Computer, Vol. 7, No. 12,December 1974, pp. 45-51.

10. Yaohan Chu, Introduction to Computer Organization,Prentice Hall, Englewood Cliffs, 1970.

11. D. Dietmeyer, Logical Design of Digital Systems, Allynand Bacon, Boston, 1971.

12. C. G. Bell and A. Newell, Computer Structures: Readingsand Examples, McGraw Hill, New York, 1971.

13. F. Hill and G. Peterson, Digital Systems: HardwareOrganization and Design, Wiley, Englewood Cliffs, 1973.

G. Jack Lipovski is an associate professorofeetrical engineering and computer science

at the University of Texas at Austin. Hisinterests are hardware description languages,

- non-numeric architecture, digital systemsarchitecture, and microcomputer architecture.He is chairman of ACM's Special InterestGroup on Computer Architecture (SIGARCH),

2 L' a past chairman of the Computer Society'sTechnical Committee on Computer Archi-

tecture, coordinator of conferences and meetings for theComputer Society, a director of Euromicro, and an enthusiasticmember of the Conference on Digital Hardware Languages.Lipovski received an AB and BSEE from Notre Dame and

an MSEE and PhD in electrical engineering from the Universityof Illinois.

Use order form on p. 127.

Proceedings of the 2nd International Conference on

SOFIWARE ENGINEERNGOctober 13-15, 1976 (700 pages)

Topics covered in this proceedings include softwarerequirements and specifications, program synthesis,operating systems, education, performance evaluation,networks, design and development, programminglanguages, modeling, testing, tools, and case studies.Non-members -$20 Members - $15K~

.IsI

,