RISC V

[tcpipchip]

fui atualizar o IAR hoje e esta na primeira pagina o RISC-V

[Rodrigo_P_A]

O Marcelo tá em outro nível, parabéns.

[tcpipchip]

sim, tudo que o marcelo escreve eu salvo aqui e leio com carinho!

[msamsoniuk]

valeu pessoal! <3 hahaha


Sent from my iPhone using Tapatalk

[B-EAGLE]

É verdade, volta e meia vejo os posts do Marcelo lá e cá a respeito do risc-v, parabéns pelo trampo!

Marcelo, você chuta que em quanto tempo os riscv vão chegar nos microcontroladores , coisas low-power, etc de uma forma acessível (preço, ferramentas, etc)?

[xultz]

Esse cara fez neste vídeo algumas previsões (e previsões são somente previsões, ele pode estar totalmente equivocado), e pela análise dele a maior probabilidade é que o Risc-V comece tendo boa penetração no mercado de microcontroladores, mas tem um caminho difícil (e eventualmente impossível) em mercados que exijam mais poder computacional (servidores, desktops, mobile, etc)

Eu não tenho conhecimento suficiente para opinar a respeito do que ele diz.

[msamsoniuk]

É verdade, volta e meia vejo os posts do Marcelo lá e cá a respeito do risc-v, parabéns pelo trampo!

Marcelo, você chuta que em quanto tempo os riscv vão chegar nos microcontroladores , coisas low-power, etc de uma forma acessível (preço, ferramentas, etc)?

boa pergunta, eu mesmo nao tenho ideia! hoje em dia o RISCV eh muito popular na area de FPGAs pq cabe em FPGAs pequenas, por exemplo, o RV32E cabe em uma Spartan-3 100E de 1920 LUTs e 4 blockrams, que eh um dos modelos mais baratos da familia. jah no outro extremo, tem casos de 1800 cores RV64I rodando em uma Virtex UltraScale enorme. veja que nestes casos especificos estamos falando em suporte a hardwares que nao tem como fazer com microcontroladores e processadores, mas fora desse ambito, FPGAs nao sao muito competitivas contra microcontroladores (preco) e processadores (performance). mesmo assim, isso abre a porta para o surgimento de ferramentas, como compiladores e know how sobre como o RISCV funciona, pavimentando o caminho para microcontroladores e processadores com arquitetura RISCV chegarem ao mercado. um ponto que mudou forte agora foi na area de mobile por conta da guerra comercial com a china, mas acho que eh cedo para saber onde vai dar isso.

jah nos segmentos de desktop e server, realmente nao vi nada palpavel a curto prazo. talvez tenha que pensar no aspecto de como o RISCV vai ocupar eventuais vacuos de mercado: o ARM tentou entrar nesses segmentos e nao conseguiu: salvo o POWER (dos top 500 supercomputadores, 3 sao POWER, incluindo os dois primeiros), o resto eh praticamente x86. na dinamica moderna, tentar e nao conseguir eh simplesmente enterrar o produto, ou seja, jah era para o ARM nesses segmentos. e o RISCV ainda ataca com o conceito de acabar com as licencas proprietarias: independente do uso ou nao do RISCV, MIPS, SPARC e POWER agora sao abertos e isso enterra de vez o modelo de negocios e o ganha pao da ARM. ou eles inventam outra forma de ganhar dinheiro e sobreviver a essa nova realidade ou nao vao existir em 10 ou 20 anos.

no caso da intel, eh quase indiferente: eles vao continuar vendendo desktops e servers por mais 10 ou 20 anos ainda sem sequer ouvir falarem do RISCV. se o RISCV realmente substituir o ARM e outras plataformas menores, chegando a se tornar um standard universal, tudo que a intel tem que fazer eh lancar um modo de compatibilidade e pronto. nao tem licenca, nao tem advogados, nao absolutamente nenhum impedimento para a intel fazer isso. provavelmente, ateh vai ser um bom negocio: da mesma forma q eles deixaram o x86 de 32 bits no chip e partiram para o x86 de 64 bits projetado pela AMD, certamente seria possivel adicionar um modo RISCV de 128 bits sem grandes obstaculos, coisa que vai ser necessidade para eles daqui 10 ou 20 anos quanto os espacos de enderecamento de 64 bits comecarem a ficar pequenos. o fato do RISCV ser little-endian hoje jah permite modos hibridos com kernel linux rodando em x86 e aplicativos rodando em RISCV (emulado no caso, mas que pode vir a ser nativo no futuro), na mesma maquina, de modo que o aplicativo RISCV chama uma syscall no emulador e essa syscall eh chamada diretamente 1:1 no kernel linux x86 nativo rodando na maxima performance! na medida que o supercomputador de hoje vai ser o desktop de amanha, um eventual intel com tecnologia RISCV de 128 bits e processamento vetorial provavelmente vai rodar a clocks muito maiores do que seria possivel no x86 (talvez 10 ou 20GHz) e conter muito mais cores por chip (possivelmente mais de mil). a chave eh eficiencia, e como o RISCV eh muito mais eficiente em todos os aspectos, faria milagres com a tecnologia de ponta da intel.

