WEAC2011-AnaisDigitais

Prévia do material em texto

WEAC 2011 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Workshop sobre Educação em 
Arquitetura de Computadores 
 
 
APRESENTAÇÃO 
 
 
 
O Workshop sobre Educação em Arquitetura de Computadores (WEAC) é um evento 
promovido pela comissão especial em Arquitetura de Computadores e Processamento de 
Alto Desempenho da Sociedade Brasileira de Computação (SBC). 
 
Em sua sexta edição, o WEAC 2011 conta com 5 artigos distribuídos em duas sessões 
técnicas. Destaca-se o empenho do Comitê de Programa durante o processo de avaliação. 
Cada artigo recebeu 3 avaliações que consideraram tanto o mérito técnico como a 
inserção nos tópicos de interesse do evento. 
 
Nesta edição, o WEAC promove um painel sobre o livro “Arquitetura de Computadores: 
educação, ensino e aprendizado”, cujo objetivo é discutir a aplicação do livro e de seus 
capítulos em disciplinas da graduação e pós-graduação. O WEAC promove também um 
grupo de discussão sobre a Revista Eletrônica de Educação em Arquitetura de 
Computadores (REEAC). O objetivo é a criação de um fluxo contínuo de submissões 
promovendo a divulgação de novas idéias sobre educação em Arquitetura de 
Computadores. 
 
 
Tenham todos um excelente workshop. 
 
 
 
Henrique Cota de Freitas 
Coordenação do WEAC 2011 
Vitória, 28 de outubro de 2011 
 
WEAC 2011 
Workshop sobre Educação em Arquitetura de Computadores 
 
 
Coordenação do WEAC 2011 
Henrique Cota de Freitas (PUC Minas) 
 
 
Comitê de Programa do WEAC 2011 
 
Carlos Augusto Paiva da Silva Martins (PUC Minas) 
Cesar Albenes Zeferino (UNIVALI) 
Cesar De Rose (PUCRS) 
Dilma M da Silva (IBM – USA) 
Edil Fernandes (UFRJ) 
Edson Midorikawa (USP) 
Eduardo Marques (USP) 
Edward David Moreno (UFS) 
Gabriel Pereira da Silva (UFRJ) 
Henrique Cota de Freitas (PUC Minas) 
Ivan Saraiva Silva (UFPI) 
Joao Angelo Martini (UEM) 
Manoel Eusébio de Lima (UFPE) 
Maurício Pilla (UFPEL) 
Nahri Moreano (UFMS) 
Philippe Olivier Alexandre Navaux (UFRGS) 
Rafael dos Santos (CEITEC) 
Rafael Dueire Lins (UFPE) 
Raimundo Barreto (UFAM) 
Ricardo Santos Ferreira (UFV) 
Roberto A Hexsel (UFPR) 
Rodolfo Jardim de Azevedo (UNICAMP) 
Romanelli Lodron Zuim (PUC Minas) 
Ronaldo Augusto de Lara Gonçalves (UEM) 
Sandro Neves Soares (UCS) 
Sandro Rigo (UNICAMP) 
Sérgio Takeo Kofuji (USP) 
 
SUMÁRIO 
 
 
 
Metodologia de Ensino Orientada a Projetos e Criação de Material Didático aplicada 
ao Projeto de Processadores 
Ricardo Duarte (UFMG), Pedro Donoso-Garcia (UFMG) 
 
 
1 
Simuladores de Memória Cache, um Estudo Comparativo Direcionado ao Ensino 
Matheus Xavier (IFCE), Jardel Rodrigues (IFCE), Otávio Júnior (IFCE) 
 
 
7 
Extensão do Ptolemy para o ensino de Organização e Arquitetura de Computadores 
André Torres (UFPB), Alisson Brito (UFPB) 
 
 
13 
Arquitetura de Computadores em uma Simples Folha de Papel 
Ricardo Ferreira (UFV) 
 
 
19 
BIP IV: Especificação e Suporte na Ferramenta Bipide 
Paulo Rech (UNIVALI), Paulo Vieira (UNIVALI), Cesar Zeferino (UNIVALI), André 
Raabe (UNIVALI) 
 
25 
 
 
 
Metodologia de Ensino Orientada a Projetos e Criação de Material Didático 
aplicada ao Projeto de Processadores 
 
 
Ricardo de Oliveira Duarte, Pedro Francisco Donoso Garcia 
Depto. de Engenharia Eletrônica – Escola de Engenharia 
Universidade Federal de Minas Gerais 
Av. Antônio Carlos, 6627 – Campus da Pampulha – CEP 31.270-901 – Belo Horizonte, MG 
(ricardoduarte@ufmg.br, pedro@cpdee.ufmg.br) 
 
 
Resumo 
 
Este artigo descreve uma experiência de produção de 
material didático para o ensino do projeto de 
processadores para uma disciplina teórica e prática 
conhecida por Sistemas, Processadores e Periféricos 
obrigatória aos cursos de Graduação em Engenharia 
Elétrica, Engenharia de Controle e Automação e 
Engenharia de Sistemas da UFMG. A construção de 
materiais didáticos desenvolvidos para essa disciplina 
segue diretrizes encontradas em metodologias ativas 
de ensino orientadas a projetos. É considerada uma 
proposta para atividades de laboratório, motivando os 
alunos a adquirir e construir seu próprio 
conhecimento através da auto-aprendizagem com 
materiais didáticos desenvolvidos especificamente 
para este fim. Os alunos tomam decisões de projeto e 
apresentam suas próprias soluções, ao invés da 
simples repetição de tarefas pré-determinadas 
encontradas em metodologias de ensino práticas 
baseadas em guias de aula. Os resultados observados 
são o aumento da motivação, do aprendizado e da 
participação dos alunos nas aulas e atividades 
propostas. 
 
 
1. Introdução 
 
Este artigo trata do relato de caso da aplicação da 
metodologia de Ensino Orientado a Projetos e o 
desenvolvimento de material didático para uma 
disciplina prática de laboratório cujo nome é Sistemas, 
Processadores e Periféricos (SPP). Essa disciplina é 
obrigatória aos cursos de Engenharia Elétrica, 
Engenharia de Controle e Automação e Engenharia de 
Sistemas na UFMG, onde o aprendizado do projeto de 
processadores é um dos objetivos. 
O material didático desenvolvido foi norteado pela 
metodologia de ensino que tem seus princípios 
inspirados na metodologia conhecida como Problem 
Based Learning – PBL, amplamente divulgada em 
literatura [1]. O elemento chave dessa metodologia de 
ensino é a forma como os alunos propõem a solução 
para um projeto em Engenharia enunciado, por meio 
dos conhecimentos adquiridos e na integração deles 
com outros conhecimentos. A partir da identificação 
dos requisitos mínimos determinados pelo projeto 
proposto pelo professor, inicia-se o fracionamento do 
projeto em etapas, que necessita de profundo 
entendimento de conceitos, análise e técnicas 
envolvidas na sua solução. O aluno é incentivado a 
construir seu próprio aprendizado estudando os 
conceitos em material didático cuidadosamente 
desenvolvido para esse fim e de outros 
disponibilizados, para a realização de sua própria 
solução da situação-problema proposta. 
O aluno é orientado a definir, documentar, 
implementar seu próprio projeto e testá-lo em 
laboratório. O professor atua como orientador das 
atividades propostas e trabalha como ator facilitador da 
construção do conhecimento de cada estudante, 
esclarecendo dúvidas sobre seus projetos, sugerindo 
alternativas de projeto e referências bibliográficas para 
o desenvolvimento das soluções, além de avaliar o 
aprendizado e o envolvimento do aluno no projeto. 
Essa metodologia de ensino já vem sendo 
empregada em algumas disciplinas do curso de 
Engenharia Elétrica e de Engenharia de Controle e 
Automação, mas especificamente nas disciplinas de 
laboratório de Eletrônica I, Eletrônica de Potência e 
Controle I na UFMG desde 2006. Conforme observa 
Donoso-Garcia, professor da disciplina de laboratório 
de Eletrônica I, “tal abordagem no âmbito da 
Engenharia se aproxima muito do modus operandis, 
encontrado em diversas indústrias no desenvolvimento 
de novos produtos tecnológicos” [2]. A partir de uma 
especificação parcial de um conjunto de instruções e 
requisitos da arquitetura, o aluno é convidado a 
envolver-se ativamente com o processo de criação da 
sua própria solução. O desenvolvimento do 
processador é realizado seguindo orientações gerais 
passadas pelo professor da disciplina. Como o aluno é 
responsável por suas próprias decisões de projeto, isso 
faz com que o seu aprendizado se torne mais 
agradável, estimulante e próximo da realidade 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
1
 
 
enfrentada na vida profissional de um engenheiro. Para 
que isso se torne uma realidade, um conjunto de 
objetos multimidiáticos, enfatizando os conceitos e a 
base teórica necessária ao desenvolvimento da 
situação-problema deve ser desenvolvido e apresentado 
ao aluno no início das atividades da disciplina. O 
enfoque desse trabalho concentra-se no relato de um 
caso de aplicação de uma metodologia de ensino 
orientada a projetos e a criação do material didático 
voltadoao projeto de processadores nas aulas práticas 
da disciplina SPP. 
A abordagem de ensino orientada a projetos 
possibilita a valorização das habilidades e 
competências individuais de cada aluno e também 
estimula o trabalho em grupo, pois implica na 
constante troca de experiências dos atores envolvidos 
no processo. Essa abordagem também estimula o 
professor que ministra a disciplina a cada semestre por 
vivenciar diferentes soluções e situações práticas com a 
cada situação-problema proposta. Para cada semestre 
letivo, o professor pode e deve elaborar uma nova 
situação-problema, de forma que os alunos se sintam 
motivados e desafiados a desenvolver um trabalho 
inédito. 
A teoria tem uma importância substancial e não é 
menosprezada, mas prioritariamente se enfatiza que 
esta serve como subsídio para a realização de trabalhos 
práticos, e não apenas uma simples memorização de 
conceitos teóricos, sem relacionamento com a prática. 
Os alunos têm sido incentivados a serem atores 
participantes do ensino e não apenas receptores de 
informações prontas. Por outro lado, o professor 
torna-se um gestor de ensino, auxiliando e provendo 
suporte para o aprendizado dos alunos e não apenas 
repetindo conteúdo teórico extraído de livros. 
Nas aulas de laboratório onde são utilizados os 
guias ou roteiros contendo descrição de experimentos, 
estes se mostram repetitivos e muitas vezes desconexos 
com a evolução inerente de certos temas abordados em 
disciplinas de uma área tecnológica. Desta forma, o 
aluno desenvolve menos sua criatividade. 
O artigo está organizado da seguinte forma: Na 
seção 2 apresenta-se o contexto no qual a disciplina era 
ministrada até então, seus objetivos e as justificativas 
observadas para o desenvolvimento do um novo 
material didático e a mudança da metodologia de 
ensino. Na seção 3 apresenta-se a Estruturação do 
Projeto de construção do material didático. Na seção 4, 
apresenta-se uma síntese dos Materiais e Métodos 
desenvolvidos para a aplicação da metodologia de 
ensino orientada a projetos, empregada na disciplina. O 
método de avaliação utilizado também é brevemente 
relatado nessa mesma seção. Na seção 5, apresenta-se 
uma descrição dos resultados alcançados. 
Considerações finais compõem a última seção. 
 
 
2. Contextualização 
 
