Projeto Sistemas Digitais

Projecto de Sistemas Digitais
(EEC0055)

Mestrado Integrado em Engenharia Electrotécnica e
de Computadores

4º ano, 2º semestre
António José Araújo
(aja@fe.up.pt)
Hélio Sousa Mendonça
(hsm@fe.up.pt)

http://www.fe.up.pt/~aja/PSDI_200607-2S

FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007 1
José Carlos Alves

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

Fluxo de projecto (típico)
um controlador de
intensidade luminoasde para
ligar sempre que anguem
casa eou sai da luzes do
desligar
entra se chama bobi e
caoreceptor casota
tem que tareco gatoa que
1-
se -chama paraum
tambem calcular luz
2 um cpu always @(posedge clock or posedge reset)
3 - interface de potência
begin

face
proces
sador case(state)
Ideia

inter
start: begin if ( enable) ready <= 1;
memória
else ready <= 0;
state <= waitfor;
end
endcase
end
sistema (abstracto)

validação circuito (RTL – lógico) D
Q

validação mapeamento D
tecnológico Q

validação fabrico

teste IC
/dev/null

José Carlos Alves

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

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
funcionalidade
rapidez
disponibilidade
LSI número de pinos
interface CPU ASIC encapsulamento
fabricante(s)
mP
memória RAM PCB
co-proc COB
I/O proc MCM
wire-wrap
José Carlos Alves

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

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

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

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

Y- chart
fluxogramas,
estrutural algoritmos
transferências
processadores,
entre registos comportamental
memórias expressões
booleanas
registos, muxs funções de
portas lógicas transistores
transistores
layout de
di

transistores
sp
os
iti
vo
ló

ão

células
gi
co
cç
ra
RT

si
st
L

st módulos, chips
ab

e m
e

a
sd

placas, MCMs
i
ve
ní

físico
José Carlos Alves

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

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...

nível de código máquina layout
abstracção assembly portas lógicas
crescente C, C++ HDLs

José Carlos Alves

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

Metodologias de projecto
• Abordagens típicas
– bottom-up (capture-and-simulation)
• hierarquia criada de baixo para cima (lógico ⇒ RTL ⇒ sistema)
• ciclo de projecto: manual
– 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 automático
– 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

José Carlos Alves

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

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

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

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

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

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

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

VHDL-Verilog (comportamental)
VHDL Verilog
library IEEE; module MUX_2_1(S1,A1,B1,Y1,
use IEEE.STD_Logic_1164.all; S2,A2,B2,Y2,
entity MUX_2_1 is S3,A3,B3,Y3);
port(S1,A1,B1,S2,A2,B2,S3,A3,B3:in std_logic; input S1,A1,B1,S2,A2,B2,S3,A3,B3;
Y1,Y2,Y3:out std_logic); output Y1,Y2,Y3;
end entity MUX_2_1; reg Y2,Y3;

architecture COND_DATA_FLOW of MUX_2_1 is assign Y1=S1?A1:B1;
begin
Y1 <= A1 when S1=‘1’ else B1; always
TWO_2_1_MUXES: @(S2 or A2 or B2 or S3 or A3 or B3)
process(S2,A2,B2,S3,A3,B3) begin
begin Y2=B2;
Y2<=B2; if (S2)
if (S2=‘1’) then Y2=A2;
Y2<=A2; if (S3)
endif; Y3=A3;
if (S3=‘1’) then else
Y3<=A3; Y3=B3;
else end
Y3<=B3; endmodule
endif;
end process TWO_2_1_MUXES
end architecture COND_DATA_FLOW;

José Carlos Alves

VHDL-Verilog (estrutural)
VHDL Verilog
library IEEE; module HALF_ADDER(a,b,sum,carry);
use IEEE.STD_Logic_1164.all; input a,b;
output sum,carry;
entity HALF_ADDER is
port(a,b:in std_logic; xor X1(sum,a,b);
sum,carry:out std_logic); and A1(carry,a,b);
end entity HALF_ADDER;
endmodule

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;

José Carlos Alves

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

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

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: preset q
clear qbar
• interface (entradas e saídas)
preset q
• implementação (modelo do circuito digital) qbar
clear

José Carlos Alves

Verilog - introdução
• Modelo estrutural de uma latch SR com portas NAND:

module ffnand(preset,clear,q,qbar);
input preset, clear; interface
output q, qbar;
atraso
primitiva nand #1 nand1(q, qbar, preset),
implementação
nand2(qbar, q, clear);
instância
endmodule

saída entradas
• Circuito: preset q

clear qbar

José Carlos Alves

