Bora montar um?

[enigmabox]

Nao sei qual encapsulamento vc comprou, mas tenho as xc9572xl aqui e funcionam bem na jtag paralela, estao compativeis de 2,5V a 5V.
A xc9572 só trabalha em 5V mas nao tem a mesma pinagem que a xc9572xl?
Logo vou criar coragem e botar pra funcionar a fpga, o que falta é tempo.....

[mastk]

Nao Enigma, as XC9572XL funcionam OK, as nao XL, que nao funcionam, mas tudo bem, elas custam o dobro e ficar fazendo troca-troca de dispositivo no ISE nao é legal.

Das quatro CPLDs que comprei, queimei as quatro, por algum motivo estranho, se deixo o CE e WE da RAM em tri-state, a CPLD queima na hora.

Fazendo assim:

WE <- '0'

Funciona, agora:

WE <- 'Z'

Diga adeus.

Como ja tenho video na tela, terminei o programa que converte BMP para um forma mais simples de li dar, estou feliz, mas pensado no porque isso aconteceu.

E acima de tudo, graças a deus que foi com o CPLD, se fosse com as FPGAs ai sim, estaria lascado.

[mastk]

[msamsoniuk]

uma vez eu troquei ideia com um FAE da xilinx sobre a queima de alguns componentes e, depois de algumas pesquisas, ele me contou que os componentes deles nao toleram tensoes nos pinos que estejam acima de VCC ou abaixo de GND. nesta condicao os pinos ficam sujeitos a uma corrente elevada por um caminho que nao preve esse tipo de corrente e a logica de controle do pino acaba sendo danificada. obviamente isso soh ocorre quando os pinos estao em tri-state ou como input conectados a outros dispositivos. quando eles estao como output, estao conectados ao VCC ou GND atraves de caminhos capazes de suportar bastante corrente. e se nao estiverem conectados a nada, tambem nao tem como o problema ocorrer. entao, o lance eh dar uma revisada na alimentacao da CPLD para garantir que o VCC e GND dela sao compativeis com o resto do sistema. uma dica que o cara me deu foi adicionar resistores em serie nas linhas que vao ficar como input ou tri-state, de modo a limitar a corrente que passa pelo pino caso a tensao fique muito fora do VCC e GND do componente.

[mastk]

todo o sistema esta em 5V, tirando o CPLD que esta em 3,3V, entre tanto, no datasheet do mesmo, informa que eh tolerado 5V nos IOs.
Ja tenho uma serie de pinos que estao recebendo sinais de 5V sem problemas, em TriState a coisa talvez mude.

[mastk]

Acho VHDL, uma liguagem muito simples e clara. Ate o presente momento tudo o que fiz, com um exemplo e dedução, porem, depois dessa tragedia, quero realmente saber mais se o que penso que estou descrevendo é de fato que obtenho no resultado da sintetização, ia comprar o art of computer programming, mas adiei para pegar esse:

[/img]

[msamsoniuk]

eu dei uma olhada rapida no datasheet dessa CPLD e o componente tolera um range de -0.5 a 5.5V ou uma corrente limitada em 10mA. o que pode estar ocorrendo eh que tem glitches na sua alimentacao ou sinais que estao saindo fora do range de operacao. colocar resistores em serie nos pinos que ficam em input/tri-state deve limitar a corrente nessas condicoes e ajudar a prevenir o problema.

[msamsoniuk]

eu acho verilog muito melhor que VHDL... mas pode ser apenas opiniao pessoal. acho que o codigo em verilog eh mais low-level e reflete melhor o mundo real, no sentido que vc trabalha diretamente com flip-flops e fios. de qq forma, o esquema eh vc ir escrevendo e conferindo o resultado com a opcao 'view RTL schematic'. olha o impacto que tem usar a sintaxe correta... por exemplo:

Código: Selecionar todos

module filter(CLK, RESET, ADDR, DATA_X, DATA_K, DATA_Y)

  input CLK;
  input RESET;
  input [4:0] ADDR;
  input [15:0] DATA_X; // dados X
  input [15:0] DATA_K; // coeficiente K
  output [15:0] DATA_Y; // saida Y

  reg [31:0] A [0:31]; // 32x acumuladores de 32 bits

  assign DATA_Y = A[ADDR][31:16];

  always@(posedge CLK)
  begin
    if(RESET)
      A[ADDR] <= 0;
    else
      A[ADDR] <= A[ADDR] + DATA_K * DATA_X;
  end

endmodule


