¿Cuándo y cómo separar Control y Datapaths para diseños de hardware?

¿Debemos siempre separar el control y la ruta de datos durante la programación del hardware? ¿Hay alguna ventaja? En caso afirmativo, ¿cuál es la metodología básica seguida para esta estrategia? Estoy tratando de conectar una tarjeta SDHC con FPGA y estoy confundido al implementar el protocolo usando rutas de datos y control separadas.

Todo depende de tu aplicación...

Respuestas (1)

Sí, siempre debes dividir estas dos partes en tus diseños.
(Por cierto, no hablaría de esos dos si estamos hablando de módulos simples).

Dividir la ruta de datos y el control tiene estas ventajas:

  • mejor mantenibilidad
    • la ruta de datos es más fácil de entender, porque es un gráfico de flujo / dirigido
    • Los FSM son más fáciles de entender porque no están sobrecargados de datos
  • desarrollo "más rápido"
    • delegar el desarrollo a múltiples desarrolladores
    • Los módulos de ruta de datos pueden reutilizarse en el mismo proyecto o en otros.
      Si ambos están entrelazados, un módulo de ruta de datos no será universal y no permitirá la reutilización de código/módulo
  • mejor capacidad de prueba
    • probar módulos de ruta de datos independientemente del control
    • control de prueba (principalmente uno o más FSM) de forma independiente
    • use arquitecturas ficticias en la ruta de datos mientras prueba el cálculo del módulo de alojamiento

Dividir la ruta de datos y el control también implica dividir partes del control en unidades de subcontrol como sub-FSM, contadores, ...

Siempre es muy exagerado exponer el caso, puede haber razones perfectamente válidas para combinar los dos. Considere algo así como un bloque de IP de Xilinx, en la serie 7, estos tienden a tener AXI IO que pueden incluir datos de usuario que acaban de pasar (con la latencia correcta para que coincida con la latencia del núcleo), esto puede ser una ENORME victoria como usar significa no tener que reconsiderar las latencias de canalización cuando reconfigura el núcleo. Sin embargo, hace que separar el control y los datos sea más difícil, pero a veces en una aplicación basada en gran medida en el flujo de datos, vale la pena hacerlo.
En su ejemplo, la información de control es en realidad datos que se retrasan. El núcleo de IP interpreta dichos datos, simplemente se retrasa.
Mi punto es que, por lo general, desea que las transiciones de control respeten los retrasos de los datos y que escribirlos juntos para que pueda usar las cadenas de retraso integradas en los núcleos de IP (y, por lo tanto, hacer coincidir automáticamente las latencias) puede ser una gran victoria. Me pongo nervioso cuando se usan trabajos como Siempre al describir enfoques de diseño porque generalmente hay excepciones y ser absoluto sobre tales cosas elimina un conjunto de opciones a veces útiles.
¿Esta división también afecta la implementación o síntesis del hardware?
No realmente, es un estilo de codificación y diseño.
¿Cuándo y cómo separar Control y Datapaths para diseños de hardware?
RespuestasAquíPolítica de privacidad1y, 0v