Exploração do Espaço de Projeto em Hw/Sw Co-design de Sistemas Tempo-Real Embarcados Orientados a Objetos: o Objeto Escalonador

Transcrição

1 Exploração do Espaço de Projeto em Hw/Sw Co-design de Sistemas Tempo-Real Embarcados Orientados a Objetos: o Objeto Escalonador Elias Teodoro Silva Jr 1,4, Marco A. Wehrmeister 1, Fabiano C. Carvalho 1, Leandro Buss Becker 3, Carlos Eduardo Pereira 2, Flávio Rech Wagner 1, Luigi Carro 2 1 Instituto de Informática - UFRGS, Brasil 2 Departamento de Engenharia Elétrica - UFRGS, Brasil 3 Departamento de Automação e Sistemas - UFSC, Brasil 4 D e p a r t a m e n t o d e T e l e m á t i c a CEFET/CE, Brasil {etsilvajr, mawehrmeister, fccarvalho, flavio}@inf.ufrgs.br, {cpereira, carro}@eletro.ufrgs.br, lbecker@das.ufsc.br Abstract. This paper discusses a design flow for multithread object-oriented realtime applications, running on top of an embedded, platform-based, customizable Java processor, which is prototyped using affordable FPGAs. The proposed approach enforces design space exploration activities, taking into account aspects like temporal behavior, memory footprint, and power/energy consumption. A case study containing a task scheduler implementation as both software and hardware modules is presented, evaluating latency and area. While both implementations are compatible with the developed program from an interface point of view, they lead to different timing and footprint requirements. Resumo. Este trabalho propõe um fluxo de projeto para aplicações tempo-real orientadas a objetos, executando em uma plataforma embarcada customizável. A plataforma alvo é um processador Java, o qual pode ser prototipado em FPGA. Um estudo de caso de implementação do escalonador de tarefas tanto em hardware quanto em software é apresentado, avaliando as latências e a área no chip. O desenvolvedor pode facilmente optar por uma das versões, pois ambas são compatíveis do ponto de vista da sua interface, embora elas se apliquem a diferentes requisitos de tempo, memória e energia. 1. Introdução Sistemas de Tempo-real dependem não somente dos resultados lógicos da computação, mas também do tempo de ocorrência destes resultados [Stankovic 1996]. Particularmente, sist emas embarcados e de tempo-r eal vêm crescendo em termos de complexidade, demandando ferramentas que trabalhem em níveis mais altos de abstração. A fim de reduzir o time-to-market, os desenvolvedores procuram por componentes reusáveis (tanto em software quanto em hardware). Além disso, o projetista deve poder comparar entre versões em software (maior flexibilidade) e hardware (maior desempenho e menor potência) dos componentes e sub-sistemas. O projeto SEEP (Sistemas Embarcados Baseados em Plataformas) [UFRGS 2004], que está em andamento na Universidade Federal do Rio Grande do Sul, propõe uma

