Escuela Politécnica Superior _ Universidad Autónom _ Grado en Ingeniería Informática _ asignatura_ DIE _ DIE Practi

Esta es una vista previa del archivo. Inicie sesión para ver el archivo original

DIE Practicas/Diapositivas_explicaciones_P2.pdf
Práctica 2
Diapositivas utilizadas en las explicaciones
 
freq_divider 
SyncReset EnableOut 
Clk 
rst_adapt 
ResetIn ResetOut 
Clk 
Reset signal 
to all circuit 
Clock signal 
to all circuit 
debounce 
Reset 
DataOut 
Clk 
EnSample 
DataIn 
Reset 
counter <10> 
Count (3:0) 
Reset 
EnableOut 
Clk 
SyncReset 
EnableIn 
counter <10> 
Count (3:0) 
Reset 
EnableOut 
Clk 
SyncReset 
EnableIn 
counter <6> 
Count (2:0) 
Reset 
EnableOut 
Clk 
SyncReset 
EnableIn 
display_ctrl 
Reset 
Clk 
Tenths (3:0) 
UpdateDisplay 
Seconds (3:0) 
Tens (2:0) 
ResetX Clk 
StartStop 
Lap 
SetToZero 
stopwatch_fsm 
ClearCount 
Reset 
EnableCountOut 
Clk 
StartStop 
Lap 
SetToZero 
EnableCountI
n 
UpdateDisplay 
debounce 
Reset 
DataOut 
Clk 
EnSample 
DataIn 
debounce 
Reset 
DataOut 
Clk 
EnSample 
DataIn 
stopwatch 
SClk 
RClk 
Ser 
SClk 
RClk 
Ser 
External port 
Esquema
stopwatch
Base de tiempos = enable
clk
enable
Base de tiempos = enable
clk
enable
D Q
CLK
E
Base de tiempos = enable
clk
enable
D Q
CLK
E
D Q
CLK
SÍ NO
Generics
entity counter is
generic (
COUNT_LENGTH : integer := 100
);
port (
Clk : in std_logic;
...
);
end counter;
i_counter_tenths : counter
generic map (
COUNT_LENGTH => 10
)
port map (
Clk => Clk,
...
);
Diseño síncrono
• Ideal : reloj único para todo el diseño
• Soporte del concepto RTL
• Simplifica el Static Timing Analysis
Situación asíncrona 1: interfaz con el exterior
Chip
(FPGA/ASIC)
Dominio Clk:
Síncrono
Exterior
Entrada 
asíncrona
Situación asíncrona 2: diferentes “dominios de reloj”
Chip
Dominio Clk1:
Síncrono
Dominio Clk2:
Síncrono
CDC
Clock Domain Crossing
Clock Domain Crossing (CDC)
= Transferencia entre 2 dominios de reloj
→ Hay que asegurarse de que se haga de un modo seguro
(No confundir con el otro CDC, tener más de un dominio de reloj puede ser 
una enfermedad, pero también algo normal)
10
Si una señal de un dominio va a dos FFs de otro dominio totalmente 
asíncrono, debido a los diferentes retardos, uno de ellos puede 
considerar la señal antes y el otro después de una transición.
Muestreo múltiple
(situación similar a lo que puede pasar dentro de un dominio si 
no cumplimos la constraint de periodo de reloj)
¡ 1 señal en nuestro RTL, múltiples valores en realidad !
D Q
D Q
D Q
retardo 2
retardo 1
mySignal
11
Mejor si capturamos la señal con un único FF y luego la usamos en 
donde haga falta:
El muestreo ha de ser único
D Q
D Q
D Q
mySignal
D Q
12
• Cuando el dato de entrada cambia “a la vez” que el 
reloj, el FF entra en un estado metaestable.
Metaestabilidad
D Q
tSETUP
13
• La salida del estado metaestable finalmente se produce, pero no 
está acotado cuánto puede tardar.
→ Tiempo de asentamiento: distribución probabilística.
• Si la salida del FF es capturada por otros FFs cuando ya se ha 
estabilizado, no hay un problema en el funcionamiento de la lógica
– Para esto hay que contar con cualquier retardo de lógica e 
interconexión hacia esos FFs destino
Metaestabilidad (2)
D Q
t asentamiento 
aleatorio
0 1
14
• Si la salida del FF metaestable llega a múltiples sitios podría 
causar corrientes elevadas, siendo peligroso.
• Si la señal va a varios destinos, cada uno la puede 
interpretar de una manera con la llegada del flanco de reloj.
¡ 1 señal en nuestro RTL, múltiples valores en realidad !
Metaestabilidad: efectos
15
• Tiempo medio entre fallos:
Metaestabilidad: efectos (2)
MTBF = 
fClk · fIN · Tw
e T/
• fClk : Frecuencia de reloj
• fIN : Frecuencia de transiciones en la entrada
• Tw : Ventana de susceptibilidad del FF
•  : Constante de tiempo de asentamiento del FF
• T : Ventana de asentamiento
Cuanto más tiempo 
haya disponible, antes 
del siguiente flanco de 
reloj, para que la señal 
se asiente, menor 
probabilidad de fallo.
Comportamiento 
exponencial
16
• No podemos evitar la metaestabilidad pero si tolerarla.
• Solución simple: utilizar 2 FFs de sincronismo
Tolerancia a la metaestabilidad
El 2º FF captura la 
salida del primero, 
proveyendo un 
valor estable (y 
único)
D Q D Q
CLK1 CLK2
D Q D Q
D Q
17
– Cuanta menor frecuencia, más fácil será que FF2 capture el 
dato ya estable.
– Cuanto más rápido el camino entre FF1 y FF2, más 
facilitaremos que FF2 capture el dato ya estable.
– Si aumentamos el número de FFs, introducimos un factor 
multiplicativo en el MTBF: interesante si la frecuencia es alta 
(donde “alta” depende de la tecnología utilizada).
Sincronizador de cadena de FFs 
D Q D Q
FF1 FF2
QDQD QDQD Según la circunstancias 
puede ser recomendable 
usar más de 2 FFs
18
entity my_block is
port (
Clk : in std_logic; -- Reloj
DataIn : in std_logic; -- Entrada de dato de otro dominio
...
);
end my_block;
architecture rtl of my_block is
signal dataMeta : std_logic;
signal dataSync : std_logic;
begin
process (Clk)
begin
if rising_edge(Clk) then
dataMeta <= DataIn;
dataSync <= dataMeta;
end if;
end process;
...
end architecture rtl;
Sincronizador en VHDL: 2 FFs
D Q D Q
DataIn dataSync
dataMeta
Barrera de antimetaestabilidad
19
entity sync is
generic (
META_LENGTH : integer := 2 -- Numero de FFs en la cadena (min=2)
);
port (
DataIn : in std_logic; -- Entrada de dato
Clk : in std_logic; -- Reloj con el que sincronizar la salida
DataOut : out std_logic -- Salida de dato
);
end sync;
architecture rtl of sync is
signal dataMeta : std_logic_vector (META_LENGTH-1 downto 0);
begin
process (Clk)
begin
if rising_edge(Clk) then
dataMeta <= dataMeta (META_LENGTH-2 downto 0) & DataIn;
end if;
end process;
DataOut <= dataMeta (META_LENGTH-1);
end architecture rtl;
Sincronizador en VHDL: N FFs
QDQD QDQD
dataMeta[0] dataMeta[1]
dataMeta
[META_LENGTH-1]
DataIn
DataOut
Otros mecanismos de sincronización entre 
dominios de reloj
• En circuitos con más de un dominio de reloj, se aplican diversas técnicas 
para transferir señales entre dominios:
• Cadenas de antimetaestabilidad
• FIFOs
• Código Gray en buses
• Handshaking
• …
ptrWrite
ptrRead
• En el laboratorio de DIE solo 
usaremos 1 dominio interno y solo 
veremos las cadenas de 
antimetaestabilidad.
Ej. FIFO 
entre dos 
dominios 
de reloj
Debouncing de pulsadores
• El pulsado de un botón no produce una señal limpia, hay “rebotes” entre 
0 y 1 hasta que la señal finalmente se estabiliza.
Debouncing de pulsadores
• El pulsado de un botón no produce una señal limpia, hay “rebotes” entre 
0 y 1 hasta que la señal finalmente se estabiliza.
Si muestreamos la entrada del pulsador muy rápidamente, veremos las subidas y bajadas:
……….-0-0-0-0-0-1-0-1-0-1-1-1-1-0-1-1-0-…….-1-1-1-1-1-1-1……
Debouncing de pulsadores
• El pulsado de un botón no produce una señal limpia, hay “rebotes” entre 
0 y 1 hasta que la señal finalmente se estabiliza.
Si espaciamos los muestreos, solo veremos una subida:
… 0 0 1 1 1 … o bien:
… 0 0 0 1 1 …
Bloque debounce
Antimetaestabilidad
Muestreo espaciado del dato 
ya sincronizado
Enable = base de tiempos 0.1 s
25
• Cuando utilizamos un reset para un circuito, este puede venir del exterior o de 
otro dominio de reloj.
• En tal caso, es necesario sincronizarlo.
• Lo importante es sincronizar la “de-aserción”, no la “aserción”:
Nos importa que todo el circuito salga de
reset a la vez.
Sincronización del reset
QDQDResetIn
ResetOut
Clk
ResetIn
Clk
ResetOut
En ASICs es típico un esquema como el siguiente:
Asercíón asíncrona Deasercíón síncrona
Reset
D Q
R
D Q
R
Bloque rst_adapt
QDQDResetIn
ResetOut
Clk
Cadena de longitud 
parametrizable
Detección de botones en la máquina de estados
RUNNING!
STOPPED!
RUNNING!
. . .
StartStop
Necesitamos 
detectar un flanco
Detectar un flanco (p.ej. de subida)
StartStop
Easy-peasy, tenemos 
flip-flops que detectan 
flancos
D Q
CLK
Detectar un flanco (p.ej. de subida)
StartStop
Easy-peasy, tenemos 
flip-flops que detectan 
flancos
D Q
CLK
NO
Detectar un flanco (p.ej. de subida) bien (I)
StartStop
startStopReg
Pasar una señal por un FF es retrasarla un cicloD Q
CLK
Detectar un flanco (p.ej. de subida) bien (II)
StartStop
startStopReg
Tenemos una señal que ocurre un 
solo ciclo por pulsación del botón, 
alineada al flanco de subida de 
StartStop
startStopRise
D Q
CLK Usar ésta en la FSM
FAST_SIMULATION
• Truco para acelerar 
simulaciones mientras 
se depura el circuito.
• Añadimos multiplexor.
1
FAST_SIMULATION
• Truco para acelerar 
simulaciones mientras 
se depura el circuito.
• Añadimos multiplexor.
• En esa posición, 
funcionamiento normal.
1
FAST_SIMULATION
• Truco para acelerar 
simulaciones mientras 
se depura el circuito.
• Añadimos multiplexor.
• En esa posición, 
funcionamiento normal.
• En esa otra posición, el 
tren de pulsos que era 
la base de tiempos es 
ahora un ‘1’ fijo -> el 
contador de décimas de 
segundo se moverá con 
cada ciclo de reloj.
1
FAST_SIMULATION (II)
• Controlamos el multiplexor mediante un generic.
• Su valor por defecto pondrá al multiplexor en funcionamiento normal → Síntesis
• Desde el testbench, un generic map podrá acelerar las simulaciones.
freq_divider
‘1’
resto del circuito
TRUE
FALSE
FAST_SIMULATION
(generic de tipo boolean)
stopwatch
FAST_SIMULATION := false
stopwatch_tb
FAST_SIMULATION => TRUE
(por defecto)
(generic map)
entity stopwatch_tb …
end …
architecture ...
begin
Testbench (I)
No tiene puertos ni generics
Declaraciones:
- component stopwatch --> igual que entity stopwatch 
- Constantes que el enunciado pide definir
(periodo de reloj, tiempo de la fase principal de la simulación)
- Señales:
- Las necesarias para estimular stopwatch y ver sus salidas
- endSimulation, de tipo boolean
architecture ...
…
begin
end …
Testbench (II)
Instancia de stopwatch
• Con generic map para FAST_SIMULATION y señales conectadas
process para el “programa principal” del test:
• Dar valor a entradas de stopwatch (no al reloj)
• Retirar el reset tras N periodos de reloj (wait for)
• Hacer un “pulsado” de StartStop de duración TP
• Esperar el tiempo definido por la constante SIM_TIME
• Activar endSimulation
• wait;
process para generar un reloj con periodo CLK_PERIOD
• En bucle continuo hasta que endSimulation sea TRUE
• Para con un “wait;”
N , TP , SIM_TIME → ver enunciado
estímulos
control fin de 
la simulación
__MACOSX/DIE Practicas/._Diapositivas_explicaciones_P2.pdf
DIE Practicas/Diapositivas_explicaciones_P3.pdf
Práctica 3
Diapositivas utilizadas en las explicaciones
SLICE
OLOGIC
ILOGIC
Output, tri-state 
buffer
(OBUF)
Input buffer
(IBUF)
Pad
Entradas y salidas básicas
STA: Static Timing Analysis – Qué es
Analizar de forma estática (sin una simulación en la que avance el tiempo) si 
el circuito cumple los requisitos de temporización.
• Entradas del proyecto: constraints
• Periodo de reloj.
• Tiempos de propagación de datos fuera de la FPGA.
• Etc.
• Entradas de la tecnología:
• Retardos en los diferentes elementos.
• Requisitos de setup, hold, etc.
• Estructura
• Jitter previsible para el reloj
• Etc.
• Salida:
• Pasa / no pasa = ¿Estamos seguros de que cualquier pieza funcionará?
STA: Static Timing Analysis - Necesidad
Si nos funciona en el laboratorio, ¿funcionará en la aplicación?
 No tiene por qué
