Resenha da Unidade 9 – Arquiteturas Reconfiguráveis

Artigo de Referência:

A. Azevedo, R. Soares, I. S. Silva, “Implementação da DCT2D em arquiteturas reconfiguráveis utilizando a X4CP32”,Proceedings of Iberchip 02, Havana, Cuba, 2002.

A fim de demonstrar o poder e a flexibilidade das Arquiteturas Reconfiguráveis (AR), os autores do artigo fizeram uso de um cenário um tanto quanto comum hoje em dia, além de favorável para tais arquiteturas: uma aplicação que requer grande fluxo de dados e processamento. Em tempos de mobilidade em alta, o mercado pode aproveitar-se da necessidade por Arquiteturas capazes de realizar um bom trabalho (leia-se performance), consumindo pouca energia e, consequentemente, dissipando menos energia térmica. É ai que entram as ARs, nos permitindo vislumbrarmos a sua importância.

A AR utilizada foi um X4CP32, composto por grãos, células e uma UC. Como sabemos, a reconfigurabilidade da arquitetura é provida pelo grão. Nesta AR, o grão pode assumir dois modos de execução, a saber: modo processador ou bloco de ULA’s. As células, por sua vez, são responsáveis pela computação em si. Cada uma delas é composta por uma ULA, memória interna, uma pilha, um registrador acumulador, lógica de controle interno, 6 portas de comunicação e um canal para roteamento(é, tudo isso em cada uma das células J). Cada célula em um grão está ligada as demais por meio de barramentos dedicados de incríveis 32bits. A comunicação entre grãos distintos pode ser realizada por meio de roteamento ou, se possível, diretamente por barramento! Mas não para por ai. Essa AR é realmente interessante em cada um dos principais aspectos, como comunicação, barramentos, instruções, sincronismo, configuração do grão e etc.

O calculo da transformada discreta do cosseno, utilizado na codificação JPEG, é conhecido por seu alto grau de complexidade. Assim, no referido artigo, foi considerado um bom problema para implementação na AR. O algoritmo utilizado favorece o paralelismo e o uso de pipeline. A implementação ocupou uma área de 4x5 grãos, sendo alguns no modo de execução Processador e outros no modo Bloco de ULA. As constantes foram multiplicadas por 256, de modo a se trabalhar apenas com valores inteiros(truncados, claro). Apesar de o erro médio ter sido de apenas 0.00096265, esse valor já é suficiente para impossibilitar a aplicação da solução em casos mais importantes, como no tratamento de imagens médicas (que é uma grande necessidade na área de processamento de sinais). Embora os autores tenham conseguido reduzir um pouco mais essa taxa de erros(utilizando outros artifícios), ela continua sendo uma taxa de erros e, consequentemente, implicando em uma codificação com perdas.

Cada grão no modo processador possui três células, as quais trabalhando como ULA’s, sendo que 2 grãos foram utilizados para fazerem a parte principal dos cálculos(ou seja, 6ULA’s). Dessa forma, tem-se um dado a cada 10 ciclos(8 de deslocamentos, 1 de entrada e 1 de saída na célula). Desta forma, ao analisar a estrutura da implementação, temos 8 saídas a cada 10 ciclos em um pipeline completo. Isso, em outras palavras, significa que pode-se obter uma matriz 8x8 a cada 80 ciclos(essa matriz é resultante da primeira transformada discreta do cosseno, ou seja, 1D.). Repete-se o mesmo procedimento e, assim, teremos a transformada em 2D.

O FPGA utilizado foi um da família Flex 10KE, da Altera, que possibilitou um clock de 53,08Mhz. O resultado do desenho alcançado permitiu uma taxa de 70,7 imagens monocromáticas(640x480) por segundo. Outra implementação com foco no desempenho alcançou uma taxa de 141,4 imagens por segundo, ou seja, o dobro (também quase o dobro do custo J). Ambos apresentaram uma latência inicial de 160 ciclos. Em comparação com uma ASIC, o ganho foi de 14%, enquanto que o ganho em comparação com uma implementação em software foi de 137%. Levando em conta as características de desempenho e consumo elétrico, os resultados parecem promissores para um mundo mobile. No entanto, também deve-se atender a outros desafios, como o tamanho dos chips, o preço e, naturalmente, a “moda” do mercado.

Resenha da Unidade 8 - Barramentos e interconexão.

Artigos de Referência para a resenha:

Gallo12, R., & Kawakami, H. (2011). SCuP-Secure Cryptographic Microprocessor. Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais. Retrieved from http://www.ppgee.unb.br/sbseg2011/resources/downloads/sbseg/90828.pdf

