IVM (Interoperable Verification Methodology)

A metodologia IVM foi fruto do estudo de duas metodologias (VeriSC e OVM), em observância às virtudes e defeitos de cada uma delas, com intuito de gerar uma metodologia melhorada.

A arquitetura da metodologia IVM pode ser observada na figura 3.10:

Figura 3.11: Arquitetura do testbench da metodologia IVM[40]

São componentes do ambiente de verificação da metodologia IVM:

 Test Case Model: é responsável pela coordenação dos agentes que estimularão o DUV, realizando função similar ao Virtual Sequencer do OVM, modelando a especificação dos casos de teste e permitindo que todas as funcionalidades fornecidas pelos agentes sejam acionadas de maneira coordenada. Este módulo possui referências aos Agents e Monitors do ambiente, através das quais realiza o controle, proporcionando uma visão centralizada de todas as funcionalidades. Os casos de testes são implementados por extensões de classes, permitindo assim que novos testes sejam criados com a certeza de que as propriedades anteriores do ambiente serão mantidas. Por conter informações específicas da instância do sistema que está sendo verificado, este componente não pode ser reusado em outros contextos, ou seja, na verificação de outros módulos ou projetos.

 Agent: reúne todas as funcionalidades de um determinado componente externo ao sistema, proporcionando ao Test Case Model um conjunto de funcionalidades que poderão compor seus casos de teste através da geração e captura de transações que

irão estimular uma determinada interface do sistema. Além dos papéis de captura e geração de transações, este componente também é responsável pela comparação das respostas recebidas com as respostas geradas pelo Reference Model, sendo alheio ao contexto em que está inserido, podendo ser reusado em diversos projetos, assim como o Sequencer do OVM.

 Reference Model: é responsável por modelar idealmente o comportamento do sistema que está sendo verificado, normalmente implementado em um nível mais alto de abstração e sem detalhes temporais. Diferentemente do Data Checker do OVM, que modela o comportamento e faz checagens de respostas, o Reference Model apenas modela o comportamento do sistema em questão, permitindo que este componente possa ser estruturado hierarquicamente. É implementado em nível de transação (TLM), o que facilita o enfoque na funcionalidade que se deseja modelar, além de permitir uma simulação bem mais rápida.

 Driver: também conhecido como Bus Functional Model (BFM), o Driver é uma entidade ativa que realiza a comunicação entre interfaces RTL e TLM, convertendo as requisições em nível de transação (TLM) do componente Agent ou Reference Model em estímulos baseados em sinais, e vice-versa.

 Monitor: é um componente do IVM responsável pela coleta de informações de cobertura funcional e de checagem de protocolo de comunicação, funcionando através da extração das informações (como endereços acessados ou operações realizadas) que são transmitidas pelos sinais monitorados. Este módulo checa a cobertura utilizando as informações obtidas e verifica a conformidade do protocolo através de regras descritas pelo projetista.

A Metodologia IVM foi concebida para a linguagem SystemC, e utiliza a técnica de cobertura criada pelo autor, baseada em espaço de valores e probabilidade. Foi desenvolvido um mecanismo de decisão de parada para as simulações, que toma por base o comportamento da cobertura; esta sempre aumentará ou ficará constante, e após um determinado tempo (razoavelmente grande) de simulação, tenderá a se estabilizar em um determinado valor. Existe um mecanismo que finaliza a simulação quando se atinge um percentual fixo por um determinado tempo. De acordo com os estudos de casos exemplificados na proposta (PRADO, 2009) a cobertura funcional utilizada nunca testou todas as possibilidades devido ao conjunto de possibilidade ser grande.

Além do descrito acima, existe também em IVM a ausência do uso de automação para geração dos módulos do ambiente de verificação, como ocorre na metodologia VeriSC. Apenas provê as interfaces para cada componente existente na arquitetura do bloco. IVM e VeriSC não fazem uso de assertions no ambiente de verificação.

3.2.4.1 Fluxo de desenvolvimento

O fluxo de atividades do IVM é bottom-up, onde são desenvolvidas três atividades de validação do testbench para cada módulo implementado, e apenas no final é construído o ambiente de verificação funcional do DUV total.

3.2.4.1.1 Sanity Checking

Atividade semelhante ao Double Refmod da metodologia VeriSC. Tem o objetivo de validar os seguintes componentes: Test Case Model, Referencial Model e Agent. A arquitetura de testbench para esta atividade é mostrada na figura 3.8

3.2.4.1.2 Interface Refinement

Essa atividade tem como objetivo refinar a interface de comunicação baseada em transação (TLM) para interfaces baseadas em sinais. Nesta etapa são inseridos os drivers e

monitors para cada interface. A figura 3.9 mostra a arquitetura do ambiente de verificação

criado.

Test case model

Referencial Model

Referencial Model

Agent Agent

TLM Referência

3.2.4.1.3 Enviroment Validation

Depois de validar cada interface de comunicação de sinal, essa atividade junta todas as interfaces num único testbench e emulando a presença do DUV no ambiente de verificação. A arquitetura do ambiente de verificação pode ser visto na figura 3.10.

A figura 3.10 cria o ambiente de verificação completo para depois inserir o DUV. Os

drivers e o modelo de referência inseridos no retângulo pontilhado emulam a presença do

DUV no ambiente de verificação.

3.2.4.2 Análise da Metodologia IVM

Como já mencionado, a metodologia IVM provê o suporte ao desenvolvimento do ambiente de verificação funcional antes da inserção do DUV. Além disso, o reuso de componentes durante o processo de desenvolvimento do testbench, o suporte a comunicação bidirecional e o suporte a cobertura são características importantes da metodologia. Todavia, a

Referência TLM Interface Sinal

Test case model Referencial Model Referencial Model Agent _Agent Dri ve r Dri ve r Monitor Dri ve r Dri ve r Monitor Referência TLM Interface Sinal

Test case model

Referencial Model Referencial Model Agent Agent Dri ve r Dri ve r Monitor

Figura 3.13: Testbench da atividade Interface Refinement

metodologia não tem o suporte de geração automática ou semiautomática de testbench.