parece ficcao? pois na decada de 90 as pessoas ainda sonhavam que o linux um dia desbancaria a microsoft. 20 anos depois a microsoft eh a maior empresa do mundo e, olha que ironia, tem um tal de WSL2 no windows 10 que permite rodar linux lah dentro, com kernel compilado @microsoft.com e tudo mais. no fim das contas, se o RISCV for para o mundo de HW o que o linux foi para o mundo de SW, ver daqui 20 a intel simplesmente suportar milhares de containers RISCV diretamente em HW nao vai me parecer nada surpreendente, mas apenas uma repeticao do que aconteceu no SW. quem viver, vera!

[pamv]

Announcing the Winners of the RISC-V Soft CPU Contest
DATE:OCTOBER 1, 2019

As the number of connected devices skyrockets, the attack surface also increases. To solve the growing challenge of mitigating cybersecurity threats, every component in a system must be evaluated for its vulnerabilities. Processors today are able to run billions of instructions per second – this means you can access a world of content at your fingertips, but there’s also a risk of exploitation. Every processor requires built-in security features to keep systems safe.

A few months ago, we launched the RISC-V Soft CPU contest sponsored by RISC-V Foundation members Microchip Technology and Thales. Designers were challenged to develop a hardware secure RISC-V soft CPU solution that could thwart malicious software security attacks. The contest showed that simple mitigations can be integrated into designs to provide improved security. The contest also highlighted how the simple and flexible RISC-V architecture is ideal for securing the IoT. You can read about the rules of the contest at GitHub.

At the RISC-V EMEA Roadshow event in Paris on Sept. 24, Bertrand Tavernier of Thales announced the RISC-V Soft CPU contest winners. Each of the winning projects successfully mitigated five classical security attacks. Read on to learn more about the winning entries

https://riscv.org/2019/10/announcing-th ... u-contest/

[Rodrigo_P_A]

Marcelo, baseado em sua experiencia, o que daria para implementar em uma A3P250 da Microsemi?

https://www.microsemi.com/document-port ... -datasheet

[msamsoniuk]

Marcelo, baseado em sua experiencia, o que daria para implementar em uma A3P250 da Microsemi?

https://www.microsemi.com/document-port ... -datasheet

nao tenho muita ideia nao, pois eh uma tecnologia bem diferente do que eu costumo encontrar: essa FPGA usa LUTs de 3 entradas (LUT3), enquanto a maioria das FPGAs antigas e/ou baratas jah usa LUTs de 4 entradas (LUT4) e as melhores usam LUTs de 6 entradas (LUT6). e mesmo assim, nao sei se elas possuem capacidade de armazenamento, ou seja, tipicamente uma LUT4 pode ser usada como memoria de 16x1 bit e LUT6 como memoria de 64x1 bit. mas isso depende da pre-construcao da LUT prever essa possibilidade e pelo que entendi, no caso dessa FPGA da microsemi (que era actel e agora eh microchip), me parece q como unidade de armazenamento ela equivale a apenas um unico flip-flop para cada LUT3.

e eh facil ver como escala o consumo no caso do RV32I, que eh o RISCV com 32 registros de 32 bits. como o RV32I possui instrucoes no formato "op r1,r2,3", ele precisa replicar o banco para ter duas leituras e uma escrita:

LUT6 = 64 LUT6
LUT4 = 2*32*2 LUTs = 128 LUT4
LUT3 = 2*32*32 LUTs = 2048 LUT3

