linux DDR16bit/32bit

[fabim]

Pessoal que interessante uma coisa.
A beagle-bone tem memoria DDR3@700mhz, só que em 16 bits, e 1GHZ de cpu.
A cubieboard-2 tem memoria DDR3@450mhz, só que em 32 bits, e 1ghz de cpu.

A beagle-bone informou 293 BOGOMIPS.
A cubieboar-2 informou 328 BOGOMIPS.

OBS: as duas foram testadas apenas por SSH.
Sem processar nada etc.

[andre_luis]

Palpite de leigo:

A limitação do acesso pode estar no clock máximo permitido, e a performance medida seja apenas da transferencia no barramento.

[tcpipchip]

http://tldp.org/HOWTO/BogoMips/bogo-list.html

[fabim]

Nossa fiquei tonto agora !!

Baixei o tool-chain da BBB, e fiz um teste, eis que funcionou na BBB, e para minha surpresa !! o arquivo executável esta criado para 32Bit, sendo que a arquitetura do alvo esta feita em 16bits.

Existe alguma forma de descobrir se o sistema esta rodando, se foi compilado ou algo parecido para 16 bits ?

[Rodrigo_P_A]

Nossa fiquei tonto agora !!

Baixei o tool-chain da BBB, e fiz um teste, eis que funcionou na BBB, e para minha surpresa !! o arquivo executável esta criado para 32Bit, sendo que a arquitetura do alvo esta feita em 16bits.

Existe alguma forma de descobrir se o sistema esta rodando, se foi compilado ou algo parecido para 16 bits ?

Acho que você está confundindo as coisas, pois não é a largura do barramento de memória externa que indica a arquitetura.
Você pode ter por exemplo um PIC32 rodando com memória externa de 4 bits (QSPI) , e as instruções internas sendo executadas em 32 bits!

Não é porque a memória da BBB é de 16 bits que ele está rodando como se fosse 16 bits, vou tentar exemplificar de forma simples: o controlador de memória quando necessário lê duas vezes consecutivas a memória para montar internamente a palavra de 32 bits quando necessário, ou lê só uma vez e de uma só vez lê 2 bytes... e assim por diante.

Pense nisso.

[fabim]

hum, tendi, basicamente ele arrasta o código para o cache e roda-o-o no cache.
Ou algo parecido, certo ?
Desta forma quando vou usar um toolchain para criar algo, não necessito saber se a arquitetura foi construída com memoria ram em 8, 16 ou 32 bits que seja.
Única coisa que tenho que fazer no caso do kernel que esta rodando na arquitetura é configurar o tipo de ram, e o kernel que se vire com o restante para puxar, montar e executar no cache ou seja como for.

É isto ?

[Rodrigo_P_A]

hum, tendi, basicamente ele arrasta o código para o cache e roda-o-o no cache.
Ou algo parecido, certo ?
Desta forma quando vou usar um toolchain para criar algo, não necessito saber se a arquitetura foi construída com memoria ram em 8, 16 ou 32 bits que seja.
Única coisa que tenho que fazer no caso do kernel que esta rodando na arquitetura é configurar o tipo de ram, e o kernel que se vire com o restante para puxar, montar e executar no cache ou seja como for.

É isto ?

Mais ou menos.... de qualquer forma tem que ter o toolchain correto ou saber configurá-lo de forma correta.

[fabim]

hum, agora fhoderizou.
Se disse que o toolchain tinha que ser especifico para o target, sabendo logicamente se este por sua vez tem RAM em 16 ou 32, diz-me que me enganei.
Se digo que o toolchain não precisa saber como esta a arquitetura de memoria da ram, e vai cc para 32 bits normalmente, ai você diz que é mais ou menos, e que tenho que usar um toolchain e saber configura-lo para arquitetura !!

RSRS rapaiz, entortei as bielas, !!

[Rodrigo_P_A]

hum, agora fhoderizou.
Se disse que o toolchain tinha que ser especifico para o target, sabendo logicamente se este por sua vez tem RAM em 16 ou 32, diz-me que me enganei.
Se digo que o toolchain não precisa saber como esta a arquitetura de memoria da ram, e vai cc para 32 bits normalmente, ai você diz que é mais ou menos, e que tenho que usar um toolchain e saber configura-lo para arquitetura !!

RSRS rapaiz, entortei as bielas, !!

Fabim, se o processador é de 32 bits ele pode usar externamente barramento de 4 bits (QSPI por exemplo), 8 bits, 16 bits ou 32 bits. Isso num muda a arquitetura do processador.

Dá uma olhada por exemplo nos PIC32 e alguns ARMs, eles podem rodar com a memória externa QSPI ( que é serial de 4 bits ) e usar esta memória como dados/programa, quem faz a "tradução" é o controlador de memória.

[fabim]

Certo então o que eu havia dito, antes de você dizer zomeno, e eu disse o que você disse.
Agora você disse que o que eu disse antes de você dizer zomeno, estava correto !?