• Pueden variar nuestras características de operación
• Proceso -> Por fabricación, salen piezas más rápidas que otras
• Voltaje -> Velocidad a 0.98V de alimentación ≠ velocidad a 1.01V
• Temperatura -> La velocidad también depende de ella
=> Caracterización PVT realizada por el fabricante.
• Pueden variar las circunstancias externas
• P.ej. la velocidad de los chips que nos rodean.
Timing: Setup y hold
• Setup: Los FF no son “perfectos”, necesitan que el dato de entrada 
esté estable un mínimo de tiempo antes:
CLK
D
Q
R
Si este tiempo es menor que tSETUP del FF, 
su salida Q se va a un estado impredecible (‘X’)
• Hold: Mismo concepto, pero el requerimiento es de estabilidad de D
tras el flanco de reloj. También hay que cumplirlo, pero lograrlo es menos problemático, en estas prácticas no le prestaremos atención. 
Slack y frecuencia máxima de operación
• El slack es el tiempo que nos sobra para poder cumplir con los 
requisitos (si es negativo, mal)
Si encogemos más y más el periodo de reloj, el retardo (delay) va a ser el mismo y el tiempo de setup 
también, pero el slack disminuye. Cuando es 0 hemos alcanzado la frecuencia máxima para ese “path”.
CLK
D
Q
R
tSETUP
slack
delay
Camino entre FFs
D Q
C
D Q
C
Clk
A B
Periodo de reloj
Retardos combinacionales 
(LUTs, etc.) + rutado (nets)
Camino entre FFs
D Q
C
D Q
C
Clk
A B
Retardo FF (C -> Q)
Retardos combinacionales 
(LUTs, etc.) + rutado (nets)
QA
Camino entre FFs
D Q
C
D Q
C
Clk
A B
Retardo de propagación combinacional
Retardos combinacionales 
(LUTs, etc.) + rutado (nets)
QA
DB
Camino entre FFs
D Q
C
D Q
C
Clk
A B
Setup
Retardos combinacionales 
(LUTs, etc.) + rutado (nets)
QA
DB
Camino entre FFs
D Q
C
D Q
C
Clk
A B
Setup
Retardos combinacionales 
(LUTs, etc.) + rutado (nets)
QA
DB
SLACK
Camino entre FFs: análisis máximo-mínimo
D Q
C
D Q
C
Clk
A B
Setup
Retardos combinacionales 
(LUTs, etc.) + rutado (nets)
QA
DB
SLACK
Que el reloj tarde lo 
máximo esperable en llegar 
al FF origen
Y lo mínimo 
esperable en llegar 
al FF destino
Clock skew
ClkA
ClkB
D Q
C
D Q
C
A B
Retardos combinacionales 
(LUTs, etc.) + rutado (nets)
Por los distintos caminos que recorre el reloj, el flanco no llegará exactamente a 
la vez a ambos FFs.
Para el análisis de cumplimiento en setup:
• Llega después al destino → a nuestro favor
• Llega antes al destino → en nuestra contra
Skew
Clock pessimism
IBUF
Pad
BUFG
Red de distribución de reloj a los FFs (clock tree)
Hasta ese punto el retardo siempre va a ser igual para cualquier FF que dependa 
de este reloj en las ramas de la derecha (aunque, para todos, dependa de PVT)
Clock pessimism
IBUF
Pad
BUFG
Red de distribución de reloj a los FFs (clock tree)
Hasta ese punto el retardo siempre va a ser igual para cualquier FF que dependa 
de este reloj en las ramas de la derecha (aunque, para todos, dependa de PVT)
• Vivado, cuando verifica los setup, asigna primero un retardo mayor (máx.) 
hasta el FF origen y uno menor (mín.) hasta el FF destino
• Luego corrige la parte que ha de ser igual: clock pessimism
Clock uncertainty
• Realmente los flancos de reloj no son perfectos
• La detección del cambio de 0 a 1 tendrá lugar a un cierto voltaje
• La señal de reloj se ve influida por el ruido de la alimentación y de pistas cercanas
Ideal
Real
Clock jitter
Jitter = Incertidumbre
• Si en una entrada recibimos una señal desde otro chip con el mismo 
reloj, Vivado no puede saber cuánto ha tardado ese chip en proveer 
el nuevo dato desde el flanco de reloj
CHIP FPGA
Clk
• Consideramos el otro chip como un FF y le decimos
a Vivado cuánto 
ha tardado en darnos el dato desde el flanco del reloj en la placa:
set_input_delay -clock reloj tID puerto_de_entrada
tID
Constraint de entrada: set_input_delay
(tID en el datasheet del chip)
• Si damos una salida a otro chip con el mismo reloj, Vivado no puede 
saber cuánto tiempo antes del flanco de reloj necesita ese chip tener 
el dato estable
FPGA
Clk
• Consideramos el otro chip como un FF y le decimos a Vivado que 
nuestra salida tiene un recorrido externo igual al setup especificado 
en la correspondiente entrada del chip:
set_output_delay -clock reloj tOD puerto_de_salida
tOD
Constraint de salida: set_output_delay
CHIP
(tOD en el datasheet del chip)
Regla de diseño: registrar las salidas
Clk
Distintos diseñadores pueden implementar distintos bloques (o “IPs“) de un 
diseño más grande.
¿Qué pasa si varios bloques se conectan en cadena?
• Si varios diseñadores dejan un path combinacional entre entradas y salidas, se 
tendrá un path combinacional más largo -> menor frecuencia máxima
• Si cada diseñador se preocupa de registrar sus salidas, los caminos 
combinacionales quedarán limitados a un bloque.
D Q
C
In
...
...
Out
D Q
C
D Q
C
D Q
C
Clk
D Q
C
In
...
...
Out
D Q
C
D Q
C
D Q
C
Camino combinacional más largo
Seguir esta regla permite que los diseñadores analicen independientemente la 
velocidad de sus bloques tras síntesis (también puede ser tras implementación física)
__MACOSX/DIE Practicas/._Diapositivas_explicaciones_P3.pdf
DIE Practicas/DIE_Practica1-lab1_2021-22.pdf
 
 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2020/2021 v1.0 1/20 
 
 
