68K ou coisa assim, again

[enigmabox]

Marcelo e Mastk,

Eu tenho um par de cada modulo DRAM, será que serve pra algo?

[msamsoniuk]

serve sim!

pelo quantidade de chips, cada um deles possui um bus de 4 bits, de modo que os 8 chips formam um bus de 32 bits completo, sendo que cada byte eh acessivel atraves de um sinal CAS diferente. se tiver componentes apenas de um lado, eh pq possui apenas um banco e um sinal RAS, se tiver componentes de 2 lados, eh pq possui 2 bancos e portanto 2 sinais RAS.

tem a questao da capacidade. eu nao conheco de cabeca os chips ali, mas geralmente sao algo tipo 512x512x4bit (256Knibble), 1024x1024 (1Mnibble) ou 2048x2048 (4Mnibble). essa eh a parte chata, pq vc tem q desenhar o mux de modo a se adaptar corretamente a organizacao do chip, ou seja, escolher corretamente a parte alta e baixa do bus Ax para multiplexar corretamente.

quanto ao refresh, minha sugestao eh tentar usar hidden refresh.

acho q encontra facil na internet a descricao logica de como implementar com uma CPLD. acho q eu jah vi inclusive com a otimizacao para usar FP mode!

[enigmabox]

Marcelo,

O banco de memoria acima, possui somente os chips que vc vê na foto. O banco de baixo tem chip dos dois lados.
Acho que antes de eu modificar a placa, aumentando a sram de 1 para 2mb, acho que vou botar o tico e o teco pra funcionar, tentar fazer algo com estas drams, quem sabe consigo ligar na placa MC68030. Também consegui na sucata 2 conectores para esta memoria, assim fica mais facil testar os bancos.
Vou tentar achar a descrição dos chips para saber as caracteristicas da Drams que parecem ser de 60ns.

[mastk]

Que da para usar da, mas nao confio nesses pentes antigos, podem me chamar chato, mas queria uns chips novos...
Como a dram eh por natureza multiplexada, pode-se ter megas em poucos pinos.
Quanto ao uso, fico com o receio de nao ter meios de utiliza-las ainda, na tecnica de hidden refresh, sera que toda as dram suportam ele? E no tempo de RAS para CAS eh possivel acertar qual pagina sera operada? e idependenta da que esta sendo lida?
Acho mais simples e por seguranca a cada ciclo no barramente, ou por interrupcao, ou por um elemento que tire a dram do bus, se exculte o refresh primodialmente, deixando a banda de lado, mas digo isso porque nunca as utilizei e ainda hoje fico em duvida sobre os pormenores do refresh. Tipo soh bimbar o RAS e blz? Tempo em que o conteudo expira etc...

[msamsoniuk]

bom, eu dei uma melhorada naquele controlador de dram em verilog e aproveitei para fazer um update no post!

basicamente ele ficou com a mesma cara que antes:

http://www.darklife.org/Home/dram_rtl.j ... edirects=0

novamente, apenas para o 68000 com bus de 16 bits, fazendo refresh segundo um contador configuravel na FPGA e mux de RAS/CAS sem fazer cache de RAS. a diferenca eh que eu melhorei a simulacao e consertei alguns defeitos, ou seja, agora tem uma simulacao sintetizavel do 68000 que gera ciclos de comprimento variavel conforme o tempo maior ou menor de resposta do DTACK:

http://www.darklife.org/Home/dram_sim.j ... edirects=0

o conceito basico continua o mesmo, ou seja, fazer refresh distribuido. atraves de uma simulacao sintetizavel da memoria eh possivel tambem debugar o que acontece dentro dela, ver as gravacoes e ciclos de refresh quando ocorrem. a simulacao tambem esta acertada em termos de clock, ou seja, dah para estimar a performance e tempos em funcao do que esta aparecendo no simulador (usei 60ns para o clock do sistema).

como agora ficou absurdamente comprido, coloquei o projetinho do ISE com o fonte (dram.v) em:

http://framework.sf.net/pics/verilog/dram.zip

a simulacao do 68000 ainda nao esta 100% acertada com o processador real, mas o ciclo normal esta consumindo 5 clocks e o ciclo com refresh 8 clocks. quero ver se na sequencia melhoro a simulacao para ficar 100% igual ao 68000 original e entao implemento o esquema de armazenar e testar RAS para fazer acesso em page-mode.

feito isso tem q dar uma boa revisada para ver se nao ficou nada com problema de metastabilidade, mas segundo as contas do ISE, esse design com maquina de estado esta bem otimizado e rapido ateh o momento, podendo rodar com um clock de ateh 220MHz, o q eh bem bom para uma fpga low-end!