Bem, estou a uns 3 anos picadamente mente mente estudando SO, unix like.
E pelo que eu pude entender, é que:
Se uso um SO unix like, em um uC de 32bits, porém o barramento de memoria RAM é de 16 bits, o kernel tem que ser compilado para rodar nos ditos 16 bits, e logicamente os apps também devem ser compilados em 16 bits.

Mas ao comprar uma beagle-bone que possui 16 bits, e ao baixar um toolchain arm-Linux-gnueabi-"cadeia de aplicativos etc" , eu fiz um app simples com print hello otario.
Joguei este na beagle-bone, e ./teste. Pronto funcionou !
Bem, veja.
O uC é 32 bit, a RAM é 16, eu fiz um APP para arquitetura 32bit.
hipopotézis.
1° - o kernel puxa 16 + 16 palavra, executa-a, sucessivo.
2° - o kernel puxa para o cache aquele dado pacote de informações relevante ao que vai fazer, e roda-o no cache internamente. Desta forma o kernel DEVE saber que tipo de memoria esta no barramento, 4,16,32 bits, para que assim ele puxe os os nibles ou byte ou short ou int, e desta mesma forma execute no cache.
3° - Por ser Harvard no caso dos arms, a ram pode-se dizer que é uma extensão a flash, se a flash "cache interno no caso", esta carregado com algumas coisas do kernel rodando a 32 bits, e vai rodar algo na RAM externa, não entendo como é possível isto.
4° - Desisto de descobrir a logia, e apenas uso o que existe, e continuo a fazer as coisas sem saber porque, onde ou quando, e quando não funcionar, foda-se só mudar a arquitetura.

[pbernardi]

fabim,

Acho que sua dúvida é mais em relação aos hardwares que fazem o tratamento dos barramentos no microprocessadores. Os microprocessadores têm hardwares especialmente dedicados ao tratamento de bus - os controladores de RAM (SRAM, SDRAM, DDR, DDR2, DDR3, etc.) e geralemente um para tratamento de barramento paralelo genérico, que é usado para a FLASH mas poderia ser usado para acessar qualquer outro dispositivo (CIs endereçáveis, FPGA, buffers, etc.)

Então, para entender o que acontece em relação aos barramentos, é muito menos questão de entender o que acontece no core do microprocessador e enteder o que acontece nos controladores de memória, incluindo aí a cache, que não deixa de ser um outro hardware dedicado dentro do core.

Por exemplo, num coldfire que usamos aqui, o MCF5207: http://cache.freescale.com/files/32bit/ ... 5208RM.pdf

Dê uma olhada nos capítulos 5 (Cache), 6 (SRAM interna), 17 (Flexbus, que é o controlador de barramento paralelo, dê uma olhada especial na página 295), e 18 (Controlador de SDRAM).

O SO configura tudo pra você, então quando você está mexendo em alto nível, você não tem visibilidade do que está acontecendo nos controladores de HW de mais baixo nível. Mas tudo o que o SO faz nesses casos é configurar corretamente estes perféricos, de modo que você não tenha que esquentar muito a cabeça com isso.

Quanto aos casos que você descreveu:

O caso 1) é o caso em que se roda diretamente da flash. Geralmente se usa logo no começo do boot, quando a RAM ainda não está configurada. Então, um dos primeiros passos do código que roda diretamente na flash é configrar a RAM, cache, essas coisas.

Geralmente, configurado a RAM, você copia seu código da FLASH para a RAM e começa excutar o código de lá. É bem mais rápido porque a RAM temo menos latência, e se tudo tiver configurado corretamente, a RAM vai poder usar a cache para otimizar a execução do código. É mais ou menos o que você descreveu no 2), mas com uma RAM no lugar da FLASH. Apesar de que se você não tiver uma RAM externa por exemplo, deve ser possível usar a cache diretamente, eu é que nunca precisei disso.

No caso 3) apesar das arquiteturas Harvards poderem endereçar RAM e FLASHes no mesmo range de endereços, ainda assim o uP sabe quando está acessando a flash e quando está acessano a RAM, pq vc define range de endereços diferentes para eles. Por exemplo, posso ter uma ram de 64MB no range 0-0x003FFFFF e uma FLASH de 256M no range 0x80000000-0x80FFFFFF. Se eu escrever no endereço 0x80400000, o uP sabe que estou escrevendo na FLASH e vai gravar seguindo os passos que seu controlador indicar. Se eu for ler uma instrução do endereço 0x00001000, o uP sabe que é da RAM, e sendo uma instrução e o cache estiver configurado, ele provavelmente vai pegar um bloco inteiro da SDRAM e passar pra cache, de acordo com o que estiver programado no controlador de cache. Se o outro acesso for no endereço 0x00001001, a cache e o controlador SDRAM se entendem via HW, e o endereço passado já é pego diretamente da cache sem precisar pegar da SDRAM.

