Verificação de CPU suave


18

Atualmente, estou no processo de projetar uma CPU simples em VHDL usando o Xilinx ISE e ISIM. A parte do design está indo notavelmente bem, mas não consigo descobrir uma maneira de fazer a verificação de maneira consistente.

No momento, tenho uma bancada de testes VHDL que atualizo para testar a função em que estou trabalhando a qualquer momento específico. Isso é muito ad-hoc e não ajuda a capturar regressões e não pode ser usado para verificar a conformidade com o conjunto de especificações / instruções.

Pensei em desenvolver um amplo conjunto de testes, mas o problema é que o estado potencial de uma parte de uso geral como CPU é enorme em comparação a componentes menos genéricos.

Estou procurando um método que me permita executar o projeto e os testes de uma maneira mais controlada. Algum tipo de "TDD de hardware", se você preferir. Será que tal coisa existe? Pode ser aplicado com relativa facilidade a peças de uso geral, como uma CPU?

Respostas:


16

Toda a questão da verificação da CPU é super grande e difícil. Há pessoas que fazem carreira justamente com isso. Vou apenas dar uma visão geral ...

  1. Escreva um programa em linguagem assembly que teste todas as instruções e todos os pequenos detalhes de cada instrução. Por exemplo, ao testar a instrução ADD, você pode testá-la com números positivos, negativos e um de cada (duas vezes). Você testaria o sinalizador de transporte, o sinalizador zero, etc. Outros recursos especiais da CPU (como previsão de ramificação, etc.) teriam sua própria parte especial deste teste.

  2. Escreva, usando C / C ++ ou algo assim, um modelo de sua CPU. Esta é sua CPU virtual. Essa também é sua "CPU dourada", o que significa que essa é a CPU com a qual tudo o resto é comparado. Idealmente, a pessoa que escreveu o VHDL NÃO é a mesma pessoa que escreve o modelo C / C ++.

  3. Escreva / Crie um sistema no qual você possa executar o modelo C / C ++ e o modelo VHDL lado a lado e comparar os resultados ciclo a ciclo. Execute seu programa de montagem a partir da Etapa 1 e verifique se os dois modelos correspondem.

  4. Execute seus dois modelos em "instruções" aleatórias. Basicamente, preencha "ram" com dados aleatórios e execute esses dados aleatórios como se fossem instruções reais. Execute os mesmos dados aleatórios nos modelos VHDL e C / C ++ e compare os resultados. Esse modelo C / C ++ seria executado em alguma estação de trabalho e / ou servidor (não na nova CPU).

  5. Configure uma máquina ou várias máquinas para repetir a etapa 4 essencialmente para sempre. Mesmo se sua CPU estiver "concluída" e estiver em produção há um ano ou mais, você ainda estará executando este teste.

  6. Repita essas etapas sempre que houver mais coisas para simular. Por exemplo, você o executaria no VHDL pós-rota com tempo quando estiver disponível.

Não há garantia de que a comparação das versões VHDL e C / C ++ consiga detectar todos os erros - mas não há realmente uma maneira melhor. E testar a CPU em instruções aleatórias leva tempo, mas isso também é muito útil. A única alternativa real é contratar muitas pessoas para escrever código o dia todo para testar diferentes partes da CPU - e as empresas maiores fazem isso, mas também fazem dados aleatórios.

Para uma única pessoa escrevendo código VHDL, geralmente é apenas o passo 1 que está pronto. Mas se você pretende vender a CPU, pelo menos algumas das outras etapas devem ser feitas (e realmente, você deve executá-las todas).


Excelente resposta, obrigado! Isso faz muitosentido. O "CPU dourado" é realmente a peça que falta no quebra-cabeça que permite que você faça a verificação ciclo a ciclo durante o teste. Como esse é principalmente um projeto de brinquedo, acho que vou me conformar com a primeira frase do último parágrafo e fazer o primeiro passo. Mas saber o que eu deveria estar fazendo é inestimável.
Drxzcl

Você também pode ter um modelo C ++ dourado, mas sem precisão de ciclo, que permite que seja muito mais simples e, portanto, com maior probabilidade de estar correto - útil para testar a funcionalidade da ALU, por exemplo ("2 + 2 = 4 e alguns sinalizadores, I não me importo quando "ao invés de" 2 + 2 = 4 após um tick e as bandeiras após 2 ticks))
Martin Thompson

Além disso, de cobertura de código executado (para verificar se você exercido tudo) e test-cobertura (para verificar todos os testes tenham sido testados para ambos os pas e falha)
Martin Thompson

Acompanhamento: Usando o procedimento "etapa um", eu consegui encontrar muitas falhas ... no meu assembler: P O núcleo em si parece relativamente bom.
drxzcl
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.