Para implementar a função ‘load_context’ usar-se-á uma máquina de estados com 20 estados, sendo um estado parado, um estado inicial para o arranque, um estado de finalização e os restantes 17 são condicionados pelo acesso à memória e receção dos dados. Em simultâneo serão efetuadas a operação de junção dos valores do registo de supervisão e a salvaguarda dos valores recebidos/calculados nos registos respetivos. Para diminuir o overhead da leitura de R1, que guarda o
A função ‘hal_thread_load_context’ é um método da classe ‘cyg_hardware_thread’ e está implementada em assembly. Esta função opera em duas fases sequenciais:
Para migrar esta função para hardware operar-se-á em duas fases também, a primeira será composta por uma máquina de estados com pelo menos 19 estados compostos por um estado idle, um estado de início e outro de fim e 16 outros obrigatórios, devido aos acessos para escrita na memória de dados. Em simultâneo efetuar-se-á as operações necessárias aos dados para este
a instrução de salto com o uso do link register e uma instrução ‘NOP’. Esta adição será feita porque ‘context_switch’ em hardware chamará ‘load_context’ em hardware sem que o processador tenha conhecimento, logo se esta adição não fosse efetuada, o CPU executaria a próxima instrução, que neste caso seria ‘le.ht 0x1’. A nível de execução não haveria diferença, visto que efetuaria o mesmo resultado porque chamaria a função ‘load_context’, no entanto aumentaria o overhead desta operação de dois pulsos de relógio, isto porque ‘insn_rtos’ viria a zero e voltaria novamente ao valor ‘1’.
Como a FSM ‘context_switch’ terá que ativar a FSM ‘load_context’ será necessário criar uma condição que permite ativar o enable da função ‘load_context’, após ‘context_switch’ terminar.
Neste subcapítulo estão apresentados alguns esquemáticos da implementação final resultante do gateware efetuado. Estes esquemáticos foram obtidos através da ferramenta RTL-viewer presente no IDE da Xilinx, após ter sintetizado o código de descrição de hardware desenvolvido. Estes esquemáticos representam em gate-level os seguintes módulos:
hardware RTOS desenvolvido no interior do processador. Estas ligações entre estes dois módulos passam pela ligação ao register File, special purpose register e ao módulo de freeze com o wire
Este capítulo demonstra quais foram as metodologias de teste aplicadas e as ferramentas usadas para a realização dos testes. Serão apresentados os resultados obtidos e para finalizar será efetuada uma análise a esses resultados.
‘MIBench’, esta suite de benchmarks é open-source e serve para medir e comparar a performance entre vários sistemas. Como dispositivo usou-se a placa XC5VLX110T-FF1136 da família Virtex5, em que o processador Or1200 estava sintetizado para funcionar com um clock de
Foram usados dois benchmarks do ‘Mibench’, o ‘bitcnt’ e o ‘stringsearch’, cada um realizado numa thread. Para ambos os benchmarks correrem no mesmo executável foi necessário criar um ficheiro ‘.c’ com a função ‘cyg_user_start’ que cria as threads com as funções ‘bitcnt’ e