SPP é uma disciplina obrigatória para três cursos 
de graduação da UFMG: em Engenharia Elétrica, em 
Engenharia de Controle e Automação e em Engenharia 
de Sistemas, totalizando aproximadamente 150 alunos 
matriculados a cada semestre. SPP é composta de uma 
carga horária semestral de 45 horas de aulas teóricas e 
30 horas de aulas práticas em laboratório (total de 
75h/semestre). Todas as aulas teóricas acontecem 
concomitantemente com as aulas práticas. A disciplina 
SPP é de caráter formativo do aluno na área de 
Projetos de Sistemas Digitais dos cursos supracitados e 
tem como pré-requisitos às disciplinas de Sistemas 
Digitais e Laboratório de Sistemas Digitais, onde o 
enfoque de projetos de sistemas digitais modernos 
baseados em linguagens de descrição de hardware e 
uso de dispositivos lógicos programáveis deve ser 
ensinado e praticado em aulas de laboratório. 
De forma geral, os objetivos da disciplina SPP são de 
capacitar o aluno para: 
a) O entendimento do funcionamento e o projeto 
de um processador, suas partes, como estas se 
integram e se comunicam para realizar 
funções para as quais foi projetado. 
b) Identificação e caracterização de um 
periférico, sua forma de comunicação com 
processadores e seus modos de operação. 
Antes do desenvolvimento do material didático 
aqui apresentado, as aulas de laboratório desta 
disciplina eram baseadas em roteiros com experiências 
bem definidas e repetitivas, onde o aluno executava 
tarefas pré-determinadas, devendo apresentar 
pré-relatórios no início de cada aula de laboratório ao 
professor da disciplina. Desta forma, os pré-relatórios 
permitiam identificar se o aluno havia estudado o 
assunto previamente e se preparado para as atividades 
presenciais da aula prática da semana. Os roteiros de 
laboratório da aula prática estavam sempre atrelados ao 
assunto dado na aula teórica da semana. 
Para se alcançar o primeiro objetivo geral da 
disciplina, o professor apresentava em sala de aula o 
desenvolvimento de um processador definido para fins 
didáticos, conhecido por MIC-1 [3]. O projeto desse 
processador era dividido em oito aulas práticas na 
forma de roteiros de atividades. O aluno era convidado 
a projetar o processador MIC-1 na linguagem de 
descrição de hardware VHDL e validá-lo através de 
um simulador de códigos de descrição de hardware 
produzidos da mesma linguagem. O segundo grande 
objetivo dessa disciplina era alcançado com o estudo 
de periféricos e sua programação na linguagem 
Assembly da arquitetura da família de processadores da 
Intel™. Esse objetivo era alcançado em sete aulas 
práticas, sendo cada uma com o seu próprio roteiro de 
atividades abordando a programação de um periférico. 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
2
 
 
Relatos dos alunos descreviam a pouca motivação 
pelas aulas práticas devido a constante repetição e 
constatação de resultados descritos nos roteiros. 
Também relatavam sobre as aulas, que por se tratarem 
de atividades repetitivas já vivenciadas e desenvolvidas 
por alunos de turmas anteriores, não se sentiam 
motivados a preparar os pré-relatórios, tornando essa 
atividade um mero cumprimento de tarefas decorrentes 
da metodologia de ensino empregada na disciplina. 
Com a metodologia baseada em roteiros de aulas, os 
professores percebiam o baixo interesse e a pouca 
motivação dos alunos. Em geral os alunos não 
percebiam a razão de estarem estudando certos 
assuntos, por não terem a noção do todo. Todos esses 
sinais apontavam para a necessidade de mudança na 
estratégia de ensino. 
 
3. Estruturação do material da disciplina 
 
A metodologia de ensino proposta para essa 
disciplina é centrada no Ensino Orientado ao Projeto, 
baseada em aliar a teoria à prática, apresentando 
conceitos teóricos fundamentais, mas sempre 
procurando exemplificar aos alunos como aplicá-los 
[1]. A teoria usada para a base do desenvolvimento dos 
objetos de ensino utilizados na disciplina SPP foi 
baseada em livros-texto contemporâneos, referência 
das áreas, de Sistemas Digitais [4], Arquitetura e 
Organização de Computadores [5] e Projetos com 
Microcontroladores [6]. 
A fim de alcançar o primeiro objetivo da disciplina 
(mencionado na seção 2) e com base nos livros-textos 
citados foi desenvolvido o material didático contendo 
teoria e aspectos práticos do projeto de processadores. 
Um sequenciamento completo do projeto de um 
processador dividido em etapas foi elaborado. Um 
exemplo completo de projeto de um processador foi 
apresentado, desde a especificação de requisitos, 
seguindo cada uma das etapas do sequenciamento de 
projeto citado. Desta forma, os alunos são orientados 
ao estudo, ao desenvolvimento e à documentação dos 
procedimentos realizados para seus projetos. 
Paralelamente para cada etapa de projeto, documentos-
modelos foram elaborados, no intuito de manter um 
padrão de documentação de projeto e facilitar a 
avaliação dos trabalhos. Alcançando-se o primeiro 
objetivo da disciplina, na oitava aula, é realizado um 
Workshop, onde os alunos testam por completo seus 
projetos em um kit de desenvolvimento de projetos 
baseado em dispositivo lógico programável (FPGA – 
Field Programmable Gate Arrays), e apresentam seus 
trabalhos. Neste evento são incentivados a discussão 
dos trabalhos, com aportes de novas idéias baseadas na 
experiência adquiridas pelos alunos. 
Uma apostila focando o segundo objetivo da 
disciplina, que é o de identificar e caracterizar um 
periférico e desenvolver pequenos sistemas com o uso 
do mesmo, também foi desenvolvida [7]. Essa apostila 
contém o material teórico mínimo e aplicação da teoria 
nas atividades práticas relacionada ao estudo deperiféricos de um microcontrolador, sua programação e 
o desenvolvimento de pequenos sistemas, utilizando-se 
os periféricos estudados. Exemplos de programação e 
uso de cada periférico são apresentados em cada seção 
da apostila. Complementando o material 
disponibilizado para os alunos, foram selecionados 
manuais, tutoriais e folhas de dados de processadores e 
microcontroladores comerciais e material de apoio, 
(softwares e tutoriais) que auxiliam o aluno no uso das 
ferramentas empregadas no laboratório e na realização 
dos trabalhos propostos. 
Todo o material didático desenvolvido foi 
estruturado de forma a permitir seu crescimento e 
atualização com outras técnicas de projeto de 
processadores que venham a ser agregadas, sem ser 
necessário efetuar modificações nos objetos de 
aprendizagem já produzidos. 
 
4. Materiais e métodos 
 
As condições mínimas de utilização de 
equipamentos e material didático existente em 
laboratório para realização das atividades práticas 
devem estar funcionalmente disponíveis desde o 
primeiro dia de aula. O material didático é constituído 
de kits DE2-Altera de dispositivos lógicos 
programáveis para cada grupo de alunos, capazes de 
ser reconfigurados por software Quartus II - Altera [8], 
[9]. Os kits de dispositivos lógicos programáveis 
necessitam de um microcomputador com todo o 
software necessário ao desenvolvimento do projeto, 
instalados em cada bancada para cada grupo de alunos. 
A caracterização da forma semi-presencial da 
disciplina, onde o estudo e o desenvolvimento das 
etapas de projeto do processador e da programação de 
pequenos sistemas com o uso de periféricos, bem como 
o envio dessas atividades de cada etapa semanalmente 
ao professor demandam o apoio de uma plataforma de 
ensino a distância. A plataforma Moodle – Minha 
UFMG é utilizada intensamente, onde professores, 
monitores-bolsistas e alunos a utilizarão como meio 
para consulta ao material didático, esclarecimento de 
dúvidas, troca de informação através dos fóruns para 
realização das atividades propostas. Semanalmente, 
todos os grupos de alunos devem submeter suas tarefas 
de cada etapa de projeto para apreciação e comentários 
do professor dentro de um prazo estabelecido pelo 
mesmo. 
As atividades presenciais semanais em laboratório 
consistem na realização de testes por parte dos alunos 
das atividades a distância que desempenharam na 
semana. Esses testes são realizados utilizando-se os 
kits de desenvolvimento de projetos [8]. 
Esclarecimentos de dúvidas remanescentes com o 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
3
 
 
professor da disciplina são também tratadas 
presencialmente nesses encontros. Ainda dentro do 
tempo de aula, o professor avalia a participação 
individual e o conhecimento de cada aluno sobre os 
assuntos tratados na etapa. 
Um recurso didático importante desenvolvido para 
a aplicação dessa metodologia de ensino é a vídeo-
aula. As vídeo-aulas foram construídas a partir de 
narrações de animações produzidas respectivamente 
com os softwares Camtasia Studio© e Microsoft 
PowerPoint©. As vídeo-aulas apresentam de forma 
concisa e objetiva toda a teoria e o sequenciamento de 
projeto, apresentando as etapas para o desenvolvimento 
de um processador. Desta forma, um exemplo do 
projeto de um processador completo é apresentado nas 
vídeo-aulas, sugerindo ao aluno como aliar a teoria à 
prática. A Figura 1 mostra o sequenciamento de etapas 
de projeto do processador proposto ao aluno 
desenvolvido com base nos livros-texto citados [4][5]. 
Adicionalmente foram elaboradas dez guias de projeto 
que orientam passo a passo os alunos no 
desenvolvimento e documentação de suas soluções nas 
referidas etapas de acordo com modelos fornecidos 
para cada fim. 
 
 
Figura 1. Sequenciamento do Projeto. 
 
Em síntese geral o material didático produzido para a 
disciplina é composto pelos seguintes artefatos: 
 
