Design using Standard Description Languages:Types

Types

Each of the objects signals, constants, or variables has a specific type assigned in VHDL. Object types inform us about the characteristics of data flow and provide a specification telling how the data is to be processed. VHDL is said to be a strongly type oriented language. Apart from the already avail- able standard types, one’s own type definitions can be added easily. Looking at existing types, new definitions (so called sub-types) can be derived. Table 4.6 mentions the possible type classes and the tables 4.7 up to 4.15 describe pre-defined standard types of the package STANDARD as well as the operators applicable to these types.

Design using Standard Description Languages-0145

Design using Standard Description Languages-0146

Type Class Enumerator

Enumerators are versatile and provide a readable and clear VHDL text. The type definition of an ENUMERATOR assigns a symbolic name to all values in a list. Very often the signal represent- ing the state of a state machine is an enumerator. This has the advantage that the symbolic names of the states are visible during simulation. They will not be replaced by tangled bit combinations. Apart from reserved words, every name is legal in VHDL.

Design using Standard Description Languages-0148This type owns four literals: Red, Green, Yellow, Blue. Corresponding to the position in the list each literal receives a number assigned, starting with position 0. Looking at the number of this position, a comparison using the operators (=, /=, <, <=, >, >=) is possible. In addition to the symbolic names the list of an enumerator can contain character literals as well. Character literals are single letters, being part of the ASCII character set, framed by apostrophes:

Design using Standard Description Languages-0149

The advantage of character literals is the way they describe arrays as a string. They are suitable for designing a logic system containing single signals and bus signals.

Design using Standard Description Languages-0150

The physical types are a speciality of VHDL. A unit must be specified here. Physical types not only define the legal range of values, but also identify the absolute unit and provide a conversion table for deducted units. Because of the conversion table, units in expressions can be mixed, e.g., the addition of minutes and nanoseconds.

Design using Standard Description Languages-0151

Physical types have no meaning for the synthesis, but they are meaningful for the design of simulation environments (test bench, section 4.10). There are, e.g., objects of the type TIME, responsible for the correct progress of simulation.

Type Class Record

A record is similar to the structure of the program- ming language C, a collection of elements into one object. The only operators usable on records are tests on equality or non-equality (=, /=). Elements are compared on a one by one basis, followed by a boolean AND operation performed on all prior results.

Design using Standard Description Languages-0152

first element has the index 7, the second element the index 6, and the last element has the index 0. This descending sequence of indices corresponds

Additional forms of assignments to records or to elements in records are:

Design using Standard Description Languages-0153

Type Class Array

An array is a combination of elements of the same type. Individual elements are addressed using an index, which can be of the type integer or enumerator. Before a signal can be declared to be of the type array it must be specified which elements the array can take and how the indexing of the array is to be done (index type and range of value). There are two different kinds of type definitions:

• Constrained: The number of array elements is already specified in the type definition. All signals and variables of that type have the same size.

Design using Standard Description Languages-0154• Unconstrained: The size of an array is not specified in the type definition. The fill-in ’RANGE <>’ permits specification at a later point of time, e.g., when declaring the signal. Only the index type is specified, e.g., NATURAL. Be- cause of that a family of similar arrays, varying only in size, can be defined; this provides a universal use of the type array.

Design using Standard Description Languages-0155

to the usual presentation of bus signals. The index of an addressed bit is equal to the power, when calculating its binary value. The access to an individual element can be done either by a static index, e.g.,

Design using Standard Description Languages-0156

Two-dimensional Arrays

The following example shows the structure of two- dimensional arrays. The first type definition declares a one-dimensional array (rom_data) in the first instance. The second type definition takes four members and combines them to an ‘array made of arrays’. A suitable application of two-dimensional arrays would be the structuring of small storage blocks, e.g., RAM or ROM.

Design using Standard Description Languages-0157

Access

Access types are comparable to addresses or point- ers in other programming languages. Being not synthesizable and most probably being a data type used very seldom, they allow the detection of complex functions. A typical application of pointers can be seen when modelling FIFOs (first in, first out) or building chained lists within a simulation environment (test bench, section 4.10).

Furthermore, access types are only legal for vari- ables within a process.

