Máquinas algorítmicas: una metodología para su - IEEE-RITA

IEEE-RITA Vol. 4, Núm. 2, May. 2009
83
Máquinas algorítmicas: una metodología para su
aprendizaje práctico a través de LittleProc
Joaquín Saiz Alcaine, Member, IEEE, Antoni Portero Trujillo, Member, IEEE, Raúl Aragonés Ortiz,
Mercè Rullán Ayza y Jordi Aguiló Llobet
Title—Algorithmic
Machines:
Methodology through LittleProc.
a
Practical
Learning
Abstract—The learning and comprehension of algorithmic
machines usually present a high degree of difficulty for computer
engineering students. In order to make it more accessible, a
teaching methodology of eminently practical base has been
designed, centered on the development of a simple processor,
which we called LittleProc. In the paper the characteristics of
LittleProc are presented along with their pedagogical motivations.
Also the teaching methodology devised and the form it was
applied are exposed in a detailed way. The academic results
obtained and the evaluation given by the students confirm the
viability and suitability of the followed methodology.
Index Terms—algorithmic machines, didactic processors,
digital systems.
I. INTRODUCCIÓN
U
NA máquina algorítmica consiste en un sistema digital
capaz de materializar y ejecutar un determinado
algoritmo [1][2][3]. La plena comprensión de las máquinas
algorítmicas supone un alto nivel de dificultad para los
estudiantes de Ingeniería Informática, quizá por no
comprender su vertiente más práctica o real. En nuestro
entorno docente, durante varios años se había observado que
una parte importante de los estudiantes acababa la asignatura
donde se impartía esta materia, con un conocimiento no
demasiado óptimo del funcionamiento de las máquinas
algorítmicas complejas (aquellas cuya unidad de control está
microprogramada).
Por
ello
y
aprovechando
la
reestructuración de la asignatura derivada de la implantación
del proceso de Bolonia [4], se tomó, entre otras, la decisión
de redefinir las prácticas con el fin de facilitar el aprendizaje
de dichas máquinas. En concreto, se decidió que los
estudiantes implementasen de manera real una máquina
algorítmica que contase con una unidad de control
microprogramada, considerándose que la mejor opción era que
Todos los autores pertenecen al Departamento de Microelectrónica y
Sistemas Electrónicos (MiSE) de la Universidad Autónoma de Barcelona
(teléfono: +34935813559, fax: +34935813033, correo electrónico:
{Joaquin.Saiz,
Antoni.Portero,
Raul.Aragones,
Mercedes.Rullan,
Jordi.Aguilo}@uab.cat ).
DOI (Digital Object Identifier) Pendiente
realizasen un pequeño procesador, como ejemplo de máquina
algorítmica de propósito general.
En la literatura docente existen múltiples ejemplos de
procesadores didácticos [5][6]; no obstante, por diversas
razones, preferimos optar por uno que se adaptase a nuestros
intereses docentes y al perfil de nuestros estudiantes. Ello nos
llevó a desarrollar un procesador simple de arquitectura Von
Neumann clásica, al que denominamos LittleProc, que se
ajustase totalmente a los requerimientos de nuestra asignatura
y que a la vez pudiera servir de complemento a los
conocimientos expuestos en otras asignaturas relacionadas con
este tema. LittleProc está inspirado en un procesador descrito
en [7]. La metodología de enseñanza práctica, ideada y
estructurada en torno a LittleProc, constituye el eje principal
de este artículo.
El artículo está organizado de la siguiente manera. La
Sección II está dedicada a mostrar el entorno universitario en
el que se imparte nuestra asignatura, haciendo especial
hincapié en el perfil general de los estudiantes. En la siguiente
sección se explican la planificación general de las prácticas y
las herramientas didácticas de apoyo que han sido utilizadas.
En la Sección IV se presenta LittleProc a nivel de bloques
funcionales. En la Sección V se muestra de forma detallada la
metodología docente creada en torno a LittleProc y se expone
el proceso seguido por los estudiantes para el diseño y
simulación del procesador. Asimismo se detalla la etapa de
implementación del procesador sobre una placa de
prototipado. En la Sección VI se presentan los resultados
académicos obtenidos y la valoración de la metodología
docente por parte de los estudiantes. Finalmente, la última
sección está dedicada a exponer las conclusiones e indicar las
futuras líneas de innovación docente que deseamos aplicar a la
asignatura.
II. MARCO UNIVERSITARIO
La enseñanza de las máquinas algorítmicas se imparte en la
asignatura de Diseño de Sistemas Digitales (DSD), la cual
pertenece al tercer semestre de la titulación de Ingeniería
Informática. DSD tiene asignados 6,5 créditos ECTS; es una
asignatura de carácter presencial y la cursan unos 110
estudiantes.
A raíz de la adaptación de la titulación al Espacio Europeo
de Educación Superior (EEES) derivado de la declaración de
ISSN 1932-8540 © IEEE
84
IEEE-RITA Vol. 4, Núm. 2, May. 2009
Bolonia, la asignatura sufrió una fuerte transformación. En [8]
y [9] se halla una descripción de la evolución que experimentó
DSD y de los objetivos que se persiguieron con dichos
cambios.
Los estudiantes afrontan DSD con el background adquirido
en la asignatura de Fundamentos de Computadoras (FC),
perteneciente al segundo semestre de la titulación. Para cursar
la asignatura de DSD no es requisito indispensable haber
aprobado FC (aproximadamente un 20% cursa DSD sin tener
aprobada FC).
El perfil general de los estudiantes tras haber cursado FC no
es excesivamente homogéneo. En general, tienen
conocimientos sobre fundamentos de lógica booleana, conocen
los bloques combinacionales y secuenciales básicos, y tienen
ciertas nociones sobre sistemas secuenciales. Asimismo
conocen el comportamiento funcional de un procesador
elemental. El grado de profundidad y asimilación de estos
temas puede variar bastante de un estudiante a otro.
Otro aspecto importante que contribuye a la heterogeneidad
de los estudiantes es el hecho de que una parte de ellos
compatibilizan sus estudios con un trabajo a tiempo parcial.
Ello es tenido en cuenta a la hora de establecer los horarios de
los diversos grupos, y, de manera especial, en la planificación
de las sesiones relativas a las prácticas.
Considerando lo mencionado hasta ahora, la asignatura se
estructuró de la forma que se expone en la Fig. 1. Una primera
parte, necesariamente breve, en la que se refresca
conocimientos previos pertenecientes al ámbito de FC. La
segunda parte está dedicada al diseño de sistemas que
implementan esquemas de cálculo (algoritmos carentes de
bifurcaciones). A continuación se presentan las máquinas
algorítmicas, estudiando en primer lugar la unidad de proceso
(tercera parte) para posteriormente analizar dos formas de
realizar la unidad de control: mediante una PLA (cuarta parte)
o microprogramada (quinta parte); esta última constituye el
cenit de dificultad de la asignatura. Finalmente, la última parte
se dedica a presentar las diversas familias de dispositivos
programables.
DSD está estructurada en Teoría (20% del total de horas),
Seminarios de Problemas (40%) y Prácticas (40%). Las clases
de teoría son clases magistrales en las que se exponen los
conocimientos propios de la asignatura. Están concebidas
como un método fundamentalmente unidireccional de
transmisión de conocimiento del profesor al estudiante. Por su
parte, los seminarios de problemas tienen como principal
objetivo la profundización y ampliación de los conocimientos
expuestos en las clases de teoría. Ello se hace a través de toda
una serie de actividades en grupo que van desde la típica
resolución de problemas hasta la discusión de casos prácticos.
En los seminarios de problemas se trabaja con un número más
reducido de estudiantes, lo que favorece una fuerte interacción
entre el profesor y el estudiante. Los seminarios son muy
efectivos cuando se abordan problemas de diseño digital no
excesivamente complicados. Desafortunadamente en el caso
de problemas de diseño de máquinas algorítmicas complejas
14 / 0
Semanas del
1 semestre
13
Presentación y repaso de
conocimientos previos
Esquemas de cálculo
3
11
Máq. Algoriítmicas: unidad
de proceso
Maq. algorítmicas: unidad
de control con PLA
Máq. algoriítmicas: unidad
de control microprogramada
Dispositivos programables
5
9
Dudas / Preparación
exámenes
7
Fig. 1. Programa y planificación de la asignatura DSD a lo largo de 1as
catorce semanas que constituyen el semestre.
eso no es así. Se pudo constatar que la mera resolución sobre
papel de dichos problemas no aseguraba una plena
comprensión de los mismos por parte de bastantes estudiantes.
Ello originó la decisión de que los estudiantes implementasen
una máquina algorítmica físicamente, de manera completa.
Dicha labor sería afrontada en la parte de prácticas de la
asignatura.
III. PRÁCTICAS: OBJETIVOS, MÉTODO GLOBAL Y
HERRAMIENTAS DE APOYO
Las prácticas fueron diseñadas con el objetivo prioritario de
posibilitar un conocimiento más profundo de las máquinas
algorítmicas complejas, aquellas cuya unidad de control está
microprogramada.
Teniendo en cuenta el background general de los
estudiantes se consideró que la mejor opción era dedicar las
prácticas al desarrollo de un procesador sencillo, ya que este
constituía un ejemplo de máquina algorítmica de propósito
general.
Además, ello se podía considerar como una
continuación lógica del aprendizaje realizado en la asignatura
de FC, en la cual ya habían adquirido conocimientos de la
funcionalidad de un procesador simple.
Asimismo, para conseguir un mayor grado de motivación de
los estudiantes, se estableció que ellos no solo diseñarían y
simularían el procesador sino que además deberían llegar a
implementarlo, y en consecuencia, deberían tener la
posibilidad de ejecutar un pequeño programa en él. Esta
decisión se tomó a raíz de nuestra experiencia docente, según
la cual un estudiante se siente mucho más atraído e implicado
por la creación de un sistema real y tangible que por el
desarrollo de un sistema solo a nivel conceptual. En cuanto a
la implementación se consideró que la opción más viable era
usar un dispositivo programable. En concreto, por motivos
organizativos internos, se optó por una FPGA de Altera.
Además del citado objetivo prioritario existían otros que se
enumeran a continuación:
-la profundización de los conocimientos relativos a la lógica
booleana y los bloques digitales básicos
-la familiarización con alguna herramienta CAD de diseño
electrónico de uso industrial
-la introducción a la descripción de circuitos mediante el
ISSN 1932-8540 © IEEE
SAIZ ALCAINE et al.: MÁQUINAS ALGORÍTMICAS: METODOLOGÍA PARA SU APRENDIZAJE PRÁCTICO
uso de un lenguaje de descripción de hardware (HDL),
utilizado en el entorno profesional
-la promoción del trabajo cooperativo
-la mejora de la capacidad de expresión oral y escrita
-la capacidad de organización del trabajo junto con su
desarrollo metódico y continuado a lo largo del semestre.
Como puede observarse, algunos de los objetivos citados
están directamente vinculados a la asignatura mientras que
otros hacen referencia a competencias de carácter transversal.
El logro del conjunto de objetivos indicados y la evaluación
continuada de su consecución por parte de los estudiantes
requiere que las prácticas se estructuren en sesiones de
diferentes tipos. Así, además de las típicas sesiones de
laboratorio, debe haber sesiones de seminario para introducir
conceptos e información que se usarán posteriormente, y
sesiones de control donde se evalúa el progreso de los
estudiantes. Teniendo en cuenta la carga de créditos de la
asignatura, se decidió que las prácticas constarían de 7
sesiones de laboratorio (de 2h cada una), 3 sesiones de
seminario (de 1h) y 3 sesiones de control (de 1h). En la
Sección V del artículo se expone detalladamente la
planificación y contenidos de dichas sesiones.
Esta estructuración trimodal de las prácticas, en la que se
entremezclan las sesiones de laboratorio, las de seminario y las
de control, conlleva un importante esfuerzo de coordinación
por parte del profesorado pero a la vez también requiere de un
esfuerzo organizativo y de planificación por parte del
estudiante. Para facilitar este proceso a los estudiantes, nos
hemos apoyado en Moodle [10], una aplicación orientada a la
gestión de contenidos de cursos a través de un sitio web.
Mediante Moodle (ver Fig. 2) se le indica al estudiante,
semana a semana, el tipo de sesión que se realizará esa semana
y la labor que tiene que preparar. Asimismo se le proporciona
la documentación que le servirá de soporte.
Otro aspecto positivo de Moodle es que en él se puede
integrar fácilmente una wiki [11]. Para promover el trabajo
cooperativo los estudiantes son distribuidos en grupos de tres
miembros. Cada grupo de trabajo tiene su wiki, incorporada en
Moodle [12], y es en esa wiki donde desarrollará una serie de
ejercicios escritos a lo largo del semestre. El hecho de que la
wiki sea accesible por Internet permite a los miembros de un
grupo desarrollar un ejercicio sin necesidad de coincidencia
espacial ni temporal, es decir, no es necesario que se reúnan en
un mismo momento de tiempo (tan solo requieren un poco de
coordinación previa entre ellos). Esta característica es muy
positiva especialmente para aquellos estudiantes que trabajan y
que, por tanto, tienen una disponibilidad horaria limitada. Los
ejercicios desarrollados en cada wiki son supervisados por el
profesor, insertando las correcciones necesarias ya sea
mediante texto, audio o tinta electrónica. Es entonces
responsabilidad de los miembros del grupo la pertinente
modificación de los ejercicios con arreglo a esas correcciones.
Por todo ello, la wiki del grupo puede considerarse como una
aproximación a un portafolio en el que queda reflejado buena
parte de su proceso de aprendizaje.
85
Fig. 2. Ejemplo de página (vista parcial) del sitio Moodle habilitado para
el seguimiento de las prácticas de DSD.
IV. LITTLEPROC
A. Características pedagógicas deseadas
Para alcanzar la consecución de los objetivos citados en la
sección anterior, se consideró que la mejor opción era
desarrollar un sencillo procesador que se adaptase
perfectamente a nuestros intereses pedagógicos. El primer
paso consistió en determinar qué requerimientos debería tener.
Estos son los principales:
1) Para posibilitar la profundización del estudiante en las
máquinas algorítmicas complejas, la unidad de control será
microprogramada.
2) Puesto que se desea que el procesador sea enteramente
desarrollado, simulado e implementado por parte de cada
grupo de trabajo durante las sesiones de laboratorio, es
imprescindible que su arquitectura interna sea sencilla.
Asimismo el número de módulos distintos debe ser reducido.
3) La unidad de proceso tendrá una arquitectura basada en
el modelo de buses, lo cual posibilita al estudiante visualizar la
utilización de un recurso compartido (el bus) y comprender lo
que puede y no puede hacerse en un solo ciclo de reloj.
4) Es necesario iniciar la práctica antes de haber impartido
la teoría correspondiente a las máquinas algorítmicas
complejas. Si no se hiciera así, faltaría tiempo material para
realizarla. En consecuencia, deberá ser posible desarrollar las
etapas iniciales del procesador, sin necesidad de tener
conocimientos sobre máquinas algorítmicas.
5) La mayor parte de los módulos del procesador deben
tener una funcionalidad susceptible de ser expresada de
manera independiente del procesador. Con ello se consigue
ISSN 1932-8540 © IEEE
86
IEEE-RITA Vol. 4, Núm. 2, May. 2009
MemoryL1
MDRdata[11..0]
MEMRW
MARdata[7..0]
ckn
NOT
ck
MEMdata[11..0]
data[11..0]
w ren
address[7..0]
clock
q[11..0]
RAM
ram
inst20
UC
glResetn
asynResetn
clock
inicio
control_signals_to_UP[19..0]
zero
negative
carry
opcode[3..0]
ck
inicio
zero
negativ e
carry
opcode[3..0]
control_s[19..0]
UNIDAD DE
CONTROL
inst
control_s[19]
LCELL
R1load
control_s[10]
_R1load
control_s[18]
LCELL
LCELL
R1out
control_s[9] LCELL
LCELL
R2load
control_s[8] LCELL
LCELL
R2out
control_s[7] LCELL
LCELL
IRload
control_s[6] LCELL
LCELL
IRout
control_s[5] LCELL
LCELL
MARload
control_s[4] LCELL
LCELL
ACCload
_ACCload
MARout
control_s[3..1] LCELL
_MARout
control_s[11]
PCinit
_PCinit
_MARload
control_s[12]
PCout
_PCout
_IRout
control_s[13]
PCload
_PCload
_IRload
control_s[14]
MemRW
_MemRW
_R2out
control_s[15]
MDRmem
_MDRmem
_R2load
control_s[16]
MDRout
_MDRout
_R1_out
control_s[17]
LCELL
ALUcode[2..0]
_ALUcode
MDRload
control_s[0] LCELL
_MDRload
end
_end
UP
carry
glResetn
glResetn
ck
R1load
R2load
IRload
PCload
PCinit
MARload
MDRload
ACCload
R1out
R2out
IRout
PCout
MARout
MDRout
ALUcode[2..0]
MEM[11..0]
MDRmem
ck
La consecución de gran parte de estas características nos
llevó a desarrollar y utilizar el procesador que se presenta a
continuación y al que llamaremos LittleProc. Para ello
seguiremos una estrategia top-down.
B. Arquitectura general
En la Fig. 3 se observa el esquema global de LittleProc
(incluyendo una memoria RAM). Como se puede apreciar se
corresponde con el típico esquema de una arquitectura de Von
Newman, conformada por una unidad de control (UC), una
unidad de proceso (UP) y una memoria RAM (de tamaño
parametrizable).
LittleProc tan solo tiene como entradas un reset asíncrono
(glResetn), el reloj (ck) y la señal que activa la ejecución del
programa almacenado en RAM (inicio). Su única salida es la
señal end que indica la finalización de la ejecución del
programa.
La memoria RAM alberga el programa que va a ejecutar el
procesador, el cual se halla a partir de la posición cuya
dirección es InitDir; a su vez también almacena los datos. La
RAM se comunica con la UP a través de tres caminos
dedicados. Es de tipo single-port y tiene un mecanismo de
control muy simple, compuesto por la señal wren y la señal de
reloj. La señal wren determina el tipo de operación a realizar
SEÑALES DE CONTROL DE LA UP
poder afrontar el diseño de dichos módulos pese a no tener
conocimientos previos sobre el mismo.
6) Ciertos módulos del procesador deben ser simples, de
forma que con su diseño el estudiante pueda recordar/reforzar
sus conocimientos previos sobre fundamentos de lógica
booleana y bloques digitales básicos.
7) Sería deseable que hubiese módulos de funcionalidad
similar que pudiesen ser especificados indistintamente
mediante captura de esquemas o HDL. De esa forma los
estudiantes pueden percibir las ventajas derivadas del uso de
HDLs.
8) El funcionamiento de las memorias vinculadas al
procesador debe ser lo más sencillo posible para no dificultar
la comprensión de la funcionalidad de la máquina
algorítmica/procesador.
9) Puesto que se prioriza el conocimiento del
funcionamiento interno de la máquina algorítmica/procesador,
es preferible que el conjunto de instrucciones del procesador
sea reducido. Además, las instrucciones se estructurarán
solamente en dos ciclos: uno de búsqueda (común a todas) y
otro de ejecución. Todo ello contribuirá a evitar que el
estudiante invierta excesivo tiempo en el estudio y análisis de
las instrucciones. El reducido conjunto inicial puede ser
utilizado para motivar a los grupos de trabajo a que lo amplíen
con otras instrucciones.
10) La ALU realizará un conjunto reducido de operaciones
simples. Ello facilitará la comprensión inicial del procesador y
a la vez podrá ser usado para promover la implementación de
nuevas instrucciones, más complejas, a través de operaciones
aritméticas simples.
R1load
R2load
IRload
PCload
PCinit
MARload
MDRload
ACCload
R1out
R2out
IRout
PCout
MARout
MDRout
ALUcode[2..0]
MEMdata[11..0]
MDRmem
carry
zero
negative
IRdata[11..8]
MARdata[11..0]
MDRdata[11..0]
zero
negativ e
opcode[3..0]
MARdata[11..0]
MDRdata[11..0]
UNIDAD DE
PROCESO
up
glResetn
INPUT
VCC
inicio
ck
INPUT
VCC
OUTPUT
INPUT
VCC
E/S
end
Fig. 3. Esquema general de LittleProc.
(lectura o escritura) y el flanco de subida del reloj provoca la
petición de la operación.
En el esquema también se puede observar una serie de
buffers virtuales a través de los cuales las señales de control
llegan a la UP. Son añadidos para facilitar la monitorización
de dichas señales durante la etapa de simulación.
ISSN 1932-8540 © IEEE
SAIZ ALCAINE et al.: MÁQUINAS ALGORÍTMICAS: METODOLOGÍA PARA SU APRENDIZAJE PRÁCTICO
R1out
reg
glResetn
TRI
asy nResetn
ck
dataout[11..0]
R1load
load
R1
datain[11..0]
R1
glResetn
TRI
asy nResetn
ck
dataout[11..0]
load
R2
R2
TRI
asy nResetn
ck
dataout[11..0]
IRload
load
datain[11..0]
IR
IR
TRI
glResetn
ck
PCinit
PCload
PCin[11..0]
PCinit
PCload
PC[11..0]
PCdata[11..0] inst41
PC
inst3
MARout
reg
glResetn
TRI
asy nResetn
ck
dataout[11..0]
MARdata[11..0] inst42
ck
1000
1001
1010
dataout[11..0]
MDRdata[11..0] inst43
ck
MDRload
load
MDRin[11..0]
MDR
datain[11..0]
MDR
reg
dataout[11..0]
asy nResetn
glResetn
ck
ck
ACCload
load
bus1[11..0]
datain[11..0]
ACC
carry
zero
negative
IRdata[11..8]
MARdata[11..0]
MDRdata[11..0]
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
ck
ck
negative
zero
carry
ALUv 0
Sel[2..0]
OUTPUT
B[11..0]
ACC
A[11..0]
ALUcode[2..0]
ACCdata[11..0]
alu
ALU
carry
zero
Bus2[11..0]
negativ e
MDRmem
sel
inst6
MEM[11..0]
data0x[11..0]
data1x[11..0]
result[11..0]
MDRin[11..0]
lpm_mux4
glResetn
ck
R1load
R2load
IRload
PCload
PCinit
INPUT
VCC
INPUT
VCC
INPUT
VCC
INPUT
VCC
INPUT
VCC
INPUT
VCC
INPUT
VCC
MARload
MDRload
ACCload
MDRmem
MEM[11..0]
ALUcode[2..0]
INPUT
VCC
INPUT
VCC
INPUT
VCC
VCC
INPUT
VCC
INPUT
VCC
INPUT
Fig. 4. Esquema lógico de la unidad de proceso de LittleProc.
ISSN 1932-8540 © IEEE
R1out
0110
0111
TRI
asy nResetn
ck
R2out
0101
glResetn
IRout
0100
MDRout
reg
PCout
0011
MAR
datain[11..0]
MAR
Bus1[11..0]
ck
MDRout
0010
PCout
PC
glResetn
C[11..0]
0001
inst40
IRdata[11..0]
ck
load
CONJUNTO DE INSTRUCCIONES DE LITTLEPROC
Instrucción
Descripción
LDR1 $mem Carga el contenido de la posición de
memoria $mem en el registro R1
LDR2 $mem Carga el contenido de la posición de
memoria $mem en el registro R2
ADD
Suma el contenido de los registros R1
y R2 y almacena el resultado en R1
STR1 $mem Almacena el contenido del registro R1
en la posición de memoria $mem
CMP
Compara el registro R1 con el R2,
activando la señal zero si son iguales
BRE $mem
Salta a la posición de memoria $mem
si la señal zero está activa
JMP $mem
Salta a la posición de memoria $mem
SUB
Resta el contenido del registro R2 a R1
y almacena el resultado en R1
END
Finaliza el programa: activa la señal
end y pone al procesador en un estado
de espera
NOP
No hace nada; su ciclo de ejecución
consume un ciclo de reloj
STR2 $mem Almacena el contenido del registro R2
en la posición de memoria $mem
IRout
reg
glResetn
MARload
Opcode
0000
inst39
R2data[11..0]
ck
R2load
D. Unidad de proceso
En la Fig. 4 se puede observar la unidad de proceso.
Presenta una arquitectura de dos buses (que denominaremos
Bus1 y Bus2) y está formada por 7 registros y una ALU. Los
registros se desglosan de la siguiente manera:
-dos registros de propósito general (R1 y R2)
-un registro de instrucción (IR)
-un registro contador de programa (PC)
-un registro de dirección de memoria (MAR)
-un registro de datos de memoria (MDR)
-un registro acumulador (ACC)
TABLA I
R2out
reg
datain[11..0]
La finalidad de dichos registros es fácilmente deducible a
partir de su nombre. El registro IR tiene como objetivo
almacenar la instrucción que se va a ejecutar. El registro PC
indica la dirección de la siguiente instrucción a ejecutar. Posee
una señal de control que permite inicializarlo al valor InitDir
que por defecto es la dirección 0x01.
Los registros MAR y MDR son utilizados en las operaciones
de memoria. El MAR almacena la dirección de la posición a la
que afecta la operación de memoria y el MDR contiene el dato
inst38
R1data[11..0]
ck
VCC
INPUT
VCC
INPUT
VCC
INPUT
VCC
INPUT
VCC
INPUT
VCC
INPUT
C. Conjunto de instrucciones
LittleProc en su versión más elemental cuenta con un
pequeño conjunto de instrucciones formado por un total de 11.
Cada instrucción de LittleProc se codifica a través una palabra
de 12 bits. Los cuatro primeros bits contienen el opcode y los
ocho restantes pueden almacenar un operando. En la Tabla I se
resume el conjunto de instrucciones. Este conjunto, aunque
reducido, es suficiente para la ejecución de pequeños
programas.
a escribir en una operación de escritura o recibe el dato leído
en una operación de lectura. Ambos registros se comunican
con la memoria a través de caminos dedicados, sin necesidad
de usar los buses de la UP.
Finalmente, el acumulador tiene como misión almacenar el
primer operando en las operaciones binarias de la ALU.
MARout
La UP y la memoria están regidas por flancos de reloj
opuestos. Por su parte, la UP y la UC reciben la misma señal
de reloj, si bien una parte de la UC está controlada por el
flanco opuesto como se verá más adelante.
87
88
IEEE-RITA Vol. 4, Núm. 2, May. 2009
Todas las microinstrucciones tienen un mismo formato, el
cual se halla reflejado en la Fig. 6. Se puede observar que los
dos bits más significativos sirven para controlar el multiplexor
de condiciones, seleccionando la señal de condición que se
desea testear según la siguiente codificación:
01: Zero 10: Carry
11: 2egative
00: Inicio
Los dos bits siguientes indican el tipo de microinstrucción,
de acuerdo a los siguientes valores:
01: GOTO
10: EXE
11: BRA2CH
00: IF
El resto de la microinstrucción, excepto el último bit, puede
estar formado por dos elementos: las microórdenes que
NOT
clock
inst8
clock
INPUT
VCC
clock
INPUT
VCC
inicio
INPUT
VCC
zero
INPUT
VCC
negativ e
INPUT
VCC
carry
INPUT
VCC
opcode[3..0]
INPUT
VCC
address[5..0]
Microprograma
q[23..0]
asy nResetn
inst3
control_signals[23..0]
control_signals[23..22]
control_signals[21..20]
w3
jumpAddress[5..0]
inst9
g
sel[1..0]
control_signals[19..0]
W1
W3
W2
address[5..0]
asynResetn
clock
w1
output_address[5..0]
w3
input_address[5..0]
instrucAddress[5..0]
w1
T1
T0
g
T[0]
inst11
w2
inst1
IRdecoder
sel[1..0]
inst7
inst2
NOT
negativ e
opcode[3..0]
Decodificador
result
inst
lpm_mux1
carry
opcode[3..0]
initAddress[5..0]
data0
data1
data2
data3
Multiplexor
condiciones
instrucciones
AND2
NOT
zero
Secuenciador
sequencer
asy nResetn
clock
CtrlSeq
T[1]
inicio
LCELL
_jumpAddress
LCELL
Control
secuenc.
T[1..0]
_sel
_T
control_signals[19..14]
inst5
E. Unidad de control
En la Fig. 5 se puede observar el esquema de la unidad de
control. Los elementos que conforman la UC son una ROM,
un multiplexor de condiciones, un secuenciador, un módulo
de control del secuenciador, un decodificador de instrucciones
y una serie de puertas AND que regulan el paso de las señales
de control hacia el exterior (unidad de proceso).
El multiplexor de condiciones tiene como finalidad
seleccionar una señal de condición, entre cuatro distintas, cuyo
estado será utilizado por cierto tipo de microinstrucciones (ver
más adelante).
La ROM contiene los microprogramas correspondientes a la
inicialización del procesador, el ciclo de búsqueda (común a
todas las instrucciones) y los ciclos de ejecución de las
instrucciones.
Un microprograma está formado por un conjunto de
microinstrucciones. Cada palabra o posición de la ROM
contiene una microinstrucción. Según su función, existen
cuatro tipos de microinstrucciones:
-EXE: genera microórdenes de control para los registros,
buses y ALU, ubicados en la UP
-IF: realiza un salto condicionado según el estado de una
señal de condición
-GOTO: realiza un salto incondicional
-BRA2CH: realiza un salto al inicio de un ciclo de
ejecución. El ciclo de búsqueda acaba con una
microinstrucción de este tipo para posibilitar el salto al ciclo
de ejecución de la instrucción actual.
romv2
ROM
LCELL
Todos los registros pueden ser reseteados asíncronamente.
La ALU, en principio, solo cuenta con cinco operaciones:
paso transparente, suma, resta, máscara de los cuatro primeros
bits e incremento en uno del dato procedente del Bus1 (útil
para generar la dirección de la siguiente instrucción a
ejecutar).
Como se puede observar en la Fig. 4, en las operaciones
unarias el operando proviene de Bus1 y en las operaciones
binarias los operandos proceden de ACC y Bus1. El resultado
siempre se vuelca sobre el Bus2.
La ALU genera tres señales de condición, Zero, 2egative y
Carry, indicadoras de que en una operación binaria (suma o
resta) se ha producido como resultado el valor cero, un valor
negativo o se ha generado un acarreo, respectivamente.
ANDs
OUTPUT
control_signals_to_UP[19..0]
Fig. 5. Esquema general de la unidad de control de LittleProc.
Bits 23
22 21
Selector
Mux. Condic.
20 19
Tipo
μ-instruc.
14
Señales de control de la UP (μ
μ-instr. EXE) /
Dirección de salto (µ-instr. IF y GOTO)
1 0
end
Fig. 6. Estructura de una microinstrucción
controlan la UP (en las microinstrucciones EXE) o la dirección
de salto (microinstrucciones IF y GOTO) en cuyo caso solo se
utilizan los primeros bits.
El último bit de la microinstrucción constituye la señal end
con cuya activación el procesador informa que ha finalizado la
ejecución de un programa.
El secuenciador (Fig. 7) es un bloque formado por un
registro (denominado microPC), un módulo incrementador y
un multiplexor de direcciones. El registro microPC indica la
dirección en la ROM de la siguiente microinstrucción que será
leída/ejecutada. Dicha dirección puede ser una de las tres
siguientes:
-la dirección consecutiva (la cual es producida por el
incrementador).
-una dirección de salto proveniente del contenido de una
microinstrucción de la ROM.
-una dirección de salto, correspondiente al inicio del ciclo
de ejecución de una instrucción.
El módulo de control del secuenciador tiene una doble
finalidad. Por un lado, genera las dos señales (w1 y w3) que en
el secuenciador controlan la siguiente dirección a ser cargada
en el microPC y por otro, produce la señal w2 que controla la
apertura de las puertas AND y, por tanto, el paso de señales
hacia la UP.
ISSN 1932-8540 © IEEE
SAIZ ALCAINE et al.: MÁQUINAS ALGORÍTMICAS: METODOLOGÍA PARA SU APRENDIZAJE PRÁCTICO
____
inicio
asynResetn
instrucAddress[5..0]
input_address[5..0]
inicio
Inicialización
datain[5..0]
INPUT
VCC
INPUT
VCC
w1
INPUT
VCC
EXE (MDRmem, MDRload,
EXE (R1out, ACCload)
EXE (R2out, ALU-SUMA,R1load)
GOTO (dirección donde
empieza ciclo búsqueda)
Ejecución se ha puesto a modo de ejemplo el ciclo de
ejecución de la instrucción ADD.
OUTPUT
clock
Ejecución
Fig. 8. Máquina de estados simplificada de la UC
microPc
asy nResetn
IR ≠ Instr. END
BRANCH
asynResetn REGISTRE
ck
microPc
D
EN
Ejemplo: Instrucción ADD
PCout, ALU-Incr., PCload)
dataout[5..0]
clock
=
.
str
In
EXE (PCout, ALU-Transp., MARload)
EXE (MDRout, ALU-Transp., IRload)
reg6
asy nResetn
IR
Búsqueda
lpm_mux0
data3x[5..0]
data2x[5..0]
result[5..0]
sel[1..0]
data1x[5..0]
inst3
INC
Multiplexor
direcciones
EXE (end)
GOTO (dirección donde
empieza periodo espera)
IF ([not inicio] continuar aquí)
EXE (PCload, PCInit)
w3,w1
Ejecución_END
Espera
A_Plus[5..0]
inst2
A[5..0]
data0x[5..0]
INCREMENTADOR
Incrementador
89
w3
input_address[5..0]
instrucAddress[5..0]
output_address[5..0]
INPUT
VCC
INPUT
VCC
INPUT
VCC
Fig. 7. Esquema lógico del secuenciador.
Finalmente, el decodificador de instrucciones tiene como
objetivo generar la dirección de la ROM donde comienza el
ciclo de ejecución de la instrucción actual. Para ello, dicho
módulo utiliza el código de la instrucción (opcode) que se
encuentra almacenado en el registro IR. La dirección que
genera será la dirección a la que se saltará cuando se ejecute
una microinstrucción de tipo BRA2CH.
La Fig. 8 muestra una representación simplificada de la
máquina de estados de la UC. Inicialmente, tras el reset global,
la UC se halla en el estado Espera. Al activarse la señal inicio
pasa al estado Inicialización donde al registro PC se le asigna
el valor InitDir. A continuación va al macroestado Búsqueda
donde se realiza el ciclo de búsqueda de la primera
instrucción. Se debe recordar que el ciclo de búsqueda es
común a todas las instrucciones. Una vez concluido éste, pasa
al macroestado Ejecución correspondiente al ciclo de
ejecución. Las acciones realizadas en este ciclo dependen de la
instrucción que se esté ejecutando (la cual se halla en el
registro IR). Una vez finalizado el ciclo de ejecución se realiza
de nuevo la búsqueda de otra instrucción. Este proceso se
repite con todas las instrucciones excepto con la instrucción
END. En este caso en su ciclo de ejecución (macroestado
Ejecución_E2D) se emite la señal end y se salta al estado
Espera. En la Fig. 8 se presenta también el microcódigo que
implementa cada estado. En el caso del macroestado
F. Bloques básicos de LittleProc
Para desarrollar LittleProc se requiere un conjunto de
bloques básicos sumamente pequeño, elaborados bien por
captura esquemática o bien con VHDL. Estos son sus
integrantes:
-reg, un registro de 12 bits con reset asíncrono y señal de
carga, usado para implementar los registros R1, R2, IR, MAR.
MDR y ACC.
-PCreg, un registro de 12 bits, con posibilidad de ser
inicializado a un determinado valor de forma síncrona. Es
utilizado para implementar el registro PC.
-ALU, con la funcionalidad descrita en la subsección relativa
a la UP. Este módulo tiene una parte combinacional y otra
secuencial.
-ctrlSeq, un módulo puramente combinacional que
implementa tres funciones booleanas de tres variables y que
constituye el modulo de control del secuenciador.
-microPC, un registro de 6 bits con señal de reset asíncrono,
usado en el secuenciador. Carece de señal de carga.
-incrementer, módulo combinacional que realiza el
incremento en uno de su valor de entrada (de 6 bits), utilizado
para implementar el incrementador del secuenciador.
-IRdecoder, un conversor de datos utilizado para
implementar el decodificador de instrucciones.
En la lista anterior se ha omitido los multiplexores y las
memorias ROM y RAM. Dichos elementos se pueden generar
de forma casi-automática con la ayuda de asistentes (wizards)
integrados en el CAD de Altera.
V. METODOLOGÍA DE APRENDIZAJE PRÁCTICO:
ESTRUCTURACIÓN DE LAS SESIONES Y EVALUACIÓN
En esta sección se expone la forma en cómo se ha
estructurado incrementalmente el proceso de aprendizaje
mediante las trece sesiones que conforman las prácticas de la
asignatura y se muestra cómo se alcanzan los objetivos
especificados en anteriores secciones. En el último punto se
explica como se evalúan las prácticas.
ISSN 1932-8540 © IEEE
90
IEEE-RITA Vol. 4, Núm. 2, May. 2009
B. Sesión 2. Diseño mediante captura de esquemas.
Recordatorio de fundamentos booleanos
En esta sesión de laboratorio los estudiantes continúan
diseñando algunos módulos básicos de LittleProc. En concreto
realizan dos módulos, microPC y PCreg (ver Fig. 10 y 11),
que por su estructura simple son susceptibles de ser fácilmente
implementados mediante captura de esquemas. Se proporciona
a los estudiantes su comportamiento funcional sin hacer
ninguna referencia a su papel dentro de LittleProc.
Las características de estos módulos junto con el
desarrollado en la primera sesión (ctrlSeq) los hace muy
apropiados para recordar/refrescar conocimientos básicos de
lógica booleana, especialmente cuando se procede a su
simulación funcional/temporal. Al ser ctrlSeq combinacional y
los dos restantes secuenciales, ello permite observar si los
estudiantes tienen claras las diferencias entre ambos tipos de
circuitos y los principales conceptos asociados (p.e., elementos
básicos que los conforman). Asimismo, la implementación de
los circuitos secuenciales permite comprobar si los estudiantes
tienen claro su funcionamiento en relación a la señal de reloj
(distinción entre latches y flip-flops) y la actuación de otras
señales de control (p.e., reset asíncrono en contraposición a
reset síncrono).
El desarrollo de estos módulos también permite a los
estudiantes familiarizarse con la conectividad por nombre y
con la expresión de un grupo de instancias a través de un solo
6
7
8
9
10
11
12
13
AND2
INPUT
VCC
NOT
_W2
inst
LCELL
T1
AND3
OUTPUT
W2
OUTPUT
W1
OUTPUT
W3
inst4
inst3
OR2
LCELL
INPUT
VCC
g
inst7
NOT
_W1
AND2
inst5
inst1
AND2
_W3
A. Sesión 1. Familiarización con el CAD
La primera sesión se dedica básicamente a que el estudiante
conozca el CAD que va a utilizar de forma continuada a lo
largo del semestre. Dado que LittleProc se implementará en
una FPGA de Altera se optó, como herramienta de CAD, por
Quartus II Web Edition [13] del mismo fabricante. Dicho
software está disponible de forma gratuita lo que posibilita que
los estudiantes puedan instalarlo particularmente y
experimentar con él libremente.
En esta sesión de laboratorio, mediante el desarrollo de
ctrlSeq, un bloque combinacional sencillo de LittleProc, el
estudiante aprende a realizar capturas de esquemas, las
diversas maneras de especificar formas de onda y a hacer
simulaciones tanto funcionales como con retardos. Se puede
observar ctrlSeq en la Fig. 9.
Para facilitar la familiarización con Quartus II se le
proporciona a cada grupo de trabajo un documento a modo de
walkthrough. Este documento permite que cada grupo, a pesar
de su inexperiencia con herramientas CAD, pueda trabajar de
forma semiautónoma, requiriendo la presencia del profesor tan
solo para resolver dudas puntuales. Asimismo el citado
documento le sirve como pequeño manual de referencia de
Quartus II en las posteriores sesiones de laboratorio.
Sesión
1
2
3
4
5
TABLA II
PLANIFICACIÓN DE LAS SESIONES DE PRÁCTICAS
Tipo
Descripción
Laboratorio Introducción a Quartus II Web Edition
Laboratorio Bloques básicos (I): captura de esquemas
Seminario
Introducción al VHDL
Laboratorio Bloques básicos (II): diseño con VHDL
Control
Preguntas sobre VHDL y bloques básicos
oral
(50% estudiantes)
Seminario
Presentación de LittleProc
Laboratorio Diseño de la UP
Laboratorio Diseño de la UC
Laboratorio Diseño de LittleProc
Control
Preguntas
sobre
LittleProc
(50%
oral
estudiantes)
Seminario
Introducción a la placa de prototipado
Laboratorio Implementación de LittleProc en la placa de
prototipado
Control
Preguntas sobre la totalidad de la práctica
oral
(100% estudiantes)
LCELL
La Tabla II presenta un resumen de la planificación de las
sesiones. Todas las sesiones se apoyan en una documentación
que se proporciona a los estudiantes a través de Moodle.
Asimismo, todas las sesiones de laboratorio requieren un
cierto grado de preparación previa por parte de cada grupo de
trabajo.
T0
INPUT
VCC
inst2
Fig. 9. Esquema lógico del módulo ctrlSeq (versión simplificable).
símbolo (ver esquemas de microPC o PCreg). En las
simulaciones de estos módulos se ven involucradas un número
muy pequeño de señales que permite a los estudiantes
afrontarlas sin excesivas dificultades.
La única dificultad reseñable en esta sesión es la
inicialización de forma síncrona al valor InitDir en el módulo
PCreg. La forma de resolverla permite al profesor hacerse una
idea aproximada del perfil de cada grupo de trabajo.
C. Sesiones 3-5. Introducción a VHDL
La tercera sesión consiste en un seminario en el que a través
de pequeños ejemplos se introduce el lenguaje VHDL como
lenguaje de descripción de hardware. La finalidad de esta
sesión es que los estudiantes conozcan las sentencias y
operadores básicos de VHDL y la forma en como pueden ser
utilizados para la descripción de circuitos poco complejos y su
posterior síntesis.
Estos conocimientos son puestos en práctica en la cuarta
sesión (de laboratorio) por los diversos grupos para la
realización del resto de módulos básicos (reg, ALU,
incrementer e IRdecoder) de LittleProc. El lector de este
artículo puede hallar el código de dichos módulos en [12].
Respecto al diseño de estos módulos, es la ALU el que
presenta un mayor nivel de dificultad para los estudiantes dado
que debe estructurarse en dos partes diferenciadas: una
ISSN 1932-8540 © IEEE
SAIZ ALCAINE et al.: MÁQUINAS ALGORÍTMICAS: METODOLOGÍA PARA SU APRENDIZAJE PRÁCTICO
DFF
PRN
INPUT
VCC
INPUT
VCC
datain[5..0]
ck
D
OUTPUT
Q
dataout[5..0]
CLRN
6f f
INPUT
VCC
asy nResetn
Fig. 10. Esquema lógico del módulo microPC.
PCinit
NOT
inst10
PCin[11..1]
AND2
DFFE
in[11..1]
inst8
PC[11..1]
PRN
D
ck
Q
PCload
ENA
CLRN
f f 11_1
glResetn
PCinit
OR2
DFFE
in[0]
PCin[0]
inst9
PC[0]
PRN
D
ck
Q
PCload
ENA
CLRN
f f _0
glResetn
glResetn
ck
PCinit
INPUT
VCC
INPUT
VCC
INPUT
VCC
PCload
INPUT
VCC
INPUT
VCC
PCin[11..0]
OUTPUT
PC[11..0]
Fig. 11. Esquema lógico del módulo PCreg con InitDir = 1.
parte puramente combinacional y la otra de carácter
secuencial, asociada a la generación de las señales de
condición.
Otro aspecto destacable es el hecho de que cada grupo ha
tenido que desarrollar un registro tanto mediante captura de
esquemas como mediante VHDL (PCreg y reg) lo cual
permite comparar ambos métodos de especificación y tomar
conciencia de las ventajas de usar un HDL (simplicidad,
parametrizabilidad y portabilidad).
Con posterioridad a la sesión 4, cada grupo, a través de su
wiki, tiene que resolver de forma cooperativa un cuestionario
sobre los módulos desarrollados y sobre VHDL. Finalmente en
la sesión 5 se procede a realizar un cuestionario oral a un
conjunto de estudiantes de la clase. Ello permite comprobar de
forma individualizada el nivel de asimilación de
conocimientos alcanzado y posibilita también que el estudiante
desarrolle su capacidad de expresión oral.
D. Sesiones 6-10. Diseño de la unidad de proceso y de la
unidad de control. Creación de LittleProc.
Al llegar a este punto de la asignatura, los estudiantes, a
través de las clases de teoría, han adquirido unos
conocimientos elementales de máquinas algorítmicas
complejas y han realizado algunos problemas representativos.
La sexta sesión consiste en un seminario que tiene como
objetivo presentar la arquitectura de las unidades de proceso y
control de LittleProc. Asimismo se explica cómo usar los
módulos desarrollados hasta ahora para crear ambas unidades.
Es en esta sesión donde el estudiante toma conciencia de la
funcionalidad final de cada módulo dentro de LittleProc. En
dicha sesión también se expone cómo crear LittleProc
mediante el adecuado conexionado de la UP, la UC y una
pequeña memoria RAM.
Entender la UP no suele ser problemático para los
estudiantes. Por el contrario, comprender el funcionamiento
91
detallado de la UC suele presentar un nivel de complejidad
relativamente elevado puesto que no solo han de entender la
interrelación de los módulos hardware sino también el
contenido de las microinstrucciones de la ROM.
Respecto a la UP, y teniendo en consideración su
simplicidad, se promueve que cada grupo la desarrolle por su
cuenta y la traiga ya realizada al principio de la sesión 7 (de
laboratorio). De esa forma puede dedicar la totalidad de la
sesión a simularla bastante exhaustivamente. Uno de los
problemas que presenta su simulación es el gran número de
señales que se han de gestionar. Los estudiantes se suelen
quedar colapsados al observar una simulación en la que
pueden aparecer una veintena de señales distintas. Por ello se
les proporciona una documentación con las señales que deben
ser monitorizadas y una descripción textual orientativa de la
simulación a realizar.
La sesión 8 (de laboratorio) se centra en el desarrollo del
módulo secuenciador, la generación automática de la ROM y
la creación de la UC. Para la especificación de la ROM, se
facilita a los estudiantes un fichero con parte de los
microprogramas que han de estar almacenados en ella. Una
vez creada la unidad de control, cada grupo procede a su
simulación. Idear una simulación de la UC no es
conceptualmente difícil ya que el número de señales de entrada
que tiene es pequeño. Lo que sí resulta más difícil para los
estudiantes es observar el gran número de señales de salida,
producidas por ella. Por ello se les proporciona una guía con
un orden recomendado de visualización de señales, orientada a
facilitarles su comprensión y su seguimiento ciclo a ciclo de
reloj.
En la sesión 9 (de laboratorio), cada grupo conecta la UP, la
UC y una pequeña RAM generada, creando así su propia
versión de LittleProc. Para la especificación de la RAM, se
facilita a los estudiantes un fichero con un pequeño programa
en lenguaje máquina (unas 10 instrucciones) que estará
almacenado en ella y que podrá ser ejecutado por LittleProc.
La mayor parte de esta sesión se dedica a simular la ejecución
del citado programa realizando un seguimiento ciclo a ciclo de
reloj de todos los elementos del procesador (registros de la
UP, microPC, señales de control de la UC, etc.), tal como se
puede observar en la Fig. 12. Para hacer esta simulación
resulta imprescindible ver la evolución de las señales internas
del procesador. Para conseguirlo en Quartus II, se requiere
añadir ciertos elementos en los esquemas (buffers virtuales
LCELL) y hacer ciertas declaraciones adicionales en el código
VHDL (sentencias attribute).
Tras la sesión 9 los estudiantes deben haber alcanzado un
alto grado de comprensión del funcionamiento de su LittleProc
y en consecuencia del modo de funcionamiento de una
máquina algorítmica cuya unidad de control sea
microprogramada. Llegado este momento se plantea a cada
grupo un segundo cuestionario en el que, entre otras cosas, se
les pide que completen la ROM de la UC y que implementen
nuevas instrucciones ampliando así las posibilidades de su
LittleProc. En la sesión 10 (de control) se vuelve a escoger un
conjunto de estudiantes, diferente del elegido en la sesión 5,
para realizarles de forma individual un cuestionario oral sobre
los conocimientos adquiridos acerca de LittleProc.
ISSN 1932-8540 © IEEE
92
IEEE-RITA Vol. 4, Núm. 2, May. 2009
Fig. 12: Formas de onda pertenecientes a la simulación de LittleProc ejecutando un pequeño programa. Las señales se han dispuesto de la siguiente
forma: entradas (3), salida (1), registros de la UP y señales vinculadas, ALU y señales relativas a la UC (empezando por el microPC).
E. Sesiones 11-13. Implementación y uso de LittleProc
mediante una placa de prototipado
En la recta final del semestre se aborda la parte más
estimulante para los estudiantes. A través una placa de
prototipado que cuenta entre otros elementos con una FPGA,
se procede a implementar LittleProc para posteriormente
realizar una ejecución controlada de un pequeño programa. La
placa de prototipado usada es la UP3 Education Kit (Fig. 13)
[14].
En la sesión 11 (de seminario) se explican las principales
características de la placa UP3 y los elementos que la
conforman. A su vez, se exponen las modificaciones que se
deben realizar sobre el diseño de LittleProc para facilitar su
implementación en la placa, que consisten básicamente en la
adición de dos pequeños módulos. El primero de ellos permite
que el reloj del procesador sea controlado a través de un
pulsador externo. El segundo posibilita que el contenido de los
registros del procesador se visualice externamente en un
display integrado en la placa. Finalmente se explican los pasos
a seguir para realizar la síntesis del circuito.
En la sesión 12 (de laboratorio) se suministra a cada grupo
una placa UP3. Asimismo se le proporciona los módulos a los
que se hacía referencia en el párrafo anterior. Cada grupo
genera una nueva versión de LittleProc incorporándole esos
módulos y algunas modificaciones técnicas menores. Una vez
realizado esto, procede a sintetizar LittleProc sobre la placa de
prototipado y ejecuta un pequeño programa que se halla en la
RAM. Con ayuda de un pulsador de la placa va generando el
Fig. 13. Placa de prototipado UP3 Education Kit.
reloj ciclo a ciclo, observando a través del display como van
cambiando los registros y evaluando la coherencia de dichos
cambios.
Tras esta sesión cada grupo tiene que responder un tercer
cuestionario centrado en el conocimiento de FPGAs, las
características de la placa UP3 y el proceso de síntesis. Como
complemento final de su formación, la sesión 13 (de control)
se dedica a realizar de forma individual un pequeño examen
oral a la totalidad de los estudiantes.
ISSN 1932-8540 © IEEE
SAIZ ALCAINE et al.: MÁQUINAS ALGORÍTMICAS: METODOLOGÍA PARA SU APRENDIZAJE PRÁCTICO
F. Evaluación de las prácticas
La evaluación de las prácticas se realiza a través de la
puntuación de cada cuestionario respondido por cada grupo en
su wiki y de las notas obtenidas en los cuestionarios orales
individuales. Para cada grupo se computa la nota media de sus
cuestionarios escritos y para cada estudiante se calcula la
media de sus cuestionarios orales. Haciendo una suma
ponderada de dichas medias se determina la nota final de
prácticas de cada estudiante. Cabe la posibilidad de ser
restrictivo estableciendo la condición de que si la media de los
cuestionarios orales individuales es inferior a un valor umbral
el estudiante quede suspendido.
positivos de la asignatura mientras otros claramente preferirían
prescindir de ella. En cuanto a la planificación global de las
prácticas, la opinión es positiva si bien existe un número
reseñable de estudiantes a los que las sesiones de laboratorio
les parecían algo cortas.
También se solicitó a los estudiantes que hicieran una
valoración del nivel de interés que les suscitaban las prácticas
de nuestra asignatura en relación a las de otras asignaturas.
Dicha cuestión se planteó debido a que, en cierta forma, el
tiempo de los estudiantes puede ser considerado como un
recurso compartido por el que compiten todas las asignaturas.
Las respuestas de los estudiantes indican que el interés de
nuestras prácticas está claramente por encima del nivel medio.
VI. RESULTADOS Y VALORACIÓN DE LOS ESTUDIANTES
Tras haber puesto en práctica la metodología expuesta en
las secciones anteriores, era necesario analizar los resultados
derivados de su aplicación y conocer la opinión/percepción de
los estudiantes.
La Tabla III muestra una comparativa de las notas finales
correspondientes a la primera convocatoria de dos cursos: el
último curso con el contenido antiguo de prácticas y el primer
curso en el que la nueva metodología de prácticas fue
plenamente aplicada. Se puede observar una clara mejora que
se hace patente en el incremento del porcentaje de estudiantes
con nota igual o superior a notable. Asimismo es reseñable la
disminución del porcentaje de estudiantes no presentados.
Para estudiar la influencia de la metodología en el grado de
comprensión de las máquinas algorítmicas se ha procedido a
analizar la evaluación obtenida por los estudiantes en dos
ejercicios del examen final relativos al desarrollo de una
máquina algorítmica microprogramada. La nota media global
de los dos ejercicios fue 6,38. En concreto uno de esos dos
ejercicios estaba centrado en la estructura de la UC. En dicho
ejercicio, la nota media fue 7,00. Todos estos resultados
demuestran, a nuestro juicio, la efectividad de la metodología
docente descrita.
Otro punto importante era conocer la valoración que tenían
los estudiantes sobre la labor realizada y la metodología
seguida en las prácticas. Para ello se procedió a realizar una
encuesta cuyos principales resultados se pueden observar en la
Tabla IV. Existe una amplia coincidencia en que la realización
de la práctica ha contribuido a la profundización de los
conceptos presentados en las clases de teoría. El uso del
entorno Moodle para el seguimiento de las prácticas y la
documentación proporcionada para la realización de cada
sesión también ha recibido una valoración bastante positiva.
En relación al uso de una wiki para la realización del trabajo
de grupo existe una mayor disparidad de criterios: algunos
estudiantes la señalan como uno de los elementos más
TABLA III
COMPARATIVA NOTAS FINALES 1ª CONVOCATORIA
Metod. antigua
Metod. nueva
No presentados
16,3 %
6,1 %
Suspensos
8,4 %
16,2 %
Aprobados
42,1 %
33,3 %
Notables o superior
33,2 %
44,4 %
93
VII. CONCLUSIONES
Se ha desarrollado una metodología de base práctica
orientada a facilitar y mejorar la comprensión de las máquinas
algorítmicas, concretamente aquellas cuya unidad de control es
microprogramada. La aplicación de esta metodología se ha
traducido en la obtención de un alto rendimiento académico de
nuestros estudiantes y en un creciente interés por la asignatura,
si bien ha requerido un importante esfuerzo por parte del
profesorado.
En la actualidad nuestro trabajo se centra en la introducción
de diversas variantes en LittleProc tanto a nivel de módulos
como a nivel de arquitectura (UP con 1, 2 o 3 buses) para
conseguir que cada grupo realice una práctica distinta del
resto, evitando el riesgo de copia y promoviendo una labor
cooperativa entre grupos. Asimismo, el hecho de que se
implementen diversas versiones de arquitectura puede permitir
un análisis comparativo del rendimiento y características de
dichas variantes.
Otra posibilidad interesante sería la de promover que algún
grupo de trabajo realizase la versión cableada de la UC y de
esa forma tener la oportunidad de realizar una comparativa
entre la versión microprogramada y la cableada.
TABLA IV
RESULTADOS DE LAS ENCUESTAS
Nivel de dificultad de la práctica [ 1 (bajo) – 5 (alto) ]
Contribución de la práctica a la mejor comprensión de los
conceptos estudiados en teoría/problemas [1 (poca) – 5(mucha) ]
Valoración de la documentación proporcionada para la realización de las diversas sesiones de prácticas [ 1 (baja) – 5 (alta) ]
Valoración de la contribución del entorno Moodle al desarrollo
de las prácticas [ 1 (baja) – 5 (alta) ]
Valoración de la contribución de la wiki a la realización del
trabajo cooperativo [ 1 (baja) – 5 (alta) ]
Valoración de la planificación global de las prácticas
[ 1 (poco adecuada) – 5 (muy adecuada) ]
Valoración de la duración de las sesiones de prácticas
[ 1 (poco adecuada) – 5 (muy adecuada) ]
Tiempo personal requerido para la preparación del trabajo de
prácticas [ 1 (poco) – 5 (mucho) ]
Nivel de interés de las prácticas en relación a las prácticas de
otras asignaturas [ 1 (bajo) – 5 (alto) ]
Grado de consecución de las siguientes competencias
[ 1 (bajo) – 5 (alto)]
Trabajo en equipo
Capacidad de organización y planificación
Comunicación oral y escrita
ISSN 1932-8540 © IEEE
3,72
4,09
3,89
3,46
3,00
3,63
3,09
3,95
3,96
3,76
3,59
3,34
94
IEEE-RITA Vol. 4, Núm. 2, May. 2009
AGRADECIMIENTOS
Los autores queremos expresar nuestro agradecimiento a
Borja Martínez Huerta (MiSE-UAB) por su ayuda durante la
implementación de LittleProc en la placa de prototipado. Su
amplia experiencia en el desarrollo de sistemas electrónicos
resultó de gran importancia en esa etapa del trabajo. Asimismo
queremos agradecer a los estudiantes Justo Salcedo y Pau
Picas la realización de un ejercicio que contribuyó al diseño de
la metodología docente expuesta.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
J.P. Deschamps y J. M. Angulo, Diseño de Sistemas Digitales:
Metodología Moderna. Ed. Paraninfo, 1989.
A. Lloris y A. Prieto, Diseño Lógico. Ed. McGraw-Hill Interamericana,
1996.
D. D. Gajski, Principles of Digital Design, Ed. Prentice-Hall, 1997.
Declaración conjunta de los Ministros Europeos de Educación, The
Bologna Declaration of 19 June 1999.
R. B. Brown, R. J. Lomax, G. Carichner y A. J. Drake. “A
Microprocessor Design Project in an Introductory VLSI Course”. IEEE
Transactions on Education, vol. 43, no. 3, pag. 353-361.
J. P. Deschamps, Síntesis de Circuitos Digitales, Cap. 12, Ed.
Thomson–Paraninfo, 2002.
V. P. Heuring y H. F. Jordan, Computer Systems Design and
Architecture, Cap. 4 y 5, Ed. Pearson Prentice Hall, 2004.
A.Portero, J. Saiz, R. Aragonés, M. Rullán, J. Aguiló y E. Valderrama,
“Transforming Spanish student attitude in the face of engineering
learning”, en Proc. 10th IACEE World Conference in Continuing
Engineering Education, Viena, 2006.
R. Aragonés, J. Saiz, A. Portero, M. Rullán y J. Aguiló. “Experiencia de
Innovación Docente siguiendo las directrices del EEES en la enseñanza
del diseño digital”, Revista Latinoamericana de Tecnología Educativa
(RELATEC), vol. 5, no. 2, pag. 203-222.
Página principal de Moodle: http://moodle.org. Abril de 2009.
W. Cunningham y B. Leuf, The Wiki Way, Addison-Wesley, 2001.
Moodle derivado del servidor real usado en la asignatura de DSD:
http://ume015.uab.es/dsdmoodleRITA . Abril de 2009.
Introduction to the Quartus II Software, Altera Corporation.
UP3 Education Kit. Reference Manual, Cyclone Edition. Altera
Corporation - System Level Solutions (SLS).
Joaquín Saiz Alcaine (A’02-M’04) nació en Reus
(España) en 1967. Obtuvo el grado de Licenciado en
Ciencias (Sección Informática) por la Facultad de
Ciencias de la Universidad Autónoma de Barcelona
(UAB) en 1990. Dicho grado está homologado al de
Ingeniero en Informática.
En la actualidad es profesor colaborador en la
Escuela Técnica Superior de Ingeniería de la UAB.
Anteriormente había trabajado como profesor en la
Escuela Universitaria Politécnica de Mataró, las Escuelas Universitarias
Gimbernat y la Facultad de Ciencias de la UAB. Su labor docente se ha
desarrollado en las titulaciones de Ingeniería Informática e Ingeniería
Electrónica centrándose en el diseño de sistemas digitales y el diseño de
ASICs. Inició su labor investigadora en el Centro Nacional de
Microelectrónica participando en diversos proyectos relacionados con el
desarrollo de CAD y las bibliotecas de celdas. Posteriormente, en el
departamento de Informática de la UAB, centró su labor en el ámbito del
codiseño y los lenguajes de especificación de sistemas. Actualmente trabaja
en el departamento de Microelectrónica y Sistemas Electrónicos de la UAB en
el campo de la representación de las funciones booleanas.
Antoni Portero Trujillo (M’06) nació en Granollers,
Barcelona, España, el 2 de febrero de 1973. Ingeniero
Electrónico (97) y Máster en Microelectrónica (00) por
la Universidad Autónoma de Barcelona, Barcelona,
Cataluña, España.
Actualmente es investigador de segunda etapa en la
Universidad Autónoma de Barcelona. Anteriormente ha
sido profesor asociado (97-03) y profesor ayudante (03-07) en la mencionada
universidad. Ha sido promotor en CEPHIS (Centro de Prototipos y Soluciones
Hardware-Software, asociada a la red de innovación tecnológica de la
Generalitat de Cataluña) en el 2002 y director de proyectos desde el 2003.
Ha participado como investigador en varios proyectos de investigación con
subvenciones del gobierno y empresas privadas. Esta especializado en
sistemas reconfigurables para video compresión.
El Sr. Portero tiene más de cuarenta publicaciones de investigación y de
educación en congresos nacionales e internacionales. Es miembro del “Who is
who in the world”, Marquis (06); y del IACEE (The International Association
for Continuing Engineering Education) (06).
Raúl Aragonés Ortiz nació en Sabadell, España, el 25
de Junio de 1975. Recibió el grado de Ingeniero
Técnico en Electrónica Industrial en la Escola
Salesiana Universitaria de Sarrià en 1998 y el grado de
Ingeniero en Electrónica en la Universitat Autònoma
de Barcelona en el 2001. A su vez obtuvo el master en
informática en esta misma universidad, con la
especialidad Microelectrónica, en el 2004.
Desde el 2001 trabaja en el departamento de
Microelectrónica de la Universidad Autónoma de
Barcelona participando en varios proyectos relacionados con redes de
sensores y arquitecturas distribuidas de microsistemas, realizando varias
publicaciones en estas áreas.
Sus principales áreas de interés son los sistemas de adquisición y
conversión frecuenciales.
Mercè Rullán Ayza nació en Barcelona (1964);
licenciada en Ciencias (Sección: Informática) en la
Facultad de Ciencias de la Universidad Autónoma de
Barcelona (1988) y doctora en Informática por la
Facultad de Ciencias de misma universidad (1996).
Actualmente es Titular de Universidad (desde
1997) de la UAB en la Escuela Técnica Superior de
Ingeniería,
dentro
del
Departamento
de
Microelectrónica y Sistemas Electrónicos y
vinculada a las líneas de investigación de diseño y
test de circuitos integrados y microsistemas. Desde
1996 está relacionada con la Coordinación de la titulación de Ingeniería
Informática de la UAB y más concretamente con la adaptación de la titulación
de Ingeniería Informática al EEES (título de Grado en Tecnologías
(Informática)).
Jordi Aguiló Llobet nació en Barcelona en 1950.
Es Licenciado en Física por la Universidad de
Barcelona, Barcelona, España (1972). Doctor en
Ciencias por la Universidad Autónoma de
Barcelona, Bellaterra, España (1976), es
Catedrático de Arquitectura y Tecnología de
Computadoras de esta universidad.
Actualmente es Director del Departamento de
Microelectrónica y Sistemas Electrónicos de la
Escuela Superior de Ingenieros de la Universidad
Autónoma de Barcelona. Desde 1985 es también
investigador adscrito al Centro Nacional de Microelectrónica, CNM, del
Consejo Superior de Investigaciones Científicas y vicedirector del mismo
hasta 2002. Actualmente está coordinando el Grupo de Aplicaciones
Biomédicas del CNM. Es Gestor de la Iniciativa en Tecnologías Convergentes
de la UAB. Ha participado en numerosos proyectos europeos liderando entre
otros MicroCard y MicroTrans del programa EU-IST, aplicaciones médicas
de las microtecnologías a la cirugía cardiovascular y al trasplante de órganos
respectivamente. Fue también director de la Oficina Sur del Centro de
Competencia Europeo en Aplicaciones Médicas de las Microtecnologías de la
DG-IST. Actualmente participa en el proyecto integrado PERSONA sobre
aplicación de las TIC a la autonomía personal.
El Dr. Aguiló es coordinador científico y tecnológico del Programa
Iberoamericano de Ciencia y Tecnología para el Desarrollo. Ha participado
como experto en la iniciativa Converging Technologies for Food: 2ano-BioInfo and Cognitive Sciences de la UE y es miembro del comité científico para
aplicaciones médicas de la European Platform on Smart Systems, EPoSS.
ISSN 1932-8540 © IEEE