SystemVerilog

É uma linguagem proprietária derivada de Verilog (linguagem de descrição de hardware e de Verificação), com recursos de orientação a objetos, bastante análoga à SystemC. Sua concepção teve como motivação oferecer a Verilog a capacidade de mo- delagem de sistemas em alto nível e mecanismos de Verificação mais integrados e efici- entes. Foi desenvolvida pela Accellera Inc. em 2002, sendo um padrão IEEE 1800-2005. A linguagem SystemVerilog tem sido amplamente utilizada por várias empresas e inclui um excelente conjunto de ferramentas de Verificação, destacando-se a cober- tura funcional e assertions que funcionam de maneira nativa. Entretanto, por ser uma linguagem de domínio específico, ou seja, é usada exclusivamente por projetistas de hardware, não oferece um conjunto variado de bibliotecas. Este problema é contornado através da importação de funções diretamente de código C/C++, de forma a permitir que funcionalidades já implementadas (como funções matemáticas ou algoritmos) não precisem ser refeitas.

3.2.2

Arquitetura

A principal característica da arquitetura do OVM é o foco na interoperabilidade de seus componentes, através da padronização de interfaces e configurabilidade dos com- ponentes, além de diversas facilidades para simulação como a checagem de condições e coleta de informações de cobertura. Maiores detalhes sobre os componentes do OVM serão fornecidos a seguir e uma visão geral da arquitetura é dada na figura 3.7:

Figura 3.7: Arquitetura do OVM

� Virtual Sequencer: é responsável pela coordenação das sequências que serão ge- radas nos Sequencer instanciados no ambiente, definindo a ordem de geração das transações, criando a visão de cenário de caso de teste. Por conter informações específicas da instância do sistema que está sendo verificado, este componente não pode ser re-usado em outros contextos.

� Sequencer: cria as transações que irão estimular uma determinada interface do sistema, através da geração e requisição de dados ao sistema, sendo alheios a que contexto estão inseridos, podendo ser reusados em diversos projetos, ao contrário do Virtual Sequencer.

� Driver: também conhecido como Bus Functional Model (BFM), o Driver é uma entidade ativa que realiza a injeção e captura de estímulos, convertendo as re- quisições em nível de transação (TLM) do Sequencer em estímulos baseados em sinais e vice-versa.

� Monitor: é uma unidade passiva do ambiente de Verificação responsável pela coleta de informações de cobertura e de checagem de dados através da extração das informações que são transmitidas e recebidas pelo sistema. Com estas infor- mações, as transações que serão utilizadas pelo Data Checker podem ser geradas e a análise de cobertura funcional pode ser feita, além de possibilitar a checagem de eventuais violações de protocolo de comunicação.

� Data Checker: é o equivalente ao Refmod e Checker do VeriSC, sendo respon- sável tanto pela modelagem do comportamento do sistema como pela checagem dos resultados gerados. Também é chamado de Score Board, e recebe as informa- ções dos seus monitores associados, sendo capaz de inferir das entradas e saídas geradas e qual deveria ser a resposta correta.

O foco em interoperabilidade de seus componentes e na análise de cobertura são os conceitos chave do OVM, proporcionando redução do esforço na construção de ambi- ente de Verificação e na melhoria da qualidade dos testes realizados, respectivamente. O apoio das principais companhias de EDA do mundo torna o OVM o mais impor- tante esforço da indústria para padronização e unificação de componentes e metodo- logias de Verificação.

3.2.3

Fluxo de atividades

Em fluxos de desenvolvimento em cascata, como é o caso onde o OVM é aplicado, é necessário que uma atividade que precede a outra, seja completamente terminada, para que a próxima atividade seja iniciada. Por isso, o OVM necessita de uma especifi- cação completa e prévia do sistema que será verificado. Isto pode implicar em atrasar o desenvolvimento do ambiente de Verificação até que a especificação e um release com- pletos do sistema estejam disponíveis.

Outro aspecto interessante a ser notado é que o OVM não prevê nenhum meca- nismo para validação de seus componentes3. Esta validação implícita torna ainda mais importante a interoperabilidade de seus componentes, já que não existe um mecanismo dedicado para validar os componentes, é fundamental que o ambiente de Verificação possa ser construído utilizando uma biblioteca de componentes que já foram utilizados e acreditados.