a) Um planejamento de aulas sugestivo para a 
parte teórica da disciplina, contendo o assunto 
que deverá ser tratado em cada aula, material 
de referência e a conexão com as atividades 
fim, tratadas em laboratório. 
b) Um planejamento de atividades em 
laboratório, contendo o objetivo de cada 
atividade presencial, material que deverá ser 
produzido pelo aluno na etapa e material de 
referência disponível ao aluno para a 
execução da etapa. 
c) Nove vídeo-aulas com animações explicando 
a base teórica necessária para o aluno projetar, 
documentar e desenvolver sua própria solução 
para a situação-problema proposta. 
d) Um documento contendo as especificações de 
requisitos mínimas do processador proposto. 
e) Dez guias de projeto, as quais orientarão os 
alunos nas atividades de documentação, 
implementação e validação de suas soluções 
para submissão da tarefa semanal. 
f) Material para referência no desenvolvimento 
dos projetos. Esse material fica disponível no 
ambiente Moodle – Minha UFMG para acesso 
dos alunos e também no repositório de objetos 
de aprendizagem GIZ-UFMG [10] e está 
organizado em sumários, aula a aula (vide 
Figura 2). Estão disponíveis materiais para 
aprendizado e consulta sobre aspectos 
relacionados à Linguagem de Descrição de 
Hardware; Material de referência e usuário do 
Kit de desenvolvimento e do ambiente de 
programação que o aluno deverá usar para 
validar a sua solução. 
g) Um modelo para elaboração de cada etapa de 
projeto do processador, que cada grupo de 
alunos deverá submeter à apreciação do 
professor pelo ambiente Moodle. 
h) Um exemplo completo do projeto de um 
processador, seguindo as etapas do 
seqüenciamento de projeto apresentado, 
acompanhado de toda documentação 
necessária: códigos e simulações utilizados no 
projeto, conforme modelo sugerido pelo 
professor. 
i) Um roteiro sugestivo de avaliação de 
trabalhos dos workshops para o professor. 
j) Um documento informativo para o aluno 
contendo os critérios que são utilizados na 
avaliação dos workshops. 
k) Uma apostila com a teoria mínima necessária 
ao projeto de sistemas com 
microcontroladores e seus periféricos. 
 
A Figura 2 mostra um sumário do curso 
organizado no ambiente Moodle. Cada sumário está 
associado a uma aula e a uma etapa do sequenciamento 
do projeto do processador. Todas as aulas são 
apresentadas de forma padronizada, contendo os 
seguintes itens: objetivo da aula; material que o grupo 
deverá produzir; material para estudo e atividades 
propostas, separadas em documentos, vídeo-aulas e 
softwares. Cada aula também apresenta um link para 
submissão das tarefas da etapa de projeto para 
avaliação e comentários do professor. 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
4
 
 
 
Figura 2. Organização da Disciplina no Moodle 
 
A Figura 3 apresenta um slide de uma das nove 
vídeo-aulas, visualizada com o auxílio de um 
navegador de Internet. Observa-se uma via de dados de 
um processador simples de três instruções. A esquerda 
dessa imagem observa-se um recurso utilizado na 
criação dos vídeos, de grande utilidade para o aluno, 
que é a navegação por slides utilizados na produção da 
aula. Esse recurso possibilita ao aluno interromper e 
voltar a assistir o vídeo de onde parou sem se 
preocupar em tomar nota do tempo do momento no 
qual parou de assistir. 
 
 
Figura 3. Imagem com o Trecho de uma Vídeo-aula 
 
4.1. Aplicação do material produzido 
 
Na primeira aula de SPP é apresentada a proposta 
da disciplina, mostrando os objetivos, a metodologia de 
trabalho e o material que o aluno terá a disposição para 
desenvolver sua solução, bem como as formas das 
atividades avaliativas. Os alunos são agrupados em 
duplas ou trios, para realizar todas as atividades 
propostas no semestre. Cada grupo seguirá seu próprio 
projeto, tomará suas próprias decisões e proporá uma 
solução. Incentiva-se a discussão entre os membros de 
um grupo para definir as possíveis decisões sobre as 
etapas de projeto do processador. 
A disciplina de SPP tem dois objetivosclaros e 
distintos, citados na seção 2. Cada objetivo é tratado 
em um módulo composto por sete aulas de 2h/aula. No 
início do primeiro módulo é apresentado ao aluno uma 
situação-problema do módulo, ou seja, o documento de 
requisitos mínimos de projeto do processador no 
semestre, também são apresentados os instrumentos 
que ele terá a sua disposição para desenvolver a sua 
própria solução e o modo de utilizá-los. Nas seis aulas 
subsequentes do módulo 1, cada dupla deverá criar, 
desenvolver, testar e documentar sua solução com o 
acompanhamento e a orientação presencial do 
professor responsável pela turma. Na última aula do 
módulo, cada grupo deverá apresentar sua solução para 
a turma. Essa último aula presencial funciona como um 
workshop. As últimas sete aulas compõem o segundo 
módulo, onde pretende-se alcançar o segundo grande 
objetivo da disciplina. O objeto de aprendizado 
principal desse segundo módulo é a apostila, que 
apresenta sete situações-problemas, que induzem o 
grupo de alunos a criarem suas próprias soluções. 
A avaliação da disciplina é realizada por meio de 
avaliações parciais semanais e no final de cada 
módulo. Os alunos são arguidos individualmente 
semanalmente e são atribuídos conceitos ao grupo e a 
cada aluno do grupo, em cada etapa de projeto. 
 
5. Resultados 
 
Os objetos de aprendizado desenvolvidos segundo 
a metodologia do Ensino Orientado a Projetos se 
encontram disponíveis, à comunidade da UFMG, no 
repositório de objetos de aprendizado do GIZ – Rede 
de Desenvolvimento de Práticas de Ensino Superior, 
vinculado a Pró-Reitoria de Graduação da UFMG sob 
a licença Creative Commons [10]. 
Essa metodologia de ensino com todos os objetos 
de aprendizagem desenvolvidos vem sendo aplicada há 
dois semestres na disciplina SPP (2010/2 e 2011/1). 
Resultados quantitativos a partir de enquetes com os 
alunos sobre as disciplinas e os professores são obtidos 
e divulgados semestralmente pela Pró-Reitoria de 
Graduação da UFMG. Um total de 269 alunos já 
cursou esta disciplina utilizando essa metodologia de 
ensino. A figura 4 mostra quantitativamente a 
afirmação sobre o aumento da motivação dos alunos na 
disciplina diante da metodologia de ensino proposta 
nesse trabalho. O gráfico de barras da Figura 5 mostra 
que o aluno considera que seu aprendizado melhorou 
com a nova metodologia aplicada nos semestres de 
2010/2 e 2011/1. Ainda como resultado quantitativo da 
mesma enquete, 63% e 62% (respectivamente em 
2011/1 e 2010/2) contra 41% e 40% (respectivamente 
em 2010/1 e 2009/2) afirmam que o material didático é 
considerado como bom a muito bom. Os alunos 
afirmam que as vídeo-aulas propiciam uma base 
primordial para o desenvolvimento de seus projetos. 
Por fim, os documentos que acompanham o material 
didático e o desenvolvimento de um exemplo de 
projeto de um processador são objetos de 
aprendizagem essenciais para o sucesso da aplicação 
dessa metodologia. 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
5
 
Figura 4. Grau de motivação com relação à 
disciplina 
 
Figura 5. Meu aprendizado na disciplina
 
6. Considerações finais 
 
As vantagens da adoção dessa metodolo
ensino são muitas: (i) Alunos mais motivado
projetar, tomar decisões de projeto e analisar o impacto 
das decisões tomadas. Cabe-lhes desenvolver uma 
postura ativa perante o processo de aprendizagem e 
reconhecer que o professor não é mais o único a 
decidir sobre os caminhos a serem seguidos. 
professor, essa metodologia de ensino
proporciona uma dinâmica constante a cada seme
em que uma nova situação-problema é elaborada e 
proposta aos alunos. O professor é o condutor da 
formação da experiência prática do aluno, mostrando 
os possíveis rumos a serem tomados e corrigindo erros 
conceituais que possam surgir no percurso
desvantagem: (i) necessita dedicação 
professor; (ii) demanda ferramenta de en
distância bem instalada, funcional e disponível
Vários tipos de objetos de aprendizagem podem 
ser desenvolvidos segundo essa metodologia, 
que o princípio que a norteia seja obedecido, 
aliar a teoria à prática para o desenvolvimento da 
situação-problema, conduzindo o aluno as suas 
próprias escolhas e decisões de projeto. 
materiais desenvolvidos, cabe destacar que
vídeo-aulas são um dos objetos de ap
principais desenvolvidos nesse trabalho. 
 
0%
10%
20%
30%
40%
50%
0%
10%
20%
30%
40%
50%
60%
 
Grau de motivação com relação à 
 
Meu aprendizado na disciplina 
As vantagens da adoção dessa metodologia de 
mais motivados para 
e analisar o impacto 
lhes desenvolver uma 
postura ativa perante o processo de aprendizagem e 
reconhecer que o professor não é mais o único a 
decidir sobre os caminhos a serem seguidos. (ii) Para o 
essa metodologia de ensino-aprendizagem 
proporciona uma dinâmica constante a cada semestre, 
problema é elaborada e 
proposta aos alunos. O professor é o condutor da 
ia prática do aluno, mostrando 
is rumos a serem tomados e corrigindo erros 
no percurso. Como 
desvantagem: (i) necessita dedicação intensiva do 
professor; (ii) demanda ferramenta de ensino a 
distância bem instalada, funcional e disponível. 
objetos de aprendizagem podem 
segundo essa metodologia, desde 
que a norteia seja obedecido, ou seja, 
prática para o desenvolvimento da 
conduzindo o aluno as suas 
sões de projeto. Dentre os 
, cabe destacar que as 
de aprendizado 
nesse trabalho. 
Agradecimentos 
A Pró-Reitoria de Graduação da UFMG
financeiro ao projeto de desenvolvimento do material 
didático apresentado nesse artigo. 
 
 
7. Referências 
 
[1] Donoso-Garcia, P. F., Martins, L. F.; Cortizo, P. C. 
Ensino Orientado ao Projeto: Uma Experiência para o 
Ensino de Eletrônica nas disciplinas de laboratório de 
Eletrônica e Eletrônica de Potência. 
Potência (Florianópolis), v. 13, p. 109
 
