Do ponto de vista da verificação e validação funcional, para verificar a implementação de projeto é necessário verificar o seu comportamento, isto é, portas de entrada e saída. Se uma propriedade de um dispositivo não pode ser verificada por meio de suas portas, em seguida, que a propriedade é ou não controlável, ou seja, não pode ser ativado; ou não está sendo observada. Esta abordagem de validação é chamada de validação de caixa preta, cuja abordagem de validação foi utilizada [21].
Como estratégia de verificação com abordagem em caixa preta, parte dos IP’s foram implementados e uma outra parte foi utilizada de terceiros, a fim de verificar o quanto é importante evidenciar em uma fase de projeto, do ponto de vista da segurança de hardware, mostrando a necessidade de diferenciação entre os projetistas que projetam dos que fazem testes de funcionalidade do circuito.
Para a estratégia de verificação e validação dos dados, com abordagem em caixa– preta, deve-se garantir que o sistema funcione, conforme especificação técnica do IP, conferindo se os dados checados e analisados realmente funcionam de forma correta, garantindo de forma segura o funcionamento do projeto.
6.8.1 Fluxo de Validação Funcional do Circuito
Toda a atividade de projeto começa a partir da especificação dele. A tarefa de uma equipe de projeto é criar uma implementação de hardware através de sua interpretação da especificação do projeto. A especificação é compreendida pelo projetista, que inicia a imple- mentação através de uma série de etapas, nas quais ferramentas de automação de projeto a- propriadas são usadas para passar de um nível de abstração para o próximo em cada passo. Por exemplo, em um fluxo de projeto ASIC inicia-se em nível RT (Register Transfer), a im- plementação inicial RTL (Register Transfer Language) é criada pela equipe de projeto da especificação do projeto. A implementação RTL é então sintetizada num nível estrutural de portas lógicas netlist. Este netlist é então processado através de estágios de projeto físicos, a fim de preparar a informação final para a máscara que será utilizada na fabricação de semi- condutores [27][5].
O passo mais trabalhoso e propenso ao erro no fluxo de projeto é a tradução manual da especificação do projeto para a implementação do projeto inicial. De um modo geral, outras tarefas de projeto são menos propensas a erros de funcionamento por causa do alto grau de automação envolvidos na execução das etapas posteriores.
O principal objetivo da validação funcional é verificar que a implementação inicial do projeto é funcionalmente equivalente à especificação de concepção. Neste caso, este projeto obteve sucesso com seus objetivos constituindo um arcabouço com base na metodologia eRM, eReuse Metodology. Este arcabouço corresponde a um conjunto de componentes de validação de dados, tempo e registros, comparando os resultados obtidos no projeto do controlador digital versus os resultados obtidos no ambiente de teste[19].
As metodologias de validação, bem como os componentes reutilizáveis, são con- ceitos abstratos que levam a melhorias de produtividade de validação, enquanto novas lingua- gens de validação de hardware estão permitindo um novo conceito e o surgimento de novas tecnologias [21]. O fluxo de projeto típico e suas tarefas de concepção e validação associadas são mostrados na figura 37.
Figura 37 - Fluxo de Projeto ASIC [21]
As principais razões para erros funcionais em um projeto são [21]: Ambiguidades na especificação do projeto;
Compreensão errada da especificação, mesmo quando a especificação é clara; Erros de implementação, mesmo quando o objetivo da implementação é claro; O principal objetivo da validação funcional é verificar se a implementação inicial do projeto é funcionalmente equivalente à especificação de concepção.
6.8.2 Testes de Caixa Branca e Caixa Preta
Na figura 38, é mostrada a arquitetura de validação para a validação de caixa preta. Nota-se que, nesta abordagem, é requerido um modelo de referência para verificar que a resposta gerada por um dispositivo é, de fato, a resposta esperada [21].
Figura 38 – Validação de Caixa Preta [21]
As características que proporcionam uma vantagem de implementação no projeto podem ser o desempenho, porém não são visíveis através das portas dos dispositivos. Por exemplo, num ambiente de validação de instruções precisas de uma CPU, com um pipeline, funcionalmente parecem se comportar do mesmo modo que uma CPU sem um pipeline. Para verificar o correto funcionamento deste pipeline, é necessário examinar o projeto e monitorar o comportamento do pipeline e verificar se ele está proporcionando melhoria de desempenho da CPU. Portanto, mesmo que seja possível criar um modelo de referência, é preciso verificar se há tais comportamentos internos através das portas dos dispositivos, o esforço associado com a construção de um modelo preciso faria a validação como caixa preta impraticável na maioria dos casos [21].
Mesmo nos casos em que um recurso específico pode ser verificado através de portas de dispositivo, a diferença entre o momento em que a falha é ativada e o tempo que a falha é observada faria qualquer análise de causalidade difícil de controlar. Para melhorar a busca pelas falhas, há necessidade da implementação de componentes, a fim de monitorar as propriedades internas, com potencial para se tornarem fontes de mau funcionamento do dispositivo. Os testes de caixa branca e caixa cinza possuem abordagens de validação alternativa que superam as limitações de validação de caixa preta. A validação de caixa branca, figura 39, refere-se a verificar um projeto através da checagem (checkers de declaração e monitores), sem usar um modelo de referência. A validação de caixa cinza, figura 40, refere-se a verificar um projeto usando um modelo de referência, mas utilizando verificadores (afirmações, checkers e monitores) para melhorar a produtividade de validação [21].
Figura 39 – Validação de Caixa Cinza [21]
Figura 40 – Validação de Caixa Branca [21]
Validação caixa branca é normalmente utilizada para módulos menores nos estágios iniciais de projeto. Esta abordagem de validação é difícil de reutilizar e de gerenciar. Em outra via, testes de caixa preta são fáceis de reutilizar como projeto de validação modificando de nível de módulo para nível do sistema. No entanto, o tempo de latência para a detecção de erros tem potencial para falhas críticas de erro interno de estado e, a necessidade de construir um modelo de referência detalhado, faz da validação de caixa preta difícil de utilização na prática. O teste de caixa cinza permite que o engenheiro de validação encontre o equilíbrio certo entre propriedade de validação do projeto e construção de um modelo de referência. Portanto, validação de caixa cinza é a abordagem que fornece o maior benefício em todo o fluxo de validação [4] [18].