de resto, eh logica. mas eh facil imaginar que o consumo dobra de LUT4 para LUT3: para mapear funcoes de 4 entradas, vc precisa de duas LUT3. e minha referencia eh que o darkriscv consome umas 1200 LUT6 e 1800 LUT4, portanto suponho que vai para umas 3600 LUT3, embora nessa conta tenha os registros tambem, ou seja, sairia 128 LUT3 e somaria 2048 LUT3, portanto iria para um total de umas 5300 LUT3. claro, isso eh um chutao bem forte, mas na area de FPGA nao tem muito como prever as coisas sem colocar a mao na massa. tem o fator de performance tambem: com LUT6 eu consigo 100MHz, com LUT4 cai para uns 66MHz usando tecnologia similar. mas quando usa LUT4 com uma tecnologia inferior, cai para uns 40MHz. considerando que usam LUT3 por conta da epoca, eu chutaria que estaria na faixa dos 40 ou 30MHz, mas tem que pensar que tem muito mais LUT3, entao o jitter eh muito maior, o que pressiona o clock para baixo, entao eu diria que 20MHz deve ser algo mais esperado. ah sim! tem o armazenamento interno: em uma FPGA com LUT4 eu tenho 4 miseras blockrams totalizando 64kbit, enquanto que nessa microsemi temos apenas 1/2 disso.

assim, somando tudo, e note que eh um p*ta chutao, diria que em tese caberia um darkriscv rodando a 20MHz e com 1/2 da rom/ram de uma configuracao tipica com modelos peh de boi da lattice e xilinx. mas tem que considerar fatores como roteamento tambem: comparativamente, os bancos de registros consomem apenas 64 LUT6 ou 128 LUT4, mas isso nao eh a historia toda, pq precisa rotear isso. e certamente rotear 64 ou 128 LUTs interconectadas eh muito mais simples do que rotear 2048. assim, provavelmente tem um custo de roteamento que deve fazer aquelas 5300 LUT3 chegarem talvez a 8 ou 10 mil LUT3, o que daih jah explode o tamanho do componente. essa resposta pode ser vista como uma boa interpretacao sobre pq usar xilinx: em FPGAs deles com LUT6, eu tenho projetos em que a sintese chega a atingir ateh 110% de ocupacao e as ferramentas da xilinx conseguem otimizacoes magicas capazes de enxugar isso para menos de 98% e sem perder performance. parte da magia eh realmente suprimir partes redundates, parte eh resultado de um auto-router que realmente funciona bem.

eu acho que um core de 16 ou 8 bits, com menos registros e menos complexidade, caberia de forma mais confortavel nessa FPGA. ela nao eh ruim como FPGA, soh eh um pouco outdated, o que mostra tambem que o RISCV nao eh solucao para todos os problemas. ah sim, o numero de LUTs poderia ser 1024 LUTs menor se usar o RV32E, que eh uma maracutaria muito usada em FPGAs com LUT4 e reduz os registros para 16x32 bit, ou seja, pela metade. tambem nao conheco o software de sintese dessa FPGA e isso eh um ponto importante, pq o software pode realmente fazer milagres! mas infelizmente o mais esperado seria um software meio capenga mesmo, entao eu nao criaria muitas expectativas. se fosse para apostar, eu continuaria apostando em xilinx pq tem produtos bons em praticamente todos os segmentos (LUT4 e LUT6). fico com um peh atras em relacao a intel, dois pes atras com a lattice e tres com a microsemi. tem a achronix tambem que promete bater de igual para igual com xilinx e intel, mas somente em segmentos pop e daih eu nao tenho grana nem para entrar na brincadeira

[pamv]

RISC-V causando na The Economist

A new blueprint for microprocessors challenges the industry’s giants
RISC-V is an alternative to proprietary designs

https://www.economist.com/science-and-t ... ecomputing

[Rodrigo_P_A]

Obrigado Marcelo, esclareceu muito.

[julian camargo]

Interessante tudo isso. Não entendi nada !

Que argumentos vcs usariam para me fazer desistir de usar ARM e adotar isso ai?

Waiting for replay

PS: Não mexo com Embarcados e nem uso sistema operacional em ARM.

[msamsoniuk]

Interessante tudo isso. Não entendi nada !

Que argumentos vcs usariam para me fazer desistir de usar ARM e adotar isso ai?

Waiting for replay

PS: Não mexo com Embarcados e nem uso sistema operacional em ARM.

eu acho que o mais certo seria vc me convencer a desistir de usar FPGA e RISCV para usar ARM! hahaha

[tcpipchip]

Marcelo
Bom dia
Olhou ser é possivel implementar a M++ ?