ASM51

Ola Marcelo

Podes olhar se conseguimos implementar num FPGA ?

Segue descricao e projeto

https://www.dropbox.com/sh/rdzpj2ru2ins ... TOV_a?dl=0

tcpipchip escreveu:Ola Marcelo

Podes olhar se conseguimos implementar num FPGA ?

Segue descricao e projeto

https://www.dropbox.com/sh/rdzpj2ru2ins ... TOV_a?dl=0

vou dar uma olhada!

Se conseguir, já quero adotar na disciplina!

Ai posto uns exemplos de código de máquina!

tcpipchip escreveu:Se conseguir, já quero adotar na disciplina!

Ai posto uns exemplos de código de máquina!

bom, eu baixei o mpp.zip lah e encontrei os arquivos todos em verilog jah. salvo uma pequena correcao em um arquivo (foi usado "=" para um register, mas precisa ser "<="), basicamente usei o codigo como estava e consegui gerar uma primeira versao. evidentemente deve ter muitas falhas para corrigir, mas de forma preliminar consumiu 114 LUTs e a sintese indica capacidade de rodar ateh 183MHz em uma xilinx spartan-6. sao valores bem bons, mas a tendencia depois de consertar os warnings eh ficarem um pouco piores que isso, pois precisa trocar alguns latches por flip-flops para funcionar corretamente. de qq forma, provavelmente vai ficar com clock final maior que o darkriscv e consumindo muito menos logica (eh razoavel, dado o nivel de complexidade menor). vou adicionar uma uart bufferizada no in/out, de modo que de para rodar um "hello world" pela serial e testar em um kit por aqui.

bom, para mandar um "hello world" pela porta out, como ficaria o codigo? ele tem algo tipo move valor,acc e entao move acc,out ? uma sequencia de codigo desse tipo, imprimindo um texto p/ o out e finalizando com um loop de um jmp para ele mesmo ajudaria bastante!

Bola um curso de FPGA prá nóis, Sam...

Você tinha comentado que não sabia qual abordagem usar, uma ementa que envolva sintetizar um Risc V e colocar uns perféricos (USART, SPI, etc), você acha viável ou é necessário ser um tanto jedi prá isso?

Marcelo S!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Tu é rápido hein! Até parece que entende de FPGA

Brincadeira!

Aqui é um dos exemplos que executamos na nossa M++

Código: Selecionar todos

        MOV 00,A;
ESCREVE:
   MOV A,OUT0;
   MOV A,OUT1;
   MOV A,OUT2;
   MOV A,OUT3;
   INC A,A;
   JMP ESCREVE;


Zera acumulador, manda acumulador para as 4 saidas, incrementa acumulador, repete o ciclo.

O código de máquina é

Código: Selecionar todos

07, C0, 00, C3, CB, D3, DB, E0, 07, 03, 00, 03
------------
MOV 00,A
                 -----------------------
                 MOV A,OUT0..3
                                              ------------------
                                              JMP 0003

Veja se isto já roda! E depois vamos para pilha para CALL/RET

Execucao no simulador

https://www.dropbox.com/s/orgtcsjjmxuzw ... B.png?dl=0

Aqui a parte interna da M++

http://www.inf.furb.br/~maw/pdf/

quem dera! apenas coloquei os fontes na ferramenta para sintetizar e gerar um diagnostico... agora tem que ir simulando clock a clock e ir corrigindo os pequenos detalhes passo a passo ateh funcionar.

alguns comentarios iniciais: dentro do codigo existem muitos elementos nao-sintetizaveis, ou seja, que nao possuem modelo fisico real, como tri-state em barramentos internos, delays e uso do for(). o tri-state soh eh sintetizavel nos pinos de IO da FPGA e internamente deve-se sempre usar multiplexadores. os delays sao similares, ou seja, soh sao sintetizaveis nos pinos de IO da FPGA e internamente deve-se sempre usar flip-flops para prover atrasos quantizados de acordo com um clock. no caso de construcoes com for(), sao usados apenas em simulacao e nao produzem codigo. para produzir codigo, eh possivel usar generate e for(), mas o codigo em particular eh a inicializacao de um banco de registros (4 registros de 8 bits), entao ainda esbarra em um problema que arrays de memoria precisam ser fisicamente enderecados. na pratica, como sao poucos registros, acaba sendo melhor expressar eles como registros individuais.