SILVA, Yamar Aires da. Estudo e proposta de um novo documento de identificação eletrônica (e-ID) para o Brasil. 2007. xx, 147 f. Dissertação (Mestrado em Engenharia Elétrica)-Universidade de Brasília, Brasília, 2007.

Piccolo, Lara Schibelsky Godoy. Arquitetura do Set-top Box para TV Digital Interativa. Instituto de Computação – Unicamp, 2006. Disponível em http://www.ic.unicamp.br/~rodolfo/Cursos/mo401/2s2005/Trabalho/039632-settopbox.pdf

Elevando o nível de proteção...

A Arquitetura de Von Neumann, na qual os nossos dispositivos digitais dotados de processamento se baseiam, não seria tão eficiente nos dias de hoje sem o avanço dos barramentos. Ao pensarmos, em alto nível, em uma CPU executando instruções sobre dados, os quais foram obtidos, ambos, na memória principal, em um determinado instante e por um determinado motivo, pode nos influenciar a crermos que a velocidade da operação dependerá tão somente do clock da CPU, ou, ainda pior, do espaço de armazenamento da nossa memória principal. Mas, na realidade, o gargalo está em um nível mais baixo.

A Unidade de Controle (UC), naturalmente, precisa de um meio para “obter” dados da memória. Além disso, também é necessário um canal de sinalização, informando que o acesso será realizado. Não satisfeito, nosso inseparável amigo também requer outro meio para informar o endereço de memória que contém os dados/instruções necessários. Esses meios são, respectivamente, o Barramento de Dados, Barramento de Controle e o Barramento de Endereço de Memória. Nos processadores Intel, o barramento de dados passou a ter 64bits a sua disposição, um pouco antes que o barramento de memória, que atualmente também conta com 64bits em praticamente todos os novos processadores x86. Mas, qual a relação desses barramentos com “proteção/segurança”?

O Barramento de Dados e o Barramento de Endereço de Memória são, ambos, um canal entre a Memória Principal(MP) e o Registradores de Dados de Memória(RDM) e Registrador de Endereço de Memória(REM). Assim, embora o Barramento de Memória seja unidirecional (apenas a UC aciona a MP, e não o contrário), não ocorre o mesmo com o Barramento de Dados, no qual tanto a UC quanto a MP podem “depositar” dados/instruções. Essa interconexão entre a MP e o Registrador de Dados (ou o Acumulador) é análoga a interconexão entre dois dispositivos em uma Rede de Computadores, na qual fica mais fácil vislumbrarmos a necessidade de um Firewall neste canal.

O firewall é o elemento responsável por analisar o conteúdo dos dados que trafegam em um canal, “fazendo a separação entre o joio e o trigo”. Dessa forma, no contexto dos Barramentos de Interconexão em Chips, os projetistas decidiram que, em certos tipos de chips, era necessário um tipo de firewall no hardware, a fim de evitar que instruções/dados maliciosas possam passar da MP para o RDM(ou outros registrados, a depender da arquitetura) e, com isso, serem executadas pelo processador.

Conforme pode ser visto nas referências desse texto, várias são as abordagens para se conseguir um efeito de Firewall na interconexão de chips. Em smartcards mais antigos, por exemplo, pode ser exigir que a aplicação realize um processo de autenticação antes de poder carregar instruções/dados na MP. Ou seja, o firewall não está, de fato, na interconexão(barramento) entre a MP e o RDM, mas antes da MP. Essa abordagem, de fato, não é a mais segura, uma vez que uma aplicação após autenticada poderá depositar quaisquer tipos de instruções na MP(inclusive maliciosas), as quais, posteriormente, serão carregadas para os Registradores e executadas! Apesar de não ser ideal, é ainda melhor do que no caso de alguns Set-top Box para TVs digitais, que, embora tenham barramentos velozes, que interligam inclusive o controle remoto do usuário diretamente no barramento de dados da CPU(pelo menos é o que disseram o pessoal do artigo), não dispõem de um método para filtrar o conteúdo.

Por outro lado, smartcards mais elaborados, possuem um eficiente Firewall, que recebem o sugestivo nome de Firewall de Hardware (HWF). O HWF age controlando o acesso entre os mestres de barramento e os periféricos (repare que, neste caso, a proteção vai além de apenas a interconexão entre RDM e a MP). Dessa forma, pode-se evitar que qualquer periférico que tenha sido comprometido (como, por exemplo, o teclado de uma urna de votação eletrônica) possa ter acesso aos barramentos de conexão com dados em claro. Com uma aplicação corretamente escrita para essa arquitetura, o voto eletrônico é capturado e criptografado pelo processador. Caso a informação tente passar pelo barramento em claro (sem a criptografia), será impedida pelo HWF. Ao mesmo tempo em que, se um periférico tentar acessar o dado em claro, também poderá ser impedido. Propostas para Documentos de Identificação Eletrônicas (e-ID) seguem a mesma proposta, implemetando um HWF nos níveis mais baixos, a fim de evitar comprometimentos no chip.

