Verificação funcional de Hardware usando SystemVerilog
Este curso foi dado no final de 2007 na forma de estudo dirigido. Veja a versão atualizada deste curso.
Esta página contém direções e resultados.
Participantes
- Ana Karina
- Fabrício Lélis
- George Sobral Silveira
- Helder Fernando
- Isaac Maia
- Leandro Max
- Maria de L. Nascimento
- Rômulo Calado
- Erison Marcio da Silva
Material
Página com muitos Tutoriais para SystemVerilog
Tutoriais mais simples com SystemVerilog
Transaction-Level Modeling: SystemC and/or SystemVerilog
Using SystemC Reference Models in SystemVerilog Testbenches
Cadence "SystemVerilog Reference" capítulo 19
Resposta da Cadence sobre interface SC/SV
Posted By hariprem on 9/12/2007 4:01 AM
The plan is to provide detailed documentation and examples for OVM when it is released as open source at the end of Q4 this year. In the meantime, you can access the URM documentation/examples that are available to all Cadence users within the Incisive Plan to Closure Methodology. From a methodology perspective, OVM is based on URM and will be backward compatible. Thus if you want to understand more about OVM methodology, URM will show you all you want to know.
Roteiro de Estudo
Arquivo hello.sv
module hello(); logic a,y; always_comb y<=~a; initial begin $monitor(a,y); a<=1; #10; a<=0; end endmodule
Comando: vcs -sverilog hello.sv; ./simv
Resultado:
...blablabla...
Compiler version Y-2006.06; Runtime version Y-2006.06; Nov 8 14:16 2007
10
01
V C S S i m u l a t i o n R e p o r t
...blablabla...
Fazer Testbench Conception - Single Refmod para o DPCM em SV
Procurar implementações prontas de FIFOS em SV
AVM
estudo atribuido a Fabrício
The AVM is a methodology to build pieces of software, called testbenches,whose function is to verify eletronic desings. The AVM provides a structure for developing testbench architectures and a library of base classes and utilities that can be use to construct testbenches. Just as a desing is a network of desing components, a testbench is a network of verification components. The AVM defines verification components, their structure and interfaces. Pessoal, desculpa por tá em inglês, e ainda estou pesquisando sobre a fifo, mas quis contribuir com esse estudo sobre a metodologia.
URM e UVM
estudo atribuido a Leandro
Qual é a diferênça entre URM e UVM ??
Não consigo achar a diferença entre URM(Universal Reuse Methodology) que vem de eRM(e Reuse Methodoly) e UVM( Unified Verification Methodology). Já procurei por toda a documentação da cadence por isso e não tem nada além desse paper que já está aqui na página. Em alguns lugares eles são referenciados como se fossem intercabiáveis, ou seja, conclusão até o momento é que são dois nomes diferentes para a mesma coisa.
Favor encontre algo parecido ao AVM Cookbook sobre URM e UVM dentro da docmentação da Cadence e coloque na secção "Material" e façca um resumo.
Não existe absolutamente nada de muito concreto ou interessante que se possa achar sobre URM e UVM através no google ou Emule e Kazaa. Passei bastante tempo procurando documentação ou pelo algum paper que fosse um pouco mais concreto do que apenas as propagandas da Cadence mas não achei. A única apresentação que vale a pena ver eu colequei aqui. Então só resta a documentação da Cadence mesmo de onde vou tirar alguma coisa relevante.
O que há em termos de Verificação Funcional usando SystemVerilog com Cadence?
estudo atribuido a Ana Karina
Pelo que eu pude perceber a metodologia UVM foi abandonada em 2004. Tanto é que no site da Cadence não existe nenhuma documentação atual sobre a metodologia UVM.
O que existe para a Cadence hoje em termos de metodologia de verificação é o Incisive Plan to Closure Methodology (IPCM) que contém vários componentes metodológicos, tais como: ABV (Assertion-Based Verification), URM (Universal Reuse Methodology) e SVM (System Verification Methodology) e TBV (Transaction Based Verification). Já as metodologias eRM (e Reuse Methodology) e MRM (Mixed-Language Reuse Methodology) fazem parte da metodologia URM.
No site a seguir, existe toda a documentação da metodologia IPCM: documentação IPCM
OVM
OVM significa provavelmente "Open Verification Methodology".
estudo atribuido a Erison
encontrar informações sobre OVM
http://www.linuxelectrons.com/news/eda/11212/cadence-mentor-graphics-embrace-open-systemverilog
Fazer um Resumo da Metodologia VMM
estudo atribuido a Ana Karina
Esta metodologia está documentada no livro Verification
Methodology Manual (VMM). Ela usa SystemVerilog como linguagem de verificação e descrição de hardware. A natureza orientada a objetos da metodologia VMM é apontada como sendo o maior obstáculo para os engenheiros que desejam adotá-la, visto que classes, encapsulamento, herança, extensões entre outros aspectos da programação orientada a objetos torna o ambiente de verificação diferente do utilizado tradicionalmente para a construção dos testbenches.
Para tentar resolver este problema a metodologia VMM possui
quatro bibliotecas que ajudam no seu entendimento:
· A biblioteca VMM Standard que possui um conjunto de classes
e testbenches em SystemVerilog.
· A biblioteca VMM Checker que possui um conjunto de assertions
e checkers em SystemVerilog.
· A biblioteca XVC Standard que possui um conjunto de classes
básicas em SystemVerilog.
· O Framework de Teste de Software que possui uma biblioteca C
para verificação de software.
Estas bibliotecas têm por objetivo permitir o desenvolvimento
de equipes que passarão a criar mais facilmente o ambiente de verificação utilizando a metodologia VMM.
A seguir, será apresentada uma breve síntese destas quatro
bibliotecas.
Biblioteca VMM Standard
A metodologia VMM para SystemVerilog define uma arquitetura de
testbench que suporta verificação avançada e promove a sua reutilização. O controle deste testbench e a execução dos casos de teste envolvem uma série de etapas bem definidas sob o controle de métodos virtuais. A biblioteca VMM Standard define a classe vmm_env para controlar a execução de cada caso de teste, envolvendo a geração da configuração de casos de teste, construindo testbenches, redefinindo e configurando o DUT (Design Under Test), executando os testes e por fim gerando relatórios. Os métodos virtuais na classe vmm_env fornecem a infra-estrutura para cada uma destas etapas, porém muitos destes métodos têm de ser estendidos para realizar ações específicas do DUT.
A classe vmm_log fornece uma interface para o serviço de
mensagens da VMM, a fim de que todas as mensagens, independentemente da sua origem, possam ter uma visão comum. O serviço de mensagem descreve e controla mensagens, baseado em vários métodos: Message source, Message filters, Message type, Message severity, Simulator message handling.
A classe vmm_data é a base para todos os descritores de
transações e do modelo de dados para os testbenches. Esta classe pode ser estendida para construir qualquer modelo adequado a um testbench especifico, como por exemplo, em um modelo de dados para uma conexão Ethernet MAC ou para uma descrição de pacotes em um barramento serial. As transações são modeladas pelos descritores de transação, que também são estendidos da classe vmm_data. Isso torna mais fácil a criação de uma série de operações randômicas que é o caso das chamadas a procedimentos tradicionais.
Segue abaixo, outras classes importantes da biblioteca VMM
Standard:
· Vmm_channel: fornece uma interface genérica a nível transação.
· Vmm_broadcast: replica transações em múltiplos canais.
· Vmm_notify: fornece uma interface para a sincronização da
execução concorrente de threads.
· Vmm_xactor: serve como base para todas transações. Juntas, todas essas classes provêem a construção de blocos
essenciais para o ambiente de verificação, acelerando o desenvolvimento do testbench ao mesmo tempo em que fornece soluções personalizadas para atender às necessidades de verificação de DUT específicos. A estensibilidade destas classes pré-definidas são a chave para a abordagem orientada a objetos com VMM, onde cada equipe de verificação pode personalizar seu ambiente de testbench e as suas operações sem ter que modificar as suas próprias classes.
Biblioteca VMM Checker
O papel das assertions de encontrar erros, mais rapidamente,
tem sido bem documentado há alguns anos. As assertions capturam as intenções de Design, isolando os seus erros, acelerando o seu tempo de depuração e permitindo a análise formal para encontrar bugs que poderiam ser perdidos na simulação. Dadas estas vantagens, é normal que as equipes de verificação de Design usem assertions.
Uma biblioteca de assertion-checker é uma maneira de tornar
mais fácil o uso de assertions em Designs RTL. Os Checkers são projetados para mapear os elementos comuns do Design, tais como FIFOs, pilhas, memórias, máquinas de estado e interfaces.
Os Checkers são implementados como módulos do SystemVerilog,
podendo ser colocado em qualquer lugar do Design ou do testbench. O seu uso é muito simplificado, bastando que o usuário ligue o clock, reset e sinais ao checker.
Biblioteca XVC Standard
A metodologia VMM define um componente de verificação
estendido (XVC) e um sistema a nível transação estendido a partir de um bloco a nível transação ou a partir de uma combinação de blocos em nível transação. O livro da metodologia VMM especifica a biblioteca XVC standard com um conjunto de classes para serem utilizadas na construção de um XVC para o sistema em nível de verificação.
O XVC gerencia um componente de verificação opcional
responsável pelo alto nível de sincronização dos XVCs. A sincronização e os mecanismos de controle do XVC podem ser definidos pelo usuário de acordo com a necessidade do sistema ou de um teste especifico. A biblioteca XVC Standard especifica a classe xvc_manager, que pré define o gerenciamento da classe vmm_xvc_manager.
Framework de Teste de Software
A verificação utilizando software embutido é uma parte
importante de qualquer sistema de verificação de infra-estruturas em que um processador direciona aplicações de dados e controles de emórias e periféricos. Para um sistema em nível de testes onde uma CPU ou DSP faz parte do Design do sistema a ser testado, sendo desejável a existência de um ambiente de verificação que suporte a execução de testes de software para demonstrar que o sistema suporta com sucesso a execução de um sistema operacional, uma aplicação de software ou algoritmo de controle de um DSP.
A metodologia VMM define um ambiente de teste de software para
complementar a infra-estrutura dos testbenches. Este ambiente é usado no lugar de um sistema operacional com Design centrado na CPU. O ambiente de verificação do XVCs trabalha em conjunto com o framework de teste de software de tal forma que tanto os estímulos internos quanto externos podem ser gerados e sincronizados para criar condições para satisfazer os requisitos de verificação de hardware e software. Esta metodologia também define uma biblioteca C que inclui vários elementos que podem ser usados para implementar um ambiente de verificação e testes de software.
Referências:
[1] Bergeron, J. , Cerny, E. , Hunter, A. , Nightingale, A. Verification Methodology Manual for SystemVerilog, Synopsys Inc, EUA, 2005, 1nd ed.
[2] Bergeron, J., Anderson, T., Cerny, E., Hunter, A., Nightingale, A. SystemVerilog Reference Verification Methodology: VMM Adoption, EETimes: Design News, 2006.
Implementar uma FIFO usando um Vmm_channel
estudo atribuido a Rômulo Calado
Primeiro, é preciso pegar esse biblioteca e instalar na sua conta. Depois, rode um exemplo o mais bestinho possível que usa algo dela. Depois, faça (copiar-colar) um exemplo o mais simplesinho usando ese tal de Vmm_channel.
Um exemplo de Cobertura usando SV
De Maria de L. Nascimento
program eth_frame; // Mesmo com program não está compilando
endprogram // Talvez seja porque é class e não module
// Alguém já compilou um exemplo com class????
class frame;
// Definitions as above
covergroup cov;
coverpoint dest {
bins bcast[1] = {48'hFFFFFFFFFFFF};
bins ucast[1] = default;
}
coverpoint type {
bins length[16] = { [0:1535] };
bins typed[16] = { [1536:32767] };
bins other[1] = default;
}
psize: coverpoint payload.size {
bins size[] = { 46, [47:63], 64, [65:511], [512:1023], [1024:1499], 1500 };
}
sz_x_t: cross type, psize;
endgroup
endclass
Mais exemplos no link: http://lad.dsc.ufcg.edu.br/~maria/sv_code/
Implementar uma FIFO em SV puro
estudo atribuido a Maria de L. Nascimento
<Colocar aqui desenhos, códigos e conclusões>
de Elmar:
A base de uma FIFO em SV é a mailbox.
Exemplo de uso:
program dummy; // sem isso a mailbox não compila
endprogram
module source;
mailbox ch_out; // apontador de saída para mailbox
initial begin
ch_out = new(); // a mailbox mesmo é criada aqui
repeat (10) begin
int n;
n = $random % 5 + 5;
ch_out.put(n); // coloca algo na mailbox
end
end
endmodule
module sink;
mailbox ch_in; // apontador de entrada para mailbox
initial #2 // espera que a conexão seja feita
forever begin
int n;
ch_in.get(n); // retira algo da mailbox
$display(n);
end
endmodule
module tb;
source so(); // instancia source e sink
sink si();
initial #1 /* espera que a mailbox tenha sido criada */ begin
si.ch_in = so.ch_out; // faz conexão
end
endmodule
Esse só funciona com vcs. No NCVerilog da mais nova versão IUS62 chove "not yet implemented" e "unimplemented" ao tentar esse exemplo.
Parece que a mailbox é suficiente para fazer comunicação TLM para VeriSV.
Tem desvantagens:
- dá para conectar mais do que um modulo de saída
- ...???...
Encontre um jeito de eliminar essa desvantagem criando uma classe derivada de mailbox que só permite a atribuição de 1 saída.
Implementar uma FIFO usando AVM
estudo atribuido a Ana Karina
Rodar o exemplo mais simples de FIFO no AVM e relate aqui suas esperiências.
Esse AVM dá erros de compilação no vcs e mais ainda no ncsim. Tem que tentar realmente no vsim (Mentor). A solução AVM parece necessitar o dobro de linhas de código em relação a solução por mailbox.
Implementar uma FIFO usando o biblioteca Trusster
estudo atribuido a Helder
Na realidade Trusser é somente o nome do site que é especializado para engenheiros de verificação de hardware. Ele disponibiliza duas bibliotecas para verificação funcional, que são a Truss e a Teal. A biblioteca Teal já vem com algumas funções que podem ser utilizadas para fins de verificação funcional, que suporta várias metodologias. Já a biblioteca Truss é na realidade um Framework, que fornece camadas sobre a biblioteca Teal, adicionando mais classes, pseudo-templates, idiomas, e convenções para facilitar a contrução de um sistema de verificação funcional adaptável. Devido ao fato da biblioteca Truss possuir uma arquitetura em camadas, isso nos dá a flexibilidade de escolher como implementar as camadas, salvo que existem algumas convenções e classes básicas que podem servir como guia. Dessa forma percebemos que a biblioteca Truss não é para ser utilizada para criação de fifos, ou outra estrutura qualquer, mas sim para fazer verificação funcional de uma forma mais flexível que a biblioteca Teal.
<Colocar aqui desenhos, códigos e conclusões>
Implementar uma FIFO usando xxx
<Colocar aqui desenhos, códigos e conclusões>
Conclusão: a FIFO mais gostosa é ...
Implementar TB 1.1 usando FIFO gostosa
Cosimulação
Fazer um exemplo do uso de C dentro de SV
Fazer um exemplo do uso de C++ dentro de SV
estudo atribuido a George