68K ou coisa assim, again

[msamsoniuk]

hehehe usb soh se for de ouro, dae eu derreto e vendo! obviamente quando se fala em pesquisas serias na area de telecom, ethernet eh o primeiro nome que aparece e eh muito mais facil de trabalhar, pq separa toda a comunicacao em diversos layers diferentes e eu soh vou precisar efetivamente mexer no cabecalho de layer 3

bom, sobre os controladores externos, eu estou deixando como ultima opcao caso implementar um controlador ethernet se mostre muito complexo! mas ateh o momento nao detectei problemas com isso. a vantagem de ter tudo interno e apenas conectar os PHYs eh que eu troco o bus ISA de 16 bits pseudo-sincrono entre 8 e 16MHz por um bus MII de 4 bits sincrono com 25MHz.

uma diferenca grande eh que no caso de controladores externos eu teria que esperar os frames serem integralmente recebidos. no caso de controladores internos, eu consigo comecar a rotear o frame pela interface de saida antes mesmo de ter terminado de receber ele na interface de entrada... coisa que nem um quad-xeon sabe fazer!

[enigmabox]

Marcelo,

Falando de Ethernet, em ambito industrial, vc teria algum comparativo em relação a Can-Bus, referente a efeitos de EMI?
Dá até raiva usar USB, toda vez que conecto meu cel motorola no PC via USB, o Ruindows as vezes perde a configuração e mostra como dispositivo desconhecido. Será que o USB é invenção dos portugueses que usam memória de vaga lembrança?
Qual FPGA tu pensa em usar para o prototipo, algum da Xilinx?
Pelo que vc diz neste copiar, modificar e montar real time, a montagem dos frames via hardware deve ficar bem rapido, sem o delay de perifericos externos, que tem que espera montar, modificar e enviar...
Seria dificil no lugar de uma interface ethernet ISA usar uma PCI, tem que fazer muita conversão, além de usar clock mais alto?

[msamsoniuk]

infelizmente nao tenho nenhuma informacao de ethernet vs canbus...

a fpga que eu vou usar sera uma spartan-3e da xilinx, pq realmente acho que eles tem a melhor ferramenta para verilog. soh nao decidi se sera o modelo de 100 pinos mais barato ou o de 144. em principio sao os dois encapsulamentos nao-BGA disponiveis e para estes encapsulamentos eu tenho opcao de componentes com 100 mil, 250 mil e 500 mil gates.

quanto a interface pci, melhora bastante a banda se comparado com ISA, pois vc dobra a largura do bus e quadriplica o clock. porem o bus de dados e enderecos passa a ser multiplexado no tempo, de modo que vc soh ganha o pico de performance se implementar acessos em burst. o ruim eh que tudo isso vai comendo muita logica e pinos!

me parece que a melhor opcao para o futuro eh pci-express: a maioria dos processadores high-end jah suporta e a maioria das fpgas novas esta oferecendo blocos com implementacao direta em hardware, ao que parece sem custo... a diferenca eh brutal, pq pci-express na pratica eh uma serial capaz de que operar a 2.5Gbit/s!

mas por hora vou ter q manter um peh no bus ISA tb... ao menos em parte, pq na pratica a interface entre os 68000 e a FPGA sera via barramento VME assincrono com DTACK... mas a FPGA eh realmente muito rapida: em um design recente meu o limite de operacao estimado pelo software para o acesso ao bus eh da ordem de 170MHz!

e uma dica que eu andei vendo em foruns de amiga: a galera que esta fazendo minimigas em casa (amigas simulados com FPGAs) costuma usar o 68SEC000 de 20MHz e andaram experimentando overclockar o bicho... parece q a freescale andou reduzindo o tamanho do chip e nao avisou para ninguem: varias pessoas conseguiram chegar aos 50MHz!

daqui a pouco vai ter 68000 batendo arm! hahaha

[enigmabox]

Marcelo,