• Simulação do módulo ffnand escala temporal
`timescale 1ns/100ps
module top_ffnand; fios
wire q, qb;
reg pre, clr; registos
ffnand ffnand1(pre,clr,q,qb);
instância
initial
begin monitor
$monitor($time, de sinais
“ preset=%b, clear=%b, q=%b, qbar=%b”,
pre, clr, q, qb);
espera 10ns
#10 pre=0; clr=1;
#10 pre=1;
#10 clr=0; estímulos
#10 clr=1; de simulação
#10 $finish;
end
endmodule

José Carlos Alves

• 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 valor lógico
10 preset=0 clear=1 q=x qbar=x
desconhecido
11 preset=0 clear=1 q=1 qbar=x
12 preset=0 clear=1 q=1 qbar=0

José Carlos Alves

• 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:

counter
c16 clockgen

Dff Dff Dff Dff

José Carlos Alves

• Modelo do contador c16
module c16(value, clock, fifteen, ten);
input clock; vector de bits
output [3:0] value;
output fifteen, ten; saídas de 1 bit
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; operadores
assign ten = value[3] & ~value[2] & value[1] & ~value[0];

endmodule

saída ten vale 1 quando value = 1010

José Carlos Alves

• Modelo (comportamental) do Dff

module Dff(q, clock, d);
input clock, d;
output q;
reg q; q é reg porque “segura” um valor
initial
q = 0;
no início da simulação (t=0)
always
@ (negedge clock)
#10 q = d; sempre que clock
endmodule

José Carlos Alves

• Gerador de relógio (clockgen)
module clockgen(clock);
output clock;
reg clock;

initial
#5 clock = 1; para sempre...
always sinal clock gerado:
#50 clock = ~clock;

endmodule
5 50 50
t=0

arredondamento
dos cálculos
unidades de tempo reais: ‘timescale 1ns/100ps

unidade de atraso
José Carlos Alves

• 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

Testbench
modelo não sintetizável
(testbench)

clock
reset registos de texto
memórias geração circuito análise waveforms
A/D e D/A de a de ficheiros
estímulos respostas ...
interfaces fabricar
ficheiros
...

simula o comportamento de modelo sintetizável analisa respostas para
dispositivos externos (vai ser um circuito digital) verificar a correcção do modelo

José Carlos Alves

Verilog
• Modelo de um full-adder (estrutural gate-level)
module full_adder(a, b, cin, s, co);

fios
input a, b, cin; interface
output s, co; // resultado e carry-out
atraso de 3 saída wire t1, t2, t3;
unidades de comentário
tempo xor #3 xor_1( s, a, b, cin );
instância
and #2 and_1( t1, a, b ),
and_2( t2, a, cin), implementação
primitivas and_3( t3, b, cin);
lógicas entradas
or #(2,3) or_1( co, t1, t2, t3);

endmodule
atraso de
propagação: tpLH=2 unidades de tempo; tpHL=3 unidades
José Carlos Alves

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

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

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

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

Verilog – modelos estruturais
• um somador de 4 bits
– usando instâncias do full-adder anterior
a e b são
entradas de
4 bits module four_bit_adder(a, b, cin, s, cout);
input [3:0] a, b;
s é uma input cin;
saída de output [3:0] s;
4 bits output cout; sinais ligados
wire [2:0] cy; por posição
cy é um
bus de 3 bits sinais ligados
full_adder fa_0( a[0], b[0], cin, s[0], cy[0] ),
por nome
fa_1( a[1], b[1], cy[0], s[1], cy[1] ),
nome do
fa_2( a[2], b[2], cy[1], s[2], cy[2] ),
componente
fa_3(.cin(cy[2]),.a(a[3]),.b(b[3]),.s(s[3]),.co(cout));
nomes das
instâncias endmodule

José Carlos Alves

verificação funcional
• um testbench instancia o módulo four_bit_adder.
`timescale 1ns/100ps módulo sem interface (testbench)
module four_bit_adder_testbench;
reg [3:0] a, b;
reg cin; registos (seguram valores)
wire [3:0] s;
wire cout; fios (propagam valores)
o circuito a testar
four_bit_adder adder4(a, b, cin, s, cout);
monitor
initial quando o simulador inicia... de sinais
begin
$monitor($time, “ ci=%b, a=%d, b=%d, s=%d, co=%b”, cin, a, b, s, cout);
estímulos cin=0; a=2; b=4; #30
de b=12; #30 espera 30 unidades de tempo (30ns)
simulação cin=1; #30
a=4'b1110; b=4'b0110; #30
$stop; controlo do simulador (pára)
end
endmodule

José Carlos Alves

resultados da simulação (formas de onda)

José Carlos Alves