[sisae]

Bem só pra continuar

consegui comprar um 6845 essa sexta, parece q ele vai me facilitar muito a vida. Quando ao q vc tinha comentado no outro forum, eu coloquei slot pra até 2 megas de memoria eeprom na placa-base (acho q não irei fazer um programa maior q isso por hora XDXD ), e espero conseguir usar um HD, mas depois q tudo tiver OK.

Vcs teriam algum info a mais do 6845? Só achei o Ds dele, mas não entendi como opera-lo...

Tenho alguns destes ai, alguem conseguiu usa-lo?

[mastk]

Sim, o enigmabox conseguiu.

[mastk]

Bati muito a cabeça na parede...



Agora ta quase, estou prototipando grande, espero amanha mesmo ver se 16 bits de cor serao o bastante e disso comecar a pensar em rotear essa tralha em uma placa soh ou sintetizar em algo compravel.



Como estao indo as coisa enigma e sam?

[msamsoniuk]

que componente eh aquele NEC que vc usou ali? eh uma sram? que capacidade tem?

os meus projetinhos estao empacados neste semestre, mas devo retomar com forca total no proximo! neste semestre estou muito preso ao trabalho e as disciplinas do mestrado, entao nao dah tempo para mais nada... o lado bom eh que estou hoje em dia trabalhando quase que exclusivamente em projetos com FPGAs e verilog. e o meu mestrado eh justamente sobre o uso de FPGAs como coprocessadores de rede! obviamente eu vou precisar de um processador principal para controle e a minha placa com o dual-68000 se encaixa bem, pois tem um bus facil de utilizar. o q preciso fazer nela eh comecar a pensar em expandir para pelo menos 2MB de flash e 2MB de sram, que eh o minimo necessario para rodar o uclinux. daih preciso montar uma placa de expansao com a FPGA e pelo menos dois PHYs ethernet e fechou!

os 68000 dae ficam apenas no gerenciamento das tabelas de roteamento e o trabalho pesado fica a cargo da FPGA.

comercialmente eh meio sem nexo o projeto, mas academicamente fica perfeito, pois creio que sera bem facil contrastar a diferenca de performance quando os 68000 fazem packet forward por software e quando a FPGA assume a tarefa por hardware... a minha expectativa eh inclusive bater alguns x86 maiores em algumas condicoes de trafego! hehehe

no futuro, quero ver se faco algo mais comercial com o MCF5270!

Bati muito a cabeça na parede...

http://img260.imageshack.us/img260/2266/cagadas.jpg

Agora ta quase, estou prototipando grande, espero amanha mesmo ver se 16 bits de cor serao o bastante e disso comecar a pensar em rotear essa tralha em uma placa soh ou sintetizar em algo compravel.

http://img338.imageshack.us/img338/1392/video16bp1.jpg

Como estao indo as coisa enigma e sam?

[enigmabox]

Mastk,
Tu fez as placas com resina fotosensivel ou sistema com toner? Já apanhei bastante com isso e os melhores resultados tive com a impressao a laser e transferencia termica.
Já usei até emulsão de silk de alta resolução(vermelha), a transferencia da imagem para placa ficou otima, mas na hora de corroer o acido atacou a emulsão silk...ai larguei de vez este processo.
Parece que tu ta usando sram de 1mb 70ns da NEC? Não é muito lenta pra resolução VGA?
Eu estou estudando alguns processadores de video. Achei muita informação de engenharia reversa do TMS9918/28 e Atari, vou bolar algo em CPLD com os XC9572xl que tenho aqui, usarei memoria de 16 bits tb.
Estou com outros trabalhos pendentes, mas logo vou começar a esquentar o ferro de solda novamente....

Marcelo,

Estou curioso pra ver tu ligar os 68K em paralelo, será que o ulinux gerencia 2 68K em paralelo como os do seu projeto?
Tem ideia de qual CI vai usar como ethernet?
Falando em coldfire, qual o MCF que pode ser facilmente comprado em pequenas quantidades no mercado local?

[msamsoniuk]

entao enigma, a implementacao do SMP eh meramente experimental e eu pretendo testar utilizando um RTOS q eu jah comecei a desenvolver ano passado para o HC908.