Sobre a EMI, vou ver se consigo algo, digo isso porque ambas as interfaces em ambiente industrial, dependendo da configuração, instalação e EMI dá problemas. Parece que o CanBus é um pouco mais confiavel neste ambiente, mas não tem todas as facilidades do Ethernet.
Tb pensei em comprar um FPGA da Xilinx pra testar, escolho por ter software gratuito, dependendo da capacidade e por ja ter algum conhecimento em CPLD da Xilinx.
Como tu vai carregar o codigo no FPGA, vai ser via flash, via 68K ou vai colocar algum MCU pra fazer o upload pro FPGA?
Estes novos 68K devem utilizar tecnologia recente de construção, por isso dá pra dar um overclock. Mesma as versões antigas do 68K dava pra subir o clock, mas era pouca coisa.
ARM estudei, mas desisti de fazer algo, tem muita opção de MCU, mas não seguem um padrão, toda hora estão mudando algo, criando incompatibilidades. O modo de programar do ARM me lembra as cpus antigas 6502, quer dizer não evoluiram nada com o tempo. Prefiro tecnologia tradicional CISC da Motorola que ja tem mais de 30 anos. Pelo menos vc fazendo um projeto com 68K ou coldfire, tu teras componentes e suporte por muito tempo.

[msamsoniuk]

na verdade tem umas solucoes mais robustas para ethernet sim!

note que a maioria dos conectores RJ45 femea blindados possuem uma serie de recortes de modo que alguns dentes de metal costumam encostar no chassis metalico da maquina e ao mesmo tempo possuem dois dentes nas lateriais internas, de modo q fazer contato com um conector RJ45 macho blindado:



essa blindagem, por sua vez, esta conectado aquela folha de blindagem que acompanha toda a extensao do cabo STP (na pratica, eh um UTP comum com blindagem), ateh chegar no outro extremo, onde se conecta internamente a outro conector RJ45 macho blindado, por sua vez fechando contato com um RJ45 femea blindado que esta conectado ao outro chassis.

assim, em toda a extensao do cabo ele praticamente nao fica nenhum momento exposto. outra solucao seria usar ethernet com fibra optica!

sobre a FPGA, eu ainda vou dar uma boa estudada na melhor forma, mas de qq forma eu vou ter q bolar uma forma dela bootar tanto sozinha quanto pelo 68000... ocorre q pelo jeito nao vou escapar de ter q fazer uma PCB, mas fazer poucas unidades fica caro! daih a ideia eh fazer de modo que depois eu possa vender o excedente na forma de kit de desenvolvimento para FPGA... colocar um MCU junto seria uma boa ideia hein! algo simples, como um HC908QY4 jah resolve, tipo o cara abre o hyperterminal, conecta a 9600 bps e envia o bitstream da FPGA via xmodem para o mcu e ele grava na eeprom de boot da FPGA e bingo!

no meu caso, nao montaria o MCU nem a eeprom, ao inves disso plugaria esse modulo numa VME16 com os conectores RJ45 e a fiacao que conecta ao backplane, de onde outra VME16 com os 68000 comandaria o esquema... eh uma ideia!

e pior que essa historia ae de 68SEC000 rodando a 50MHz jah dah outras ideias hehehe se o dual-68000 de 16MHz funcionar, acho que vou tentar um quad-68SEC000 overclockado a 50MHz! putz! dae sim o fabim vai ficar invejas, pq os ARMs dele lah nao sabem fazer SMP ainda! hehehe

[enigmabox]

Marcelo,