Práctica 1 
 
Tutorial 
 
Objetivo 
 
Utilizando un diseño especialmente simple, seguir con él un flujo completo con la herramienta. 
 
 
Circuito utilizado 
 
Se trata de una lógica muy simple situada entre los interruptores (SW0-SW3) y los leds (LD0-
LD3) de la placa Zybo. 
 
 
 
 
Guía para la realización 
 
En las siguientes páginas se reproduce un tutorial del programa universitario de Xilinx, adaptado para esta 
asignatura. 
 
Antes de continuar: 
• Crear una carpeta DIE y bajo ella una carpeta P1. Será aquí donde se trabaje para esta práctica. 
• Bajar de Moodle el archivo sources.zip y extraerlo como un subdirectorio sources de P1. 
 
 
LEDs: LD0-LD3 
Switches: SW0-SW3 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 2/20 
 xup@xilinx.com 
 
Vivado Design Flow 
Introduction 
This lab guides you through the process of using Vivado IDE to create a simple HDL design targeting the 
ZYBO board. You will simulate, synthesize, and implement the design with default settings. Finally, you 
will generate the bitstream and download it in to the hardware to verify the design functionality 
Objectives 
After completing this lab, you will be able to: 
• Create a Vivado project sourcing HDL model(s) and targeting a specific FPGA device located on the 
ZYBO board 
• Use the provided Xilinx Design Constraint (XDC) file to constrain the pin locations 
• Simulate the design using the Vivado simulator 
• Synthesize and implement the design 
• Generate the bitstream 
• Configure the FPGA using the generated bitstream and verify the functionality 
Procedure 
This lab is broken into steps that consist of general overview statements providing information on the 
detailed instructions that follow. Follow these detailed instructions to progress through the lab. 
Design Description 
The design takes its inputs from the slide switches, operates on them and outputs the results to the LEDs, 
as shown in Figure 1. 
 
Figure 1. The Completed Design 
 
 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 3/20 
 xup@xilinx.com 
General Flow 
 
 
 
 
 
 
 
Create a Vivado Project using IDE Step 1 
1-1. Launch Vivado and create a project targeting the XC7Z010CLG400-1 device 
and using the VHDL language. Use the provided lab1.vhd and lab1.xdc files 
from the sources\lab1 directory. 
1-1-1. Open Vivado by double clicking in the Vivado 2020.1 icon. 
1-1-2. Click Create Project to start the wizard. You will see Create A New Vivado Project dialog box. 
Click Next. 
1-1-3. Click the Browse button of the Project location field of the New Project form, browse to [our_ 
location]/P1, and click Select. 
1-1-4. Enter lab1 in the Project name field. Make sure that the Create Project Subdirectory box is 
checked. Click Next. 
 
Figure 2. Project Name and Location entry (do not use the exact location shown) 
Step 5: 
Perform the 
Timing 
Simulation 
Step 6: 
Verify 
Functionality 
in Hardware 
 
 
Step 1: 
Create a 
Vivado 
Project using 
IDE 
Step 2: 
Simulate the 
Design using 
Vivado 
Simulator 
 
Step 3: 
Synthesize 
the Design 
Step 4: 
Implement 
the Design 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 4/20 
 xup@xilinx.com 
1-1-5. Select RTL Project option in the Project Type form, and click Next. 
1-1-6. Using the drop-down buttons, select VHDL as the Target Language and Simulator Language in 
the Add Sources form. 
 
Figure 3. Selecting Target and Simulator language -> Change from Verilog to VHDL 
1-1-7. Click on the Add Files… button, browse to the sources directory, select lab1.vhd, click Ok. 
Select the Copy sources into project option and then click Next to get to the Add Constraints 
form. 
1-1-8. Click on the Add Files… button, browse to the sources directory (if necessary), select lab1.xdc 
and click OK. Make sure Copy constraints files into project is selected and then click Next. 
This Xilinx Design Constraints file assigns the physical IO locations on FPGA to the switches and 
LEDs located on the board. This information can be obtained either through the board’s 
schematic or the board’s user guide. 
1-1-9. In the Default Part form, using the Parts option and various drop-down fields of the Filter section, 
select the XC7Z010CLG400-1 part: use Family=Zynq-7000, Package=clg400, Speed=-1 to 
reduce the list. Click Next. 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 5/20 
 xup@xilinx.com 
 
Figure 4. Part Selection 
 
1-1-10. Click Finish to create the Vivado project. 
Use the file system explorer and look at the [your_drive_and_dir]/P1/lab1 directory. You will 
find that the lab1.srcs directory and the lab1.xpr (Vivado) project file have been created. Two 
directories, constrs_1 and sources_1, are created under the lab1.srcs directory; deep down 
under them, the copied lab1.xdc (constraint) and lab1.vhd (source) files respectively are placed. 
 
Figure 6. Generated directory structure 
 
 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 6/20 
 xup@xilinx.com 
1-2. Open the lab1.vhd source and analyze the content. 
1-2-1. In the Sources pane, double-click the lab1.vhd entry to open the file in text mode. 
 
Figure 7. Opening the source file 
1-2-2. Read and understand the existing, incomplete code. 
1-2-3. Complete the architecture in order to implement the logic shown in Figure 1. 
1-3. Open the lab1.xdc source and analyze the content. 
1-3-1. In the Sources pane, expand the Constraints folder and double-click the lab1.xdc entry to open 
the file in text mode. 
 
Figure 8. Opening the constraint file 
1-3-2. Lines 5-12 define the pin locations of the input switches [3:0] and lines 17-24 define the pin 
locations of the output LEDs [3:0]. 
 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 7/20 
 xup@xilinx.com 
 
Simulate the Design using the Vivado Simulator Step 2 
2-1. Add the lab1_tb.v testbench file. 
2-1-1. Click Add
Sources under the Project Manager tasks of the Flow Navigator pane. 
 
Figure 10. Add Sources 
2-1-2. Select the Add or Create Simulation Sources option and click Next. 
 
Figure 11. Selecting Simulation Sources option 
2-1-3. In the Add or Create Simulation Sources form, click the Add Files… button. 
2-1-4. Browse to the sources folder, select lab1_tb.vhd and click OK. 
2-1-5. Make sure Copy sources into project is selected and Click Finish. 
2-1-6. Select the Sources tab and expand the Simulation Sources group. 
The lab1_tb.vhd file is added under the Simulation Sources group, and lab1.vhd is automatically 
placed in its hierarchy as a dut instance. 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 8/20 
 xup@xilinx.com 
 
Figure 12. Simulation Sources hierarchy 
2-1-7. Using the Windows Explorer, verify that the sim_1 directory is created at the same level as 
constrs_1 and sources_1 directories under the lab1.srcs directory, and that a copy of lab1_tb.vhd 
is placed under lab1.srcs > sim_1 > imports > sources. 
2-1-8. Double-click on the lab1_tb in the Sources pane to view its contents. 
2-1-9. Read and understand the existing, complete code. 
 
 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 9/20 
 xup@xilinx.com 
 
2-2. Simulate the design for 50 ns using the Vivado simulator. 
2-2-1. Select Settings under the Project Manager tasks of the Flow Navigator pan, then Simulation. 
2-2-2. Select the Simulation tab, and set the Simulation Run Time value to 50 ns and click OK (see 
below). 
 
Figure 14. Setting simulation run time 
2-2-3. Click on Run Simulation under the SIMULATION tasks of the Flow Navigator pane, then click on 
Run Behavioral Simulation. 
The testbench and source files will be compiled and the Vivado simulator will be run (assuming 
no errors). You will see a simulator output similar to the one shown below. 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 10/20 
 xup@xilinx.com 
 
 
Figure 15. Simulator output 
You will see four main views: (i) Scope, where the testbench hierarchy is displayed, (ii) Objects, 
where top-level signals are displayed, (iii) the waveform window, and (iv) Tcl Console where the 
simulation activities are displayed. Notice that since the testbench used is self-checking, the 
results are displayed as the simulation is run. 
Notice that the lab1.sim directory is created under the lab1 directory, along with several lower-
level directories. 
 
Figure 16. Directory structure after running behavioral simulation 
 
 
 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 11/20 
 xup@xilinx.com 
 
2-2-4. Click on the maximize button of the waveform window ( ). Then click on the Zoom Fit button 
( ) to see the entire waveform. 
Notice that the output changes when the input changes. 
You can also float the simulation waveform window by clicking on the Float button on the upper 
right hand side of the view. This will allow you to have a wider window to view the simulation 
waveforms. To reintegrate the floating window back into the GUI, simply click on the Dock 
Window button. 
 
Figure 16. Float Button 
 
Figure 17. Dock Window Button 
2-3. Change display format if desired. 
2-3-1. Select switches[3:0] in the waveform window, right-click, select Radix, and then select Unsigned 
Decimal to view this signal in an integer form. Now, using the shift or control key, select both 
switches[3:0] and leds[3:0] and change the radix to binary as we want to see each output bit. 
2-4. Add more signals to monitor the lower-level signals and continue to run the 
simulation. 
2-4-1. De-maximize the waveform window if necessary. Expand the lab1_tb instance, if necessary, in 
the Scope window and select the dut instance. 
The swt[3:0], led[3:0] and ledSig[3:0] signals will be displayed in the Objects window. 
 
Figure 18. Selecting lower-level signals 
2-4-2. Select swt[3:0] and led[3:0], right-click and select Add to Wave Window to include then into the 
waveform window to monitor those lower-level signals. 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 12/20 
 xup@xilinx.com 
 
2-4-3. On the simulator tool buttons ribbon bar (below the main menu bar), type 50 in the simulation run 
time field, click on the drop-down button of the units field and select ns 
( ) to run for another 50 ns (total of 100 ns), and click on the ( ) 
button. 
The simulation will run for an additional 50 ns. Observe the new messages in the Tcl Console 
window. 
Now click on the Run All button ( ). The simulation will run until the simulator has nothing else 
to do, i.e., until our simulation is finished. 
2-4-4. Maximize the waveform window, click on the Zoom Fit button and observe the output. 
 
