VHDL Tutorial

Syntax descriptions in VHDL

Syntax Descriptions


In thethis tutorial, we describe rules of syntax using a notation based on the Extended Backus-Naur Form (EBNF).  The idea behind EBNF is to divide the language into syn- tactic categories For each syntactic category  we write a rule  that describes how to build  a VHDL  clause  of that category by combining  lexical  elements and  clauses  of other categories.   We write a rule with the syntactic category we are defining on the

left of a “” sign (read as “is defined to be”), and a pattern on the right.  The simplest kind of pattern is a collection of items in sequence, for example:


Want To have highly paid VLSI jobs ?? then you may contact at

Contact : webmaster@freehost7com

variable_assignment target := expression ;


This  rule  indicates  that  a  VHDL  clause  in  the  category  “variable_assignment”  is defined to be a clause in the category “target”, followed by the symbol “:=”, followed by a clause in the category “expression”, followed by the symbol “;”.

The next kind of rule to consider is one that allows for an optional component in

a clause.   We indicate the optional part by enclosing it between the symbols “[” and

“]”.   For example:


function_call name [ ( association_list ) ]


This indicates that a function call consists of a name that may be followed by an as- sociation list in parentheses.   Note the use of the outline symbols for writing the pat- tern in the rule, as opposed to the normal solid symbols that are lexical elements of VHDL.

In many rules, we need to specify that a clause is optional, but if present, it may be repeated as many times as needed For example, in this rule:



process is

{ process_declarative_item }


{ sequential_statement }

end process ;


the curly braces specify that a process may include zero or more process declarative items and zero or more sequential statements.  A case that arises frequently in the rules

of VHDL is a pattern consisting of some category followed by zero or more repetitions

of that category.  In this case, we use dots within the braces to represent the repeated category, rather than writing it out again in full.   For example, the rule



case expression is


{ … }

end case ;


indicates  that  a  case  statement  must  contain  at  least  one  case  statement  alternative, but may contain an arbitrary number of additional case statement alternatives as re- quired.   If  there  is  a  sequence  of  categories  and  symbols  preceding  the  braces,  the dots represent only  the  last  element of the sequence.   Thus,  in  the  example  above, the dots represent only the case statement alternative, not the sequence “case expres- sion is case_statement_alternative”.

We also use the dots notation where a list of one or more repetitions of a clause

is required, but some delimiter symbol is needed between repetitions For example, the rule

identifier_list identifier { , … }


specifies that an identifier list consists of one or more identifiers, and that if there is more than one, they are separated by comma symbols.  Note that the dots always rep- resent a repetition of the category immediately preceding the left brace symbol.  Thus,

in the above rule, it is the identifier that is repeated, not the comma.

Many syntax rules allow a category to be composed of one of a number of alter- natives, specified using the “I” symbol.   For example, the rule


mode in I out I inout


specifies that the category “mod can be formed from a clause consisting of one of the reserved words chosen from the alternatives listed.

The final notation we use in our syntax rules is parenthetic grouping, using the symbols  “(“  and  “)” These  simply  serve  to  group  part  of  a  pattern,  so  that  we  can avoid any ambiguity that might otherwise arise.  For example, the inclusion of paren- theses in the rule


term factor { ( * I / I mod I rem ) factor }


makes it clear that a factor may be followed by one of the operator symbols, and then another factor.

This  EBNF  notation  is  sufficient  to  describe  the  complete  grammar  of  VHDL. However, there are often further constraints on a VHDL description that relate to the meaning of the constructs used.  To express such constraints, many rules include ad- ditional information relating to the meaning of a language feature For example, the rule shown above describing how a function call is formed is augmented thus:


function_call function_name [ ( parameter_association_list ) ]


The italicized prefix on a syntactic category in the pattern simply provides semantic information.   This rule indicates that the name cannot be just any name, but must be the  name  of  a  function.   Similarly,  the  association  list  must  describe  the  parameters supplied to the function.

In this tutorial, we will introduce each new feature of VHDL by describing its syn- tax using EBNF rules, and then we will describe the meaning and use of the feature through examples.  In many cases, we will start with a simplified version of the syntax

to make the description easier to learn and come back to the full details in a later section.