Eu já uso este sistema de Ethernet blindado, tem algumas instalações que eu usei até uma caixinha da Siemens metalica dos dois lados do cabo ethernet blindado, aterrando-o na carcaça da máquina.
Em alguns clientes, principalmente quando o cabo passa muito perto de inversores de motor, as vezes a comunicação falha e com o tempo queima a interface ou o circuito integrado que faz a Ethernet dentro do PC industrial.... Pode ser algum erro de projeto da motherboard do micro industrial, porque com versões mais antigas de motherboard o problema não aparece.
É, o caminho é pela fibra optica que vc falou.... Mas vai depender dos cabeça de bagre dos engenheiros lá da fábrica... Como são italianos, duvido que vão mudar algo...
Ficaria bom colocando o 68hc08 que tu tem ai pra carregar o codigo no FPGA, não sei o espaço ocupado pelo codigo do FPGA, mas poderia gravar na flash do 68hc08, todo o boot do sistema o 68hc08 carrega o FPGA.
Como nunca vi 6502 da mostek em SMP, o ARM também não vai funcionar.....
Só botar um powerpc ou mc68060 no projeto, que já deixa os ARM lá comendo poeira. Nem precisa tanto, usar um Coldfire com clock um pouquinho mais alto que já resolve o problema.

[msamsoniuk]

os HC908 que eu utilizo estao muito obsoletos e ocupam muito espaco nas PCBs! hehehe na verdade jah faz tempo que ando pensando em colocar este outro componente mais moderno em todos os meus kits de desenvolvimento:

http://www.freescale.com/webapp/sps/sit ... code=S08JS

a vantagem obvia eh que funciona em qq notebook sem precisar de porta serial, ao mesmo tempo que eh uma solucao compacta e barata, pois nao precisa de BDM para programar (ele se autoprograma a partir da USB), nem tao pouco fonte de alimentacao para o kit. o q me assusta eh justamente a questao de device driver! uma possibilidade que ando pensando bastante eh mapear uma eeprom como se fosse um dispositivo de armazenamento, daih para gravar o bitstream seria questao apenas de copiar o arquivo para o drive da eeprom e entao resetar a FPGA para ela bootar a partir da eeprom.

seria o ideal e creio que funcionaria em qq sistema operacional... soh que no momento eu ainda nao tenho conhecimentos de USB para tal.

sobre o SMP, o q restringe a possibilidade ou nao eh existir instrucao com funcionalidade de read-modify-write indivisivel. isso eh necessario justamente para se construir semaforos que funcionem em ambiente SMP. no caso do 68000, isso eh feito pela instrucao TAS, que testa um semaforo e atribui um se ele estiver livre. eh facil perceber que se varios processadores estiverem rodando a instrucao TAS ao mesmo tempo, o primeiro que chegar vai ler o semaforo como livre e setar o valor 1. como a operacao eh indivisivel, entre ler e setar um valor nao existe margem para que outro processador leia zero tambem e pensei, por engano, que o semaforo esta livre.

conseguindo criar semaforos deste tipo, vc coloca um destes para criar caminhos de execucao do tipo "passa um somente" em areas criticas, por exemplo, no escalonamento de processos, pois o mesmo processo nao pode ser executado em dois processadores ao mesmo tempo.

[enigmabox]

Uma segunda opção para o HC908, verificando no site da Freescale e Farnell seria o MCF51JM128VLH ou MCF51QE128CLH, que possuem mais memoria e recursos, mas muda a arquitetura para coldfire v1. Pelo menos em questão de preço é um pouquinho mais caro que o MC9S08JS.
Outra coisa interessante é pegar um Spartan mais potente e colocar nucleos de 68K em paralelo dentro do fpga, ai ficaria interessante.....
Será que a versão gratuita do ISE Xilinx tem alguma limitação para trabalhar com FPGA?

[msamsoniuk]

acho que o coldfire v1 seria uma boa opcao sim... eu vi que existem bibliotecas para fazer ele ser reconhecido como dispositivo de armazenamento em massa e acho que isso seria o ideal, pq daih funciona em qq sistema operacional sem device driver e jah resolveria os dramas que aparecem com interfaces USB.

