máquinas algorítmicas: una ... - universidade de...

Title—Algorithmic Machines: a Practical Learning

Methodology through LittleProc.

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

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

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

U

IEEE-RITA Vol. 4, Núm. 2, May. 2009 83

ISSN 1932-8540 © IEEE

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

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

Presentación y repaso deconocimientos previos

Esquemas de cálculo

Máq. Algoriítmicas: unidadde proceso

Maq. algorítmicas: unidadde control con PLA

Máq. algoriítmicas: unidadde control microprogramada

Dispositivos programables

Dudas / Preparaciónexámenes

14 / 01

5

7

11

13

3

Semanas delsemestre

9

Fig. 1. Programa y planificación de la asignatura DSD a lo largo de 1as catorce semanas que constituyen el semestre.

84 IEEE-RITA Vol. 4, Núm. 2, May. 2009

ISSN 1932-8540 © IEEE

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.

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

Fig. 2. Ejemplo de página (vista parcial) del sitio Moodle habilitado para el seguimiento de las prácticas de DSD.

SAIZ ALCAINE et al.: MÁQUINAS ALGORÍTMICAS: METODOLOGÍA PARA SU APRENDIZAJE PRÁCTICO 85

ISSN 1932-8540 © IEEE

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.

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

(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.

NOT

inst20

asynResetn

clock

inicio

zero

negative

carry

opcode[3..0]

control_signals_to_UP[19..0]

UC

inst

data[11..0]

w ren

address[7..0]

clock

q[11..0]

MemoryL1

ram

glResetn

inicio

zero

negativ e

carry

opcode[3..0]

control_s[19..0]

ck

MARdata[7..0]

MEMRW

MDRdata[11..0] MEMdata[11..0]

ck

ckn

RAM

CONTROL

UNIDAD DE

LCELL

_R1load

LCELL

_IRload

LCELL

_R1_outLCELL

_R2loadLCELL

_R2out

LCELL

_IRoutLCELL

_MARloadLCELL

_MARoutLCELL

_MDRload

LCELL

_MDRoutLCELL

_MDRmemLCELL

_MemRWLCELL

_PCloadLCELL

_PCoutLCELL

_PCinitLCELL

_ACCloadLCELL

_ALUcodeLCELL

_end

control_s[19]

control_s[18]

control_s[17]

control_s[16]

control_s[15]

control_s[14]

R1load

IRload

R1out

R2load

R2out

IRout

control_s[13]

control_s[12]

control_s[11]

MARload

MARout

MDRload

control_s[10]

control_s[9]

control_s[8]

MDRout

MDRmem

MemRW

ALUcode[2..0]

control_s[7]

control_s[6]

control_s[5]

control_s[4]

control_s[3..1]

control_s[0]

PCload

PCout

PCinit

ACCload

end

SE

ÑA

LES

DE

CO

NT

RO

L D

E L

A U

P

glResetn

ck

R1loadR2load

IRload

PCloadPCinit

MARloadMDRload

ACCload

R1outR2out

IRoutPCout

MARout

MDRoutALUcode[2..0]

MEM[11..0]

MDRmem

carry

zero

negativeIRdata[11..8]

MARdata[11..0]

MDRdata[11..0]

UP

up

carry

zero

negativ e

opcode[3..0]

MARdata[11..0]

MDRdata[11..0]

glResetn

ck

R1load

R2load

IRload

PCload

PCinit

MARload

MDRload

ACCload

R1out

R2out

IRout

PCout

MARout

MDRout

ALUcode[2..0]

MEMdata[11..0]

MDRmem

PROCESO

UNIDAD DE

VCC

glResetn INPUT

VCCck INPUT

VCCinicio INPUT

endOUTPUTE/S

Fig. 3. Esquema general de LittleProc.


ISSN 1932-8540 © IEEE

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.

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.

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) 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

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.

TABLA I CONJUNTO DE INSTRUCCIONES DE LITTLEPROC

Opcode Instrucción Descripción 0000 LDR1 $mem Carga el contenido de la posición de

memoria $mem en el registro R1 0001 LDR2 $mem Carga el contenido de la posición de

memoria $mem en el registro R2 0010 ADD Suma el contenido de los registros R1

y R2 y almacena el resultado en R1 0011 STR1 $mem Almacena el contenido del registro R1