quando aos elementos sintetizaveis, tem alguns detalhes chatos... no codigo temos muitas construcoes do tipo:

Código: Selecionar todos

reg alguem;

always@(linha)
    if(linha==0) alguem = algum_lugar;

a construcao eh valida e vai gerar um latch, de modo que alguem recebe algum_lugar quando linha for ativado em zero.

bom, eh uma construcao que lembra muito o process do VHDL, mas nao eh muito popular em verilog realmente. um dos problemas eh que isso gera um latch, ou seja, ele captura a entrada enquanto linha for valido. mas isso reduz a performance em comparacao a um flip-flop que captura a entrada em uma borda, de modo que a construcao mais usada seria:

Código: Selecionar todos

reg alguem;

always@(posedge linha)
    alguem <= algum_lugar;

no caso, posedge indica que o flip-flop ira capturar algum_lugar para dentro de alguem na borda de subida de linha. mas ainda aqui temos um outro problema: arvore de clock. como linha eh um sinal qualquer e pode eventualmente ter sido gerado por logica combinacional, existe a possibilidade de linha ter jitter e ruido. para evitar isso, o certo seria usar um clock global de modo que todos os sinais fossem sincronos com este clock, incluindo linha e algum_lugar, de modo que ficaria:

Código: Selecionar todos

reg alguem;

always@(posedge clk)
    if(linha==0)
        alguem <= algum_lugar;

finalmente, embora externamente seja popular o uso de sinais ativados em zero, isso vem dos tempos imemoriais onde os processadores eram construidos com portas NMOS, ou seja, todas as linhas eram ligadas em nivel alto por pull-ups e transistores NMOS driveavam a linha para zero para ativar.

hoje em dia, na era CMOS temos pares de transistores PMOS e NMOS capazes de drivar tanto para zero quanto para um, de modo que os sinais podem perfeitamente ser ativos em nivel 1. outro detalhe a adicionar eh reset, de modo que temos:

Código: Selecionar todos

reg alguem;

always@(posedge clk)
    if(reset)
        alguem <= 0;
    else
    if(linha)
        alguem <= algum_lugar;

mas essa notacao com if() else etc... tambem nao eh muito boa e lembra muito o VHDL com aquele sotaque carregado de ada... ao inves disso temos algo mais c-like:

Código: Selecionar todos

reg alguem;

always@(posedge clk)
    alguem <= reset ? 0 : linha ? algum_lugar : alguem;

basicamente eh o que esta escrito: se reset estiver ativo, carrega zero, se linha estiver ativo carrega algum_lugar, senao deixa como estah.

a vantagem dessa notacao eh que possui alguma simetria com o assert, de modo que, quando temos armazenamento:

Código: Selecionar todos

reg alguem;

always@(posedge clk) alguem <= reset ? 0 : linha ? algum_lugar : alguem;

mas quando queremos apenas logica combinacional sem armazenamento, podemos fazer o mesmo, mas como wire:

Código: Selecionar todos

wire alguem;

assert alguem = reset ? 0 : linha ? algum_lugar : alguem;

muito similar, mas com umas sutilezas: eh um wire, portanto logica combinacional, nao tem clock, portanto atualiza continuamente e instantaneamente. a notacao fica mais compacta e, na minha opiniao, mais legivel.

o lance do reset em particular eh bastante importante: primeiro que eh comum apos o power on as coisas nao estarem funcionando direito. apenas como exemplo, na propria simulacao o M++ jah nao carrega corretamente a primeira instrucao e eh isso eh mais comum do que parece! de fato, durante anos quase todos os meus processadores, incluindo as primeiras versoes do darkriscv nao carregavam corretamente a primeira instrucao, o que obrigava a comecar todo codigo com um nop! hehehe

