Diminuindo a duração do ciclo de projeto em SoCs co-projetados com Renode

Neste artigo, explicamos como o uso de simuladores funcionais de código aberto como o Renode da Antmicro pode ser parte integrante dos esforços de co-design de hardware e software .

Neste artigo, explicamos como o uso de simuladores funcionais de código aberto como o Renode da Antmicro pode ser uma parte integrante dos esforços de co-design de hardware e software.

Conforme os mercados exigem mais de seus sistemas embarcados, os SoCs da próxima geração estão se tornando mais complexos, levando a ciclos de design mais longos e custos crescentes, de acordo com a Semico Research.

A realidade frustrante para os fabricantes de dispositivos é que a única maneira de fornecer os recursos novos e inovadores, maior segurança e melhor desempenho que seus clientes estão pedindo é se envolver em co-design de "pilha inteira", hardware em evolução, firmware, tempo de execução (SO) e conjunto de ferramentas de desenvolvimento em conjunto. Isso permite que as equipes de hardware e software tratem de compensações complexas em torno de onde na pilha implementar funcionalidades e otimizações.

Infelizmente, o co-projeto costuma ser o principal motivador do alongamento dos ciclos de projeto - e, portanto, dos custos - quando as ferramentas de simulação adequadas não estão disponíveis.

Neste artigo, explicamos como o uso de simuladores funcionais de código aberto como o Renode da Antmicro pode ser uma parte integrante dos esforços de co-design de hardware e software. Além disso, mostraremos a você um exemplo de como os usuários Renode são capazes de alavancar a ferramenta para reduzir drasticamente a duração de seus ciclos de design, fornecer um meio simples e eficaz para os clientes avaliarem suas soluções e começarem a adaptar o material de apoio do software em paralelo com esforços de integração de hardware.

Onde os simuladores de software podem falhar

A importância de escolher a ferramenta de simulação certa é melhor ilustrada no caso da Dover Microsystems.

A tecnologia CoreGuard® da Dover é a única solução que impede a exploração de vulnerabilidades de software e permite que os processadores se defendam contra ataques baseados em rede. A Dover conseguiu isso por meio de oito anos de pesquisa e desenvolvimento - primeiro como o maior executor no DARPA Crash Program e depois na Draper Labs - que resultou em uma solução híbrida de hardware / software exclusiva para sistemas embarcados.

Esta solução híbrida requer forte integração entre os componentes de hardware e software. O CoreGuard silicon IP é um processador sentinela que atua como guarda-costas, protegendo os sistemas embarcados de ataques cibernéticos. Ele monitora cada instrução executada pelo processador host para garantir que ela esteja em conformidade com um conjunto definido de regras de segurança, proteção e privacidade chamadas micropolíticas - o componente de software do CoreGuard. Se uma instrução violar uma regra existente, o CoreGuard interrompe sua execução antes que qualquer dano possa ser feito.

Para fazer isso, o CoreGuard precisa acompanhar a execução do processador host. Ou seja, em média, ele deve ser capaz de retirar (aprovar por meio de micropolíticas) instruções na mesma taxa que o processador host que está sendo protegido. Também é desejável que o CoreGuard minimize a quantidade de memória necessária para o gerenciamento de metadados.

Portanto, atender às demandas de desempenho, potência e área requer uma interação complexa de otimizações das camadas de hardware e software.

A equipe de hardware da Dover usa um processo e uma cadeia de ferramentas padrão com base em SystemVerilog. Os protótipos iniciais do sistema CoreGuard são construídos em SoCs baseados em RISC-V. Como o CoreGuard tem um componente de software substancial além do IP de hardware, era importante que a equipe de software pudesse começar bem antes de qualquer protótipo de hardware estar disponível.

A equipe de software da Dover inicialmente usou o simulador de software Spike RISC-V ISA que está disponível nos repositórios RISC-V GitHub. Eles encontraram dois problemas baseando seu desenvolvimento comercial do CoreGuard em torno do Spike:

1. Spike não fornece nenhum periférico realista; ou seja, o Spike é um simulador ISA, não um simulador SoC. A equipe da Dover começou a adicionar periféricos como UARTs e armazenamento persistente ao Spike, e isso deu muito trabalho.
2. Spike, por definição, é específico para RISC-V, mas os clientes iniciais da Dover Microsystems são RISC-V e baseados em Arm.

Essas deficiências destacaram a necessidade da Dover de um simulador de arquitetura múltipla flexível com o conceito de modelos periféricos a serem usados ​​no lugar de Spike.

Como o Renode atende às necessidades importantes de co-design

Enfrentando desafios de engenharia de co-design de hardware / software heterogêneos semelhantes decorrentes do trabalho com softcores de código aberto, software inicial para plataformas de computação de ponta, FPGA SoCs e arquiteturas de CPU emergentes, como RISC-V, Antmicro - um software voltado para o código aberto provedor de tecnologia e serviços - desenvolveu uma estrutura de simulação flexível chamada Renode.

Renode é uma estrutura de simulação modular e hierárquica destinada a executar firmware de produção real (ou seja, não modificado) em uma variedade de sistemas complexos, incluindo sistemas multi-nós interconectados, multi-arquiteturas, heterogêneos, em nível de MCU e com capacidade para Linux.

Para lidar com esses vários níveis de complexidade, Renode é construído em torno de uma forte noção de abstração e adota uma abordagem modular orientada a objetos para simulação de sistema. Núcleos e periféricos são vistos como blocos de construção que podem ser conectados por meio de interfaces em diferentes configurações, refletindo como os SoCs reais são construídos.

Figura 1. Um exemplo de um SoC RISC-V simulado.

