Projeto de Sistemas Digitais FEUP 2006/2007

FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007
José Carlos Alves
1
Projecto de Sistemas Digitais
(EEC0055)
Licenciatura em Engenharia Electrotécnica e de Computadores
Faculdade de Engenharia da Universidade do Porto
Departamento de Engenharia Electrotécnica e de Computadores
5º ano, 1º semestre
José Carlos Alves
António José Araújo
http://www.fe.up.pt/~aja/PSD2006_07
José Carlos Alves
2
Projecto de Sistemas Digitais
• Tecnologias digitais cada vez mais importantes
– vastas áreas de aplicação
– evolução tecnológica exponencial (lei de Moore)
• tamanho, consumo, rapidez
– custo continua a descer (um PC custa 1000€!)
• Um sistema (electrónico) digital deve ser…
(numa perspectiva industrial)
– bom: satisfazer a funcionalidade com fidelidade e fiabilidade
– barato: custo mais baixo possível, sem comprometer a
qualidade
• Projectar um SD
– “if it wasn’t hard they wouldn’t call it hardware”, J.F. Wakerly
– ferramentas computacionais ajudam “the little gray cells”
mas não substituem

José Carlos Alves
3
Fluxo de projecto (típico)
Ideia
sistema (abstracto)
circuito (RTL – lógico)
mapeamento
tecnológico
validação
validação fabrico
teste
/dev/null
D
Q
D
Q
um controlador de
intensidade luminoas para
ligar e desligar luzes de
casa sempre que anguem
entra ou sai da casota do
cao que se chama bobi e
tem tambem um gato que
se chama tareco
1 - receptor
2 - um cpu para calcular a luz
3 - interface de potência
int
er
fac
e
processador
memória
validação
IC
always @(posedge clock or posedge reset)
begin
case(state)
start: begin if ( enable) ready <= 1;
else ready <= 0;
state <= waitfor;
end
endcase
end
José Carlos Alves
4
Concepção
• Ideia
– clarificar e estruturar a ideia, definir especificações
• um produto é muito mais do que o sistema digital
• por vezes um projecto é iniciado com especificações incompletas
• Exequibilidade
– boas ideias podem não ser praticáveis
• custo ou risco elevado
• tecnologia não acessível, não dominada ou não adequada
• tempo de desenvolvimento demasiado longo
• Implementação
– Parte do projecto pode ser independente da tecnologia alvo...
– ...mas deve ser decidida o mais cedo possível no ciclo de projecto

José Carlos Alves
5
Aspectos tecnológicos
• Que tecnologia?
– ASIC, FPGA, componentes off-the-shelf?
• Particionamento arquitectural
– um sistema pode não “caber” num único componente
• tamanho, número de terminais, tecnologia de fabrico
• divisão da funcionalidade (por exemplo analógico vs. digital)
• selecção dos componentes e da tecnologia de montagem
memória
interface
co-proc
CPU
I/O proc
funcionalidade
rapidez
disponibilidade
número de pinos
encapsulamento
fabricante(s)
PCB
COB
MCM
wire-wrap
ASIC
RAM
mP
LSI
José Carlos Alves
6
Tecnologias disponíveis
(para implementar sistemas digitais)
• ASIC (CMOS)
– Centenas de MHz, baixo consumo, custos fixos elevados
– Densidades: 250K gates/mm2 (90nm), 320K (65nm)
• FPGA
– Centenas de MHz, consumo elevado, sem custos fixos
– Reconfiguráveis!
– 10.000.000 gates (equivalentes…) num único chip
• Microcontroladores/microprocessadores
– Baixo custo, baixo desempenho, programáveis
– Muitas configurações com variados periféricos
• Exemplos: os PIC da Microchip, muitos derivados do 8051
• Circuitos discretos
– Circuitos “off-the-shelf”, funcões específicas (ASICs)
– Circuitos integrados digitais para SSI e MSI (série 74…)

José Carlos Alves
7
Justifica-se um ASIC/FPGA?
• Alguns dos aspectos a ter em conta
– rapidez (MHz, MIPS, MFLOPS)
– consumo de energia
– tamanho físico
– custo (das ferramentas, prototipagem e produção)
– complexidade do projecto
– Flexibilidade (evoluções futuras?)
– fiabilidade
– testabilidade
– dissipação térmica
– compatibilidade electromagnética
– resistência mecânica
José Carlos Alves
8
Ferramentas computacionais
• CAD/CAE (Computer Aided Design/Computer Aided Engineering)
– fundamentais para projectar em tempo útil circuitos complexos
– Muitos problemas são NP-hard
• Ferramentas CAD/CAE
– trabalham com representações electrónicas de SDs (modelos)
– exemplos de ferramentas CAD/CAE
• captura esquemática (mais do que desenhar o circuito lógico...)
• síntese (layout, lógica, RTL, alto nível)
• desenho físico (layout), verificação de regras geométricas
• simulação lógica (verificação funcional)
• análise temporal
• simulação eléctrica
• modelação e simulação de faltas
• geração de vectores de teste
• análise térmica
• edição de texto (documentação e não só!)

José Carlos Alves
9
Modelos de circuitos digitais
• Representações electrónica de SDs
– usadas e transformadas por ferramentas CAD/CAE
• Um modelo é uma aproximação!
– que pode ser boa e pode ser má…
– rigor ⇒ detalhe ⇒ aproximação da tecnologia
– a simulação de um modelo nunca é igual ao seu
funcionamento real
• Modelos (frequentemente) tratados por humanos
– modelos estruturais (esquemáticos)
• detalham a estrutura do circuito, interligando “componentes”
– modelos comportamentais (HDLs, state charts, tabelas, BDDs)
• descrevem apenas o comportamento do sistema
José Carlos Alves
10
Y- chart
comportamental
estrutural
físico
placas, MCMs
módulos, chips
células
layout de
transistores
transistores
portas lógicas
registos, muxs
processadores,
memórias
fluxogramas,
algoritmos
transferências
entre registos
expressões
booleanas
funções de
transistores
d
i
s
p
o
s
i
t
i
v
o
l
ó
g
i
c
o
R
T
L
sistem
a
n
í
v
e
i
s
d
e
a
b
s
t
r
a
c
ç
ã
o