Dealing with access types, two pre-defined func- tions are prominent: NEW and DEALLOCATE. The function NEW allocates storage for the size of the object and returns a pointer to the memory area. From that moment the object can be accessed using the pointer. If the object is not be needed during simulation, the allocated memory can be returned. To achieve that the function DEALLO- CATE deletes the object addressed by the pointer and returns the memory to the system. Section 4.7.8 shows an example of a chained list using access types.

Type Class File

File objects allow a direct access to the file system. Within a VHDL description files are very suitable for reading or storing sequences of test vectors (section 4.10) or to initialize blocks of storage, such as RAM or ROM. The use of files provides a high degree of flexibility in a VHDL descrip- tion, because files can be modified or exchanged without a new compilation step. The interfaces to files are procedures for transferring data (read and write) or functions to detect the end of a file (end of file).

The first step in setting up a file object is the defini- tion of its content. Possible entries are scalar types, records, or arrays. The second step generates an object, links the object and the file name (including path information), and specifies the direction of the data transfer (IN or OUT).

Design using Standard Description Languages-0159

Whereas a file according to the VHDL87 standard has to be explicitly opened during the elaboration phase, the VHDL93 standard provides procedures solely for opening and closing files. Hence these two versions of the standard are not compatible. A second form of the procedure ‘file open’ additionally returns a status to indicate the successful opening of a file (OPEN_OK) or notifies when there is a problem:

• STATUS_ERROR: File is already in use;

• NAME_ERROR: File does not exist;

• MODE_ERROR: File can not be opened using this mode.

To read, write, or close a file the corresponding procedure is called with the name of the file object. Prior to each read operation a test for end of file should be carried out.

Design using Standard Description Languages-0160

Design using Standard Description Languages-0161Design using Standard Description Languages-0162

Comments

Post a Comment

Popular posts from this blog

Design using Standard Description Languages:The simulation model in VHDL

Image
The simulation model in VHDL After a look at concurrent signal statements in chapter 4.3, basic mechanisms of the language can be discussed in detail. Originally the language VHDL was developed for simulation only. A dis- cussion about the theory of operation of a VHDL simulator helps to understand VHDL modelling and simplifies the choice of suitable language constructs to describe hardware constructs. The topic simulation model has an emphasis on: • Driving signals; • Delta delay mechanisms; • Modelling of delay times. Drivers Every concurrent statement, including processes, causes an event responsible for the progress of a signal. Within the simulator there is a list containing points in time to schedule signal events. Such an entry in that list is called a transaction. This list is the basic information for scheduling signal values during simulation (fig. 4.22). A change of a signal value caused by an entry in that list, is called an event in that signal. If a new entry is the ...
Read more

EDA Tutorial:Place and Route in a Standard Cell Design Style

Image
Place and Route in a Standard Cell Design Style In the design of FPGA circuits, after the synthesis of the EDIF files, the compiling and programming of the FPGA device, everything is defined and the component is completely configured. With ASIC designs, there are two possible scenarios: • Delivery of the design to an ASIC provider in the form of a so called simulate d netlist (EDIF); • Place and Route of the design with one’s own tools, verification of the results, and delivering of the design as a geometrically exact GD S II File . For similar designs in industry the netlist version is frequently chosen, but here the second scenario which includes the bac k en d processing , the phys- ical design, will be demonstrated in more detail. This needs special software tools, which allow the mask design at the lowest geometry level, and tools for checking the generated geometries against the predefined design rules ( Desig n Rule Che c k , DRC ), and allow one to extract parasitics and el...
Read more

Overview of EDA Tools and Design Concepts:Major Classes of EDA Tools.

Image
Introduction In the next few chapters, we will discuss specific kinds of EDA tools. In this chapter, we provide an overview of the EDA tool world. There are several EDA-related concepts which are helpful to understand the EDA tools and the design process. These include: Design Views Hierarchy Design Chip Architecture Methodology Design Flow Tool Suites Nora of Sandbox, Inc., is meeting again with Andrea, an ASIC engineer who works for Fabless Design, Inc. Nora has asked to learn more about the use of EDA tools. Let us listen in on their discussion. Nora: Hello again, Andrea. Did you like the party the other evening? Andrea: Yes, very much. Sandbox has both outstanding tools and great parties. Nora: We seem to be continually developing new tools. I am a little unclear why that is. Tool Improvements Andrea: That's because each generation of semiconductor process improvements shrinks the size of the transistors and wires. The number of transistors and wires...
Read more