Embora essa sofisticação seja incrivelmente funcional, não existem muitos relatos na literatura sobre incidentes de segurança causados pela falta de um HWF na interconexão do chip (pelo menos por enquanto). Ou, em outras palavras, em um nível tão baixo. Algo que as pesquisas não revelaram foi que, de fato, as maiores fraudes quase sempre ocorrem no Mais Alto Nível, literalmente. E isso, infelizmente, está além de qualquer chip(eletrônico). ;)

Arquitetura de Computadores - PPGI/UFPB

(Unidade 6)

O ano de 1936 foi, sem dúvida, um marco para a ciência (não só da computação). Um jovem matemático britânico, conhecido como Alan Turing, publicava o primeiro artigo que apresentava ao mundo o seu modelo de máquina universal. Era uma “simples” maquina de computar, composta de um cabeçote capaz de mover-se por uma fita, na qual lia e escrevia informações. Estava pronta a base para, praticamente, toda a computação existente até hoje! De lá para cá, muita coisa mudou, mas quase tudo permaneceu o mesmo (isso mesmo, não é um erro de digitação). Os computadores mais modernos que utilizamos atualmente são basicamente implementações da máquina universal, proposta por Turing em 1936.

A fita dessa máquina, hoje em dia mais conhecida como memória, sempre se manteve como um foco de esforços por parte dos projetistas de hardware, que buscam aperfeiçoar suas capacidades de armazenamento, velocidade e consumo elétrico. Inicialmente usadas em meio magnético, logo as memórias volátil passaram a ser elétricas, eliminando os gargalos mecânicos inconvenientes. Mas, claro, isso apenas não era suficiente J. Logo os computadores passaram a usufruir de vários níveis de memória, as quais variam basicamente em velocidade. As mais velozes, como as memórias cache, naturalmente são mais caras e menos acessíveis. A divisão em níveis teve como objetivo otimizar o acesso aos dados de memória, mas não provocando um grande impacto no custo. Por exemplo, ao invés de construir um computador apenas com memória cache como memória principal, constrói-se uma maquina com uma pequena parcela dessa memória (o que não trará grande impacto no custo), e aplicam-se mecanismos/algoritmos de gerenciamento, os quais buscarão garantir que os dados realmente úteis estejam, na maior parte do tempo, disponíveis na memória cache. Com isso, podemos simular uma memória de tamanho variável, apenas pelo gerenciamento da mesma.

A velocidade de acesso à memória principal não depende exclusivamente da sua própria tecnologia, mas, também, do barramento de dados de memória e do barramento de endereço de memória. Haja vista que a memória cache encontra-se praticamente dentro do processador, neste caso a velocidade dos barramentos não chega a ser um problema, o que, infelizmente, não é o caso das memórias *RAM. No entanto, nos últimos anos, a velocidade dos barramentos externos tem atingido valores mais altos, dando lugar à importância da velocidade interna do circuito de memória. Além disso, tais barramentos dobraram de tamanho, passando a ter 64 linhas (bits), não só no barramento de endereço, mas também no de dados. Com isso, ganhamos memórias muito mais velozes, além de apenas memórias de grande capacidade. É pena que, infelizmente, ainda é comum se ouvir propagandas de computadores com “muita memória” por preços relativamente muito baixos, enquanto outros computadores com “menos memória” (mas com uma tecnologia mais nova e muito mais veloz) por preços mais altos. Assim, o consumidor, mal influenciado, quase sempre termina fechando um belo mal negócio.

---------------------

Terminando de arrumar as referências ainda... minha internet deu problema ;\

(Resenha do Artigo:

FÁVERO, AL: “Suporte a Multiprocessadores Simétricos (SMP) em kernel Linux”, Universidade Federal do Rio Gande do Sul.)

Referências:

Open Source Development Labs, Inc., Linux Process Scheduler Improvements in Version

2.6.0, Disponível em http://developer.osdl.org/craiger/hackbench/. Acesso em abril 2004.

Rick Lindsley, What's New in the 2.6 Scheduler, Disponível em

http://www.linuxjournal.com/article.php?sid=7178 . Acesso em abril 2004.

Enkh Tumenbayar, Linux SMP HOWTO. Disponível em

http://www.tldp.org/HOWTO/SMP-HOWTO.html. Acesso em abril 2004.

Hank Dietz, Linux Parallel Processing HOWTO, Disponível em

http://www.tldp.org/HOWTO/Parallel-Processing-HOWTO.html. Acesso em abril 2004.

Intel Corporation, MultiProcessor Specification,Version 1.4 May 1997.