José Carlos Alves
11
Especificação de um SD
• Tradicionalmente…
– captura esquemática (estrutural)
• interligação de portas lógicas, flip-flops, componentes RTL,…
• bibliotecas de componentes específicas de uma tecnologia
• anotação do desenho com atributos
– nomes, parâmetros, restrições para implementação
• captura a estrutura (física) do circuito
• transformado de forma optimizada para uma tecnologia alvo
– tabelas de verdade, expressões booleanas (comportamental)
• conveniente para blocos de lógica combinacional ou FSMs
– minimização lógica
– codificação de estados
• representação textual, tradução automática para um circuito lógico
• independente do meio de implementação
José Carlos Alves
12
Especificação de um SD
• Actualmente...
– projecto a níveis de abstracção mais elevados
• representações comportamentais ao nível RTL e algorítmico
• linguagens normalizadas para descrição de hardware
– suportadas por ferramentas de síntese automática
– combinam modelação estrutural com comportamental
– permitem ao projectista abstrair-se da tecnologia alvo
– portabilidade e facilidade de manutenção e documentação
• redução do ciclo de projecto
– permite explorar melhor o espaço de soluções
– comparando com a programação de computadores...
código máquina
assembly
C, C++
layout
portas lógicas
HDLs
nível de
abstracção
crescente

José Carlos Alves
13
Projecto estruturado
• Hierarquia e modularidade
– conceitos semelhantes aos empregues em programação estruturada
– objectivos:
• estruturação do projecto
• permitir a reutilização de módulos
• facilitar a verificação do projecto
• simplificar a produção da documentação (geralmente esquecida!)
– “quanta” hierarquia ?
• critérios principais:
– funcionalidade e granularidade (complexidade dos módulos)
• uma diferença importante da hierarquia em software:
– não significa reduzir a complexidade do hardware
– geralmente “desaparece” em algum estágio da implementação
José Carlos Alves
14
Metodologias de projecto
• Abordagens típicas
– bottom-up (capture-and-simulation)
• hierarquia criada de baixo para cima (lógico ⇒ RTL ⇒ sistema)
• ciclo de projecto:
– desenhar os circuitos mais simples (ou usá-los se existirem)
– validar com simulação esses circuitos
– usá-los na construção de outros circuitos mais complexos
– top-down (describe-and-synthesize)
• hierarquia criada de cima para baixo (sistema ⇒ RTL ⇒ lógico)
• ciclo de projecto
– especificar o sistema de forma comportamental
– sintetizar e avaliar as soluções resultantes de diferentes restrições
– na prática usa-se uma mistura de top-down e bottom-up
manual
automático

José Carlos Alves
15
Validação do projecto
• Simulação funcional
– verificação funcional da especificação
• realizada a diferentes níveis de abstracção (sistema ou RTL)
• verificar que é satisfeita a funcionalidade desejada
• se não funciona? detecção e depuração de erros (debug)
• problemas:
– como definir os vectores de simulação ?
– como se sabe que o resultado é correcto ?
– quão exaustivo é o teste ?
– fontes de erro mais comuns
• especificações incompletas, ligações erradas ou nomes trocados
• uso incorrecto de ferramentas de síntese automática
• má organização das várias versões de um projecto
• os computadores não erram, os humanos sim…
• são humanos que criam as ferramentas de software!
José Carlos Alves
16
Validação do projecto
• Análise temporal
– circuitos lógicos introduzem atrasos
• a simulação dá resultados correctos considerando os atrasos ?
• qual o desempenho ?
• o que limita o desempenho ? Como se pode melhorar ?
– modelos de atrasos
• específicos de uma tecnologia
• dependem do circuito em que um componente se insere (fan-out)
• quanto mais completo é o modelo, mais complexa é a simulação
– tpLH, tpHL, tr, tf (mínimos, típicos e máximos)
• interligações também introduzem atrasos
– função do comprimento e da forma
– só são conhecidos após a implementação ao nível físico

José Carlos Alves
17
Implementação
• Síntese lógica
– Tradução automática de descrições abstractas (textuais)
– Resultado é um netlist que interliga blocos primitivos
• Portas lógicas, flip-flops, buffers, RAMs,…
• Cada bloco tem uma representação física determinada
• Place&Route
– Colocação física desses blocos numa área determinada
• Minimizar a área, maximizar as relações de proximidade
– Construir as interligações definidas no netlist
• Satisfazer restrições temporais, minimizar a área
– Sinais de relógio devem ser tratados à parte
• Ferramentas e processos dedicados para sinais desse tipo
José Carlos Alves
18
Teste
• Teste do sistema fabricado
– testar para quê?
• minimizar (→ 0%) o número de sistemas defeituosos vendidos
• detectar e diagnosticar defeitos de fabrico
• melhorar o sistema ou o processo produtivo
– como testar ?
• construir um modelo de faltas do circuito
• criar vectores de simulação que as consigam detectar
– saídas diferentes na presença ou ausência da falta
– ferramentas para ATPG - Automatic Test Pattern Generation
– teste é uma fatia importante do custo de produção
• projecto orientado para a testabilidade (DFT - Design for Testability)
• auto-teste (BIST - Built-in Self Test)
• teste de PCB (boundary scan test, norma IEEE 1149.1)