Figure 19. Running simulation until completion 
Observe the Tcl Console window and see the output is being displayed as the testbench uses the 
report sentence. 
 
Figure 20. Tcl Console output 
2-4-5. Close the simulator by selecting File > Close Simulation. 
2-4-6. Click OK and then click Discard to close it without saving the waveform. 
Synthesize the Design Step 3 
3-1. Synthesize the design with the Vivado synthesis tool and analyze the 
Project Summary output. 
3-1-1. Click on Run Synthesis under the Synthesis tasks of the Flow Navigator pane, then OK. 
The synthesis process will be run on the lab1.vhd file (and all its hierarchical files if they existed). 
When the process is completed a Synthesis Completed dialog box with three options will be 
displayed. 
3-1-2. Select the Open Synthesized Design option and click OK as we want to look at the synthesis 
output before progressing to the implementation stage. 
Click Yes to close the elaborated design if the dialog box is displayed. 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 13/20 
 xup@xilinx.com 
3-1-3. Select the Project Summary tab and understand the various sections. 
If you don’t see the Project Summary tab then select Layout > Default Layout, or click the 
Project Summary icon . 
 
Figure 21. Project Summary view 
3-1-4. Click on the Table tab under the Utilization section. 
Notice that there are an estimated three LUTs and 8 IOs (4 input and 4 output) that are used. 
 
Figure 22. Resource utilization estimation summary 
3-1-5. In The Flow Navigator, under Synthesis (expand Open Synthesized Design if necessary), click on 
Schematic to view the synthesized design in a schematic view. 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 14/20 
 xup@xilinx.com 
 
Figure 23. Synthesized design’s schematic view 
Notice that IBUFs and OBUFs are automatically instantiated (added) to the design as the input 
and output are buffered. The logical gates are implemented in LUTs (1 input is listed as LUT1, 2 
input is listed as LUT2, and 3 input is listed as LUT3). You can see that there is not a one to one 
relationship between the basic logic elements we described in our RTL and how the circuit is 
implemented, but the result is the same. 
Using the file system explorer, verify that lab1.runs directory is created under lab1. Under the 
runs directory, synth_1 directory is created which holds several files related to synthesis. 
 
Figure 24. Directory structure after synthesizing the design 
 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 15/20 
 xup@xilinx.com 
 
Implement the Design Step 4 
4-1. Implement the design with the Vivado Implementation default settings and 
analyze the Project Summary output. 
4-1-1. Click on Run Implementation under the Implementation tasks of the Flow Navigator pane, then 
OK. 
The implementation process will be run on the synthesized design. When the
process is 
completed an Implementation Completed dialog box with three options will be displayed. 
4-1-2. Select Open implemented design and click OK as we want to look at the implemented design in 
a Device view tab. 
4-1-3. Click Yes, if prompted, to close the synthesized design. 
The implemented design will be opened. 
4-1-4. In the Netlist pane, select one of the nets (e.g. swt_IBUF[0]) and notice that the net is displayed in 
the X1Y1 clock region in the Device view tab (you may have to zoom in to see it). 
4-1-5. If it is not displayed, click the Routing Resources icon to show routing resources. Take a look 
to the two end points of the net. 
 
Figure 25. Viewing implemented design 
4-1-6. Close the implemented design view and select the Project Summary tab (you may have to 
change to the Default Layout view) and observe the results. 
Select the Post-Implementation tab of Utilization if not already selected and the Table view. 
Notice that the actual resource utilization is three LUTs and 8 IOs. 
You can also see that there is no Timing information, since no timing constraints were defined for 
this combinational design. 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 16/20 
 xup@xilinx.com 
 
Using the file system explorer, verify that impl_1 directory is created at the same level as 
synth_1 under the lab1.runs directory. The impl_1 directory contains several files including the 
implementation report files. 
4-1-7. In Vivado, select the Reports tab in the bottom panel (if not visible, click Window in the menu bar 
and select Reports), and double-click on the utilization report entry under the Place Design 
section. The report will be displayed in the auxiliary view pane showing resource utilization. Note 
that since the design is combinational no registers are used. 
 
 
Figure 27. Viewing utilization report 
 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 17/20 
 xup@xilinx.com 
 
Perform Timing Simulation Step 5 
5-1. Run a timing simulation. 
5-1-1. Select Run Simulation > Run Post-Implementation Timing Simulation process under the 
Simulation tasks of the Flow Navigator pane. Disregard a possible warning message. 
The Vivado simulator will be launched using the implemented design and lab1_tb as the top-level 
module. 
Using the Windows Explorer, verify that timing directory is created under the lab1.sim > sim_1 > 
impl directory. The timing directory contains generated files to run the timing simulation. 
5-1-2. Click on the Zoom Fit button to see the waveform window from 0 to 50 ns. 
5-1-3. Right-click at 20 ns (where the switches input is set to 2) and select Markers > Add Marker. 
5-1-4. Similarly, right-click and add a marker at the moment where the leds changes to its final value for 
this input, 7. You can also add a marker by clicking on the Add Marker button ( ). 
 
Figure 28. Timing simulation output 
Notice that we monitored the expected led output at 10 ns after the input is changed (see the 
testbench), whereas the actual delay is about 8 ns. 
5-1-5. Close the simulator by selecting File > Close Simulation without saving any changes. 
 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 18/20 
 xup@xilinx.com 
Generate the Bitstream and Verify Functionality Step 6 
6-1. Connect the board and power it ON. Generate the bitstream, open a 
hardware session, and program the FPGA. 
6-1-1. Make sure that the Micro-USB cable is connected to the PROG UART connector (next to the 
power ON/OFF switch). 
6-1-2. Make sure that the JP7 is set to select USB power. Connect the USB cable to the PC. 
 
Figure 29. Board connection 
6-1-3. Power ON the switch on the board. 
6-1-4. Click on the Generate Bitstream entry under the Program and Debug tasks of the Flow 
Navigator pane, then OK. 
The bitstream generation process will be run on the implemented design. When the process is 
completed a Bitstream Generation Completed dialog box with three options will be displayed. 
 
Figure 30. Bitstream generation 
This process will have generated a lab1.bit file under impl_1 directory in the lab1.runs directory. 
 
Lab Workbook Vivado Design Flow 
 
 Based on www.xilinx.com/support/university 19/20 
 xup@xilinx.com 
6-1-5. Select the Open Hardware Manager option and click OK. 
The Hardware Manager window will open indicating “unconnected” status. 
6-1-6. Click on the Open target link, then Auto Connect. 
You can also click on the Open recent target link if the board was already targeted before. 
 
Figure 30. Opening new hardware target 
6-1-7. The Hardware Session status changes from Unconnected to the server name and the FPGA 
device is shown. Also notice that the Status indicates that it is not programmed. 
 
Figure 32. Opened hardware session 
6-1-8. Select the device and verify that the lab1.bit is selected as the programming file in the General 
tab of the Hardware Device Properties pane. 
 
Figure 33. Programming file 
6-1-9. Right-click on the device and select Program Device… or click on the Program device link to 
program the target FPGA device. 
P1: Lab1 Workbook 
 
 Based on www.xilinx.com/support/university 20/20 
 xup@xilinx.com 
 
Figure 34. Selecting to program the FPGA 
6-1-10. Click Program to program the FPGA. 
The DONE light will light when the device is programmed. You may see some other LEDs lit 
depending on switch positions. 
6-1-11. Verify the functionality by flipping switches and observing the output on the LEDs (Refer to the 
earlier logic diagram). 
6-1-12. When satisfied, close the hardware session by selecting File > Close Hardware Manager. 
6-1-13. Power OFF the board. 
6-1-14. Close the Vivado program by selecting File > Exit and click OK. 
Conclusion 
The Vivado software tool can be used to perform a complete design flow. The project was created using 
the supplied source files (HDL model and user constraint file). A behavioral simulation using the provided 
testbench was done to verify the model functionality. The model was then synthesized, implemented, and 
a bitstream was generated. The timing simulation was run on the implemented design using the same 
testbench. The functionality was verified in hardware using the generated bitstream. 
 
__MACOSX/DIE Practicas/._DIE_Practica1-lab1_2021-22.pdf
DIE Practicas/DIE_Practica3_2021-22.pdf
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 1/9 
 
Diseño de Alta Velocidad. Temporización y Segmentación 
(Pipelining) 
 
 
 
Objetivo 
El objetivo de esta práctica es el familiarizarse con la problemática del diseño de alta velocidad y 
utilizar diferentes estrategias de mejora de los resultados de “timing”. Como ejemplo, se usará un 
circuito que computa un checksum (suma de verificación) como el utilizado en las cabeceras de los 
paquetes IP (Internet Protocol), UDP o TCP. Durante el desarrollo de la práctica se verá cómo 
interpretar los reportes de “timing” proporcionados por las herramientas; también se prestará 
atención a los reportes relacionados con el área ocupada por el diseño. 
 
Descripción del Diseño 
El checksum calculado, de 16 bits, es el complemento a uno, de la suma en complemento a uno, de 
todas las palabras de 16 bits de las cabeceras y carga útil de las tramas del protocolo. En este 
circuito simplificaremos el problema al calcular el checksum de 8 palabras de entrada de 16 bits. 
 
Complemento a uno y la operación de Suma. 
 