basicamente um filtrinho tipo y += k*x, soh que multiplexado no tempo, ou seja, tem capacidade para 32 canais independentes. quando vc manda gerar o RTL schematic, ele gera um monstro gigantesco. olhando o resultado da sintese, vc descobre que ele consome 989 slices, 1024 flip-flops e 868 LUTs. no caso de uma spartan-3 modelo 100E, isso representa 103% dos recursos e vc precisaria de uma FPGA maior.

no RTL schematic eh possivel seguir os sinais e perceber que ele tem clear para cada flip-flop. fazendo uma leve mudanca de sintaxe na logica sincrona para mudar o clear pode melhorar:

Código: Selecionar todos

  always@(posedge CLK)
  begin
      A[ADDR] <= RESET ? 0 : A[ADDR] + DATA_K * DATA_X;
  end


mandando fazer o RTL schematic, vc rapidamente visualiza que ele condensou todos os flip-flops, a logica de decodificacao e a logica de multiplex em memorias sincronas, que sao muito mais compactas. normalmente o nivel de complexidade que vc ve no RTL schematic se reflete no consumo de logica. quanto menos complexo o circuito, mais limpa a logica e menos recursos consumidos. de fato, o resultado agora eh o consumo de apenas 66 slices, nenhum flip-flop e 55 LUTs, o que corresponde a meros 6% de consumo no mesmo modelo de FPGA do exemplo anterior.

de fato, mesmo escalando esse segundo circuito de 32 para 512 canais, o consumo de logica ainda fica na casa dos 71% e o RTL schematic permanece inalterado: a unica coisa que muda eh o tamanho da memoria que armazena os acumuladores e a largura do barramento de enderecos. com a outra logica precisaria de umas 17 FPGAs para fazer o mesmo.

mas essas dicas vc soh aprende testando diferentes sintaxes, olhando o RTL schematic e repetindo ateh conseguir a solucao mais compacta possivel.

[mastk]

Sim, os circuitos que descrevo atualmente estao no limite de 72 macro celulas, quando isso acontece faço exatamente o que disse, tento mudar a "forma que descrevi" e muito vezes isso basta, porem ja teve casos que tive que mudar o escopo do sintetizador.

Em alguns outros casos, o sintetizador, simplifica a minha logico a ponto que algo deixa de funcionar, deixando apenas um avisso, que sequer é reportado nos Logs finais, apenas nos parciais.

Nao cheguei a ver nenhuma ferramente no ISE de visualizar graficamente o resultado da sintese.

É F*** ser burro, doi no cabeca e principalmente no bolso.

[msamsoniuk]

opa! o RTL schematic eh justamente o resultado grafico da sintese!

Sim, os circuitos que descrevo atualmente estao no limite de 72 macro celulas, quando isso acontece faço exatamente o que disse, tento mudar a "forma que descrevi" e muito vezes isso basta, porem ja teve casos que tive que mudar o escopo do sintetizador.

Em alguns outros casos, o sintetizador, simplifica a minha logico a ponto que algo deixa de funcionar, deixando apenas um avisso, que sequer é reportado nos Logs finais, apenas nos parciais.

Nao cheguei a ver nenhuma ferramente no ISE de visualizar graficamente o resultado da sinteze.

É F*** ser burro, doi no cabeca e principalmente no bolso.

[mastk]

Achei, o RTL final da logica que implementei ate o presente momento ta bem complicada rs. Porem invalida.

Ja li metade do livro e algumas coisas, ja foram bem esclarecedoras e interresantes.

Eh meio vergonhoso usar um kit, porem, pensei, um FPGA com uma densidade razoavel, ja me permitiria fazer a implementacao do TMS9918 e nao precisso de muito pinos, me veio a mente:



Me sinto o homem mais rico do mundo

Ainda assim, o esquema de modos de video eu entendo, agora sprite parceiro, acho que vai tendo:

RAM rapida pra diabo.
RAMs em paralelo.
RAM interna no ASIC.

Creio que sintetizar RAM no FPGA nao eh uma coisa muito inteligente...

[msamsoniuk]

dah para trabalhar com memoria na boa dentro da FPGA!

o TMS9918 tinha suporte apenas a 16 kbytes de memoria e ele tambem suportava 32 sprites de 16x16 pixels. em uma 250E vc tem 12 blockrams dualport de 2 kbytes cada uma e vc pode usar isso para formar um banco de memoria de video de 16 kbytes facil facil:

Código: Selecionar todos