[2] Donoso-Garcia, P. F., Torres, L. Ensino Orientado 
ao projeto desafio: uma experiencia para o ensino de 
controle, instrumentação e eletrônica. 
Brasileiro de Educação em Engenharia, 2007
XXXV COBENGE 2007. p. 3B05-
[3] Tanenbaum, A. S. Organização Estruturada de 
Computadores. 5ª Edição, Prentice Hall, 2006.
[4] Vahid, F. Sistemas Digitais: Projeto, Otimização e 
HDLs, Bookman, 2008. 
[5] Patterson, D. A., Hennessy, J. L. Organização e 
Projeto de Computadores - A Interface Hardware/ 
Software. 3a. Edição. Editora Campus, 2005. 
[6] de Oliveira, A. S. e Andrade, F. S. Sistemas 
Embarcados - Hardware e Firmware na Prática. 1a. 
Edição. Editora Érica, 2006. 
[7] Oliveira Junior, M., Duarte, R. O. Apostila sobre 
Introdução ao Projeto com Microcontroladores e 
Programação de Periféricos. DELT 
2011. Disponível por acesso restrito a comunidade da 
UFMG em: 
<https://dspaceprod01.grude.ufmg.br/dspace/handle/O
AUFMG/545/browse?type=title>, 
agosto de 2011. 
[8] Altera Corporation©: DE2 Development and 
Education Board User Manual –
Disponível para download
<http://www.abramovbenjamin.net/altera_
acessado em 24 de agosto de 2011.
[9] Altera Corporation©: Introduction to Quartus II 
Software - Version 10.0, 2011. 
<http://www.altera.com/literature/manual/archives/int
ro_to_quartus2.pdf>, acessado em 24 de agosto de 
2011. 
[10] Repositório da Rede de Desenvolvimento de 
Práticas de Ensino Superior, Pró
Graduação - UFMG. Disponível por acesso restrito em: 
<https://dspaceprod01.grude.ufmg.br/dspace/handle/O
AUFMG/545/browse?type=title>, 
agosto de 2011. 
Ruim
Médio
Bom
Muito bom
Ruim
Médio
Bom
Muito bom
 
ção da UFMG pelo suporte 
financeiro ao projeto de desenvolvimento do material 
Garcia, P. F., Martins, L. F.; Cortizo, P. C. 
Projeto: Uma Experiência para o 
Ensino de Eletrônica nas disciplinas de laboratório de 
nica e Eletrônica de Potência. Eletrônica de 
Potência (Florianópolis), v. 13, p. 109-116, 2008. 
Garcia, P. F., Torres, L. Ensino Orientado 
desafio: uma experiencia para o ensino de 
controle, instrumentação e eletrônica. In: Congresso 
Brasileiro de Educação em Engenharia, 2007, Curitiba. 
-1-3B05-15. 
] Tanenbaum,A. S. Organização Estruturada de 
ão, Prentice Hall, 2006. 
] Vahid, F. Sistemas Digitais: Projeto, Otimização e 
] Patterson, D. A., Hennessy, J. L. Organização e 
A Interface Hardware/ 
. 3a. Edição. Editora Campus, 2005. 
veira, A. S. e Andrade, F. S. Sistemas 
Hardware e Firmware na Prática. 1a. 
] Oliveira Junior, M., Duarte, R. O. Apostila sobre 
Introdução ao Projeto com Microcontroladores e 
ção de Periféricos. DELT – EE – UFMG, 
2011. Disponível por acesso restrito a comunidade da 
UFMG em: 
https://dspaceprod01.grude.ufmg.br/dspace/handle/O
>, acessado em 24 de 
DE2 Development and 
– Version 1.3, 2006. 
download em: 
http://www.abramovbenjamin.net/altera_de2.pdf>, 
. 
Introduction to Quartus II 
10.0, 2011. Disponível em: 
http://www.altera.com/literature/manual/archives/int
cessado em 24 de agosto de 
Rede de Desenvolvimento de 
or, Pró-Reitoria de 
UFMG. Disponível por acesso restrito em: 
https://dspaceprod01.grude.ufmg.br/dspace/handle/O
>, acessado em 24 de 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
6
Simuladores de Memória Cache, um Estudo Comparativo Direcionado ao 
Ensino 
Matheus Arleson Sales Xavier¹, Jardel das Chagas Rodrigues¹, Otávio Alcântara de Lima Júnior¹ 
¹Laboratório de Eletrônica e Sistemas Embarcados (LAESE) 
Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE) 
Av. Contorno Norte, 10 – CEP: 61925-315 – Maracanaú, Ceará 
matheusarleson@gmail.com, jardel.ifce@gmail.com, otavio@ifce.edu.br 
 
Resumo 
 
O conceito de memória cache é um tópico 
importante visto principalmente na disciplina de 
Arquitetura de Computadores, em cursos da área de 
computação. Esse é um assunto no qual muitos alunos 
sentem dificuldades, isso se deve ao cunho 
extremamente teórico das aulas na maioria dos cursos 
ofertados. Um simulador se mostra uma ferramenta 
importante neste cenário. Este artigo apresenta um 
estudo comparativo entre os principais simuladores de 
memória cache disponíveis, visando avaliar sua 
aplicabilidade como ferramenta de apoio ao ensino em 
cursos introdutórios de arquitetura de computadores. 
O estudo aponta que um dos principais empecilhos à 
aplicação destas ferramentas é a dificuldade em 
localizar estes aplicativos. 
 
1. Introdução 
 
No decorrer da evolução dos sistemas 
computacionais, a diferença de velocidade entre a 
unidade central de processamento e a memória 
principal se tornou um obstáculo ao aumento do 
desempenho dos computadores. Uma das formas 
encontradas para mitigar essa problemática foi o 
emprego de uma pequena porção de memória veloz e 
de custo mais elevado, denominada memória cache, 
localizada entre o processador e a memória principal. 
 A memória cache armazena temporariamente os 
dados e instruções que possuem maior probabilidade 
de serem usados pelo processador, reduzindo o número 
de acessos à memória principal. A memória cache é 
largamente empregada nas arquiteturas computacionais 
modernas. Sua utilização visa à melhora de 
desempenho do sistema. 
O conceito de memória cache está inserido na 
disciplina de Arquitetura de Computadores. Motivar os 
alunos a estudar Arquitetura de Computadores pode ser 
um problema quando o aluno acredita não ser 
necessário conhecer arquitetura para desenvolver 
softwares. O desafio em motivar os alunos pode não 
estar somente na disciplina de Arquitetura de 
Computadores, mas em todas as disciplinas de um 
curso, quando estas deixam ausente a correlação de 
importância com Arquitetura de Computadores [1]. 
Portanto, devem-se utilizar mecanismos para 
solucionar essa problemática e tornar a disciplina mais 
atrativa e menos complexa para os alunos. A utilização 
de simuladores didáticos contribui para uma melhor 
compreensão do assunto, uma vez que esses são 
capazes de traduzir para a realidade os conceitos 
teóricos através de uma introdução de forma clara e 
didática dos mesmos [2]. 
À medida que a complexidade e variedade de 
sistemas computacionais aumentam, a adequação 
desses como ferramentas pedagógicas nos cursos de 
Arquitetura de Computadores diminuem. Em 
consequência disso, muitos instrutores estão se 
voltando para simuladores como auxiliares de ensino, 
muitas vezes empregando o valioso tempo de 
ensino/pesquisa para construí-los [3]. Um simulador de 
memória cache pode ser utilizado para facilitar as aulas 
e auxiliar no aprendizado de sistemas computacionais 
modernos. 
O objetivo geral do artigo é realizar um estudo 
comparativo de alguns simuladores de memória cache e 
sua empregabilidade no ensino, com o intuito de 
facilitar o processo de seleção da ferramenta usada 
como apoio ao ensino em cursos introdutórios de 
arquitetura de computadores. Alguns simuladores já 
foram propostos com esse objetivo e os mesmos serão 
analisados no decorrer desse trabalho, dentre os quais 
foram selecionados: KSH [4], MSCSim [5], DCMSim 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
7
[6] e o Dinero IV [7]. O restante do trabalho está 
organizado em cinco seções. A seção 2 traz o conceito 
de memória cache e explica brevemente o seu 
funcionamento. A seção 3 do artigo detalha cada 
simulador. A seção 4 do artigo exibe os parâmetros de 
comparação e características desejáveis em um 
simulador utilizado no ambiente ensino-aprendizagem. 
A seção 5 faz um estudo comparativo dos simuladores. 
A seção 6 mostra as conclusões deste artigo. 
Finalmente, a última seção mostra as referências 
utilizadas nesse trabalho. 
 
2. Memória cache 
 
Ao passar dos anos, os processadores e outros 
dispositivos conseguiram um aumento incrível na 
velocidade de processamento das informações, o que 
não foi acompanhado pela memória principal, 
tornando-se lenta e atrasando as demais operações [8]. 
Na Figura 1 é mostrada claramente essa diferença. 
Nesse âmbito, precisava-se de uma unidade 
intermediária que acelerasse as operações que a 
envolviam. Ao analisar o comportamento dos 
programas, percebeu-se que o processador tende a 
referenciar endereços de memória próximos, devido ao 
grande uso de estruturas de repetições e dados, 
localizados um após o outro na memória [9]. 
 
Figura 1. Evolução de desempenho - 
Memória x CPU [8]. 
 
A Figura 2 mostra o posicionamento da memória 
cache no sistema, onde a mesma pode ser dividida em 
vários níveis de acordo com a proximidade da CPU, 
proporcionando uma melhoria no desempenho global. 
A cache mantém um bloco de informações, 
composto das posições de memória mais recentemente 
utilizadas, como também o conteúdo das posições de 
memória próximas, pois estas possuem alta 
probabilidade de serem acessadas nas próximas 
referências de memória . 
Figura 2. Esquema de uma memória cache 
[9]. 
 
Para que esta operação ganhe velocidade, a cache 
fica próxima ao processador e é feita deste mesmo 
material. Apenas quando um dado referenciado não 
está na cache, um acesso à memoria principal é feito. 
A Figura 3 apresenta um resumo das operações 
envolvidas na busca de uma posição de memória em 
um sistema empregando memória cache. 
 
Figura 3. Funcionamento da cache [9]. 
 