2 metodologia completa e integrada para o projeto e teste de sistemas embarcados e de t e m p o -real, levando em conta requisitos funcionais e também não funcionais, como comportamento temporal e consumo de potência. A metodologia SEEP faz uso intensivo de conceitos de orientação a objetos, desde a especificação do sistema até a sua implementação, visando à obtenção de componentes reusáveis que possam ser aproveitados e m d i ferentes implementações e que atendam a diversas restrições de projetos. A abordagem utiliza componentes de hardware e software e baseia-se na configuração de plataformas arquiteturais implementadas usando dispositivos de lógica programável. Alguns trabal hos têm proposto a implementação de serviços do sistema operacional em hardware [Burleson 1999] [Kuacharoen 2003] [Kohout 2003] [Götz 2004], procurando tirar vantagem da natureza paralela deste tipo de implementação. Assim, o conhecido overhead introduzido no sistema por aqueles serviços, quando implementados em software, é significativamente reduzido. Esta idéia é estendida neste trabalho, encapsulando serviços do sistema operacional em um objeto, aumentando assim o re-uso. O presente trabalho também disc ute questões relacionadas com a exploração do espaço de projeto na metodologia definida pelo projeto SEEP usando como exemplo um componente de escalonamento de tarefas. Ao longo do artigo é descrita a exploração do espaço de projeto r e l a t i v a m e n t e à i m p l e m e ntação deste componente em hardware ou em software, mantido o mesmo modelo de objetos da aplicação, seguindo a definição RTSJ (Real-Time Specification for Java) [Bollella 2001]. 2. Um Processador Java-RT Configurável 2.1 Processador FemtoJava O FemtoJava [Ito 2001] é um processador de pilha que executa bytecodes J a v a e q u e t e m como principais características um conjunto reduzido e configurável de instruções, arquitetura Harvard e tamanho pequeno. O FemtoJava implementa uma máquina Java em hardware, que é compatível com a especificação JVM (Java Virtual Machine). Para a versão do núcleo do processador usada neste trabalho, todas as instruções são executadas em 3, 4, 7 ou 14 ciclos. Para que pudesse suportar multi-tarefa o FemtoJava teve o seu conjunto de instruções expandido [Rosa 2003] [Wehmeister 2004]. Ganhos de desempenho foram obtidos com uso de Pipeline e de VLIW em outras versões do processador [Beck 2003]. 2.2 API baseada na RTSJ Java vem ganhando popularidade nos últimos anos como uma linguagem aplicável ao desenvolvimento de sistemas embarcados e de tempo-r eal, especialmente devido à definição da RTSJ. A especificação define uma API para a linguagem Java que permite a criação, verificação, análise, execução e gerenciamento de threads, cujo correto fu ncionamento depende do atendimento de requisitos de tempo. O ambiente Sashimi [Ito 2001] é um exemplo de otimização da JVM para sistemas embarcados. Ele oferece um ambiente simples e poderoso que tem sido aplicado com sucesso em diferentes estudos de caso. O ambiente Sashimi foi estendido para incorporar uma API que suporte a especificação orientada a objetos de tarefas concorrentes e com restrições de tempo [Wehmeister 2004]. Estes recursos elevam o nível de abstração do projeto e otimizam o desenvolvimento de sistemas embarcados. A figura 1 mostra um modelo UML de parte da API apresentada em [Wehmeister 2004], usada neste trabalho.

3 Esta API oferece uma alternativa para simplificar o projeto de aplicações orientadas a objetos e de tempo-r e a l, e x e c u t a n d o e m um processador de código nativo Java. Usando esta API, junto com o ambiente Sashimi, o programador pode desenvolver aplicações com tarefas concorrentes de tempo-real e sintetizá -las em um processador FemtoJava. Figura 1. Classes dos escalonadores da API. 3. Alternativas de Implementação para o Objeto Escalonador 3.1 Objeto Escalonador em Software A estrutura do escalonador consiste em um processo adicional que se encarrega da alocação da CPU para aqueles processos de aplicação que estão prontos para execu t a r, e x a t a m e n t e como ocorre em um RTOS (Real Time Operating System). O desenvolvedor de aplicações pode escolher o algoritmo de escalonamento mais adequado em tempo de projeto. Assim, um escalonador personalizado é sintetizado juntamente com toda a aplicação no sistema embarcado alvo. 3.2 Objeto Escalonador em Hardware O escalonador em hardware contém tabelas que armazenam descritores das tarefas, enviados pelo processador FemtoJava, bem como os operadores que manipulam estas tabelas. Ele é encapsulado por uma classe chamada HardwareScheduler, que interage com o hardware e realiza as ações de troca de contexto e despacho. Estas ações têm um baixo custo relativamente à ação de escalonar as tarefas, especialmente quando se trata de algoritmos de escalonamento complexos Arquitetura A arquitetura proposta para o escalonador em hardware é mostrada na Figura 2. Os componentes principais do escalonador em hardware, que age como um coprocessador, são: General Register, Scheduler, SyncEvent e AsyncEvent. O bloco General Register contém os descritores de todas as tarefas independentemente de seu estado (running, blocked e ready). A qualquer momento, o processador pode incluir ou remover tarefas neste bloco. O bloco AsyncEvent recebe tarefas que serão disparadas por eventos e monitora eventos externos de hardware cujos instantes de ocorrência não podem ser definidos a priori. Estes eventos ou sinais são tipicamente associados a sensores, tais como ocorrência de alarmes. Quando um evento associado a uma tarefa acontece, o ID da tarefa é enviado para o bloco Scheduler. O bloco SyncEvent é similar ao bloco AsyncEvent e monitora tarefas da aplicação sensíveis a eventos do relógio de tempo-real do sistema. A execução deste tipo de tarefa depende do relógio e pode ocorrer periodicamente ou em instantes específicos. O bloco Scheduler recebe tarefas que estão prontas para executar, enviadas pelos blocos SyncEvent ou AsyncEvent, e as coloca em sua tabela, classificando-as de acordo