José Carlos Alves
19
Linguagens de descrição de hardware
• Modelação de um circuito (digital)
– descrições comportamentais permitem nível elevado de abstracção
– metodologia top-down: ferramentas de síntese automática
– representação textual: portabilidade, edição e documentação
– a favor do esquemático: “uma figura diz mais do que mil palavras”
• um esquema captura melhor a ideia estrutural
• ferramentas gráficas front-end produzem descrições em HDLs
– editores de esquemático: netlist em HDL (estrutural, gate-level ou RTL)
– editores de diagramas de estados: descrições sintetizáveis
– duas perspectivas na construção de um modelo
• descrever o seu funcionamento apenas para simulação
• construir uma descrição sintetizável ($monitor(…) não é sintetizável!)
– um modelo sintetizável deve descrever “bem” o seu funcionamento
– subsets das linguagens e regras de modelação dependem das ferramentas
José Carlos Alves
20
Verilog vs. VHDL - história
•VHDL
– ‘80: por necessidade de normalização, documentação e portabilidade, e DOD funda
projecto para criar linguagem de “programação” para descrever hardware
– ‘83: início do desenvolvimento do VHDL (IBM, Texas, Intermetrics)
– ‘87: o DOD impõe que todos os SDs fossem descritos em VHDL; standard IEEE 1076;
os sistemas electrónicos do F-22 foram um dos primeiros projectos em VHDL
– ‘93: VHDL é revisto e adoptado como o standard IEEE 1076 ’93
– ‘96: adopção generalizada por ferramentas EDA; package para ferramentas de síntese (IEEE
1076.3); modelação de bibliotecas para ASIC e FPGA (IEEE 1076.4)
•Verilog
– ‘81: Gateway Design Automation, Philip Moorby cria GenRad HDL e o simulador HILO
– ‘83: Gateway lançou a linguagem Verilog HDL e um simulador de Verilog
– ‘85: linguagem e simulador são enriquecidos (Verilog-XL)
– ‘87: Synopsys adopta Verilog como formato de entrada para ferramentas de síntese
– ‘89/’90: Cadence compra Gateway e separa o simulador da linguagem; a linguagem é
libertada para o domínio público; é criado o OVI (Open Verilog International)
– ‘93: neste ano, de todos os circuitos submetidos a fundições de silício, 85% foram
desenvolvidos e submetidos em Verilog.
– ‘95: Verilog é revisto e adoptado como o standard IEEE 1364

José Carlos Alves
21
Verilog e VHDL - comparação
• capacidade de modelação
– semelhante para modelos estruturais
– VHDL oferece melhor suporte para modelos abstractos e modelos de atrasos
– Verilog tem melhores construções para modelar ao nível lógico e primitivas
de bibliotecas de ASICs e FPGAs
• tipos de dados
– VHDL suporta tipos de dados abstractos criados pelo utilizador
– em Verilog os tipos são muito simples e mais próximos do hw (wire e reg)
• aprendizagem
– VHDL é fortemente tipada, menos intuitiva, mais verbosa (baseada em
ADA)
– Verilog é mais simples e menos verbosa (baseada em C)
• parametrização
– VHDL tem construções para parametrizar número de bits, replicar
estruturas e configurar modelos
– Verilog suporta apenas modelos com parâmetros, instanciação com
redefinição de parâmetros
José Carlos Alves
22
VHDL-Verilog (comportamental)
library IEEE;
use IEEE.STD_Logic_1164.all;
entity MUX_2_1 is
port(S1,A1,B1,S2,A2,B2,S3,A3,B3:in std_logic;
Y1,Y2,Y3:out std_logic);
end entity MUX_2_1;
architecture COND_DATA_FLOW of MUX_2_1 is
begin
Y1 <= A1 when S1=‘1’ else B1;
TWO_2_1_MUXES:
process(S2,A2,B2,S3,A3,B3)
begin
Y2<=B2;
if (S2=‘1’) then
Y2<=A2;
endif;
if (S3=‘1’) then
Y3<=A3;
else
Y3<=B3;
endif;
end process TWO_2_1_MUXES
end architecture COND_DATA_FLOW;
module MUX_2_1(S1,A1,B1,Y1,
S2,A2,B2,Y2,
S3,A3,B3,Y3);
input S1,A1,B1,S2,A2,B2,S3,A3,B3;
output Y1,Y2,Y3;
reg Y2,Y3;
assign Y1=S1?A1:B1;
always
@(S2 or A2 or B2 or S3 or A3 or B3)
begin
Y2=B2;
if (S2)
Y2=A2;
if (S3)
Y3=A3;
else
Y3=B3;
end
endmodule
VHDL Verilog

José Carlos Alves
23
VHDL-Verilog (estrutural)
library IEEE;
use IEEE.STD_Logic_1164.all;
entity HALF_ADDER is
port(a,b:in std_logic;
sum,carry:out std_logic);
end entity HALF_ADDER;
architecture STRUCT of HALF_ADDER is
component xor2
port(a,b:in std_logic; c:out std_logic);
end component;
component and2
port(a,b:in std_logic; c:out std_logic);
end component;
begin
X1: xor2 port map(a=>a,b=>b,c=>sum);
A1: and2 port map(a=>a,b=>b,c=>carry);
end STRUCT;
module HALF_ADDER(a,b,sum,carry);
input a,b;
output sum,carry;
xor X1(sum,a,b);
and A1(carry,a,b);
endmodule
VHDL Verilog
José Carlos Alves
24
Modelação em HDL
• Modelo sintetizável vs. modelo não sintetizável
– ferramentas de síntese automática inferem uma estrutura
• o modelo (comportamental ou estrutural) vai ser hardware
• regras, restrições e recomendações das ferramentas de síntese
– como é interpretado e traduzida a descrição em HDL
– simulação e implementação devem concordar
– construções específicas da tecnologia de implementação
– modelos não sintetizáveis
• não são traduzidos para hardware
• definem estímulos para simulação; monitorização de sinais
• modelam o comportamento de outros circuitos só para simulação
– circuito de relógio
– memórias ou CPUs
– circuitos de interface (por exemplo conversores A/D ou D/A)

