Upload
alexandre-augusto-giron
View
1.131
Download
1
Embed Size (px)
DESCRIPTION
Segunda parte da apresentação do Minicurso de Introdução a Sistemas embarcados e Projeto de Plataformas - CBSEC 2012Overview do MPSoc OMAP 35 e amostras de experimentos práticos na plataforma BeagleBoard
Citation preview
Beagleboard- OMAP 3530
Alexandre Augusto Giron- UNIOESTE
João Angelo Martini- UEM
Marcio Seiji Oyamada- UNIOESTE
http://www.inf.unioeste.br/~marcio
UNIOESTE – Universidade Estadual do Oeste do Paraná
Curso de Ciência da Computação
Cascavel - Brasil
Tópicos
Beagleboard
– Características
OMAP 3530
– ARM Cortex A8
– DSP C64x+
Exemplos práticos
Beagleboard
Kit de desenvolvimento utilizando a plataforma
OMAP
– www.beagleboard.org
BeagleBoard C4: ARM+ DSP (US$ 125)
BeagleBoard XM: ARM +DSP (US$ 149)
BeagleBone: ARM (US$ 89)
BeagleBoard C4
Beagleboard C4
Beagleboard
Sistemas Operacionais suportados
– Angstrom
– Debian (sem atualização)
– Ubuntu (constantes atualizações)
– Android
Beagleboard XM
ARM 1Ghz
512 MB RAM
Portas USB
Porta Ethernet
OMAP 3530
OMAP 3530
Plataforma OMAP3
– Aplicações alvo:
• Audio
• Telecom
• Eletrônicos
• Industrial
• Médico,
• Segurança
• Avionicos e defesa
• Vídeo e imagem
OMAP 3530- Esquemático
Dispositivos utilizando o OMAP3xxx
Device TYPE MPSoC
Touch Book Netbook OMAP 3530
Pandora Portable Video
Game OMAP 3530
DevKit8000 Evaluation Kit OMAP 3530
BeagleBoard Evaluation Kit OMAP 3530
Motorola
Milestone Smartphone OMAP 3430
Nokia N9000 Smartphone OMAP 3430
Samsung i8910 Smartphone OMAP 3430
Galaxy S Smartphone OMAP 3630
Droid 2 Smartphone OMAP 3630
Milestone 2 Smartphone OMAP 3630
ARM Cortex A8
Pipeline de 3 estágios
– Busca(3 cycles)
– Decodificação (4 cycles)
– Execução (6 cycle)
ARM- Diferenças em relação ao RISC
Instruções com ciclos de execução diferentes
Pré-processamento de operandos
Conjunto de instruções Thumb 16-bit
Execução condicional
Instruções especializadas
Load/Store múltiplos
DSP
Arquitetura com recursos para extrair o máximo
desempenho em algoritmos de processamento de
sinais
Realizar as operações em paralelo
– ci * x(n -1)
C64x+
Processador de sinais digitais da TI- Texas
Instruments
VLIW – Very long instruction
– 8 instruções por ciclo
– Empacotamento de instruções para execução sequencial
ou paralela
– Suporte a tipos de dados de 8, 16 e 32 bits
– Suporte a saturação e normalização
C64x+
Experimentos práticos
Instalando a distribuição Linux [3]
Download de uma imagem pré-compilada
– http://rcn-ee.net/deb/rootfs/oneiric/ubuntu-11.10-r9-
minimal-armel.tar.xz
Script de Instalação
– De acordo com a plataforma: sudo ./setup_sdcard.sh --
mmc /dev/mmcblk0 --uboot “board”
– Opções “board”: beagle_cx, beagle_xm
BeagleBoard Networking
Através de um cabo USB-OTG
– ssh, interface usb0
Cabo “par-trançado” (BeagleBoard XM apenas)
Adaptador Wifi USB
Ubuntu – Instalando aplicações
Sudo apt-get update
Sudo apt-get install gcc
Exemplo hello_world.c
Exemplo MiBench -> jpeg decoder
Alterando a frequência no ARM
cpufreq-info
cpufreq-set -g performance
cpufreq-set -f 800MHz
cpufreq-set –f 300MHz
BeagleBoard GUI - Ubuntu
Gdm xubuntu-desktop
BeagleBoard GUI - Ubuntu
xfce
BeagleBoard GUI – Debian
Debian gdm
BeagleBoard – Desenvolvimento ARM+DSP
O programador deve implementar explicitamente o
código no ARM e no DSP
Baseada na criação de DSP Nodes
Requisitos:
– Compilador arm-linux-gnueabi-gcc
– DSP toolchain: C6x CGT compiler
– doffbuild tools
Comunicação efetuada através da troca de
mensagens entre os processadores
BeagleBoard – Ambientes de desenvolvimento
Ferramentas:
– Hard-style: vi + makefile (arm e dsp)
• Programador fica desamparado
• Depuração heterogênea comprometida
– Soft-Style: utilizar um ambiente de programação
• Ex: Code Composer Studio – CCS*
– Suporte à várias plataformas
– Análise de performance e comportamento
– Hardware Debugging
* http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5
Code Composer Studio
Code Composer Studio
BeagleBoard – Comunicação
Messaging:
– API para troca de mensagens síncronas
• DSP_Node_PutMessage, DSPNode_GetMessage
– Capacidade assíncrona: mecanismo de notificação
• DSPNode_RegisterNotify, DSPManager_WaitForEvents
BeagleBoard – Tipos de Comunicação
Estrutura de Componentes
DSP/Bridge Project: http://www.omappedia.org/wiki/DSPBridge_Project
Componentes
Da perspectiva ARM-Side
Gerenciamento de Recursos
– Instancia dinamicamente os DSP nodes
– Monitoramento dos recursos DSP
– Carregar dinamicamente código DSP conforme a
necessidade
– Políticas para gerenciar os recursos DSP
Componentes
Gerenciador de Plataforma
– Inicia/Finaliza execução do DSP
– Implementa streaming de dados
– Carrega estaticamente o bridgedriver (baseImage)
DSP link driver para comunicação baixo-nível
Componentes DSP
Da perspectiva do lado DSP (DSP/BIOS)
Servidor de Gerenciamento de Recursos
– DSP/BIOS se comunica com o lado ARM através do link
driver
– Permite a criação, execução e término dos DSP task nodes
• DSP Task Nodes: threads independentes de execução
no DSP, suportam I/O stream entre si e com o ARM
– Responde aos comandos do Gerenciador de Recursos
(lado ARM)
O modelo DSP-dummy
Disponível em:
– http://gitorious.org/vjaquez-beagleboard/dsp-samples
Basicamente, divide-se em três partes: o código
voltado ao processador ARM, o código voltado ao
DSP e o código para as chamadas ao DSP Bridge
Etapas da Execução (ARM)
Primeiro, é iniciado o controlador do DSP Bridge
Em seguida, reserva-se os recursos do lado ARM
para controle de um processador DSP
Etapas da Execução (ARM)
Agora, o nodo DSP pode ser alocado:
Etapas da Execução (ARM)
A função dsp_node_create é responsável por criar o
nó dsp alocado. Após criado, ele é executado
Executando:
• A partir do momento que o DSP node está em execução,
o processador ARM pode trocar mensagens ou realizar
streaming de buffers de dados com o nodo
Etapas da Execução (ARM)
No exemplo, um input e um output buffer.
• A referência para os buffers (arg1 e arg2) é passada ao
DSP: dsp_node_put_message
Com a posse dos buffers, o DSP aguarda a
mensagem para iniciar o processamento (cmd = 1)
Etapas da Execução (Perspectiva DSP)
O DSP espera a mensagem do ARM
– Com cmd = 0, DSP recebe as referências dos buffers
Etapas da Execução (Perspectiva DSP)
Então aguarda pela mensagem de início do
processamento (cmd = 1)
– Ao iniciar o processamento, nesse caso, o lado ARM fica
bloqueado esperando a resposta do DSP.
Etapas da Execução (ARM)
Assim que termina o processamento por parte do
DSP, o nodo pode ser finalizado e então liberado da
memória.
Liberando nodo:
Interações ARM-Bridge-DSP
Interações ARM-Bridge-DSP
Interações ARM-Bridge-DSP
Exemplos
Soma de vetores:
– Soma simples: Execução no DSP
– Execução em torno de 50 ms
Exemplos
Soma de vetores:
– Soma otimizada: através de instruções específicas DSP
– Execução em torno de 10 ms
Referências
V. M. J. LEAL, “The DSP/BIOS Bridge”, Igalia
Company. Slides disponíveis em:
– [1] http://people.igalia.com/vjaquez/talks/bridgedriver-
omap3-fosdem-2010.pdf
BeagleBoard Sites:
– [2] http://beagleboard.org/
– [3] http://elinux.org/BeagleBoardUbuntu
– [4] http://elinux.org/BeagleBoard/DSP_Howto
Manuais de Referência da Texas Instruments:
– OMAP 3530, ARM Cortex-A8, DSP C64x+