no caso do M++ coloquei 4x "inc a" no inicio para testar e na simulacao fiquei olhando quando ele comecava efetivamente a processar o resto do codigo. como ele nao tem reset, ele acaba perdendo a primeira instrucao sempre. creio que nao eh dificil consertar, mas comecar com um "inc a" resolve o problema tambem pq mantem a sequencia de instrucoes corretamente alinhada qdo ele comeca executar codigo.

bom, nesse meio tempo eu tambem aproveitei para dar uma lida nas dissertacoes relacionadas ao M++. pelo fato de ter vindo de um conceito de esquematico, supostamente passivel de ser implementado com logica TTL discreta, fica um pouco dolorido para passar para verilog.

outra coisa interessante eh que medindo o numero de clocks por instrucao obtive algumas poucas medidas, mas suficiente para fazer algumas contas:

inc a = 8 clocks
mov 0,a = 10 clocks
jmp label = 14 clocks

assim, se conseguirmos rodar ele a 150MHz, daria uns 15MIPS apenas, acho que meio na media de outros processadores antigos... o 68008, por exemplo, precisava de no minimo 8 clocks por instrucao (e algumas podiam demorar centenas de clocks).

uma coisa que senti dificuldades eh que no aspecto do ISA do M++ nao achei com facilidade uma referencia das instrucoes. existe algum material sobre o assembler, mas para um nivel de desenvolvimento baixo nivel seria interessante um guia de referencia com instrucoes, bitmaps das instrucoes e tabelas indicando as possibilidades de cada campo nas instrucoes, bem como quantidade de ciclos para executar. outra coisa que acho que falta eh informacoes sobre licencas dos codigos disponiveis... nao sei como estah licenciado, mas se nao estiver recomendaria adotar uma licenca BSD ou MIT. tendo uma licenca, documentacao e estando melhor organizado, poderia ateh colocar o codigo no github hein

totavia, tambem tem o outro lado da moeda: da mesma forma que eu acabei largando o 680x0 para partir para o RISCV pq eh mais simples de implementar, sera que partir para um conceito mais moderno e otimizado para FPGA nao seria vantagem?

olha o tamanho deste core RISC de 16 bits que eu montei anteriormente:

http://darklife.org/pics/xilinx/src/core.v

apesar de ter apenas esse tamanho pequeno, ele tranquilamente atinge os 80MIPS e roda uma pah de instrucoes! com alguns updates, fica bem simples e didatico! hahaha

tcpipchip escreveu:Marcelo S!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Tu é rápido hein! Até parece que entende de FPGA

Brincadeira!

Aqui é um dos exemplos que executamos na nossa M++

Código: Selecionar todos

        MOV 00,A;
ESCREVE:
   MOV A,OUT0;
   MOV A,OUT1;
   MOV A,OUT2;
   MOV A,OUT3;
   INC A,A;
   JMP ESCREVE;


Zera acumulador, manda acumulador para as 4 saidas, incrementa acumulador, repete o ciclo.

O código de máquina é

Código: Selecionar todos

07, C0, 00, C3, CB, D3, DB, E0, 07, 03, 00, 03
------------
MOV 00,A
                 -----------------------
                 MOV A,OUT0..3
                                              ------------------
                                              JMP 0003

Veja se isto já roda! E depois vamos para pilha para CALL/RET

Execucao no simulador

https://www.dropbox.com/s/orgtcsjjmxuzw ... B.png?dl=0

Aqui a parte interna da M++

http://www.inf.furb.br/~maw/pdf/

xultz escreveu:Bola um curso de FPGA prá nóis, Sam...

Você tinha comentado que não sabia qual abordagem usar, uma ementa que envolva sintetizar um Risc V e colocar uns perféricos (USART, SPI, etc), você acha viável ou é necessário ser um tanto jedi prá isso?

