albertorcneto escreveu:Marcelo Samsoniuk escreveu:portanto o consumo total na maxima cadencia de transferencia da sua uart assincrona com dma vai ser de 115200 clocks. note que, se a uart vai ter fifo ou nao, nao eh muito relevante para vc.
as coisas funcionam dessa forma praticamente em qq processador. claro, tem variacoes: nos coldfires q eu uso, por exemplo, os controladores de dma tem contadores de tamanho maior e menor, q permitem transferencias de areas bi-dimensionais, listas encadeadas de buffers ou listas infinitas com auto-reload. mas daih eh outro nivel neh...
entao fabim, entendeu o quer que desenhe?
Ate onde eu sei, o tamanho da buffer fifo eh relevante porque o periferico transfere todo o buffer antes de gerar uma interrupcao de fim de buffer. Ou entendi o que voce explicou errado?
O OMAP3530 (da Beagleboard) pelo menos tambem tem transferencia bidimensional e acho que auto-reload tambem.
eh relevante para o tamanho do buffer, mas normalmente os buffers sao muito maiores que as fifos. a dinamica da fifo do periferico pode ser encarada como uma caixa preta desenhada para evitar que dispositivos sincronos engasguem por latencia de acesso ao dma. por exemplo, suponha que vc tem uma memoria de 8 bits clockada a 50MHz e que consome 2 clocks por acesso. entao vc tem 25MB/s de bandwidth para dividir com o dma e processador. imagine entao que vc tem 4 controladores de dma. o pior caso possivel de latencia seria o processador jah estar usando o bus e os outros tres canais jah terem priorizado seus acessos. a latencia vai ser de 8 clocks de 50MHz ateh o seu canal conseguir acessar.
daih suponha que vc tem uma ethernet de 100mbps. cada byte chega a cadencia de 12.5MB/s, ou seja, equivalente a 4 clocks de 50MHz. o lado receptor nao tem controle de fluxo e nao para depois q comeca um frame, portanto eh possivel que cheguem 2 bytes naquele tempo de latencia do controlador de dma. normalmente desenhamos as fifos "seguras" em um layout de double buffer, onde o tamanho da janela de entrada eh do tamanho da janela de saida, assim vc teria uma fifo de 4 bytes.
isso em certas condicoes. se vc extender o problema, tem a questao de chip-selects externos. supondo que o processador esta acessando um periferico externo e os outros 3 canais tambem, e que este periferico tem wait-states, a latencia p/ tomar o bus aumenta. e com isso o tamanho da fifo para o controlador ethernet tem que aumentar. o que eu tenho visto na pratica sao fifos de 16 bytes nos controladores que eu chamaria de "arrojados". nessa condicao, ele pode ter uma latencia equivalente a 64 clocks de 50MHz. uma vez conseguindo tomar o bus, ele vai limpar a fifo de 16 bytes ou o que tiver disponivel em uma rajada e parar. daih o ciclo recomeca e, claro, ele fica novamente sujeito a latencia.
mas vc nao precisa necessariamente conhecer esse mecanismo. o que vc precisa conhecer eh algo mais alto nivel: o frame sera transferido via dma e ele nao vai parar! entao esqueca a parte da fifo e concentre-se no mecanismo como um todo: o mtu do frame ethernet tipico eh de 1500 bytes e o controlador pode anexar descritores com flags e crc. entao uma boa pratica eh alocar um buffer p/ o dma da ordem de 1516 bytes. independente entao do tamanho da fifo, vc precisa suprir a necessidade de alto nivel do controlador, pq nao dah tempo de trocar o buffer no meio da recepcao de um frame.
os controladores que tem auto-reload integrado sao interessantes pq no exemplo da ethernet eles nao parariam depois de transferir um frame: eles fariam reload dos registros do controlador p/ apontar para o proximo buffer automaticamente. a interrupcao eh necessaria pq vc precisa ir processando os frames jah recebidos, mas o recurso permitiria receber frames em cadencias mais rapida que o processamento, evitando problemas com latencias (por exemplo, o processador pode estar atendendo outra interrupcao mais importante).
o coldfire tem auto-reload, mas o powerpc tem um negocio mais legal ainda: ring buffers. os ring buffers sao listas com listas de ponteiros para buffers. se nao me falha a memoria, cada descritor (ele tem centenas de descritores) corresponde a um canal de dma (portanto ele tem centenas de canais independentes) e aponta para uma lista de descritores de buffers (cada entrada eh um buffer) que sao usados em sequencia (por isso o termo ring buffer). os limites, se nao me falham a memoria, sao 16384 descritores de buffers e cada buffer tipicamente tem o tamanho de um frame (1516 bytes).
por exemplo, se vc tiver um MPC860, que eh um powerpc antigo, vc tem 4 controladores HDLC dentro dele e cada um deles pode ser quebrado em ateh 32 sub-controladores. assim, vc poderia configurar uma interface PCM de 8MHz e quebrar 1/4 dessa interface p/ cada controlador, tendo assim 128 canais PCM que podem trabalhar com voz ou dados (HDLC). tipicamente, cada canal vai ter um ring-buffer de 8 a 32 frames com um certo tamanho. por exemplo, para audio o payload tipico eh o mesmo dos frames RTP e, portanto costuma ser de 40, 80 ou 160 bytes. se vc pegar o caso mais amplo, vc teria entao 32 frames de 160 bytes em cada canal, com 128 canais no total. sao 4096 buffers de 160 bytes para ele gerenciar. com 160 bytes, a cadencia do stream RTP fica em 50 frames/s por canal.
o interessante eh que eh possivel alinhar a transferencia exatamente nos limites de um frame RTP, quer dizer, o dma preenche o frame automaticamente e depois o powerpc apenas coleta os frames, adiciona headers IP, UDP, RTP e roteia p/ a ethernet a cadencia de 6400 frames/s.
bom, na pratica, o IPv4 dah uma afogada pesada no powerpc soh p/ calcular CRC e vc descobre que um MPC860 pode nao dar conta hehehe daih vc comeca a procurar coisas mais potentes e, eventualmente, aceleracao IP e UDP em hardware comecam a fazer sentido (soh de nao precisar calcular CRC frame a frame a coisa jah melhora muito!). mas daih o merito comeca a sair do controlador de dma e ir p/ o periferico.
Enviado: 13 Mar 2012 13:21