A Figura 1 mostra um exemplo de um SoC RISC-V simulado. Cada bloco de construção, incluindo a CPU, tem um conjunto de propriedades e APIs que podem ser usados ​​para construir o modelo de simulação de todo o SoC. Da mesma forma, nós únicos podem ser combinados em um sistema de vários nós usando conexões virtualizadas sem fio e com fio (6LoWPAN, UART, Ethernet etc). Tudo isso não requer mudanças na base de código do Renode, mas é feito por meio de configuração e script, diminuindo a curva de aprendizado e limitando a fragmentação da base de código.

A natureza flexível do framework Renode, sua disponibilidade de código aberto e a existência de suporte comercial fornecido por seus autores tornaram mais fácil para a Dover construir primeiro um protótipo de implementação de seu fluxo de trabalho desejado e, em seguida, contratar a Antmicro para implementar (e lançar no mercado aberto domínio de origem) funcionalidades que tornaram o Renode ainda mais adequado para seu caso de uso, como a execução por instrução.

Em particular, usando Renode, os engenheiros da Dover agora são capazes de:

• Alterne entre os esforços de integração baseados em Arm e RISC-V usando a mesma configuração.
• SoC de protótipo (tanto de referência / mínimo e definido pelo cliente) em diferentes níveis de detalhe / fidelidade.

Modele a especificação da arquitetura de hardware do grupo de hardware da Dover e, em seguida, escreva e teste o firmware em relação a esses modelos, enquanto o hardware está em desenvolvimento.

Como a Renode diminuiu significativamente o ciclo de design da Dover

A tecnologia CoreGuard da Dover é um produto híbrido de cibersegurança em que os designs de hardware e software estão evoluindo. Como resultado, é importante que o processo de desenvolvimento da Dover permita o desenvolvimento e teste paralelos de hardware e software.

Figura 2. O processo de desenvolvimento usado pela Dover.

Dover está usando o processo de desenvolvimento descrito na Figura 2. As equipes de hardware e software colaboram na interface de hardware (que, é claro, continuará a evoluir). Conforme a equipe de hardware começa a implementar blocos em SystemVerilog, a equipe de software cria modelos dos novos blocos em C #, a linguagem nativa subjacente ao Renode. A equipe de software é então capaz de escrever firmware que se comunica com as novas interfaces de hardware e testar esse software na simulação Renode. Eventualmente, o software é executado em um emulador FPGA.

Este processo de desenvolvimento, possibilitado pela Renode, ajudou a Dover a otimizar as simulações de “baixa fidelidade” e “alta fidelidade”.

Embora essa simulação de "baixa fidelidade" abstraia toda a lógica de hardware do CoreGuard, Dover ainda acha essa configuração útil nos seguintes contextos:

• Depuração de micropolítica: Quando novas micropolíticas CoreGuard estão sendo desenvolvidas, queremos iterar rapidamente em uma variedade de testes de software, para verificar o comportamento.
• Demonstrações e visualizações do cliente: Para demonstrações do CoreGuard, a simulação pura de software é muitas vezes suficiente para educar um cliente potencial sobre os recursos do CoreGuard® e para estimular o interesse em discussões futuras. Além disso, a Dover geralmente entrega um "SDK" aos clientes que consiste neste simulador de "baixa fidelidade" com algumas micropolíticas predefinidas, para que o cliente "brinque" com o CoreGuard, incluindo a possibilidade de executar micropolíticas CoreGuard contra o software do cliente.

Em simulações de "alta fidelidade", que replicam um modelo de hardware mais preciso, a equipe de engenharia da Dover foi capaz de reconhecer uma série de benefícios com Renode, incluindo:

• Integração com vários formatos binários não ELF (por exemplo, scatter-load) usados ​​por ROMs de inicialização de hardware.
• Desenvolvendo e testando o processo de boot; copiando do flash para a RAM, inicializando dispositivos.
• Depuração de tráfego de ônibus usando instrumentação Renode.
• Periféricos de depuração (UARTs, PICs, a própria interface CoreGuard) por instrumentação.
• Brincando com o mapa da memória.
• Implementar firmware de vídeo HDMI, antes que o hardware funcionasse.

Conforme indicado anteriormente, existem alguns desafios de desempenho e restrições de área que as soluções de próxima geração, como o CoreGuard, colocam nas equipes de design de SoC durante a implementação.

Para aumentar o desempenho e reduzir o uso de memória, há uma ampla gama de otimizações que precisam ser feitas, que frequentemente ultrapassam os limites de hardware / software.

É fundamental que as equipes de design sejam capazes de explorar uma grande variedade de possíveis técnicas de co-otimização de hardware / software e compensações, sem um grande e serializado "primeiro processo de desenvolvimento de hardware e depois software". Um simulador funcional de software flexível, como o Renode, permite que os engenheiros da Dover colaborem na divisão hardware-software para encontrar compensações ideais entre a complexidade do hardware e do software, tornando-o parte integrante de seus esforços.

Para saber mais sobre como Renode pode agilizar projetos de co-design, visite renode.io. Para saber mais sobre como o CoreGuard pode proteger os sistemas embarcados de ataques baseados em rede, solicite uma demonstração para ver o CoreGuard em ação.

Este artigo foi coautor de Michael Gielda, VP de Desenvolvimento de Negócios e cofundador da Antmicro.

Artigos do setor são uma forma de conteúdo que permite aos parceiros do setor compartilhar notícias, mensagens e tecnologia úteis com os leitores do All About Circuits de uma forma que o conteúdo editorial não é adequado. Todos os artigos da indústria estão sujeitos a diretrizes editoriais rígidas com a intenção de oferecer aos leitores notícias úteis, conhecimentos técnicos ou histórias. Os pontos de vista e opiniões expressos nos Artigos da Indústria são do parceiro e não necessariamente da All About Circuits ou de seus redatores.