Apostila de VHDL

VHDL Notas de aula (semestre 98.
1)
David Deharbe Departamento de Informatica e Matematica Aplicada Universidade Federal do Rio Grande do Norte 15 de Abril de 1998
Indice
1 Introduc~ ao
1.1 Historico . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 O contexto . . . . . . . . . . . . . . . . . . . 1.1.2 A historia de VHDL . . . . . . . . . . . . . . 1.2 O que e uma linguagem de descric~ ao de hardware ? . 1.2.1 O que e VHDL ? . . . . . . . . . . . . . . . . 1.3 Introduc~ ao aos princ pios de concepc~ ao de VHDL . . 1.4 Exemplos de descric~ oes VHDL . . . . . . . . . . . . 1.5 Convenc~ oes lexicogra cas . . . . . . . . . . . . . . . 1.5.1 Identi cadores . . . . . . . . . . . . . . . . . 1.5.2 Numeros . . . . . . . . . . . . . . . . . . . . . 1.5.3 Carateres . . . . . . . . . . . . . . . . . . . . 1.5.4 Cadeias de carateres . . . . . . . . . . . . . . 1.5.5 Cadeias de bits . . . . . . . . . . . . . . . . . 1.5.6 Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 8 8 9 9 9 9 10 10 11 11 11
2 Organizac~ ao e utilizac~ ao de descric~ oes VHDL
2.1 Unidades de concepc~ ao . . . . . . . . . . . . . . . . . . 2.2 Bibliotecas de concepc~ ao . . . . . . . . . . . . . . . . . 2.3 Clausula de contexto . . . . . . . . . . . . . . . . . . . 2.3.1 Escopo . . . . . . . . . . . . . . . . . . . . . . . 2.4 Elementos de descric~ ao estrutural . . . . . . . . . . . . 2.4.1 Declarac~ ao de componentes . . . . . . . . . . . 2.4.2 Instanciac~ ao de componentes . . . . . . . . . . 2.4.3 Con gurac~ ao de componente . . . . . . . . . . 2.4.4 Declarac~ ao de con gurac~ ao . . . . . . . . . . . 2.4.5 Instanciac~ ao direta de entidades de concepc~ ao . 3.1 Introduc~ ao . . . . . . . . . . . . . . . . . . . 3.2 Elementos basicos do modelo de simulac~ ao . 3.2.1 Sinais . . . . . . . . . . . . . . . . . 3.2.2 Processos . . . . . . . . . . . . . . . 3.3 O algoritmo de simulac~ ao . . . . . . . . . . 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13 14 15 16 16 17 17 17 19 20 21 21 21 22 27
3 Processos, sinais e simulac~ ao
21
4 3.3.1 3.3.2 3.3.3 3.3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 5.1 5.2 5.3 5.4 Mais noc~ oes ligadas a sinais A fase de inicializac~ ao . . . O ciclo de simulac~ ao . . . . Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INDICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 28 28 29
4 Programac~ ao sequencial
Introduc~ ao . . . . . . . . . . . . . Processos . . . . . . . . . . . . . Rotinas . . . . . . . . . . . . . . Instruc~ ao de asserc~ ao . . . . . . . Instruc~ ao de relatorio . . . . . . Chamada de procedimento . . . . Instruc~ ao condicional de escolha Instruc~ ao de laco . . . . . . . . . Instruc~ ao proximo . . . . . . . . Instruc~ ao de sa da . . . . . . . . Instruc~ ao de retorno . . . . . . . Instruc~ ao nula . . . . . . . . . . .
33
33 34 34 35 36 36 37 37 37 38 38 38 39 39 39 40 40 42 44 46 46 47 47 49 49 50 50 50 51 52 52 53 53 54
5 Programac~ ao concorrente
5.5 5.6 5.7 5.8
Introduc~ ao . . . . . . . . . . . . . . . . . . . . . . . . Instruc~ ao de processo . . . . . . . . . . . . . . . . . . Instruc~ ao de bloco . . . . . . . . . . . . . . . . . . . Instruc~ ao concorrente de atribuic~ ao de sinal . . . . . 5.4.1 Atribuic~ ao condicional de sinal . . . . . . . . 5.4.2 Atribuic~ ao selecionada de sinal . . . . . . . . 5.4.3 Atribuic~ oes guardadas . . . . . . . . . . . . . Instruc~ ao concorrente de chamada de procedimento . Instruc~ ao concorrente de asserc~ ao . . . . . . . . . . . Instruc~ ao de instanciac~ ao de componente . . . . . . Instruc~ ao de gerac~ ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6 O sistema de tipos
6.1 Introduc~ ao . . . . . . . . . . . . 6.2 Tipos escalares . . . . . . . . . 6.2.1 Tipos enumerados . . . 6.2.2 Tipos inteiros . . . . . . 6.2.3 Tipos f sicos . . . . . . . 6.2.4 Tipos v rgula utuante . 6.3 Tipos compostos . . . . . . . . 6.3.1 Tipos arranjos . . . . . 6.3.2 Tipos registros . . . . . 6.4 Tipos acesso . . . . . . . . . . . 6.5 Tipos arquivo (VHDL-93) . . .
49
INDICE
5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Gramatica da linguagem VHDL-93

A.1 Design entities . . . . . . . . . A.2 Subprograms and Packages . . A.3 Types . . . . . . . . . . . . . . A.4 Declarations . . . . . . . . . . . A.5 Speci cations . . . . . . . . . . A.6 Names . . . . . . . . . . . . . . A.7 Expressions . . . . . . . . . . . A.8 Sequential statements . . . . . A.9 Concurrent statements . . . . . A.10 Scope and visibility . . . . . . . A.11 Design units and their analysis A.12 Lexical elements . . . . . . . .
59
59 61 63 65 68 70 70 72 75 78 78 79
INDICE
1. Introduc~ ao
1.1 Historico
1.1.1 O contexto
As primeiras linguagens de descric~ ao de hardware foram desenvolvidas no nal dos anos 60, como alternativa as linguagens de programac~ ao para descrever e simular dispositivos hardware. Durante dez anos, numeros linguagens foram desenvolvidas com sintaxe e sem^ anticas incompativeis, permitindo descric~ oes a diferentes n veis de modelizac~ ao. A partir de 73, um primeiro esforco de padronizac~ ao foi iniciado: o projeto CONLAN (CONsensus LANguage), cujos objetivos eram de de nir uma formalmente uma linguagem multi-n veis com uma sintaxe unica e uma sem^ antica n~ ao ambigua. O relatorio nal desse projeto, composto em maioria por acad^ emicos, foi publicado em janeiro de 1983. Em paralelo, na area de software, a necessidade de portabilidade entre varias plataformas resultou num projeto de desenvolvimento de uma linguagem de programac~ ao, nanciado pelo Ministerio da Defesa dos Estados Unidos (DoD). Como resultado desse esforco, em 1983, foi publicada a linguagem ADA.
1.1.2 A historia de VHDL

O DoD iniciou em marco de 1983 o programa VHSIC (Very High Speed Integrated Circuits ) para meliorar a tecnologia de concepc~ ao, engenharia e construc~ ao nos Estados Unidos. Foi de nido um conjunto de requisitos e um contrato assinado em 1983 com um consorcio composto de IBM, Intermetrics e Texas Instruments. Depois de varias avaliac~ oes e revis~ oes, em 1986, a Intermetrics developou um compilador inicial assim como um simulador. Nesse mesmo ano, foi criado um grupo de padronizac~ ao da IEEE para VHDL, que passo a entrar no dom nio publico. Em dezembro de 1997 foi publicado o manual de refer^ encia da linguagem. Conforme aos estatutos da IEEE, um novo processo de padronizac~ ao recomecou em 1991, tendo como objetivo a colecta e analise de requisitos, a de nic~ ao dos objetivos, e a especi cac~ ao das modi cac~ oes a linguagem. Em 1992 e 1993, as modi cac~ oes propostas foram avaliadas, e votadas. Um novo padr~ ao, conhecido como VHDL-93, foi publicado em 1993. Em paralelo, varios grupos de interesse se formaram para de nir extens~ oes a linguagem, como um subconjunto de s ntese de alto-n vel, a simulac~ ao em modo mixto analogo e digital, a veri cac~ ao formal. 7
Cap tulo 1. Introduc~ ao
Os primeiros software desenvolvidos foram comercializados a partir de 1988. Hoje, existe varios compiladores e simuladores, s ntetizadores, etc. VHDL faz parte do processo de concepc~ ao de circuitos integrados em um grande numero de centros e e um dos dois linguagens de descric~ ao de hardware dominantes no mercado mundial com a linguagem Verilog HDL.
1.2 O que e uma linguagem de descric~ ao de hardware ?

A descric~ ao de um sistema digital permite de nir um modelo de um pedaco de hardware. O modelo, escrito na linguagem VHDL, descreve o que o sistema faz e como. A descric~ ao VHDL e um modelo do sistema hardware. Essa descric~ ao pode ser executada por um software chamado de simulador. O simulador roda uma descric~ ao VHDL e calcula os valores das saidas do sistema modelizado em func~ ao de uma sequ^ encia de valores de entradas aplicadas ao decorrer da simulac~ ao. O simulador estimula o comportamento din^ amico de um modelo VHDL. Se o modelo VHDL corresponde com precis~ ao a func~ ao do hardware modelizado, ent~ ao o comportamento das entradas e saidas da simulac~ ao do modelo deve corresponder o comportamento das entradas e saidas do hardware. Uma linguagem de descric~ ao de hardware e um quadro preto de alto-tecnologia para a concepc~ ao de sistemas digitais. Num projeto de concepc~ ao, varias etapas de modelizac~ ao, simulac~ ao, correc~ ao ou precis~ ao s~ ao necessarias para chegar a um modelo su cientemente detalhado para poder servir de especi cac~ ao da implementac~ ao hardware e como documentac~ ao para ajudar a comunicac~ ao do projeto para outros grupos e organizac~ oes.
1.2.1 O que e VHDL ?

VHDL signi ca VHSIC Hardware Description Language, e VHSIC e Very High Speed Integrated Circuits. Portanto, VHDL for concebido para desenvolver circuitos integrados. Na realidade, ele pode ser usado para descrever varios tipos de sistema: uma rede de computadores, um circuito integrado, ou simplesmente uma simples porta logica. VHDL e portanto uma linguagem multi-n veis e abrange todos os n veis de descric~ ao discreta. VHDL n~ ao e pratico para descric~ oes: ao n vel eletrico: n~ ao e poss vel descrever as equac~ oes diferenciais necessarias a de nic~ ao de um transistor. ao n vel sistema: e imposs vel descrever a criac~ ao e a destruc~ ao din^ amica de processos software.
1.3. Introduc~ ao aos princ pios de concepc~ ao de VHDL
1.3 Introduc~ ao aos princ pios de concepc~ ao de VHDL

Para desenvolver sistemas em VHDL, e importante entender quais s~ ao os princ pios de concepc~ ao em VHDL. Podemos destacar duas fases principais: a modelisac~ ao e a simulac~ ao. Na fase de modelisac~ ao, o usuario cria arquivos textos que contem as descric~ oes os diferentes componentes do sistema. Esses arquivos s~ ao ent~ ao compilados por um compilador VHDL que faz varias veri cac~ oes e gera arquivos objetos. Esses arquivos objetos resultados dessa compilac~ ao s~ ao armazenados em bibliotecas de componentes. Na fase de simulac~ ao, o usuario chama o simulador. No simulador, o usuario escolhe um componente de uma de suas bibliotecas. A esse momento, e elaborado um modelo de simulac~ ao, que e executado pelo simulador.
O modelo de simulac~ ao VHDL