Un sistema de complemento a uno es un sistema donde los números negativos están representados 
por el inverso de las representaciones binarias de sus correspondientes números positivos. En tal 
sistema, un número es negado (convertido de positivo a negativo
o viceversa) calculando el 
complemento de cada bit. Un número de N bits en complemento a uno sólo puede representar 
enteros en el rango − (2N−1−1) a 2N−1−1 (el complemento a dos puede expresar −2N−1 a 2N−1−1). En 
complemento a uno existe doble representación del cero (000…000 y 111…111). 
La regla empírica para la suma (o resta) es que se debe recircular el bit de acarreo. Por ejemplo, en 
un sistema de representación de 5 bits (números decimales entre -15 y 15), la suma 10dec + -5dec 
(10 dec = 01010 bin; -5 dec = 11010 bin) será: 
0 1 0 1 0 10 dec 
1 1 0 1 0 -5 dec 
(1) 0 0 1 0 0 
+ 1 
0 0 1 0 1 5 dec 
 
NOTA: Una posibilidad para sumar en complemento a uno dos números es hacer dos sumas en complemento a dos, una 
con una entrada de acarreo (carry in) a 0 y la otra con esta entrada a 1. Dependiendo de si hay acarreo de salida (carry 
out), se seleccionaría el resultado de una u otra suma en complemento a dos como el resultado de la suma en 
complemento a uno. Esto puede verse implementado en una función VHDL en el código entregado. 
 
Suma en complemento a uno usando sumadores en complemento a dos. 
 
Una interesante propiedad es que la suma de múltiples números complemento a uno puede hacerse 
con una suma en complemento a dos (suma de enteros), con una posterior reducción complemento a 
uno (recirculando los bits de acarreo). 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 2/9 
 
Ejemplos de suma de 4 valores en 5 bits. Podemos sumar los valores en complemento a 2 y realizar 
la reducción complemento a uno. 
 
0 1 0 1 1 11 1 1 1 1 1 -0 1 1 0 1 1 -4 
 1 0 0 0 1 -14 1 1 1 1 1 -0 1 1 1 0 1 -2 
0 1 1 0 1 13 1 1 1 1 0 -1 0 1 0 1 0 10 
1 1 0 1 1 -4 1 1 1 1 1 -0 1 1 1 0 1 -2 
(1 0) 0 0 1 0 0 (1 1) 1 1 0 1 1 (10) 1 1 1 1 1 
+ 1 0 + 1 1 + 1 0 
( 0) 0 0 1 1 0 6 ( 0) 1 1 1 1 0 -1 ( 1) 0 0 0 0 1 
+ 0 + 0 + 1 
0 0 1 1 0 6 1 1 1 1 0 -1 * 0 0 0 1 0 2 
 
* En este último ejemplo fue necesario el segundo ajuste (recirculación final del bit) 
 
El problema del cálculo de nuestro checksum se simplifica por tanto en realizar 8 sumas de 16 bits y 
la reducción complemento a 1. Una construcción rápida será realizar un árbol de suma de los 8 
elementos como el sugerido en la Figura 1 de abajo, más una reducción complemento a uno final. 
El circuito adicionalmente dispone de una señal SoP (Start of Packet) que señala cuándo capturar 
datos de entrada. La señal ChksumValid señala cuándo es válido el dato a la salida. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1. Circuito que calcula el checksum, con registros en entrada y salida. 
SoP 
 
 
 
ChksumValid 
 
ChksumOut 
 
 
 
16 bits add 
 
16 bits add 16 bits add 
 
16 bits add 
 
18 bits add 
1´s comp reduc 
17 bits add 17 bits add 
not 
 
16 
 
16 
 
 
PktData0 
 
16 
 
 
16 
 
 
PktData1 
 16 
 
 
16 
 
 
16 
 
 
16 
 
 
16 
 
 
16 
 
PktData2 
 PktData3 
 
PktData4 
 PktData5 
 
PktData6 
 PktData7 
 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 3/9 
 
Realización de la práctica 
La práctica consta de 4 ejercicios en los que se analiza el circuito a diferentes frecuencias de 
operación y finalmente se expone la estrategia de pipelining para aumentar su máxima frecuencia. 
 
Preparación del diseño 
Con objeto de favorecer la limpieza y comprensión del diseño se entregan directorios con la 
estructura siguiente, que habrá de mantenerse: 
P3_checksum/ 
rtl/ - Código fuente VHDL para el diseño 
sim/ - Directorio de simulación, que contiene los ficheros del banco de pruebas (testbench). 
vivado/ - Directorio que contendrá el proyecto Vivado; se entrega con un fichero .xdc con las 
restricciones (constraints) de posicionamiento de pines y una restricción inicial para 
el reloj. 
Ejercicio 1: Puesta en Marcha 
En este primer ejercicio se busca comprender el diseño, crear un proyecto Vivado para el mismo y 
realizar un primer análisis, tanto de área ocupada como de temporización: 
1. Crear un nuevo proyecto Vivado “chksum”, con su propio subdirectorio en el directorio 
vivado/. Añadir al proyecto el fichero chksum.vhd (con la casilla Copy sources into project 
desactivada) y, como ficheros de simulación (seleccionar “Simulation only”, ver imagen 
debajo), los archivos de testbench chksum_tb.vhd y package tb_fifo_pkg.vhd. 
 
Agregar también el fichero de constraints (.xdc) proporcionado. Utilizar un dispositivo Zynq 
7z020 con package clg484 y speed grade -1. Se trata de un dispositivo relativamente 
pequeño pero con suficientes pines para las entradas-salidas del diseño 
2. Lo primero es entender el funcionamiento del circuito de cómputo de checksum. 
3. Realizar una simulación funcional del diseño.¿Funciona correctamente? Interpretar los 
resultados. Obsérvese que la simulación tiene una primera zona con pulsos de la entrada SoP 
espaciados, seguida de otra zona con SoP a ‘1’ de forma continua. Comprobar la relación 
temporal entre SoP y ChksumValid (comparar para esto las ondas con el código de 
chksum.vhd). 
 En la tabla de resultados al principio de la Hoja de Respuestas, rellenar la primera celda 
(Latencia para el Ej.1). Se puede obtener la respuesta razonando sobre el código o 
viendo las ondas de la simulación. 
4. Observar el contenido del fichero de restricciones ¿Cuál es la frecuencia objetivo? ¿Qué se 
restringe adicionalmente en este fichero? 
 Anotar frecuencia y periodo objetivo en la hoja de resultados de la práctica. 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 4/9 
 
 
5. Implementar el diseño y observar los resultados post-implementación. 
5.1. Área. 
Podemos obtener datos de área en varios sitios, por ejemplo: 
• En el panel de resumen del proyecto (Project Summary). Si se hubiese cerrado esta 
ventana, puede volver a abrirse en Window-> Project Summary (icono sumatorio de 
la barra). Aquí aparece una visión resumida de la información. 
 
• Una información más completa puede obtenerse abriendo el diseño implementado (Open 
Implemented Design) y allí accediendo al informe de uso (Report Utilization) 
 En la tabla de la Hoja de Respuestas, completar las filas en rojo para la columna “Ej.1.”. 
Han de ser valores tras implementación, no tras síntesis. 
5.2. Timing. 
Podemos obtener un informe de tiempos ejecutando Report Timing Summary (también en el 
panel izquierdo). De nuevo, ha de tenerse cuidado de obtener el informe tras 
implementación, no tras síntesis. En el resumen podemos ver el peor caso para el slack 
(WNS, Worst Negative Slack). Podemos ver los 10 peores caminos en cuanto a margen para 
cumplir el setup en el apartado Intra-Clock Paths/clk/Setup. El camino crítico (el de menor 
slack, ojo, no el de menor retardo) es el primero de la lista. En la tabla podemos ver varios 
valores al respecto, pero haciendo doble clic sobre la línea correspondiente podremos 
acceder a una ventana con más detalles: 
• Resumen de datos del camino: origen, destino, slack, reloj utilizado, etc. (haciendo clic 
sobre los valores en azul se muestra la fórmula utilizada para su cálculo). 
• Source Clock Path: camino que sigue el reloj desde la entrada a la FPGA hasta el pin de 
reloj del flip-flop origen. 
• Data Path: camino de datos entre el flip-flop origen y el flip-flop destino.
• Destination Clock Path: camino que sigue el reloj desde la entrada a la FPGA hasta el 
pin de reloj del flip-flop destino. 
Estudiar este camino crítico. En él veremos diferentes recursos de la FPGA, tanto recursos 
combinacionales como flip-flops, separados por recursos de interconexión (net). Entre los 
elementos combinacionales encontraremos recursos de las slices (p.ej. LUT3, CARRY4), 
buffers de entrada/salida (p.ej. IBUF, OBUF) y buffers de reloj (BUFG). Los flip-flops 
reciben distintos nombres según la configuración utilizada (p.ej. FDRE para un FF tipo D 
configurado para usar patas de Reset síncrono y Enable). 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 5/9 
 
Dos columnas nos muestran el retardo de cada elemento (Incr) y el retardo acumulado en el 
camino (Path). Realmente en la primera columna, además de retardos, aparecen la 
contribución de otros valores temporales asociados al elemento en cuestión (p.ej. el setup de 
un FF), el instante de tiempo relativo en que ocurren los flancos de reloj implicados, y 
valores de ajuste del cálculo (p.ej. clock pessimism, clock uncertainty). 
La forma de comprobar si el path cumple con las restricciones de tiempo es ver si el dato 
llega al FF de destino antes que el reloj. En relación con esto puede observarse lo siguiente: 
• El Data Path sigue acumulando retardos a partir del punto en que termina el Source 
Clock Path, encontrándose como primer elemento del Data Path el tiempo de respuesta 
del FF (entre su reloj y su salida). 
• El Destination Clock Path tiene como punto de partida el siguiente flanco de reloj 
respecto al Source Clock Path. 
• El setup del FF destino contribuye como un valor que restamos del camino del reloj para 
el FF destino (como tenemos que tener el dato listo X tiempo antes del flanco de reloj, a 
la hora de realizar la comparación mencionada arriba es como si el flanco llegase X 
tiempo antes). Aquí se da una circunstancia que despista bastante: el setup del FF en los 
dispositivos de la Serie 7 de Xilinx es negativo, con lo que parece que se suma en vez de 
restarse (y además en la columna Incr aparece como positivo, porque muestra el 
incremento en el path, más que el valor correspondiente al elemento). 
• El pesimismo en el cálculo de los caminos del reloj (clock pessimism) suma al camino 
del reloj hacia el FF destino, es decir, se compensa el pesimismo poniendo más fácil 
cumplir la comparación mencionada arriba. 
• La incertidumbre en los tiempos a considerar para los flancos de reloj (clock uncertainty) 
resta al camino del reloj hacia el FF destino, es decir, pone más difícil cumplir el 
objetivo. 
Tras entender el reporte: 
 En la tabla de la Hoja de Respuestas, completar las filas en azul para la columna “Ej.1.”. 
 Rellenar los valores de la figura de camino crítico de flip-flop a flip-flop que aparece en 