Embora existam diversas implementações, poucos 
elementos básicos de projeto servem para classificar e 
diferenciar as diversas arquiteturas. O primeiro deles: o 
tamanho da memória cache. Quanto maior, mais caro e 
rápido, até certo ponto, fica o sistema. Como a cache é 
feita do mesmo material do processador, o custo por bit 
é muito elevado e o tempo de procura é maior. A 
função de mapeamento determina como a cache é 
preenchida, podendo ser de forma direta: cada bloco da 
memória principal é mapeado para apenas uma linha de 
cache, associativa: um bloco pode ser alocado em 
qualquer linha da cache, associativa por conjunto: a 
cache é dividida em conjuntos, com certo número de 
linhas cada e um bloco pode estar associado a qualquer 
Workshop sobre Educação em Arquiteturade Computadores (WEAC 2011)
8
linha de um conjunto já pré-determinado. 
Os algoritmos de substituição determinam como os 
dados serão substituídos, podendo ser pelas técnicas: 
Least Frequently Used (LFU), os dados menos 
frequentemente utilizados serão substituídos; First In 
First Out (FIFO), o primeiro dado a entrar é o primeiro 
a sair; Least Recently Used (LRU), os dados menos 
recentemente usados são descartados primeiro; ou de 
forma aleatória. A política de escrita determina como 
os dados serão atualizados na memória principal, 
podendo ser de forma simultânea: write through ou os 
dados são escritos temporariamente na cache e depois 
na memória, o que denominamos write back. Por fim, o 
tamanho do bloco, que determina a quantidade de 
dados de um bloco alocado e a quantidade de níveis, 
para um sistema com vários níveis de cache. 
Atualmente a memória cache vem evoluindo e já não 
está apenas presente nos processadores, mas em quase 
todos os dispositivos que necessitam dessa aceleração, 
como os discos-rígidos, por exemplo. Podemos 
encontrar também sistemas com vários níveis de cache 
ou caches separadas para dados e instruções. 
 
3. Simuladores 
 
Esta seção analisa as características presentes nos 
simuladores, exibindo suas principais funcionalidades e 
modos de operação. 
No presente artigo foram escolhidos quatro 
simuladores para realização do estudo, entretanto 
outras ferramentas podem ser encontradas, como o 
SMPCache [10] e o Loop-way Cache [11], por 
exemplo. Alguns critérios para a escolha dos 
simuladores foram adotados, a saber: ou grau de 
exibição dos simuladores em relação às pesquisas 
realizadas na web sobre o tópico de memória cache e as 
documentações encontradas referentes aos mesmos, 
sejam estas artigos ou páginas da internet. 
 
3.1 KSH 
 
O KSH foi desenvolvido na Pontifícia Universidade 
Católica de Minas Gerais e desenvolvido na linguagem 
de programação Java. Esta ferramenta pode ser 
executada em modo gráfico ou via console, ambos 
possuindo as mesmas funcionalidades. O KSH 
implementa as três arquiteturas de memória cache: 
mapeamento direto; mapeamento associativo e 
mapeamento associativo por conjunto. Suas políticas 
de substituição são FIFO e LRU. Possui técnicas de 
escrita: write back e write through e o acesso à 
memória pode ser de modo sequencial ou paralelo. 
Figura 4. Visão geral do simulador KSH. 
 
O seu memory trace pode ser um arquivo de texto ou 
um comando via teclado. O programa possui 
basicamente três ambientes de execução: o primeiro, 
logo após o menu do programa, é o controle da 
simulação, que permite tanto a observação passo-a-
passo, quanto visualizar diretamente o final da 
simulação; o segundo, abaixo do controle da 
simulação, é onde é possível observar as informações; 
o terceiro, à direita, informa o conteúdo do memory 
trace. 
 
3.2 DCMSim 
 
DCMSim (Didatic Cache Memory Simulator) é um 
simulador que foi projetado na Digital and 
Computational System Groups (GSDC) na Pontifícia 
Universidade Católica. A primeira versão foi iniciada 
como um trabalho universitário, enquanto que a última 
versão foi desenvolvida como um trabalho de 
graduação, ambos foram escritos em Java. A última 
versão, selecionada para o estudo, implementa as 
seguintes arquiteturas de cache: mapeamento direto; 
associativa e associativa por conjunto. Políticas de 
substituição: FIFO e LRU. Políticas de escrita: write 
back e write through. Os dados de entrada são 
representados pelo conjunto de acessos à memória. 
O memory trace apresenta-se na forma de um 
arquivo de texto onde cada linha representa um acesso 
à memória e tem suas linhas neste formato: <endereço> 
<indicação de (d)ado ou (i)nstrução> <indicação de 
(l)eitura ou (e)scrita> <dado/instrução>. Possui um 
recurso denominado MissAnalyst que analisa os acertos 
e erros dos acessos realizados na memória cache. Na 
seção denominada LogBox, as estatísticas do tempo de 
acesso são exibidas, tanto da iteração corrente, como 
de toda a simulação. Isso possibilita gerar um arquivo 
de relatório contendo a sequência das ocorrências, 
configurações e os resultados da simulação. 
 
 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
9
 
 
 
 
 
 
 
 
 
 
 
Figura 5. Visão geral do DCMSim. 
 
3.3 MSCSim 
 
MSCSim (Multilevel and Split Cache Simulator), foi 
desenvolvido na Pontifícia Universidade Católica de 
Minas Gerais. Desenvolvido também em Java e 
implementa as arquiteturas de cache: mapeamento 
direto; mapeamento associativo e associativo por 
conjunto. Políticas de substituição: FIFO e LRU. 
Políticas de escrita: write back e write through. Acesso 
à memória: paralelo e sequencial. O programa possui 
interface gráfica composta de vários ambientes, sendo a 
janela principal composta de um menu principal e um 
espaço onde é mostrado os arquivos usados 
recentemente (configurações e traces). Seu memory 
trace pode ser feito através de um trace generator no 
programa, o qual permite a criação manual ou 
randômica seguindo o formato: <endereço> 
<(L)eitura/(E)scrita> <(I)nstrução/(D)ado>. 
 Quanto à configuração da arquitetura, pode 
ser elaborada ou ser importada de um arquivo pré-
definido. É possível dividir a cache em vários níveis e 
diferenciar as características de cada nível. Depois de 
configurada a arquitetura e informado o trace, surge o 
ambiente de simulação – uma janela com abas: 
simulação, memória cache, memória principal e 
estatísticas – a simulação pode ocorrer passo-a-passo 
ou diretamente. 
 
Figura 6. Visão geral do MSCSim. 
3.4 Dinero IV 
 
Desenvolvido pelo Dr. Jan Edler da NEC Researchs 
Corporation e pelo prof. Mark D. Hill do 
Departamento de Ciência da Computação da 
Universidade de Wisconsin. O Dinero IV é um 
simulador de memória cache baseado nas referências 
do memory trace que permite a simulação de caches 
multi-níveis dentre seus mais diversos tipos, como, por 
exemplo, uma cache separada para instrução e uma 
para dados. Possui melhor desempenho e portabilidade 
do que seu antecessor, o Dinero III. 
O Dinero IV não apresenta o tempo decorrido da 
simulação, sendo a sua principal funcionalidade o 
cálculo das taxas de acerto e de erro dos acessos feitos 
à memória cache. Suas políticas de substituição são: 
LRU; FIFO ou aleatória. Os vários parâmetros de cada 
cache podem ser configurados separadamente em 
relação aos fatores como: arquitetura; política e 
estatísticas. Durante a inicialização é realizada a 
configuração, uma cache por vez, começando por cada 
nível, desde a memória principal. Após a inicialização, 
os níveis superiores são alimentados a cada referência 
através por uma chamada simples de uma função, 
enquanto que os níveis mais baixos da hierarquia são 
tratados de maneira automática. O Dinero IV foi 
testado nos ambientes: x86/Linux, Alpha/Linux, 
Alpha/OSF, SGI/IRIX-6, RS6000/AIX, x86/Solaris, e 
Sparc/Solaris. 
Figura 7. Resultado de uma simulação 
realizada pelo Dinero IV. 
 
4. Comparação entre os simuladores 
 
Essa seção apresenta a comparação entre os 
simuladores selecionados, através da análise de seus 
respectivos artigos. 
 
 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
10
4.1 Parâmetros de comparação 
 
Após a análise dos simuladores, algumas 
características fundamentais foram discutidas e essa 
seção mostra os requisitos essenciais desejados em um 
simulador. 
Como a interface gráfica é a forma de interação com 
o usuário, esta deve ser intuitiva, de forma que a 
ferramenta seja fácil de utilizar. É importante que o 
processo de utilização do ambiente de simulação 
aconteça em etapas. O usuário deve passar por cada 
etapa, inserindo as informações solicitadas sobre a 
arquitetura simulada até a conclusão da simulação e 
exibição dos resultados. 
A visibilidade das informações é fundamental, aferramenta deve mostrar como é feito o acesso à 
memória cache, através da exibição de todos os 
parâmetros envolvidos no controle da mesma. Ao final 
da simulação, é esperado um relatório, cujo conteúdo 
mostraria uma descrição detalhada do desempenho do 
sistema. 
Para evitar erros, a geração do memory trace deve 
seguir um modelo fácil e deve ser feita de forma 
manual ou aleatória dentro do aplicativo. 
É essencial a disponibilização do aplicativo e de seu 
código fonte. Alguns dos trabalhos desenvolvidos não 
estão disponíveis para download e o contato dos 
desenvolvedores não é mais válido. Após o 
desenvolvimento da ferramenta, esta deve ser 
disponibilizada de forma simples, através, por 
exemplo, de sites que ofereçam hospedagem 
permanente. 
 
4.2 Estudo comparativo 
 
 Após a análise dos artigos dos simuladores de 
acordo com os critérios escolhidos, foi possível 
verificar que a maioria dos simuladores analisados não 
atende a alguns critérios. 
 Dos simuladores selecionados apenas o Dinero IV 
não apresenta uma cache dividida para dados e 
instruções, enquanto que todos os outros possuem tal 
recurso. 
 Em relação à quantidade de níveis de memória 
cache apenas o KSH e o DCMSim não apresentam a 
possibilidade de realizar simulações com vários níveis 
de cache. 
 Os tipos de acesso sequencial e paralelo, bem como 
o tempo de cada acesso são características apenas do 
KSH e do MSCSim, os outros simuladores não 
disponibilizam tal opção. 
 Os erros de compulsório, conflito e capacidade que 
podem ocorrem em um acesso à memória cache são 
pertinentes apenas aos simuladores Dinero IV e 
MSCSim. 
 Em relação ao memory trace, a maioria dos 
simuladores usa arquivos de texto elaborados pelo 
usuário, baseados em um modelo pré-definido. Embora 
não seja uma tarefa tão complexa, uma função 
randômica que gere o memory trace é importante, 
sendo o MSCSim o único simulador que possui tal 
recurso. O Dinero IV utiliza um trace gerado pelo 
próprio programa. 
 No quesito intuitividade, o que mais demonstrou 
deficiência foi o Dinero IV, pois não apresenta 
interface gráfica e nem comandos simples para as 
operações, que são exclusivamente via console. 
 Todos os outros possuem interfaces gráficas, 
variando em complexidade. A ferramenta que se 
mostrou mais completa foi o MSCSim, apresentando 
uma interface bem estruturada. 
 Na análise da visibilidade de informações, o 
