Automatizando casos de teste C para verificação de sistema embarcado

À medida que os designs de sistema em chip (SoC) avançam em sua marcha para uma maior complexidade, os conjuntos de testes contendo milhares de linhas de código para verificação no nível do sistema continuam a ser escritos à mão, uma prática estranhamente antiquada e ineficaz que desafia o ditado "automatizar quando possível." Isso é especialmente verdadeiro para testes C que são executados em processadores incorporados de um SoC para verificar todo o dispositivo antes da fabricação.

Demonstrou-se que a automação da composição do teste de verificação, quando possível, aumenta a produtividade em muitas fases do desenvolvimento de SoC. As técnicas de Random Random, por exemplo, em um testbench de Metodologia de Verificação Universal (UVM), fazem uso de vetores de teste randomizados direcionados a cenários específicos para aumentar a cobertura. Embora tenham aumentado a eficiência da verificação no nível do bloco de hardware, o design ainda é percebido como uma caixa preta com estímulos, verificações e código de cobertura escritos separadamente, ainda uma tarefa onerosa e sujeita a erros para blocos grandes.

É difícil estender essa metodologia para o nível de sistema, dada a necessidade de combinar o código de teste do processador com transações de I / O, muitas vezes executadas em um emulador ou sistema de prototipagem. Para verificar adequadamente um SoC, os próprios processadores devem ser exercitados. UVM e outras abordagens aleatórias restritas não levam em consideração o código em execução nos processadores. Na verdade, para usar o UVM em um SoC, os processadores são frequentemente removidos e substituídos por entradas e saídas virtuais no barramento SoC, permitindo que o subsistema sem o processador seja verificado.

Os engenheiros de verificação de SoC reconhecem as limitações dos bancos de teste aleatórios restritos, levando-os a criar testes C manuscritos para serem executados nos processadores para simulação e emulação de hardware, embora sejam limitados em exercitar totalmente o design do SoC. O desempenho dessas plataformas de verificação não é bom o suficiente para executar um sistema operacional (SO) completo, portanto, esses testes executam "bare-metal", o que adiciona uma sobrecarga significativa ao esforço de composição. É incomum que testes escritos à mão, especialmente sem o auxílio de serviços do sistema operacional, sejam executados de forma coordenada em processadores com vários núcleos, aproveitando vários threads. O resultado é que os aspectos do comportamento do SoC, como operações simultâneas e coerência, são verificados minimamente.

Gerando testes C automaticamente

Obviamente, os testes C gerados automaticamente farão um uso mais eficiente dos recursos de engenharia. Eles também aumentam a cobertura. Os casos de teste C gerados podem exercitar mais a funcionalidade do SoC do que testes escritos à mão e buscarão casos de canto complexos difíceis de imaginar. Casos de teste multiencadeados e multiprocessadores podem exercitar todos os caminhos paralelos dentro do projeto para verificar a simultaneidade. Eles podem mover dados entre segmentos de memória para algoritmos de coerência de estresse e coordenar com as transações de I / O quando os dados devem ser enviados para as entradas do chip ou lidos de suas saídas. O efeito geral disso é aumentar a cobertura funcional do sistema, normalmente maior que 90% de números que são caracteristicamente muito mais baixos.

O software de geração de teste, conhecido como Test Suite Synthesis, usa um modelo de cenário baseado em gráfico fácil de entender que captura o comportamento de projeto pretendido. Esses modelos podem ser escritos usando o padrão de estímulo portátil Accellera usando C ++ nativo ou descritos visualmente. Os modelos de cenário são criados por engenheiros de projeto ou verificação como uma parte natural do desenvolvimento do SoC, uma vez que se assemelham a diagramas de fluxo de dados de chip tradicionais que podem ser desenhados em um quadro branco para explicar parte da especificação do projeto.

Esses modelos inerentemente incluem estímulos, verificações, detalhes de cobertura e informações de depuração, fornecendo ao gerador tudo o que ele precisa para produzir casos de teste C de autoverificação de alta qualidade que enfatizam todos os aspectos do projeto. Por serem hierárquicos e modulares, quaisquer testes desenvolvidos no nível do bloco podem ser reutilizados inteiramente como parte do modelo SoC completo e facilmente compartilhados com diferentes equipes e entre projetos. Finalmente, o modelo único de intenção pode ser decomposto pela ferramenta de síntese para fornecer os testes simultâneos entre threads e portas de E / S, todos sincronizados juntos.

Síntese do conjunto de testes de vantagens

Uma vantagem significativa da síntese do conjunto de testes é a capacidade de definir objetivos de cobertura antecipadamente no modelo de intenção. Uma vez que a intenção foi especificada, a ferramenta pode analisá-la para entender o número de testes que poderiam ser produzidos e a cobertura da intenção funcional que seria alcançada.

