68K ou coisa assim, again

[mastk]

Eh estou com um problema chato, pela falta de pinos do GP32 tive q multplexar alguns sinais e disso, o GP32 nao pode operar o BUS mantendo o RESET e HALT em baixo. Logo, tive a ideia de requisitar o BUS e soltar o 68K do reset e o 68K mantem seu BUS em TRI-STATE, mas nao do jeito que espero, nao esta ocorrendo um momento que o AS = 1 e BG = 1.

Estava tendendo, porem nao mais a colocar um FLASH de boot para o 68K, essa RAM que rolar de qlqr jeito

[msamsoniuk]

dah uma olhada nesse bichinho:



eu estou ainda montando a logica de controle, mas o processador de controle eh um 68HC908GR4 e tem bem poucos pinos de GPIO. de quebra, nao posso envolver BR e BG na jogada no momento, visto que quero futuramente expandir o sistema para dois 68000 em SMP e estes pinos serao cruciais para o funcionamento correto do sistema. a solucao que sobrou eh bolar um emulador de flash assincrona, tirando proveito do fato do bus do 68000 ser assincrono e inserir infinitos wait states por default. com isso, basta ir colocando os bytes no bus e respondendo com DTACK para o 68000 ir executando exatamente as instrucoes que o GR4 coloca no bus. estas instrucoes devem instruir o 68000 a fazer o download de um codigo na SRAM a partir do GR4, feito isso creio q eh possivel mudar o mapeamento das memorias no 68000 e resetar ele, de modo que ele boote magicamente pela sram com um codigo que ele mesmo colocou lah! quero restringir o acesso ao GR4 a um espaco bem pequeno de memoria, basicamente soh para ele ter acesso a UART e SPI do GR4, o resto ele puxa da sram e do backplane (quando eu construir um).

falta ainda ajustar alguns detalhes para o processo todo dar certo, mas no momento em que estiver ok espero que sobre espaco na placa para ativar o segundo 68000 em SMP. a ideia nesse caso eh um supervisor de bus muito simples que ativa o pino BR alternadamente de cada 68000 a cada acesso ao bus: quando um 68000 esta usando o bus, o outro esta em tri-state e vice-versa.

a ideia eh que ambos rodem exatamente o mesmo firmware e a diferenciacao entre eles pode ser feita atraves de semaforos controlados pela instrucao TAS, que possui um recurso de leitura-modificacao-escrita que bloqueia BR. desta forma os dois processadores podem rodar o mesmo software na mesma area de memoria compartilhada, mas atacar problemas diferentes paralelamente.

na teoria eh tudo legal, vamos ver se funciona!

[enigmabox]

Marcelo S.

Por cima tá bem bonita a placa, gostei do conceito se smp. Acho que por baixo , vai ter bastante fios!!!hehe. A ultima vez que tentei fazer isso foi com dois 8051, seguindo algumas ideias do databook da intel. Mas la tinha que trabalhar com interrupções pois não havia como colocar o 8051 em three-state, a menos que fosse usado varios 74ls244 e 245.
Como ja falei pro mastk, tô pensando na ideia de adotar un pcf8574 para ler memoria serial, falta estudar o protocolo I2C. Mas este boot minimo do 68k teria que ser carregado via eprom ou flash.

[msamsoniuk]

o codigo de boot inicial vai estar armazenado em um pequeno (bem pequeno) array no GR4, este codigo basicamente transfere bytes de uma pseudo-porta de IO do GR4 mapeada no IO do 68k para a SRAM. estes bytes por sua vez o GR4 vai puxar via SPI de uma memoria flash serial, de um cartao MMC ou de uma imagem S19 descarregada via porta serial.

em relacao ao SMP, acho q a logica vai ser bem simples mesmo. a estimativa eh que melhore em 100% a performance, visto q a media de tempo de execucao no 68000 eh de 10 clocks e ele usa o bus apenas 4 clocks. mas colocar 3 ou 4 processadores em SMP jah nao melhoraria nada.

[mastk]

Realmente show sam

O ganho de 100 eh quase garantido, negocio eh soft usando os dois cara...

Doido doido doido

[msamsoniuk]

pois eh, o conceito inicial parece ateh funcionar na simulacao:



usei um simples 74F74 para gerar dois sinais BR alternados que controlam o acesso de dois sub-sistemas digitais diferentes, que rodam inclusive com clocks diferentes. apos o reset um deles vai estar ativo e outro nao, o que estiver ativo vai forcar um processador a ficar com o bus em tri-state, esperando. o outro vai tomar o bus e fazer um acesso de dados (representado na simulacao pelo clock do sub-sistema), ativando AS. essa ativacao de AS clocka o 74F74 para o proximo estado e ele alterna BR para que o processador atual fique em tri-state e libere o bus para o outro processador. agora tem q ir refinando a ideia, pois na simulacao jah apareceu uma serie de "bugs" hehehe

