Relatório do Modulo Integrador de Sistemas Digitais

...

Dentre as características do Nios II, pode-se citar que ele possui 32 registradores de propósito geral, com instruções e endereçamento de 32 bits. Além disso, o cache é dividido entre endereços de dados e de instruções, sendo possível a configuração do tamanho da memória dedicado para endereçamento e instruções.

[pic 2]

Figura 2: Arquitetura interna do processador Nios II.

Na figura 2 é mostrada a arquitetura interna do Nios, como o sistema de memórias (SDRAM, SRAM e Flash), o núcleo de processamento e os periféricos.

2.3 Software JNIOSEmu

Tendo em vista que o desenvolvimentos dos códigos assemblies foi para o processador Nios II, foi utilizada a ferramenta JNiosEmu (Disponível em: http://stpe.github.io/jniosemu/) como ambiente de trabalho. O JNiosEmu é um ambiente de desenvolvimento e emulador desenvolvido para permitir programação em assembly, facilitando assim a montagem e execução do código. Outro objetivo com o desenvolvimento do JNiosEmu foi permitir programação em Assembly sem a necessidade de conhecimento prévio de um conjunto de ferramentas complexas.

O propósito do JNiosEmu é fornecer uma ferramenta fácil de usar na qual o usuário possa experimentar programação usando o assembly. O aplicativo não é um ambiente de compilação completa. O que ele faz é emular um sistema simples, incluindo registros, memória e dispositivos de E/S básicos que permite que o usuário execute instruções do assembly. O JNiosEmu não emula pipeline e caches, apenas um subconjunto da plataforma Nios II é suportado. Na figura 3, podemos observar o programa JNiosEmu executando um código em assembly.

[pic 3]

Figura 3 - JNiosEmu

3. Metodologia

O processo de elaboração do software foi dividido em etapas, que foram ditadas a partir das metas das sessões tutoriais. Estas sessões são reuniões nas quais ocorrem as discussões a cerca do produto que deve ser concebido. Nelas, os integrantes podem expor suas ideias e discutir possibilidades de implementação. Além disso, há papéis que cada integrante deve ocupar, como por exemplo, atuar na coordenação ou ser responsável pelo relatório da sessão. Esta dinâmica de papéis exercidos pelos componentes é rotativa, sendo assim, todos exercem os mesmos, e é possível então, nivelar a participação de todos.

Abaixo seguem os tópicos relacionados às discussões que auxiliaram na resolução do problema.

Análise do simulador JNIOSEmu: Um dos primeiros pontos discutidos nas sessões tutoriais foi acerca do simulador que seria utilizado, visto que esta seria a base de desenvolvimento e orientaria os passos para a implementação do produto final. A decisão tomada pelo grupo foi de fazer uma revisão bibliográfica sobre o software em questão, juntamente com a análise do seu manual de uso, além de fazer testes de usabilidade para verificar as funcionalidades do software.

Avaliação da complexidade de programação e limitações do dispositivo: Também foi discutido um dos objetivos do problema: a avaliação das limitações do dispositivo, que afetariam diretamente o desenvolvimento dos programas. Para tanto foi decidido pela equipe fazer uma revisão bibliográfica sobre o ISA (Instruction architecture set) do processador trabalhado em questão, de modo a dominar todo o conjunto de instruções necessárias para a implementação dos programas em assembly.

Entrada de dados: Outro ponto discutido durante as sessões foi sobre como seria feita a entrada de dados. Foi levantada a possibilidade de permitir números de um ou dois dígitos e chegou-se à conclusão de que isso ficaria a cargo de cada equipe, como uma decisão de projeto.

Programas de teste: Tendo em vista que o objetivo principal do problema é desenvolver os programas de teste, tal etapa foi exaustivamente discutida, levantando possibilidades de implementação em alguns programas. Para o algoritmo de Fibonacci, foi discutido algumas possibilidade como a de ter como saída a sequência de Fibonacci completa até um determinado limite, ou ter como saída o valor da sequência de Fibonacci em uma determinada posição. No caso do algoritmo de Bubble Sort foi discutido a possibilidade de permitir a entrada informando o tamanho do vetor, juntamente com os elementos que integrariam o mesmo. Outra possibilidade foi a de manter um vetor de tamanho fixo e solicitar ao usuário apenas os elementos que seriam armazenados no mesmo.

4. Resultados e decisões de projeto

Os tópicos abordados nas sessões tutoriais levantaram algumas ideias acerca da elaboração do produto final. No entanto, havia diversas possibilidades de implementação para as mesmas funções e coube a cada desenvolvedor escolher quais seriam utilizadas em seus programas.

Sendo assim, a primeira decisão a ser tomada foi acerca da saída que seria gerada pelo programa responsável pela sequência de Fibonacci. A opção escolhida foi a de implementar a saída como sendo o valor da sequência em uma determinada posição. Por exemplo: caso o usuário insira o valor 05, será exibido o valor da sequência na quinta posição. Tal decisão foi tomada de forma a facilitar a implementação, sem comprometer a essência do algoritmo. Vale ressaltar que na literatura encontram-se resultados que apontam que a sequência começa a partir do valor zero, bem como resultados que apontam que a sequência começa a partir do valor um, ou seja, aparentemente não se tem um consenso sobre isso. Sendo assim, a decisão de projeto da equipe foi de iniciar a sequência a partir do valor um: 1, 1, 2, 3, 5, 8… e assim por diante. Outras observações é de que este programa foi implementado de forma recursiva, o resultado final é armazenado no registrador r1 e a entrada é composta por números de dois dígitos.

No que diz respeito ao programa responsável pelo algoritmo de Bubble Sort foi necessário decidir qual seria a dinâmica para determinar o tamanho e preencher o vetor a ser ordenado. A opção escolhida foi de determinar um tamanho fixo para o vetor, neste caso o tamanho de cinco elementos. e solicitar ao usuário somente os valores necessários para preencher o mesmo. Tal decisão foi tomada devido à dificuldades de implementação de um loop necessário para capturar quantidades indeterminadas de entradas. Embora o tamanho do vetor esteja fixo, sabe-se que o objetivo do algoritmo ainda está presente e é possível demonstrar