Verificação

Jo
João
ão Leonardo Fragoso

Desafios
2

Permitir o reuso entre a verificação dos módulos,

blocos e chip completo

Métricas bem definidas (cobertura)

Mínima redundância, evitar verificar a mesma coisa

Link com a fase final de testes (bring-up)

1
 Técnicas de Verificação
3

Tipos de Visão

Black Box

White Box

Tipos de verificação

Simulação

Verificação Formal

Emulação em FPGA

Black Box
4

Interface apenas na comunicação com o

mundo externo (ports)
Testbench
RAM Model

µP Transactor
DUV

(Design Under
I2C Controller Verification)
Transactor

2
 Black Box
5

Ambiente de Verificação Complexo

Geração automática dos valores de entrada

Validação das respostas

Análise de cobertura de testes

Automatismo!

Um testbench só por cada nível.

Black Box
6

Simulação

Simular  Verficar ≠ Testar

Imita-se o comportamento

Baseados em modelos

Modelos simples  Rapidez

Modelos complexos  Precisão

Permite encontrar erros no sistema (debug).

Permite a compreensão do projeto.

3
 Black Box
7

Testbench

Tradicional

Usando linguagens de descrição de hardware, ou alto nível ou

até mesmo linguagens de verificação

Linguagens de Verificação
E e Vera
 System C (SVL) e System Verilog

Black Box
8

Simulação

Tipos
 Block Level
 Testar a funcionalidade de um bloco
 Demorado para muitos blocos, mas
 Mais confiável (vários checks)
 Top Level
 Assumindo que os blocos estão corretos, testa integração e
conectividade
 Sanity checks
 verifica erros óbvios  tipo nada funciona.

4
 Black Box
9

Testbench - tradicional

Black Box
10

Exemplo: verificar um bloco Ethernet

Gerar tráfego na rede

Levar estes estímulos ao design

Verificar os dados

Verificar protocolo e timing

5
 Black Box
11

Automatismo

Linguagens de verificação
 Vera (synopsys)
 E (verisity – cadence)
 System Verilog
 System C

 Uso de scripts e arquivos

Black Box
12

Gerando estímulos

Tradicional
 Testesdirecionados
 Corner Cases

Randômico
 Geraçãode padrões diferentes a cada rodada do simulador
 Usando uma Linguagem de verificação isto é integrado

6
 Black Box
13

Simulação de Hard Cores

Modelagem para simulação

O cliente tem que poder simular o sistema onde o core vai ser
integrado

Modelagem funcional em RTL ou nível de sistema

White Box
14

Asserções permitem “ver” dentro do bloco

Aumenta observabilidade

Facilita a automação

Não necessitam de dados voltadas a elas

Não dependem de teste (estão sempre ativas)

7
 White Box
15

Specman Elite

A ferramenta da Cadence também é construída de forma a
“ver” dentro do componente

Testbench/Test Cases

João Leonardo Fragoso

8
 Diferença Clara
17

Testbench

Bancada de teste

Depende do circuito

Permite testar “todos“ os casos

Test Cases

Casos a serem verificados

Devem usar o mesmo testbenches

Estressar o circuito

Problemas tradicionais
18

Incompleto

Testa somente o caso implementado (ou especificado)

RTL

O que verificar comportamento ou netlist???

9
 Semântica da Simulação
19

Event Driven Simulation – Simulação orientada a

evento

modelo de atraso zero ou unitário

“triggado” por eventos,

Simula só tempos em que acontece alguma coisa e ignora
os outros

Cycle-Based Simulation – Simulação orientada a
ciclos

Simula os ciclos de clock

Assume atraso zero

Todos os ciclos de clock são simulados

Orientado a eventos
20

10
 Com atrasos
21

Hazard
22

Circuito com Hazard potencial

Qual é o efeito?

Precisa de mais valores que 0,1

11
 Testbench Tradicional
23

Testbech
24

Metodologias avançadas requerem testbenches em

linguagens de verificação que implementem
conceitos avançados como restrições para geração de
teste, asserções e definição de cenários de cobertura
para análise da cobertura funcional da verificação.

12
 Arquitetura possível
25

Transactor ou VIP
26

Módulo capaz de gerar estímulos simulando o

dispositivo ou sistema externo

Não precisa ser sintetizável

Pode (deve) ser reusado (VIP)

13
 BFM
27

Bus Functional Model (BFM)

Modelo para testar e gerar padrões em barramentos

Oferece tarefas ou interface procedural para especificar

operações no barramento de acordo com um protocolo pré-
definido.

TLM
28

Modelagem a nível de transações

É quando o nível de abstração da geração de estímulos deixa
de ser uma sequência de valores binários e passa a ser
transações funcionais ou tarefas, por exemplo, LER,
ESCREVER, DMA, RESET, etc.

Pode ser implementado na mão ou usando linguagens

especiais (HVLs)

14
 Verification Plan
29

Descreve a estratégia de toda a verificação

Definição do Testbench e test-setup

Definição dos Test cases

Definição da Coverage esperada

Etc. Dependente da estratégia ☺

Directed Tests
30

Testes direcionados

Teste de funcionalidade

Corner-cases

15
 Random Patterns
31

Geração de padrões diferentes a cada rodada do

simulador

Usando uma Linguagem de verificação isto é
integrado

Tentando aumentar a cobertura

Simulação de Hard Cores

32

Modelagem para simulação

O cliente tem que poder simular o sistema onde o
core vai ser integrado

Modelagem funcional em RTL ou nível de sistema

16
 SOC / Cosimulação
33

Precisa verificar block e top

Uso de um tesbench para bloco e top

Simulação de hardware/Software em conjunto

Tarefas
34

Engenheiro de Verificação

modela o transactor.

Difícil em HDL porque não existem estruturas de dados.

17
 Apêndice A
35

A linguagem E

Specman Cadence

E
36

18
 E
37

E
38

Não necessita gerar os dados

O gerador para o tipo struct é integrado à linguagem.

List of frames (gera a lista de frames necessária)

Todo o controle de memória é transparente

19
 E
39

E
40

O packing converte os dados num stream de bits

sozinho

Controlabilidade e observabilidade dos sinais
embutido e independente de simulador

20
 E
41

E
42

Métodos de comparação de estruturas

Métodos para destruir a lista

21
 E
43

Suporta asserções

E
44

Expansão

22