[enigmabox]

Marcelo Samsoniuk

Com este sistema de flip-flop gerador de BR, acho que nao dá pra saber qual das duas CPU partira primeiro. Agora, se a cpu mais lenta não termina sua tarefa e é alternada pela cpu mais rapida, será que nao da problema não perde dados? Tem alguma interrupção no meio do caminho, ou somente pelos sinais de bus de controle dá tempo de alternar de uma para outra? Tem que fazer alguma logica extra para tratar os 3 pinos de controle de bus e o DTACK?
Tem muita diferença em usar o 68EC000 pelo 68HC000?

[msamsoniuk]

elas vao partir de forma aleatoria, mas uma opcao eh ligar o pino BR a um registro de IO, de modo que durante a leitura a cpu consegue determinar quem ela eh.

em relacao ao tempo de acesso no bus, isso eh assincrono mesmo, controlado por DTACK, que encerra o ciclo corrente e soh entao AS sobe, portanto BR nunca alterna antes de AS subir. claro que existem dois tempos: o tempo de ler a instrucao e acessar o bus e o proprio tempo de execucao da instrucao, q roda em background. em uma multiplicacao, 4 ciclos seriam gastos puxando a propria instrucao e entao mais 66 rodariam em background. existe margem para uma contencao de bus sim, mas nesse caso posso analisar uma forma de usar BG como uma sinalizacao extra para prevenir isso, no entando estou confiando que AS resolve o problema, vamos ver.

em relacao a interrupcao, ateh conversei com o mastk e nao parece muito trivial mesmo, entao vou manter as linhas de requisicao separadas e usar recurso de autovetor, assim cada 68000 pode atender 7 interrupcoes distintas sem envolver nenhuma sinalizacao extra no bus.

a logica de bus depende muito do device: para devices 68k-like eh relativamente simples e direto, pois eles tem um CS que pode ativado a partir de AS+74F138, um DS, um RW e geram DTACK no tempo correto. no caso de memorias, muito similar, exceto por DTACK nesse caso ser o proprio CS da memoria (supondo memorias com zero wait state).

sobre o HC000 vs EC000, a diferenca fundamental eh poder selecionar a largura de bus no boot para 8 ou 16 bits. no meu caso, estou usando 8 bits agora no inicio pq fica menos fios para puxar. quem sabe no futuro splito o bus para ter 16 bits, de qq forma no HC000 nao teria essa opcao. outra diferenca eh que o EC000 nao possui os sinais sincronos compativeis com o 6800, mas ninguem usa eles hoje em dia.

[enigmabox]

Marcelo Samsoniuk,

Agora entendi seu projeto....
Digo isso porque estou fazendo uma placa com mc68hc000 com os 16bits de dados, assim não dá pra fazer a jogada entre MPU e CPU em 8 bits no boot.
Na minha placa pensei em fazer de dois modos:usar eprom 16 bits como boot ou uma z80 ou MPU com varios 74ls374, 245( fazendo um ckt tree-state) para fazer o carregamento do Mpu ou z80 para a ram em 16 bits. Depois disso libera o 68k do boot.
Quando pensei em usar o PCF8574 I2C ligado a uma eeprom serial, nao tava dando certo, porque como vou carregar dados em 8 bits para uma para o barramento de 16?
Que posso tentar é usar um Atmega32 ou msp430f149, criando umas linhas de 16bits para dados e algumas para endereço, fazendo de modo similar a um simulador de rom.
Tambem estou prevendo em usar a fpu mc68882 como periferico, ela tem barramento de 32bits, mas pode ser dividido em duas palavras de 16bits.
E tambem usar futuramente um mc68hc681 como dual port serial, que conversa direto com o 68k.

[msamsoniuk]

exceto pelo trampo extra de passar fios, nao vejo pq nao fazer 16 bits!

note que o 68EC000 no meu caso esta usando um latch para o bus de dados (8 bits), mas poderia ser perfeitamente 16 ou 32 bits (para um 68HC000 ou mesmo um 68020), com o HC908 gravando de 8 em 8 bits (2 ou 4 passos). como o 68000 faz acesso assincrono, no momento em que ele endereca algo na area da flash-virtual (mapeado por um 74F138), temos um chip-select indicando ao HC908 que o 68000 quer algo e entao o 68000 para, esperando DTACK. o HC908 pode tranquilamente puxar isso de outro lugar (flash SPI ou MMC) e gravar o byte na latch (que podem ser varias, para formar um bus de dados de 8, 16 ou 32 bits de dados). soh depois que o HC908 ativar DTACK eh que o 68000 completa o ciclo.

