
Tratará de usar modelos de dispositivos não muito simples, como, por exemplo, SoC (System on Chip) ou placas de circuito impresso com muitos dispositivos integrados a bordo. No desenvolvimento desses próprios dispositivos, duas etapas podem ser distinguidas. O hardware é desenvolvido primeiro. Este é um processo lento - pode demorar um ano ou mais.
Depois que a primeira revisão do dispositivo físico aparece e verificações básicas são realizadas, o dispositivo é transferido para os desenvolvedores de software. A partir deste momento, começa a segunda fase - o desenvolvimento do software para o dispositivo. Podem ser firmware, BIOS, BSP / CSP (Pacote de suporte de placa e CPU) para vários sistemas operacionais, bem como drivers.

Aliás, no desenvolvimento de chips, muitas vezes chamados de "silício", essas fases são denominadas "pré-silício" e "pós-silício" ou simplesmente "silicone".
Em teoria, o desenvolvimento de software é possível antes que um dispositivo físico apareça. No entanto, na prática, poucos o fazem. O desenvolvimento sem a possibilidade de lançamentos intermediários e depuração, e é exatamente para isso que um dispositivo é necessário, é um negócio muito ingrato, encontrei poucos desses masoquistas. Todo mundo está esperando por "hardware", mas, como escrevi acima, aparecerá apenas em um ano.
Além disso, há outro problema com o hardware. A primeira revisão é lançada em uma edição limitada e distribuída uma peça por vez. Simplificando, não há placas e fichas suficientes para todos. Existem filas, conflitos, se trata de agressão. E se você acidentalmente queimar um dispositivo, o que é muito fácil, todo o desenvolvimento é interrompido até que outro dispositivo seja encontrado. Muitas vezes não é encontrado, é necessário produzir um novo e aguardar a entrega. Isso retarda muito o processo.
E então os simuladores ajudam os desenvolvedores de software!
A criação de um modelo de dispositivo virtual começa simultaneamente com o design do dispositivo físico. Mas como a criação e o lançamento de um modelo são muito mais fáceis, os primeiros lançamentos de tais modelos aparecem convencionalmente não em um ano, mas muito antes. Usando esses modelos, os desenvolvedores de software podem iniciar suas tarefas imediatamente, sem esperar pelo "hardware".
Sim, não haverá todas as funcionalidades, mas os programadores nos primeiros estágios não precisam de todas elas. Até que o dispositivo seja feito, as equipes de arquitetos de hardware, modeladores e desenvolvedores de software devem ter planos claros e consistentes que reflitam qual funcionalidade específica deve ser feita em qual estágio. A cada iteração e a cada estágio, o modelo virtual cresce com funcionalidades adicionais, que, por sua vez, são utilizadas pelos desenvolvedores de software para escrever um driver ou criar firmware para esta funcionalidade.

Nessa abordagem, os desenvolvedores de modelo e software usam especificações comuns. Ao executar o software em um modelo, eles estão essencialmente verificando o trabalho um do outro.
Uma vantagem adicional é a validação do "hardware", apesar do próprio hardware ainda nem estar lá. Parece surpreendente à primeira vista, mas estamos falando sobre erros de arquitetura no design do dispositivo, alguns dos quais podem ser detectados ao executar o software em um modelo. E isso é muito legal, já que é possível consertar esses bugs no hardware antes do lançamento. Caso contrário, esses erros levariam à necessidade de relançar as próximas revisões, e isso é um prazer caro.
Tivemos um caso em que 10 blocos para processamento do fluxo de dados de entrada foram implementados em um dispositivo complexo, e os registros de controle e gerenciamento nos permitiram trabalhar com apenas metade deles. Isso foi implementado na versão anterior do dispositivo, e os arquitetos simplesmente se esqueceram de expandir essa parte. Quando criamos o modelo e a outra equipe escreveu e executou o driver, rapidamente descobrimos que todas as funcionalidades avançadas não estavam disponíveis. A arquitetura e as especificações foram corrigidas a tempo, antes que o protótipo físico do dispositivo fosse criado.
Grandes empresas de dispositivos podem dar suporte a todo um ecossistema construído em torno de seus produtos. Esse ecossistema inclui muitas outras empresas, inclusive aquelas que produzem software para esses equipamentos. Por exemplo, podem ser fabricantes de BIOS, os chamados IBV (Independent BIOS Vendors), os mais famosos dos quais são AMI, Insyde, Phoenix. Essas empresas também recebem modelos do fabricante do hardware e começam o desenvolvimento antes que o dispositivo físico apareça. Por exemplo, o simulador Simics é usado para plataformas Intel, que pode ser lido com mais detalhes no artigo Parceiros do ecossistema trocam de lugar com a Intel para um tempo de chegada mais rápido ao mercado .
Obviamente, a criação de modelos requer custos adicionais. A quantidade de custos, é claro, depende do tipo de modelo (funcional, por ciclo, etc.), mas em geral, o custo de criação de um modelo pode ser considerado aproximadamente igual ao custo de escrever software para o dispositivo. Nem todas as empresas estão dispostas a pagar esse preço por um lançamento anterior, e é por isso que essa abordagem é comum em grandes corporações. Eles têm orçamentos suficientes para isso, e o lançamento antecipado de um produto no mercado aumenta significativamente sua receita. Embora recentemente, tenha havido uma tendência de uso mais difundido de simuladores para desenvolvimento de software em empresas de pequeno porte.
Muitas vezes, para reduzir custos, o modelo não implementa todas as funcionalidades possíveis, mas apenas o mínimo necessário para determinados cenários de uso do dispositivo. Por exemplo, se um dispositivo de rede não foi planejado para ser usado em VLANs, mas apenas para atualizar o firmware e baixar via tftp, então não é necessário implementar a lógica com tags VLAN, mas a funcionalidade para cenários de inicialização do dispositivo pela rede e atualizações de firmware devem ser implementadas por completo volume.
Qual é o resultado final?
Se assumirmos que o tempo de desenvolvimento de hardware e software são aproximadamente iguais entre si (veja a imagem acima), então o uso de modelos pode reduzir significativamente, quase 2 vezes, o tempo de comercialização de um produto (denominado TTM - Time To Market) , uma vez que o desenvolvimento de "hardware" e software é realizado em paralelo, e não sequencialmente. Para isso, o termo Shift Left é frequentemente usado, vindo da área de testes, onde significava testar o mais cedo possível. O mesmo termo se aplica ao desenvolvimento de software, que parece se deslocar para a esquerda na linha do tempo quando é executado no simulador.
Quando aparecer a primeira revisão do equipamento, será necessário apenas verificar a operabilidade do software em hardware real. Idealmente, os erros e correções não devem ser significativos e esta etapa não apresenta grandes atrasos, uma vez que o código já foi escrito e depurado no modelo.
Esta abordagem não é "gratuita", requer um orçamento adicional e uma equipe de programadores, portanto, você precisa entender claramente quanto esses custos compensarão em um caso ou outro.
Este não é o único caso de uso para simuladores. Falarei sobre pesquisa arquitetônica e criação de ambientes complexos nos próximos artigos. Não mude.