Otimizando o desenvolvimento de software pré-silício

Na era da tecnologia em rápida evolução de hoje, a abordagem mais comum para lidar com as necessidades do mercado é um sistema em chip (SoC). Um SoC é basicamente um processador cercado por aceleradores de função e muitos I / O para os periféricos associados que ele suporta. Desde a revolução dos dados móveis em 2002, tornou-se um pré-requisito usar SoCs para facilitar os principais recursos que definem um smartphone. Da mesma forma, os SoCs se tornaram o dispositivo indispensável para a criação de produtos de consumo “inteligentes”, como TVs, carros e o mercado de Internet das Coisas (IoT) em constante expansão.

A crescente demanda por SoCs criou um mercado altamente competitivo. Por causa disso, os SoCs estão ficando mais complexos, os periféricos nos SoCs estão em constante evolução e o tempo de lançamento no mercado está diminuindo. Um componente crucial para corresponder às complexidades do desenvolvimento de SoC é a disponibilidade de software. Há pouco espaço para erros e o software deve estar pronto o mais rápido possível. Para enfrentar esse desafio, o desenvolvimento de software deve ser iniciado antes da disponibilidade da parte SoC.

Desenvolvimento de software SoC

Tradicionalmente, o desenvolvimento de software começaria depois que a primeira amostra de silício chegasse da fabricação. Quando as amostras de SoC chegavam, as equipes de software e validação começavam suas atividades de desenvolvimento e um grande esforço de apresentação de SoC era iniciado. As equipes que trabalham no SoC convergiriam de todo o mundo para ficar sob o mesmo teto por um período limitado de tempo para apoiar a criação do SoC.

O desenvolvimento de software geralmente levava meses após a chegada da primeira amostra antes de estar pronta para produção. Enquanto isso, a validação do silício seria concluída, o que daria uma quantidade limitada de confiança para iniciar a produção em massa dos produtos associados.

Devido à complexidade crescente no design do SoC, no entanto, o que normalmente levaria meses de desenvolvimento de software pode agora se estender por anos antes que o software estivesse pronto para produção. O número crescente de periféricos com suporte e a evolução desses periféricos também criaram lacunas na experiência no assunto. As equipes de software seriam obrigadas a preencher essas lacunas específicas, contratando novos desenvolvedores com experiência nesses domínios (áudio, vídeo, USB, Ethernet, etc.).

Para ser capaz de entregar software pronto para produção no início do projeto, o desenvolvimento de software não pode esperar até que a primeira amostra de silício esteja disponível. Uma abordagem de mudança para a esquerda precisa ser adotada onde o desenvolvimento de software começa o mais cedo possível e, ainda melhor, ao mesmo tempo que o design de hardware SoC começa. O desenvolvimento de software pré-silício também pode ajudar a identificar bugs de implementação de SoC e potencialmente reduzir o custo de fixação de metal ou fita adesiva de máscara completa. Diversas metodologias são consideradas para atender a esses requisitos.

Abordagens de desenvolvimento de pré-silício

Para iniciar o desenvolvimento de software antes da fita de SoC, os desenvolvedores podem usar algumas abordagens, como prototipagem de software, testbench RTL, placas FPGA, emuladores de hardware, etc. Uma vez que essas abordagens geralmente se concentram em módulos individuais, cada uma dessas abordagens tem seus próprios desafios, pois o objetivo é desenvolver software para trazer todo o SOC, em vez de módulos individuais. Se dividirmos o problema em módulos menores, a primeira coisa necessária antes que o desenvolvimento do driver possa começar é o conhecimento de cada processador, acelerador ou periférico em desenvolvimento.

Modelos System C

Modelos comportamentais C podem ser construídos para cada IP do SoC, e drivers de software independentes podem ser testados nesses modelos comportamentais. Mas essa abordagem tem alguns problemas. Primeiro, é necessário um grande esforço de software, o que significa que uma grande equipe de software ou uma equipe de modelo dedicada é necessária para dar suporte à implementação do próprio modelo. Conseqüentemente, o desenvolvimento de modelos não seria custo-efetivo. Em segundo lugar, a precisão dos modelos comportamentais depende da interpretação do desenvolvedor. Quaisquer lacunas de comunicação entre o proprietário do design de IP e o desenvolvedor do modelo podem resultar em comportamento impreciso. Isso resulta em muito esforço desperdiçado para corrigir problemas associados à interpretação incorreta do design.