resultados da simulação (texto)

José Carlos Alves

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

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):
reg [3:0] a;
...
initial
begin
a = 28; // 28=11100 -> a fica com 1100=1210
...
end

• pode-se (deve-se) definir o número de bits e a base de
representação:
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

valor (pode-se usar o separador “_” entre dígitos)
base de representação
nº de bits

José Carlos Alves

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

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; modela blocos
o sinal s está combinacionais
ligado à expressão
assign s = a ^ b ^ cin;
operadores
sempre que... lógicos
always @( a or b or cin )
begin
cout = (a & b) | (a & cin) | (b & cin);
end
endmodule

José Carlos Alves

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.
sempre que...
always @( a or b or cin or ta or tb or ts )
begin concatenação de bits
ta = { 1’b0, a, 1’b1 };
tb = { 1’b0, b, cin }; somador
ts = ta + tb;
cout = ts[5]; extrair os resultados
s = ts[4:1];
end
endmodule

José Carlos Alves

operadores (semelhantes aos da linguagem C)
operador #opr observações
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
José Carlos Alves

modelação de blocos combinacionais
• assign sinal = expressao;
– Liga permanentemente sinal ao resultado da expressao:
assign #10 opa = { a<<7, ( IR[7:4] & 4’b1010 ? (a+b) : (a-b) ) };

atraso de transporte (não pode ser usado em modelos sintetizáveis)

• always @(a or b or c or ...) begin ... end
– sempre que um sinal da lista muda de estado avalia o bloco:
always @(a or IR or b)
lista de sensibilidades
begin
if ( IR[7:4] & 4’b1010 )
a
opa = { a<<7, (a+b) };
else IR opa
opa = { a<<7, (a-b) }; b
end

José Carlos Alves

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 always @(a or b or sel)
if ( sel ) begin
y = a; if ( sel )
else y = a;
y = b; end
end
uma latch transparente
um multiplexer 2÷1
José Carlos Alves

construções condicionais
if (a[2:0]==3’b010 && cy)
if (condition) ...
statement1
else
statement2 if (a[2:0]===3’b01z && cy)
...

case (expression) case (ir[7:4])
expr1: statement1; 4’b0001: ...
expr2: statement2; 4’b0010: ...
default: statement3; default: ...
endcase; endcase

casez casex (ir[7:4])
(z é don’t care) 4’bxx01: ...
4’bxx10: ...
casex default: ...
(z e x são don’t care) endcase

(expression)?(true):(false) acc=(ir[7:0]==4’b0011) ? 0 : 255;

José Carlos Alves

ciclos
(utilização restrita em modelos sintetizáveis)
for(start;end_expr;update)
for(i=0;i<8;i=i+1)
statement; x[i] = x[i+1]

while(condition) while(i<8)
statement; begin
...
end

repeat(10)
repeat(fixed_loop_count) begin
statement; a[i]=a[i+1];
i=i+1;
end;

forever statement; forever #10 clock = ~clock;

José Carlos Alves

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;
reg_sum “segura” um
valor lógico
always @( negedge clk )
if ( reset )
processo
reg_sum <= 8’d0;
síncrono com clk sempre que clk
else
reg_sum <= a + reg_sum;
endmodule

reset

D Q reg_sum
a
0
clk
José Carlos Alves

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; processo combinacional
output end_count;

assign end_count = enable & (down ? (dout==0) : (dout==15) );

always @( posedge clk or posedge reset)
begin
if ( reset )
dout <= 0
else processo síncrono
begin com o flanco ascendente
if ( enable ) de clk e reset assíncrono
if ( down )
dout <= dout – 1;
a avaliação do sinal de reset
else
tem de ocorrer no início do
dout <= dout + 1;
bloco begin...end
end
end
endmodule

José Carlos Alves

testbench para o contador up/down
module updown_counter_testbench;
reg clk, reset, enable, down;
wire [3:0] dout; instância do contador
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 estímulos
#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; sinal de
always #5 clk = ~clk; // 10ns clock period relógio
endmodule

José Carlos Alves

atribuições blocking/nonblocking
• Atribuições procedimentais – avaliadas em sequência
Admitindo que in0=4,in1=4,acc=1
begin a1=4, b1=4, y1=8
a1=in0+in1-acc;
y1=a1+b1; a1 = 4+4-1 = 7;
z1=y1+a1; y1 = 7+4 = 11;
end z1 = 11+7 = 18;

• Atribuições non-blocking – avaliadas em paralelo
begin
a1<=in0+in1-acc; a1 = 7;
y1<=a1+b1; y1 = 4+4 = 8;
z1<=y1+a1; z1 = 8+4 = 12;
end