O modelo de simulac~ ao VHDL e composto de varios processos. Cada processo VHDL executa um programa sequ^ encial. Como num linguagem de programac~ ao classico, esses programas sequ^ enciais podem ser compostos de variaveis locais, de instruc~ oes de atribuic~ ao, de escolha, de loop, e chamar func~ oes e procedimentos. Os processos comunicam entre com sinais e se sincronizam com instruc~ oes de espera.
1.4 Exemplos de descric~ oes VHDL 1.5 Convenc~ oes lexicogra cas
Identi cadores s~ ao palavras chaves ou nomes de nidos pelo autor. Um identi cador e composto de um numero qualquer de letras, digitos e sublinhados e deve comecar com uma letra. Sublinhados s~ ao signi cativos, portanto os identi cadores XOR_2 e XOR2 s~ ao diferentes. Maiusculos e minusculos n~ ao s~ ao diferenciados, portanto Xor e XOR s~ ao o mesmo identi cador. Exemplos:
COUNT VHSIC X X1 c_out PageCount FFT Decoder STORE_NEXT_ITEM
1.5.1 Identi cadores
VHDL 93 O novo padr~ ao VHDL de ne a noc~ ao de identi cador basico (basic
identi er ) como foi de nido no paragrafo precedente, e o identi cador extendido (extended identi er ). Um identi cador extendido e uma sequ^ encia de carateres gra cos delimitada por duas barras invertidas \. Um caratere gra co pode ser
10
qualquer caratere do teclado, incluido letras acentuadas. No caso de identi cadores extendidos, maiusculas e minusculas s~ ao diferenciadas. Exemplos
\BUS\ \a\\b\ VHDL \bus\
\VHDL\
\vhdl\
{ Dois identi cadores diferentes, { nenhum deles e a palavra chave bus { Um identi cador com 3 carateres { Tres identi cadores distintos.
1.5.2 Numeros
Numeros podem ser notados em notac~ ao decimal ou em uma base qualquer entre 2 (binario) e 16 (hexadecimal). Se o literal tem um ponto, ele representa um numero real, sen~ ao um numero inteiro. Literais decimais s~ ao de nidos por as regras seguintes: literal decimal ::= inteiro . inteiro] expoente] inteiro ::= algarismo f sublinhado ] algarismo g expoente ::= E + j - ] inteiro Exemplos:
0 0.0 1 0.5 123_456_789 2.718_28 987E6 12.4E-9
{ literais inteiros { literais reais
Literais com base s~ ao de nidos por as regras seguintes: literal em base ::= base # inteiro em base . inteiro em base ] # expoente base ::= inteiro inteiro em base ::= algarismo ext f underline ] g algarismo ext g algarismo ext ::= algarismo | letra Exemplos:
2#1100_0100# 16#C4# 4#301#E1 2#1.1111_1111_1111#E+11 16#F.FF#E2
{ o inteiro 196 { o real 4095.0
1.5.3 Carateres
Um literal caratere e composto de um caratere gra co entre dois carateres apostrofe. Exemplos:
'A' ''' ' ' 'e' \= \verb'*'
1.5. Convenc~ oes lexicogra cas
11
1.5.4 Cadeias de carateres
Um literal cadeia de carateres e composto por uma sequ^ encia, eventualmente vazia, entre aspas. Exemplos: "Tempo de setup e curto demais" { uma messagem de erro "" { uma cadeia de carateres vazia " " "A" """" { tr^ es cadeias de comprimento 1 Uma cadeia de carateres n~ ao pode ultrapassar uma linha. Portanto, para escrever grande cadeias em varias linhas, precisa usar o operador de concatenac~ ao &:
"Primeira parte de uma sequ^ encia de carateres " & "qui continua na linha seguinte"
Cadeias de bits s~ ao compostas por uma sequ^ encia de algarismos extendidos, possivelmente vazia, entre aspas e precedida de da especi cac~ ao da base. ao da base " valor bit ] " cadeia de bits ::= especi cac~ valor bit ::= algarismo ext f sublinhado ] algarismo ext g especi cac~ ao da base ::= B j O j X Em VHDL, comentarios comecam com dois tracos e v~ ao ate o nal da linha. Eles est~ ao ignorados pelo compilador pois eles n~ ao fazem parte do sentido da descric~ ao.
1.5.5 Cadeias de bits
1.5.6 Comentarios
12
2. Organizac~ ao e utilizac~ ao
de descric~ oes VHDL
Nesse cap tulo, veremos como as descric~ oes VHDL s~ ao analizadas, de nidas e organizadas em bibliotecas. Veremos tambem como utilizar descric~ oes ja analizadas como componentes de novas descric~ oes.
2.1 Unidades de concepc~ ao

Os diferentes tipos de unidades de concepc~ ao s~ ao: declarac~ ao de entidade (entity declaration ) descreve a interface de um sistema. declarac~ ao de pacote (package declaration ) grupa um conjunto de declarac~ oes (tipos, subprogramas por exemplo), a ser usados para a descric~ ao de sistemas. declarac~ ao de con gurac~ ao (con guration declaration ) descreve como um sistema deve ser con gurado. corpo de arquitetura (architecture body ) e associado a uma declarac~ ao de entidade, e descreve como o sistema deve funcionar. corpo de pacote (package body ), e associado a uma declarac~ ao de pacote, e da detalhes de implementac~ ao dos objetos declarados. Unidades de concepc~ ao (design units ) podem ser compiladas (ou analizadas) independentemente e armazenadas em bibliotecas de concepc~ ao (design library ). Os arquivos de codigo fonte VHDL s~ ao chamados de arquivo de concepc~ ao (design le ). Cada arquivo de concepc~ ao pode conter varias unidades de concepc~ ao. Quando um arquivo de concepc~ ao e compilado, por cada unidade de concepc~ ao analizada com sucesso, e criada uma unidade de biblioteca (library unit ) que e ent~ ao armazenada em uma biblioteca de concepc~ ao (design library ). Uma unidade de biblioteca pode ser primaria(primary ) ou segundaria (secondary ): declarac~ ao de entidade, declarac~ ao de pacote e declarac~ ao de con gurac~ ao s~ ao unidades primarias, enquanto corpo de arquitetura e corpo de pacote s~ ao unidades segundarias. Uma unidade segundaria e um corpo de uma unidade primaria analizada independentemente e previamente. Se uma unidade primaria 13
14
Cap tulo 2. Organizac~ ao e utilizac~ ao de descric~ oes VHDL
e modi cada, ent~ ao as unidades segundarias correspondentes cam obsoletas e n~ ao podem ser mais usadas ate que as unidades de concepc~ ao correspondentes sejam analizadas de novo. Uma declarac~ ao de entidade pode ter varios corpos diferentes, enquanto uma declarac~ ao de pacote so pode ter um corpo.
2.2 Bibliotecas de concepc~ ao

Uma biblioteca de concepc~ ao e um tipo de memoria que armazena as unidades de concpec~ ao previamente analizadas. A estrutura e a implementac~ ao das bibliotecas depende da implementac~ ao e pode ent~ ao variar de ferramentas em ferramentas. Em geral, implementac~ oes do sistema de bibliotecas s~ ao realizadas em cima de um sistema de arquivos. Bibliotecas (logicas) s~ ao implementadas por diretorios (f sicos). E as unidades de biblioteca s~ ao implementadas por arquivos. Cada biblioteca tem um nome logico, com qual ela pode ser referenciada no codigo VHDL, e um nome f sico, que denota o armazem correspondente no ambiente de utilizac~ ao.
Exemplo:
O ambiente de concepc~ ao tem 4 bibliotecas de concepc~ ao. STD, IEEE, LOGIC_GATES, PROJECT s~ ao os nomes logicos dessas bibliotecas. Cada biblioteca de concepc~ ao tem um nome f sico, que como pode ser um nome de diretorio, como por exemNome logico Nome f sico plo:
STD IEEE LOGIC_GATES PROJECT /usr/lib/vhdl/std /usr/lib/vhdl/ieee /usr/lib/vhdl/lgates /usr/lib/vhdl/project
A ferramenta de compilac~ ao
VHDL deve ent~ ao ter um mec^ anismo de criac~ ao de bibliotecas e de associac~ ao com os \armazens". Durante uma analise de unidade de concepc~ ao, as bibliotecas podem ser consideras como sendo: 1. bibliotecas de recursos (resource library ): contem unidades de bibliotecas que s~ ao usadas na unidade de concepc~ ao sendo analizada. 2. a biblioteca de trabalho (working library ), chamada WORK, que e a biblioteca aonde a unidade de concepc~ ao sendo analizada sera armazenada. Compiladores VHDL tem um comando que permite ao usuario especi car qual e a biblioteca de trabalho antes de fazer a compilac~ ao. As bibliotecas STD e IEEE s~ ao bibliotecas de recursos importantes, o conteudo delas e de nida pelo comite de padronizac~ ao:
Bibliotecas padr~ ao
2.3. Clausula de contexto
15
Figura 2.1: Ilustrac~ ao do sistema de bibliotecas durante a compilac~ ao A biblioteca STD contem dois pacotes com de nic~ oes padr~ ao: 1. o pacote STANDARD onde s~ ao de nidos alguns tipos de base, 2. e o pacote TEXTIO onde s~ ao de nidos tipos e subprogramas de entrada e saida de texto. A biblioteca IEEE contem varios pacotes de extens~ ao para tarefas comuns: 1. um pacote para a s ntese, 2. um pacote, chamado NUMERIC_STD, que de ne tipos e func~ oes para a convers~ ao de vetores de bits para inteiros com ou sem sinal, 3. um pacote, chamado STD_LOGIC_1164, que de ne uma logica multivaluada.
2.3 Clausula de contexto

Cada unidade de concepc~ ao tem uma clausula de contexto que de ne o ambiente inicial na analise. A clausula de contexto poder ser composta de
clausulas de biblioteca (library clause ) declaram nomes logicos de bibliotecas que podem passar a ser usadas no resto da descric~ ao. Por exemplo, a clausula seguinte
library LOGIC_GATES
de ne a biblioteca LOGIC_GATES, e todos os nomes de unidades de biblioteca armazenadas nessa biblioteca passam a ser vis veis.
16
Cap tulo 2. Organizac~ ao e utilizac~ ao de descric~ oes VHDL passam a poder ser referenciados no resto da descric~ ao. Exemplos:
use STD.STANDARD.all use IEEE.NUMERIC_STD.BV_TO_UNSIGNED
clausulas de uso (use clause ) declaram nomes ou conjunto de nomes que
A primeira linha torna todas as declarac~ oes do pacote STANDARD da biblioteca STD vis veis, enquanto a segunda linha torna so a declarac~ ao de BV_TO_UNSIGNED vis vel. Por defaut, o clausula de contexto contem as clausulas seguintes:
library STD, WORK use STD.STANDARD.all
VHDL tem regras de escopo similares as de linguagens de programac~ ao classicos, com estruturas de blocos. Assim, as declarac~ oes de uma unidade de concepc~ ao primaria s~ ao vis veis nas unidades de concepc~ ao segundarias correspondentes. Existe regras de escopo espec cas para pacotes. O exemplo seguinte ilustralas:
package A is -- declarac~ oes ... end A use WORK.A.all package B is -- declarac~ oes -- as declarac~ oes de A s~ ao vis veis ... end B use work.B.all architecture X of Y is -- as declarac~ oes de B s~ ao vis veis -- as declarac~ oes de A n~ ao s~ ao vis veis end X
2.3.1 Escopo
2.4 Elementos de descric~ ao estrutural

Uma descric~ ao e estrutural se ela usa outras entidades de concepc~ ao como componentes. VHDL da ao usuario uma exibilidade muito grande para declarar componentes, usar componentes, e instanciar componentes com entidades de concepc~ ao ja armazenadas em bibliotecas.
2.4. Elementos de descric~ ao estrutural
17
2.4.1 Declarac~ ao de componentes
Uma declarac~ ao de componente declara uma interface de entidade virtual. Exemplo:

component AND2 generic(DELAY: TIME := 15ns) port(A, B: in BOOLEAN C: out BOOLEAN) end component
Em VHDL-93, a palavra chave is pode seguir o nome do componente e esse nome pode ser repetido no nal. Nota que n~ ao ha indicac~ ao de qual entidade de concepc~ ao corresponde a esse componente.
2.4.2 Instanciac~ ao de componentes

signal S1, S2, S3, S4, S5: BOOLEAN ... GATE1: AND2 generic map (20ns) port map (S1, S2, S3) GATE2: AND2 port map (B => S3, A => S4, C => S5)
Uma vez um component declarado, e poss vel instanciar ele dentro de um corpo de arquitetura atraves de instruc~ oes de instanciac~ ao de componentes.
Este exemplo destaca as varias maneiras de instanciar componentes: 1. sinais podem ser conectados aos por posic~ ao, 2. ou por associac~ ao, 3. itens gen^ ericos podem ser especi cados ou n~ ao. De novo, n~ ao ha indicac~ ao de qual entidade de concepc~ ao deveria ser usada nessa arquitetura. E a tarefa da con gurac~ ao de componente e da declarac~ ao de con gurac~ ao de realizar essa tarefa.
2.4.3 Con gurac~ ao de componente
A con gurac~ ao de componentes e uma maneira de associar uma entidade de concepc~ ao que ja foi analizada a um componente, dentro da arquitetura onde esse componente ca declarado e instanciado.
18
-- As entidades de concepc~ ao seguintes foram analizadas na -- biblioteca LOGIC_GATES entity AND2 is generic(D: TIME) port(I1, I2: in BOOLEAN O: out BOOLEAN) end entity AND2 architecture TIMED of AND2 is ... end architecture TIMED architecture UNTIMED of AND2 is ... end architecture UNTIMED -- Exemplo de uso das entidades precedentes (outro arquivo) library LOGIC_GATES architecture TIMED of AND3 is component AND2 generic(DELAY: TIME := 15ns) port(A, B: in BOOLEAN C: out BOOLEAN) end component AND2 signal S1, S2, S3, S4, S5: BOOLEAN -- primeira possibilidade: configurac~ ao diferente para -- as duas instanciac~ oes de AND2 for GATE1: AND2 use entity LOGIC_GATES.AND2(TIMED) generic map(D => DELAY) port map (IN1 => A, IN2 => B, O => C) for GATE2: AND2 use entity LOGIC_GATES.AND2(UNTIMED) -- segunda possibilidade: configurac~ ao igual para as -- duas instanciac~ oes de AND2 for all: AND2 use entity LOGIC_GATES.AND2(TIMED) generic map(D => DELAY) port map (IN1 => A, IN2 => B, O => C) begin GATE1: AND2 generic map (20ns) port map (S1, S2, S3) GATE2: AND2 port map (B => S3, A => S4, C => S5) end architecture TIMED
2.4. Elementos de descric~ ao estrutural
19
Neste caso, se uma das unidades de concepc~ ao usadas como componentes s~ ao modi cadas, a unidade de biblioteca correspondente a essa arquitetura ca obsoleta e e portanto necessario reanalizar-la.
2.4.4 Declarac~ ao de con gurac~ ao
A declarac~ ao de con gurac~ ao e uma segunda maneira de associar uma entidade de concepc~ ao que ja foi analizada a um componente, fora da arquitetura onde esse componente ca declarado e instanciado.
-- As entidades de concepc~ ao seguintes foram analizadas na -- biblioteca LOGIC_GATES -- Exemplo de uso das entidades precedentes (outro arquivo) library LOGIC_GATES architecture TIMED of AND3 is component AND2 generic(DELAY: TIME := 15ns) port(A, B: in BOOLEAN C: out BOOLEAN) end component AND2 signal S1, S2, S3, S4, S5: BOOLEAN begin GATE1: AND2 generic map (20ns) port map (S1, S2, S3) GATE2: AND2 port map (B => S3, A => S4, C => S5) end architecture TIMED -- primeira possibilidade: configurac~ ao diferente para -- as duas instanciac~ oes de AND2 configuration AND3C1 of WORK.AND3(TIMED) is for GATE1: AND2 use entity LOGIC_GATES.AND2(TIMED) generic map(D => DELAY) port map (IN1 => A, IN2 => B, O => C) for GATE2: AND2 use entity LOGIC_GATES.AND2(UNTIMED) -- segunda possibilidade: configurac~ ao igual para as -- duas instanciac~ oes de AND2 configuration AND3C1 of WORK.AND3(TIMED) is for all: AND2 use entity LOGIC_GATES.AND2(TIMED) generic map(D => DELAY)
20
port map (IN1 => A, IN2 => B, O => C) end configuration AND3C2
Agora, se uma das entidades usadas como componente e modi cado e so necessario recompilar a declarac~ ao de con gurac~ ao. Em VHDL-93, existe a possibilidade de instanciar diretamente entidades de concepc~ ao como componentes de um modelo estrutural.
entity MAJORITY is port (A_IN, B_IN, C_IN: in BIT Z_OUT: out BIT) end MAJORITY architecture STRUCTURE of MAJORITY os signal INT1, INT2, INT3: BIT begin A1: entity WORK.AND2_OP(MODEL) port map(A_IN, B_IN, INT1) A2: entity WORK.AND2_OP(MODEL) port map(B_IN, C_IN, INT2) A3: entity WORK.AND2_OP(MODEL) port map(C_IN, A_IN, INT3) O1: entity WORK.OR3_OP(MODEL) port map(INT1,INT2,INT3,Z_OUT)
2.4.5 Instanciac~ ao direta de entidades de concepc~ ao
3. Processos, sinais e
simulac~ ao
3.1 Introduc~ ao
O objetivo desse cap tulo e apresentar a simulac~ ao em VHDL. Dois tipos de unidades de concepc~ ao podem ser simuladas: corpos de arquitetura e declarac~ ao de con gurac~ ao. Uma unidade de concepc~ ao e simulavel se ela e completamente con gurada: todos os componentes instanciados devem ser con gurados, e todos os par^ ametros gen^ ericos ser xados. Para simular uma unidade de biblioteca, a elaborac~ ao de um modelo de simulac~ ao e necessaria. Modelos de simulac~ ao s~ ao processos interconectados por sinais. Veremos no paragrafo 3.2 os elementos basicos desses modelos de simulac~ ao. O algoritmo usado para simular esses modelos e ent~ ao apresentado no paragrafo 3.3.
3.2 Elementos basicos do modelo de simulac~ ao

Basicamente, o modelo de simulac~ ao e composto de processos e de sinais. Processos s~ ao objetos que executam programas sequ^ encias e podem ser usados para modelizar os diferentes componentes de um sistema. Sinais s~ ao canais de comunicac~ ao entre processos. Eles podem ser usados para modelisar o uxo de informac~ ao entre os diferentes componentes do sistema.
3.2.1 Sinais
Um sinal e de nido por: O seu nome S que permite identi car o sinal. O seu tipo T que de ne quais s~ ao os valores que o sinal pode ter. Opcionalmente uma func~ ao de resoluc~ ao F, que deve ter como par^ ametro um vector de valores do tipo T e retornar um valor de tipo T. A func~ ao de resoluc~ ao e obrigatoria se o sinal e atribuido par mais de um processo. Ela e chamada pelo simulador para calcular o novo valor do sinal em func~ ao dos valores atribuidos aos sinais. Um exemplo de de nic~ ao de sinal com func~ ao de resoluc~ ao e apresentado na gura 3.1. O nome do sinal e S, seu tipo e LOGIC3, portanto, ele pode ter 21
22
Cap tulo 3. Processos, sinais e simulac~ ao
valores 'U', '0' e '1', e e associado a func~ ao de resoluc~ ao RESOLVED. Se S e simultaneamente atribuido os valores '0' and '1', ent~ ao ele tera o valor 'U'.
3.2.2 Processos
Um processo e composto de: Uma parte declarativa, que pode incluir declarac~ oes de variaveis. Uma parte programa, que pode ser composto por varios tipos de instruc~ oes sequenciais. Por enquanto, usaremos os quatro tipos de instruc~ oes seguintes seguintes: { instruc~ ao de atribuic~ ao de variavel, { instruc~ ao se, { instruc~ ao de atribuic~ ao de sinal, { instruc~ ao de espera,
Atribuic~ ao de variavel
Sintaxe:
name := expression
Atribuic~ ao se
Sintaxe:
if condic~ ao then instruc~ oes sequenciais {elsif condic~ ao then instruc~ oes sequenciais} else instruc~ oes sequenciais] end if
Atribuic~ ao de sinal
Por cada sinal atribuido na parte programa de um processo, o processo tem um piloto associado a esse processo. O piloto associado a um sinal e composto de 1. O valor pilotando (driving value ) que e o valor que o processo esta atualmente atribuindo. 2. Uma lista de transac~ oes. Uma transac~ ao e um par de valor e data. As transac~ oes s~ ao ordenadas por ordem de data, e representam valores que o processo escalonou para atribuir ao sinal ao longo do tempo. Usaremos a notac~ ao seguinte para o piloto de um sinal:
3.2. Elementos basicos do modelo de simulac~ ao
23
type ULOGIC3 is ('U','0','1') type ULOGIC3_VECTOR is array ( NATURAL range <> ) of ULOGIC3 function RESOLVED ( S : ULOGIC3_VECTOR ) return ULOGIC3 signal S: RESOLVED ULOGIC3 constant RESOLUTION_TABLE : LOGIC3_TABLE := ( ---------------------------| U 0 1 | | --------------------------( 'U', 'U', 'U'), -- | U | ( 'U', '0', 'U'), -- | 0 | ( 'U', 'U', '1') -- | 1 | ) function RESOLVED ( S : ULOGIC3_VECTOR ) return ULOGIC3 is variable RESULT : ULOGIC3 := 'U' -- weakest state default begin -- the test for a single driver is essential otherwise the -- loop would return 'U' for a single driver of '0' and that -- would conflict with the value of a single driver unresolved -- signal. if (S'LENGTH = 1) then return S(S'LOW) else for I in S'RANGE loop RESULT := RESOLUTION_TABLE(RESULT, S(I)) end loop end if return RESULT end RESOLVED
Figura 3.1: Exemplo de func~ ao de resoluc~ ao
24
Cap tulo 3. Processos, sinais e simulac~ ao 1 2 2 12 5 8 NOW +3ns +12 ns +13 ns +20 ns + 42 ns
Instruc~ oes de atribuic~ ao de sinal modi cam o conteudo do piloto associado a esse sinal, e n~ ao o valor do sinal. Portanto, na codigo seguinte:
V := S+1 S <= V if (S=V) then ...
a condic~ ao da instruc~ ao se sempre sera falsa. VHDL tem uma grande versitilidade na forma de atribuir sinais, podendo por exemplo ser usado para modelizar fen^ omenos f sicos:
<atribuic~ ao_de_sinal> ::= name <= <mec^ anismo_de_atraso>] <forma_de_onda> <mec^ anismo de atraso> ::= transport | reject <express~ ao_temporal>] inertial <forma_de_onda> ::= <elemento_de_forma_de_onda> {, <elemento_de_forma_de_onda>} <elemento_de_forma_de_onda> ::= <express~ ao> after <express~ ao_temporal> ] | null
Na forma de atribuic~ ao nula, o piloto do sinal e disconectado, e para o simulador, o processo n~ ao atribui mais ao valor do sinal. Ilustraremos a forma geral com o exemplo seguinte:
S <= reject 15 ns inertial 12 after 20 ns, 18 after 41 ns
aplicado a um piloto de sinal na situac~ ao seguinte: 1 27 27 12 5 8 NOW +3ns +12 ns +13 ns +20 ns + 42 ns Cada elemento de forma de onda produz uma transac~ ao. As transac~ oes s~ ao inseridas no piloto do sinal segundo as regras seguintes: Antigas transac~ oes escalonadas para acontecer a ou depois a data da primeira nova transac~ ao s~ ao apagadas. 1 27 27 12 NOW +3ns +12 ns +13 ns As novas transac~ oes s~ ao ent~ ao inseridas no piloto, em ordem crescente de data de escalonamento.
3.2. Elementos basicos do modelo de simulac~ ao 1 27 27 12 12 20 NOW +3ns +12 ns +13 ns +20 ns + 42 ns Se o atraso e de tipo inercial, as demais modi cac~ oes s~ ao efetuadas: As novas transac~ oes s~ ao marcadas. 1 2 2 12 12 18 NOW +3ns +12 ns +13 ns +20 ns + 41 ns
25
"
"
S~ ao tambem marcadas as antigas transac~ oes escalonadas para acontecer antes da data da primeira nova transac~ ao menos a limita do tempo de rejec~ ao. 1 2 2 12 12 18 NOW +3ns +12 ns +13 ns +20 ns + 41 ns
"
"
"
Para cada antigas transac~ ao ainda n~ ao marcada, a antiga transac~ ao e marcada se a proxima transac~ ao e marcada e tem o mesmo valor. 1 2 2 12 12 18 NOW +3ns +12 ns +13 ns +20 ns + 41 ns
"
"
"
"
A transac~ ao determinando o valor pilotando e marcada. 1 2 2 12 12 18 NOW +3ns +12 ns +13 ns +20 ns + 41 ns
"
"
"
"
"
Transic~ oes n~ ao marcadas s~ ao apagadas. 1 2 12 12 18 NOW +3ns +13 ns +20 ns + 41 ns
Discuss~ ao Ha ent~ ao dois modos de atribuic~ ao: inercial e transporte. O modo

O <= not I after 7 ns.
inercial corresponde a inerc a dos sistemas f sicos e e o modo defaut de atribuic~ ao. Na forma simples (VHDL'87) a atribuic~ ao tem a forma seguinte: Essa atribuic~ ao escalona o valor de not I a o tempo atual mais 7ns. Todos os valores escalonados ate esse tempo s~ ao apagados do piloto.
26
0

0
Se ha a opc~ ao reject do valor temporal t (so em VHDL-93), combinado com um atraso do valor temporal t , so os valores escalonados entre os tempos t e t ; t s~ ao apagadas. O par^ ametro t corresponde a inercia do sistema: ele n~ ao e capaz de reagir a eventos que ocorrem a intervalos de menos de t. O segundo par^ ametro corresponde ao tempo que as modi cac~ oes levam para ser tomadas em conta. t e o tempo de inercia e t e o tempo de atraso.
0 0
O <= reject 5 ns inertial not I after 7 ns
Todos as modi cac~ oes de menos de 5 ns s~ ao ltradas e eliminadas. As modi cac~ oes de mais de 5 ns s~ ao propagadas com um atraso de 7 ns.
Finalmente, as atribuic~ oes em modo transporte n~ ao apagam valores escalonados e correspondem a dispositivos ideialmente transparentes, que n~ ao tem nenhuma inercia.
O <= transport not I after 7 ns
Como ja vimos para a instruc~ ao de atribuic~ ao de sinal, e poss vel explicitar quantidades temporais no tempo do modelo de simulac~ ao. Mas, nesse tempo as instruc~ oes levam um tempo nulo para se executar. E necessario ter um tipo de instruc~ ao para parar a execuc~ ao dos processos e deixar o tempo passar. Isso e a tarefa da instruc~ ao de espera:
Instruc~ ao de espera
3.3. O algoritmo de simulac~ ao

wait on <lista_de_sinais>] until <condic~ ao>] for <express~ ao_temporal>]
27
Quando um processo encontra uma instruc~ ao de espera, ele para sua execuc~ ao. O simulador acorda esse processo se as condic~ oes indicadas na instruc~ ao de espera s~ ao veri cadas.
on <lista_de_sinais>, a lista de sensibilidade, o processo para ate que haja um evento em um dos sinais presente na lista. Um evento e uma mudanca de valor. Se n~ ao ha lista de sensibilidade expl cita, ela e construida a partir da condic~ ao e e composta por todos os sinais presente nesta condic~ ao. Se n~ ao ha sinal, ou n~ ao ha condic~ ao, o processo ca parado eternamente. for <express~ ao_temporal>,
perando.
e o tempo maximo que o processo ca es-
cada vez que ha um evento em um dos sinais da lista de sensibilidade, a condic~ ao e avalidada e, se for verdadeira, o processo recomeca sua execuc~ ao. Exemplos:
wait wait wait wait wait on ALARM_A, ALARM_B until (CLK = '1') for 1 ms on ALARM_1, ALARM_B until (CLK = '1') on ALARM_A, ALARM_B until (CLK = '1') for 1 ms
until <condic~ ao>,
Processos adiados
Um processo pode ser adiado se ele e descrito com a palavra chave postponed. Processos adiados s~ ao executados depois dos outros processos.
3.3 O algoritmo de simulac~ ao

O algoritmo de simulac~ ao consiste em executar o modelo de simulac~ ao elaborado a partir da entidade de descric~ ao, e assim simular o sistema modelizado. A simulac~ ao consiste em executar os processos de nidos pelo usuario e um processo conceptual, chamado de processo corac~ ao (process kernel ), que sincroniza as atividades desses processos usuarios. A execuc~ ao de um modelo consiste em uma fase de inicializac~ ao seguida por a execuc~ ao repetida do ciclo de simulac~ ao. Esse algoritmo usa duas variaveis Tc e Tn que representam o tempo atual na simulac~ ao, e o tempo do proximo ciclo de simulac~ ao.
28
Um sinal e ativo (active ) se ele e atribuido um valor diferente ou n~ ao do valor precedente. Quando um sinal n~ ao e ativo, ele e tranquilo (quiet ). Um evento ocorre em um sinal se ele e atribuido um valor diferente do valor precedente. VHDL permite de nir implicitamente novos sinais por uso de atributos ligados a sinais ja de nidos: S'stable (T)] e de tipo booleano e e verdadeiro se nenhum evento ocorreu no S desde T unidades de tempo, sen~ ao e falso. O valor defaut de T e 0 ns. S'quiet (T)] e de tipo booleano e e verdadeiro se S cou calmo as ultimas T unidades de tempo, sen~ ao e falso. O valor defaut de T e 0 ns. S'delayed (T)] e do mesmo tipo que S e equivalente ao sinal S decalado de T unidades de tempo. O valor defaut de T e 0 ns.
3.3.1 Mais noc~ oes ligadas a sinais
3.3.2 A fase de inicializac~ ao

O valor pilotando e o valor efetivo de cada sinal declarado explicitamente s~ ao calculadas. E suposto que antes da simulac~ ao, o sinal sempre teve esse valor inicial. Os sinais impl citos S'stable(T) e S'quiet(T) s~ ao atribuidos o valor TRUE. Cada sinal impl cito S'delayed(T) e atribuido o valor de S. Todos os processos n~ ao adiados s~ ao ativados, ate que eles sejam suspensos, por execuc~ ao de uma instruc~ ao de espera. Depois s~ ao executados os sinais adiados. Nota que e poss vel que um processo n~ ao parasse. O tempo do proximo ciclo de simulac~ ao Tn e calculado segundo as regras de nidas no ciclo de simulac~ ao.
Tc e inicializado a 0.
3.3.3 O ciclo de simulac~ ao
Um ciclo de simulac~ ao e composto das etapas seguintes: 1. O tempo atual Tc e atribuido Tn. A simulac~ ao para se Tn = TIME'HIGH e n~ ao tem sinais ou processos ativos a Tn. 2. Cada sinal de nido explicitamente e atualizado. Eventos podem resultar dessa atualizac~ ao. 3. Cada sinal de nido implicitamente e atualizado. Eventos podem resultar dessa atualizac~ ao. 4. Para cada processo P n~ ao adiado, se P e sens vel a um sinal S e houve um evento em S nesse ciclo de simulac~ ao, ent~ ao P retoma sua execuc~ ao ate parar.
3.3. O algoritmo de simulac~ ao 5. Tn e atribuido o menor de

TIME'HIGH
29
O proximo tempo no qual um piloto de sinal ca ativo (data da primeira transac~ ao). O proximo tempo no qual um processo recomec~ ao sua execuc~ ao (clausula for). Se Tn = Tc, ent~ ao o proximo ciclo de simulac~ ao sera um ciclo delta (delta cycle ). Se o proximo ciclo n~ ao for um ciclo delta, os processos adiados e ativos s~ ao executados ate parar. Tn e calculado de novo e e um erro se Tn = Tc.
3.3.4 Exemplo
entity ODD_PARITY_DETECT is port (A, B, C, D: in BIT ODD: out BIT) end ODD_PARITY_DETECT architecture DATA_FLOW of ODD_PARITY_DETECT is signal INT1, INT2: BIT begin process begin INT1 <= A xor B after 5 ns wait on A, B end process begin INT2 <= INT1 xor C after 5 ns wait on INT1, C end process begin ODD <= INT2 xor D after 5 ns wait on INT2, D end end DATA_FLOW A '1' ------------------'0' ----B '1' '0' ------------------------
30

C '1' ------------------'0' ----D '1' ------------------'0' -----
INT1 '1' -------------'0' ---------INT2 '1' ----'0' -----------------ODD '1' -------'0' -------------0 5 10 15 20
A sa da do circuito e '1' quando ha um numero impar de '1' em entrada. Fazemos a hipotese que, no in cio da simulac~ ao, todos os sinais s~ ao inicializados o valor '0', e que a data 5 ns os sinais de entrada A, Ce D passam de '0' a '1'. Esses eventos causam as tr^ es instruc~ oes concorrentes de atribuic~ ao de sinal a ser executadas. Como resultado, tr^ es transac~ oes '1', 10 ns] s~ ao inseridas nos pilotos dos sinais INT1, INT2 e ODD. No proximo ciclo de simulac~ ao, o tempo avanca ate as primeiras transac~ oes escalonadas: 10 ns, e os valores efetivos dos sinais INT1, INT2 e ODD s~ ao modi cados, o que causa a execuc~ ao dos segundos e terceiros processos. Novas transac~ oes '0', 15 ns] s~ ao inseridas nos pilotos dos sinais INT2 e ODD. A data 15 ns, os valores efetivos desses sinais s~ ao modi cados, causando a execuc~ ao do terceiro processo, e uma nova transac~ ao '1', 20 ns] e inserida no piloto de ODD. O tempo ent~ ao avanca ate a data 20 ns e o valor efetivo de ODD passa a ser '1'. O que acontece se n~ ao ha atraso nas atribuic~ oes de sinais, como no codigo seguinte ?
architecture DATA_FLOW of ODD_PARITY_DETECT is signal INT1, INT2: BIT begin process begin INT1 <= A xor B wait on A, B end process begin INT2 <= INT1 xor C wait on INT1, C
3.3. O algoritmo de simulac~ ao

end process begin ODD <= INT2 xor D wait on INT2, D end end DATA_FLOW
31
O mesmo numero de ciclo de simulac~ ao e necessario, mas todas as modi cac~ oes s~ ao feitas na mesma data. Os ciclos de simulac~ ao s~ ao delta-ciclos.
32
4. Programac~ ao sequencial
4.1 Introduc~ ao
Esse cap tulo tem como objetivo apresentar em detalhes como descrever processos e rotinas em VHDL. Primeiro daremos algumas geralidades sobre processos e rotinas. Ser~ ao ent~ ao apresentados os diferentes tipos de instruc~ oes sequ^ enciais usadas para a de nic~ ao de algoritmos em processos e rotinas assim como os diferentes tipos de declarac~ oes poss veis em processos e rotinas. As instruc~ oes sequ^ enciais s~ ao: 1. instruc~ ao de espera 2. instruc~ ao de atribuic~ ao de sinal 3. instruc~ ao de atribuic~ ao de variavel 4. instruc~ ao condicional \se" 5. instruc~ ao de asserc~ ao 6. instruc~ ao de relatorio (VHDL-93) 7. chamada de procedimento 8. instruc~ ao condicional de escolha 9. instruc~ ao de laco 10. instruc~ ao proximo 11. instruc~ ao nula 12. instruc~ ao de sa da 13. instruc~ ao de retorno Ja estudamos as 4 primeiras instruc~ oes no cap tulo precedente. 33
34
Cap tulo 4. Programac~ ao sequencial
4.2 Processos
O conceito de processo ja foi abordado no cap tulo sobre o modelo de simulac~ ao VHDL. A sintaxe de um processo e:
<process_statement> ::= <label>: ] postponed] process <declarations> begin <statements> end process] <label>] <sensitivity_list> ::= <name> {, <name>} (<sensitivity_list>)] is]
A parte declarac~ ao de um processo pode conter declarac~ oes de variaveis, rotinas, tipos, etc. mas declarac~ oes de sinais s~ ao prohibidas, pois sinais s~ ao usados para comunicar entre processos e portanto tem que ter um escopo maior que um processo. Quando a ultima instruc~ ao de um processo e executada, o controle passa de novo para a primeira instruc~ ao do processo:
loop while TRUE <statements> end loop
A lista de sensibilidade e uma clausula opcional do processo e deve e constituida com nomes de sinais. Quando um processo tem uma lista de sensibilidade, ele n~ ao pode conter instruc~ oes de espera expl cita. Ele e ent~ ao equivalente a:
<label>: ] process is] <declarations> begin <statements> wait on <sensitivity_list> end process] <label>]
4.3 Rotinas
Chamadas de func~ oes s~ ao consideradas como express~ oes, enquanto chamadas de procedimento s~ ao consideradas como instruc~ oes. A sintaxe de uma declarac~ ao de rotina e:
<subprogram_declaration> ::= procedure <designator> ( <formal_parameter_list> ) ] | pure | impure ] function <designator> ( <formal_parameter_list> ) ] return <type_mark>
4.4. Instruc~ ao de asserc~ ao

<designator> ::= <identifier> | <operator_symbol>
35
Uma func~ ao e pura se ela sempre retorna o mesmo valor para os mesmos valores dos par^ ametros, e impura caso contrario. O defaut e de ser pura. As noc~ oes de func~ oes pura e impura s~ ao so em VHDL-93. O nome de uma func~ ao pode ser um nome de operador, como "=" por exemplo. Isso permite ao programador rede nir os operadores para um tipo de dado, ou ate de de nir operadores entre tipos de dados diferentes: essa tecnica consiste em sobrecarregar o operador. A sintaxe da de nic~ ao de rotina e:
subprogram_body ::= subprogram_specification is subprogram_declarative_part begin subprogram_statement_part end subprogram_kind ] designator ] subprogram_kind ::= procedure | function
E prohibido declarar sinais numa rotina.
4.4 Instruc~ ao de asserc~ ao

A instruc~ ao de asserc~ ao e usada para veri car se uma condic~ ao dada e verdadeira e reportar um erro se ela e falsa.
<assertion_statement> ::= <label>: ] assert <condition> report <expression> ] severity <expression> ]
Se a clausula report esta presente, a express~ ao argumento deve ser de tipo STRING e e chamada de cadeia de mensagem. Se a clausula severity esta presente, a express~ ao argumento deve ser do tipo enumerado SEVERITY_LEVEL, e e chamada de n vel de severidade. Os valores poss veis desse tipo s~ ao NOTE, WARNING, ERROR e FAILURE. Os valores defaut dessas clausulas s~ ao respectivamente "Assertion violation" e ERROR. Quando a instruc~ ao e executada a condic~ ao e avaliada. Se a condic~ ao for falsa, uma mensagem de erro e imprimida pelo simulador. Essa mensagem de erro deve ter as informac~ oes seguintes: uma indicac~ ao que a mensagem vem de uma asserc~ ao, o valor do n vel de severidade,
36
Cap tulo 4. Programac~ ao sequencial o valor da cadeia de mensagem, o nome da unidade de concepc~ ao onde ca a asserc~ ao.
4.5 Instruc~ ao de relatorio

Uma instruc~ ao de relatorio imprime uma mensagem durante a sua execuc~ ao.
<report_statement> ::= <label>: ] report <expression> severity <expression> ]
A instruc~ ao de relatorio e equivalente a instruc~ ao de asserc~ ao com condic~ ao sempre falsa.
4.6 Chamada de procedimento

A instruc~ ao de chamada de procedimento tem o sentido tradicional de invocar a execuc~ ao de uma rotina.
<procedure_call_statement> ::= <label>: ] <procedure_name> (<actual_parameter_part>)]
Para cada par^ ametro formal do procedimento, a chamada deve especi car exatamente um par^ ametro atual correspondente. Esse par^ ametro pode ser especi cado explicitamente, por uma associac~ ao de elemento por nome ou por posic~ ao. Por exemplo, seja o procedimento declarado da maneira seguinte:
procedure INCREMENT (variable VAR: inout NATURAL constant INCR: in NATURAL :=1)
A instruc~ ao seguinte e uma chamada com associac~ ao por posic~ ao:

INCREMENT (REGISTRO VALOR + 2)
A instruc~ ao seguinte e uma chamada com associac~ ao por nome:

INCREMENT (VAR => REGISTRO INCR => VALOR + 2)
O valor de um par^ ametro pode tambem ser expeci cado implicitamente como sendo igual ao valor por defaut do par^ ametro formal. Por exemplo, nas chamadas seguintes:
INCREMENT (REGISTRO) INCREMENT (VAR => REGISTRO)
O codigo do procedimento e ent~ ao executado, usando os valores dos par^ ametros atuais e os valores defaut dos par^ ametros formais como valores dos par^ ametros formais correspondentes.
4.7. Instruc~ ao condicional de escolha
37
4.7 Instruc~ ao condicional de escolha

A instruc~ ao condicional de escolha e uma instruc~ ao comum nas linguagens de programac~ ao imperativa. Sua sintaxe em VHDL e:
<case_statement> ::= <label>: ] case <expression> is <case_statement_alternative> { <case_statement_alternative> } end case <label>] <case_statement_alternative> ::= when <choices> => <sequence_of_statements>
A express~ ao de escolha deve ser de um tipo discreto (tipo inteiro ou enumerado) ou de tipo cadeia de carateres (vetor unidimensional de carateres). Os tipos dos diferentes casos deve ser o mesmo que o tipo da escolha. Quando o tipo da escolha e discreto, cada valor pode aparecer em um caso so, e todos os valores devem ser representados por um caso.
4.8 Instruc~ ao de laco

VHDL tem dois tipos de laco: enquanto e para. A sintaxe e a seguinte:
<loop_statement> ::= <label>: ] <iteration_scheme>] loop <sequence_of_statements> end loop <label>] <iteration_scheme> ::= while <condition> | for <identifier> in <discrete_range>
Os dois esquemas while e for tem os sentidos habituais. Um laco sem esquema de iterac~ ao e equivalente a um laco while TRUE. Para um la`co for, a especi cac~ ao do par^ ametro de iterac~ ao e uma declarac~ ao desse par^ ametro, que e uma variavel, cujo tipo e o tipo da faixa da iterac~ ao. Quando a instruc~ ao e executada, a avaliac~ ao da faixa e realizada, e o corpo do laco e executado por cada valor nessa faixa.
4.9 Instruc~ ao proximo

Essa instruc~ ao serve para passar a iterac~ ao seguinte de uma instruc~ ao laco. Sua sintaxe e:
<next_statement> ::= <label>: ] next <loop_label>] when <condition>]
O rotulo <loop_label> ind ca qual e o laco a qual a instruc~ ao faz refer^ encia, como por exemplo no caso de lacos aninhados.
38
Cap tulo 4. Programac~ ao sequencial
4.10 Instruc~ ao de sa da
Essa instruc~ ao serve para terminar a execuc~ ao de uma instruc~ ao laco. Sua sintaxe e:
<exit_statement> ::= <label>: ] exit <loop_label>] when <condition>]
O rotulo <loop_label> ind ca qual e o laco a qual a instruc~ ao faz refer^ encia, como por exemplo no caso de lacos aninhados.
4.11 Instruc~ ao de retorno

A instruc~ ao de retorno serve para retornar um valor dentro de uma func~ ao ou de um procedimento. A sintaxe dessa instruc~ ao e:
<return_statement> ::= <label>: ] return <expression>]
4.12 Instruc~ ao nula

A instruc~ ao nula n~ ao tem efeito. Ela pode ser util dentro de uma instruc~ ao de escolha. Sua sintaxe e:
<null_statement> ::= <label>: ] null
5. Programac~ ao concorrente
5.1 Introduc~ ao
Instruc~ oes concorrentes s~ ao usadas para de nir processos ou blocos de processos. A execuc~ ao paralela desses processos de ne o comportamento do sistema. As instruc~ oes concorrentes de base s~ ao o bloco, que grupa varios instruc~ oes concorrentes, e o processo, que ja foi estudado no capitulo precedente. Outros tipos de instruc~ oes concorrentes permitem de de nir com uma sintaxe mais conveniente estruturas aninhadas e repetitivas, assim como os processos ocorrendo de maneira mais comum.
<concurrent_statement> ::= <block_statement> | <process_statement> | <concurrent_procedure_call_statement> | <concurrent_signal_assignment_statement> | <component_instantiation_statement> | <generate_statement>
5.2 Instruc~ ao de processo

Ver o cap tulo 4.
5.3 Instruc~ ao de bloco

A instruc~ ao bloco grupa varias instruc~ oes concorrentes. Ela pode ter uma parte de declarac~ oes, que tem como escopo o bloco. A sintaxe da instruc~ ao de bloco e:
<block_statement> ::= block ( <expression> ) ] <block_header> <block_declarative_part> begin <block_statement_part> end block <label> ] is ]
39
40
Cap tulo 5. Programac~ ao concorrente
A express~ ao opcional aparencedo no in cio do bloco e chamada de express~ ao de guarda e deve ser de tipo BOOLEAN. Quando ha uma express~ ao de guarda, ent~ ao um sinal, com o nome GUARD, e de tipo BOOLEAN e implicitamente declarado dentro do bloco. O sinal GUARD pode ser usado dentro do bloco para controlar operac~ oes.
5.4 Instruc~ ao concorrente de atribuic~ ao de sinal

Exemplos de atribuic~ ao de sinal em VHDL s~ ao:
S <= A and B after 3 ns -- atribuic~ ao condicional S <= A when (B = '1') else -- atribuic~ ao condicional '0' S <= A when (B = '1') else -- atribuic~ ao condicional '0' when (B = '0') with A select -- atribuic~ ao selecionada S <= B when '1', '0' when '0'
Uma instruc~ ao concorrente de atribuic~ ao de sinal representa um processo que atribui valores a esse sinal. A sintaxe dessa instruc~ ao e:
<concurrent_signal_assignment_statement>::= <label>: ] postponed] conditional_signal_assignment | <label>: ] postponed] selected_signal_assignment <options> ::= guarded ]
<delay_mechanism> ]
A atribuic~ ao concorrente condicional de sinal e parecida com uma instruc~ ao sequencial se, enquanto a atribuic~ ao concorrente selecionada de sinal corresponde a uma instruc~ ao sequencial de escolha. Para cada forma de atribuic~ ao de sinal, vamos ver o processo equivalente correspondente.
5.4.1 Atribuic~ ao condicional de sinal

A sintaxe da atribuic~ ao condicional de sinal e:
<conditional_signal_assignment> ::= <target> <= <options> <conditional_waveforms> <conditional_waveforms> ::= { <waveform> when <condition> else } <waveform> when <condition> ]
Se uma atribuic~ ao condicional de sinal tem a forma seguinte:

<target> <= <options> <waveform1>
5.4. Instruc~ ao concorrente de atribuic~ ao de sinal O processo equivalente tera a forma seguinte.:
process begin <wave_transform> wait on <sensitivity_list> end process
41
A lista de sensibilidade contem os sinais aparecendo nas express~ oes da atribuic~ ao de sinal. Se uma atribuic~ ao condicional de sinal tem a forma seguinte:
<target> <= <options> <waveform1> when <condition1> else <waveform2> when <condition2> else ... <waveformN-1> when <conditionN-1> else <waveformN>
O processo equivalente tera a forma seguinte.:

process begin if <condition1> then <wave_transform1> elsif <condition2> then <wave_transform2> ... elsif <conditionN-1> then <wave_transformN-1> else <wave_transformN> end if wait on <sensitivity_list> end process
Se uma atribuic~ ao condicional de sinal tem a forma seguinte:

<target> <= <options> <waveform1> when <condition1> else <waveform2> when <condition2> else ... <waveformN-1> when <conditionN-1> else <waveformN> when <conditionN>
O processo equivalente tera a forma seguinte.:

process begin
42
if <condition1> then <wave_transform1> elsif <condition2> then <wave_transform2> ... elsif <conditionN-1> then <wave_transformN-1> elsif <conditionN> then <wave_transformN> end if wait on <sensitivity_list> end process
waveform_1, waveform_2, ..., waveform_N.
Uma forma de onda pode ser a palavra chave unaffected ou da forma No primeiro caso, a instruc~ ao sequencial equivalente e a instruc~ ao nula. No segundo caso e uma atribuic~ ao sequencial de sinal:
<target> <= <delay_mechanism> waveform_1, ... waveform_N process begin S <= A and B after 3 ns wait on A, B end process process if (B = '1') then S <= A else '0' end if wait on A, B end process process if (B = '1') then S <= A elsif (B = '0') then '0' end if wait on A, B end process
-- atribuic~ ao condicional
5.4.2 Atribuic~ ao selecionada de sinal

<selected_signal_assignment> ::=
5.4. Instruc~ ao concorrente de atribuic~ ao de sinal

with <expression> select <target> <= <options> <selected_waveforms> <selected_waveforms> ::= { <waveform> when <choices>, } <waveform> when <choices>
43
Para uma atribuic~ ao selecionada de sinal da forma:

with <expression> select <target> <= options <waveform1> when <choice_list1>, <waveform2> when <choice_list2>, ... <waveformN-1> when <choice_listN-1>, <waveformN> when <choice_listN>
o processo equivalente tem a forma seguinte:

process begin case <expression> is when <choice_list1> => <wave_transform1> when <choice_list2> => <wave_transform2> ... when <choice_listN-1> => <wave_transformN-1> when <choice_listN> => <wave_transformN> end case wait on <sensitivity_list> end case
A construc~ ao dos wave_transformI e explicada no paragrafo precedente. A atribuic~ ao concorrente selecionada de sinal deve ser tal que a instruc~ ao de escolha construida e legal (ver cap tulo sobre programac~ ao sequencial).
process begin case A is when '1' => S <= B when '0' => S <= '0' end case wait on A, B end process
44
5.4.3 Atribuic~ oes guardadas

<options> ::= guarded ]
As opc~ oes poss veis de uma atribuic~ ao de sinal s~ ao:

<delay_mechanism> ]
Quando uma atribuic~ ao e guardada, ela e executada: quando o sinal GUARD passa do valor FALSE ao valor TRUE, ou quando o valor do sinal GUARD e TRUE, e ocorre um evento em um dos sinais de entrada da instruc~ ao de atribuic~ ao. De maneira geral, o processo equivalente a uma atribuic~ ao concorrente de sinal e construido com as regras seguintes: Se a opc~ ao guarded aparece na atribuic~ ao, o programa do processo tem a forma seguinte:
if GUARD then <signal_transform> end if
Se a opc~ ao guarded n~ ao aparece, ent~ ao a forma do programa do processo equivalente e:

<signal_transform>
A construc~ ao de <signal_transform> depende se a atribuic~ ao e condicionada ou selecionada. Pode ser uma atribuic~ ao sequencial de sinal, uma instruc~ ao se, uma instruc~ ao de escolha, ou uma instruc~ ao nula. Se a atribuic~ ao de sinal e guardada, ou se uma express~ ao que depende de um sinal faz parte da atribuic~ ao, ent~ ao o processo equivalente termina uma instruc~ ao de espera, com uma clausula de sensitividade (wait on <signal_list>). Os sinais da lista de sensitividade s~ ao os sinais aparecendo na express~ ao e, se for o caso de uma atribuic~ ao guardada, o sinal GUARD. Exemplo de atribuic~ oes guardada:
block (SET = 1) begin Q <= guarded I QBAR <= guarded not I end block
Os processos equivalentes s~ ao:
5.4. Instruc~ ao concorrente de atribuic~ ao de sinal

block (SET = 1) process begin Q <= I wait on I, GUARD end process begin QBAR <= not I wait on I, GUARD end
45
Sinais guardados
Um sinal e guardado quando ele e declarado com a palavra-chave register ou bus. Por exemplo:
signal R: STD_LOGIC register := 'U' signal B: STD_LOGIC bus := 'Z'
Quando o alvo de uma atribuic~ ao de sinal guardada e um sinal guardado, o processo equivalente tem a forma seguinte:
process begin if GUARD then <signal_transform> else <disconnection_statements> end if wait on GUARD, ... end process
Por exemplo:
block (ON = '1') begin R <= guarded S B <= guarded A and B end block
tem como processos equivalentes:

block (ON = '1') begin process if GUARD then R <= S else
46
R <= null end if wait on S end process process if GUARD then B <= A and B else B <= null end if wait on A, B end process end block
Quando um sinal de genro register e deconectado, ele ca com seu valor atual. Quando um sinal de genro bus e deconectado, ele volta a ter seu valor inicial.
5.5 Instruc~ ao concorrente de chamada de procedimento

A sintaxe de uma chamada concorrente de procedimento e:
<concurrent_procedure_call_statement> ::= <label> : ] postponed ] <procedure_call>
O processo equivalente tem uma chamada de procedimento sequencial seguida de uma instruc~ ao de espera, com uma lista de sensibilidade que contem todos os sinais aparecendo como par^ ametros efetivos da chamada.
process begin <procedure_call> wait on <sensitivity_list> end process
5.6 Instruc~ ao concorrente de asserc~ ao

A sintaxe de uma asserc~ ao concorrente e:
<concurrent_assertion_statement> ::= <label> : ] postponed ] <assertion>
O processo equivalente tem uma asserc~ ao sequencial seguida de uma instruc~ ao de espera, com uma lista de sensibilidade que contem todos os sinais aparecendo na condic~ ao da asserc~ ao.
5.7. Instruc~ ao de instanciac~ ao de componente

process begin <procedure_call> wait on <sensitivity_list> end process
47
5.7 Instruc~ ao de instanciac~ ao de componente

A sintaxe de uma instruc~ ao de instanciac~ ao de componente e:
<component_instantiation_statement> ::= <label> : <instantiated_unit> <generic_map_aspect> ] <port_map_aspect> ] <instantiated_unit> ::= component ] <component_name> | entity <entity_name> (<architecture_identifier>) ] | configuration <configuration_name>
Ver o cap tulo 2 para mais informac~ oes.
5.8 Instruc~ ao de gerac~ ao

A instruc~ ao de gerac~ ao permite de nir condicionalmente ou repetitivamente partes de um sistema:
<generate_statement> ::= <label> : <generation_scheme> generate { <block_declarative_item>} begin ] { concurrent_statement } end generate <label> ] <generation_scheme> ::= for <parameter_specification> | if <condition>
Por exemplo:
GEN: block begin L1: CELL port map (TOP, BOTTOM, A(0), B(0))
48
L2: for I in 1 to 3 L3: for J in 1 to L4: if (I + J > L5: CELL port end generate end generate end generate L6: for I in 1 to 3 L7: for J in 1 to L8: if (I + J < L9: CELL port end generate end generate end generate end block

generate 3 generate 4) generate map (A(I-1), B(J-1), A(I), B(J))
generate 3 generate 4) generate map (A(I+1),B(J+1),A(I),B(J))
6. O sistema de tipos
6.1 Introduc~ ao
Nesse cap tulo abordamos o sistema de tipo de VHDL. Um tipo e um conjunto de valores e de operac~ oes. A linguagem VHDL permite de nir varias classes de tipos: tipos escalares (enumerados, inteiros, f sicos, v rgula utuante), tipos compostos (arrangos e registros), tipos acesso e tipos arquivo. VHDL tem tambem a noc~ ao de subtipo, que corresponde a um subconjunto dos valores do tipo de base correspondente. A linguagem VHDL tem alguns tipos prede nidos e permite ao usuario criar novos tipos ou subtipos com declarac~ oes de tipos e de subtipos:
<type_declaration> ::= type <identifier> is <type_definition> type A is range 1 to 10 type B is range 1 to 10 <subtype_declaration> ::= subtype <identifier> is <subtype_indication> <subtype_indication> ::= <resolution_function_name> ] <type_name> <constraint> ] <contraint> ::= <range_constraint> | <index_constraint> subtype NATURAL is INTEGER range 0 to INTEGER'HIGH subtype WORD is BIT_VECTOR (0 to WORD_SIZE)
6.2 Tipos escalares

Os elementos de um tipo escalar s~ ao ordenados. Uma faixa especi ca um subconjunto de valores de um tipo escalar:
<range_constraint>::= range <range> <range> ::= <range_attribute_name> | <expression> <direction> <expression> <direction> ::= to | downto
Um exemplo de nome de atributo faixa e RANGE. 49
50
Cap tulo 6. O sistema de tipos
6.2.1 Tipos enumerados

Exemplos:
type MULTI_LEVEL_LOGIC is (LOW, HIGH, RISING, FAILING) type BIT is ('0', '1') type SWITCH_LEVEL is ('0', '1', 'X')
Sintaxe:
<enumeration_type_definition> ::= ( <enumeration_literal> {, <enumeration_literal>} ) <enumeration_literal> ::= <character_literal> | <identifier>
Um mesmo literal ou identi cador pode pertencer a varios tipos diferentes. Cada elemento de um tipo enumerado tem uma posic~ ao, comecando pela posic~ ao 0 pelo primeiro elemento, e a posic~ ao dos demais elementos e 1 a mais que a posic~ ao do elemento precedente. Os tipos enumerados prede nidos na linguagem s~ ao os tipos CHARACTER, BIT, BOOLEAN, SEVERITY_LEVEL, FILE_OPEN_KIND e FILE_OPEN_STATUS.
6.2.2 Tipos inteiros

Exemplos:
type TWOS_COMPLEMENT_INTEGER is range -32768 to 32767 type BYTE_LENGTH_INTEGER is range 0 to 255 type WORD_INDEX is 31 downto 0 subtype HIGH_BIT_LOW is BYTE_LENGTH_INTEGER range 0 to 127 <integer_type_definition> ::= <range_constraint>
Um tipo e ascendente se ele e de nido com a direc~ ao to, sen~ ao ele e descendente.
6.2.3 Tipos f sicos

Exemplo:
type DISTANCE is range 0 to 1E16 units -- unidade primaria A -- angstrom -- unidades segundarias metricas nm = 10 A -- nanometro
6.2. Tipos escalares

um mm cm m km = = = = = 1000 nm 1000 um 10 mm 1000 mm 1000 m -----micrometro milimetro centimetro metro kilometro
51
-- unidades segundarias inglesas mil = 254000 A -- mil inch= 1000 mil -- polegada ft = 12 inch -- pe yd = 3 ft -- yard mi = 5280 ft -- milha lg = 3 mi -- liga end units <physical_type_definition> ::= <range_constraint> units <primary_unit_declaration> { <secondary_unit_declaration> } end units <primary_unit_declaration> ::= <identifier> <secondary_unit_declaration> ::= <identifier> = <physical_literal> <physical_literal> ::= <abstract_literal> ] <unit_name>
O unico tipo f sico prede nido e o tipo TIME.
6.2.4 Tipos v rgula utuante

Exemplos:
type PROBABILITY is range 0.0 to 1.0 type SIGNAL_LEVEL is range -10.00 to 10.00 <floating_point_type_definition> ::= <range_constraint>
O unico tipo v rgula utuante prede nido e o tipo incluir -1E38 e 1E38
REAL,
cuja faixa deve
52
6.3 Tipos compostos

6.3.1 Tipos arranjos
Um arranjo em VHDL e uma colec~ ao indicada de elementos que s~ ao todos do mesmo tipo. Eles podem ser unidimensional ou multidimensionais. Um tipo arranjo pode ser constrito, e neste caso o valor do ndice e restrito a uma certa faixa, ou n~ ao constrito. Exemplos: unidimensionais constritos:
type WORD is array (31 downto 0) of BIT type MEMORY is array (ADDRESS) of WORD type REGISTER_BANK is array (BYTE range 0 to 127) of REGISTER
unidimensionais n~ ao constritos:
type BIT_VECTOR is array (NATURAL range <>) of BIT type STRING is array (POSITIVE range <>) of CHARACTER
tipos multidimensionais:
type TRANSFORM_MATRIX is array (1 to 4, 1 to 4) of REAL
A sintaxe e:
<array_type_definition> ::= <unconstrained_array_definition> | <constrained_array_definition> <unconstrained_array_definition> ::= array ( <index_subtype_definition> { , <index_subtype_definition> } ) of <element_subtype_indication> <constrained_array_definition> ::= array <index_constraint> of <element_subtype_indication> <index_subtype_definition> ::= <type_mark> range <> <index_constraint> ::= ( <discrete_range> { , <discrete_range> } ) <discrete_range> ::= <discrete_subtype_indication> | <range>
Para denotar um valor de um tipo arranjo, s~ ao usados agregados por posic~ ao, ou por nome. Por exemplo, seja o tipo seguinte:
type A is array (1 to 4) of CHARACTER
6.4. Tipos acesso Um agregado por posic~ ao e
53
('d','i','c','a'), e um agregado por nome e (1=>'d', 3=>'c', 2=>'i', 4=>'a'). E tambem poss vel mixturar notac~ oes e usar others no lugar de um ndice na notac~ ao por nome: ('f', 4=>'d', others => 'o').
Para denotar que todos os elementos s~ ao atribuidos um valor, e usado a forma por defaut (others => ' '). Para selecionar parte de um arranjo ou um unico elemento, s~ ao usadas parenteses: reg(31 downto 16) e uma parte do arranjo inicial, e reg(31) e um unico elemento desse arranjo.
6.3.2 Tipos registros
Existe tambem a possibilidade de de nir tipos registros em VHDL. Um tipo registro e uma colec~ ao nomeada de elementos de diferentes tipos. Por exemplo:
type INSTRUCTION is record OP_CODE: PROCESSOR_OP ADDRESS_MODE: MODE OPERAND1, OPERAND2: INTEGER range 0 to 15 end record <record_type_definition> ::= record <element_declaration> { <element_declaration> } end record <record_type_simple_name> ] <element_declaration> ::= <identifier_list> : <element_subtype_definition> <identifier_list> ::= <identifier> { , <identifier> } <element_subtype_definition> ::= <subtype_indication>
E poss vel usar agregados para denotar valores constantes de tipo registro, usando posic~ ao ou nome. Para selecionar parte de um registro, usa-se o operador ..
6.4 Tipos acesso

Ponteiros fazem parte da linguagem VHDL sob o nome de tipos acesso. O ponteiro nulo e designado por null, e a alocac~ ao de memoria e realizada com o operador new. Desalocac~ ao e realizada com o procedimento DEALLOCATE. So variaveis podem ser de tipo acesso. Exemplos:
type ADDRESS is access MEMORY
54
type BUFFER is access TEMP_BUFFER type CELL type LIST is access CELL type CELL is record VALUE: INTEGER SUCC: LIST PRED: LIST end record CELL variable HEAD: LIST := new CELL'(0, null, null) variable SUCC: LIST := HEAD.SUCC variable L1, L2: LIST variable C: CELL L2 := L1 L1 := L1.SUCC C := L2.all -- L1 e L2 designam o mesmo objeto. -- all dereferencia explicitamente o objeto referenciado
6.5 Tipos arquivo (VHDL-93)

Em VHDL-87, entradas-saidas s~ ao de nidas atraves do pacote TEXTIO. Tipos arquivos s~ ao usados para de nir objetos que correspondem a arquivos no ambiente de uso. Eles s~ ao geralmente usados para armazenar resultados de simulac~ ao, ou vetores de testes. Exemplos:
file of STRING file of NATURAL -- tipo arquivo podendo conter STRING -- tipo arquivo podendo conter NATURAL.
A sintaxe e:
<file_type_definition> ::= file of <type_mark>
Operac~ oes:
type FILE_OPEN_KIND is (READ_MODE, WRITE_MODE, APPEND_MODE) type FILE_OPEN_STATUS is (OPEN_OK, STATUS_ERROR, NAME_ERROR, MODE_ERROR) type FT is file of TM procedure FILE_OPEN (file F: FT filename: in STRING mode: in FILE_OPEN_KIND := READ_MODE) procedure FILE_OPEN (status: out FILE_OPEN_STATUS file F: FT
6.5. Tipos arquivo (VHDL-93)

filename: in STRING mode: in FILE_OPEN_KIND := READ_MODE) procedure FILE_CLOSE (file F: FT) procedure READ (file F: FT VALUE: out TM) procedure READ (file F: FT VALUE: out TM LENGTH: out NATURAL) procedure WRITE (file F: FT VALUE: in TM) function ENDFILE (file F: FT) return BOOLEAN
55
56
Ref^ erencias
Description and Simulation of Hardware Design Using VHDL. Dominique Borrione. Notas de aula do DEA Microelectronique, Universite Joseph Fourier, Grenoble, France. Outubro 1989, revisado Janeiro 1997. The VHDL Cookbook. First Edition. Peter J. Ashenden. Dept Computer Science. University of Adelaide. Australia. 1990. An Introductory VHDL Tutorial. Green Mountain Computing Systems. 1995. http://together.net/~thibault/tutorial.htm VHDL Language Reference Manual | Std 1076-1993. IEEE. 1994. Editora IEEE Press.
57
58
A. Gramatica da linguagem
VHDL-93
A.1 Design entities

entity_declaration ::= entity identifier is entity_header entity_declarative_part begin entity_statement_part ] end entity ] entity_simple_name ] entity_header ::= formal_generic_clause ] formal_port_clause ] generic_clause ::= generic ( generic_list )
port_clause ::= port ( port_list ) generic_list ::= generic_interface_list port_list ::= port_interface_list entity_declarative_item ::= subprogram_declaration | subprogram_body | type_declaration | subtype_declaration | constant_declaration | signal_declaration | shared_variable_declaration | file_declaration | alias_declaration | attribute_declaration
59
60
| | | | |
Ap^ endice A. Gramatica da linguagem VHDL-93

attribute_specification disconnection_specification use_clause group_template_declaration group_declaration
entity_declarative_part ::= { entity_declarative_item } entity_statement ::= concurrent_assertion_statement | passive_concurrent_procedure_call_statement | passive_process_statement entity_statement_part ::= { entity_statement } architecture_body ::= architecture identifier of entity_name is architecture_declarative_part begin architecture_statement_part end architecture ] architecture_simple_name ] architecture_declarative_part ::= { block_declarative_item } architecture_statement_part ::= { concurrent_statement } configuration_declaration ::= configuration identifier of entity_name is configuration_declarative_part block_configuration end configuration ] configuration_simple_name ] configuration_declarative_item ::= use_clause | attribute_specification | group_declaration configuration_declarative_part ::= { configuration_declarative_item } block_configuration ::= for block_specification
A.2. Subprograms and Packages

{ use_clause } { configuration_item } end for block_specification ::= architecture_name | block_statement_label | generate_statement_label index_specification ::= discrete_range | static_expression configuration_item ::= block_configuration | component_configuration component_configuration ::= for component_specification binding_indication ] block_configuration ] end for
61
( index_specification ) ]
A.2 Subprograms and Packages

subprogram_declaration ::= subprogram_specification subprogram_specification ::= procedure designator ( formal_parameter_list ) ] | pure | impure ] function designator ( formal_parameter_list ) ] return type_mark designator ::= identifier | operator_symbol
operator_symbol ::= string_literal formal_parameter_list ::= parameter_interface_list subprogram_declarative_part ::= { subprogram_declarative_item } subprogram_declarative_item ::= subprogram_declaration
62
| | | | | | | | | | | |

subprogram_body type_declaration subtype_declaration constant_declaration variable_declaration file_declaration alias_declaration attribute_declaration attribute_specification use_clause group_template_declaration group_declaration
subprogram_body ::= subprogram_specification is subprogram_declarative_part begin subprogram_statement_part end subprogram_kind ] designator ] subprogram_kind ::= procedure | function subprogram_statement_part ::= { sequential_statement } package_declaration ::= package identifier is package_declarative_part end package ] package_simple_name ] package_declarative_part ::= { package_declarative_item } package_declarative_item ::= subprogram_declaration | type_declaration | subtype_declaration | constant_declaration | signal_declaration | shared_variable_declaration | file_declaration | alias_declaration | component_declaration | attribute_declaration | attribute_specification | disconnection_specification
A.3. Types
| use_clause | group_template_declaration | group_declaration package_body ::= package body package_simple_name is package_body_declarative_part end package body ] package_simple_name ] package_body_declarative_part ::= { package_body_declarative_item } package_body_declarative_item ::= subprogram_declaration | subprogram_body | type_declaration | subtype_declaration | constant_declaration | shared_variable_declaration | file_declaration | alias_declaration | use_clause | group_template_declaration | group_declaration
63
A.3 Types
scalar_type_definition ::= enumeration_type_definition | floating_type_definition | integer_type_definition | physical_type_definition enumeration_type_definition ::= ( enumeration_literal { , enumeration_literal } ) enumeration_literal ::= identifier | character_literal integer_type_definition ::= range_constraint range_constraint ::= range range range ::= range_attribute_name | simple_expression direction simple_expression direction ::= to | downto
64
physical_type_definition ::= range_constraint units base_unit_declaration { secondary_unit_declaration } end units physical_type_simple_name ] base_unit_declaration ::= identifier secondary_unit_declaration ::= physical_literal ::= identifier = physical_literal
abstract_literal ] unit_name := range_constraint
floating_type_definition
composite_type_definition ::= array_type_definition | record_type_definition array_type_definition ::= unconstrained_array_definition
constrained_array_definition
unconstrained_array_definition ::= array ( index_subtype_definition { , index_subtype_definition } ) of element_subtype_indication constrained_array_definition ::= array index_constraint of element_subtype_indication index_subtype_definition ::= type_mark range <> index_constraint ::= ( discrete_range { , discrete_range } ) discrete_range ::= discrete_subtype_indication | range record_type_definition ::= record element_declaration { element_declaration } end record record_type_simple_name ] element_declaration ::= identifier_list : element_subtype_definition identifier_list ::= identifier { , identifier }
A.4. Declarations
element_subtype_definition ::= subtype_indication access_type_definition ::= access subtype_indication file_type_definition ::= file of type_mark
65
A.4 Declarations
declaration ::= type_declaration | subtype_declaration | object_declaration | interface_declaration | alias_declaration | attribute_declaration | component_declaration | group_template_declaration | group_declaration | entity_declaration | configuration_declaration | subprogram_declaration | package_declaration type_declaration ::= full_type_declaration | incomplete_type_declaration full_type_declaration ::= type identifier is type_definition incomplete_type_declaration ::= type identifier
type_definition ::= scalar_type_definition | composite_type_definition | access_type_definition | file_type_definition subtype_declaration ::= subtype identifier is subtype_indication subtype_indication ::= resolution_function_name ] type_mark
constraint ]
66
type_mark ::= type_name | subtype_name
constraint ::= range_constraint | index_constraint object_declaration ::= constant_declaration | signal_declaration | variable_declaration | file_declaration constant_declaration ::= constant identifier_list : subtype_indication signal_declaration ::= signal identifier_list : subtype_indication signal_kind ::= register | bus
:= expression ]
signal_kind ]
:= expression ]
variable_declaration ::= shared ] variable identifier_list : subtype_indication
:= expression ]
file_declaration ::= file identifier_list : subtype_indication file_open_information ] file_open_information ::= open file_open_kind_expression ] is file_logical_name file_logical_name ::= string_expression interface_declaration ::= interface_constant_declaration | interface_signal_declaration | interface_variable_declaration | interface_file_declaration interface_constant_declaration ::= constant ] identifier_list :
in ] subtype_indication
:= static_expression
interface_file_declaration ::= file identifier_list : subtype_indication
A.4. Declarations
interface_signal_declaration ::= signal] identifier_list : interface_variable_declaration ::= variable] identifier_list : mode ] subtype_indication
67
bus ] := static_expression ]
mode ] subtype_indication
:= static_expression ]
mode ::= in | out | inout | buffer | linkage interface_list ::= interface_element {
interface_element }
interface_element ::= interface_declaration association_list ::= association_element { , association_element } association_element ::= formal_part => ] actual_part formal_part ::= formal_designator | function_name ( formal_designator ) | type_mark ( formal_designator ) formal_designator ::= generic_name | port_name | parameter_name actual_part ::= actual_designator | function_name ( actual_designator ) | type_mark ( actual_designator ) actual_designator ::= expression | signal_name | variable_name | file_name | open alias_declaration ::= alias alias_designator
: subtype_indication ] is name
signature ]
alias_designator ::= identifier | character_literal | operator_symbol
68
attribute_declaration ::= attribute identifier : type_mark component_declaration ::= component identifier is ] local_generic_clause ] local_port_clause ] end component component_simple_name ] group_declaration ::= group identifier : group_template_name ( group_constituent_list ) group_constituent_list ::= group_constituent { , group_constituent } group_constituent ::= name | character_literal group_template_declaration ::= group identifier is ( entity_class_entry_list ) entity_class_entry ::= entity_class <> ]
entity_class_entry_list ::= entity_class_entry { , entity_class_entry }
A.5 Speci cations

attribute_specification ::= attribute attribute_designator of entity_specification is expression entity_specification ::= entity_name_list : entity_class entity_name_list ::= entity_designator { , entity_designator } | others | all entity_designator ::= entity_tag entity_tag ::= signature ]
simple_name | character_literal | operator_symbol
entity_class ::= entity | procedure | type
| architecture | function | subtype
| configuration | package | constant
A.6. Names
| signal | label | group | variable | literal | file | component | units
69
configuration_specification ::= for component_specification binding_indication component_specification ::= instantiation_list : component_name instantiation_list ::= instantiation_label { , instantiation_label } | others | all binding_indication ::= use entity_aspect ] generic_map_aspect ] port_map_aspect ] entity_aspect ::= entity entity_name ( architecture_identifier) ] | configuration configuration_name | open generic_map_aspect ::= generic map ( generic_association_list ) port_map_aspect ::= port map ( port_association_list ) disconnection_specification ::= disconnect guarded_signal_specification after time_expression guarded_signal_specification ::= guarded_signal_list : type_mark
A.6 Names
name ::= simple_name | operator_symbol | selected_name | indexed_name | slice_name
70
| attribute_name simple_name ::=
identifier
selected_name ::= prefix . suffix prefix ::= name | function_call suffix ::= simple_name | character_literal | operator_symbol | all function_call ::= function_name
( actual_parameter_part ) ]
actual_parameter_part ::= parameter_association_list indexed_name ::= prefix ( expression { , expression } ) slice_name ::= prefix ( discrete_range )
attribute_name ::= prefix signature ] ' attribute_designator signature ::= type_mark { , type_mark } ]
( expression ) ]
return type_mark ] ]
attribute_designator ::= attribute_simple_name
A.7 Expressions
expression ::= relation | relation | relation | relation | relation | relation { and relation } { or relation } { xor relation } nand relation ] nor relation ] { xnor relation }
relation ::= shift_expression
relational_operator shift_expression ]
A.7. Expressions
shift_expression ::= simple_expression shift_operator simple_expression ]
71
shift_operator ::= sll | srl | sla | sra | rol | ror simple_expression ::= sign ] term { adding_operator term } sign ::= + | term ::= factor { multiplying_operator factor } factor ::= primary ** primary ] | abs primary | not primary primary ::= name | literal | aggregate | function_call | qualified_expression | type_conversion | allocator | ( expression ) allocator ::= new subtype_indication | new qualified_expression type_conversion ::= type_mark ( expression ) relational_operator ::= adding_operator ::= + | = | /= | < | <= | > | >=
| &
multiplying_operator ::= * | / | mod | rem literal ::= numeric_literal | enumeration_literal | string_literal | bit_string_literal | null
72
numeric_literal ::= abstract_literal | physical_literal aggregate ::= ( element_association { , element_association } ) element_association ::= choices => ] expression choices ::= choice { | choice } choice ::= simple_expression | discrete_range | element_simple_name | others qualified_expression ::= type_mark ' ( expression ) | type_mark ' aggregate
A.8 Sequential statements

sequence_of_statements ::= { sequential_statement } sequential_statement ::= wait_statement | assertion_statement | report_statement | signal_assignment_statement | variable_assignment_statement | procedure_call_statement | if_statement | case_statement | loop_statement | next_statement | exit_statement | return_statement | null_statement wait_statement ::= label : ] wait
sensitivity_clause ]
condition_clause ]
timeout_clause ]
A.8. Sequential statements

label ::= identifier sensitivity_clause ::= on sensitivity_list
73
sensitivity_list ::= signal_name { , signal_name } condition_clause ::= until condition timeout_clause ::= for time_expression assertion_statement ::= label : ] assertion
assertion ::= assert condition report expression ] severity expression ] signal_assignment_statement ::= label : ] target <= delay_mechanism ] waveform target ::= name | aggregate delay_mechanism ::= transport | reject time_expression ] inertial waveform ::= waveform_element { , waveform_element } | unaffected waveform_element ::= value_expression after time_expression ] | null after time_expression ] variable_assignment_statement ::= label : ] target := expression procedure_call ::= procedure_name procedure_call_statement ::= label : ] procedure_call if_statement ::= ( actual_parameter_part ) ]
74

if_label : ] if condition then sequence_of_statements { elsif condition then sequence_of_statements } else sequence_of_statements ] end if if_label ]
condition ::= boolean_expression case_statement ::= case_label : ] case expression is case_statement_alternative { case_statement_alternative } end case case_label ] case_statement_alternative ::= when choices => sequence_of_statements loop_statement ::= loop_label : ] iteration_scheme ] loop sequence_of_statements end loop loop_label ] iteration_scheme ::= while condition | for loop_parameter_specification parameter_specification ::= identifier in discrete_range next_statement ::= label : ] next exit_statement ::= label : ] exit return_statement ::= label : ] return null_statement ::=
loop_label ]
when condition ]
loop_label ]
when condition ]
expression ]
label : ] null
A.9. Concurrent statements

report_statement ::= label : ] report expression severity expression ]
75
A.9 Concurrent statements

concurrent_statement ::= block_statement | process_statement | concurrent_procedure_call_statement | concurrent_assertion_statement | concurrent_signal_assignment_statement | component_instantiation_statement | generate_statement block_statement ::= block_label : block
( guard_expression ) ] block_header block_declarative_part
is ]
begin block_statement_part end block block_label ]
block_header ::= generic_clause generic_map_aspect ] ] port_clause port_map_aspect ] ] block_declarative_part ::= { block_declarative_item } block_declarative_item ::= subprogram_declaration | subprogram_body | type_declaration | subtype_declaration | constant_declaration | signal_declaration | shared_variable_declaration | file_declaration | alias_declaration
76
| | | | | | | |

component_declaration attribute_declaration attribute_specification configuration_specification disconnection_specification use_clause group_template_declaration group_declaration
block_statement_part ::= { concurrent_statement } process_statement ::= process_label : ] postponed ] process ( sensitivity_list ) ] process_declarative_part begin process_statement_part end postponed ] process process_label ] process_declarative_part ::= { process_declarative_item } process_declarative_item ::= subprogram_declaration | subprogram_body | type_declaration | subtype_declaration | constant_declaration | variable_declaration | file_declaration | alias_declaration | attribute_declaration | attribute_specification | use_clause | group_template_declaration | group_declaration process_statement_part ::= { sequential_statement } concurrent_procedure_call_statement ::= label : ] postponed ] procedure_call concurrent_assertion_statement ::= label : ] postponed ] assertion
is ]
A.9. Concurrent statements
77
concurrent_signal_assignment_statement ::= label : ] postponed ] conditional_signal_assignment | label : ] postponed ] selected_signal_assignment conditional_signal_assignment ::= target <= options conditional_waveforms conditional_waveforms ::= { waveform when condition else } waveform when condition ] selected_signal_assignment ::= with expression select target <= options selected_waveforms options ::= guarded ] delay_mechanism ]
selected_waveforms ::= { waveform when choices , } waveform when choices component_instantiation_statement ::= instantiation_label : instantiated_unit generic_map_aspect ] port_map_aspect ] instantiated_unit ::= component ] component_name | entity entity_name ( architecture_identifier ) ] | configuration configuration_name generate_statement ::= generate_label : generation_scheme generate { block_declarative_item } begin ] { concurrent_statement } end generate generate_label ] generation_scheme ::= for generate_parameter_specification | if condition
78
A.10 Scope and visibility

use_clause ::= use selected_name { , selected_name }
A.11 Design units and their analysis

design_file ::= design_unit { design_unit } design_unit ::= context_clause library_unit context_clause ::= { context_item } context_item ::= library_clause | use_clause library_clause ::= library logical_name_list logical_name_list ::= logical_name { , logical_name } logical_name ::= identifier library_unit ::= primary_unit | secondary_unit primary_unit ::= entity_declaration | configuration_declaration | package_declaration secondary_unit ::= architecture_body | package_body
A.12 Lexical elements

abstract_literal ::= decimal_literal | based_literal base ::= integer base_specifier ::= based_integer ::= B | O | X
A.12. Lexical elements

extended_digit { underline ] extended_digit }
79
based_literal ::= base # based_integer
. based_integer ] #
exponent ]
basic_character ::= basic_graphic_character | format_effector basic_graphic_character ::= upper_case_letter | digit | special_character| space_character basic_identifier ::= letter { underline ] letter_or_digit } bit_string_literal ::= base_specifier " bit_value "
string_literal ::= " { graphic_character } " bit_value ::= extended_digit { underline ] extended_digit }
character_literal ::= ' graphic_character '
decimal_literal ::= integer
. integer ]
exponent ]
letter ::= upper_case_letter | lower_case_letter letter_or_digit ::= letter | digit exponent ::= E + ] integer | E - integer
extended_digit ::= digit | letter extended_identifier ::= \ graphic_character { graphic_character } \ integer ::= digit { underline ] digit }
identifier ::= basic_identifier | extended_identifier graphic_character ::= basic_graphic_character
| lower_case_letter | other_special_character

Apostila de VHDL

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Apostila de VHDL

Diunggah oleh

Hak Cipta:

Format Tersedia

VHDL Notas de aula (semestre 98.

2 Organizac~ ao e utilizac~ ao de descric~ oes VHDL

3 Processos, sinais e simulac~ ao

5.5 5.6 5.7 5.8

A Gramatica da linguagem VHDL-93

1.1.2 A historia de VHDL

Cap tulo 1. Introduc~ ao

1.2 O que e uma linguagem de descric~ ao de hardware ?

1.2.1 O que e VHDL ?

1.3. Introduc~ ao aos princ pios de concepc~ ao de VHDL

1.3 Introduc~ ao aos princ pios de concepc~ ao de VHDL

O modelo de simulac~ ao VHDL

1.5.1 Identi cadores

VHDL 93 O novo padr~ ao VHDL de ne a noc~ ao de identi cador basico (basic

Cap tulo 1. Introduc~ ao

{ literais inteiros { literais reais

{ o inteiro 196 { o real 4095.0

1.5. Convenc~ oes lexicogra cas

1.5.4 Cadeias de carateres

1.5.5 Cadeias de bits

Cap tulo 1. Introduc~ ao

de descric~ oes VHDL

2.1 Unidades de concepc~ ao

Cap tulo 2. Organizac~ ao e utilizac~ ao de descric~ oes VHDL

2.2 Bibliotecas de concepc~ ao

2.3. Clausula de contexto

2.3 Clausula de contexto

clausulas de uso (use clause ) declaram nomes ou conjunto de nomes que

2.4 Elementos de descric~ ao estrutural

2.4. Elementos de descric~ ao estrutural

2.4.1 Declarac~ ao de componentes

Uma declarac~ ao de componente declara uma interface de entidade virtual. Exemplo:

2.4.2 Instanciac~ ao de componentes

2.4.3 Con gurac~ ao de componente

Cap tulo 2. Organizac~ ao e utilizac~ ao de descric~ oes VHDL

2.4. Elementos de descric~ ao estrutural

2.4.4 Declarac~ ao de con gurac~ ao

Cap tulo 2. Organizac~ ao e utilizac~ ao de descric~ oes VHDL

2.4.5 Instanciac~ ao direta de entidades de concepc~ ao

3.2 Elementos basicos do modelo de simulac~ ao

Cap tulo 3. Processos, sinais e simulac~ ao

3.2. Elementos basicos do modelo de simulac~ ao

Figura 3.1: Exemplo de func~ ao de resoluc~ ao

Transic~ oes n~ ao marcadas s~ ao apagadas. 1 2 12 12 18 NOW +3ns +13 ns +20 ns + 41 ns

Discuss~ ao Ha ent~ ao dois modos de atribuic~ ao: inercial e transporte. O modo

Cap tulo 3. Processos, sinais e simulac~ ao

O <= reject 5 ns inertial not I after 7 ns

3.3. O algoritmo de simulac~ ao

e o tempo maximo que o processo ca es-

until <condic~ ao>,

3.3 O algoritmo de simulac~ ao

Cap tulo 3. Processos, sinais e simulac~ ao

3.3.1 Mais noc~ oes ligadas a sinais

3.3.2 A fase de inicializac~ ao

3.3.3 O ciclo de simulac~ ao

3.3. O algoritmo de simulac~ ao 5. Tn e atribuido o menor de

Cap tulo 3. Processos, sinais e simulac~ ao

3.3. O algoritmo de simulac~ ao

Cap tulo 3. Processos, sinais e simulac~ ao

Cap tulo 4. Programac~ ao sequencial

4.4. Instruc~ ao de asserc~ ao

E prohibido declarar sinais numa rotina.

4.4 Instruc~ ao de asserc~ ao

4.5 Instruc~ ao de relatorio