language is irrelevant: It's what you do with it that counts, The

International Journal of Electrical Engineering Education, Oct 2001 by Brown, A D

Abstract This paper presents a brief comment on the role of hardware description languages (HDLs) in the design process, and attempts to look past the semantics of an HDL and identify the semantic constructs that must be supported if a language is to be of practical use. Some brief remarks on the capabilities of state-of-the-art optimisation techniques are also presented.

Keywords electronic design automation; hardware description languages

If you go to a conference on EDA (Electronic Design Automation) you will meet Language Evangelists. I'm sure other areas and disciplines have their evangelists, but I don't go to their conferences, so I can't comment. In this paper, I will offer a few brief perspectives on issues surrounding languages in the electronic systems industry. Firstly, a quick look at the `design food chain'-- languages here are a semantic glue between the steps, nothing more. A language possesses no intrinsic value. Secondly, an equally brief look at behavioural synthesis, or architectural exploration, as it is becoming known. The semantics of a description language need very careful definition if they are to support useful unambiguous behavioural definition whilst not impeding optimisation.

Perspectives

This article discusses integrated digital systems. Analogue and mixed signal systems are the same, only much, much worse.

The food chain

Humans are extremely good at designing things. For a sufficiently small problem, a competent, experienced human designer will usually produce a solution that is better than one produced by a computer, irrespective of the complexity. An individual transistor can be characterised by however many parameters you have the patience for. A human designing, say, a long-tailed pair will know what is important, and what can be neglected, and will intuitively ignore the irrelevant bits and produce a solution. A computer cannot make these value judgements, and therein lies both the strength and the weakness of automation. The computer looks at a transistor model with 35 parameters and uses this as a definition of the device - there is no alternative. A human looks at the model and uses it as a description. Humans, however, become overwhelmed by size. A human designing a 100000 gate circuit will make mistakes and will overlook parameter interactions and dominations.

The design food chain is shown in Fig. 1. Ultimately, everything is made from electronic devices, which are fabricated on silicon using photolithography. IC masks are effectively sets of polygons, which are themselves described by a language (for example, GDSII). The devices are interconnected to form gates, and usually these are sufficiently simple for this to be done manually. The behaviour of the gate (what does it do when we build it?) can be established using continuous circuit simulation.

Gates are assembled to make cells. Cells occupy a wide part of the spectrum of complexity; a two-bit AND-OR-INVERT is a cell, and so is a 64-bit floating point complex arithmetic ALU. The internal cell layout problem is just about tractable manually, and event based logic simulators quite capable of demonstrating functionality. (Note there is a big difference between demonstrating functionality and proving correctness. The only way of achieving the latter with a simulator is by exhaustive simulation of all possible inputs; this is obviously feasible for the two bit AND-OR-INVERT, but becomes less so as the size of the cell increases.) Finally, cells are assembled to make complete systems, and here the size issue usually means design automation is a necessity, not a luxury.

Languages as glue

A language that describes a gate in terms of its constituent devices needs to capture the connectivity of the devices, and the parameter sets associated with each device instance. (Parasitic effects can be supported by lumped equivalent devices and models.) Aside from a few syntactic details, there is no concept of order in a description. In the jargon, a netlist is an example of an imperative description. An example is a SPICE circuit. Defining cells in terms of gates moves to a slightly higher level of signal abstraction, but the underlying concept - that the language describes the structure or connectivity - remains the same. The structure implies (defines) the functionality. HILO or a subset of VHDL can do this adequately.

Defining systems in terms of cells widens the semantic scope. It is possible, of course, to define a complete system in terms of how it is assembled. The functionality falls out of the structure and the system definition is complete. Often, however, we do not have a structure, but we do have a behaviour. We know what we want the system to do, and we want to be able to describe and communicate this before the structure is defined. Indeed, we don't want to define the structure. We want the functionality, and don't usually care where it comes from.

Constraints

When we arrive at the (current) top of the design food chain, then, the language we use needs to be able to carry the semantics of both structure and functionality, independently. VHDL, for example, can do this. Is anything more needed? Unfortunately, yes. An extra layer - constraints - needs to be supported. We need to be able to say things like "I need this functionality, subject to the whole thing dissipating less than 1 mW, using as little silicon as possible, and there must not be more than 10 ms between this 'go' signal and that 'ready' line. I don't care how it's done."