1. Premise

We will report the design, implementation, and experience of VLSI modelling language, Sakura.

There are several bottom line considerations that went into the design of this language. We are now in the middle of designing VLSI computer system, and we needed a modelling language for our design. Since one of the author is also working on the VLSI computer project, we do not want to spend much time in the implementation. On the other hand the widely available hardware modelling language, ISP, is based on programming languages of twenty years ago and much to be desired. We also considered that the clean separation of functionality specification and structural specification to be very important.

We also do not want to teach a new system description language and furthermore we do not want to create various utilities such as binder and debugger so we decided to create a language by putting a thin layer on top of Mesa.

Sakura compiler transforms them into Mesa programs. We tried to make the syntax of the generated Mesa programs to be very close to the original Sakura programs. New features that required complex translation are translated to procedure calls of a Sakura runtime system.

The advantages we gained by doing this way are:

1.The Sakura translator was very easy to write. We modified Mesa pretty printer in about one month and created Sakura to Mesa translator.

2.Various utility programs such as binder, debugger, and pretty printer are readily available.

3.Since it is not a simulator, but rather a compiled system, it is easy to connect to other simulators.

4.The semantics of Sakura can be easily described to other people since they can be described by equivalent Mesa programs. This is, however, not sufficient for rigorous treatment. We are working on a formal semantics.

5.Mesa is a very rich language. All the features of Mesa are available in describing the functionality -- features that are paritcularly useful that are not available in ISP are modularity, parallelism, record and abstract data structures, exception. We, however, added nondeterminism.

2. Features

If you look at VLSI circuits, they can be considered as consisting of several cells. Then these cells are in turn built out of subcells and one can repeat this hierarchy until one arrives at transistors.

One way to describe the structure of this chip is to say that it consists of several cells connected together. Then each cell is created by connecting subcells together. We cll this the structural description of the chip.

In order to understand the behavior of this chip, one has to go down to the lowest level elements -- in most of the case transitors.

One problem with this approach is that the functionality of the chip cannot be understood until one specifies the structure of the entire chip. Therefore, one cannot debut the design before actually implements the system.

Even if one finished the implementation, the simulation of the chip depends on the simulator that only understnads the transistors and this may be a slow process.

Another problem is that there is nothing you have that you can compare your results against.

So optimally we have a chip A, and a network of cells that implents the chip. We will write the functionality of the chip as well as the functionality of each cell. Then the behavior of the both should be the same. We can actually compare both to debug the system.

3. Protocol

Another issue of complex VLSI computer systems is that the way they exchange signals, or protocol, is rather specified in a complex manner.

Therefore, in many current computer systems, the specifications of protocols are very important.

These protocols are usually not checked by chips. So the system may break down if the systems uses wrong protocols.

So we would like to put these protocol checking in some part of our description.

We would test these specifications by running the system with some test data. At these times signals are checked against protocols.

One can put these tests inside the functional specifications, but it will quite obscure the protocols.