Microsoft projeta chips do Azure no próprio Azure e testa workloads de EDA no Cobalt 200

A Microsoft diz que todo chip do Azure que ela construiu nasceu em jobs de EDA (electronic design automation), usados para projetar, testar e validar o silício antes da fabricação. São simulações de dias, regressões de verificação espalhadas por milhares de cores durante a noite e execuções de physical signoff que consomem centenas de gigabytes de memória por bloco. No total, centenas de milhões de compute jobs por ano.

Os testes foram feitos com Cadence Xcelium e Spectre, Synopsys VCS e PrimeTime, e Siemens Calibre. As ferramentas já habilitadas no Cobalt 100 rodaram sem modificação no Cobalt 200. Os números variam de 1,30x (Calibre DRC, com cerca de 23% menos tempo de parede) a 4,15x sobre o Cobalt 100. No PrimeTime, o ganho foi de 2x de throughput por logical core. No Spectre, 38% geração sobre geração. Em RTL com Xcelium e VCS, mais de 40% de throughput por logical core sobre qualquer outro sistema testado.

Ressalvas da própria Microsoft: os resultados são preliminares, vêm de casos de teste internos e valem só para as cargas, versões de software, configurações de VM e níveis de concorrência avaliados. As VMs comparadas tinham tamanhos diferentes: Cobalt 100 com 96 cores, Cobalt 200 com 128, hx176rs com 176 e e160adsv7 com 160 logical cores e hyperthreading ligado. Por isso o throughput é normalizado por logical core. A empresa afirma que trabalha com os parceiros de EDA em mais ajustes e que o Cobalt 200 está entrando em disponibilidade geral.

Do lado de plataforma, o texto cita capacidade elástica (provisionar para uma campanha de regressão ou um esforço de signoff e liberar depois), armazenamento de alto desempenho, capacidade global e proximidade com serviços de IA do Azure. A premissa é sair do modelo x86 on-premise dimensionado para o pico, com períodos ociosos.

Para quem opera plataforma ou gerencia farms de CI pesado, o caso é um exemplo de como medir: throughput por core sob carga alta, não em VM ociosa. Também mostra o argumento de custo de capacidade elástica contra hardware dimensionado para o pico. É leitura nossa: como os testes são internos e preliminares, vale rodar a sua própria carga antes de migrar, e conferir se suas ferramentas têm build Arm.