tristate

[tcpipchip]

estou finalizando um UCP para FPGA e na especificação coloquei vários elementos ROM, RAM, FF, REG ligados no mesmo DATA BUS com TRISTATE.

Disseram que não é uma boa prática...pq ?

[andre_luis]

Palpite...só se nenhum deles for ao menos weak pull para algum nível lógico, faz sentido ?

[tcpipchip]

Faz sentido...
Mas...não queria mexer muito no que esta funcionando!
Pediram para por vários MUX

[tcpipchip]

veja isto

Em vez disso, usar um multiplexador com saída ativada também não funcionará se você pretende sintetizar seu projeto para FPGA, já que os sinais tristate não são suportados nos FPGAs (atuais). Na melhor das hipóteses, os sinais tristate serão emulados por meio de lógica adicional pelo sintetizador lógico. Eu recomendaria usar um multipler simples, que seleciona a saída correta com base na faixa de endereço de leitura.

QUE M. nao queria reprojectar a M+++

[msamsoniuk]

eh, dentro da FPGA nao tem elementos com tri-state, eles sao de uso exclusivo para pinos de IO. um grande problema do tri-state eh que permite contencao de bus e isso reduz a velocidade, ou seja, ao inves de operar no range entre 250 e 750MHz tipico para FPGAs, o tri-state baixaria essa velocidade para algo entre 25 e 100MHz.

a alternativa hi-speed para agregar barramentos eh usar mux.

[tcpipchip]

Exato Marcelo

Já estou reconstruindo o processador com esta configuração!

Todas as OUTPUTS indo para um MUX.

[tcpipchip]

esta é a variante dele, mas escrito em C#

https://www.youtube.com/watch?v=F27MNn1m-mI

Falta hoje, apenas finalizar o Hardware aqui no Altera

[tcpipchip]

Removido tristate!
Maquina RISC finalizada

[tcpipchip]

M+++ lite Evolution - 8 bits
64K de ROM
256B de RAM
256B de STACK
18 INSTRUÇÕES
acesso a memoria RAM direto ou indiretamente
4 ENTRADAS DIGITAIS de 8 BITS
4 SAIDAS DIGITAIS de 8 BITS
INSTRUCOES ADD,SUB, AND, OR, NOT, XOR, INC, CALL, RET, JMP, JMPZ, JMPZ, MOV, PUSH, POP
ASSEMBLADOR

https://youtu.be/HqbfzF_YWV8

[msamsoniuk]

voce tem que fazer um salto de feh ae e ir logo para verilog! e depois adotar o RISC-V!

[tcpipchip]

o RISC V já estou 'testando" faz uns 6 meses...

[tcpipchip]

"feh" está em HEXADECIMAL ?

[msamsoniuk]

salto de feh, vc tem que assistir mais indiana jones! eh que eu tenho preguica de usar acentuacao qdo estou em "modo descanso"



mas entao, tem varios sabores de RISC-V!

o meu eh um pouco mais complexo pq eu queria primar pela performance, com CPI ~ 1 (clocks per instruction) e ele chega a 1.15, o que eh bem bom, mas ao custo de um certo nivel de complexidade (pipeline de 3 estagios, memorias sincronas, arquitetura de harvard, duplicacao de banco de registros, suporta threading, etc). o meu ficou popular entre estudantes por ser em verilog, visto que no comeco a maioria dos cores era montada em linguagens de alto nivel, como o vexriscv, que eh um core com pipeline de 5 estagios e CPI ~ 1, mas escrito em chisel (parente de escala) e que usa um tool de conversao para gerar um verilog ininteligivel hehehe

tem o core de um amigo meu fez o desenvolvimento de um core do zero que eh mais simples (maquina de estado, arquitetura von neumann, bem estruturado, etc) e gravou tudo:

https://www.youtube.com/playlist?list=PLEP_M2UAh9q52a-w3ZUEChEoG_ROeMa88

outra opcao legal eh o SERV, que eh um RISC-V bit-serial, ou seja, ele ocupa bem pouco espaco as custas da performance (CPI >= 32). comparativamente, em uma FPGA onde se coloca 100 vexriscv rodando em 100MHz, eh possivel colocar 1024 cores SERV rodando em 128MHz e que permite muita pesquisa relacionada a HPC com poucos recursos. com o meu core, darkriscv, eu fiz um experimento na mesma placa com um unico core e 128 threads, bem louco!

sobre o SERV, ele tipicamente ocupa 1/4 do tamanho dos menores RISC-V e tem ateh um concurso para ver quem coloca mais cores, as duas entradas de 1024 cores (5a e 6a) sao minhas:

https://corescore.store

no mais, o santo graal ainda eh o GRVI do Jan Gray:

https://forums.xilinx.com/t5/Xcell-Daily-Blog-Archived/Shazam-Jan-Gray-gets-1680-RISC-V-processors-to-dance-on-the-head/ba-p/789549

todo mundo fica tentando entender como ele conseguiu chegar a apenas 320LUTs e 375MHz nesse core:



ao que parece a chave eh construir algumas unidades que sao menos usadas, mas consome mais area de forma compartilhada, como shift e tal. outra tecnica eh que ele meio que roteia e otimiza tudo na mao.

enfim, o bom do RISC-V eh que a spec minima RV32E com apenas 37 instrucoes eh perfeitamente suportada pelo GCC, o que significa zero esforco na parte de software!