no caso do uclinux e linux, nunca ouvi falar de ninguem tentar utilizar em alguma placa com 680x0 em configuracao SMP, entao nao imagino em que estado estaria o suporte no kernel. de qq forma, se ficar complicado para ativar, eu tenho opcao de bootar as cpus de forma independente a partir da mesma flash, porem enderecando bancos diferentes de ram. efetivamente seriam como dois computadores totalmente independentes capazes de se comunicar de forma muito veloz atraves de queues em uma area compartilhada de memoria.

para a ethernet, eu pretendo colocar os controladores ethernet na FPGA, deixando apenas conexoes MII para PHYs DP83848 da national. na FPGA o trafego recebido dos controladores ethernet seria avaliado em tabelas de roteamento e atraves dessas tabelas seria feita a decisao de descartar ou encaminhar o pacote, sem intervencao dos processadores. se o pacote realmente fosse destinado aos processadores, ele iria acabar em uma queue onde estaria acessivel aos 68000 para processamento... soh espero conseguir fazer caber tudo isso em uma unica FPGA! hehehe

bom, sobre a disponibilidade do coldfire, acho que depende da quantidade. para poucas pecas, acho que na ordem, a primeira possibilidade eh conseguir amostras, a segunda eh comprar fora e a terceira eh comprar na farnell.

se a quantidade for acima de 100 pecas, vc encontra em distribuidores nacionais, como o grupo informat, por excelente preco.

a proposito, dando uma fucada na opencores.org, entre outros mais, achei estes projetos bem interessantes:

http://opencores.org/project,yavga
http://opencores.org/project,ethmac

e, imagina soh, tem ateh uns clones de 68k:

http://opencores.org/project,ao68000
http://opencores.org/project,ae68
http://opencores.org/project,k68
http://opencores.org/project,tg68

[enigmabox]

Marcelo,

Entendi seu Core 2 Due 68K
O jeito é fazer a placa e testar para ver como se comporta os dois 68K.

Já vi modulos ou circuitos integrados com todo o ckt Ethernet embutido, acessando como periferico da cpu, mas fica dificil achar algo pra vender aqui no Brasil.
Tambem saiu um projeto na Elektor, de uma placa ISA Ethernet sendo acessada por um AVR Atmega.
No caso do Coldfire, pensei primeiro em comprar na Farnell, para pequenas quantidades, apesar de ser mais caro, mas pelo menos pode ser comprado 1 peça.



Alguns links interessantes:

Receita basica de FPGA com 68K:
http://www.bitfellas.org/e107_plugins/c ... ontent.160

Este link é pro Mastk, Arcade com fpga:
http://www.fpgaarcade.com/

Outro site com varias informações de cpu no fpga:
http://www.fpgacpu.org/links.html

[msamsoniuk]

eh que a minha ideia para o mestrado eh justamente um switch melhorado: ao inves de fazer switch de pacotes em layer 2 pelo MAC address, ele faria roteamento em layer 3 pelo IP address. daih o pacote tem que ser inteiramente processado dentro da FPGA mesmo.

a ideia de fazer por hardware eh mostrar que um 68000 pode ter a mesma performance de um dual-xeon! e nao parece, mas sob trafego RTP intenso muitas maquinas parrudas simplesmente arriam fazendo forward de pacote, pq cada pacote que passa por um router precisa ter o ttl decrementado e o crc do header ip atualizado, motivo que performance em router nao se mede em bits/s, mas em pacotes/s.

de qq forma eu achei um projetinho bem joia em verilog para usar a ethernet diretamente e fazer alguns testes iniciais:

http://www.fpga4fun.com/10BASE-T0.html

muito simplao! o cara nem PHY usou! hehehe infelizmente soh roda a 10mbps full-duplex e usa dois clocks (20MHz para Tx e 48MHz para RX), mas francamente, para comecar acho que esta bom!

no fundo casa bem com minha ideia, pq a maioria dos pacotes vai entrar e sair quase que do mesmo jeito, passando de uma interface para outra e trocando apenas alguns campos no header ethernet e header IP (o q pretendo fazer por hardware). a vantagem de ter uma implementacao compacta eh que eu posso extender facil para mais portas!

[enigmabox]

Marcelo,

A melhor coisa que tu faz é projetar algo em Ethernet, estas porcarias de interface USB são um lixo, só dá problema.....
Interessante teu projeto de mestrado, se funcionar bem, informa a Intel pra jogar os Xeons pro lixo....
Como o sistema tem uma maior implementação via hardware(fpga) deve ficar mais rapido que via software.

[helton]

marcelo.
Um outro teste interessante, seria utilizar 2 RTL8019AS, e um FPGA no meio do caminho e desenvolver a parte de roteamento, apenas analisando os headers da camada 3.