José Carlos Alves

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) always @(posedge clk)
begin begin
... ...
if ( dataready ) if ( rdy )
rdy = 1; begin
... reg = datain;
end ack = 1;
end
end

José Carlos Alves

blocos sequenciais e paralelos
begin // sequencial begin
x = k; x = k; inicia bloco paralelo
#10 y = a + b; fork
#5 z = y * x; #10 y = a + b; avaliadas em paralelo
end #5 z = y * x;
join
end termina bloco paralelo

10 5 10

x x
y y

z z
5

José Carlos Alves

parametrização

• módulos com parâmetros

module my_multiply(...);
parameter size=16, delay=5;
...
endmodule
valores por omissão
my_multiply #(8,2) mult1(...);

valores atribuídos
à instância mult1

José Carlos Alves

Modelação de máquinas de estados
• FSM (Finite State Machine)
– sequência determinada de estados, síncronizado com relógio
– estrutura geral
saídas (Moore)
entradas
saída saídas (Mealy)
saída saídas (Moore)

próximo
reset estado
(síncrono)
registo de
clock estado

reset
(assíncrono)

José Carlos Alves

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

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

i1 i1/s1 condição de
A B
transição de estado
C
• Moore i2/s2
valores das
– as saídas dependem apenas do estado corrente saídas
– o valor das saídas é associado aos estados
i3
s3
i3 s3 E
D
i4
F
s4

José Carlos Alves

Máquinas de estados - especificação
• Tabela de transição de estados
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

• Diagrama de transição de estados
Ymo 0 1 Ymo
1X/0 i1/Yme
00 01 i1/Yme S1
S0
0X/1
X1/0 i2/Yme
X0/1 i2/Yme
XX/1
Yme
i1 i2/Yme 10 saídas Mealy S2
1 saídas Moore Ymo
José Carlos Alves

Máquinas de estados - modelação em Verilog
module FSM_mal(clock, i1, i2, Yme, Ymo);

• Modelo incorrecto input clock, i1, i2;
output Yme, Ymo;
reg Yme, Ymo;
reg [1:0] state;
always @(posedge clock)
Ymo 0 1 case (state)
1X/0 2’b00: begin
00 01
Ymo<=0;
0X/1 if (i1)
X1/0
X0/1 begin
XX/1
state<=2’b01; Yme<=0;
end
i1 i2/Yme 10 else
1 Yme<=1;
end
2’b01: begin
Ymo<=1;
if (i2)
begin
end
else
begin
Onde estão os erros ? end
end
2’b10: begin
Ymo<=1; state<=2’b00; Yme<=1;
end
endmodule

José Carlos Alves

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

José Carlos Alves

always @(state or i1 or i2)
• Modelo correcto begin
case (state)
2’b00: begin
nextstate=2’b00;
Ymo 0 1 Ymo=0;
1X/0 if (i1)
00 01
begin
0X/1 nextstate=2’b01; Yme=0;
X1/0
X0/1 end
else
XX/1 Yme=1;
i1 i2/Yme 10 end
1 2’b01: begin
Lógica de geração Ymo=1;
if (i2)
Memória de estado do próximo estado begin
e das saídas nextstate=2’b00; Yme=0;
end
else
module FSM_bem(reset, clock, begin
i1, i2, Yme, Ymo); nextstate=2’b10; Yme=1;
input reset, clock, i1, i2; end
output Yme, Ymo; end
reg Yme, Ymo; 2’b10: begin
reg [1:0] state, nextstate; Ymo=1; nextstate=2’b00; Yme=1;
end
always @(posedge clock) default: begin
if (reset) Ymo=0; nextstate=2’b00; Yme=1;
state<=2’b00; end
else end
state<=nextstate; endmodule

José Carlos Alves

• Separação da lógica do próximo estado das
saídas
always @(state or i1 or i2)
begin
always @(state or i1 or i2) case (state)
begin 2’b00: begin
case (state) Ymo=0;
2’b00: if (i1) if (i1)
nextstate=2’b01; Yme=0;
else else
2’b01: begin end
if (i2) 2’b01: begin
nextstate=2’b00; Ymo=1;
else if (i2)
end else
2’b10: nextstate=2’b00; Yme=1;
end
default: nextstate=2’b00; 2’b10: begin
Ymo=1; Yme=1;
end end
endmodule default: begin
Ymo=0; Yme=1;
end
end
endmodule

José Carlos Alves