bom, nesse estagio tem alguns passos que requerem atencao: se o 68000 fizer dois acessos seguidos na flash-virtual, o primeiro DTACK pode ficar pendurado e gerar um falso DTACK para o segundo acesso. pior, se o latch ficar aberto no bus, pode ter acessos erroneos. para prevenir isso o 68000 controla o tri-state da latch de acordo com o chip-select dessa flash virtual gerada pelo 74F138.

o problema do falso DTACK pode ser prevenido por um flip-flop: o HC908 arma DTACK e o 68000 finaliza o ciclo corrente retirando AS e desarmando DTACK no flip-flop. como DTACK eh um sinal comum no bus, um 74F125 pode ser utilizado para deixar ele em tri-state junto com o bus de dados quando o chip-select da flash virtual nao esta ativo.

sobre a fpu 68882, creio que ela usa dynamic resizing, portanto seria perfeitamente possivel mudar a largura do bus, porem o 68HC000 nao implementa o protocolo de coprocessador on-chip e vc precisaria emular.

dependendo do caso, um 68020 poderia ser mais vantagem, pois vc poderia operar com bus de 8 a 32 bits de largura, tornando o layout simples, porem ele jah tem o protocolo de coprocessador on-chip e fica infinitamente mais eficiente (inclusive, o 68020 usa a 68881 ou 68882 indistintamente).

bom, a 68681 jah usei em uma versao on-chip no 68340 e eh bem pratica de usar, acho que vc nao vai ter problemas. o unico detalhe eh aquele referente ao uso comum do DTACK, principalmente quando se mistura devices que geram e outros que nao geram DTACK: em dispositivos q nao geram DTACK eh uma boa colocar um 74F125 para deixar o sinal em tri-state quando aquele periferico especifico nao estiver em uso no momento, para nao atrapalhar o funcionamento dos que geram DTACK, como a 68681 e 68882.

corrigindo um post anterior: o 74F74 possui reset, portando apos o reset dos processadores eh possivel fixar a montagem de modo que a cpu #0 roda as mesmas instrucoes antes da cpu #1. uma das primeiras instrucoes seria a TAS, para testar um flag e setar usando ciclo indivisivel, com isso a cpu #0 pode continuar executando o FW enquanto a cpu #1 fica presa em um loop infinito, aguardando a descarga do OS. quando o OS estiver disponivel, a cpu #0 remove o flag de bloqueio e ambas partem para a execucao paralela do OS, onde outro mecanismo similar ira escalonar processos diferentes para as diferentes cpus.

um outro lance interessante eh que eu nao leio o bus de enderecos no HC908, simplesmente jogo as instrucoes em sequencia. isso significa q eu imagino que o 68k esta em determinado ponto e jogo as instrucoes, mas por outro lado nao posso habilitar interrupcoes neste momento, pq eh dificil prever o que ele vai pedir para a area da flash. nesse caso o lance eh descarregar todo o FW p/ a sram e entao usar o truque de overlay, invertendo os mapas de memoria da flash e da sram, de modo que a tabela de vetores e todo o FW descarregado ficam em sram, onde os enderecos funcionam corretamente. o mapa da flash-virtual, nesse caso, dae fica restrita a funcoes basicas de IO (SPI e UART), com uns poucos enderecos de IO realmente mapeados.

uma outra ideia interessante q eu vi agora a pouco: quando o 68000 boota, ele puxa sucessivamente o SP e PC, entao comeca a ler instrucoes a partir do PC. a minha ideia era ir fornecendo instrucoes para o 68000 para ele mesmo gravar um FW na sram, mas vi uma ideia mais interessante: fornecer para ele o PC e SP zerados, de modo que apos isso ele comeca a rodar o PC em 0 e vai aumentando o PC de 2 em 2. se eu fornecer 128 mil NOPs para ele, isso equivale a ele fazer o PC incrementar de 0 a 262144.

a cada ciclo ele coloca o endereco no bus, deixa o bus de dados como leitura e aguarda DTACK. a jogada seria colocar o que se deseja escrever naquele endereco na sram e gerar um strobe de escrita na memoria, entao colocar um NOP no bus e responder DTACK. assim o 68000 cuida de incrementar os enderecos e o HC908 de escrever bytes na sram e gerar um NOP para ir ao proximo endereco, hehehe parece uma ideia relativamente bem eficiente!

[enigmabox]

Marcelo Samsoniuk,

