Processador AMD MicroBlaze V: soft core RISC-V flexível para FPGA

 (xilinx.com)
3 pontos por GN⁺ 2023-11-05 | 1 comentários | Compartilhar no WhatsApp
  • AMD MicroBlaze V é um IP de processador RISC-V soft core para uso em AMD adaptive SoCs e FPGAs, integrado ao fluxo de projeto do Vivado e do Vitis
  • Mantém a compatibilidade de hardware com projetos MicroBlaze existentes, ao mesmo tempo em que busca portabilidade de software baseada na ISA RISC-V e aproveitamento do ecossistema open source
  • Permite configurar os conjuntos básicos de instruções RV32I e RV64I, com extensões opcionais M/A/F/C e extensões de manipulação de bits ZBa, ZBB, ZBc, ZBs
  • Oferece configurações predefinidas desde microcontroladores até processadores de aplicação, incluindo 4 opções de pipeline e recursos de segurança como dual-core lockstep e TMR
  • Pode ser direcionado, sem custo adicional, a qualquer dispositivo AMD adaptive SoC ou FPGA compatível com o Vivado Design Suite, embora RV64I e a Memory Protection Unit estejam em Early Access, e a Memory Management Unit ainda esteja no roadmap

Processador RISC-V em software para AMD adaptive SoCs e FPGAs

  • AMD MicroBlaze V é um IP de processador RISC-V soft core para AMD adaptive SoCs e FPGAs
  • Baseia-se na arquitetura de conjunto de instruções RISC-V (ISA) e oferece uma arquitetura modular e configurável para aplicações de sistemas embarcados
  • Desenvolvedores podem direcionar o MicroBlaze V, sem custo adicional, a dispositivos AMD adaptive SoC ou FPGA compatíveis com o Vivado Design Suite
  • RISC-V é uma ISA padrão open source administrada pela organização sem fins lucrativos RISC-V Foundation, da qual a AMD é membro desde 2020

Configuração da ISA RISC-V e portabilidade

  • O MicroBlaze V é baseado em uma ISA open source apoiada por um ecossistema amplo de software e soluções da indústria
  • O objetivo do projeto é facilitar a migração de hardware de projetos existentes com processadores MicroBlaze e aumentar a portabilidade de software em projetos RISC-V
  • Escopo de suporte configurável da ISA:
    • RV32I e RV64I Base Integer Instruction Set
    • Extensão M para multiplicação e divisão
    • Extensão A para instruções atômicas
    • Extensão F para ponto flutuante
    • Extensão C para compressão de código
    • Extensões ZBa, ZBB, ZBc e ZBs para manipulação de bits
  • O recurso de compressão de código é usado para reduzir o tamanho do código e economizar memória no projeto

Arquitetura, desempenho e recursos de segurança

  • É possível escolher configurações predefinidas adequadas a várias faixas de aplicação, de microcontroladores a processadores de aplicação
  • Oferece 4 opções de pipeline para otimização de área ou desempenho
  • Também inclui recursos opcionais de segurança para sistemas críticos

    • Dual-core lockstep

      • Triple modular redundancy (TMR)

Fluxo de projeto com Vivado e Vitis, e periféricos

  • O MicroBlaze V oferece um fluxo de projeto integrado ao Vivado Design Suite e às Vitis software tools
  • É compatível com todos os AMD adaptive SoCs e FPGAs suportados pelas ferramentas de projeto Vivado
  • Pode ser usado tanto na interface gráfica (GUI) quanto na interface de linha de comando (CLI)
  • Com IPs otimizados, é possível inserir subsistemas integrados de processador MicroBlaze V na lógica programável, com o objetivo de reduzir o número de componentes do sistema e o tempo de desenvolvimento
  • Principais categorias de periféricos que podem ser adicionados via drag and drop:
    • General Purpose: Multichannel DMA, Streaming FIFO, Timer / Watchdog, Mutex / Mailbox
    • I/O: UART, USB 2.0, SPI, GPIO, PWM
    • Video: HDMI Camera/Display Interface, MIPI-CSI, MIPI-DSI, Video DMA
    • Memory: DDR, Quad SPI, SDRAM
    • Networking: Ethernet Subsystem, Controller Area Network

Configurações de exemplo, documentação e status de suporte

  • Há duas configurações de projeto de exemplo: MicroBlaze V Microcontroller e MicroBlaze V with Memory Protection Unit

  • Configuração MicroBlaze V Microcontroller

    • 32-bit Processor Core RV32IMAFC
    • JTAG Debug Interface
    • Tightly Coupled Local Memory
    • SPI controller, I2C Controller, UART
    • Interrupt Controller, Timer, GPIO

  • Configuração MicroBlaze V with Memory Protection Unit

    • Todos os blocos predefinidos do preset de microcontrolador
    • Instruction Cache

    • Memory Protection Unit

      • Data Cache
      • Memory Controller

  • Documentação e recursos de suporte

  • Status de suporte

    • A Microcontroller configuration está disponível em produção
    • AMD MicroBlaze V com RV64I e Memory Protection Unit está em Early Access
    • AMD MicroBlaze V com Memory Management Unit está no roadmap