Para um SoC, isso pode envolver muitos milhares de testes. As metas de cobertura podem então ser definidas restringindo a intenção a ser testada e focando a ferramenta em áreas-chave. Esse recurso salva o doloroso loop iterativo que ocorre nas abordagens tradicionais, que é configurar os testes, executar a ferramenta de verificação, entender a cobertura alcançada e, em seguida, redefinir os testes repetidamente.

Em um projeto típico em um grande SoC desenvolvido por uma conhecida empresa de semicondutores, os engenheiros de verificação reduziram o tempo de composição do teste para 20% do que antes exigia testes manuscritos. A tecnologia de automação produziu casos de teste mais rigorosos, aumentando a cobertura de 84% para 97%. Além disso, os modelos são portáteis.

Um único modelo pode gerar casos de teste para plataformas virtuais, simulação de nível de transferência de registro (RTL), emulação, protótipos de field programmable gate array (FPGA) ou um chip real no laboratório passando por validação pós-silício.

Depurar é outra perda de tempo para engenheiros, especialmente no nível de SoC. Se um caso de teste descobrir um bug de design oculto, o engenheiro de verificação deve entender qual teste disparou o bug para rastrear sua fonte. Uma falha de caso de teste pode ser devido a um erro no modelo de cenário, portanto, deve ser possível correlacionar o caso de teste de volta ao gráfico onde a intenção do projeto foi capturada. Este processo cria testes altamente modulares e autocontidos que são facilmente decompostos, de forma que o teste executado até o bug descoberto seja fácil de ver.

Cenários de aplicação

Os casos de teste sintetizados podem exercitar casos de uso realistas, chamados de cenários de aplicativo, para o design. Por exemplo, considere o SoC da câmera digital mostrado na figura 1.

clique para ampliar a imagem

Figura 1:Exemplo de SoC de processamento de imagem. (Fonte:Breker Verification Systems)

Os componentes de nível de bloco SoC incluem dois processadores, os dispositivos periféricos e a memória. Um gráfico simples para o SoC é mostrado abaixo do diagrama de blocos. O gráfico inclui os possíveis caminhos de alto nível que podem ser exercidos no processo de verificação do SoC. Por exemplo, um cenário possível, expresso no caminho superior do gráfico, lê uma imagem JPEG do cartão SD e a passa para o processador de fotos por meio de uma região alocada na memória. A imagem é processada em uma forma que pode ser exibida e carregada em um segundo bloco na memória. A partir daí, é passado para o controlador do monitor. Obviamente, cada um desses blocos de alto nível é de natureza hierárquica, com muitas ações e decisões sendo executadas como parte do processo.

A ferramenta de síntese fará o teste aleatório e os agendará de forma adequada. Na forma mais simples, conforme mostrado na figura, o teste pode ser agendado em um único encadeamento, seguido pelo próximo teste e assim por diante. No entanto, a capacidade dos casos de teste de enfatizar o SoC vem da intercalação de aplicativos em vários threads e vários processadores. A ferramenta executará tantos aplicativos em paralelo quantos forem suportados pela simultaneidade inerente do design, alocando memória da maneira mais tortuosa possível. Isso também é mostrado como uma alternativa na figura onde os testes são espalhados por três threads, fazendo uso de várias regiões alocadas nas memórias SoC.

Claro, este exemplo é apresentado em um alto nível para tornar o processo claro. Na realidade, o gráfico hierárquico será achatado pela ferramenta de síntese, criando um grande número de ações e conexões. Isso também incluirá decisões aleatórias, que precisam ser executadas por meio de um algoritmo de solucionador. Conforme o gráfico é percorrido, algoritmos de planejamento de IA são empregados para inspecionar as saídas desejadas e otimizar os testes de entrada para corresponder a isso. A ferramenta de síntese inclui serviços semelhantes aos do sistema operacional que alocam memória, fornecem acesso ao mapa de endereços, interrupções de processo e outras tarefas necessárias para completar as estruturas de teste. Os testes são então programados aleatoriamente com armazenamento e outros recursos alocados apropriadamente.

Conclusão

Assim como os bancos de teste aleatórios restritos eliminaram o trabalho manual para verificação de bloco, o conteúdo de teste sintetizado para SoCs baseados em processador embutido demonstrou reduzir o esforço de verificação no nível do sistema. Além disso, essa solução agora está sendo aplicada em nível de bloco e para validação pós-silício. Neste exemplo, os casos de teste C automatizados aplicam o ditado “automatize sempre que possível”, melhorando drasticamente a cobertura enquanto encurta os cronogramas de verificação.