module vram(
  input CLKA,
  input WEA,
  input [7:0] DINA,
  input [14:0] ADDRA,
  output reg [7:0] DOUTA,
  input CLKB,
  input WEB,
  input [7:0] DINB,
  input [14:0] ADDRB,
  output reg [7:0] DOUTB
);

  reg [7:0] VRAM [0:16383];

  always@(posedge CLKA)
  begin
    DOUTA <= VRAM[ADDRA];
    if(WEA)
      VRAM[ADDRA] <= DINA;
  end

  always@(posedge CLKB)
  begin
    DOUTB <= VRAM[ADDRB];
    if(WEB)
      VRAM[ADDRB] <= DINB;
  end

endmodule


no RTL schematic aparece exatamente uma RAM de 16 kbytes dual-port.

um barramento vc pode usar do lado do microcontrolador, para fazer as escritas e operacoes, enquanto o outro lado vc pode usar para fazer o refresh periodico da tela. eles podem inclusive operar com clocks diferentes!

os sprites sao mais complicados, mas nao tanto... vc pode criar 32 instancias de memorias de 8x32 bits usando lookup tables (LUTs). um unico sprite seria assim:

Código: Selecionar todos

module spriteram(
  input CLKA,
  input WEA,
  input [7:0] DINA,
  input [4:0] ADDRA,
  output [7:0] DOUTA,
  input PXCLK,
  input PXRES,
  input HEN,
  input VEN,
  output PXOUT
);

  reg [7:0] SPRITE [0:31];
  reg [7:0] PXADDR;

  assign PXOUT = SPRIT[PXADDR[7:3]][PXADDR[2:0]];

  always@(posedge PXCLK)
  begin
     PXADDR <= PXRES ? 0 : PXADDR + (VEN&&HEN);
  end

  assign DOUTA = SPRITE[ADDRA];

  always@(posedge CLKA)
  begin
    if(WEA)
      SPRITE[ADDRA] <= DINA;
  end

endmodule


eh praticamente a mesma sintaxe, soh que tem uma sutileza de fazer a leitura assincrona, daih ele nao consegue inferir uma blockram e se obriga a usar lookup. imagino tb que os sprites soh precisam de acesso RW de um lado e que do outro lado pode ser somente leitura.

como o sprite eh orientado a bit, a segunda porta eh uma porta somente de leitura com o pixel clock e sinais de sincronismo. quando o PXRES eh ativo, ele reseta os contadores internos (durante um VSYNC, por exemplo), enquanto HEN e VEN sao os enables quem vem dos circuitos externos que detectam colisao do sprite com determinado endereco.

no refresh de video, vc tem contadores que contam as colunas e linhas. estes contadores precisam ser comparados com os valores da posicao do sprite e tamanho de video, algo como:

Código: Selecionar todos

always@(posedge PXCLK)
begin
  if(HCOUNT == HWIDTH)
  begin
    HCOUNT <= 0;
    if(VCOUNT == VWIDTH)
    begin
      VCOUNT <= 0;
      PXRES <= 1;
    end
    begin
      PXRES <= 0;
      VCOUNT <= VCOUNT+1;
      if(VCOUNT >= VSPRITE && VCOUNT < (VSPRITE+16))
        VEN <= 1;
      else
        VEN <= 0;
    end
  end
  else
  begin
    HCOUNT <= HCOUNT+1;
    if(HCOUNT >= HSPRITE && HSPRITE < (HSPRITE+16))
      HEN <= 1;
    else
      HEN <= 0;
  end
end


daih quando os contadores de coluna e altura simultaneamente estao ativos, eh pq o refresh esta sendo feito na area do sprite e a spriteram cospe os valores dos pixels continuamente... ou algo assim! tendo os valores na mao, vc provavelmente vai colocar em um encoder de prioridade todos os sprites, para ver quem esta acima e, entao, vai plotar na tela o pixel de cor correspondente aquele sprite. se nao tiver sprite ou a combinacao dos sprites for zero, vc plota o pixel normal da vram.

para um TMS9918 acho que vai na boa... agora, se for algo cavalar tipo um XGA 1280x1024, realmente, dentro da FPGA nao cabe mesmo! :D hehehe

[msamsoniuk]

medo hein!

http://sblive.narod.ru/ZX-Spectrum/V9938/V9938.htm

[marcelo campos]

Que droga ! será que vou ter que comprar um MSX no Mercado Livre mesmo ?
Eu queria é ter o prazer de montar um, mesmo que não fosse igualzinho ao que eu tinha ou com os mesmos recursos...

abraço ao amigos do Forum

Marcelo

[enigmabox]

Este site tem bastante informação sobre MSX, tem vários manuais e livros:

http://msxlivros.blogspot.com/


Tem um manual técnico em português sobre o Hotbit da Sharp que pode servir como ponto de partida para montagem ou sintetizar o MSX em FPGA ou em outro hardware.