Leituras relacionadas

1 comentários

 
GN⁺ 2023-11-05
Opiniões no Hacker News

  • Pode ser confuso se você não lembrar que a AMD adquiriu a Xilinx recentemente
    Daqui para frente, é bem provável que muitos novos produtos da Xilinx passem a levar o nome da AMD

    • É difícil ver isso como um produto novo aleatório. O Xilinx MicroBlaze é uma tecnologia com mais de 20 anos e foi um dos primeiros softcores “de verdade” desenvolvidos para FPGA
      O equivalente do lado da Intel seria o Altera NIOS II

  • Segundo um comentário no Reddit [1], isso seria como colocar um decodificador de instruções RISC-V na frente do RTL do MicroBlaze existente
    Do ponto de vista de “vamos criar o melhor core RISC-V”, isso parece não fazer muito sentido, mas esse nunca foi exatamente o objetivo da Xilinx/AMD
    O MicroBlaze era um bom exemplo de uma CPU RISC sequencial, sem graça, que entra em nichos sem graça; para uma fabricante de FPGA, um softcore é meio que um produto-isca. Ajuda a vender silício, mas não ganha dinheiro por si só. Como não é a área do FPGA que determina o desempenho, e sim algo mais próximo de uma “cola de integração”, “bom o bastante” já basta
    Se a AMD realmente reutilizar o RTL do MicroBlaze, consegue manter o firmware existente (core, FPU, depuração, periféricos etc.) e o software (HAL, compilador, drivers). Isso é muito atraente tanto para o fornecedor quanto para usuários que querem migrar para o novo core MicroBlaze sem sofrimento
    1: https://old.reddit.com/r/FPGA/comments/17mdcyt/microblaze_go...

    • Esse usuário do Reddit tem karma -5. E, em um cenário em que dá para implementar um core RISC-V simples do zero em alguns dias, essa ideia quase não faz sentido
      Eu não confiaria nessa informação
      Ainda assim, ele tem as mesmas interfaces externas do MicroBlaze existente, então, do ponto de vista de hardware, é de fato um substituto que pode ser encaixado diretamente em projetos atuais
    • É correto dizer que, para fabricantes de FPGA, softcores são produtos-isca. Essas tecnologias habilitadoras não geram dinheiro por si mesmas, então não são tratadas como algo valioso em empresas de hardware
      É por isso que os CEOs bilionários da Xilinx e da Altera balançam a cabeça com pena quando ouvem que Jensen Huang continua despejando dinheiro na stack de software da Nvidia. Um dia eles vão aprender onde está o valor de verdade

  • Alguém consegue explicar o quanto esse anúncio é importante para o RISC-V?

    • Outros grandes fabricantes de FPGA já começaram, há alguns anos, a oferecer cores RISC-V com suporte oficial como alternativa aos seus cores com conjuntos de instruções proprietários
      Claro que também se usam muitos cores de terceiros do GitHub, mas estar oficialmente integrado e suportado na IDE e nas ferramentas faz diferença para muitos clientes
      A MicroSemi oferece softcores RISC-V desde 2017 e, desde o fim de 2020, também oferece hardcores como o PolarFire SoC. Exemplos incluem a nova BeagleBoard Fire, a Icicle etc.
      A Lattice anunciou seu primeiro softcore RISC-V oficial por volta de junho de 2020, anunciou uma colaboração com a SiFive em dezembro de 2019 e, em meados de 2021, lançou versões melhoradas, como um core de 800 LUTs
      A Intel introduziu o Nios V em outubro de 2021
    • O MicroBlaze era um core na escala de contagem de portas que o RISC-V vem ocupando agressivamente
      Coisas como Tensilica e ARC também perderam muito valor agregado nessa área. Falando como alguém que já portou um kernel diretamente para MicroBlaze, ele é um RISC clássico com pipeline, na faixa de cerca de 20 mil portas, mais ou menos entre MIPS e SH4
      O ponto mais interessante desse anúncio é que a AMD/Xilinx foi fundo a ponto de redefinir o próprio termo registrado “MicroBlaze”, em vez de criar um novo nome e continuar dando suporte a atualizações do MicroBlaze existente
    • A antiga SiFive tinha um core RV32 que cabia em um Artix-7, mas era bem básico
      A E/S era toda fragmentada, e nem dava para usar a DRAM integrada da placa. Seria ótimo ver um softcore RV32 com suporte oficial no Artix-7
      Eu já usei o MicroBlaze de forma bastante satisfatória no passado, mas ele era muito fechado, então eu não pensaria em usá-lo fora de testes ou educação. Não sou um defensor fervoroso do RISC-V, mas ele se encaixa bem nesse tipo de área. É algo como “vamos fornecer ferramentas que usam um conjunto de instruções no qual você talvez já tenha investido, e não vamos tentar te prender também nessa toolchain”
      É até aceitável que a AMD/Xilinx te prenda, em certa medida, abaixo do conjunto de instruções. Afinal, seja comprando um FPGA, seja comprando algum dia uma peça de catálogo que talvez venha a existir, é bem provável que você ainda tenha de pagar pelo hardware
    • A Xilinx é uma fabricante de FPGAs bem grande, e o MicroBlaze oferece recursos de tolerância a falhas bastante bons, incluindo TMR
      TMR em si não é novidade no RISC-V, mas isso significa que muitos projetos que já usam MicroBlaze, e projetos novos que gostariam de usar MicroBlaze, agora poderão usar RISC-V
    • Ele é um microcontrolador e também pode operar como CPU em tempo real
      RISC-V já é bastante popular nesse mercado

  • Fico curioso sobre os usos do MicroBlaze V em comparação, por exemplo, com o SERV https://serv.readthedocs.io/en/latest/servant.html
    Ou seja, além da aprovação oficial da fabricante do chip, a única vantagem que o MicroBlaze V parece oferecer é velocidade. CPUs em FPGA não costumam ser usadas para tarefas que não são tão sensíveis a tempo? Eu vejo o propósito como deixar as tarefas rápidas e sensíveis a tempo para o tecido FPGA, junto com as interfaces de E/S on-chip

    • O ponto central são ferramentas e suporte. A pessoa não quer ficar mexendo manualmente em um softcore RISC-V; ela quer algo que simplesmente funcione e já se conecte bem às coisas que realmente importam
      O MicroBlaze permite literalmente montar seu próprio softcore por drag-and-drop, escolhendo entre várias opções de configuração e periféricos. Também inclui um SDK para a aplicação do usuário e ferramentas de depuração para encontrar a causa de problemas
      Se você desenvolver com o SERV, não seria surpreendente que o tempo de desenvolvimento seja ordens de grandeza maior, apenas pela menor maturidade das ferramentas

  • É bom que um novo softcore esteja saindo, mas fico pensando se havia mesmo necessidade de poluir ainda mais o namespace
    MicroBlaze já é o nome de uma arquitetura que alguém pode acabar pesquisando
    Poderiam simplesmente ter chamado de algo como AMDcoreV

    • Exato. MicroBlaze é o nome de uma arquitetura pertencente à AMD e, segundo o artigo, este core é compatível com ela

      It allows developers to leverage the open-source RISC-V software ecosystem, is hardware compatible with the classic MicroBlaze processor

    • A interface vista pelo HDL é a mesma. Já do lado do software, trata-se do conjunto de instruções RISC-V, que está crescendo rapidamente para se tornar o ecossistema mais forte
      Basta recompilar e, desta vez, sem precisar lidar com ferramentas fracas, proprietárias, customizadas e de baixa qualidade; dá para usar ferramentas confiáveis e padrão da indústria, como gcc, binutils e llvm
    • Este é o novo Xilinx MicroBlaze. É a migração de um conjunto de instruções parecido com AVR para RV32
    • Você não está falando daquela arquitetura MicroBlaze que a AMD passou a possuir com a aquisição da Xilinx?
    • Ainda assim, por ser MicroBlaze V, é melhor do que usar simplesmente o nome sem sufixo

  • Ele inclui algo equivalente ao PSP ou ao ME? Já estou farto de CPUs caixa-preta suspeitas, inseguras e impossíveis de corrigir

  • O core em si é open source?

    • Provavelmente não, mas a AMD disse que ele pode ser usado gratuitamente em qualquer FPGA AMD(Xilinx)
      Se fosse preciso pagar licença, eu não teria interesse neste anúncio, já que existem alternativas gratuitas
      Dá para considerar que este core é bem otimizado para usar eficientemente os recursos dos FPGAs Xilinx, e é provável que essa seja a vantagem em relação às alternativas
    • Pode não estar sob uma licença open source, mas o código-fonte do core MicroBlaze anterior vinha incluído no kit de desenvolvimento e era apenas levemente ofuscado
      Eles nem removeram os comentários do código-fonte

  • Seria bom ter uma visão geral que comparasse esses softcores RISC-V de uma vez
    Coisas como se são open source, qual é a pontuação no CoreMark, qual é o tamanho etc.
    neorv, serv, vexrisc, nios v, microblaze v e assim por diante

  • Existe algum kit de desenvolvimento para testar isso? Como começar?

  • Este é um primeiro passo, e é um bom sinal
    Só que eu preferiria que fosse um core de 64 bits, em vez de um core de 32 bits. Porque, ao escrever caminhos de código em assembly RISC-V de 64 bits, eles poderiam ser realmente reutilizados em desktops, servidores e embarcados

    • Não é um “primeiro passo”. Já é um de vários passos
      Se você quer um core de 64 bits, acho que não está no mercado-alvo
      Também não é realista reutilizar assembly RISC-V de 64 bits em desktops, servidores e embarcados. Desktops e servidores são, na prática, exclusivamente 64 bits, enquanto a maioria dos embarcados usa cores de 32 bits, então não há tanta sobreposição
      Além da diferença entre 32 e 64 bits, o ambiente de programação também muda bastante: complexidade do sistema, procedimento de boot, formas de interagir com o mundo externo etc.
      Em resumo, é preciso escolher o dispositivo-alvo e programar de acordo com ele. Se você quer portar facilmente entre vários tipos de dispositivo, o mais adequado é escrever em outra linguagem, não em assembly