3.3

Cobertura Funcional

Esta importante técnica de análise, apesar de não figurar como uma metodologia, possui um papel extremamente importante em ambientes de Verificação, sendo consi- derada um dos pilares de sustentação das principais metodologias. Consiste em medir quais funcionalidades foram e quais não foram estimuladas, fornecendo ao engenheiro de Verificação informações relevantes e criteriosas sobre a qualidade dos vetores de teste que estão sendo utilizados.

3.3.1

Técnicas utilizadas

Dentre as possíveis técnicas de Cobertura Funcional, duas, consideradas mais rele- vantes, serão explicitadas:

3_{A validação do componente de Verificação ocorre implicitamente através de sua utilização em di-} versos projetos.

� Baseada em regras[7]: a análise é realizada através de um conjunto de regras explícitas que precisam ser definidas pelo projetista para que a simulação seja finalizada. Ex: Quando três endereços consecutivos de uma memória forem es- critos, a simulação pode ser finalizada. A qualidade da definição das regras é fun- damental para que a Cobertura Funcional e a Verificação sejam bem sucedidas. Portanto, especial atenção deve ser empreendida durante o uso desta técnica, para que importantes aspectos funcionais do sistema não sejam suprimidos; � Baseada em espaço de valores[2]: esta análise se concentra em como as infor-

mações devem ser amostradas, definindo, por exemplo, se os dados devem ser agrupados ou se devem ser considerados individualmente. Ao invés de definir a condição de parada explicitamente, o projetista analisa os dados coletados e de- fine em qual o momento a simulação pode ser finalizada. Ex: Quando 80% dos endereços de memória forem acessados, a simulação pode ser finalizada. Esta técnica possui a grande vantagem de livrar o projetista da definição de todos os possíveis valores que deveriam gerados, deixando a análise de cobertura mais rápida e eficiente.

Em ambas as técnicas descritas, é necessário que regras sejam definidas, baseando- se em proposições que podem não ser necessariamente verdadeiras ou dependendo do julgamento subjetivo das informações geradas. O impacto principal disto é ter uma cobertura inadequada e ineficiente, permitindo que erros possam ficar mascarados.

3.4

Análise Comparativa

Um quadro comparativo, sistematizado na tabela 3.1, resume as características an- teriormente descritas do VeriSC e do OVM, fornecendo ao leitor uma visão geral das metodologias e de suas diferenças e semelhanças.

Característica VeriSC OVM Fluxo de

desenvolvimento Modelo cascata Modelo cascata Ambiente de Verificação executando antes do DUV Suporte direto Suportado, mas necessita da criação de um modelo funcional adicional Interoperabilidade

dos componentes Pouco suportada Suporte efetivo Organização

estrutural

Monolítico e sem uma clara distinção de fronteiras de níveis

Em camadas para geração dos estímulos Cobertura Funcional Baseada em regras Baseada em espaço de

valores Linguagem de

programação SystemC SystemVerilog Tabela 3.1: Quadro comparativo do VeriSC e OVM

É interessante perceber que a comparação realizada representa a análise sobre um ponto de vista, não representando uma verdade absoluta. Esta observação se deve ao fato de que termos como "pouco" ou "direto" serem subjetivos e podem ser questiona- dos pelo leitor. A idéia deste quadro comparativo é reunir as características percebidas em ambas as metodologias, permitindo que leitor tenha todos os subsídios necessários ao completo entendimento deste trabalho.

No próximo capítulo, que descreve a metodologia de Verificação proposta, será mostrado que todas as vantagens que estavam disjuntas nas metodologias considera- das, como a interoperabilidade do OVM e o ambiente de Verificação pronto antes do DUV do VeriSC, foram unificadas em uma só metodologia. Além de unificar os pontos fortes de cada metodologia, novas funcionalidades foram adicionadas, como o suporte efetivo ao fluxo de desenvolvimento iterativo e incremental que não é explicitamente suportado por nenhuma das metodologias consideradas.

Metodologia IVM