eh que tem ***varios*** detalhes! lembra que no curso de DSP tinha uma plaquinha com um DSP, ele era facilmente programavel via UART e de quebra tinha ateh um tool que simulava um osciloscopio puxando dados da UART vindos do DSP. tudo isso complementado com uma interface de desenvolvimento que permitia programar comodamente em C... no caso da FPGA, eu precisaria desenvolver uma plaquinha, pq nao tem exatamente uma plaquinha muito didatica de FPGA que seja barata e programavel com facilidade. a vantagem agora seria jah prever um cp2102 ou ftdi p/ USB/UART, de modo a facilitar a vida. mas tem um pequeno dilema reference a parte de programacao da FPGA, que nao eh exatamente aquele conceito seguro que o DSP tinha de bootar de uma ROM interna... se pah, um daqueles attiny85 acabaria sendo melhor, pq conecta via USB, cai em uma serial e via serial descarrega a imagem para a FPGA ou para a SPI dela, algo assim. daih outro dilema sao os tools: as FPGAs mais novas nao tem mto problema quanto a isso, mas justamente as FPGAs que sao economicamente melhores para isso possuem alguns problemas com os tools, do tipo ***nao funciona em windows 10***, nada critico neh, ateh aqui nem precisamos chamar o obi wan para salvar o universo hahaha

supondo que resolvamos os problemas com os kits de desenvolvimento e ferramentas, daih temos aquele dilema: low level ou high level? no low level tem logica digital e verilog. dah para inclusive projetar o processador do zero e entender o que ele faz, o que nao faz e pq.... como diria o clovis de barros filho, EH BEM LEGAL!

jah no high level dah para comecar integrando uns blocos pre-fabricados, tipo RISCV com UART, SPI, GPIO, timer, etc. daih vai do que tem no kit, em principio teria uma USB/UART, a propria FLASH SPI e GPIOs. dah para implementar facil um timerzinho em verilog para fazer uma saida no GPIO controlada pelo RISCV e por aih afora. mas eu vejo por onde uso ele: daih jah vai querer ver a forma de onda no osciloscopio, daih jah precisa de um osciloscopio e por aih afora. alternativamente, daria para ligar um AD/DA de audio facil facil. e o meu RISCV tem extensao MAC, entao ateh rolaria puxar o cursinho de DSP, soh que rodando em um RISCV dentro da FPGA... sobre o dilema lah dos tools nao funcionarem no windows 10, tem uma saida: WSL2. roda os tools certinho e de quebra permite rodar outras coisas interessantes, como gtkwave e icarus verilog. sem falar no GCC! eu jah estava esquecendo o GCC! como compila as coisas para o RISCV sem GCC? o negocio eh meio casado saca, vc aumenta a memoria de programa no RISCV na FPGA, tem q mexer no linker lah no GCC. adiciona instrucao MAC no RISCV, tem que criar uma funcao dummy e mapear o opcode em assembler no GCC. eh um p*ta know know e se pah serve para qq processador isso... mas nao sei se nao eh complicado *demais*!

msamsoniuk escreveu:

xultz escreveu:Bola um curso de FPGA prá nóis, Sam...

Você tinha comentado que não sabia qual abordagem usar, uma ementa que envolva sintetizar um Risc V e colocar uns perféricos (USART, SPI, etc), você acha viável ou é necessário ser um tanto jedi prá isso?

