Este artigo descreve a instalação e o uso de software livre para modelar circuitos lógicos digitais no Verilog como uma alternativa aos produtos comerciais Incisve da Cadense e ModelSim da MentorGraphics. Comparação de simulações no ModelSim e Verilator. Uma metodologia de verificação universal, UVM, também será considerada.
Instalação do software SystemC UVM
1. O verificador
Uma das linguagens de descrição de hardware é o verilog. Você pode escrever um módulo neste idioma.
Por exemplo, existe um esquema de contador:
Seu código ficará assim:
reg [3:0]counter; always @(posedge clk or posedge reset) if(reset) counter <= 4'd0; else counter <= counter + 1'd1;
Após a simulação, obtemos as formas de onda:
Pode-se observar que o próximo valor, um a mais que o anterior, será gravado nos registradores de contador ao longo da frente da freqüência do relógio.
Um módulo escrito pode ter uma estrutura mais complexa, difícil de verificar manualmente todos os estados de. Nós precisaremos de testes automatizados. Para isso, é necessário desenvolver um ambiente de teste em uma das linguagens de programação. O ambiente de teste nos dará a oportunidade de realizar uma verificação funcional completa do dispositivo.
Para testar o código do projeto, além de idiomas como Verilog, SystemVerilog, Python (para escrever modelos), você pode usar a linguagem
SystemC . SystemC é uma linguagem de design e verificação em nível de sistema para modelos em nível de sistema implementados como uma biblioteca C ++ de código aberto.
Uma maneira de verificar os módulos Verilog usando o SystemC é converter arquivos verilog em C ++. Ajude-nos com este Verilator.
O Verilator é o simulador gratuito Verilog HDL mais rápido que supera a maioria dos simuladores comerciais. O Verilator compila SystemVerilog sintetizado (geralmente esse não é um código de teste), bem como algumas instruções do SystemVerilog e Synthesis em código C ++ ou SystemC simples ou multiencadeado. O Verilator foi projetado para grandes projetos em que o desempenho da simulação é fundamental e é particularmente adequado para gerar modelos de processadores executáveis para equipes de desenvolvimento de software embarcadas. O Verilator é usado para simular muitos projetos de gateway multimilionários muito grandes com milhares de módulos e é suportado por muitos provedores de tecnologia IP, incluindo IP da Arm e todos os famosos provedores IP do RISC-V.
O Verilator pode não ser a melhor opção se você espera uma substituição completa do NC-Verilog, VCS ou outro simulador comercial da Verilog ou simulador comportamental da Verilog para um projeto muito pequeno. No entanto, se você está procurando uma maneira de portar o Verilog sintetizado para C ++ ou SystemC, e sua equipe está livre para escrever apenas código C ++, este é um compilador Verilog gratuito para você.
Para instalar a versão mais recente no Ubuntu: baixe o arquivo
no link do site oficial .
Instalar:
2. Onda GTK
O GTKWave é um visualizador de formas de onda com todos os recursos e também permite converter arquivos do formato vcd para o fst, mais conveniente e mais rápido.
Instalar:
sudo apt-get install gtkwave
3. SYSTEMC
Uma linguagem para projetar e verificar modelos no nível do sistema implementados na forma de uma biblioteca C ++ de código aberto.
Como mencionado anteriormente, o verilator suporta o systemc, portanto, você precisa criar um projeto no qual a referência de teste seja descrita no systemc e os arquivos de origem no verilog sintetizado. Para fazer isso, precisamos das bibliotecas do compilador g ++ fornecidas pela Accelera. A Accellera Systems Initiative é uma organização independente, sem fins lucrativos, dedicada à criação, suporte, promoção e promoção de padrões de projeto, simulação e verificação em nível de sistema para uso na indústria eletrônica global.
Faça o download do arquivo:
http://accellera.org/images/downloads/standards/systemc/systemc-2.3.1a.tar.gzInstalar:
tar -xvf systemc-2.3.1a.tar.gz cd systemc-2.3.1a mkdir objdir sudo ./configure --prefix=/usr/local/systemc-2.3.1a/ sudo make sudo make install cd ../
4. UVM para SYSTEMC
Este artigo revisará um projeto que implementa ferramentas de verificação UVM. A verificação é uma confirmação da conformidade do produto final com os requisitos de referência predefinidos. Uma de suas ferramentas de verificação pode ser testes. Para executar sequências de teste em modelos de dispositivos reais no nível das descrições de RTL, é necessário desenvolver um ambiente de teste.
O UVM - (Universal Verification Methodology) é uma metodologia de verificação universal, um padrão que permite o desenvolvimento e reutilização eficientes de ambientes de validação de bloco IP. O UVM é uma metodologia de verificação cujas tarefas incluem organizar um ambiente eficaz em torno da unidade em teste. Suas vantagens:
- estrutura clara na forma de blocos dedicados que decidem
- tarefas
- a capacidade de reutilizar blocos em projetos subseqüentes;
- a máxima automação possível da verificação;
- as informações de relatório mais completas que permitem, quando ocorre um erro, identificar suas causas com a maior rapidez e precisão possível e sugerir soluções.
As metodologias UVM consistem em duas partes: um conjunto de regras para a construção de um ambiente de teste e uma biblioteca de espaços em branco para verificação, por exemplo, um gerador de texto, coletor de estatísticas etc. A principal vantagem do UVM é sua versatilidade e compatibilidade com ambientes de terceiros.
Como o systemc suporta a metodologia UVM, vamos instalar as bibliotecas necessárias.
Faça o download do arquivo:
https://www.accellera.org/images/downloads/drafts-review/uvm-systemc-1.0-beta2.tar.gzInstalar:
tar -xvf uvm-systemc-1.0-beta2.tar.gz cd uvm-systemc-1.0-beta2/ mkdir objdir sudo ./configure --prefix=/usr/local/systemc_uvm/ --with-systemc=/usr/local/systemc-2.3.1a sudo make sudo make install
Criamos uma aliança:
sudo mkdir /usr/local/uvm_systemc_aliance
Copie o conteúdo das pastas / usr / local / uvm_systemc_aliance / e /usr/local/systemc-2.3.1/ para esta pasta
Faça o download do projeto finalizado no link:
https://github.com/paprikun/SYSTEMC/Abra a pasta de exemplos do verilator.
A pasta rtl contém uma descrição do dispositivo. Neste exemplo, é um controlador PWM.
No arquivo makefile da pasta sim para a construção do projeto.
Na pasta tb está o código para o verificador. A pasta tb / uvm contém um exemplo de ambiente uvm. O arquivo principal é um ponto de entrada nos testes; conecta o dispositivo em teste ao ambiente uvm.
Tentamos construir o projeto a partir da pasta sim com o comando make all. Vemos um erro:
/usr/local/uvm_systemc_aliance//include/systemc.h:120:16: error: 'std::gets' has not been declared using std::gets;
Nós corrigimos isso substituindo a linha 120:
#if defined(__cplusplus) && (__cplusplus < 201103L) using std::gets; #endif
Mais uma vez, tentamos executar o testbench e tropeçamos com aviso:
/usr/local/uvm_systemc_aliance//include/sysc/packages/boost/get_pointer.hpp:21:40: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] template<class T> T * get_pointer(std::auto_ptr<T> const& p)
Altere auto_ptr para unique_ptr.
Montagem e simulação de projetos
Agora que as bibliotecas estão instaladas e funcionando, estamos construindo o projeto: make all. O arquivo executável simu deve aparecer na pasta sim. Este é um objeto criado pelo compilador. Começamos com a equipe ./simu. O seguinte deve aparecer:
SystemC 2.3.1-Accellera --- Jun 28 2019 11:39:29 Copyright (c) 1996-2014 by all Contributors, ALL RIGHTS RESERVED Universal Verification Methodology for SystemC (UVM-SystemC) Version: 1.0-beta2 Date: 2018-10-24 Copyright (c) 2006 - 2018 by all Contributors See NOTICE file for all Contributors ALL RIGHTS RESERVED Licensed under the Apache License, Version 2.0 UVM_INFO @ 0 s: reporter [RNTST] Running test ... simulation real time = 9 sec UVM_INFO uvm_default_report_server.cpp(666) @ 179490249010 ps: reporter [UVM/REPORT/SERVER] --- UVM Report Summary --- ** Report counts by severity UVM_INFO : 1 UVM_WARNING : 0 UVM_ERROR : 0 UVM_FATAL : 0 ** Report counts by id [RNTST] 1 UVM_INFO @ 179490249010 ps: reporter [FINISH] UVM-SystemC phasing completed; simulation finished
Quando a simulação termina, a gravação na forma de wafe termina. O arquivo simu.vcd pode ser aberto com gtkwave:
Para exibir os sinais à esquerda, selecione SystemC, e, mantendo pressionada a tecla Shift, selecione qualquer sinal e clique em Anexar. As dicas de ferramentas aparecem na barra de ferramentas quando você passa o mouse. A rolagem do mouse funciona, você precisa pressionar shift ou cntrl.
Também existem maneiras de converter esse arquivo em outro menor.
Se houver modelos, o sim fará a conversão. No terminal, digite o comando vsim. Nos modelos de terminal sim:
vcd2wlf simu.vcd simu.wlf
Ou usando gtkwave no terminal linux:
vcd2lxt simu.vcd simu.lxt vcd2lxt2 simu.vcd simu.lxt2
Para comparar o tempo de simulação, um projeto semelhante foi criado, mas já para o
Modelsim . Pasta modelsim_example. Ambiente UVM criado de forma semelhante. A sintaxe é semelhante, apesar de diferentes idiomas. Se você instalou o Modelsim com suporte ao uvm, poderá executar o comando make all.
Além do ambiente nos dois projetos, foi feita uma simulação em tempo real das medições.
Com o tempo, a diferença acabou:
Como você pode ver na tabela, o verilator tem uma vantagem. Os dados são apresentados para um PC com 8 GB de RAM, um processador de 8 núcleos, 800 MHz, carregando um núcleo.
Compare o tamanho do arquivo:
Aqui o verilator perde, mas você pode experimentar a criação de formas de onda e profundidade de traços, o período de gravação (o início e o final da gravação de formas de onda podem ser alterados). Qual arquivo para trabalhar é com você.
Durante o teste, além do tempo da simulação em si, foi encontrada uma discrepância na leitura dos dados de entrada do barramento de entrada. Se os dados do barramento in mudarem durante a frente clk, o Modelsim leu os dados após a frente, verilator antes:
input clk; input [7:0] in; reg [7:0] in_last_ ; ... always @(posedge clk) begin ... in_last_ <= in; ... end
Durante o teste, esse ponto precisa ser levado em consideração, pois parte do ambiente de teste para diferentes simuladores funcionará de maneira diferente.
Além disso, o verilador não leva em consideração o estado "x" do sinal e converte tudo para "0";
UVM TESTBENCH
Considere o ambiente de teste, a pasta tb / uvm.
O UVM testbench é o ambiente acima do dispositivo. Neste exemplo, o dispositivo é um controlador PWM. Diagrama do ambiente UVM:
Como você pode ver no diagrama, o UVM consiste em blocos (classes). Cada bloco executa suas funções. O exemplo mostra um dos layouts possíveis do ambiente de teste. O nome e a funcionalidade de cada classe correspondem à classe da qual são herdados. Vamos considerar cada classe com mais detalhes.
Arquivo de ambiente env.h ou env.svh. Esta é uma classe que pode conter uma ou mais classes de agentes, nas quais três classes estão conectadas: sequenciador, driver, monitor. Não há nenhum agente no exemplo, mas sua função é implementada na classe env. Para o teste, precisamos escrever uma sequência de ações - sequenciamento.
Vamos seguir para o código inicial de seqüenciamento:
sequence_[n]->start(sqr, NULL);
Sequencer (sequenciador) - arquivo sequncer.h. No verilog do sistema, acabou por usar o seqüenciador padrão. Uma classe que contém uma ou mais seqüências (sequência) (arquivos sequence_a.h, sequence_a.svh). Cada sequência é uma cadeia de ações. Uma dessas ações pode estar enviando uma transação. Transação - transferência de dados de uma classe para outra. A classe na qual as transações são descritas é bus_trans. Abaixo está uma descrição de duas classes, cada uma das quais ideologicamente tem suas próprias funções específicas: driver e monitor.
Driver - arquivo drv.h, drv.svh. Uma classe que recebe transações de um seqüenciador e as converte em sinais. O motorista atua como assistente de sequenciador em um nível inferior. Considere enviar um pacote.
Sequência abre uma janela de transação, o driver detecta esse evento e começa a receber dados. A sequência está aguardando uma resposta do driver. O driver simula os sinais para o dispositivo e depois sinaliza ao seqüenciador que a janela pode ser fechada. A idéia é que o sequenciador funcione em um nível alto e o driver em um nível inferior.
Os sinais são conectados através do barramento de interface ao dispositivo. A interface é descrita nos arquivos vip_if.h, vip_if.svh.
Em seguida, você precisa verificar se os sinais de saída correspondem aos esperados. Existem duas soluções:
- Escrevendo um modelo para um dispositivo
- Verificação de sinal através do agente UVM
No exemplo, a segunda opção é considerada. Para testar o dispositivo no nível funcional, é necessário comparar a saída com a esperada. O requisito para o dispositivo era a exatidão do ciclo de serviço fornecido do sinal e o período do sinal. Para monitorar os sinais de saída, uma nova classe é gravada - Monitor (arquivo monitor.h, monitor.svh). Geralmente, em um ambiente de teste, o monitor transfere os sinais na transação (para um nível superior) e é enviado para a classe de comparação - placar.
Neste exemplo, os sinais são verificados imediatamente. Em caso de discrepância entre o valor esperado e o medido, o teste é interrompido.