Combinación de componentes y temporización en VHDL (y probablemente verilog) / FPGA

Parece que entiendes esto correctamente. Para responder a sus preguntas individualmente:

1. Este podría ser un problema real, pero los registros FPGA y la infraestructura del reloj funcionan de una manera que significa que no tiene que preocuparse por este problema en un sistema completamente sincrónico como el uno que has descrito.

2. Existen algunos factores que le permiten registrar datos de manera confiable en el mismo borde del reloj que está modificando dichos datos:

   • Los tiempos de espera para los registros internos son muy pequeños, muy por debajo de 1 nanosegundo en, por ejemplo, un FPGA Xilinx Spartan 6, y menos de 0.2 nanosegundos para la memoria de bloque en dicho FPGA.
   • La red de reloj normalmente utiliza un diseño de sesgo muy bajo, de modo que el borde del reloj en una parte del FPGA pasa muy cerca en el tiempo al borde de otras partes. Compare esto con la ruta de datos, donde su señal de datos cambiante tiene que propagarse a lo largo del cable de un registro a otro.
   • Cada elemento cronometrado tiene un retraso de propagación desde su entrada D a su salida Q .

   Combinando estos factores, cuando se produce un flanco de reloj, los datos vistos por el segundo registro (en su caso, un elemento de memoria) no cambiarán hasta que el retardo de propagación del registro más el retardo del cable. Mientras este total sea más que el tiempo de espera para el registro de recepción, el diseño funcionará de manera confiable. El sesgo del reloj juega un papel aquí, pero como antes, debería (pero ver el punto 3) ser pequeño en comparación con los otros dos factores.

3. Su cadena de herramientas de diseño FPGA realizará un análisis de tiempo muy detallado de todo el diseño, siempre que le haya dado la información correcta en forma de restricciones. Este análisis incluirá cualquier sesgo interno de reloj, retrasos, verificaciones de temperatura y proceso, etc. Siempre es importante crear restricciones para los períodos de reloj y cualquier tiempo de E / S. Con estos en su lugar, la cadena de herramientas le dirá si hubo algún problema de tiempo en su diseño. A pesar de que el escenario particular que usted describe nunca tendría un problema de tiempo, creo que este es un punto importante.

Tiene razón al identificarlo como un problema potencial, y también es correcto al suponer que es tan prominente que las herramientas lo tratan bien.

De hecho, se garantiza que la salida de ALU asumirá el valor calculado en algún momento después de el borde del reloj, por lo que no hay incertidumbre; se almacenará en la memoria en el borde del reloj next . Por lo tanto, debe configurar la señal WRITE ENABLE de la memoria en el mismo ciclo en que la ALU envía los datos.

El problema potencial se manifiesta de dos maneras: cualquiera

• la señal del reloj puede llegar a la ALU y a la memoria en diferentes momentos (o diferentes bits de la ALU en diferentes momentos), llamada "sesgo de reloj"
• las salidas de ALU tardan tanto en llegar a la memoria que tampoco están listas para el próximo borde del reloj.

Normalmente, le dice a las herramientas su velocidad de reloj deseada (e información similar, llamada colectivamente "restricciones de tiempo") y traducen el diseño de manera adecuada, por ejemplo, ubicando la ALU y la memoria cerca unas de otras para reducir los retrasos de enrutamiento, y el paso denominado "análisis de tiempo estático" informa si se han cumplido todas las restricciones de tiempo.

Por lo general, en la práctica, las herramientas resuelven este problema por usted.

Puede experimentar con restricciones de tiempo; por ejemplo, pida a las herramientas que alcancen velocidades de 200,300,400 MHz y en algún momento fallarán: luego enumerarán las rutas más lentas, y puede decidir la mejor manera de hacer que el diseño sea más rápido (si necesitas).

Por ejemplo, si tenía una unidad de cambio / rotación directamente conectada entre la ALU y la memoria, y esto era demasiado lento, también podría convertir esa unidad en un proceso cronometrado, por lo tanto acelerando el diseño agregando otra etapa de canalización.

En el diseño de la CPU, esto causa problemas porque las sucursales se vuelven más lentas gracias a la necesidad de limpiar tuberías largas (el Pentium-4 fue muy criticado por esto), pero en el diseño de FPGA tiende hacia un estilo de diseño que evita las sucursales por completo, o al menos , en la medida de lo posible.