RTL testbench

Para resolver esse problema de imprecisão, outra abordagem que pode ser tomada é usar um testbench Verilog. O testbench é normalmente desenvolvido e mantido pela equipe de design do SoC para verificação. O testbench do Verilog é baseado na especificação da linguagem de transferência de registros (RTL) do SoC, representando o SoC completo, não apenas alguns blocos de IP. Conseqüentemente, é preciso ciclo a ciclo. Conforme o RTL se desenvolve, o testbench se move em sincronia com ele. Isso garante que seja a representação mais atualizada e precisa do SoC conforme está em desenvolvimento. Para fins de desenvolvimento de software, o testbench Verilog também pode ser usado para desenvolver drivers de software.

O software desenvolvido usando este método é preciso e pode ajudar a reduzir o tempo de preparação do software quando as amostras de SoC chegam após o processo de fabricação. Mas há um problema com essa abordagem. Como o testbench da Verilog tem um ciclo preciso, ele é muito lento. O desenvolvimento de software em tal ambiente é possível, mas será extremamente lento para desenvolver e depurar. Pode levar meses para desenvolver um driver com esta metodologia. O testbench do Verilog pode ser usado iniciando muito mais cedo - essencialmente aumentando a quantidade de tempo necessária no pré-silício para compensar a velocidade lenta da solução (mas depende da disponibilidade do testbench). Em uma abordagem alternativa, outra equipe de software pode usar esta metodologia (trabalhando apenas no desenvolvimento de pré-silício) - essencialmente aumentando o número de recursos necessários, não eliminando, assim, esse problema semelhante ao problema com o método do modelo C comportamental.

Na prática, não podemos aceitar ciclos de desenvolvimento longos ou imprecisos, nem podemos aceitar os custos adicionais necessários para duplicar ou aumentar o número de recursos para manter um cronograma de ciclo de design normal. Consequentemente, temos que considerar outra abordagem para o desenvolvimento de software pré-silício. Esta abordagem envolveria a emulação de cada bloco SoC IP em um field-programmable gate array (FPGA).

Protótipos FPGA

Os FPGAs modernos são bastante rápidos e, como os FPGAs são construídos a partir de RTL, são precisos ciclo a ciclo. Com o aumento da complexidade do projeto, os blocos IP têm muito mais portas do que anos atrás. Anos atrás, os FPGAs eram limitados pelo número de portas ASIC, o que significava que não era possível encaixar blocos lógicos maiores em um único FPGA. Agora é possível construir um FPGA para cada bloco e desenvolver um driver rápido e preciso.

Essa metodologia é mais rápida e não exige que as equipes de software reservem seu tempo antecipadamente. Como funciona com cada bloco de IP separado, em vez de todo o design de SoC integrado, essa abordagem limita o software de fazer um desenvolvimento completo no nível de SoC. Ele omite detalhes de integração de como vários blocos de IP funcionam juntos. Conseqüentemente, embora esse método reduza o esforço de apresentação, ainda existem lacunas, uma vez que ele perde os detalhes de integração do SoC pertinentes. Este método pode ser uma abordagem aceitável para SoCs derivados, que têm um número limitado de mudanças, mas não têm a cobertura total desejada necessária para o desenvolvimento de software SoC.

clique para ampliar a imagem

Figura. Sinopse de soluções de desenvolvimento de software pré-silício. (Fonte:Nitin Garg)

Emuladores SoC

Para resolver o problema de precisão, velocidade e cobertura, uma abordagem mais robusta pode ser adotada, que é o uso de emuladores SoC. Existem muitos emuladores SoC disponíveis comercialmente, que podem emular SoCs muito grandes e complexos. Os emuladores SoC são baseados em RTL, portanto, são precisos e são 100 vezes mais rápidos do que o testbench do Verilog, tornando-o muito melhor para o desenvolvimento de software. Por serem bastante rápidos, a portabilidade completa do sistema operacional e o desenvolvimento do driver podem ser executados em um período de tempo razoável. Os emuladores SoC podem dimensionar todo o SoC, de forma que o desenvolvimento de software seja mais bem adaptado ao SoC de produção final.