MSCSim se destaca, exibindo uma gama de 
informações em sua simulação, além de possuir 
animações que ajudam a visualizar as modificações. O 
DCMSim e o KSH apresentam apenas as informações 
básicas e o Dinero IV não apresenta informações 
durante sua simulação, apresentando apenas um 
arquivo de relatório ao término. 
 O MSCSim possui um recurso de importação de 
arquivos de extensão xml com arquiteturas pré-
definidas para este fim. Já o KSH possui um script de 
configuração, porém a edição do mesmo é mais 
trabalhosa. Todos os outros não apresentam nenhuma 
forma de implementação de tutoriais. 
 A tabela 1 mostra as características básicas, que 
foram os parâmetros de comparação existentes nos 
simuladores, e outras características adicionais que se 
mostraram presentes nos mesmos. 
Tabela 1. Características gerais pertinentes 
aos simuladores 
 
 
 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
11
5. Resultados 
 
 Todos os simuladores apresentaram problemas de 
disponibilidade do aplicativo e do código fonte. O 
DCMSim possui o aplicativo disponível, porém em 
uma versão incompleta. O Dinero IV é disponível no 
site do autor, enquanto que para obter o MSCSim, é 
necessário entrar em contato com seus autores, os quais 
não retornaram os inúmeros contatos realizados. Não 
foram encontradas fontes para o KSH. 
A partir do estudo comparativo realizado, podemos 
verificar que há uma grande carência nas ferramentas 
de simulação. Mesmo havendo vários trabalhos 
publicados, não é possível encontrar os simuladores, 
exceto o Dinero IV, tanto por estes não estarem mais 
disponibilizados, quanto pela impossibilidade de 
contato com os idealizadores. 
Dos trabalhos selecionados, o MSCSim se destaca, 
sendo a ferramenta mais completa em todos os quesitos 
avaliados em nossa análise. Ele possui a interface com 
mais informações e as animações permitem uma 
melhor visualização das mudanças durante a simulação. 
Já o Dinero IV obteve o pior desempenho. A operação 
via console e a falta de informações durante a 
simulação, tornam o uso e a compreensão difíceis, 
sendo não indicado para o ensino. 
 
6. Conclusões 
 
Nesse ambiente conclui-se que apenas um único 
simulador atende às principais características que um 
simulador didático deve possuir. Porém, o programa 
não foi localizado e as inúmeras tentativas de contato 
com os autores não obtiveram êxito. 
Dessa maneira, os objetivos do artigo foram 
alcançados e foi percebida a carência da existência de 
simuladores que possam auxiliar o ensino sobre 
memória cache. 
Assim, surge a necessidade de que sejam elaborados 
novos simuladores de acordo com os estudos já 
realizados, onde sejam implementadas as 
funcionalidades expostas nesse artigo. As novas 
ferramentas devem, primeiramente, ser 
disponibilizadas de forma simples, através, por 
exemplo, de um serviço de hospedagem permanente de 
arquivos. O projeto da interface gráfica deve primar 
por criar um ambiente agradável, no qual o aluno possa 
obter as informações do funcionamento e de 
desempenho de várias organizações diferentes de 
memória cache. 
Juntamente com os artigos analisados nesse estudo, 
este trabalho complementa as pesquisas realizadas 
sobre simuladores de memória cache mostrando um 
estudo comparativo, de modo a facilitar a escolha de 
uma ferramenta de simulação que possa ser empregada 
na disciplina de arquitetura de computadores. 
 
7. Referências 
 
[1] Coutinho, L. M. N.; Mendes, J. L. D.; Martins, C. A. P. 
S. “MSCSim – Simulador de Memória Cache, Split e 
Multiníveis”, VI WSCAD, 2005, pp. 193-196. 
 
[2] Djordjevic, J.; Nikolic, B.; Mitrovic, M. “A Memory 
System for Education”, The Computer Journal, Vol. 48, 
No. 6, 2005, pp. 630-641. 
 
[3] Yurcik, W.; Wolffe, G. S.; Holliday, M. A; “A Survey 
of Simulators Used in Computer 
Organization/Architecture Courses”, Summer Computer 
Simulation Conference (SCSC), Society for Computer 
Simulation (SCS), 2001. 
 
[4] Ribeiro, A. S.; Duarte, R. P. “KSH: Simulador de 
memória cache com carregamento dinâmico de módulos 
e execução de script de configuração”, IV Workshop em 
Sistemas Computacionais de Alto Desempenho, 2003, 
pp. 160-163. 
 
[5] Cordeiro, E. S.; Stefani, I. G. A.; Soares, T.; Martins, C. 
A. P. S. “DCMSim: Didactic Cache Memory 
Simulator”, Frontiers in Education Conference – FIE 
2003, Boulder – Colorado, v. 2003, pp. F1C14-F1C19, 
2003. PDF. 
 
[6] Coutinho, L. M. N.; Mendes, J. L. D.; Martins, C. A. P. 
S. “MSCSim – Multilevel and Split Cache Simulator”, 
IV Workshop em Sistemas Computacionais de Alto 
Desempenho, 2006, pp. 193-196, (in portuguese). 
 
[7] Edler, J. Dinero IV Trace-Driven Uniprocessor Cache 
Simulator. Disponível em: 
http://www.cs.wisc.edu/~markhill/DineroIV/. 
 
[8] Hennessy, J. L.; Patterson, D. A. “Computer 
Organization and Design: The Hardware/Software 
Interface”, 3rd Edition, Morgan Kaufman, 2005. 
 
[9] William Stallings. “Organização e Arquitetura de 
Computadores”, 5ª Edição, Pearson Prentice Hall, 2002. 
 
[10] Vega M. A.; Martin R.; Zarallo F.A.; Sánchez J. M.; 
Gómez, J. A. "SMPCache: Simulador de Sistemas de 
Memoria Caché en Multiprocesadores Simétricos". 
Actas de las Xi Jornadas de Paralelismo, 2000, pp.3-8. 
 
[11] Moreira, L.; Pontes, B.; Fernandes, G.; Vidal, J. M.; 
Wanderley Netto, E. B.; Loop-way Cache. In Anais do 
Workshop em Sistemas Computacionais de Alto 
Desempenho, Oct, 24-27, pp. 197-200 Rio de Janeiro, 
Brazil,2005. 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
12
Extensão do Ptolemy para o ensino de Organização e Arquitetura de 
Computadores 
 
 
André L. L Torres, Alisson V. Brito 
Universidade Federal da Paraiba 
Programa de Pós-Graduação em Informática 
{atorres, alissonbrito}@dce.ufpb.br 
 
Resumo 
 
A utilização de simuladores na educação se faz 
cada vez mais presente nas atividades pedagógicas. 
Nesta nova realidade, várias aplicações visam facilitar 
a construção do conhecimento por parte dos 
professores em relação aos alunos, através de métodos 
dinâmicos e expondo aulas para múltiplos ramos sem 
haver grande esforço ou repetições desnecessárias. 
Neste sentido, este trabalho apresenta uma extensão 
desenvolvida numa ferramenta de modelagem e 
simulação de sistemas concorrente baseada em atores, 
denominada Ptolemy, para contribuir com o processo 
de ensino-aprendizagem da disciplina de Organização 
e Arquitetura de Computadores. A extensão permite a 
criação de roteiros didáticos que abordam a disciplina 
e a verificação automática dos mesmos. 
 
1. Introdução 
 
A análise dos sistemas computacionais atuais, seu 
entendimento é uma tarefa difícil, principalmente 
embasado apenas na teoria. Logo, o estudo da 
disciplina Organização e Arquitetura de Computadores 
podem ser facilitados com a utilização de simuladores 
[3], sendo uma abordagem benéfica para que os alunos 
entendam seu comportamento e possam visualizar a 
execução de programas para montagem real de uma 
arquitetura. 
Existem muitas técnicas de ensino utilizando 
simuladores para representar arquiteturas reais ou 
hipotéticas [2]. Estas técnicas, porém, não permitem 
uma abordagem construtivista onde os alunos possam 
criar suas próprias arquiteturas. 
Neste sentido, esse trabalho aborda uma 
metodologia para modelagem e simulação de sistemas 
concorrentes baseada em atores, utilizando um 
Framework denominado Ptolemy [6]. A metodologia 
abordada possui um grande potencial educacional 
ainda pouco explorado. Onde um modelo de atores é 
definido como um modelo matemático de computação 
concorrente que trata “atores” como sendo os 
elementos primitivos da computação concorrente 
digital [6]. 
Dada as limitações das soluções e propostas 
existentes, este trabalho propõe uma metodologia para 
o ensino de Organização e Arquitetura de 
Computadores apoiada pela simulação de sistemas 
concorrentes baseada em atores e pela ferramenta 
Ptolemy II, desenvolvida pela Universidade de 
Berkeley. O objetivo geral deste trabalho é prover um 
simulador que possibilite um ambiente didático onde 
os alunos possam criar seus próprios modelos de 
arquitetura de maneira simples, interativa e didática. 
 
2. Trabalhos Relacionados 
 