la Hoja de Respuestas. 
 Sobre la ventana de reporte de este peor path, hacer clic con el botón derecho y 
ejecutar “Export Entire Path to Spreadsheet…”; usar el nombre de fichero 
TableEj1.xls (en el directorio vivado/). 
 
RECOMENDACIÓN: 
Crear un archivo comprimido en este momento y al terminar cada uno de los siguientes ejercicios 
(ejercicio 2, 3a, 3b y 4). De esta forma, si se desea, se podrá volver a abrir el proyecto tal como 
estaba en estos puntos. 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 6/9 
 
Ejercicio 2: Tiempos en entradas y salidas 
Para la realización de este ejercicio se tendrán en cuenta las siguientes características del sistema 
del que la FPGA formará parte: 
• Los retardos de la placa de circuito impreso (PCB) se considerarán despreciables (los chips 
están muy cercanos entre sí). 
• La FPGA está situada entre dos chips, el primero entrega los datos sobre los que realizar el 
checksum y el segundo utiliza el valor de checksum que la FPGA calcula. 
• Los tres chips funcionan síncronamente con el flanco positivo de un mismo reloj, el que la 
FPGA recibe en su puerto Clk. Este reloj tiene una frecuencia de 50 MHz. 
• En el datasheet del primer chip puede verse que éste entrega sus salidas 3 ns tras el flanco de 
reloj. Esto es, la FPGA recibe sus datos de entrada (PktData* y SoP) 3 ns tras el flanco de 
reloj. 
• En el datasheet del segundo chip puede verse que éste requiere respetar un tiempo de setup 
de 0.4 ns para los datos que recibe, respecto al flanco positivo del reloj. Esto es, la FPGA 
debe entregar sus salidas (ChksumOut y ChksumValid) con tiempo suficiente para que el 
chip que las recoge las vea estables desde 0.4 ns antes del flanco de reloj. 
 
 
 
 
 
 
 
 
 
 
Figura 2. Condiciones temporales de las entradas y salidas de la FPGA en el sistema 
 
Teniendo en cuenta todo esto: 
• Modificar las restricciones (constraints) de tiempos de entrada/salida que aparecen al final 
del fichero de constraints, set_input_delay y set_output_delay, para que la herramienta 
intente cumplir los requisitos de la FPGA en el sistema. Descomentar las líneas borrando el 
primer carácter (#) y modificar los valores. Entender los argumentos que forman parte de 
estos comandos de constraints (sin necesidad de investigar la sintaxis en detalle). 
• Re-implementar y generar reportes de timing específicos para las entradas y para las salidas. 
Para ello, ejecutar dos veces Reports > Timing > Report Timing…; en un caso especificar 
como Start Points “[all_inputs]” (sin las comillas) y en el otro como End Points 
“[all_outputs]”, dejando en cada caso la casilla contraria en blanco. 
 Estudiar el reporte del camino peor resultante en cada uno de los dos reportes de timing. 
Sobre la ventana de reporte de este peor path, hacer clic con el botón derecho y 
ejecutar “Export Entire Path to Spreadsheet…” Usar el nombre de fichero 
TableEj2in.xls para las entradas y TableEj2out.xls para las salidas (ambos ficheros 
deben quedar en el directorio vivado/). 
 ¿Se cumplen los requisitos? ¿Cuál es el slack para la constraint de las entradas? ¿Y para 
la de las salidas? Responder a estas preguntas en la Hoja de Respuestas. 
 
Reloj del sistema 
t SETUP = 0.4 ns 
t OUT = 3.0 ns 
FPGA CHIP 1 CHIP 2 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 7/9 
 
Ejercicio 3: Cambios en la frecuencia de reloj 
En este ejercicio se introducen requisitos más exigentes para la velocidad del reloj. Los procesos de 
Synthesis, Mapping y Place and Route tratarán de cumplir los requisitos impuestos, tras lo cual 
realizaremos un análisis de tiempos. 
a) 
1. Partiendo del fichero de constraints tal y como lo hemos dejado en el ejercicio anterior, 
asignar ahora un objetivo de periodo de reloj para el diseño de 12 ns (83.333 MHz), 
editando el fichero XDC. Tener en cuenta que en la constraint el reloj debe mantener su 
forma (“-waveform”) con duty cycle del 50%, esto es, primer flanco en t=0 y segundo en 
t=Periodo/2. 
2. Reimplementar y mirar el reporte de Report Timing Summary. 
 ¿Se logra cumplir los requerimientos?¿Qué tipo de camino provoca el peor slack (entrada, 
salida o interno) y cuál es el valor de este slack?. Responder en la Hoja de Respuestas. 
 Anotar los resultados de área y timing en la tabla de la Hoja de Respuestas (“3a”). 
 Exportar el reporte detallado del camino crítico, igual que se ha hecho en otros apartados. 
