Maude / VHDL similarities

[Alexis Read]

I haven't used VHDL extensively so people feel free to correct me...
VHDL I believe was based on ADA, which is maude's parent too. It is a
procedural language, but if you look at the basic framework you can see
the similarities:

On the most basic level, the description of a logical block is split into
two parts, the ENTITY and the ARCHITECTURE.

The ENTITY declaration is much like a declaration of a function in C++. In
this case, the ENTITY decalaration tells us that we have a device called
compare8. It does not tells us how compare8 actually functions... this is
left to the ARCHITECTURE section. For example if I were to be describing a
8-bit comparator, I would need two 8-bit inputs and a 1-bit output:

1 ENTITY compare8 IS PORT(
2     x, y:  IN std_logic_vector(7 DOWNTO 0) ;
3     res: OUT std_logic );
4 END compare8;

The first line tells us what we are describing, in this case the name of
the entity is compare8. The word PORT followed by a parenthesis tells us
that the following information describes the I/O behavior of this entity.
Line 2 begins the actual description of our inputs. In this case we are
using x and y as inputs and declaring them to be vectors of 8-bits with
bit 7 being the most significant and bit 0 the least. Line three describes
our output. For a comparison, we only need to know if the values are
equal, or not equal. We therefore only need a single bit as the output.
The final line tells us that we are at the end of the description for the
entity called compare8.

The ARCHITECTURE statement is like the actual function in C++, it
describes the logic behind the entity. For the case of the comparator, we
want to return a 1 if the two values are equal and a 0 if they are not:

1 ARCHITECTURE struct OF compare8 IS
2 BEGIN
3     res <= '1' WHEN (x = y) ELSE '0';
4 END struct;

The first line tells us that the architecture name of the entity compare8
is struct. This is important because an entity may have several different
architectures, perhaps with various levels of detail in their
descriptions. For our purposes, however, we will usually only write one
architecture. The BEGIN statement tells us that you are beginning your
description of the logic. In some cases you may declare types beforehand
in which case it would not be the first statement, but we will touch upon
that later in this tutorial. Line 3 is the meat of this section, and reads
just as it is written: the value 1 will be placed in res when the values
of x and y are equal, otherwise it will return a 0. The <= is an
assignment operator and can only be used when writing to an output value,
variables use a different assignment operator that will be discussed
later. The final line tells us that we have completed our description of
the architecture struct.

The complete description of this comparator would also include a couple of
lines to import a library.
Comparing this to maude, we can see that the entity statement corresponds
closely to the operator defs in maude, and the architecture statement with
the equational representation. The library can be seen as an imported
module with similar defs etc.

To link entities we merely connect their I/O registers which is one way of
passing parameters between the components, and it allows the whole system
to do things concurrently:

If we introduce three new concepts: TYPE, VARIABLE, and CASE: A SIGNAL is
analogous to a physical wire while a variable is only visible inside a
process, function, or procedure. A variable is typically used as index
holders in loops, but can also be used in a similar fashion to a signal.
The TYPE definition allows you create new types of variables just as it
wold in any other programming language. Since VHDL is a strongly typed
language, there are a multitude of types available including integer,
array, floating, record, and composite just to name a few. From these
types the user can create new types as necessary using the TYPE statement.
The last concept introduced here is the CASE statement. The CASE statement
is a block of sequential statements that allow the user to dictate the
behavior of a part by looking at an input and using the input as a key to
determine which path to follow, e.g. Every time a signal changes states,
an event occurs. This can be modelled in maude in a similar fashion to the
maude1 petri net example.

Moreover, this is a description of a hardware entity, and it describes the
BEHAVIOUR of the chip, not neccesarily the internal methodology. The
internal methods can be modelled too, which brings us nicely to the need
for lazy evaluation (as the simlulations get too complex) and the need to
prove properties of 'black box' representations of things, some of which
are not quite as nice as this example and use variables external to our
model to determine their behavior, e.g. a thermo-sensor which changes its
output throughout the day - time acts as the hidden/external variable.

Alexis.