Discrepancia entre el análisis de tiempo estático posterior al lugar y la ruta y los resultados de simulación ISIM

Question

Discrepancia entre el análisis de tiempo estático posterior al lugar y la ruta y los resultados de simulación ISIM

#1 de W5VO (3 votos)

5

Descripción general

Estoy implementando una CPU simple estilo Harvard usando Xilinx ISE versión 14.1. Estoy usando configuraciones compatibles con una placa Digilent Nexys3, pero por el momento todo el proyecto se realiza solo en simulación.

Tengo la siguiente entrada en mi archivo UCF que especifica la ubicación (pin) del reloj en la placa Nexys3, junto con una restricción de período de 100MHz. 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 sincronizando toda la lógica síncrona usando el borde positivo de este reloj.

El análisis de temporización estática de lugar y ruta posterior 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 está dentro del objetivo de 10 ns. No hay rutas sin restricciones en el informe.

El informe menciona este camino primero. Dado que la sincronización coincide, asumo que es la ruta más lenta en el diseño (la ruta con la menor holgura). Es la ruta desde el registro de instrucciones hasta el bit más alto del puntero de pila. La ruta (a través de la ALU y el bus 3) parece sensata para mi diseño cuando el registro se carga con un valor inmediato. La ruta push / pop toma una ruta 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, ejecuto una simulación posterior al lugar y la ruta con un período de 10 ns de tiempo pensando que todo estará bien. Sin embargo, no lo es. Las señales no se ajustan a tiempo para el próximo borde del reloj y todo es un desastre. Relajar el reloj a 50 ns (20Mhz) permite mucho tiempo para que todo se resuelva.

En425nsobtenemoselpulsoderelojqueseñalaeliniciodelcicloenelqueejecutaremoslainstrucciónSP<-0xFFFFFFFF.IR_15_2eslaseñaldelinformedetemporización.SP_valueesunregistro,porloquesoloasumeelvalorqueselepresentaenelsiguienteflancoascendente.SPsecargadesdebus3,asíquelousamoscomoproxy.

Enelgráficovemosquesenecesitan3nsomenosparaqueseconfirmeIR_15_2.Luegotomamásde10nsparaquelaseñalseatomadaporelbus1.En451ns,26nnmástarde,laseñalestádisponibleenbus3ypodemosempezarapensarencargarSPconél.

Pregunta

Lasincronizaciónestáticamedicequelarutamáslargaderegistroaregistroeneldiseñodeberíatomaraproximadamente4ns,mientrasquelasimulaciónmuestraquelasseñalestardanalrededorde26nsenestablecerse.¿Queestapasandoaqui?¿Elanálisisdetiempoestáticonoencuentratodaslasrutasrelevantes?¿Usé/configurémalelsimulador?¿Heleídomalelanálisisdetiempoestático?

Estoybienejecutandoeldiseñoa20Mhz,estonoesunacompetenciadevelocidad.Solotengolasensacióndequemeestoyperdiendoalgoimportante.

Informaciónadicional

Elproyectocompleto(archivosVHDL,proyectoXISE)está disponible en bitbucket .

fpga simulation timing spartan constraints

pregunta drxzcl

1 respuesta

Lea otras preguntas en las etiquetas fpga simulation timing spartan constraints

Frecuencias comunes de señales analógicas Cambio de una bomba trifásica usando un relé de estado sólido

score 3 · Accepted Answer

Mirando a través de su informe de tiempo, no hay nada que indique un problema potencial. Dado que tiene un problema, esto significa que los escenarios que el análisis de tiempo estático (STA) está verificando no cubren el uso real de su circuito.

Sin una configuración seria de STA, algunas suposiciones comunes son que todas las entradas son válidas en el momento en que se levanta el reloj y que todos los estados son conocidos (es decir, una lógica 1 o 0 ). Inmediatamente, el UUUUUUUU en bus3 parece muy sospechoso, y es un posible problema con la inicialización. En las simulaciones lógicas, U implica que la línea es un 1 o 0 , pero un registro que lo condujo no se inicializó correctamente. Esto podría hacer que el simulador dé respuestas raras hasta que todos los registros estén cargados o restablecidos. Sin embargo, este problema se manifiesta en ciclos posteriores después de que todos los registros se hayan inicializado.

El otro problema potencial es que bus1 comienza en un estado de alta impedancia ( ZZZZZZZZ ). Teniendo en cuenta que el tri-estado no se suele asumir en el análisis de tiempo, esta es la fuente más probable de la discrepancia de tiempo. Las condiciones de los tres estados deben estar cuidadosamente codificadas en su herramienta STA para que sean consideradas. Esta puede ser una tarea muy difícil y es propensa a errores (programación incorrecta, casos perdidos, etc.). Creo que la programación en retrasos de tres estados lo más probable es que le brinde un resultado de STA preciso que debería coincidir con su simulación.

Sin embargo, tri-state suele ser una mala elección para la comunicación en chip tanto para ASIC como para FPGA. Esta ambigüedad de la confiabilidad de la STA, el potencial de contención del bus y la incertidumbre de los requisitos de la potencia del variador hacen que los tres estados tengan más probabilidades de causar problemas que de solucionarlos. El método más seguro es usar un multiplexor para seleccionar qué fuente "habla" con el bus, o dividir el diseño de manera diferente. Solo usaría tri-state cuando sé que resolverá más problemas de los que puede causar.

Discrepancia entre el análisis de tiempo estático posterior al lugar y la ruta y los resultados de simulación ISIM

Publicaciones recientes del blog

Descripción general

Pregunta

Informaciónadicional

1 respuesta