sobre a spartan, estou pensando em usar o encapsulamento TQFP-100, que suporta 3 densidades diferentes, com 100, 250 e 500 mil gates e permite usar 66 pinos para aplicacao. como a USB fornece 5V, precisaria de um regulador para baixar para 3.3V e tambem 1.2V para o core, talvez um par de conectores de 40 pinos para todos os sinais e alimentacao, daih fechou. para a minha aplicacao eu nao incluiria o coldfire, pq a FPGA seria programada via backplane. tambem incluiria os footprints para uma memoria SRAM e talvez um par de PHYs ethernet e seus conectores. assim teria uma placa capaz de atender minhas necessidades e ao mesmo tempo servir como kit de desenvolvimento para vender, fazer pesquisas e utilizar em cursos.

e tem realmente muitas aplicacoes interessantes!

as spartans possuem conjuntos de multiplicadores 18x18 e bancos de memoria sincrona. adicionando um acumulador temos uma unidade MAC capaz de operar com clocks relativamente bons. o datasheet indica performance de ateh 240MHz trabalhando com pipelines e, multiplicando pelo numero de unidades paralelas, teriamos 960 MMAC/s jah no modelo mais simples de FPGA. para o modelo intermediario essa performance teoricamente aumentaria para 2880 MMAC/s e chegaria a 4800 MMAC/s no modelo maior... e fim! para ir acima disso, teria que passar para componentes com encapsulamento BGA. em funcao do encapsulamento, seria possivel tambem usar 7 linhas seriais diferenciais que podem chegar a 622Mbit/s.

mas daih depende da imaginacao do desenvolvedor.

sobre colocar o 68000 na FPGA, eu testei uma implementacao em VHDL e pareceu estar ok, porem utilizou o modelo de maior capacidade, consumindo por baixo uns 300 mil gates. obviamente isso eh bem acima do consumo do componente verdadeiro, que requer 70 mil gates e muito acima de um core coldfire tipico, com 25 mil gates. se a proporcao for a mesma, eu diria que um coldfire em verilog deveria consumir uns 100 mil gates ou menos, pois a diferenca entre otimizar para a arquitetura da FPGA e escrever genericamente eh realmente muito grande.

de qq forma, com 100 mil gates jah daria para colocar 4 cores no modelo maior e ainda sobraria espaco para perifericos. uma outra abordagem seria trabalhar em um core unico, mas criar extensoes de alta performance. por exemplo, a arquitetura do 68000 define 8 registros para uso geral. se implementar estes registros como ALUs independentes, vc cria uma extensao vetorial capaz de multiplicar a performance por 8. rodando a 125MHz, vc conseguiria atingir 1 bilhao de operacoes por segundo com o modelo de 250 mil gates.

claro, a organizacao particular dos barramentos e a forma das instrucoes rodarem em um processador cria uma serie de restricoes que impacta a performance quando comparado com uma solucao dedicada que roda deterministicamente, entao nao sei se ah vantagem. na pratica seria soh para deixar os caras que curtem ARM com dor de cotovelo! hehehe

sobre o ISE webpack, em principio vc faz tudo sim.

o suporte dele para FPGAs e CPLDs eh suficiente para vc sintetizar, simular e gravar. os pacotes mais avancados e pagos possuem simuladores melhores, recursos de debug em realtime para usar na FPGA e acesso a IPs de modulos pre-fabricados. mas se for ver o preco, o ISE webpack jah faz praticamente tudo.

[enigmabox]

Marcelo e Mastk,

Tô pensando em comprar um coldfire V1(MCF51JM128) e um coldfire V2(MCF5270) e um Spartan FPGA da Xilinx na Farnell, já que vcs são crânios nestes MCUs, pergunta de leigo:
O CW tem alguma limitação em questão de tamanho do codigo fonte e codigo assembler gerado? Há outra opção de compilador alem do GW e GCC no linux?
Como vcs estão gravando o codigo no coldifire, tem alguma interface ou via serial?

[mastk]

Sim 64K de codigo para o V1, para o V2 o limite eh maior mas nao consigo uma licensa que nao expire.
Sim ha, mas nao tao bom quanto o Easy68K (que sou mais ele...).
Fiz um programador serial, e coloco na placa. Mas isso soh para fazer um bootloader.