Utilizar el nombre TableEj3a.xls (de nuevo este fichero debe quedar en el directorio 
vivado/). 
b) 
3. A continuación imaginaremos que la comunicación de la FPGA con los otros chips no es un 
problema (hay técnicas para mejorar el timing en las interfaces que quedan
fuera de los 
objetivos de esta práctica). Nos centraremos en la constraint de reloj. Quitar las restricciones 
de entrada-salida: Volver a comentar, en el fichero XDC resultante del apartado a), las lineas 
set_input_delay… y set_output_delay… (poniendo un carácter ‘#’ al principio de la línea). 
4. Modificar el requisito de periodo de reloj a 8 ns (125 MHz) 
5. Reimplementar y mirar el reporte de Report Timing Summary. 
 ¿Se logra cumplir los requerimientos? ¿Qué slack tenemos? Responder en la Hoja de 
Respuestas. 
 Anotar los resultados de área y timing en la tabla de la Hoja de Respuestas (“3b”). 
 Exportar el reporte detallado del camino crítico, igual que se ha hecho en otros apartados. 
Utilizar el nombre TableEj3b.xls (de nuevo este fichero debe quedar en el directorio 
vivado/). 
 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 8/9 
 
 
Ejercicio 4: Pipeline 
En este ejercicio se realiza una segmentación (pipeline) del circuito, aplicando una cadena de flip-
flops en mitad de la ruta de datos (ver Figura 3 más abajo). Esto aumenta la latencia (retardo de 
entrada a salida), pero produce una mejora significativa en la velocidad de reloj soportada. 
Partir del proyecto tal y como queda al final del ejercicio 3. Esta vez no tocaremos el fichero de 
constraints sino el VHDL. Añadir una etapa de registros intermedios de pipeline en chksum.vhd, tal 
como se muestra en la Figura 3. 
• Simular el circuito, comprobando su corrección tras los cambios. 
• Reimplementar y mirar el reporte de Report Timing Summary. 
 ¿Se logran los requerimientos? ¿Qué slack tenemos? Responder en la Hoja de Respuestas. 
 Anotar los resultados de área y timing en la tabla de la Hoja de Respuestas (“4”). 
 Exportar el reporte detallado del camino crítico, igual que se ha hecho en otros apartados. 
Utilizar el nombre TableEj4.xls (de nuevo este fichero debe quedar en el directorio vivado/). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3. Checksum segmentado en dos etapas (una etapa de registros intermedia). 
 
SoP 
 
 
 
ChksumValid 
 
ChksumOut 
 
1´s comp reduc 
 
16 
 
17 bits add 17 bits add 
 
not 
16 
 
 
18 bits add 
16 bits add 
 
16 bits add 16 bits add 
 
16 bits add 
 
 
16 
 
 
16 
 
 
16 
 
 
16 
 
 
16 
 
 
16 
 
 
16 
 
 
16 
 
PktData0 
 PktData1 
 
PktData2 
 PktData3 
 
PktData4 
 PktData5 
 
PktData6 
 PktData7 
 
Laboratorio de Dispositivos Integrados Especializados 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 9/9 
 
Preguntas adicionales para razonar (no se requiere entrega) 
a. Teniendo en cuenta solo la constraint de periodo de reloj, si obtenemos un determinado 
WNS (Worst Negative Slack), ¿cuál sería el mínimo periodo de reloj que podríamos utilizar? 
b. ¿Cómo se relacionan para el camino crítico los conceptos: WNS, Period Requirement, Data 
Path Delay, Clock Path Skew, Tiempo de Setup del FF y Clock Uncertainty? 
c. ¿Tiene sentido que al ser más restrictivo (reducir el período) cambie el uso de recursos 
(cantidad de registros y/o número de slices y LUTs)? 
 
 
Entrega 
Antes de la fecha límite especificada en el calendario del laboratorio deberá entregarse en Moodle 
un único archivo comprimido (zip o rar) con: 
• El directorio P3_checksum completo. Bajo el subdirectorio vivado deberá estar el proyecto 
entero de Vivado y los ficheros Table*.xls cuya generación se solicita en este enunciado. 
 
• La Hoja de Respuestas que se proporciona en Moodle, con las respuestas rellenas y el nombre 
del alumno. Dejar esta hoja directamente bajo el directorio P3_checksum. La hoja puede 
entregarse en formato Word o PDF (en este último caso puede ser el resultado de escanear el 
documento relleno a bolígrafo, mientras se entienda bien). 
 
El archivo comprimido deberá tener la siguiente nomenclatura: 
<<nº de grupo>>_<<nº de alumno (dos dígitos)>>_<<nº de práctica>>.[zip|rar] 
(Ej.: 3311_05_3.zip para el alumno 5 del grupo de DIE de los lunes) 
 
Se recuerda que los alumnos deberán comprender el diseño completo y familiarizarse con él. 
__MACOSX/DIE Practicas/._DIE_Practica3_2021-22.pdf
DIE Practicas/DIE_Practica2_2021-22.pdf
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 1/16 
 
Práctica 2 
 
Completar el diseño de un cronómetro 
Objetivos 
 
- Realizar el flujo de diseño con un ejemplo más complejo que el de la Práctica 1. 
- Practicar la codificación en lenguaje VHDL, desde estructuras simples hasta más 
avanzadas como funciones, generics y packages. 
- Ver un mecanismo para acelerar las primeras simulaciones. 
 
NOTA IMPORTANTE: En esta práctica se trabaja sobre un diseño incompleto, 
entregándose a los alumnos porciones de código ya escritas. Los alumnos deberán 
comprender todo el código. A la hora de evaluar la práctica se podrán hacer preguntas 
sobre cualquier parte del diseño. 
 
Circuito utilizado 
 
En este ejercicio implementaremos sobre la placa Zybo un cronómetro de tres dígitos, con 
segundos (0-59) y décimas. El cronómetro se visualizará sobre los tres displays 7-segmentos 
de la placa de expansión tipo pmod OHO-DY1. Usaremos los pulsadores BTN3 a BTN0 
para lo siguiente: 
- BTN3: Reset asíncrono general del circuito. 
- BTN2: Puesta a cero del cronómetro. 
- BTN1: Parada y rearranque (Start/Stop) de la cuenta. 
- BTN0: Función “Lap” para mostrar el tiempo de una vuelta sin que pare el cronómetro, 
que vuelve a mostrar el tiempo actual al pulsar el botón una segunda vez. 
 
 
 
RESET 
(ResetX) 
ARRANQUE 
/PARADA 
(StartStop) 
PUESTA A 
CERO 
(SetToZero) 
TIEMPO DE 
VUELTA 
(Lap) 
Punto 
decimal 
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 2/16 
 
 
La siguiente figura muestra un diagrama de bloques del circuito: 
 
 
freq_divider 
SyncReset EnableOut 
Clk 
rst_adapt 
ResetIn ResetOut 
Clk 
Reset signal 
to all circuit 
Clock signal 
to all circuit 
debounce 
Reset 
DataOut 
Clk 
EnSample 
DataIn 
Reset 
counter <10> 
Count (3:0) 
Reset 
EnableOut 
Clk 
SyncReset 
EnableIn 
counter <10> 
Count (3:0) 
Reset 
EnableOut 
Clk 
SyncReset 
EnableIn 
counter <6> 
Count (2:0) 
Reset 
EnableOut 
Clk 
SyncReset 
EnableIn 
display_ctrl 
Reset 
Clk 
Tenths (3:0) 
UpdateDisplay 
Seconds (3:0) 
Tens (2:0) 
ResetX Clk 
StartStop 
Lap 
SetToZero 
stopwatch_fsm 
ClearCount 
Reset 
EnableCountOut 
Clk 
StartStop 
Lap 
SetToZero 
EnableCountI
n 
UpdateDisplay 
debounce 
Reset 
DataOut 
Clk 
EnSample 
DataIn 
debounce 
Reset 
DataOut 
Clk 
EnSample 
DataIn 
stopwatch 
SClk 
RClk 
Ser 
SClk 
RClk 
Ser 
External port 
 
 
Un bloque de división de frecuencia (freq_divider) se encarga de dividir por 12.500.000 el 
reloj de 125 MHz de la placa para dar un pulso de un ciclo cada décima de segundo. A partir 
de esta base de tiempos, tres contadores en cascada (counter) proveen la cifra de décimas de 
segundo (tenths), unidades de segundo (seconds) y decenas de segundo (tens). Los 
contadores son instancias de un contador genérico que puede ser parametrizado para contar 
entre 0 y (N-1). 
Unos bloques de anti-rebote (debounce) se encargan de adaptar la señal de los pulsadores de 
control. Otro bloque (rst_adapt) sincroniza el reset externo que viene del otro pulsador. 
Una máquina de estados (stopwatch_fsm)
recibe las señales de los pulsadores de control y 
permite que se muevan o no los contadores (dejando pasar o no los pulsos generados por 
freq_divider), seleccionando además que se congele o no la cifra visualizada, esto último 
para la funcionalidad “Lap”. 
Finalmente, un bloque de control de los displays (display_ctrl) se encarga de convertir las 
cifras de cada dígito a unas salidas de control del display de tres dígitos 7-segmentos OHO-
DY1. Adicionalmente este bloque tiene un registro a su entrada para permitir, cuando no se 
habilita su carga, “congelar” la visualización mientras el cronómetro corre. Esto último será 
lo que suceda al pulsar el botón “Lap”. 
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 3/16 
 
 
El diagrama de la máquina de estados es tal como se muestra en la siguiente figura: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Las señales de entrada de la FSM mostradas en las transiciones de este diagrama en realidad 
no son exactamente las del nombre mostrado, sino que han de corresponderse con señales 
internas a la máquina, la cuales sean ‘1’ cuando las correspondientes entradas del bloque 
stopwatch_fsm (conectadas a las señales de botón filtradas anti-rebote) pasan de ‘0’ a ‘1’. 
Por ejemplo, el StartStop mostrado en el diagrama será una señal interna que sea ‘1’ cuando 
la entrada StartStop del bloque stopwatch_fsm pase de ‘0’ a ‘1’. 
Por otra parte, la señal de salida de la FSM enableCounting también es interna al bloque, y 
se mezclará mediante un and con la señal EnableCountIn para generar EnableCountOut. 
Además, no se muestra en el diagrama la salida ClearCount, que se encargará de poner a 0 
todos los contadores, y que será ‘1’ siempre que llegue SetToZero, siendo por tanto 
independiente del estado y resultando equivalente a utilizar la señal de detección de cambio 
de ‘0’ a ‘1’ de ese pulsador. 
El estado por defecto de la FSM debe ser “IDLE”. 
IDLE 
RUNNING 
SHOWLAP 
STOPPED 
StartStop 
SetToZero 
Lap 
Lap 
StartStop StartStop 
SetToZero 
SetToZero 
StartStop 
0 1 
1 1 
1 0 
0 0 
<state> 
x y 
x = enableCounting 
y = UpdateDisplay 
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 4/16 
 
 
Guía para la realización del diseño 
 
Se parte de la siguiente estructura de directorios y ficheros, que se entrega a los alumnos en 
un fichero zip y que habrá que situar bajo el directorio de trabajo: 
 
P2_stopwatch / 
rtl/ 
 counter.vhd -> incompleto 
 debounce.vhd -> completo 
 display_ctrl.vhd -> incompleto (*) 
 freq_divider.vhd -> no se entrega a los alumnos 
 rst_adapt.vhd -> completo 
 stopwatch.vhd -> no se entrega a los alumnos 
 stopwatch_fsm.vhd -> incompleto 
 stopwatch_pkg.vhd -> completo 
 
netlist/ 
 display_ctrl.dcp -> completo (*) 
 display_ctrl.edn -> completo, no se usa (*) 
 display_ctrl.vhd -> completo (*) 
 
 sim/ 
 stopwatch_tb.vhd -> no se entrega a los alumnos 
 runsim.do -> completo (script ModelSim) 
 runsim_netlist.do -> completo (script ModelSim) 
 
 vivado/ 
 stopwatch.xdc -> incompleto (constraints) 
 
Esta estructura de directorios deberá mantenerse. 
Para terminar el diseño será necesario completar los ficheros fuente incompletos y crear 
los no entregados. 
(*) En el caso del bloque display_ctrl, este se entrega incompleto, pero también se entrega 
completo en formato de “netlist” (de forma efectiva es como si fuese una caja negra). Puede 
utilizarse en este formato para tener el diseño completo del cronómetro, siendo de entrega 
opcional (con mayor puntuación) el desarrollar este bloque en VHDL (directorio rtl/). 
 
 
1- Crear un nuevo proyecto y el fichero del top-level del RTL 
 
- Crear con Vivado un nuevo proyecto de nombre stopwatch, creando su propia carpeta, 
bajo la carpeta P2_stopwatch/vivado. Como en la Práctica 1, será un RTL Project para 
la FPGA XC7Z010CLG400-1. Durante la creación pueden añadirse ya los ficheros 
presentes en el directorio rtl/, salvo display_ctrl.vhd, que no deberá añadirse al 
proyecto. Por otra parte NO se deberá utilizar la opción Copy sources into Project. 
De esta manera mantendremos nuestro código en rtl/. 
- Bien con el editor de Vivado o con el editor de texto que uno prefiera, crear el fichero 
VHDL del “top-level” del diseño (stopwatch.vhd). Desde Vivado se puede hacer con 
clic derecho en el panel de fuentes y Add Sources > Add or create design sources > 
Create File. Si se crea externamente luego también se puede añadir al proyecto con Add 
Sources. IMPORTANTE: los ficheros de código fuente RTL utilizados por el proyecto 
Vivado deberán situarse siempre en el directorio rtl/. 
- En este fichero stopwatch.vhd, crear la entidad con sus puertos, a partir del esquema del 
circuito de más arriba (donde los puertos externos vienen identificados por un 
pentágono gris). Crear también inicialmente una arquitectura en blanco. 
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 5/16 
 
 
2- Crear un primer sub-bloque desde cero: el divisor de frecuencia 
 
En este apartado haremos un primer ejercicio recordatorio de VHDL: 
o Describiremos un contador, como ejemplo típico de proceso secuencial. 
o Veremos en un mismo código la codificación del reset asíncrono y síncrono. 
o Asignaremos varias señales en un mismo proceso. 
o Al terminar el diseño de este sub-bloque, pasaremos a situarlo en el bloque “top-
level” para recordar cómo se declaraba e instanciaba un componente. 
o Lo que crearemos será un ejemplo de generación de “base de tiempos” para el 
funcionamiento de otros bloques. 
- Bien con el editor de Vivado o con el editor de texto que uno prefiera, procederemos a 
crear el fichero VHDL del divisor de frecuencia (freq_divider.vhd). Desde Vivado se 
puede hacer con clic derecho en el panel de fuentes y Add Sources > Add or create 
design sources > Create File. Si se crea externamente luego también se puede añadir al 
proyecto con Add Sources. IMPORTANTE: los ficheros de código fuente RTL 
deberán situarse siempre en el directorio rtl/. 
- Para editar este fichero y los siguientes: si no se recuerda bien alguna estructura 
sintáctica de VHDL se puede consultar la documentación en Moodle y/o hacer uso de 
Tools > Language Templates, pero conviene memorizar las estructuras básicas del 
lenguaje. 
- Para implementar el divisor de frecuencia crearemos un proceso que haga una cuenta de 
0 a 12.499.999 (este valor deberá definirse como una constant VHDL de tipo integer). 
Para soportar la cuenta usaremos una signal “count” de tipo std_logic_vector que se 
deberá poner a 0: a) cuando llegue el reset asíncrono (activo a nivel alto); b) cuando al 
llegar el flanco de reloj veamos activo (a 1) el reset síncrono del bloque (SyncReset, 
señal que viene de la máquina de estados); y c) cuando al llegar el flanco de reloj la 
cuenta actual sea igual a la constante definida (12.499.999). Si no se cumple ninguna de 
estas condiciones, la cuenta deberá avanzar con la llegada del flanco de reloj. Para 
implementar este proceso partir de la descripción de un flip-flop con reset asíncrono, 
respetando su estructura y rellenando apropiadamente la parte del “if” en la que se ha 
detectado el reset asíncrono y la parte en que se ha detectado la llegada de un flanco 
activo del reloj. 
A la hora de comparar nuestra cuenta con la constante, haremos uso de la función 
conv_integer del package std_logic_unsigned. 
- A continuación, añadiremos en
el mismo proceso la generación de la señal de salida 
EnableOut, la cual estará un ciclo a ‘1’ cada 12.500.000. Es decir, generaremos esta 
señal de forma registrada, como un flip-flop adicional. No se debe olvidar que este flip-
flop adicional también debe resetearse adecuadamente. 
- Finalmente, añadir en el fichero stopwatch.vhd la declaración de este componente y su 
instanciación. En la instanciación conectar el puerto Clk al del “top-level” y crear 
señales internas para los demás puertos (por ejemplo: reset, clearCount, 
enFromFreqDiv u otros nombres con sentido). Declarar estas signals en la parte 
declarativa de la arquitectura. 
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 6/16 
 
 
3- Terminar e instanciar el componente counter: 
 
