más información:
microcontrolador diferente reloj 50 MHz creo ..
La frecuencia de reloj SPI es de 16Mhz
Reloj central SPI VHDL @ 100 Mhz
He hecho una prueba de resistencia escribiendo y leyendo algunos registros... sin errores con spi
el problema :
algunos síntomas:
a veces en algunos registros hay bits que no escribí por spi, haciendo que la aplicación vhdl actúe de manera inesperada.
Al agregar sondas de derivación de señal, el comportamiento del vhdl cambia un poco.
preguntas:
¿Necesito usar timequest para SPI CORE para agregar restricciones de tiempo a los pines de entrada SPI? ¿Tengo metaestabilidad?
Su suposición de que tiene un problema de metaestabilidad parece correcta. Solo hice una encuesta del código esclavo spi, y esto es lo que encontré:
Si lee los datos continuamente, tendrá metaestabilidad ya que no está sincronizado. El diseñador del núcleo probablemente espera que use datos válidos para evitar eso. Personalmente, creo que es un mal diseño y usaría FIFO poco profundo para hacer el trabajo limpiamente.
Además, preferiría hacer lo que sugiere Brian y simplemente sincronizar el spi clk/data con un reloj más rápido (esos 100 MHz) y hacer la lógica central con ese reloj. 16 MHz a 100 MHz sesgarán el borde del reloj para su lógica de salida (después de la resincronización), pero debería estar bien.
En cuanto a las restricciones, 16 MHz es muy, muy lento... No necesita restricciones, aunque su CPOL/CPHA tiene que coincidir, obviamente.
Metaestabilidad? Altamente improbable.
¿Entradas no sincronizadas? Muy probable y pueden causar los síntomas que describes.
Así que cronometre cada entrada SPI desde su reloj rápido y enrute las versiones cronometradas al núcleo SPI. (A menos que ya esté seguro de que ya los vuelve a sincronizar).
Cristian Mardones