Tú ta fazendo um projeto bem interessante. Por enquanto nao me arriscarei em fazer SMP. Pensei em usar o MC68882, porque trabalho com umas placas industriais com 68K quem vem assim. Mas para entender como funciona.
Na farnell consigo o mc68hc000 facil assim como a FPU. Agora será que no centro de São Paulo, posso conseguir o MC68020 ou MC68040 que ja tem a FPU interna?
Conhece algum fornecedor para pequenas quantidades?
Memoria ram estou usando a HM628512 e eprom 27c512. Poderia usar a flash 29f040 mas meu velho gravador nao suporta.
Verdade, fazendo o reset do ls74, sempre dá pra saber quem é o que parte primeiro.
Na placa industrial que conheço, o bus de dados da FPU tá ligado D0-D15 e D0-15 no D0-D31 do MC68882, e tem CS pra ativá-la, funcionando assim como periferico.
Acho que o mais pratico no seu caso é jogar tudo na Ram, direcionar o 68K para lá e partir após o carregamento e usar alguns endereços da MPU como periferico, assim não complica muito.
Como GlueLogic para o 68K pretendo usar o XC9572xl, que tem compatibilidade com linhas de 3,3V e 5V. Será que funciona bem em 5V ou tem que usar outro CPLD para 5V?

[msamsoniuk]

acho que ateh consegue sim, o mastk comentou uma vez sobre uns 68020 ou 68030 para vender meio baratinhos. o 68040 acho que eh mais raro achar, principalmente pq a maioria dos macintoshes q vc encontra na sucata usam a versao sem FPU. se nao me falha a memoria, o 68040 tem um bus um pouco mais complexo: funciona de forma sincrona e nao permite modificar a largura de 32 bits.

a 68882 se conecta como periferico no caso do 68000 q nao suporta extesao para coprocessador. as instrucoes do coprocessador no 68000 caem direto naquela excessao de linha-F nao implementada (dah para emular por lah hehehe). no caso do 68020 ou 68030, as instrucoes da linha-F passam de forma transparente para o coprocessador, de modo que vc pode ter coisas no seu asm como "fsqrt". como periferico no 68000 fica mais moroso.

no caso do 68040, tem a vantagem da fpu integrada ser mais veloz, mas ela nao eh uma fpu totalmente full e requer a instalacao de um codigo de emulacao da 68882. no 68060 me parece que tambem eh assim.

sobre os 3.3V e 5V, estes dias eu testei um coldfire em um sistema com flash e sdram rodando tudo a 3.3V com um periferico direto no bus rodando a 5V e nada de problematico aconteceu. nao sei sobre a confiabilidade a longo prazo, mas ateh funciona meio tranquilo, suponho que a maioria dos componentes tolera 5V com corrente baixa no bus.

[enigmabox]

Marcelo Samsoniuk,

Bom..em mãos tenho o MC68hc000, MC68882, MC68hc681 e o XC9572xl. Vou terminar de desenhar no Kicad e fazer a placa com saida para flat-cable de 60 pinos, assim posso ligar outras em paralelo, mas nesta, não usarei o MC68882. Por enquanto quero só usar o MC68hc000, porque com a FPU como periferico vai enrolar a coisa....
Se eu conseguir um MC68020 ou MC68030 faço a placa com a FPU, vou falar com o Mastk.
No datasheet da Xilinx diz que é compativel, assim vou montar e ver se funciona o XC9572xl, pois economiza espaço dos componentes na placa.

[mastk]

O 68030 encotrava com relativa facilidade.

Sim, num start-up o ideal, ao me ver é só uma CPU rodando e ficar trocando uma com a outra após o boot, porem, como disse, pensado em duas CPU rodando o msm codigo, para cada instrução realizada, seus registradores internos terão seu conteudo alterado, digamos o proprio SR a instrução seguinte se for realizada por outra CPU, fará q seu programa fique louco, nisso seria interresante, por exemplo no caso dos x86, vc ter cada CPU rodando codigos diferente, ou treços diferentes, assim ganha-se o processamento. Porem vem a dor de cabeça de controlar os ninchos do programas, nessa condição a segmentação dos x86 parece otima ideia...

O controle de arbitragem só com BR e BG e não dependete do AS, bem melhor.

[msamsoniuk]

pois eh, tenho q pensar em uma solucao.

eu gostaria de manter elas rodando o mais simetricamente possivel, mas no caso do FW nao haveria vantagem, visto que o trabalho consiste apenas em descarregar o SO para a sram. como nesse estagio as instrucoes sao supridas pelo HC908, poderia simplesmente fornecer NOPs para a cpu #1, assim ela fica atoa e a cpu #0 faz o trabalho. descarregada imagem do SO para a sram eu inverto os bancos de memoria e, nesse instante, ambas as cpus devem disparar sozinhas daquele ponto de entrada jah rodando na sram, visto que a operacao na sram nao eh supervisionada pelo HC908.

no SO as coisas ficam mais simples, basta criar semaforos especiais para SMP e as cpus rapidamente comecam a rodar tarefas diferentes. entao nao precisa se preocupar em fazer programas com suporte a paralelismo, basta o sistema ser multi-tarefa e o paralelismo eh naturalmente aproveitado!

bom, vamos ver como o sistema se comporta.