O ambiente de verificação (ou testbench, em inglês) modela o universo no qual o projeto sendo verificado, de agora em diante designado por DUV (Design Under Verification), vai funcionar depois de concluído. Ele contém o código que é responsável por gerar, obser- var e verificar dados de entrada/saída do DUV. Em geral, este código é decomposto em componentes geradores de estímulos, componentes de monitoração, modelos de referência, comparadores e, em alguns casos, marcadores (scoreboards). Estes componentes podem ser implementados em linguagens de descrição de hardware, tais como SystemC ou SystemVeri- log, ou em linguagens de propósito geral, tais como C/C++ ou Java. Nas subseções seguintes, é apresentada uma visão geral dos componentes do ambiente de verificação funcional.
2.2.1
Geradores de Estímulos
O componente gerador de estímulos é responsável por produzir as entradas que são utilizadas para a execução do DUV. Assim, este componente deve modelar o comportamento do usuário ou dos demais sistemas que fornecem algum dado para a operação do DUV. Diante da rea- lidade de que um projeto pode ser desenvolvido uma única vez e ser reusado diversas vezes em diferentes contextos, o gerador não deve se restringir a valores que podem ser fornecidos pelos vizinhos do DUV no sistema corrente. De fato, o foco da geração de estímulos deve ser o conjunto de valores que o DUV é capaz de operar. Ao proceder desta maneira, o engenheiro tem mais chances de exercitar cenários mais complexos e que ocorrem raramente (em inglês, estes cenários são chamados de corner cases).
Os estímulos devem ser gerados de forma que seja possível repetir uma determinada si- mulação quantas vezes forem necessárias pelo engenheiro. Isto permite, por exemplo, que o engenheiro detecte um erro, faça as devidas alterações para removê-lo e em seguida repita a simulação para se certificar de que tal o erro foi removido de fato e nenhum outro erro foi in-
serido pelas modificações realizadas no projeto. Em geral, duas abordagens são empregadas para a geração de entradas do projeto: geração aleatória e geração direta. Na abordagem ale- atória, o engenheiro faz uso de funções que geram seqüências pseudo-aleatórias de números, isto é, seqüências que podem ser previstas conhecendo-se o número inicial. Na abordagem direta, cada estímulo é individualmente definido pelo engenheiro. Esta abordagem é impor- tante nos momentos iniciais do projeto, quando ele ainda possui erros crassos. A abordagem aleatória tem o potencial de exercitar mais funcionalidades do DUV que a abordagem direta, pois as seqüências de números pseudo-aleatórias podem exercitar o DUV de maneiras não previstas pelo engenheiro.
2.2.2
Monitores
O monitor é a parte do ambiente de verificação que é responsável por observar as entradas e saídas do DUV. A partir desta observação, o engenheiro pode realizar análise de cobertura funcional. Este tipo de análise, que será apresentado nas seções seguintes, permite ava- liar a qualidade da verificação segundo as funcionalidades que o sistema deve implementar. Um monitor também pode conter uma lógica para que os valores observados por ele sejam convertidos para níveis de abstrações diferentes, conforme as necessidades do projeto. Por exemplo, ele pode converter um valor observado na saída do DUV, considerado de baixo nível, para um nível de abstração mais alto para facilitar a análise pelo engenheiro.
Em ambientes de verificação sofisticados, à medida que a verificação funcional é execu- tada, as informações coletadas pelos monitores podem ser exploradas para se re-configurar os componentes geradores de estímulos. Esta re-configuração tem como objetivo simular uma quantidade maior de funcionalidades. Este tipo de abordagem é chamado de geração dirigida por cobertura [37; 46].
2.2.3
Modelos de Referência
Ao fornecer uma entrada para o DUV, o engenheiro precisa de algum mecanismo para deter- minar se o resultado produzido na saída é de fato o resultado esperado. Uma forma de deter- minar este valor esperado é por meio de uma re-implementação do DUV em uma linguagem de mais alto nível que a linguagem usada para a descrição do DUV. Esta re-implementação
é chamada de modelo de referência (em inglês, reference model). O modelo de referência calcula todas as saídas esperadas do sistema baseando-se nas entradas que são utilizadas du- rante a verificação funcional. Em diversas metodologias, a entidade responsável por atestar que o resultado produzido pelo DUV está certo ou errado é chamada de scoreboard.
Idealmente, o DUV e o modelo de referência devem ser implementados por engenheiros diferentes para diminuir a possibilidade de que uma interpretação equivocada da especifica- ção do sistema seja repetida no DUV e no ambiente de verificação. Se esta repetição ocorrer, a verificação funcional pode aprovar um DUV que não se comporta conforme o esperado.
2.2.4
Verificadores
Um verificador (em inglês, Checker) é a parte do ambiente de verificação que valida, do ponto de vista funcional, se o projeto está funcionando conforme determinado pela especi- ficação. A quantidade de estímulos usados na verificação funcional é grande o suficiente para tornar impraticável a comparação manual dos resultados produzidos pelo DUV com os resultados esperados de fato. Assim, o verificador compara automaticamente o resultado produzido pelo DUV com o resultado produzido pelo modelo de referência. Se os resultados são iguais, a simulação prossegue normalmente. Em caso contrário, o verificador emite uma mensagem notificando o erro. Em alguns casos, o verificador não existe como uma entidade explícita do ambiente de verificação. De acordo com a necessidade do projeto, a comparação que é realizada pelo verificador é feita pelo scoreboard.
2.2.5
Abordagens Black Box, Grey Box e White Box
De acordo com a visibilidade do DUV, existem três abordagens de verificação funcional: Black Box, White Box e Grey Box.
Na abordagem Black Box, a verificação funcional é realizada sem nenhum conhecimento da implementação real do DUV. A verificação é acompanhada nas interfaces do DUV, sem acesso direto aos estados internos dele e sem conhecimento de sua estrutura e implemen- tação. Esta abordagem possui a vantagem de não depender de qualquer detalhe de imple- mentação. Mesmo que o DUV seja modificado durante a fase de verificação, o ambiente de verificação não precisa ser alterado se a interface não for mudada. Esta abordagem também
permite que os elementos do ambiente de verificação sejam reutilizados na verificação de outros dispositivos. O ponto negativo dessa abordagem é que se perde um pouco do controle da parte interna da implementação do DUV.
Com a abordagem White Box, o engenheiro tem uma visibilidade completa da estrutura interna do DUV. A vantagem de se usar White Box é que se pode testar diretamente fun- ções do dispositivo sendo verificado, simplificando o processo de localização dos erros. A desvantagem dessa abordagem é que ela é altamente acoplada a detalhes de implementação do DUV. Conseqüentemente, alterações no DUV podem resultar em modificações no ambi- ente de verificação. Além disso, é necessário ter conhecimento de detalhes internos para a criação de cenários de testes e saber quais as respostas que devem ser esperadas. Conseqüen- temente, o reuso dos elementos do ambiente de verificação em outros dispositivos pode ser mais complicado.
A abordagem Grey Box possui características das duas abordagens. Ela procura resolver o problema da falta de controlabilidade do black Box e da dependência de implementação do white Box. Um exemplo de um caso de teste típico Grey Box pode ser usado para aumentar as métricas de cobertura. Nesse caso, os estímulos são projetados para linhas de código específicas ou para verificar funcionalidades específicas.