José Carlos Alves
25
Modelação em HDLs
recomendações gerais
• Antes de iniciar a construção do modelo
– definir a arquitectura e estruturação do projecto (particionamento)
– ferramentas de síntese não processam bem circuitos muito grandes!
• Problemas de optimização são NP-completos
• Escrever o código de modo a reflectir a arquitectura
– estruturado em módulos e funções, ter em mente a reusabilidade
– favorecer a legibilidade: nomes, comentários, parêntesis, parâmetros
• Garantir a precisão da simulação
– deve traduzir fielmente o comportamento do hardware gerado
– modelar correctamente o comportamento das partes não sintetizáveis
José Carlos Alves
26
Verilog HDL (Hardware Description Language)
• Linguagem de descrição de hardware (digital)
– Suporta modelação em diferentes níveis de abstracção
– criada para modelação e simulação de circuitos digitais
– actualmente usada como fonte para ferramentas de síntese
– modelos estruturais e modelos comportamentais
– não é uma linguagem de programação!
• Unidade básica de um modelo em Verilog:
– module: um sub-circuito definido por:
• interface (entradas e saídas)
• implementação (modelo do circuito digital)
preset
clear
q
qbar
q
qbar
preset
clear

José Carlos Alves
27
Verilog - introdução
• Modelo estrutural de uma latch SR com portas NAND:
module ffnand(preset,clear,q,qbar);
input preset, clear;
output q, qbar;
nand #1 nand1(q, qbar, preset),
nand2(qbar, q, clear);
endmodule
interface
implementação
q
qbar
preset
clear
instância
atraso
• Circuito:
saída entradas
primitiva
José Carlos Alves
28
• Simulação do módulo ffnand
`timescale 1ns/100ps
module top_ffnand;
wire q, qb;
reg pre, clr;
ffnand ffnand1(pre,clr,q,qb);
initial
begin
$monitor($time,
“ preset=%b, clear=%b, q=%b, qbar=%b”,
pre, clr, q, qb);
#10 pre=0; clr=1;
#10 pre=1;
#10 clr=0;
#10 clr=1;
#10 $finish;
end
endmodule
fios
estímulos
de simulação
monitor
de sinais
instância
registos
espera 10ns
escala temporal

José Carlos Alves
29
• Modelo completo para simulação (testbench)
– reunião dos módulos ffnand e top_ffnand
• Resultados da simulação
– produzidos pela função $monitor(...)(system task)
• sempre que algum dos sinais declarados muda de estado
– análise das formas de onda de sinais relevantes
0 preset=x clear=x q=x qbar=x
10 preset=0 clear=1 q=x qbar=x
11 preset=0 clear=1 q=1 qbar=x
12 preset=0 clear=1 q=1 qbar=0
valor lógico
desconhecido
José Carlos Alves
30
• Um contador de 4 bits (counter)
– estruturação em 3 módulos: c16, Dff e clockgen
– clockgen produz o sinal de relógio
– contador c16 usa instâncias do módulo Dff (flip-flops tipo D)
– hierarquia do modelo:
clockgen
c16
Dff Dff Dff Dff
counter

José Carlos Alves
31
• Modelo do contador c16
module c16(value, clock, fifteen, ten);
input clock;
output [3:0] value;
output fifteen, ten;
Dff D1(value[0], clock, ~value[0]),
D2(value[1], clock, value[1] ^ value[0]),
D3(value[2], clock, value[2] ^ &value[1:0]),
D4(value[3], clock, value[3] ^ &value[2:0]);
assign fifteen = &value;
assign ten = value[3] & ~value[2] & value[1] & ~value[0];
endmodule
vector de bits
operadores
saída ten vale 1 quando value = 1010
saídas de 1 bit
José Carlos Alves
32
• Modelo (comportamental) do Dff
module Dff(q, clock, d);
input clock, d;
output q;
reg q;
initial
q = 0;
always
@ (negedge clock)
#10 q = d;
endmodule
q é reg porque “segura” um valor
no início da simulação (t=0)
sempre que clock

José Carlos Alves
33
• Gerador de relógio (clockgen)
module clockgen(clock);
output clock;
reg clock;
initial
#5 clock = 1;
always
#50 clock = ~clock;
endmodule
para sempre...
sinal clock gerado:
t=0
50 50
5
unidades de tempo reais: ‘timescale 1ns/100ps
unidade de atraso
arredondamento
dos cálculos
José Carlos Alves
34
• O circuito completo (módulo counter)
module counter;
wire [3:0] count;
wire clock, ten, fifteen;
c16 contador( count, clock, fifteen, ten);
clockgen clock( clock );
initial
$monitor($time, “ Clk=%b, Count=%d, is_10=%b, is_15=%b”,
clock, count, ten, fifteen);
endmodule

José Carlos Alves
35
Testbench
circuito
a
fabricar
geração
de
estímulos
análise
de
respostas
modelo sintetizável
(vai ser um circuito digital)
modelo não sintetizável
(testbench)
clock
reset
memórias
A/D e D/A
interfaces
ficheiros
...
simula o comportamento de
dispositivos externos
analisa respostas para
verificar a correcção do modelo
registos de texto
waveforms
ficheiros
...
José Carlos Alves
36
Verilog
• Modelo de um full-adder (estrutural gate-level)
module full_adder(a, b, cin, s, co);
input a, b, cin;
output s, co; // resultado e carry-out
wire t1, t2, t3;
xor #3 xor_1( s, a, b, cin );
and #2 and_1( t1, a, b ),
and_2( t2, a, cin),
and_3( t3, b, cin);
or #(2,3) or_1( co, t1, t2, t3);
endmodule
interface
implementação
instância
saída
entradas
primitivas
lógicas
atraso de
propagação: tpLH=2 unidades de tempo; tpHL=3 unidades
fios
comentário
atraso de 3
unidades de
tempo

José Carlos Alves
37
declaração do interface
• um módulo pode não ter interface
– em módulos usados para teste de outros - testbenches
module myadder_testbench; // sem entradas nem saídas
• declaração de portos de interface:
– portos unidireccionais:
input [7:0] din_a, din_b; // din_a, din_b são entradas de 8 bits
// onde o MSB é din_a[7] e o LSB é din_a[0]
input clock, reset; // clock, reset são entradas de 1 bit
output [0:8] res; // result é uma saída de 9 bits, onde o
// MSB é res[0] e o LSB é res[8]
– portos bidireccionais:
inout [7:0] databus; // databus é um sinal bidireccional de 8 bits:
// pode forçar um nível lógico ou receber um
// sinal do exterior
• todos os sinais declarados como portos de entrada/saída são do tipo wire (fio)
– fios (wires) apenas “propagam” valores lógicos entre uma origem e um destino
– as saídas que “seguram” valores lógicos devem ser declaradas como sinais do tipo reg
• valores lógicos: 1, 0, x (desconhecido) e z (estado de alta impedância)
José Carlos Alves
38
declaração de sinais
• sinais do tipo wire representam fios ou barramentos (vários bits)
– servem para transportar um valor lógico desde uma origem que o produz
– um identificador não declarado é considerado um wire de 1 bit
wire en_clock, sel_reg; // fios simples (um bit)
wire [15:0] opr_a, opr_b; // dois barramentos de 16 bits
• sinais do tipo reg representam “registos” (um ou mais bits)
– seguram valores lógicos
reg clock, reset; // registos de 1 bit
reg [7:0] Ra, Rb; // registos de 8 bits
reg [15:0] regfile[0:31]; // vector de 32 registos com 16 bits cada
• campos de vectores de bits
Rb; // todo o registo Rb de 8 bits
opr_a[15:8]; // os 8 bits mais significativos de opr_a
Rb[3]; // o bit 3 do registo Rb
regfile[6]; // o elemento no endereço 6 do vector regfile;

José Carlos Alves
39
primitivas lógicas
• primitivas lógicas implícitas na linguagem Verilog
– representam “componentes” que implementam funções lógicas elementares
• realizam operações entre sinais de 1 ou mais bits
– portas lógicas: and, nand, or, nor, xor, xnor (1º sinal é saída, restantes são entradas)
and and_1(o1, x1, x2), and_2(o2, x3, x4, x5, x6, en);
– buffers e inversores: buf, not (último sinal é a entrada e os restantes são saídas)
not inv_1(nclkout, nclkout1, nclkout2, clkin);
buf mybuffer(a, b, c, d, busout);
– buffers de 3 estados: bufif1, bufif0
bufif0 tristate_1(out, in, control);
– inversores com saída de 3 estados: notif1, notif0
notif0 my_not(not_in, in, control);
José Carlos Alves
40
tempos de propagação
(não suportados em modelos sintetizáveis)
• na instanciação de primitivas são especificados com o operador #
and #3 and_1(o1, x1, x2, x3; // tp = 3 unidades de tempo
and #(3,5) and_2(out2, a, b); // tplh=3, tphl=5
bufif1 #(3,2,5) buf_1(out, in, en) // tplh=3, tphl=2, tpHiZ=5
• para cada tempo podem ser especificados valores min, typ e max
and #(3:4:5) myand(out2, a, b); // tpmin=3, tptyp=4, tpmax=5
bufif1 #(1:2:3,2:3:4,3:4:6) buf_1(out, in, en) // atrasos min:typ:max
• o valor da unidade de tempo é definido pela directiva
`timescale
`timescale 1ns/100ps // uma unidade=1ns; precisão de simulação=0.1ns

José Carlos Alves
41
Verilog – modelos estruturais
• um somador de 4 bits
– usando instâncias do full-adder anterior
module four_bit_adder(a, b, cin, s, cout);
input [3:0] a, b;
input cin;
output [3:0] s;
output cout;
wire [2:0] cy;
full_adder fa_0( a[0], b[0], cin, s[0], cy[0] ),
fa_1( a[1], b[1], cy[0], s[1], cy[1] ),
fa_2( a[2], b[2], cy[1], s[2], cy[2] ),
fa_3(.cin(cy[2]),.a(a[3]),.b(b[3]),.s(s[3]),.co(cout));
endmodule
a e b são
entradas de
4 bits
s é uma
saída de
4 bits
nome do
componente
nomes das
instâncias
sinais ligados
por posição
sinais ligados
por nome
cy é um
bus de 3 bits
José Carlos Alves
42
verificação funcional
• um testbench instancia o módulo four_bit_adder.
module four_bit_adder_testbench;
reg [3:0] a, b;
reg cin;
wire [3:0] s;
wire cout;
four_bit_adder adder4(a, b, cin, s, cout);
initial
begin
$monitor($time, “ ci=%b, a=%d, b=%d, s=%d, co=%b”, cin, a, b, s, cout);
cin=0; a=2; b=4; #30
b=12; #30
cin=1; #30
a=4'b1110; b=4'b0110; #30
$stop;
end
endmodule
o circuito a testar
monitor
de sinais
estímulos
de
simulação
registos (seguram valores)
fios (propagam valores)
controlo do simulador (pára)
espera 30 unidades de tempo (30ns)
módulo sem interface (testbench)
quando o simulador inicia...

José Carlos Alves
43
resultados da simulação (formas de onda)
José Carlos Alves
44
resultados da simulação (texto)

José Carlos Alves
45
verificação funcional
• Verificação exaustiva do somador de 4 bits
• e se fosse de 32 bits ? (com 1ns por vector seriam necessários 1170 anos!)
module four_bit_adder_testbench;
reg [3:0] a, b; reg cin;
wire [3:0] s; wire cout;
four_bit_adder adder4(a, b, cin, s, cout);
initial
begin
$monitor($time, “ ci=%b, a=%d, b=%d, s=%d, co=%b", cin, a, b, s, cout);
cin = 0; $display(“Verificacao com carry-in = %b”, cin);
for(a=0;a<15;a=a+1) for(b=0;b<15;b=b+1) #40;
cin = 1; $display(“Verificacao com carry-in = %b”, cin);
for(a=0;a<15;a=a+1) for(b=0;b<15;b=b+1) #40;
$display(“Fim da simulação”); $stop;
end
endmodule
José Carlos Alves
46
constantes
• por omissão: decimal, 32 bits em complemento para dois
– são truncadas se forem atribuídas a sinais com menos bits (a partir do LSB):
• pode-se (deve-se) definir o número de bits e a base de
representação:
reg [3:0] a;
...
initial
begin
a = 28; // 28=11100 -> a fica com 1100=1210
...
end
nº de bits
5’d10; // a constante decimal 10 com 5 bits
10’b1010_0011_11; // constante com 10 bits, em binário
16’h1E_C6; // 16 bits em em hexadecimal
base de representação
valor (pode-se usar o separador “_” entre dígitos)

José Carlos Alves
47
Verilog system tasks
• algumas funções internas do simulador (system tasks)
– $monitor()
• imprime um registo de texto formatado quando um sinal muda de
estado
• a sintaxe é semelhante à função printf() da linguagem C
• num projecto só pode existir activo um monitor de sinais
– $time
• devolve o tempo actual do simulador (um inteiro)
– $display()
• quando invocado imprime um registo de texto formatado
– $stop
• interrompe a simulação mas pode ser retomada (breakpoint)
– $finish
• termina a execução do simulador (só em alguns simuladores...)
José Carlos Alves
48
modelos comportamentais
• Um modelo comportamental é formado por:
– um ou mais processos que operam concorrentemente
• assign: blocos combinacionais
• always: blocos combinacionais, sequenciais ou síncronos
• Modelo de um full-adder (combinacional)
module full_adder_comp(a, b, cin, s, cout);
input a, b, cin;
output s, cout;
reg cout;
assign s = a ^ b ^ cin;
always @( a or b or cin )
begin
cout = (a & b) | (a & cin) | (b & cin);
end
endmodule
modela blocos
combinacionais
sempre que...
o sinal s está
ligado à expressão
operadores
lógicos

José Carlos Alves
49
modelos comportamentais
• Modelo comportamental do somador de 4 bits
module four_bit_adder_c(a, b, cin, s, cout);
input [3:0] a, b;
input cin;
output [3:0] s;
output cout;
reg cout, s;
reg [5:0] ta, tb, ts; // “registos” temps.
always @( a or b or cin or ta or tb or ts )
begin
ta = { 1’b0, a, 1’b1 };
tb = { 1’b0, b, cin };
ts = ta + tb;
cout = ts[5];
s = ts[4:1];
end
endmodule
sempre que...
concatenação de bits
somador
extrair os resultados
José Carlos Alves
50
operadores (semelhantes aos da linguagem C)
aritméticos + - * / % 2 operandos são estendidos com zeros
lógicos ! negação lógica 1 zero é falso, não-zero é verdadeiro
&& E lógico 2 retorna 1-verdadeiro ou 0-falso
|| OU lógico 2
relacionais > < >= <= 2 operandos considerados unsigned
igualdade == != 2 comparam apenas zeros e uns
=== !== 2 comparam também os valores z e x
bitwise ~ & | ^ 2 operandos são estendidos com zeros
shift >> << 2 desloca bits e preenche sempre com zeros
concatenação { } N {3’b101,1’b0,3’b111}=7’b1010111
replicação {{ }} N {N{A}} replica N vezes o valor A
condicional ? : 3 igual à expressão condicional de C
operador #opr observações

José Carlos Alves
51
modelação de blocos combinacionais
• assign sinal = expressao;
– Liga permanentemente sinal ao resultado da expressao:
• always @(a or b or c or ...) begin ... end
– sempre que um sinal da lista muda de estado avalia o bloco:
opa
a
IR
b
atraso de transporte (não pode ser usado em modelos sintetizáveis)
always @(a or IR or b)
begin
if ( IR[7:4] & 4’b1010 )
opa = { a<<7, (a+b) };
else
opa = { a<<7, (a-b) };
end
assign #10 opa = { a<<7, ( IR[7:4] & 4’b1010 ? (a+b) : (a-b) ) };
lista de sensibilidades
José Carlos Alves
52
latches em blocos combinacionais
• Num modelo de um circuito combinacional
– as saídas devem ter um valor atribuído para todas as condições das
entradas
– se essa condição não for satisfeita são criadas latches transparentes
– a ocorrência de latches num bloco que se pretendia combinacional
é geralmente FATAL (a ver mais tarde)
always @(a or b or sel)
begin
if ( sel )
y = a;
else
y = b;
end
always @(a or b or sel)
begin
if ( sel )
y = a;
end
um multiplexer 2÷1
uma latch transparente

José Carlos Alves
53
construções condicionais
if (condition)
statement1
else
statement2
case (expression)
expr1: statement1;
expr2: statement2;
default: statement3;
endcase;
(expression)?(true):(false)
if (a[2:0]==3’b010 && cy)
...
casez
casex
(z é don’t care)
(z e x são don’t care)
case (ir[7:4])
4’b0001: ...
4’b0010: ...
default: ...
endcase
casex (ir[7:4])
4’bxx01: ...
4’bxx10: ...
default: ...
endcase
acc=(ir[7:0]==4’b0011) ? 0 : 255;
if (a[2:0]===3’b01z && cy)
...
José Carlos Alves
54
ciclos
(utilização restrita em modelos sintetizáveis)
for(start;end_expr;update)
statement;
forever statement;
for(i=0;i<8;i=i+1)
x[i] = x[i+1]
repeat(fixed_loop_count)
statement;
repeat(10)
begin
a[i]=a[i+1];
i=i+1;
end;
forever #10 clock = ~clock;
while(i<8)
begin
...
end
while(condition)
statement;

José Carlos Alves
55
modelação de circuitos síncronos
• acumulador de 8 bits
module acc(clk, reset, a, reg_sum);
input clk, reset;
input [7:0] a;
output [7:0] reg_sum;
reg [7:0] reg_sum;
always @( negedge clk )
if ( reset )
reg_sum <= 8’d0;
else
reg_sum <= a + reg_sum;
endmodule
processo
síncrono com clk sempre que clk
reg_sum “segura” um
valor lógico
reg_sum
a
D Q
clk
0
reset
José Carlos Alves
56
contador up/down
module updown_counter(clk, reset, enable, down, dout, end_count);
input clk, reset, enable, down;
output [3:0] dout;
reg [3:0] dout;
output end_count;
assign end_count = enable & (down ? (dout==0) : (dout==15) );
always @( posedge clk or posedge reset)
begin
if ( reset )
dout <= 0
else
begin
if ( enable )
if ( down )
dout <= dout – 1;
else
dout <= dout + 1;
end
end
endmodule
processo síncrono
com o flanco ascendente
de clk e reset assíncrono
processo combinacional
a avaliação do sinal de reset
tem de ocorrer no início do
bloco begin...end

José Carlos Alves
57
testbench para o contador up/down
module updown_counter_testbench;
reg clk, reset, enable, down;
wire [3:0] dout;
wire end_count;
updown_counter count_1(clk, reset, enable, down, dout, end_count);
initial
begin
down = 0; reset = 0; enable = 1;
#2 reset = 1; // apply reset
#6 reset = 0; // release reset
#300 // count up 300ns
enable = 0; #40 // disable counter
down = 1; #100 // count down
enable = 1; #300 // enable counter, wait 300ns
$stop; // stop simulation
end
initial clk = 1’b0;
always #5 clk = ~clk; // 10ns clock period
endmodule
estímulos
instância do contador
sinal de
relógio
José Carlos Alves
58
atribuições blocking/nonblocking
• Atribuições procedimentais – avaliadas em sequência
• Atribuições non-blocking – avaliadas em paralelo
begin
a1=in0+in1-acc;
y1=a1+b1;
z1=y1+a1;
end
begin
a1<=in0+in1-acc;
y1<=a1+b1;
z1<=y1+a1;
end
Admitindo que in0=4,in1=4,acc=1
a1=4, b1=4, y1=8
a1 = 4+4-1 = 7;
y1 = 7+4 = 11;
z1 = 11+7 = 18;
a1 = 7;
y1 = 4+4 = 8;
z1 = 8+4 = 12;

José Carlos Alves
59
atribuições blocking/nonblocking
• Quando usar a=b ou a<=b ?
– em processos combinacionais podem-se usar os dois tipos
– em processos síncronos deve-se usar apenas non-blocking
• evita a ocorrência de race conditions que podem “encravar” o
simulador
always @(posedge clk)
begin
...
if ( dataready )
rdy = 1;
...
end
always @(posedge clk)
begin
...
if ( rdy )
begin
reg = datain;
ack = 1;
end
end
José Carlos Alves
60
blocos sequenciais e paralelos
begin // sequencial
x = k;
#10 y = a + b;
#5 z = y * x;
end
begin
x = k;
fork
#10 y = a + b;
#5 z = y * x;
join
end
avaliadas em paralelo
inicia bloco paralelo
termina bloco paralelo
x
y
z
10 5
x
y
z
10
5

José Carlos Alves
61
parametrização
• módulos com parâmetros
module my_multiply(...);
parameter size=16, delay=5;
...
endmodule
my_multiply #(8,2) mult1(...);
valores por omissão
valores atribuídos
à instância mult1
José Carlos Alves
62
Modelação de máquinas de estados
• FSM (Finite State Machine)
– sequência determinada de estados, síncronizado com relógio
– estrutura geral
saída
próximo
estado
registo de
estado
entradas
saídas (Mealy)
reset
(assíncrono)
reset
(síncrono)
clock
saídas (Moore)
saídas (Moore)
saída

José Carlos Alves
63
Modelação de máquinas de estados
• Codificação de estados (feita “à mão”)
– atribuição de padrões de bits a cada estado
– o tipo de codificação influencia
• dimensão do registo de estado
• complexidade dos circuitos lógicos combinacionais
– codificações mais usadas
• sequencial
– 0000 0001 0010 0011 0100 … 1101 1110 1111
• código Gray
– 0000 0001 0011 0010 0110 … 1011 1001 1000
• código Johnson
– 00000000 00000001 00000011 00000111 00001111 … 11100000
11000000
• one-hot
– 0000000000000001 0000000000000010 0000000000000100 ...
José Carlos Alves
64
Máquinas de estados - Mealy e Moore
• Mealy
– as saídas dependem do estado corrente e das entradas
– o valor das saídas é associado às transições entre estados
• Moore
– as saídas dependem apenas do estado corrente
– o valor das saídas é associado aos estados
A B
C
i1/s1
i2/s2
D E
F
s3
s3
s4
i1
i3
condição de
transição de estado
i3
i4
valores das
saídas

José Carlos Alves
65
Máquinas de estados - especificação
• Tabela de transição de estados
• Diagrama de transição de estados
00 01
10
0X/1
0
1X/0
1
1
X1/0
X0/1
XX/1
S0 S1
S2
i1/Yme
i1/Yme
Ymo
Ymo
i2/Yme
Yme
i2/Yme
entradas estado próximo saídas
i1 i2 corrente estado Yme Ymo
0 X 00 (S0) 00 (S0) 1 0
1 X 00 (S0) 01 (S1) 0 0
X 1 01 (S1) 00 (S0) 0 1
X 0 01 (S1) 10 (S2) 1 1
X X 10 (S2) 00 (S0) 1 1
saídas Mealy
saídas Moore
i1 i2/Yme
Ymo
José Carlos Alves
66
Máquinas de estados - modelação em Verilog
• Modelo incorrecto
module FSM_mal(clock, i1, i2, Yme, Ymo);
input clock, i1, i2;
output Yme, Ymo;
reg Yme, Ymo;
reg [1:0] state;
always @(posedge clock)
case (state)
2’b00: begin
Ymo<=0;
if (i1)
begin
state<=2’b01; Yme<=0;
end
else
Yme<=1;
end
2’b01: begin
Ymo<=1;
if (i2)
begin
end
else
begin
end
end
2’b10: begin
Ymo<=1; state<=2’b00; Yme<=1;
end
endmodule
00 01
10
0X/1
0
1X/0
1
1
X1/0
X0/1
XX/1
i1 i2/Yme
Ymo
Onde estão os erros ?

José Carlos Alves
67
• Modelo incorrecto
module FSM_mal(clock, i1, i2, Yme, Ymo);
input clock, i1, i2;
output Yme, Ymo;
reg Yme, Ymo;
reg [1:0] state;
case (state)
2’b00: begin
Ymo<=0;
if (i1)
begin
end
else
Yme<=1;
end
2’b01: begin
Ymo<=1;
if (i2)
begin
end
else
begin
end
end
2’b10: begin
Ymo<=1; state<=2’b00; Yme<=1;
end
endmodule
00 01
10
0X/1
0
1X/0
1
1
X1/0
X0/1
XX/1
i1 i2/Yme
Ymo
• falta de reset (síncrono e/ou assíncrono)
• todas as saídas são registadas
• Yme não é saída Mealy
• não é definido o estado inicial
• falta o estado 2’b11
José Carlos Alves
68
• Modelo correcto
00 01
10
0X/1
0
1X/0
1
1
X1/0
X0/1
XX/1
i1 i2/Yme
Ymo
always @(state or i1 or i2)
begin
case (state)
2’b00: begin
nextstate=2’b00;
Ymo=0;
if (i1)
begin
nextstate=2’b01; Yme=0;
end
else
Yme=1;
end
2’b01: begin
Ymo=1;
if (i2)
begin
end
else
begin
end
end
2’b10: begin
Ymo=1; nextstate=2’b00; Yme=1;
end
default: begin
Ymo=0; nextstate=2’b00; Yme=1;
end
end
endmodule
module FSM_bem(reset, clock,
i1, i2, Yme, Ymo);
input reset, clock, i1, i2;
output Yme, Ymo;
reg Yme, Ymo;
reg [1:0] state, nextstate;
if (reset)
state<=2’b00;
else
state<=nextstate;

José Carlos Alves
69
• Separação da lógica do próximo estado das
saídas
begin
case (state)
2’b00: if (i1)
nextstate=2’b01;
else
nextstate=2’b00;
2’b01: begin
if (i2)
nextstate=2’b00;
else
nextstate=2’b10;
end
2’b10: nextstate=2’b00;
default: nextstate=2’b00;
end
endmodule
begin
case (state)
2’b00: begin
Ymo=0;
if (i1)
Yme=0;
else
Yme=1;
end
2’b01: begin
Ymo=1;
if (i2)
Yme=0;
else
Yme=1;
end
2’b10: begin
Ymo=1; Yme=1;
end
default: begin
Ymo=0; Yme=1;
end
end
endmodule
José Carlos Alves
70
• Combinando estado corrente e próximo estado
always @(posedge clock or negedge reset)
begin
if (!reset)
state <= 2’b00;
else
case (state)
2’b00: if (i1)
state<=2’b01;
else
state<=2’b00;
2’b01: begin
if (i2)
state<=2’b00;
else
state<=2’b10;
end
2’b10: begin
state<=2’b00;
end
default: begin
state<=2’b00;
end
end
endmodule
modelando Ymo como saída síncrona:
always @(posedge clock or negedge reset)
begin
if (!reset)
begin
Ymo<=0;
state <= 2’b00;
end
else
case (state)
2’b00: if (i1)
begin
Ymo<=1;
state<=2’b01;
end
else
begin
Ymo<=0;
state<=2’b00;
end
...

Projeto de Sistemas Digitais FEUP 2006/2007

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Projeto de Sistemas Digitais FEUP 2006/2007

Semelhante a Projeto de Sistemas Digitais FEUP 2006/2007 (20)

Mais de RodriguesAntonioNabo

Mais de RodriguesAntonioNabo (9)

Projeto de Sistemas Digitais FEUP 2006/2007