En este apartado volveremos a practicar creando un contador, pero esta vez: 
o Haremos uso de una señal de “clock enable”. 
o Crearemos varias “asignaciones concurrentes” (formato VHDL abreviado de 
procesos) para señales combinacionales. 
o Utilizaremos una señal combinacional interna generada con una de las 
asignaciones concurrentes para indicar al proceso secuencial contador cuándo ha 
llegado al final de cuenta. 
o Veremos un ejemplo de uso de los generic VHDL. 
o Veremos un ejemplo de uso de los packages VHDL. 
 
- Si no se ha hecho ya, añadir al proyecto los ficheros “counter.vhd” y 
“stopwatch_pkg.vhd” (del directorio “rtl/”). Estudiar el contenido de estos ficheros. Se 
trata de un contador cuyo valor máximo de cuenta es parametrizable y de un package de 
utilidad. Observar el uso en el contador del generic, del package “stopwatch_pkg” y de 
la función “log2_ceil” definida en este package. 
- Completar el fichero “counter.vhd”. Tener en cuenta que el contador interno debe 
resetearse asíncronamente con Reset y síncronamente tanto con el final de cuenta como 
con la entrada SyncReset (señal que viene de la máquina de estados). Además, habrá 
que tener en cuenta que el contador sólo debe avanzar (o bien hacer “wrap-around”, 
esto es, volver a 0 desde su valor máximo) cuando lo permita la señal de “enable” de 
entrada. 
- Añadir la declaración del componente de este contador y sus tres instancias a 
“stopwatch.vhd”. 
En cada instancia utilizar un generic map adecuado, para que cada contador cuente 
hasta donde debe. 
- Conectar los puertos de las tres instancias de counter, añadiendo tanto las señales que 
van entre ellos como las que posteriormente conectaremos a las instancias de otros 
componentes. Declarar estas signals que vamos creando, en la parte declarativa de la 
arquitectura. En el último contador su “enable” de salida queda al aire, por lo que 
usaremos, en vez de una signal, la palabra especial open. 
- Añadir en stopwatch.vhd la misma sentencia para uso del package stopwatch_pkg que 
se puede encontrar en counter.vhd (necesaria para utilizar la función log2_ceil). 
 
4- Comprensión de los ficheros que se entregan completos: 
En este apartado veremos dos ejemplos de mecanismos de sincronización: 
o Cadena de anti-metaestabilidad. 
o Sincronización de reset. 
 
- Añadir al proyecto y examinar los ficheros “rst_adapt.vhd” y “debounce.vhd”. 
Comprender su funcionamiento, preguntando al profesor en caso de dudas. 
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 7/16 
 
- Añadir sus declaraciones e instanciaciones a “stopwatch.vhd”. Para el caso de 
“rst_adapt” puede obviarse el hacer un generic map, utilizando el valor por defecto del 
generic. Tener en cuenta que, como se muestra más arriba en el diagrama del diseño, el 
reset externo entrante es ResetX y la salida de rst_adapt será la que vaya, con el nombre 
que le hayamos dado, a todos los demás bloques. 
 
5- Completar la máquina de estados: 
En este apartado: 
o Describiremos una máquina de estados (FSM), siguiendo el estilo de 
codificación que divide las FSM en un proceso combinacional y otro secuencial. 
o Ejercitaremos la correcta escritura de un proceso combinacional. 
o Veremos un ejemplo de detección de flancos en señales sin usar éstas como 
reloj. 
 
- Si no se ha hecho ya, añadir al proyecto el fichero “stopwatch_fsm.vhd”. Estudiarlo y 
completarlo, considerando la descripción de la máquina de estados dada más arriba. A 
la hora de describir la parte combinacional se puede tener en cuenta que SetToZero 
produce el mismo efecto en todos los estados, para simplificar el código. 
- No olvidar dedicar el tiempo necesario para comprender la parte del código que ya 
viene escrita. 
- Añadir la declaración e instanciación de este componente a “stopwatch.vhd”. 
 
6- Añadir el bloque de control de los displays 7-segmentos, como una netlist 
En este apartado: 
o Añadiremos a nuestro diseño un bloque del cuál no tenemos su código fuente (como 
una IP -Intelectual Property- que solo tuviéramos disponible en formato de netlist). 
Los tres ficheros presentes en el directorio netlist/ representan la misma netlist (lista de 
células + interconexión), en tres formatos diferentes: VHDL (que podremos usar como 
modelo de simulación del bloque), EDIF (formato de netlist estándar en la industria, 
incluido aquí simplemente como referencia) y DCP (formato propietario de lo que en 
Vivado se llama un “design checkpoint”). Echar un vistazo rápido a los dos primeros con un 
editor de texto. El tercero, fichero DCP, es realmente un archivo comprimido con varios 
ficheros en su interior. 
Utilizar Add Sources para añadir al proyecto el fichero display_ctrl.dcp (ojo, no .vhd) del 
directorio netlist/, como si tratara de un fichero RTL más. Comprobar que anteriormente NO 
se ha añadido al proyecto por error el fichero rtl/display_ctrl.vhd. 
Para poder simular esta “caja negra”, añadir también su modelo de simulación, 
netlist/display_ctrl.vhd. pero en este caso utilizar Add Sources > Add or create simulation 
sources. 
Realizar la declaración e instanciación de este componente en stopwatch. Para esto, téngase 
en cuenta que la declaración de la entidad de display_ctrl se puede encontrar tanto en 
netlist/display_ctrl.vhd como en rtl/display_ctrl.vhd. 
 
Laboratorio de Dispositivos Integrados Especializados 
 
 
Escuela Politécnica Superior - UAM - Curso 2021/2022 v1.0 8/16 
 
 
7- Finalizar el RTL del “top-level” stopwatch.vhd 
En este apartado: 
o Practicaremos la instanciación de bloques y su interconexión mediante signals 
internas declaradas por nosotros (ya habremos ido haciéndolo en los apartados 
anteriores). 
o Practicaremos la aplicación tanto de port map para los puertos como de generic 
map para los generics que parametrizan sub-bloques (también habremos ido 
haciéndolo en los apartados anteriores). 
o Adaptaremos nuestro diseño para que su funcionalidad pueda ser simulada (en 
cierta medida) en un tiempo razonable. 
 
- Terminar de “cablear” el fichero “stopwatch.vhd” si quedaba algo pendiente. 
Comprobar que el chequeo sintáctico es correcto. Corregir los posibles errores y 
“warnings”. 
- Con el fin de “acelerar” el circuito durante las simulaciones de depuración de la 
funcionalidad, hacer lo siguiente: 
o Añadir un generic a “stopwatch” llamado “FAST_SIMULATION”, de tipo 
boolean y valor por defecto FALSE. El objetivo es que este generic haga que el 
cronómetro se acelere cuando sea TRUE, para poder realizar más rápidamente 
las simulaciones. A continuación, veremos cómo hacerlo. 
o Usar una asignación concurrente condicional para sustituir el cable a la salida de 
freq_divider por un ‘1’ cuando “FAST_SIMULATION” sea TRUE. El 
multiplexor introducido deberá mantener en su salida todas las conexiones 
anteriormente