1. Innledning
7.3 Prinsippet om den manglende idébeskyttelsen
O componente que implementa as funcionalidades das Tarefas de Hardware é ilus- trado na Figura 5.5 e este componente foi desenhado baseando-se no modelo de tarefas que o Sistema Operativo de suporte apresenta, tornando esta implementa- ção o mais transparente possível e favorecendo a migração de tarefas de software para o FPGA, para além de abstrair a complexidade de implementação aos vários serviços do sistema.
Para o desenho deste componente inicialmente fez-se a distinção de duas partes, criando uma parte para a lógica do utilizador e uma outra para a maquina de estados de sincronização e nesta última foi necessário definir quais os estados que uma tarefa poderia assumir e como foi demonstrado na secção 3.2 as tarefas ape- nas assumem dois estados fundamentais, NOT_RUNNING (Execução parada)
NOT_RUNNING
User Logic
Sinchronization state machine
Sy st em B us Run Done READ POST RUN RUNNING QueueReceive()=1 Done=0 \Run<=1 Done=1 \Run<=0 QueueSignal<=1 QueueSend()=1 \QueueSignal<=0 clk reset
Hardware Thread
TaskRun=1 QueueSignal Data_In TaskRun=0 Data_Oute RUNNING (Em execução), indicando o estado atual da tarefa de hardware e quando a tarefa se encontra no estado de NOT_RUNNING a tarefa poderá estar em estado suspenso ou bloqueado, sendo da responsabilidade do gestor de tarefas atribuir esse estado à tarefa. Com esta análise dos estados das tarefas foi então desenhada uma máquina de estados para o modelo de tarefas de hardware com apenas dois estados, Running e Not_Running, mas a tarefa de hardware não pode apenas estar a ser executada, esta também terá de ter uma forma de se comu- nicar com outras tarefas, tal como o FreeRTOS disponibiliza um parâmetro para transferência de dados no cabeçalho da criação de uma tarefa de software ou essa transferência de dados também poderá ser feita através de mecanismos de comu- nicação, assim como as messages queues e para se controlar estas transferências de dados foi criado uma máquina de estados dentro do estado Running para poder assumir os estados da tarefa de hardware, para tal foi necessário definir qual seria o ciclo natural de tarefa de hardware, e a execução natural de uma tarefa é a leitura de dados, processamento desses dados e saída dos dados tratados. Com o ciclo da tarefa de hardware já definido foi desenhada a máquina de estados presente dentro do estado Running, que apresenta os estados Read, Run e Post, para lei- tura dos dados vindos da queue, processamento e saída de dados, respetivamente. Este componente também apresenta um sinal denominado de QueueSignal que está ligado diretamente à interrupção externa do processador de modo a informar o sistema operativo que a tarefa de hardware terminou a sua execução e que tem tem disponível os dados já tratados para serem consultados.
A maquina de estados e a lógica do utilizador comunicam através de dois sinais (Run e Done) e de dois barramentos de dados, um de entrada e outro de saída (Data_In e Data_Out), criados especificamente para este efeito. O sinal de Run é responsável por indicar à lógica do utilizador que esta poderá iniciar a execução da tarefa nela implementada e o sinal de Done quando a nível lógico alto indica à máquina de estados que terminou a execução da tarefa e o barramento de dados de entrada tem a finalidade de transferir dados para a tarefa de hardware para posteriormente estes serem processados e após o processamento destes, o resultado obtido é devolvido através do barramento de dados de saída.
Para o utilizador poder usufruir das tarefas de hardware foi adicionada uma ma- cro HwThreadModel no ficheiro de configuração do FreeRTOS já referenciado no Capitulo 3 em que para ativar as tarefas de hardware basta que esta macro tenha o valor 1 e para desativar o valor 0. Também foi implementada uma nova API para integrar no sistema operativo com o objetivo do kernel poder interagir com
as tarefas de hardware, esta API foi feita num módulo com o nome mss_thread.h e mms_thread.c que foi introduzido ao projeto e na Figura 5.6 pode-se ver API cri- ada para as tarefas de hardware, sendo que esta API será manipulada pelo kernel do sistema operativo de forma a ser oculta aos olhos do utilizador.
Figura 5.6: API - Tarefas de hardware
O modelo de tarefas de hardware apresenta uma interface entre o barramento e a lógica do utilizador bastante simples como se pode ver na Figura 5.7 que retrata a interface desenhada para o modelo de tarefas. Fazendo uma análise top down sobre a figura, inicialmente a figura mostra uma entidade responsável pela interface com o barramento que faz a ponte com a interface com a tarefa de hardware, onde neste se pode ver como entrada um conjunto de 8 argumentos, e estes argumentos são os dados que são transferidos para a lógica do utilizador que serão processados posteriormente, sendo estes argumentos registos internos da interface de tarefas de hardware e apresentam o tamanho de 32bits. As tarefas implementadas em
hardware utilizam o conjunto de parâmetros disponíveis na interface para transferir
os resultados, que são 8 parâmetros de 32bits cada, sendo estes parâmetros apenas de leitura quando o kernel do sistema operativo der a indicação de leitura destes. A interface contém a máquina de estados de sincronização apresentada anterior- mente na Figura 5.5, que é responsável por gerir a tarefa de hardware, gerar o sinal de interrupção de forma a sinalizar o processador que a tarefa terminou a sua execução e de atualizar o registo de estado, e também contém dois registos importantes, o registo de controlo e o registo de estado, sendo que o primeiro re- gisto serve para configurar o tarefa de hardware, já o registo de estado é apenas um registo de controlo para monitorização do funcionamento correto da tarefa de
hardware.
A Figura 5.8 apresenta a composição do registo de controlo. Este é um registo leitura e escrita de apenas 8bits.
Bus Interface
User Logic
Hw Thread Interface Control Register Status Register Argument 1 Argument 2 Argument 3 Argument 7 Argument 8 Argument 4 Argument 5 Argument 6 Parameter 1 Parameter 2 Parameter 3 Parameter 7 Parameter 8 Parameter 4 Parameter 5 Parameter 6 Sincronization State Machine Done Run SignalFigura 5.7: Interface do Modelo de Tarefas de Hardware
IRQ DataW EN DataR
0
1
2
3
4
5
6
7
Control Register
O bit o menos significativo deste registo é o EN(enable) e como o nome indica este bit é responsável por ativar/desativar a tarefa de hardware. O IRQ deste registo tem a simples função de ativar/desativar o sinal de interrupção da tarefa, dando assim a possibilidade ao utilizador de decidir se pretende que a tarefa gere interrupções ao processador, deste modo a tarefa de hardware consegue sinalizar o processador de que terminou de executar a sua tarefa. DataW e DataR permite ao utilizador definir o número de dados de escrita e de leitura (argumentos e parâmetros), podendo este número variar entre 0 a 8 dados.
A Figura 5.9 mostra a composição usada no registo de estado. Este registo é apenas de leitura, e permite consultar as informações básicas sobre a execução de uma tarefa de hardware, sendo este basicamente para uso de depuração da tarefa.
Done State RUN
0
1
2
3
4
5
6
7
- - - -
Status Register
Figura 5.9: Registos Modelo de Tarefas
O primeiro bit ou bit menos significativo deste registo, denominado de RUN, indica que o sinal de Run da interface se encontra ativo, o que significa que a tarefa se encontra em execução. E quando a tarefa termina a sua execução, a tarefa lança ativa o sinal de Done e nesse momento o registo de estado é atualizado com o valor de Done. O state presente neste registo informa o estado atual em que a tarefa se encontra, assumindo os seguintes valores: ‘00’ para estado READ, ‘01’ para RUN e ‘10’ para o estado POST.