• Combinando estado corrente e próximo estado
always @(posedge clock or negedge reset)
begin
if (!reset)
modelando Ymo como saída síncrona:
state <= 2’b00;
else always @(posedge clock or negedge reset)
case (state) begin
2’b00: if (i1) if (!reset)
state<=2’b01; begin
else Ymo<=0;
state<=2’b00; state <= 2’b00;
2’b01: begin end
if (i2) else
state<=2’b00; case (state)
else 2’b00: if (i1)
state<=2’b10; begin
end Ymo<=1;
2’b10: begin state<=2’b01;
state<=2’b00; end
end else
default: begin begin
state<=2’b00; Ymo<=0;
end state<=2’b00;
end end
endmodule ...

José Carlos Alves

Síntese de Sistemas Digitais
alto nível (behavioral)

RTL
estrutural comportamental
lógica
processadores, fluxogramas,
memórias algoritmos
registos, muxs circuito transferências
entre registos
portas lógicas expressões
booleanas
transistores funções de
transistores

di
sp
layout de

os
i
transistores

tiv
o
ló
gi

ã o
co

cç
células
RT

si
ra
L

st
st
ab
em
a módulos, chips
d e
is
ve

placas, MCMs
ní

físico
José Carlos Alves

Problemas de síntese

• Síntese estrutural
– do domínio comportamental para o domínio estrutural
– dependente da tecnologia, não define a realização física
– sujeita a restrições como área, desempenho, potência,…
• Síntese física
– transformação do domínio estrutural para o domínio físico:
• dispositivo: produção dos desenhos das máscaras de células (layout)
• célula: colocação de células e interligações (place & route)
• RTL: organização física de módulos (floorplanning)
• sistema: particionamento em componentes, PCBs, MCMs

José Carlos Alves

Síntese RTL
• origem
– descrição comportamental ao nível RTL (ou lógico)
• variáveis (registos)
• operações entre variáveis (aritméticas, lógicas, deslocamento de bits)
• decisões (if-then-else, case)
• transferências entre registos síncronas com sinais de relógio
– restrições de implementação
• frequência mínima do sinal de relógio
• espaço ocupado: número e tipo de células (FPGAs) ou área física (ASICs)
• destino
– um modelo estrutural ao nível lógico
• antes do mapeamento tecnológico: portas lógicas, flip-flops, latches
• após a optimização para a tecnologia alvo: rede de células disponíveis
da tecnologia

José Carlos Alves

Síntese RTL
• Como é traduzido o código?
– cada módulo é sintetizado para uma tecnologia genérica
• pode ser realizada alguma optimização lógica nesta fase
– o circuito é posteriormente optimizado para a tecnologia alvo
• são usadas apenas células que existam na biblioteca alvo
• optimização da utilização dessas células (área ou rapidez)
• pode ser mantida a hierarquia ou ser “planificado” num só nível
– as construções Verilog são traduzidas em circuitos padrão:
• if-then-else – multiplexers 2÷1
• case-endcase – multiplexers “grandes” (ou lógica random)
• always @(posedge clk ... ) – circuitos síncronos com clk
• assign ou always @(a or ... ) – circuitos combinacionais
• operadores aritméticos e lógicos – circuitos combinacionais

José Carlos Alves

Síntese RTL – estilo de codificação
• O “estilo” de codificação afecta o resultado
– Dependente da ferramenta de síntese (ler os manuais!)
• as ferramentas têm directivas que “guiam” o processo de síntese
– Estrutura de circuitos combinacionais gerados por expressões
• depende da associação de operadores:
• a*(b+c+d+e)
• a*((b+c)+(d+e))
• a*(b+c)+a*(d+e)

– Codificação de FSMs
• codificação de estados é feita explicitamente pelo projectista
– a codificação adoptada afecta muito a qualidade do resultado
• obtêm-se melhores resultados dividindo uma FSM em vários blocos
– próximo estado, saídas, timers, ...

José Carlos Alves

Modelos RTL sintetizáveis
(regras genéricas suportadas pelas ferramentas de síntese)

– Atrasos são sempre ignorados
• o seu uso pode tornar incoerente a simulação e o comportamento do
circuito
– Sinais do tipo reg
• nem sempre são traduzidos em registos
• podem ser traduzidos em wire, D-flip-flops ou latches transparentes
– Atribuição contínua (assign sum=a^b^cin;)
• traduzida para um bloco de lógica combinacional
– Operadores aritméticos e lógicos
• inteiros sem sinal, dimensão dos resultados depende dos operandos
• são criados circuitos combinacionais que os implementam
• podem ou não ser partilhados para diferentes operações do mesmo tipo

José Carlos Alves

Projeto Sistemas Digitais

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Projeto Sistemas Digitais

Semelhante a Projeto Sistemas Digitais (20)

Projeto Sistemas Digitais