Os simuladores computacionais são recursos 
tecnológicos que podem auxiliar em diversas áreas. No 
contexto abordado neste trabalho, os simuladores 
auxiliam os professores a provocar, favorecer e 
orientar situações controladas de ensino e 
aprendizagem, pedagogicamente interessantes para o 
nível de ensino que deseja. Do ponto de vista 
pedagógico, simuladores computacionais são softwares 
úteis e simples, uma vez que levam os alunos a 
interagirem com os mesmos, o que lhes facilita a 
compreensão de conceitos abstratos, leis e 
características do mundo físico. 
Segundo Felix [4], em tal disciplina é notável a 
necessidade de ferramentas gráficas e didáticas para 
auxiliar o aprendizado. Especificamente para explicar a 
arquitetura de processadores, pois são necessárias 
muitas figuras para ilustrar os caminhos de dados e de 
controle quando uma instrução é executada. 
Para a disciplina de Organização e Arquitetura de 
Computadores, podemos citar algumas ferramentas 
voltadas para o campo da informática educativa, 
especificamente em uma das áreas correlatas 
(processadores) ao tema da pesquisa. Dentre os vários 
processadores, dos mais simples aos mais complexos, 
destacamos o processador MIPS (Microprocessor 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
13
without Interlocked Pipe Stages). O MIPS é uma 
arquitetura de microprocessador projetada com 
objetivo de oferecer alto desempenho na execução de 
código compilado. Suas instruções são todas de 32 bits, 
mesmo nos processadores de 64 bits, como forma de 
manter a compatibilidade. Todas as operações 
aritméticas no MIPS utilizam valores contidos nos 
registradores e os resultados também são colocados em 
um registrador. 
O WebMIPS [1] possui uma plataforma gráfica 
visualmente agradável para simular a arquitetura MIPS 
com pipeline. Ele possui a vantagem de ser uma 
plataforma disponível na Internet, proporcionando uma 
interface dinâmica, a qual o estudante pode ter acesso 
sem ter que instalar módulos do simulador. 
O DIMIPSS [4] (Didact Interactive MIPS 
Simulator) é um software multiplataforma de 
simulação da execução (caminho de dados e de 
controle) das instruções do MIPS Monociclo. Ele 
recebe um programa em linguagem de montagem 
(assembly), o converte para a linguagem de máquina e 
representa graficamente o comportamento do caminho 
de dados e de controle durante a sua execução. 
O MARS (Mips Assembly and Runtime Simulator) 
desenvolvido por Vollmar e Sanderson [9] é uma 
ferramenta em Java com a IDE gráfica implementada 
usando Swing que simula um conjunto de instruções 
do MIPS32. A versão atual é a 3.8 e implementa 98 
instruções, 36 pseudo-instruções e 17 chamadas de 
sistemas. 
Outra ferramenta é o WinMIPS64 [8] que simula a 
arquitetura pipeline do microprocessador MIPS64, 
apresentando um conjunto de 32 registradores para 
números inteiros, e 32 para números representados em 
pontos flutuantes. 
O WinMIPS64 [8] possibilita a visualização da 
instrução passando pelos pipelines, e ainda estatísticas 
relativas à execução, como, por exemplo, quantidade 
de ciclos que determinada instrução consumiu para 
passar por todos os estágios do pipeline. 
E por último descrevemos o MipsIt [3] que é um 
ambiente de desenvolvimento integrado e que também 
realiza a simulação do processador MIPS, 
possibilitando a programação em alto nível e 
permitindo relacionar conceitos de programação com 
organização e arquitetura de computadores. 
A Tabela 1 descreve uma análise comparativa entre 
ferramentas de simulação. Os tópicos abordados 
baseiam-se nos estudos de [7] para avaliar o potencial 
educacional dos simuladores. 
 
 
Tabela 1: Análise comparativa entre as 
ferramentas no ensino de Arquitetura de 
Computadores 
Ferramentas A B C D E F 
WebMIPS AA N S IL S S 
DIMIPSS BA N S IL N N 
MARS BA N S PL N S 
WinMIPS64 BA N N IL S S 
MipsIt AA N S IL/PL N S 
Ptolemy BA/AA S S CL/IL N S 
Legenda: 
(A) Ambiente e Complexidade 
(B) Suporte ao Projeto 
(C) Apresentação Visual 
(D) Nível de Simulação 
(E) Ensino a Distância 
(F) Detalhamento da Implementação 
 
Onde (A) avalia se o simulador apresenta noções 
básicas da introdução à Organização e Arquitetura de 
Computadores. Os níveis de avaliação são Arquitetura 
Básica (BA) e Arquitetura Avançada (AA). O critério 
(B) avalia se o simulador inclui ferramentas de apoio à 
elaboração de modulos informatizados reutilizáveis ou 
apenas simula sistemas pré-definidos. 
Para o critério (C) existem aqueles simuladores 
que detalham visualmente o funcionamento interno de 
um sistema computacional seguindo um fluxo de 
dados, ou aqueles onde os resultados são apresentados 
de forma textual, com a possibilidade de seu pós 
processamento. Ainda sobre os critérios utilizados, o 
(D) diz respeito ao nível de detalhamento do 
comportamento de um objeto exposto, com base no 
nivel mais baixo de granularidade suportado durante 
uma seção de simulação. Podendo ser: Nível de Clock 
(CL), Nível de Instrução (IL) ou Nível de Programa 
(PL). Para o critério (E), com base na disponibilidade 
de suporte para ensino à distância, os simuladores 
podem ser divididos entre aqueles com e sem suporte 
para o critério. E finalizando o (F) avalia se ossimuladores fornecem detalhes da execução visíveis 
durante a simulação. 
Após a análise das ferramentas verificou-se que o 
Ptolemy é o único que possibilita suporte ao projeto 
(B), pois permite que o aluno crie seus próprios 
elementos e possa reutilizá-los em diferentes níveis de 
abstração, como também em outros projetos e 
arquiteturas. Além disso, o Ptolemy possui algumas 
vantagens em relação às outras ferramentas, como por 
exemplo: i) no WebMIPS [1] as modificações que 
ocorrem nos caminhos de dados e controle durante a 
execução das instruções não são apresentadas; ii) O 
DIMIPSS [4] não é uma ferramenta web, dificultando 
o ensino a distância. Além de só implementar um 
pequeno número de instruções do MIPS monociclo; iii) 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
14
o MARS não possui suporte a depuração e não permite 
que o usuário desfaça etapas de execução; iv) o 
WinMIPS64 [8] não possui uma área para edição do 
código de execução pelo usuário; v) já o sistema 
MipsIt [3] a arquitetura do processador MIPS, ilustrada 
no MipsIt, possui complexidade acima do desejável 
para ilustração de conceitos aos alunos que estão 
ingressando em cursos de Computação. 
Podemos concluir que apesar do framework 
Ptolemy não ser um simulador didático (não possuindo 
um procedimento para o ensino a distância e de ter 
uma interface gráfica complexa), ele oferece a 
funcionalidade de criação de um repositório de atores, 
possibilitando ao aluno criar seus próprios cenários, 
como também seus atores, além de ser uma ferramenta 
gratuita e com o código fonte aberto, possibilitando 
que novas funcionalidades e mudanças na sua interface 
sejam realizadas para torná-la uma ferramenta 
apropriada para fins educacionais. 
 
3. Framework Ptolemy 
 
Este trabalho se baseia no uso do Ptolemy [6], 
criado e mantido na Universidade de Berkeley, como 
uma ferramenta de ensino de Organização e 
Arquitetura de Computadores. Mas para conseguir 
êxito em tal objetivo, foram verificadas algumas 
barreiras para a utilização da ferramenta: i) Ptolemy é 
um software para fins científicos e industriais com 
interface pouca amigável para usuários inexperientes. 
ii) Ptolemy não oferece nenhum tipo de ajuda sobre 
como o aluno deverá montar seus ambientes. iii) Caso 
um professor configure um ambiente para que seja 
trabalhado por seus alunos, ele não terá controle sobre 
o que os alunos fizeram com o ambiente ou com os 
atores. 
Além destas barreiras, foi realizada uma análise de 
usabilidade no framework Ptolemy, buscando 
compreender e apontar as necessidades do software 
para torná-lo uma ferramenta de ensino eficaz, para 
auxílio na disciplina de Arquitetura de Computadores, 
de forma mais simples e mais amigável. 
Na realização da avaliação de usabilidade, foi 
utilizada a técnica diagnóstica de inspeção via 
checklist, com o auxílio da ferramenta Ergolist1, 
desenvolvida pelo Laboratório de Utilizabilidade da 
UFSC/SENAI (LabiUtil), coordenado pelo Prof. Dr. 
Walter de Abreu Cybis. Essa ferramenta possui dezoito 
checklists, totalizando 193 questões. 
Na Figura 1 é apresentado um gráfico referente às 
estatísticas da avaliação de usabilidade do Ptolemy II 
na ferramenta Ergolist. O eixo horizontal apresenta os 
 
1 Para acessar o Ergolist, visite: 
http://www.labiutil.inf.ufsc.br/ergolist/check.htm 
critérios de avaliação e o eixo vertical apresenta o 
percentual de questões conformes, não-conformes e 
não-aplicáveis em cada critério. 
Após a avaliação, podem-se destacar problemas de 
usabilidade nos seguintes critérios, cujo percentual de 
questões não-conformes se sobressaíram: 
• Feedback: o Ptolemy II apresentou quase 60% 
de questões não-conformes, tendo em vista que, por 
existir uma documentação muita extensa, muitas 
tarefas executadas não fornecem um feedback 
apropriado para o usuário ficar mais seguro do que 
está fazendo; 
• Flexibilidade: o sistema deve disponibilizar 
diversas formas de se realizar uma tarefa e 
possibilitar efetuar modificações. Com quase 67% 
de questões não-conformes, no Ptolemy II só é 
possível essa flexibilidade se o usuário conhecer 
Java e XML; 
• Proteção contra erros: esse critério diz 
respeito aos mecanismos de detecção e prevenção 
de erros de entrada de dados ou comandos e ações 
não recuperáveis. O Ptolemy II obteve mais de 85% 
de questões não-conformes, pois a maioria dos 
erros é detectada na validação dos arquivos XML e 
classes Java; 
Buscando atender às necessidades do software para 
torná-lo uma ferramenta apropriada para o ensino de 
Organização e Arquitetura de Computadores, o 
trabalho descreve duas melhorias: i) tornar sua 
interface mais amigável, com instruções em português, 
e para que instruções passo a passo sejam dadas aos 
alunos na montagem de seus ambientes na forma de 
atividades; ii) Verificar automaticamente os exercícios 
feitos pelos alunos e dar feedback sobre o que pode ser 
melhorado. 
 
4. Extensão Ptolemy para fins educacionais 
 
A extensão desenvolvida permite que o usuário 
modele suas próprias arquiteturas utilizando o 
repositório de atores específicos para a disciplina de 
Arquitetura de Computadores. 
A nova interface contribuirá para que o professor 
demonstre na prática aos seus alunos tópicos abordados 
na ementa da disciplina, como: hierarquia de memória, 
registradores, barramentos, dispositivos de 
entrada/saída e a abordagem estrutural no estudo de 
computadores. De forma a especificar a nova 
arquitetura do Ptolemy para fins educacionais, foram 
utilizados padrões de projeto de interface [5], estudo de 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
15
 
Figura 1: Avaliação da usabilidade do Ptolemy
algumas ferramentas educacionais (seção 2) e 
abordagens para software educativo. 
Inicialmente foram desenvolvidos atores para 
representação dos componentes da arquitetura do 
processador MIPS como estudo de caso. Com a 
aplicação da ferramenta almeja-se estender sua 
aplicação para outras arquiteturas de processadores, 
memórias, dispositivos de Entrada e Saída etc. 
 
4.1. Interface gráfica Vergil 
 