Este capítulo apresenta o IVM (acrônimo para Interoperable Verification Methodo- logy), que foi desenvolvido no contexto deste trabalho, suportando diferentes tipos de projetos de sistemas digitais. As seções a seguir detalham a arquitetura proposta, o fluxo de atividades da metodologia e como foi feita sua validação através da exposição dos estudos de caso realizados.

4.1

Arquitetura

A arquitetura do IVM foi concebida tendo em mente as virtudes e defeitos das metodologias descritas no estado da arte, principalmente o OVM, de forma que uma metodologia melhorada fosse obtida. As contribuições e modificações arquiteturais propostas ficarão mais explicitas durante o decorrer da leitura desta seção e uma visão geral pode ser vista na figura 4.1.

Figura 4.1: Arquitetura do IVM 24

� Test Case Model: é responsável pela coordenação dos agentes que estimularão o sistema em questão, realizando função similar ao Virtual Sequencer do OVM, modelando a especificação dos casos de teste, permitindo que todas as funci- onalidades fornecidas pelos agentes sejam acionadas de maneira coordenada. Este módulo possui referências para os Agents e Monitors do ambiente através da qual os controla, permitindo uma visão centralizada de todas as funcionali- dades proporcionadas. Os casos de teste 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 es- pecíficas da instância do sistema que está sendo verificado, este componente não pode ser re-usado em outros contextos, ou seja, na Verificação de outros módulos ou projetos.

� Agent: concentra todas as funcionalidades de um determinado componente ex- terno ao sistema, proporcionando ao Test Case Model um conjunto de funcio- nalidades 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 é res- ponsável pela comparação das respostas recebidas com as respostas geradas pelo Reference Modele são alheios a que contexto estão inseridos, podendo ser reusa- dos 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 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 de- seja modelar, além de permitir uma simulação bem mais rápida.

� Driver: também conhecido como Bus Functional Model (BFM), o Driver é uma en- tidade 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 re- alizadas) que são transmitidas pelos sinais monitorados. Este módulo analisa de

cobertura utilizando as informações obtidas e verifica a conformidade do proto- colo através de regras descritas pelo projetista.

As principais contribuições arquiteturais do IVM estão na composição das arqui- teturas do VeriSC e do OVM, através de modificações no Reference Model (somente modelando comportamento), permitindo construção hierárquica de novos modelos, assim como acontece no VeriSC e não é possível no OVM. Outra contribuição está nos Agents, que aparecem independentes de seus respectivos Drivers e Monitors, além de assumirem a função de checagem de transações que no OVM é feita pelo Data Checker (modela comportamento e checa transações) e no VeriSC é realizada pelo Checker.

Figura 4.2: Camadas do IVM

Camada Interface

Test Case Model

int getTotalError();

void configureSeed(unsigned int seed); void generateReport(); void executeTestCase(); int getFunctionalError(); int getProtocolError(); double getCoverage(); bool haltExecution(); Agent int getNumberOfError();

void comparator(); Monitor

void addToTraceFile(trace_file *traceFile); int getNumberOfError();

double getCoverage(); void generateReport();

TLM TLM padrão (Interface, Channel, Port e Export) Reference Model Definida pela especificação do sistema

Driver void bindPort(INTERFACE &interface); INTERFACE& getExport(); Design Under Verification Definida pela especificação do sistema

O requisitos de interoperabilidade e organização em camadas são satisfeitos através da padronização dos componentes do ambiente de Verificação, permitindo que uma interface padrão (todos os componentes de uma determinada camada deve possuir uma interface padrão e se comunicar somente com as camadas verticalmente adjacen- tes) seja assegurada, como pode ser visto na figura 4.2 e na tabela 4.1. Desta forma, independentemente da origem deste componente, desde que ele seja aderente a esta interface e organização em camadas, ele poderá ser seguramente utilizado sem necessi- dade de modificações ou adaptações. Na parte de anexos deste documento se encontra a biblioteca desenvolvida e sua interface como referência.

