Karl J. Lieberherr
Northeastern University, College of Computer Science
Cullinane Hall, 360 Huntington Ave., Boston MA 02115
lieber@corwin.CCS.northeastern.EDU
phone: (617) 437 20 77
FAX: (617) 437 51 21
A summary of the history of Zeus and its salient technical features. An invited short paper for a special issue of IEEE Design and Test of Computers on VHDL. Allen Dewey, the editor writes: ``I would like to include several short papers describing various hardware description languages that have made seminal contributions to the present state-of-the-art.'' This is one such short paper.
My interest in hardware description languages started while I was on the faculty at Princeton University. Lectures of Richard Lipton on theory of VLSI design and Andrea LaPaugh's course on Mead/Conway style chip design were shaping my interest. During a visiting professorship at the Swiss Federal Institute of Technology in Zurich in the 1982/1983 winter semester, I was teaching a course on theory of VLSI design. It was before this course that I learned about Niklaus Wirth's new hardware description language, called Hades [Wir82]. Svend Knudsen, a Ph.D. student of Niklaus Wirth, and I became very interested in Hades and we started to use it to describe chip architectures.
This was the starting point of Zeus. While using Hades to describe VLSI designs, we identified several constructs which were missing in Hades. For example, Hades could not describe recursive hardware structures, such as a sorting network, in parameterized form. We improved Hades in several ways, and since we significantly changed the language we chose the name ``Zeus'' for our language, showing its relationship to Hades. We tested Zeus on numerous examples and we presented a paper at the 1983 Design Automation Conference, before the language was implemented.
I then started to look for a good place to implement Zeus. First I secured a grant from the Swiss National Science Foundation to continue my work at MIT, in the research group of Ron Rivest. A report on Zeus was published in the MIT Memo Series [Lie84] and in abbreviated form in this journal [Lie85]. Concurrently, I continued my Zeus work at GTE Laboratories in Waltham where Andrew Goldberg and I worked on implementing Zeus, and Steven German and I worked on the further development of Zeus from a verification point of view.
In 1984, after suggestions of Gerald Jones, Andrew Goldberg and I first developed a meta-programming tool on top of Pascal, to simplify the implementation of Zeus. This meta-programming tool has in the mean time been developed into a general purpose CASE system for C++, called the Demeter System/C++, which is described in [LBSL91] and in the references contained in that paper. Our work on the Demeter System continues and the system is available from Northeastern University.
Steven German was interested in formally verifying parameterized hardware structures, using the Boyer-Moore theorem prover. To make this process easier, we had to refine the definition of Zeus which we published in [GL85]. In [GW85], German and Wang published one of the first papers on formal verification of parameterized hardware designs.
Zeus was designed as an input language to a silicon compiler. A major concern was the expressiveness of the language regarding the desired layout and the functionality. Therefore, Zeus is a structural and functional hardware description language.
The structure of hardware is described by component types. Fig. 1 summarizes the conceptual structure of component types in the form of a so-called class dictionary [LBSL91]. A component type consists of a name, ports, subcomponents and connections. The subcomponents are named instances of component types and the connections wire the ports. A connection is described by two designators, each designator consisting of a name of an instance of a component type and a port name.
Variants of Zeus component types have other applications than for describing hardware components. They can be used to describe any modular system, be it a mechanical, electrical or software system or a combination of them.
A useful feature which we put into Zeus is parameterization. This leads to a two-tiered structure in the language. In the first tier we have parameterized statements that generate code for the second tier. The second tier then contains unparameterized descriptions which describe the ``flow of current'' when the chip is running. For example, in the first tier we have a WHEN statement which describes under which conditions a piece of hardware should be generated. This piece of hardware might contain an IF statement which describes a run-time decision.
This two-tiered structure of Zeus makes it powerful, but more complex to learn. When writing a parameterized Zeus description, one has to think about what kind of hardware will be created and how that hardware will behave at run-time. This two-level thinking is also common in the latest object-oriented programming techniques, where one also thinks in terms of parameterized code descriptions. While in Zeus the parameterization is expressed in terms of numerical parameters, in object-oriented programming it is expressed in terms of graph structures, called class dictionary graphs. For example, in Zeus we write
for i:=1 to n do left.a[i] := b[i]
to express the generation of n connections of ports. In object-oriented programming, as we practice it, we write
from ComponentType to Designator
to express the generation of code for the classes ``between'' ComponentType and Designator in a given class dictionary graph, such as the one in Fig. 1.
Zeus has the interesting feature that it is a compact notation to describe several intents: structural, functional and layout intent. All are expressed in two tiers and the structural and functional intent were combined since a Zeus (and Hades) component essentially describes the functionality of one clock cycle. The layout intent expresses relative ordering of hardware components and we felt that this was important to achieve successful silicon compilation at that time. Our interest in compact notations which describe several intents continues to be strong. In our work on object-oriented design and programming, we use a notation which allows you to describe two intents: class and syntax intent. A class dictionary, such as the one in Fig. 1 defines both a class structure in some programming language (e.g., C++) and a grammar for defining a language.
A comparison of Zeus with other approaches is given in [GHL85].
It was a pleasure to work in the VLSI CAD area and to develop Zeus. I would like to acknowledge support from both the American and Swiss National Science Foundation, Princeton University, The Swiss Federal Institute of Technology, MIT and the biggest investment was made by GTE Laboratories.
This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 2 to-ieee.tex.
The translation was initiated by Karl Lieberherr on 2/18/1998