A nova interface foi implementada na versão 8.0.1 
do Ptolemy. Seu desenvolvimento foi na linguagem de 
programação Java, utilizando o compilador Eclipse 
Helios Service Release 2. 
Ao acessar a interface gráfica [6], o usuário 
decidirá se deseja abrir um ambiente de modelagem 
para: (a) criar um novo projeto ou abrir um projeto já 
desenvolvido, podendo este ser (b) um projeto salvo no 
computador ou (c) um roteiro didático também salvo. 
No caso (a) o usuário utilizará a interface para 
modelagem e simulação, onde terá duas opções: i) criar 
um roteiro didático, clicando na opção do menu 
“Descrição de Exercício” (Figura 3), utilizando os 
atores da biblioteca, selecionando os obrigatórios, suas 
propriedades e as conexões entre eles, além de salvá-lo 
e/ou simulá-lo ou ii) criar seu próprio modelo 
utilizando a biblioteca, salvá-lo e/ou simulá-lo. 
Em relação ao item (b) o usuário poderá abrir 
projetos existentes, adicionar/editar atores, salvá-los e 
simulá-los por último, o item (c) possibilita que ele 
abra roteiros didáticos existentes, resolvendo os 
exercícios propostos, verifique possíveis erros através 
do Checker e receba um checklist da avaliação. 
A Figura 2 apresenta uma visão geral da estrutura 
para modelagem e simulação em Arquitetura de 
Computadores, seguindo uma aplicação didática do 
professor para o aluno. Na nova interface é visualizada 
as mudanças sugeridas para criação dos roteiros 
didáticos e da avaliação automática dos alunos, 
respectivamente, (a) Descrição do Exercício e (b) 
Verificação Automática. 
 
5. Roteiro didático 
 
Para ilustrar o roteiro didático aplicado aos alunos, 
é detalhado um exercício sobre o comportamento de 
uma Unidade Lógica Aritmética – Arithmetic Logic 
Unit (ALU) que é a unidade do processador que 
executa as operações aritméticase lógicas 
referenciadas pelos códigos de operações (opcodes). O 
ator criado para representar a ALU suporta oito 
operações (AND, OR, ADD, SUB, MUL, DIV, SLT, E 
NOR) em um circuito combinacional que calcula uma 
saída de 32 bits baseada em duas entradas de 32 bits e 
uma entrada de 4 bits que especifica a operação da 
ALU a ser executada além de computar bits para 
verificar se existiu overflow. 
No Ptolemy, a simulação é orientada ao ator. Logo, 
o aluno poderá estudar o caminho de dados e controle 
verificando o fluxo de dados através da simulação do 
cenário, pois as interações entre atores são mensagens 
com base na passagem dos dados de entrada e saída. 
No exercício sugerido (Figura 3), o aluno deverá 
resolver a equação (2X+Y)2 utilizando números 
binários. 
O exercício consiste na utilização das operações da 
ALU, calculando a equação na base binária, onde X = 
10 e Y = 11. 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
16
 
Figura 2: Visão geral da estrutura da nova interface gráfica 
O aluno deverá adicionar seis atores (ALU) ao 
cenário, juntamente com outros atores que 
correspondem aos valores de X,Y (ator Const) e 
Operação da ALU, além dos atores Clock e Display 
(para exibir o resultado), conectando-os de forma que 
suas relações efetuem os cálculos para a equação 
sugerida, informando na sua saída o valor binário numa 
sequência de 32 bits. 
 
 
Figura 3: Exercício proposto 
De forma a oferecer um feedback ao aluno, o 
mesmo poderá utilizar a opção do menu Verificação 
Automática para corrigir possíveis erros no seu 
cenário. Onde, caso o aluno não adicione algum ator 
obrigatório ao cenário, será informado uma mensagem 
de erro, conforme a Figura 4. 
 
Figura 4: Erro (Ator obrigatório pendente) 
A Figura 5 ilustra dois exemplos da resolução do 
exercício, um feito de forma correta, e outro com erros 
cometidos pelo aluno. 
No projeto “ALUAluno.xml” o aluno seguiu todas 
as recomendações da Figura 3 e teve como resultado o 
valor “11001”. Já no projeto “ALUAlunoErrado.xml” 
o aluno não seguiu as recomendações para o valor de 
entrada de Y, adicionando o valor “111” e conectou 
indevidamente a entrada “operation code” da ALU4 
na relação conectada a operação da ALU 
(Multiplicação), sendo a correta a da (Adição). Logo, o 
resultado não foi o esperado. 
Outras mensagens de erros foram configuradas para 
colaborar com o aprendizado do aluno. Na Figura 6 são 
apresentados os erros referentes à propriedade do ator 
Y (valor indevido) e das conexões dos atores e suas 
relações. 
 
6. Considerações Finais 
 
A extensão do Ptolemy ainda está em 
desenvolvimento, mas pelo seu potencial educacional 
que possibilita aos alunos criarem seus próprios 
modelos, combinarem novos elementos em diferentes 
níveis de abstração e ampliarem seus estudos, espera-
se com sua aplicação em sala de aula que os alunos 
possam resolver roteiros didáticos e verifiquem os 
erros existentes de uma forma clara e intuitiva. 
Na próxima etapa, a extensão criada incorporará a 
verificação automática na nova interface gráfica e será 
aplicada com alunos de graduação em Ciências da 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
17
Figura 5: Resolução do exercício
 
Figura 6: Mensagens de erro informadas no projeto do aluno 
Computação a fim de efetuar testes e analisar os 
resultados produzidos. 
 
Referências 
 
[1] Branovic, I, Giorgi, R e Matinelli, E., 2004. WebMIPS: A 
New Web-Based MIPS Simulation Environment for 
Computer Architecture Education, Proceedings of the 31st 
Annual International Symposium on Computer Architecture, 
Munchen, Germany. 
 
[2] Brito, A. V. Simulação Baseada em Atores para o Ensino 
de Arquitetura de Computadores. Apresentado no Workshop 
sobre Educação em Arquitetura de Computadores (WEAC) – 
Simpósio Brasileiro de Arquitetura de Computadores. SBAC, 
São Paulo, 2009. 
 
[3] Brorsson, M. MipsIt: a simulation and development 
environment using animation for computer architecture 
education. In Proceedings of 2002 Workshop on Computer 
Architecture Education: Held in Conjunction with the 29th 
international Symposium on Computer Architecture 
(Anchorage, ACM, New York, NY, 12. p. 
WCAE‘02.Alaska),p.1 -8. 
 
[4] Felix, A. F; Pousa, C. V. e Carvalho, M. B. DIMIPSS: 
Um simulador didático e interativo do MIPS . Apresentado 
no Workshop sobre Educação em Arquitetura de 
Computadores (WEAC) – Simpósio Brasileiro de Arquitetura 
de Computadores. SBAC, Ouro Preto - MG, 2006. 
 
[5] Koscianski, A., Soares, M. S. Qualidade de Software: 
Aprenda as metodologias e técnicas modernas para o 
desenvolvimento de software. Editora: Novatec. São Paulo – 
SP. 2007. 
 
[6] Lee, A, 2007. Neuendorffer, S. Tutorial: Building 
Ptolemy II Models Graphically. Technical Report No. 
UCB/EECS-2007-129. 
 
[7] Nikolic, B., Radivojevic, Z., Djordjevic, J and 
Milutinovic V, 2009. A Survey and Evaluation of Simulators 
Suitable for Teaching Courses in Computer Architecture and 
Organization. IEEE Transactions on Education, Vol. 52, No. 
4. 
 
[8] Scott, M. WinMips64, version 1.5, School of Computing, 
Dublin City University, Ireland, 2006. 
 
[9] Vollmar, K. and Sanderson, P., A MIPS Assembly 
Language Simulator Designed For Education. The Journal of 
Computing Sciences in Colleges, Vol. 21, No. 1, 2005. 
Workshop sobre Educação em Arquitetura de Computadores (WEAC 2011)
18
Arquitetura de Computadores em uma Simples Folha de Papel
Ricardo Ferreira
Departamento de Informa´tica
Universidade Federal de Vicosa
Vicosa, MG, 36570 000
ricardo@ufv.br
Abstract
Este trabalho apresenta um estudo inicial do uso de
uma ferramenta simples para coletar um retorno dos alu-
nos e uma participac¸a˜o efetiva nas aulas de arquiteturas
de computadores. Os estudantes fazem exercı´cios sim-
ples em conjunto com o professor ou isoladamente, du-
rante a apresentac¸a˜o dos conceitos teo´ricos. Dois temas
sa˜o abordados no artigo: memo´ria e encaminhamento de
instruc¸o˜es. Os exercı´cios sa˜o formatados para ficar em uma
folha de papel. O uso foi avaliado apenas em um semestre
letivo e apresentou uma melhora qualitativa. Os resultados
ainda sa˜o preliminares para uma avaliac¸a˜o quantitativa.
1. Introduc¸a˜o
Estudos recentes vem mostrando uma preocupac¸a˜o em
mudar a abordagem tradicional de ensino para os novos
jovens da gerac¸a˜o Y [3]. Os jovens nascidos nas duas
u´ltimas de´cadas sa˜o considerados por alguns pesquisado-
res como gerac¸a˜o Y. Sa˜o dinaˆmicos, fazem muitas tarefas
simultaˆneas, mas tem grande dificuldade ao ficarem presos
em uma sala de aula para manter a concentrac¸a˜o por mais
de 50 minutos [3].
A disponibilidade da tecnologia com a internet e suas fa-
cilidades de uso vem gerando modificac¸o˜es na sociedade.
Os jovens fazem uso intenso da internet, por meio de note-
books, telefones celulares, se comunicam por redes sociais,
etc.
O uso da tecnologia e´ uma alternativa com a disponibili-
dade de recursos multimı´dia, ferramentas colaborativas em
sı´tios na internet com animac¸o˜es, vı´deos, etc. Uma ferra-
menta interessante sa˜o os clickers [2]. O professor faz a
exposic¸a˜o da aula e va´rias pausas entre os to´picos. Mostra
perguntas simples no formato de mu´ltipla escolha, falso ou
verdadeiro, afirmativas. O estudante responde com o clic-
ker escolhendo a opc¸a˜o sim ou na˜o, a, b ou c. No mesmo
instante o professor tem o retorno dos alunos e sabe se deve
retornar ao to´pico e explicar ou esclarecer o assunto ou se
pode seguir adiante, tendo uma ideia precisa da percepc¸a˜o
dos alunos. Notebooks ou celulares tambe´m podem ser usa-
dos neste tipo de abordagem atrave´s da rede WIFI que esta´
disponı´vel na maioria dos ambientes universita´rios. Ja´ os
clickers e o software especı´fico tem que ser adquiridos para
tal finalidade.
Apesar da teconologia ajudar e trazer grandes benefı´cios,
muitas vezes o uso intensivo de projetores multimı´dia gera
muita dispersa˜o na turma. Este trabalho apresenta uma ideia
simples de baixo custo