O uso de emuladores SoC para desenvolvimento e design de software pré-silício reduz o tempo e o esforço de preparação do software, pois pode eliminar ou reduzir as lacunas gerais de desenvolvimento. O software também pode ser depurado usando ferramentas JTAG padrão em um emulador SoC. Os emuladores podem ser usados ​​para várias tarefas, como desenvolvimento e verificação de ROM, desenvolvimento de firmware e sistema operacional e verificação de nível de IP ou SoC. Outro recurso interessante dos emuladores SoC é que eles podem fazer a interface do SoC com componentes reais, como aqueles apresentados em uma placa de desenvolvimento. Por exemplo, é possível conectar um dispositivo NAND real ou virtual ao SoC em um emulador e desenvolver ROM, drivers de sistema operacional e semelhantes.

Os emuladores SoC oferecem muito mais possibilidades do que outras abordagens de desenvolvimento de software. Os emuladores podem fazer a interface do SoC simultaneamente com UART, I2C, vários monitores, dispositivos de armazenamento, dispositivos PCIe, dispositivos de conectividade como Ethernet e Wi-Fi e dispositivos de captura como câmeras e sensores. Em outras palavras, os emuladores SoC podem representar uma placa de desenvolvimento real, então é possível trazer uma estrutura completa como o Android e executar um caso de uso completo antes de gravar o SoC. Por exemplo, inicializar o Android e decodificar alguns quadros de vídeo no emulador SOC pode levar algumas horas, mas pode ser muito útil na análise do desempenho do SOC.

Devido à crescente disponibilidade de periféricos em um SoC, a emulação de SoC também é muito útil para benchmarking de desempenho, que pode destacar os pontos fracos do design antes da fita. Essa funcionalidade pode reduzir os riscos ou subseqüentes tapeouts associados a deficiências de desempenho não identificadas no SoC. Os emuladores SoC também possibilitam a interface do SoC com um FPGA de terceiros ou modelo soft se necessário para IP de terceiros.

Depurar um problema após a chegada da amostra SoC também é útil com um emulador, dado o fato de que ele executa o mesmo sistema operacional, drivers e estrutura que o hardware real. Freqüentemente, é necessário replicar os problemas observados no silício para os emuladores, para que possam ser investigados no nível do sinal. Usar o mesmo software entre o emulador e o silício proporciona uma reprodução mais rápida e precisa dos problemas, dando acesso total aos detalhes dentro do chip.

Comparando as diferentes abordagens de desenvolvimento de software SoC, usar emuladores SoC é uma escolha melhor de uma perspectiva de desenvolvimento pré-silício e depuração pós-silício. O custo para as equipes de software rodarem emuladores SoC pode parecer caro. Mas as contribuições que os emuladores SoC fornecem ao disponibilizar o software de produção mais cedo e ajudar a reduzir os riscos e custos podem ser inestimáveis ​​quando se considera o impacto no tempo para atingir as metas de mercado. Outras abordagens de desenvolvimento de software não têm a mesma cobertura, o que é arriscado e pode exigir recursos maiores da equipe de software. Todos os fatores considerados, usar abordagens de desenvolvimento de software diferentes de emuladores SoC pode provar ser muito mais caro em comparação.

Figura 2. Velocidade de execução comparativa de cada solução. (Fonte:Nitin Garg)

De acordo com a lei de Moore, a contagem de transistores dobra a cada dois anos em um circuito integrado (IC) devido ao aumento da funcionalidade do IC. A maioria dos SoCs de 64 bits baseados em ARM hoje tem de 100 a 300 milhões de portas lógicas. Das abordagens atuais de desenvolvimento de software SoC, os emuladores SoC provaram escalar e dar suporte às necessidades das equipes de desenvolvimento de software que enfrentam os desafios associados às crescentes complexidades dos SoCs no mercado competitivo de hoje.

Referências

1. Trimberger, Stephen M. “Three Ages of FPGAs.” PDF de texto completo IEEE Xplore: 2015, ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413.
2. BRUNET, JEAN-MARIE. “Por que os designs modernos de SoC adotam a emulação”. Design de computação incorporada , 5 de setembro de 2018, embedded-computing.com/embedded-computing-design/why-modern-soc-designs-embrace-emulation.
3. “Emulação Soc.” Emulação Soc , 2019, www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation–soc-emulation.
4. “Colocando mais componentes em circuitos integrados.” http://www.cs.utexas.edu/ , 2006, cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.