en la posición de memoria $mem 0100 CMP Compara el registro R1 con el R2,

activando la señal zero si son iguales 0101 BRE $mem Salta a la posición de memoria $mem

si la señal zero está activa 0110 JMP $mem Salta a la posición de memoria $mem 0111 SUB Resta el contenido del registro R2 a R1

y almacena el resultado en R1 1000 END Finaliza el programa: activa la señal

end y pone al procesador en un estado de espera

1001 NOP No hace nada; su ciclo de ejecución consume un ciclo de reloj

1010 STR2 $mem Almacena el contenido del registro R2 en la posición de memoria $mem

TRI

inst38

TRI

inst39

TRI

inst40

TRI

inst41

TRI

inst42

TRI

inst43

asy nResetn

ck

load

datain[11..0]

dataout[11..0]

reg

R1

asy nResetn

ck

load

datain[11..0]

dataout[11..0]

reg

R2

asy nResetn

ck

load

datain[11..0]

dataout[11..0]

reg

IR

asy nResetn

ck

load

datain[11..0]

dataout[11..0]

reg

MDR

asy nResetn

ck

load

datain[11..0]

dataout[11..0]

reg

MAR

asy nResetn

ck

load

datain[11..0]

dataout[11..0]

reg

ACC

glResetn

ck

PCinit

PCload

PCin[11..0]

PC[11..0]

PC

inst3

A[1

1..0

]

B[1

1..0

]

Sel[2..0]

ck C[1

1..0

]

carr

yze

rone

gativ

e

ALUv 0

alu

glResetn

ck

ACCload

ACCdata[11..0]

bus1[11..0]

MDRdata[11..0]

MDRout

MARdata[11..0]

PCdata[11..0]

PCout

MARout

IRdata[11..0]

R2data[11..0]

IRout

R1data[11..0]

R2out

R1out

carry

zero

negativ e

ALU

code

[2..

0]

ck

glResetn

ck

R1load

glResetn

ck

R2load

glResetn

ck

IRload

glResetn

ck

PCinit

PCload

glResetn

ck

MARload

glResetn

ck

MDRload

MDRin[11..0]

Bus

1[11

..0]

R1

R2

IR

PC

MAR

MDR

ACC

ALU

data1x[11..0]

data0x[11..0]

sel

result[11..0]

lpm_mux4

inst6

VCCglResetn INPUT

VCCck INPUT

VCCR1load INPUT

VCCR2load INPUT

VCCIRload INPUT

VCCPCload INPUT

VCCMARload INPUT

VCCMDRload INPUT

VCCACCload INPUT

VCCPCinit INPUT

carr

yO

UT

PU

T

zero

OU

TP

UT

nega

tive

OU

TP

UT

IRda

ta[1

1..8

]O

UT

PU

T

MA

Rda

ta[1

1..0

]O

UT

PU

T

MD

Rda

ta[1

1..0

]O

UT

PU

T

MEM[11..0]MDRin[11..0]

MDRmem

Bus2[11..0]

VCCMDRmem INPUT

VCCALUcode[2..0] INPUT

VCCMEM[11..0] INPUT

VC

CR

1out

INP

UT

VC

CR

2out

INP

UT

VC

CIR

out

INP

UT

VC

CP

Cou

tIN

PU

T

VC

CM

AR

out

INP

UT

VC

CM

DR

out

INP

UT

Fig. 4. Esquema lógico de la unidad de proceso de LittleProc.


ISSN 1932-8540 © IEEE

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.

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.

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:

00: Inicio 01: Zero 10: Carry 11: 2egative Los dos bits siguientes indican el tipo de microinstrucción,

de acuerdo a los siguientes valores: 00: IF 01: GOTO 10: EXE 11: BRA2CH El resto de la microinstrucción, excepto el último bit, puede

estar formado por dos elementos: las microórdenes que

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.

VCCclock INPUT

VCCinicio INPUT

VCCasy nResetn INPUT

VCCopcode[3..0] INPUT

VCCzero INPUT

VCCnegativ e INPUT

VCCcarry INPUT

control_signals_to_UP[19..0]OUTPUT

AN

D2

inst

5

NOT

inst1

NOT

inst2

T1

T0

g

W1

W3

W2

CtrlSeq

inst9

LCE