4 c o m a o r d e m e s t a b e l e c i d a p e l a p o l í t i c a de escalonamento. O bloco Scheduler envia tarefas para o processador em duas situações: 1) A tarefa atual concluiu a sua execução. O processador executa uma operação de leitura e recebe a próxima tarefa informada pelo coprocessador. 2) A tarefa recentemente inserida na primeira posição da tabela do bloco Scheduler tem prioridade sobre a tarefa atualmente em execução no processador. O coprocessador interrompe o processador, provocando a preempção da tarefa que estava em execução. FemtoJava Processor Co-processor GeneralRegister Scheduler Sync Event Async Event Figura 2. Arquitetura geral do escalonador em Hardware Comandos do escalonador em Hardware Para operar o escalonador em hardware, o FemtoJava pode usar cinco comandos diferentes, conforme a Tabela 1. Todas estas operações são realizadas pela classe HardwareScheduler e são transparentes para o programador que desenvolve sua aplicação sobre a API. Tabela 1. Descrição dos comandos do escalonador em hardware. Comando Descrição Inclui tarefa O coprocessador recebe um conjunto de parâmetros que descrevem a tarefa a ser escalonada. A figura 3 mostra os detalhes destes parâmetros. Remove tarefa O coprocessador remove uma tarefa previamente programada. Inicia tarefa O coprocessador move uma tarefa previamente programada para o estado Ativa e pode escalonar aquela tarefa quando os seus eventos chegarem. Tarefa concluída O coprocessador fornece o ID da primeira tarefa na fila de tarefas prontas. Tarefa O coprocessador fornece o ID da primeira tarefa na fila de tarefas prontas e re-escalona a tarefa preemptada atualmente em execução. Tabela 2. Descrição dos campos das palavras de programação do escalonador em hardware. Campo St_Priority EV ID Sync_or_Async Start Period Descrição Prioridade estática da tarefa. Define qual entrada de evento externo vai disparar a tarefa (apenas para tarefas assíncronas). Código de identificação da tarefa. Define se esta tarefa é Síncrona (periódica ou one-shot) ou Assíncrona (Esporádica). 3 palavras de bits indicam quando a tarefa deve ser iniciada pela primeira vez (se síncrona). 3 palavras de bits indicam o período de re-ativação da tarefa (se periódica). Se a tarefa não for periódica estes campos devem permanecer em zero Interface do escalonador em Hardware O FemtoJava se comunica com o coprocessador e com os demais dispositivos de I/O via um barramento de bits. Durante a programação de cada tarefa, um bloco semelhante ao

