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