LL

_sel

LCE

LL_T

LCE

LL

_jum

pAdd

ress

NOT

inst8

data3data2

data1

data0

sel[1..0]

result

lpm_mux1

inst7

Microprogramaaddress[5..0]

clock

q[23

..0]

romv2

inst3

asynResetn

clockw 1

w 3

input_address[5..0]instrucAddress[5..0]

output_address[5..0]

sequencer

inst11

opcode[3..0]initAddress[5..0]

IRdecoder

inst

asy nResetn

clock

jumpAddress[5..0]

g

T[1]

T[0]

w2

T[1

..0]

opcode[3..0]

sel[1..0]

w1

w3

addr

ess[

5..0

]

ROM

Secuenciador

Multiplexorcondiciones

Controlsecuenc.

ANDs

Decodificador

instrucciones

control_signals[23..22]



clock


negativ e

carry

zero

cont

rol_

sign

als[

19..

0]

inicio

Fig. 5. Esquema general de la unidad de control de LittleProc.

endSelector Mux. Condic.

Tipo μμμμ----instruc.

Señales de control de la UP ( μμμμ----instr. EXE)instr. EXE)instr. EXE)instr. EXE) /

Dirección de salto ( µ-instr. IF y GOTO)

Bits 23 22 21 20 19 14 1 0

Fig. 6. Estructura de una microinstrucción


ISSN 1932-8540 © IEEE

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

Ejecución se ha puesto a modo de ejemplo el ciclo de ejecución de la instrucción ADD.

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.

inicio

Espera

Inicialización

Búsqueda

Ejecución_END

Ejecución

IR = In

str. E

ND

IR ≠ Instr. END

EXE (PCload, PCInit)

EXE (PCout, ALU-Transp., MARload)

EXE (MDRmem, MDRload,

PCout, ALU-Incr., PCload)

EXE (MDRout, ALU-Transp., IRload)

BRANCH

EXE (end)GOTO (dirección donde

empieza periodo espera)

____inicio

Ejemplo: Instrucción ADD

EXE (R1out, ACCload)

EXE (R2out, ALU-SUMA,R1load)

GOTO (dirección donde

empieza ciclo búsqueda)

IF ([not inicio] continuar aquí)

asynResetn

Fig. 8. Máquina de estados simplificada de la UC

VCCclock INPUT

VCCw1 INPUT

VCCw3 INPUT

VCCinput_address[5..0] INPUT


VCCinstrucAddress[5..0] INPUT

output_address[5..0]OUTPUT

data

3x[5

..0]

data

2x[5

..0]

data

1x[5

..0]

data

0x[5

..0]

sel[1

..0]

resu

lt[5.

.0]

lpm

_mux

0

inst

3

INC

RE

ME

NT

AD

OR

A[5..0] A_Plus[5..0]

INC

inst

2

REGISTREasynResetn

ck

data

in[5

..0]

data

out[5

..0]

reg6

microPc

w3,w1

microPc

Incrementador

Multiplexordirecciones

inpu

t_ad

dres

s[5.

.0]

inst

rucA

ddre

ss[5

..0]

clock

asy nResetn

Fig. 7. Esquema lógico del secuenciador.


ISSN 1932-8540 © IEEE

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.

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.

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

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

TABLA II PLANIFICACIÓN DE LAS SESIONES DE PRÁCTICAS

Sesión Tipo Descripción 1 Laboratorio Introducción a Quartus II Web Edition 2 Laboratorio Bloques básicos (I): captura de esquemas 3 Seminario Introducción al VHDL 4 Laboratorio Bloques básicos (II): diseño con VHDL 5 Control

oral Preguntas sobre VHDL y bloques básicos (50% estudiantes)

6 Seminario Presentación de LittleProc 7 Laboratorio Diseño de la UP 8 Laboratorio Diseño de la UC 9 Laboratorio Diseño de LittleProc 10 Control

oral Preguntas sobre LittleProc (50% estudiantes)

11 Seminario Introducción a la placa de prototipado 12 Laboratorio Implementación de LittleProc en la placa de

prototipado 13 Control

oral Preguntas sobre la totalidad de la práctica (100% estudiantes)

VCCINPUT

VCCINPUT

VCCINPUT

W2OUTPUT

W1OUTPUT

W3OUTPUT