eh que tem ***varios*** detalhes! lembra que no curso de DSP tinha uma plaquinha com um DSP, ele era facilmente programavel via UART e de quebra tinha ateh um tool que simulava um osciloscopio puxando dados da UART vindos do DSP. tudo isso complementado com uma interface de desenvolvimento que permitia programar comodamente em C... no caso da FPGA, eu precisaria desenvolver uma plaquinha, pq nao tem exatamente uma plaquinha muito didatica de FPGA que seja barata e programavel com facilidade. a vantagem agora seria jah prever um cp2102 ou ftdi p/ USB/UART, de modo a facilitar a vida. mas tem um pequeno dilema reference a parte de programacao da FPGA, que nao eh exatamente aquele conceito seguro que o DSP tinha de bootar de uma ROM interna... se pah, um daqueles attiny85 acabaria sendo melhor, pq conecta via USB, cai em uma serial e via serial descarrega a imagem para a FPGA ou para a SPI dela, algo assim. daih outro dilema sao os tools: as FPGAs mais novas nao tem mto problema quanto a isso, mas justamente as FPGAs que sao economicamente melhores para isso possuem alguns problemas com os tools, do tipo ***nao funciona em windows 10***, nada critico neh, ateh aqui nem precisamos chamar o obi wan para salvar o universo hahaha

supondo que resolvamos os problemas com os kits de desenvolvimento e ferramentas, daih temos aquele dilema: low level ou high level? no low level tem logica digital e verilog. dah para inclusive projetar o processador do zero e entender o que ele faz, o que nao faz e pq.... como diria o clovis de barros filho, EH BEM LEGAL!

jah no high level dah para comecar integrando uns blocos pre-fabricados, tipo RISCV com UART, SPI, GPIO, timer, etc. daih vai do que tem no kit, em principio teria uma USB/UART, a propria FLASH SPI e GPIOs. dah para implementar facil um timerzinho em verilog para fazer uma saida no GPIO controlada pelo RISCV e por aih afora. mas eu vejo por onde uso ele: daih jah vai querer ver a forma de onda no osciloscopio, daih jah precisa de um osciloscopio e por aih afora. alternativamente, daria para ligar um AD/DA de audio facil facil. e o meu RISCV tem extensao MAC, entao ateh rolaria puxar o cursinho de DSP, soh que rodando em um RISCV dentro da FPGA... sobre o dilema lah dos tools nao funcionarem no windows 10, tem uma saida: WSL2. roda os tools certinho e de quebra permite rodar outras coisas interessantes, como gtkwave e icarus verilog. sem falar no GCC! eu jah estava esquecendo o GCC! como compila as coisas para o RISCV sem GCC? o negocio eh meio casado saca, vc aumenta a memoria de programa no RISCV na FPGA, tem q mexer no linker lah no GCC. adiciona instrucao MAC no RISCV, tem que criar uma funcao dummy e mapear o opcode em assembler no GCC. eh um p*ta know know e se pah serve para qq processador isso... mas nao sei se nao eh complicado *demais*!

Acho que no atual mercado brasileiro o que atende a demanda da maioria das empresas é a abordagem high level.
A área de low level é a mais legal de estudar mas hoje existem poucos lugares que te pagariam pra utilizar essa abordagem no trabalho.
Culpa das carreiras em Y.

O Marcelo é muito bom mesmo!!!!! Caranba! Entendeu em minutos o que levamos 40 dias para fazer...

Aqui tem um link de aula

http://www.inf.furb.br/~maw/mais/

1) Descompacte
DigitalWorks_full_free.zip
execute digitaworks

2) Abra o projeto
maquina.dwm

3) execute
MontadorMmaismais.exe
Edite o teu programa e pressione o lampada da esquerda e entao da direita...
Vai "compilar" e gerar um .MAP

4) volte para o digital works (projeto)
click em ROM e abra o MAP

5) Click em play no DIGITAL WORKS
vAI SIMULAR...TEM UM MENU PARA AUMENTAR SIMULACAO PARA 100Hz

6) CLICANDO na M++ vai entrar nos blocos mais internos

7) SINAIS DE CONTROLE
http://www.inf.furb.br/~maw/mais/Controle.txt

RESUMO INSTRUCOES
http://www.inf.furb.br/~maw/mais/tabela_instrucoes.doc

9) EXEMPLOS
http://www.inf.furb.br/~maw/mais/exerci ... rucoes.rtf