Pelo que foi mostrado na arquitetura proposta, as principais qualidades das me- todologias do estado da arte, como ambiente executável antes do DUV e interopera- bilidade dos componentes, continuam sendo atendidos, só que de maneira unificada, permitindo que novas funcionalidades sejam oferecidas. As contribuições da metodo- logia proposta ficarão mais evidentes nas seções posteriores, que descreverão seu fluxo de atividades e estudos de caso realizados.

4.2

Fluxo de atividades

O fluxo de atividades do IVM, apesar de similar ao VeriSC[7], possui um ponto chave que o difere: sua visão bottom-up que é oposta a do VeriSC que é top-down. No IVM, o sistema é decomposto numa série de partes componentes e é verificado parte por parte até que todas elas estejam integradas e validadas.

Na figura 4.3, uma visão geral do fluxo de atividades é fornecida, permitindo que o leitor tenha a clara idéia de como as atividades estão relacionadas e quais são seus pré-requisitos.

Figura 4.3: Visão geral do fluxo de atividades do IVM

As etapas mostradas são executadas sempre de forma iterativa e incremental, para cada nova funcionalidade adicionada ou modificação feita, garantindo que os propó- sitos de cada etapa sejam sempre atingidos. A sua estruturação bottom-up e seu fluxo de atividades são as características que adequam esta metodologia em processos de desenvolvimento iterativos e incrementais, como o ipPROCESS[5].

Os pré-requisitos necessários para todas as etapas são: a especificação completa ou parcial do sistema; o plano de Verificação do sistema com as metas e estratégias adotadas; e a biblioteca de componentes que serão estendidos para padronização dos componentes. Na etapa de Sanity Checking, o foco está em demonstrar que o ambiente funciona adequadamente e já pode ser refinado na etapa de Interface Refinement que especializa as interfaces TLM em interfaces baseadas em sinais. Uma vez feita as che- cagens e refinamentos, o ambiente é validado por completo na etapa de Environment Validatione finalmente recebe o sistema que será verificado na etapa de DUV Execution. Nas seções a seguir, maiores detalhes sobre cada uma destas etapas serão fornecidos.

4.2.1

Sanity Checking

O objetivo principal desta etapa é garantir que o ambiente possui capacidades mí- nimas de funcionamento, como a capacidade de comunicação e detecção de erros. Para

avaliar a sanidade é desejável que um subconjunto mínimo de componentes sejam ins- tanciados, de forma a reduzir a quantidade de variáveis que serão analisadas. Desta forma, apenas os seguintes componentes devem ser utilizados nesta etapa: Test Case Model, Reference Model e Agent, como pode ser visto na figura 4.4.

Figura 4.4: Etapa de checagem de sanidade

Esta é, sem dúvida, a mais importante das etapas, pelo fato de servir como base para as próximas etapas que somente irão refinar o comportamento do ambiente. Este refinamento ocorrerá através da criação de unidades de comunicação baseadas em si- nais, que permitirão que interfaces TLM sejam traduzidas em sinais, além da adição de módulos de análise de cobertura e de protocolo que irão certificar que estes sinais estão sendo devidamente modificados.

Durante a execução desta etapa, os casos de teste, seus agentes e o modelo de refe- rência devem ser implementados de maneira iterativa e incremental, permitindo que a cada pequeno passo realizado, a corretude seja sempre verificada, evitando a depura- ção de todo o ambiente no final da implementação.

4.2.2

Interface Refinement

Quando um conjunto de funcionalidades já teve sua sanidade devidamente che- cada é a hora de refinar as interfaces de comunicação baseadas em transação (TLM) para interfaces baseadas em sinais, com seus respectivos analisadores de protocolo e cobertura. Neste processo novos componentes, como Driver e Monitor são inseridos, e isto é ilustrado nas figuras 4.5 e 4.6.

Figura 4.5: Refinando interface da esquerda

Figura 4.6: Refinando interface da direita

Os componentes Driver e o Monitor respondem, respectivamente, pela tradução de requisições TLM para estímulos baseados em sinais e vice versa e pela análise de con- formidade de protocolo, além da coleta de dados de cobertura. No final desta etapa, regras de cobertura são adicionadas no Monitor, permitindo que análises mais sofisti- cadas sobre a qualidade dos casos de teste sejam realizadas.