AND2

inst

AND2

inst1

AND2

inst2

AND3

inst3

NOT

inst4

NOT

inst5

OR2

inst7

LCE

LL

_W2

LCE

LL

_W3

LCELL

_W1

T1

g

T0

Fig. 9. Esquema lógico del módulo ctrlSeq (versión simplificable).


ISSN 1932-8540 © IEEE

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

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.

VCCck INPUT

VCCPCload INPUT

VCCglResetn INPUT

VCCPCinit INPUT

VCCPCin[11..0] INPUT

PC[11..0]OUTPUT

NOT

inst10AND2

inst8

OR2

inst9

PRN

CLRN

D

ENA

Q

DFFE

f f _0

PRN

CLRN

D

ENA

Q

DFFE

f f 11_1

ck

glResetn

PCload

PC[11..1]in[11..1]PCin[11..1]

PCinit

PCin[0]

PCinit

ck

PCload

glResetn

in[0] PC[0]

Fig. 11. Esquema lógico del módulo PCreg con InitDir = 1.

VCCck INPUT

VCCdatain[5..0] INPUT


dataout[5..0]OUTPUT

CLRN

DPRN

Q

DFF

6f f

Fig. 10. Esquema lógico del módulo microPC.


ISSN 1932-8540 © IEEE

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

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.

Fig. 13. Placa de prototipado UP3 Education Kit.

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).


ISSN 1932-8540 © IEEE

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.

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

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.

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 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 %

TABLA IV RESULTADOS DE LAS ENCUESTAS

Nivel de dificultad de la práctica [ 1 (bajo) – 5 (alto) ] 3,72 Contribución de la práctica a la mejor comprensión de los conceptos estudiados en teoría/problemas [1 (poca) – 5(mucha) ]

4,09

Valoración de la documentación proporcionada para la realiza-ción de las diversas sesiones de prácticas [ 1 (baja) – 5 (alta) ]

3,89

Valoración de la contribución del entorno Moodle al desarrollo de las prácticas [ 1 (baja) – 5 (alta) ]

3,46

Valoración de la contribución de la wiki a la realización del trabajo cooperativo [ 1 (baja) – 5 (alta) ]

3,00

Valoración de la planificación global de las prácticas [ 1 (poco adecuada) – 5 (muy adecuada) ]

3,63

Valoración de la duración de las sesiones de prácticas [ 1 (poco adecuada) – 5 (muy adecuada) ]

3,09

Tiempo personal requerido para la preparación del trabajo de prácticas [ 1 (poco) – 5 (mucho) ]

3,95

Nivel de interés de las prácticas en relación a las prácticas de otras asignaturas [ 1 (bajo) – 5 (alto) ]

3,96

Grado de consecución de las siguientes competencias [ 1 (bajo) – 5 (alto)] Trabajo en equipo 3,76 Capacidad de organización y planificación 3,59 Comunicación oral y escrita 3,34


ISSN 1932-8540 © IEEE

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] J.P. Deschamps y J. M. Angulo, Diseño de Sistemas Digitales:

Metodología Moderna. Ed. Paraninfo, 1989. [2] A. Lloris y A. Prieto, Diseño Lógico. Ed. McGraw-Hill Interamericana,

1996. [3] D. D. Gajski, Principles of Digital Design, Ed. Prentice-Hall, 1997. [4] Declaración conjunta de los Ministros Europeos de Educación, The

Bologna Declaration of 19 June 1999. [5] 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.

[6] J. P. Deschamps, Síntesis de Circuitos Digitales, Cap. 12, Ed. Thomson–Paraninfo, 2002.

[7] V. P. Heuring y H. F. Jordan, Computer Systems Design and

Architecture, Cap. 4 y 5, Ed. Pearson Prentice Hall, 2004. [8] 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. [9] 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. [10] Página principal de Moodle: http://moodle.org. Abril de 2009. [11] W. Cunningham y B. Leuf, The Wiki Way, Addison-Wesley, 2001. [12] Moodle derivado del servidor real usado en la asignatura de DSD:

http://ume015.uab.es/dsdmoodleRITA . Abril de 2009. [13] Introduction to the Quartus II Software, Altera Corporation. [14] 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-Bio-

Info 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

máquinas algorítmicas: una ... - universidade de...

Documents