5 apresentado na figura 3 é enviado pelo processador ao coprocessador. No estudo de caso deste trabalho, um conjunto de sete palavras de bits é usado para descrever uma tarefa síncrona em um algoritmo baseado em prioridade fixa. A primeira palavra é a palavra de controle. Seus campos e os demais parâmetros são mostrados na Tabela Exploração do Espaço de Projeto para o Objeto Escalonador: um Estudo de Caso E sta sessão ilustra o uso da API proposta no projeto de um sistema embarcado, destacando aspectos da implementação em hardware e em software do escalonador. O sistema a ser modelado consiste de uma carga sintética que simula uma aplicação real. O uso de versões hardware e software do escalonador é demonstrado em um exemplo de implementação. St_Priority (not used) EV Start (days) Start (milis) Start (nanos) Period (days) Period (milis) Period (nanos) Sync_or_Async (not used) ID Figura 3. Formato das palavras de programação do coprocessador para um algoritmo de escalonamento baseado em prioridades fixas. 4.1 Implementação em Software Para exemplificar um projeto, serão usadas duas tarefas hipotéticas Task1 e Task2. A classe principal será chamada de TaskTest. Esta classe é responsável pela alocação e inicialização de objetos e disparo das tarefas. Um esquema do código fonte do exemplo é dado nas figuras 4 e 5. O método initsystem() representa o ponto de partida do fluxo da aplicação. As tarefas de tempo-real são passadas ao coprocessador pelo método addtofeasibility() e são disparadas pelo método start(). O método idletask() será chamado quando as tarefas estiverem lançadas e não houver nenhuma tarefa pronta para ser executada. O código de uma das tarefas, cuja instância é chamada de t1 na classe TaskTest, é mostrado na figura 5. Neste exemplo, esta tarefa é disparada periodicamente a cada 25ms. public class TaskTest { // static allocations // public static PriorityScheduler mysched = new PriorityScheduler(); public static void initsystem() { Scheduler.setDefaultScheduler(mySched); t1.addtofeasibility(); t2.addtofeasibility(); t1.start(); t2.start(); idletask(); } //... // } Figura 4. Classe principal para o exemplo de aplicação usando escalonador em software. public class Task1 extends RealtimeThread { // constructors // public void maintask() { while (m_schedcount < 15) { m_schedcount++; //...Repetitive operations waitfornextperiod(); } finish(); } public void exceptiontask() {// handle deadline missing } } Figura 5. Classe Task1 para o exemplo de aplicação.

6 4.2 Implementação em Hardware A implementação do coprocessador escalonador foi descrita em VHDL. Para os testes deste trabalho, o algoritmo de escalonamento utilizado é de prioridade fixa. public class TaskTest { // idem public static HardwareScheduler mysched = new HardwareScheduler(); public static void initsystem() { // idem } Figura 6. Classe principal para o exemplo de aplicação usando escalonador em hardware. Para usar o escalonador em hardware, o desenvolvedor segue a mesma metodologia mostrada na sessão 4.1. Usando o exemplo das figuras 4 e 5 a aplicação pode ser completamente reusada. A única modificação necessária é a classe do escalonador, conforme destaque na figura 6. Uma vez que o coprocessador apenas executa as ações de escalonamento, o chaveamento de contexto e o despacho continuam sendo realizados em software, pela classe HardwareScheduler. 5. Resultados Experimentais Para os estudos experimentais foi feita uma restrição no projeto de maneira que as definições de tempo utilizassem apenas um campo de bits para representar tempos em milisegundos, embora nos estudos iniciais e no Java seja possível representar o tempo em três campos de bits cada (dias, milisegundos e nanosegundos). Também o bloco AsyncEvent foi retirado para simplificar os testes. Todos os experimentos foram feitos com tarefas síncronas e periódicas. Utilizando a ferramenta da Altera Quartus II 4.0 Web Edition Full, o modelo em VHDL foi compilado. Nesta descrição foram utilizados registradores para implementar as tabelas de dados dos sub-sistemas. Para a síntese foram indicados dispositivos da família Cyclone. A Tabela 3 mostra a área de cada bloco em Células Lógicas, sendo dividida em sínteses para 4 e 8 tarefas. A área apresentada pelo coprocessador é elevada, já que o processador FemtoJava custa aproximadamente 3500 células lógicas. Entretanto este parece ser o preço a ser pago para se obter determinismo elevado e baixa energia, conforme será mostrado adiante. O bloco RTC é o relógio de tempo-real e o bloco Converter é uma m á q u i na de estados que recebe as palavras vindas do processador e as entrega para o bloco GeneralRegister, já em um formato adequado. Tabela 3. Número de Células lógicas usadas pelo coprocessador 8 tarefas / Device: EP1C20F4C6 Total GeneralRegister Converter SyncEvent RTC Scheduler tarefas / Device: EP1C4F4C6 Total GeneralRegister Converter SyncEvent RTC Scheduler Um modelo do coprocessador descrito em Linguagem C foi simulado utilizando versões adaptadas do SASHIMI e do CACO-PS [Beck 2003], um simulador ciclo-a -c i c l o. Foram feitos testes com 2, 4 e 8 tarefas. Cada tarefa é executada 15 vezes. Para a simulação foi adotado um clock de 500KHz. Para verificar as propriedades temporais do escalonador foram feitas medidas da latência da tarefa de maior prioridade, ou seja, o tempo decorrido entre o instante em que

7 ela foi programada para iniciar sua execução e o instante em que ela efetivamente começa a executar. O gráfico da figura 7 mostra estas latências para os experimentos com 2 e com 8 tarefas, para cada uma das 15 execuções. Excluindo a primeira execução, o jitter m á x i m o para os dois casos é exatamente o mesmo: 39 ciclos, ou 78 µs. A figura também mostra que o tempo de espera da tarefa para entrar em execução é muito baixo (entre 403 e 442 ciclos de clock) e independente do número de tarefas em execução. Uma vez que a troca de contexto e o despacho têm custo fixo e a ação de escalonamento é feita no hardware, o número de tarefas não afeta o tempo de processamento Nº de Ciclos de Clock Nº de Ciclos de Clock Ciclos de Execução das Tarefas 2 tarefas 8 tarefas 0 Ciclos de Execução das Tarefas Versão SW Versão HW Figura 7. Latência para a tarefa de maior prioridade. Figura 8. Tempo de chaveamento entre duas tarefas subseqüentes. Uma versão do escalonador implementada em software foi testada com os mesmos benchmarks. Apenas a freqüência do processador foi aumentada para 5MHz a fim de atender aos deadlines das tarefas, já que agora o escalonador consome um tempo bem maior. A necessidade de aumentar a freqüência do processador indica que haverá um aumento na energia gasta pelo sistema (por limitações de espaço não serão mostrados aqui dados de potência e energia). Para comparar o tempo de chaveamento entre duas tarefas consecutivas foi construído o gráfico da figura 8. Estes tempos dão uma idéia do custo de processamento do algoritmo de escalonamento da versão software. A versão software consome sempre 5385 ciclos de clock (já que são apenas duas tarefas), à exceção da primeira execução, que consome ciclos. A versão hardware consome 1114 ciclos na primeira execução e 1150 nas demais. O esc alonamento em hardware é mais rápido porque manipula suas tabelas em poucos ciclos de clock, enquanto a versão software realiza dezenas de instruções para isto. 6. Conclusões e Trabalhos Futuros Este trabalho apresenta como um desenvolvedor pode usar uma API para implementar uma aplicação, sem que o processo de desenvolvimento seja influenciado por aspectos arquiteturais, de maneira que esta possa ser facilmente portada de um escalonador em software para um em hardware. O princípio do encapsulamento de um recurso de hardware por uma classe foi testado e validado, podendo ser re-aproveitado em outros recursos como comunicação entre processos e/ou entre processadores, aumentando a sua reusabilidade. O principal custo imposto pelo coprocessador escalonador é a sua área. No exemplo com oito tarefas a área do coprocessador fica maior que a área do processador FemtoJava. Isto decorre do mapeamento das tabelas do escalonador em registradores e pode ser otimizado futuramente. Entretanto, o escalonamento em hardware oferece melhorias nas propriedades de previsibilidade, desejáveis em aplicações de tempo-r e a l, a l é m d e d i m i n u i r l a t ê n c i a e jitter.

8 Ao mover o algoritmo de escalonamento do software para o hardware, estas ações do sistema operacional não mais competem com a aplicação pelo uso do processador. A unidade de hardware dedicada ao escalonamento pode agora: 1) executar algoritmos de escalonamento mais complexos, e 2) prover um escalonamento de tarefas não intrusivo. Como trabalho futuro, os autores pretendem implementar algoritmos de escalonamento mais complexos, uma das vantagens que um escalonador em hardware pode oferecer. Bibliografia Beck Filho, A.C.S., Mattos, J., Wagner, F.R. and Carro, L. (2003) CACO-PS: A General- Purpose Cycle-Accurate Configurable Power Simulator. In: Proceedings of the 16th Symposium on Integrated Circuits and Systems Design, (São Paulo, Brazil). IEEE Computer Society Press Beck Filho, A.C.S. and Carro, L. (2003) Low Power Java Processor for Embedded Applications. In: IFIP VLSI-SOC, Darmstadt. IFIP WG 105 Proceedings. p Bollella, G., Gosling, J. and Brosgol, B. (2001) The Real-Time Specification for Java. -V1.0.pdf Burleson, W., Stankovic, J.A. et al. (1999) The Spring Scheduling Co-Processor: A Sc heduling Accelerator. IEEE Transactions on VLSI Systems, 7(1):38 48 Götz, M. (2004) Dynamic Hardware-Software Codesign of a Reconfigurable Real-T i m e Operating System. In: International Conference on Reconfigurable Computing and FPGAs 2004 (ReConFig04), Mexican Society of Computer Science, SMCC, September 2004, p Ito, S.A., Carro, L. and Jacobi, R.P. (2001) Making Java Work for Microcontroller Applications. IEEE Design & Test of Computers, vol. 18, n. 5, pp Kohout, P., Ganesh, B. and Jacob, B. (2003) Hardware support for real-time operating systems. In: International Symposium on Systems Synthesis, pages Proceedings of the 1st IEEE/ACM/IFIP International conference on HW/SW Codesign and System Synthesis Kuacharoen, P., Shalan, M. and Mooney, V. (2003) A configurable hardware scheduler for realtime systems. In: International Conference on Engineering of Reconfigurable Systems and Algorithms (ERSA), pages Rosa Jr., L.S. et al. (2003) Scheduling Policy Costs on a Java Microcontroller. In: Proceedings of the workshop on Java Technologies for Real -T i m e a n d E m b e d d e d Systems (JTRES), (Catania, Italy) pp Stankovic, J.A. et al. (1996) Strategic Directions in Real-Time and Embedded Systems. ACM Computing Surve ys 28, 4, Pages UFRGS. (2004) LSE - Embedded Systems Lab. In: < Wehmeister, M.A., Becker, L.B. and Pereira, C.E. (2004) Optimizing Real-T i m e Embedded Systems Development Using a RTSJ -based API. In: Workshop on Java T echnologies for Real-Time and Embedded Systems - JTRES 2004, Agia Napa, Cyprus. Proceedings Springer LNCS, pp