Upload
nguyenanh
View
218
Download
0
Embed Size (px)
Citation preview
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
71
Síntese de Sistemas Digitais
comportamentalestrutural
físicoplacas, MCMs
módulos, chips
células
layout detransistores
transistoresportas lógicas
registos, muxs
processadores, memórias
fluxogramas,algoritmos
transferências entre registos
expressõesbooleanas
funções detransistoresdispositivológico
RTLsistema
níveis
de a
bstra
cção
alto nível (behavioral)
lógica
RTL
circuito
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
72
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
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
73
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
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
74
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
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
75
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, ...
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
76
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
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
77
Construção de modelos sintetizáveis
– always - duas formas• always @(posedge ...): os sinais tipo reg são traduzidos para FFs tipo D
always @(posedge clock or negedge reset)beginif (!reset)acc = 8’b00000000;
elseacc = data_in;
end
• always @(a or b or ...): sinais do tipo reg são latches ou wires
reset assíncrono;tem de ser avaliado no primeiro if(...)
always @(a or b or sel)beginif (sel)
out = a;elseout = b;
end
out é uma latch out é uma função combinacional de sel, a e b
lista de sensibilidadesalways @(a or sel)beginif (sel)
out = a;end
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
78
Construção de modelos sintetizáveis
– inferência de latches em construções always - regra geral• latches são geradas para sinais do tipo reg que não sejam
completamente especificados para todos os casos de instruções condicionais (por exemplo if (sel) out = a; e quando sel==0 ? )
• no caso contrário é apenas gerado um circuito combinacional sem elementos de memória
– latches são (geralmente) indesejáveis e fatais• como podem afectar o funcionamento de um circuito síncrono?!
– ferramentas de síntese ignoram a lista de sensibilidades• em construções do tipo always @( enable or bus_a or bus_b)
• o simulador não: só avalia o bloco quando algum sinal muda de estado• um modelo pode simular mal mas o circuito resultante funcionar bem!
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
79
Construção de modelos sintetizáveis
– inferência de buffers de 3-estados• atribuindo z a um sinal (do tipo reg)
module three_state(in, out, en);input in, en;output out;reg out;
always @( in or en)if (en)out = in;
elseout = 1’bz;
endmodule
assign out = en ? in : 1’bz;
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
80
Construção de modelos sintetizáveis– ciclos
• for(...): só são suportadas 4 formas:– crescente ou decrescente de passo constante (...;index=index±step)– condição de terminação com <, >, <= ou >=
• while (...): cria um ciclo combinacional; deve ser quebrado com @(posedge clock)
always @( a or b or carry )for(i=0;i<=31;i=i+1)begins[i] = a[i]^b[i]^carry;carry = a[i]&b[i] | a[i]&carry | b[i]&carry;
end
always @( posedge clock )while (x<y)begin@(posedge clock);x=x+z;
end
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
81
Verificação do projecto
• Verificação funcional– processo para demonstrar a correcção funcional de um modelo
• que estímulos para garantir que o modelo está funcionalmente correcto?
• Importância da verificação (multi-million gate…)– consome tipicamente 70% do esforço do projecto– N Engs para projecto RTL mas 2N para verificação– os testbenches representam até 80% do volume total de código– verificação está no caminho crítico de um projecto
• Reduzir o custo da verificação– explorar paralelismo e a reutilização dos processos– criar testbenches a níveis de abstracção elevados (>RTL, eg. Matlab)– minimizar o factor humano (que é a verdadeira fonte de erros!)
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
82
Verificação de um modelo
Testbench
DUVDesign Under
Verification
estímulos saídas
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
83
O “factor humano” na verificação
EspecificaçãoInterpretação
Codificação RTL
Verificação
Modelo RTL
Factor humano
O mesmo projectista
A verificação não é feita contra a especificação originalO processo pode ser “viciado” se apenas existir uma só interpretaçãoÉ (mais ou menos…) normal as especificações conterem ambiguidades
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
84
Como reduzir o factor humano?• Automatização
– Criar procedimentos que verifiquem o projecto automaticamente (!)• quem faz esses procedimentos?
• Redundância– dois projectistas: um projecta o sistema e o outro verifica– cada um tem uma interpretação da especificação
Especificação
Interpretação A Codificação RTL
Verificação
Modelo RTL
Interpretação B
Projectista A
Projectista B
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
85
Processos de verificação• Verificação formal
– usa processos formais para provar características de um modelo• verificação da equivalência entre modelos (equivalence checking)• verificação que um modelo satisfaz condições (model checking)
• Verificação funcional– pretende provar que o modelo RTL satisfaz a especificação
• pode-se mostrar que é satisfeita a funcionalidade ensaiada• mas é impossível provar que é satisfeita a especificação (informal...)
• Geração de testbenches– geram estímulos para verificar certas propriedades do modelo
• por exemplo, tentar violar uma propriedade
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
86
Verificação da equivalência(equivalence checking)
• Verifica se dois modelos RTL/estruturais são equivalentes– verifica dois netlists após algum pós-processamento automático (ou manual)
• por exemplo, inserção da cadeia de scan (para construir a infraestrutura de teste)
– verifica se o netlist produzido pela síntese é equivalente ao modelo RTL• o modelo pode estar mal codificado, as ferramentas de síntese podem ter bugs
– permite verificar se um modelo RTL representa um netlist já existente
síntese / modificação manual
Verificaçãoda equivalência
RTL/netlistRTL/netlist
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
87
Verificação do modelo(model checking)
• Verifica se o modelo satisfaz condições/afirmações– as condições a verificar são sujeitas a interpretação
• exemplo de condições:– todos os estados de uma FSM são atingidos? não ocorre deadlock?– um interface responde correctamente sob condições dadas?
– problema: identificar na especificação que condições verificar...
codificação RTL
Verificaçãodo modelo
RTLespecificação
interpretação
condiçõesafirmações
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
88
Verificação funcional• Verifica se o modelo realiza a funcionalidade especificada
– a tradução da especificação para o código RTL é feita por humanos• é um processo manual “naturalmente” sujeito a erros
– especificações são (geralmente) representadas em linguagens informais• com ambiguidades, sujeitas a diferentes interpretações
– apenas se garante a correcção da funcionalidade ensaiada
codificação RTL
Verificação funcional
RTLespecificação
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
89
Geração de testbench• geração automática de estímulos para simulação
– com base em medidas de cobertura de código (code coverage)• que construções do código RTL são ensaiadas para um conjunto de estímulos?• que estímulos são necessários para activar e verificar parte do código?
– é o projectista que deve verificar os resultados da simulação– os estímulos produzidos não verificam a funcionalidade do projecto
cobertura do código
geração de testbench
testbenchRTL métricas
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
90
Prototipagem• Verificação por prototipagem (o DUV é hardware físico)
– como construir um protótipo de um ASIC?• componentes off-the-shelf
• que nível de equivalência? funcional, RTL ou lógico?
• sistemas baseados em FPGAs (oferecem actualmente milhões de gates…)
– o testbench é hardware (fontes de sinal, analisadores lógicos...)
– características eléctricas e dinâmicas são diferentes da tecnologia alvo• o processo de validação tem de conseguir “absorver” essas diferenças
– funcionamento em tempo real (ou quase)
– possibilita verificação com estímulos complexos de sistemas físicos• disponíveis em tempo real, mas difíceis de modelar
• exemplo: sistemas de controlo de processos físicos
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
91
Simulação• Verificação por simulação (DUV é um modelo informático)
– menor rapidez mas maior flexibilidade do que prototipagem• observar o estado de qualquer nó ou componente• forçar sinais a estados desejados • parar e reiniciar a simulação em qualquer estado• controlar de forma precisa a temporização de eventos assíncronos
– verificação funcional realiza-se em diferentes estágios do projecto• RTL, pós-síntese (gate-level), pós-layout (verificação temporal)
– diferentes modelos de atrasos • fornecidos nas bibliotecas que caracterizam a tecnologia alvo
– simulação de faltas• construção de conjuntos de estímulos para detectar defeitos• estimulam o circuito para “ver” o efeito de defeitos nas saídas
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
92
Simulação - problemas
• Como se constroem estímulos ?– não há procedimentos formais para gerar estímulos– processo heurístico, baseado na intuição e conhecimento do sistema– não é praticável a verificação exaustiva
• circuito com 75 entradas ⇒ 275 testes (1.2x103anos@1us/teste)
• Como se sabe se os resultados são correctos ?– só verifica a funcionalidade exercitada pelos estímulos– o modelo simulado é uma aproximação
• Estímulos para verificação e para teste– verificação: detectar e diagnosticar erros de projecto
• não é possível enumerar todos os erros de projecto
– teste: detectar e diagnosticar defeitos de fabrico• defeitos de fabrico (faltas) são modelados como erros lógicos
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
93
Simulação compiled code
• executa um modelo compilado do circuito– o circuito é traduzido em instruções de um processador
– apenas para verificação funcional; não suporta análise temporal– o comportamento de componentes é modelado por subrotinas– adequado para simular o comportamento de sistemas síncronos
– permite realizar simulações cycle based (resposta para cada ciclo de clk)
MOV AL,AAND AL,BMOV Y,ALMOV AL,BAND AL,YMOV AH,ALNOT ALMOV Z,AHMOV F,AL
para cada transição de clk (código x86):
DQ
A
BF
Y
clk
DQ
Z
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
94
Simulação cycle based• simulação de sistemas exclusivamente síncronos
– só interessa conhecer o estado das entradas D dos FFs– todas as funções combinacionais são traduzidas em equações
lógicas– apenas são simuladas as transferências entre registos
• sincronizadas com um único flanco do relógio
– simuladores cycle based não suportam• qualquer informação temporal associada ao circuito
– É assumido que são satisfeitos todos os requisitos temporais dos FFs
• entradas assíncronas• latches• circuitos com múltiplos domínios de relógio
– análise temporal realizada com ferramentas de análise estática• que também só se podem aplicar a circuitos síncronos
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
95
Simulação event-driven
• simulação de eventos– um evento é uma mudança do estado de um sinal num tempo dado
• os componentes que usam esse sinal são activados e avaliados
• as mudanças resultantes dessas avaliações geram novos eventos
– usa um modelo do circuito para gerar e propagar eventos• eventos nas entradas primárias são produzidos pelos estímulos
• eventos nos restantes nós são gerados pela avaliação dos componentes
– permite processar estímulos e sinais assíncronos• análise do comportamento com os atrasos dos componentes
• avaliação do funcionamento com eventos não sincronizados
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
96
Simulação event-driven
avançar tempode simulação
fim
não há eventosextrair eventos para este tempo
até ao próximo evento pendente
actualiza sinaisactivos
propaga mudançasdos sinais
avalia componentesactivados
introduz os novoseventos na lista
actualiza o valor dos sinais modificadospelos eventos deste tempo
propaga o valor dos sinaisactivos até aos componentesque os usam e activa essescomponentes
a avaliação dos componentesactivados produz novos eventosem tempo futuro (atrasos dos componentes) ou no mesmo tempo
todos os eventos produzidos pelos estímulos já foram introduzidos na lista
início
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
97
Simulação event-driveninitialbegina=2; b=3; c=1;#25 c=2;
end
always @(a or b or c)begin#5 z=a+8;#10 y=b+c;#4 k=z+y;
end
c=1b=3a=2
t=0 t=5
z=a+8
t=15
y=b+c
t=19
k=z+y
t
c=xb=xa=x
eventos agendados e extraídos por ordem
t=40
y=b+c
t=25
c=2
initialbegin
a=2; b=3; #10a=4; b=6; #10a=6; b=8; #10 $stop;
end
always @(a or b)begin
a=a+bend
O que acontece neste caso?
lista de eventos
∆
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
98
co-simulação
• cooperação de dois simuladores num só ambiente– simuladores cycle based e event driven
• um simula as partes síncronas, outro as partes não síncronas• ganho de rapidez em relação a um simulador (só) event driven• percorrem o eixo dos tempos (de simulação) em simultâneo
– simuladores de Verilog e VHDL (ou outras linguagens)• um simulador para cada linguagem num ambiente integrado• permitem simular modelos mistos (DUV em Verilog, testbench em VHDL)
• simuladores mixed-language– VHDL e Verilog traduzidas para um código intermédio (object code)– um só simulador simula esse modelo intermédio
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
99
Simulaçãointerpretação do valor lógico desconhecido
• Quando um circuito lógico é ligado,– memórias e flip-flops ficam com valores lógicos não definidos– é necessário prever um mecanismo de iniciação (reset)
• em circuitos “reais” está geralmente associado ao power-up
• Valor lógico desconhecido: u (em Verilog é representado por x)
– representa o estado de sinais lógicos não iniciados resultantes de• não iniciação de registos e memórias• indefinição do estado de entradas primárias do circuito a simular• resultantes de contenções em barramentos
– é processado juntamente com os valores lógicos 0 e 1• operadores lógicos são generalizados para tratar o valor lógico u
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
100
Simulaçãointerpretação do valor lógico desconhecido
• Tabelas de verdade para AND, OR e NOT
AND 0 1 u0 0 0 01 0 1 uu 0 u u
OR 0 1 u0 0 1 u1 1 1 1u u 1 u
NOT 0 1 u1 0 u
• Perda de informação propagando o valor lógico u
0
1
uu
u
u
u
desconhecidos, mas semprecom valores contrários
é sempre 1
não serve usar u e uuQ
Q
u
uu
1
desconhecido
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
101
Simulaçãoo valor lógico Z
• Modelação de buffers com saída de alta impedância
I O
E
• Um sinal com o nível lógico Z– pode ser forçado com 1 ou 0 (pull-up ou pull-down)– é sempre interpretado como u por uma entrada
Tabela de verdade:
I E 0 1 u0 Z 0 {0,Z}1 Z 1 {1,Z}u Z u {u,Z}
a
b
o a b 0 1 Z u0 0 u 0 u1 u 1 1 uZ 0 1 Z uu u u u u
Tabela de verdade de um barramento com 2 entradas
em que casos pode ocorrer contenção no barramento ?
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
102
Simulação - modelos de atrasos
• atraso de transporte– um atraso na propagação do nível lógico
• atrasos de subida e de descida– diferentes atrasos para as transições 0-1 e 1-0
• atrasos ambíguos– mínimos e máximos para os atrasos 0-1 e 1-0
• atraso inercial– duração mínima de uma entrada para ser propagada para a saída
• setup time e hold time (em flip-flops)
– setup time: tempo mínimo para D estar estável antes de clock– hold time: tempo mínimo para D permanecer estável após clock
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
103
Estratégias de verificação
• Que abordagens de verificação?– qual o nível de granulosidade dos elementos a verificar?– há ou não acesso e conhecimento da implementação interna?
• Como são verificadas as respostas?– análise visual de formas de onda não é (geralmente) praticável– comparação de dados armazenados em ficheiros
• Produzidos off-line por processos de confiança (nível mais elevado)
– incluir no próprio testbench o processo de verificação das saídas• “executando esta sequência de instruções sei que no instante t=134ns
R1 deve ter 35, R5 deve ter 4, ..., o PC deve ficar com A7B4,… senão ocorreu um erro” mas qual, onde e porquê?
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
104
Estratégias de verificação
• Verificação aleatória– não significa “atirar” aleatoriamente zeros e uns para as entradas!– aplicados estímulos que realizem aleatoriamente operações bem
definidas e realistas na operação do sistema• sequências de transacções num barramento com dados aleatórios
– possibilita a ocorrência de situações não previstas– devem ser contempladas as estatísticas de operações e dados– problema: como se podem prever as respostas?
• analisando as respostas off-line• comparando com respostas de modelos mais abstractos já validados• comparando com respostas de modelos em simulação
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
105
Planeamento da verificação• identificar as propriedades que interessa verificar
– a partir da especificação do sistema a projectar– os projectistas podem também sugerir verificações– definir a que nível deve ser verificada cada propriedade
• em modelos comportamentais de componentes em desenvolvimento?– verificar a funcionalidade contra a especificação
• num modelo estrutural com componentes já validados?– verificar “apenas” as interconexões entre esses componentes
• definir testes para verificar cada propriedade– exemplo: para validar o modelo de um filtro digital:
• resposta ao impulso unitário (calcular FFT - resposta em frequência)• resposta com degraus positivos e negativos, sinusóides com comp. DC
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
106
Planeamento da verificação• agrupar testes com requisitos semelhantes
– um único teste pode verificar todas as operações de uma ALU– um teste deve verificar o funcionamento de um CPU...– ...e outro teste deve verificar o funcionamento da memória cache
• verificações podem necessitar de novos recursos– design-for-verification: instrumentar modelos para facilitar o
processo de verificação (+ controlabilidade/observabilidade)• permitir “carregar” contadores longos (como validar um RTC?)• incluir mecanismos para inserção automática de “erros”• gerar estímulos em função das respostas do modelo
• construir testbenches para cada grupo de testes– uma equipa de verificação responsável por um grupo de testes– exige cooperação com as outras equipas de verificação e projecto
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
107
Veriloggeração de sinais periódicos
reg clkparameter CYCLE=10;
initial clk = 1’b0;
alwaysbegin#(CYCLE/2); clk = ~clk;end
`timescale 1ns/1nsreg clkparameter CYCLE=15;alwaysbegin#(CYCLE/2.0); clk = 1’b0;#(CYCLE/2.0); clk = 1’b1;end
`timescale 1ns/100psreg clkparameter CYCLE=15;alwaysbegin#(CYCLE/2.0); clk = 1’b0;#(CYCLE/2.0); clk = 1’b1;end
Diferenças?
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
108
Sincronização de estímulos• geração de sinais (des)sincronizados
– problema: ocorrência de condições de competição (race conditions)
– solução: não usar flancos sobrepostos! E num circuito “real” ?
initial // apply resetbeginrst = 1’b0; #200rst = 1’b1; #200rst = 1’b0;
end
alwaysbegin#50 clk = 1’b0;#50 clk = 1’b1;end
clk
rst
possibilidade de competição entre clk e resetO que acontece se reset for síncrono com o negedge de clk ?
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
109
Sincronização de estímulos
initial // apply resetbegin // for 2 clocksrst <= 1’b0; clk <= 1’b0;repeat (2) #50 clk <= ~clk;
rst <= 1’b1;repeat (4) #50 clk <= ~clk;
rst <= 1’b0;
forever #50 clk <= ~clk;end
clk
rst
não ocorre competiçãoreset muda ao mesmo tempo que clk;quando clk troca, rst ainda tem o estado anterior (atribuições non-blocking)
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
110
Entrada de dados de ficheiro
• leitura de dados de um ficheiro de texto para um vectormem é um vector de registos, por exemplo: reg [15:0] mem[0:127]filename é o nome do ficheiro de texto que contém os dadosos dados são em ASCII, representando números em binário ou hexadecimalpodem ser incluídos comentários; posições não lidas ficam com ‘xxxx’
$readmemb( “filename”, mem, start_index, end_index); // binário
$readmemh( “filename”, mem, start_index, end_index); // hex
//ficheiro de dados em binario@00 // endereço 0x00 (zero, em hexadecimal)0000_0000_0000_0001 // dado, o caracter ‘_’ é um separador0000_0000_0000_1000@10 // os dados seguintes sao colocados a partir do endereço 0x100000000000001011
//ficheiro de dados em hexadecimal@00 // endereço 0x00 (zero, em hexadecimal)00_01 // dado, o caracter ‘_’ é um separador0AFE@10 // os dados seguintes sao colocados a partir do endereço 0x10FF_0B
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
111
Saída de dados para ficheiros de texto• $fopen, $fclose, $fmonitor, $fwrite, $fdisplay
integer HI, HQ; // File handlers
initial // open output filesbeginHI = $fopen(“dout_I.dat”);HQ = $fopen(“dout_Q.dat”);// simulate ... close files$fclose(HI); $fclose(HQ);
end
initial$fmonitor(fh,...); // $monitor para ficheiro
always @(posedge clock)begin$fdisplay( HI, “%d”, HI); // inclui newline$fwrite( HQ, “%d\n”, HQ); // nao inclui newline
end
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
112
Monitorização de valores
• nomes hierárquicos – operador . (ponto)task dump_regfile; // dump CPU registersinteger i;beginfor(i=0;i<8;i=i+1)$display(“R%d=%d (%h)”, i, mycpu.regfile_1.regs[i],
mycpu.regfile_1.regs[i] )end
initialbegin// apply reset and check initial state$display(“Ctrl unit initial state: %b”, mycpu.ctrl_1.state);
end
sinal da instância ctrl_1 dentro de mycpu
reg [4:0] state;
ctrl_1mycpu
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
113
Geração de números aleatórios• geração de estímulos aleatórios (valor ou tempo)
$random(seed); // inicia o gerador de números aleatóriosx = $random; // retorna um inteiro aleatório (32 bits)x = $random / 32’h0fff_ffff; // inteiro entre [0..15]
• especificação de atrasos não constantes: #( expressão )integer x;reg [15:0] y;reg [7:0] cmd;x = $random / 32’h00ff_ffff; y = $random / 32’h0fff_fffa;cmd = $random / 32’h3fff_ffff;for(i=0; i<MAXLOOP; i=i+1)begin#(x) apply_initcommand;#(x*y/3) send_command( cmd, data);
end
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
114
tasks• Sub-rotinas em Verilog
– Interesse particular para a construção de testbenches– Podem conter atrasos, chamadas a outras tasks
task writecommand;input [15:0] data; // data to writeinput [1:0] address; // address of output portbegin
din = {4'b0010, 2’b00, address}; // compose and write command
load = 1; #10 load = 0; #10 // ld for 1 clockdin = data[15:8]; // send MS byteload = 1; #10 load = 0; #20 // ld for 2 clocksdin = data[7:0]; // send LS byteload = 1; #10 load = 0; #30 load = 0;
endendtask
initialbegin…writecommand(16'h39A6, 2'b00 );
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
115
Verilog PLI• PLI – Programming Language Interface
– Ligação do simulador de Verilog a programas em C– Acesso aos dados da simulação (escrita e leitura)– Construção de tasks específicas para tarefas de “alto nível”
• Link for ModelSim– Toolbox do MatLab para simulação conjunta MatLab-Modelsim
Tutorial em: http://www.asic-world.com/verilog/pli.html
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
116
Co-simulação MatLab-ModelSim
http://www.mathworks.com/products/modelsim/description1.html
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
117
Síntese de Alto Nível(behavioral synthesis)
while (x<a)beginxl=x+dx;ul=u-(5*x*u*dx)-(3*y*dx);yl=y+(u*dx);x=xl; u=ul; y=yl;
end
unidade decontrolo
* + -
R
mux mux mux
R R
mux mux
datapath
descrição comportamental(algorítmica)
estrutura RTL
unidadesfuncionais
registos
muxs e barramentos
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
118
Síntese de alto nívelmedidas de qualidade
• Objectivos importantes– simplificar o hardware e minimizar o tempo de execução– minimizar tempo ⇒ explorar paralelismo ⇒ complicar hardware
• Medidas de qualidade da solução RTL– avaliadas antes da implementação física, baseadas em estimações
• número e complexidade das unidades funcionais e registos• número de ciclos de relógio, período de relógio• complexidade da unidade de controlo• espaço ocupado pelas interligações, barramentos e multiplexers• potência consumida
• Compromissos área-rapidez– grande espaço de soluções
área
1/veloc.
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
119
Síntese de alto nível
y1=a+b;y2=x1+x2;y3=z+t;
y3
+
mux mux
R R Ry1 y2
a x1 z b x2 t
uma unidade funcional3 ciclos
+
R R Ry1 y2 y3
a x1 zb x2 t
++ +
3 unidades funcionais1 ciclo
espaço ocupado pelo datapath?complexidade da unidade de controlo?número de ciclos de relógio ?duração do ciclo de relógio ?potência consumida ?
Exemplo: 3 adições independentes - duas soluções alternativas:
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
120
Síntese de Alto Nível• transformações de alto nível
– semelhantes às realizadas pelos compiladores• propagação de constantes, simplificações algébricas, optimização de
ciclos
• sequenciamento (scheduling)– atribuição das operações a ciclos de execução (ciclos de relógio)
• minimizar o número de ciclos necessário para completar a operação• explorar o paralelismo natural do algoritmo
• alocação e “colagem” (allocation e binding)– selecção de registos e de um conjunto de unidades funcionais
• minimizar a complexidade do hardware• escolher entre diversos compromissos de unidades funcionais• Forte interligação com o sequenciamento
– “colagem” das operações a unidades funcionais que as realizem• uma operação pode demorar diferentes tempos em diferentes FUs
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
121
Representação internas• Compilação da descrição comportamental
– representação interna baseada em grafos• DFG (Data Flow Graph)
– representa as operações e as dependências entre dados e resultados
CFG (Control Flow Graph)– representa a sequência de controlo de blocos de operações
y=a+b;z=y*c;k=a+y;
+*
+k
cb a
y
z
if (a==b)z=y+c;
elsek=a+y;
a==b
z=y+c k=a+y
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
122
SequenciamentoASAP e ALAP
ASAP - As Soon As Possibleatribuir cada operação ao primeiro ciclo
* +
-
<+
* *
* *
-
1
2
3
4
*
ciclo
ALAP - As Late As Possibleatribuir cada operação ao último ciclo
*
+-
<+
*
*
*
*
-
1
2
3
4
*
ciclo
4 multiplicadores1 subtractor1 somador6 unidades funcionais
2 multiplicadores2 subtractores1 somador5 unidades funcionais
* +
-
<
+
*
*
*
*
-
1
2
3
4
*
ciclo
2 multiplicadores1 subtractor1 somador4 unidades funcionais
ASAP com restrições,fixando o número e tipodas unidades funcionais
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
123
Sequenciamentoheurísticas
• Lista de prioridades (list scheduling)– operações ordenadas por função de prioridade
• caminho mais longo, número de sucessores, mobilidade das operações
– em cada iteração são sequenciadas as operações prontas• uma operação pronta tem todos os antecessores sequenciados • a lista de prioridades determina a ordem de sequenciamento
• FDS - Force Directed Scheduling– distribui as operações de forma a balancear a utilização das Fus
• baseada na probabilidade de cada operação ser atribuída a cada ciclo
– requer o conhecimento de ASAP e ALAP: mobilidade– determina um sequenciamento num número fixo de ciclos
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
124
Alocação e “colagem”• Alocação (allocation)
– seleccionar um conjunto de unidades funcionais que realizem as operações
• nos ciclos de execução determinados pelo sequenciamento• em cada ciclo uma FU só pode realizar uma operação
• Formulação básica como um problema em grafos– Existe um ramo (não dirigido) entre 2 operações se:
• Puderem ser realizadas na mesma unidade funcional (mesmo tipo)• Não estiverem atribuídas a períodos de tempo sobrepostos
– determinação do número mínimo de sub-grafos completos• Um sub-grafo completo: operações compatíveis entre si
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
125
Alocação e colagem
• Grafo de compatibilidades
12
3
4
56FU1
FU3
FU2
operações 1 e 3 são compatíveis
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
126
Sequenciamento e alocaçãooptimização conjunta
• Programação Linear Inteira (PLI)– formulação básica baseada em variáveis inteiras binárias:
– restrições no número de ciclos ou de unidades funcionais – computacionalmente pesado, impraticável para problemas reais
• Métodos heurísticos– arrefecimento simulado (simulated annealing)
• flexibilidade para tratar restrições complexas associadas às FUs• necessário número elevado de iterações, soluções sub-óptimas• computacionalmente pesado
– algoritmos genéticos
xij = 1 se a operação i é atribuída ao ciclo j0 caso contrário
FEUP/DEEC : EEC0055 / Projecto de Sistemas Digitais, 2006/2007José Carlos Alves
127
Elementos do datapath• Registos
– armazenam variáveis
• Barramentos– interligam componentes
• Multiplexers– agulham barramentos
• Unidades funcionais– modelo básico
• uma FU só faz um tipo de operação num ciclo– modelos realistas para unidades funcionais
• diferentes tipos de operações para a mesma unidade (ex. uma ALU)• durações dependentes do tipo de operação (vários ciclos de relógio)• diferentes implementações para a mesma operação (custo/desempenho)• diferentes operadores pipelined• unidades funcionais reconfiguráveis dinâmicamente