Descripción
Estoy implementando un simple Harvard-estilo de uso de CPU de Xilinx ISE versión 14.1. Estoy usando la configuración compatible con un Digilent Nexys3 de la junta, pero por el momento todo el proyecto se realiza en la simulación sólo.
Tengo la siguiente entrada en mi UCF archivo que especifica la ubicación (pin) del reloj en el Nexys3 de la junta, junto con un 100MHz período de restricción. Esto significa un período de 10ns.
Net "clk" LOC=V10 | IOSTANDARD=LVCMOS33;
Net "clk" TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 100000 kHz;
Estoy registrando todos los sincrónico de la lógica con el flanco positivo del reloj.
Post Lugar-y-Ruta estática en el análisis del tiempo sugiere que todo está bien:
Timing constraint: TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_pin" 100 MHz HIGH
50%;
For more information, see Period Analysis in the Timing Closure User Guide (UG612).
12987 paths analyzed, 961 endpoints analyzed, 0 failing endpoints
0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors)
Minimum period is 4.003ns.
El período mínimo es así dentro de la 10ns de destino. No hay restricciones de rutas en el informe.
A continuación, el informe menciona que esta primero la ruta de acceso. Dado que el calendario de partidos, supongo que es el más lento camino en el diseño (la ruta con la menor holgura). Es la ruta de acceso desde el Registro de Instrucción a los más altos bits del puntero de pila. La ruta de acceso (a través de la ALU y el autobús 3) se ve sano para mi el diseño cuando el registro se carga con un valor inmediato. El push/pop ruta toma un camino diferente.
Slack (setup path): 5.997ns (requirement - (data path - clock path skew + uncertainty))
Source: CONTROL/IR_15_2 (FF)
Destination: SP/VALUE_31 (FF)
Requirement: 10.000ns
Data Path Delay: 3.951ns (Levels of Logic = 9)
Clock Path Skew: -0.017ns (0.252 - 0.269)
Source Clock: clk_BUFGP rising at 0.000ns
Destination Clock: clk_BUFGP rising at 10.000ns
Clock Uncertainty: 0.035ns
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Maximum Data Path at Slow Process Corner: CONTROL/IR_15_2 to SP/VALUE_31
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X13Y30.BQ Tcko 0.391 CONTROL/IR_15_3
CONTROL/IR_15_2
SLICE_X5Y31.D3 net (fanout=12) 0.847 CONTROL/IR_15_2
SLICE_X5Y31.D Tilo 0.259 RAM/read_address<1>
ALU1/Mmux_RR11241
SLICE_X14Y24.B3 net (fanout=4) 1.283 bus3_1_OBUF
SLICE_X14Y24.COUT Topcyb 0.380 SP/VALUE<3>
SP/Mcount_VALUE_lut<1>
SP/Mcount_VALUE_cy<3>
SLICE_X14Y25.CIN net (fanout=1) 0.003 SP/Mcount_VALUE_cy<3>
SLICE_X14Y25.COUT Tbyp 0.076 SP/VALUE<7>
SP/Mcount_VALUE_cy<7>
SLICE_X14Y26.CIN net (fanout=1) 0.003 SP/Mcount_VALUE_cy<7>
SLICE_X14Y26.COUT Tbyp 0.076 SP/VALUE<11>
SP/Mcount_VALUE_cy<11>
SLICE_X14Y27.CIN net (fanout=1) 0.003 SP/Mcount_VALUE_cy<11>
SLICE_X14Y27.COUT Tbyp 0.076 SP/VALUE<15>
SP/Mcount_VALUE_cy<15>
SLICE_X14Y28.CIN net (fanout=1) 0.003 SP/Mcount_VALUE_cy<15>
SLICE_X14Y28.COUT Tbyp 0.076 SP/VALUE<19>
SP/Mcount_VALUE_cy<19>
SLICE_X14Y29.CIN net (fanout=1) 0.003 SP/Mcount_VALUE_cy<19>
SLICE_X14Y29.COUT Tbyp 0.076 SP/VALUE<23>
SP/Mcount_VALUE_cy<23>
SLICE_X14Y30.CIN net (fanout=1) 0.003 SP/Mcount_VALUE_cy<23>
SLICE_X14Y30.COUT Tbyp 0.076 SP/VALUE<27>
SP/Mcount_VALUE_cy<27>
SLICE_X14Y31.CIN net (fanout=1) 0.003 SP/Mcount_VALUE_cy<27>
SLICE_X14Y31.CLK Tcinck 0.314 SP/VALUE<31>
SP/Mcount_VALUE_xor<31>
SP/VALUE_31
------------------------------------------------- ---------------------------
Total 3.951ns (1.800ns logic, 2.151ns route)
(45.6% logic, 54.4% route)
Armado con este conocimiento puedo ejecutar un post-Lugar-y-la simulación de la Ruta con un 10ns reloj período pensando que todo va a estar bien. Sin embargo, no lo es. Las señales no resolver en tiempo para el siguiente flanco de reloj y es todo un desastre. Relajante el reloj de 50ns (20Mhz) permite un montón de tiempo para que todo se asiente.
En 425ns tenemos el reloj de pulso que indica el inicio del ciclo en el que vamos a ejecutar la instrucción SP <- 0xFFFFFFFF. IR_15_2 es la señal de que el informe de tiempo. SP_value es un registro, de modo que sólo se asume que el valor presentado en el siguiente flanco de subida. SP está cargado de bus3 así que usar eso como un proxy.
En el gráfico vemos que tarda 3ns o así, por IR_15_2 a afirmar en absoluto. A continuación, se tarda más de 10ns más de la señal a ser tomado por bus1. En 451ns, un completo 26ns más tarde, la señal está disponible en bus3 y podemos empezar a pensar acerca de la carga de SP con ella.
Pregunta
La sincronización estática me dicen que el camino más largo registro-registro de ruta de acceso en el diseño debe tomar alrededor de 4ns, mientras que la simulación muestra que las señales tomar sobre 26ns a resolver. ¿Qué está pasando aquí? Es la sincronización estática análisis no encontrar todos los caminos? ¿Puedo usar/configurar el simulador mal? ¿Entendí mal lo estático, el análisis del tiempo?
Yo estoy bien ejecutando el diseño a 20Mhz, esto no es una competencia de velocidad. Sólo tengo la sensación de que me estoy perdiendo algo importante.
Información Adicional
El proyecto completo (archivos VHDL, XISE proyecto) está disponible en bitbucket.