[enigmabox]

Mastk,

O Easy68k eu uso tb com o mc68030, assim como o compilador AS. Também consegui gerar codigo com o GCC do linux para 68K, tinha duvida apenas para passar o codigo para o MCU Coldfire, mas como dá para transferir via serial, ai fica facil.
Já baixei o CW pra estudar, mas como é limitado não pretendo utilizar esta ferramenta para Coldfire no futuro.
Mas na media dos programas que vc esta fazendo, vc está passando dos 64K?

[msamsoniuk]

no fundo tem algumas complicacoes que eu visualizei...

no 68000 eu estou usando um HC908 como supervisor: ele reseta o 68000 e sabe o que o 68000 vai ler em sequencia... no caso, a descida de AS eh detectado pelo HC908, que estima em qual endereco o 68000 deve estar, coloca um valor diferente no bus de dados e clocka um flip-flop com o valor de DTACK. o 68000 recebe o valor da instrucao e sobe AS, resetando o flip-flop e evitando um falso DTACK no ciclo que se segue.

a ideia de estimar o endereco em que o 68000 elimina a necessidade de ler o endereco e procurar. basta fornecer as instrucoes em sequencia e o 68000 ira executar uma a uma. programando um registro de enderecos para apontar para a SRAM e fornecendo a instrucao correta (MOVE #VALOR,A0@+) alternada com dados, eh possivel usar o 68000 como uma especie de controlador de DMA de 16 bits.

para mim, esse eh o caminho de menor esforco no 68000.

jah no MCF5270 eu nao consigo fazer o mesmo esquema, pois ele jah inclui toda a logica de chip-selects e wait-states de modo que nao requer nenhum circuito externo... isso facilita, mas por outro lado impede o truque de fornecer instrucoes arbitrarias pelo barramento. ao mesmo tempo, nao encontrei no datasheet nenhuma forma de colcocar os barramentos em tri-state.

na pratica a melhor forma seria fazer como esta no kit da netburner com o MCF5270: colocar uma flash PLCC, facil de tirar e colocar, para usar um gravador externo. a outra opcao eh BDM, onde as opcoes sao gastar uma fortuna em um ou montar. ambas opcoes ruins, pq mesmo para montar dah um certo trampo!

por sinal, estou pensando nessa alternativa tambem para a FPGA: pq ter um microcontrolador se a FPGA pode se auto-programar? bastaria colocar duas flashes SPI, uma delas com um firmware de programacao que sobe uma UART com um adaptador USB/serial para download pela serial e que eh gravado na outra, de modo que o usuario pode bootar por uma das duas flashes apertando um botao na placa.

acho que na reta final com isso ae tem ainda as opcoes de usar o JS16 ou um HC908 mesmo... no fundo tem infinitos caminhos! o negocio eh ir refinando ateh achar o de menor esforco! hehehe

quanto ao compilador, soh tenho usado gcc mesmo... eh gratis, nao tem limites e praticamente todos os fabricantes utilizam! e uma dica boa, para debugar, eh usar o simulador de 68k/coldfire da lauterbach:

http://www.lauterbach.com/frames.html?dwnload.html

o software de debug deles trabalha bem com gcc e eles tambem possuem excelentes equipamentos para BDM, cujo software eh identico ao do simulador, porem custam uma pequena fortuna!

na pior das hipoteses, tambem, vc empresta um BDM ou usa um no trampo... mas, cuidado com o coldfire v1: vc soh programa ele via BDM, porem ele usa um BDM diferente dos coldfires v2! eu por exemplo, nao tenho isso no trampo e muito menos tenho de quem emprestar, o que me faz ficar meio com receio de trocar a simplicidade do HC908 por um coldfire v1 e depois me lascar com esse negocio de BDM!

[enigmabox]

Marcelo,
Então no seu projeto, vc fez e provou que o hc908 é mais poderoso que o 68K...O hc908 manda no 68K e este tem que cumprir a tarefa como um zumbi....
Com esta ideia tive outra.....
Para deixar o sistema bem versatil e rapido poderia ter um microcontrolador que faria a tarefa de periferico inteligente, isto é, interfaceando entre PC e a placa com 2 Fpga.
O microcontrolador poderia carregar o codigo para um FPGA com função de cpu, como um 68K sintetizado. Teriamos também um segundo fpga, que poderia tambem ser carregado por este microcontrolador, mas este segundo Fpga, teria a função de periferico. Neste Fpga periferico seria incorporado a ram e saidas serial, usb, ethernet e algum barramento de expansão para o sistema.
Este seria um sistema bem rapido e veloz podendo talvez atingir os 200mhz de clk, mas ao mesmo tempo caro. Pelo menos temos a facilidade das ferramentas da Xilinx, como vc disse, no software gratuito, nao teria limite para tamanho de dados e componente.
Como ocorre com os MCUs Coldfires V1, mudam a configuração dos perifericos e nucleos, conforme modelo, mas fica tudo interno, nao permitindo um acrescimo de ram, por exemplo.
Para projetar algo com estes MCU tem que selecionar bem o tipo de coldfire para que suporte a aplicação desejada e de acordo com projeto teria que gastar uma grana alta com as ferramentas sem limitações.
Pra quem vem do hc08 um passo sem muita modificação é o MCF51JM128 que possui os mesmos perifericos. Este MCU seria a transição entre 8 e 32 bits, requerendo pouca modificação no software.
Dos Coldfires que parecem mais genericos e expansiveis pelo que pude verificar é o MCF5270 que vcs estão usando.
Não conheço bem a linha atual do PowerPc, será que se comporta mais como uma CPU convencional ou está entre o meio termo entre CPU e MCU? O problema é trabalhar com BGA que não é meu caminho e nem sei se pode ser vendido fora dos EUA.......
Sei que a receita basica que muitos usam em prototipos, deixando o sistema bem versatil, por exemplo, é usar um 68K de fabricação atual, que permita um overclock + FPGA + Memoria + barramento.
Não sei qual seria o caminho mais facil para todos, cada um começou por um caminho, porque para mim por ex. o mais facil é gravar as eproms ou flash do 68k, do que partir para um sistema MCU+68K, porque já tenho todas as ferramentas.
Mas o que acho interessante em um MCU carregando um 68K, é a quantidade interna da flash do MCU, poderia colocar nesta flash de 512kb, por exemplo, o codigo ou um monitor para o 68k, que de outra forma estaria gravado em uma flash ou eprom para este 68K.
Assim eliminaria, a gravação de uma eprom ou flash no sistema. Como vc já está fazendo em seu projeto.
Outra coisa interessante é ao inves de carregar diretamente do PC para o MCU, é usar um cartão de memoria SD, se o MCU permitir. Assim o codigo executavel do 68K estaria nesta cartão. E os dados passados ao 68K atraves do MCU.
Mastk, o que vc acha... tem alguma ideia?

[mastk]

Depende do objetivo enigma, no momento meu objetivo foi vencer o problema de galinha, tendo uma pequena flash soquetada para um boot e receber o codigo externamente seja Sd ou serial mas digo isso para o mcf5270 que era quase todo novidade para mim.

Dos coldfire V1, uso eles e recomento, versateis e extremamente faceis de usar. 64K da para fazer um estrago bom na versao gratuita.

Quanto a FPGAs sao bons mas tem seu custo, eh precisso avaliar um que seja facil de comprar e tenha recursos o bastante, sintezir um pico-blazer que eh uma CPU tao ridicula quanto um PIC querer uma quantidade razoavel de recursos, uma CPU de verdade entao pode nao caber.

Vale lembrar o nucleo V1 pode ser licenseado e sintetizado a gosto do fregues.
http://www.altera.com/products/ip/proce ... re-v1.html