Toca ficha Marcelo!!!!!!!

Sam, na faculdade eu tive oportunidade de brincar com um kit da Digilent, foi minha única experiência com FPGA, o kit não é barato mas também não é um assalto, eu não faço ideia se o FPGA daquele kit permitira colocar um Risc V, mas sob o ponto de vista de hardware, aquele kit tinha tudo prá espetar no computador e desenvolver as paradas (depois de baixar 5G daquele monstro de IDE da Xilinx). Lembro que ele tinha até um conector VGA e eu consegui gerar uma imagem no monitor, além de porta serial e mais uns botões/leds.
Sobre o high/low level, penso que seja mais adequado em separar em ementas diferentes, e eventualmente oferecer módulos e/ou cursos diferentes para abordagens diferentes. Provavelmente iniciar em high level e fazer o Hello World primeiro seja mais interessante, e depois ir para low level prá separar os homens do meninos.

Como diria o filósofo Mano Brown, "sei lá, minhas idéia".

tcpipchip escreveu:O Marcelo é muito bom mesmo!!!!! Caranba! Entendeu em minutos o que levamos 40 dias para fazer...

Aqui tem um link de aula

http://www.inf.furb.br/~maw/mais/

1) Descompacte
DigitalWorks_full_free.zip
execute digitaworks

2) Abra o projeto
maquina.dwm

3) execute
MontadorMmaismais.exe
Edite o teu programa e pressione o lampada da esquerda e entao da direita...
Vai "compilar" e gerar um .MAP

4) volte para o digital works (projeto)
click em ROM e abra o MAP

5) Click em play no DIGITAL WORKS
vAI SIMULAR...TEM UM MENU PARA AUMENTAR SIMULACAO PARA 100Hz

6) CLICANDO na M++ vai entrar nos blocos mais internos

7) SINAIS DE CONTROLE
http://www.inf.furb.br/~maw/mais/Controle.txt

RESUMO INSTRUCOES
http://www.inf.furb.br/~maw/mais/tabela_instrucoes.doc

9) EXEMPLOS
http://www.inf.furb.br/~maw/mais/exerci ... rucoes.rtf

Toca ficha Marcelo!!!!!!!

Que bacana portar a M++ pra FPGA, saudades das aulas nesse simulador

Se tornar realidade, já temos a M+++

Pronta a M+++, vamos adicionar um "M" de marcelo

M++++

tcpipchip escreveu:O Marcelo é muito bom mesmo!!!!! Caranba! Entendeu em minutos o que levamos 40 dias para fazer...

Aqui tem um link de aula

http://www.inf.furb.br/~maw/mais/

1) Descompacte
DigitalWorks_full_free.zip
execute digitaworks

2) Abra o projeto
maquina.dwm

3) execute
MontadorMmaismais.exe
Edite o teu programa e pressione o lampada da esquerda e entao da direita...
Vai "compilar" e gerar um .MAP

4) volte para o digital works (projeto)
click em ROM e abra o MAP

5) Click em play no DIGITAL WORKS
vAI SIMULAR...TEM UM MENU PARA AUMENTAR SIMULACAO PARA 100Hz

6) CLICANDO na M++ vai entrar nos blocos mais internos

7) SINAIS DE CONTROLE
http://www.inf.furb.br/~maw/mais/Controle.txt

RESUMO INSTRUCOES
http://www.inf.furb.br/~maw/mais/tabela_instrucoes.doc

9) EXEMPLOS
http://www.inf.furb.br/~maw/mais/exerci ... rucoes.rtf

Toca ficha Marcelo!!!!!!!

entao, eu dei uma procurada nos trabalhos originais e encontrei estes tools, mas eu soh tenho OSX aqui, daih nao consigo rodar. de qq forma, nos trabalhos escritos tem os detalhes e tal, daih fui meio que na engenharia reversa mesmo


Sent from my iPhone using Tapatalk

PERFEITO, TOMARA QUE CONSIGAS