Espero ter dado uma esclarecida - o ponto é que tem muito mais HW dando ajuda no processador do que o core, e o core não faz tudo sozinho.

[fabim]

Hum...
Então quer dizer que eu gero uma imagem de kernel/programas etc em 32 bit, e jogo isto numa flash qualquer.
O Uboot, configura o hw de ram, entre outros, e carrega o kernel na memoria de 32MB de ram com 16 bits, de barramento, logicamente o kernel pelo uboot ou outra forma qualquer esta ciente que o barramento é 16 bits.
Feito isto, ele da um CALL para o inicio do kernel para que ele possa criar vida e fazer tudo que é necessário !!

Ai minha duvida, melhor especificada.
Se as instruções são em 32 bits, e a memoria esta populada com o kernel com acessos de 16bits.

Creio eu então que o HW puxa duas palavras de 16 bits para ula, e executa-a, e sucessivo.

Desta forma, eu consigo entender que não importa se é 8 ou 16 ou 32 bits, já que existe uma abstração que monta internamente ao uP/uC a palavra de 32 bits para poder executa-la.

Olhando desta forma, eu estou com uma linha de raciocínio.

Hoje eu possuo um LPC1788 com uma SDRAM em 16 bits rodando a 60mhz, se eu conseguisse então criar uma imagem qualquer de Linux para este meu hw, a velocidade básica da ram para EXECUÇÃO seria de 30mhz aproximadamente, pois seria 2 ciclos de leitura para palavra de programa, e um ou mais ciclos para escrita de dados etc.

Em suma, o KERNEL de alguma forma esta ligado que a RAM é de 8/16/32 bits !!

Filosoficamente.
Se possuo uma DDR3 700mhz 16 bits, ou Se possuo uma DDR2 350mhz 32 bits, as duas no mesmo uP/uC é correto dizer que a velocidade de execução de instruções, leitura escrita etc, esta limitado a 350mhz.

Correto ?

[pbernardi]

Sim, correto.

De um modo geral, ao aumentar o barramento, você aumenta a velocidade de escrita/leituram, como você colocou. Só que isso nem sempre é tão linear assim, você tem que ver qual é seu gargalo.

Por exemplo, lembre-se que na DDR ele faz dois acessos por clock, uma na subida e outra na descida. Assim, com uma DDR3 rodando a 16 bits@350 MHz (acho que comercialmente falando isso non exziste, mas para fim didádicos) você deveria conseguir rodar sem gargalos em um processador de 32 bits@350 MHz.

Ainda, para uma DDR3, há a questão das latências: para fazer um único acesso num cicclo de clock você demora alguns clocks, e gasta um (ou poucos) clock(s) para as leituras subsequenctes sequenciais. Então, se você ficar lendo de lugares aleatórios, a performance cai.

A cache atenua o efeito acima: se você tiver leituras aleatórias em um range pequeno, que ainda esteja ao alcance da cache, ele vai pegar da cache direto com performance bem melhor. Pode ser que, mesmo com um barramento de 16 bits, você consiga uma performance similar a 32 bits devido a cache.

Mas, de um modo geral, se você quer máxima performance, você vai querer:

a) seu uP rodando em um clock mais alto possível
b) sua RAM rodadando a um clock mais alta possível, e DDR.
c) seu barramento de dados com uma largura maior possível.
d) sua cache sendo a maior possível

Esses quatro parâmetros tem que ser aumentados meio que proporcionalmente. Se você aumentar muito um e não aumentar muito os outros parâmetros, você pode estar criando um gargalo e não melhorar o sistema como um todo.

[fabim]

Hummmm estou começando a entender a parada.
Como exemplo real a minha bbb revc tem ddr3-512MB-16bitt@700mhz.
Eu estou impressionado com o poder dela tocando dois videos hq mkv e mp3 em 192k ao mesmo tempo sem lags.
Se esta fosse com barramento de 32bit nos mesmos 700mhz da ddr3 eu ficaria assustado !! Certo ?

[pbernardi]

Depende do clock do processador. Se for, por exemplo, um processador com clock de menos de 700 MHz, você pode aumentar o barramento e não deve dar tanta diferença de performance, pq a DDR3 já deve conseguir passar as instruções praticamente 1:1 para o processador.

Se o processador rodar em mais de 700 MHz, pode ser que melhore. Vai depender do quanto que seu algorítmo precise acessar a RAM, se apenas a cache dá conta, essas coisas. Por exemplo, se seu código for bem pequeno e couber dentro da cache, pode ser que o acesso a RAM nem faça tanto diferença, pois na prática o processador vai estar rodando o código direto da cache.

Pra sentir na prática: dá uma verificada se você consegue desabilitar a cache do seu sistema, acho que existem maneiras de fazer isso. A diferença de performance entre um sistema com a cache ligada e desligada costuma ser brutal.