¿Por qué se requiere usar un registro en la salida de la etapa final de una canalización?

Puede usar su propia convención si lo desea, pero en su OP dice que MIT 6.004x dice que su convención es tener una salida de tubería registrada.

Pero hay mejores razones que 'es su convención'.

¿Por qué está agregando un registro de canalización en la lógica aleatoria de las puertas F, G y H? Porque no son lo suficientemente rápidos. ¿No lo suficientemente rápido para qué? No es lo suficientemente rápido para recibir entradas en este ciclo de reloj y tener el resultado listo para usarse en algún lugar del próximo ciclo. Entonces, al agregar el registro de salida, estamos siendo explícitos sobre dónde debe ser correcto el tiempo.

Cuando se diseña una canalización, la parte fácil del tiempo es "¿puede un registro impulsar a otro, en un período de reloj?". La parte difícil es '¿puede una ondulación de salida de registro a través de la lógica combinatoria aleatoria que tengo entre etapas, en un período de reloj?' El uso de un registro de salida significa que todo el tiempo difícil está bajo el control del diseñador de ese módulo (o el estudiante que responde la pregunta), y las interfaces son solo de tiempo fácil.

El uso de un registro puro al principio o al final de un proceso canalizado le brinda la sincronización de E/S más limpia con respecto al reloj. Si necesita conectar su proceso a algo, eso es importante ya que permite un cálculo más fácil de configuraciones y retenciones, y tolerancia a retrasos adicionales y desfases de reloj entre procesos. Si voy al catálogo de módulos, es más probable que pueda utilizar con éxito el diseño con el tiempo de interfaz más limpio.

Si encuentra que ha conectado dos procesos y que hay dos registros entre ellos cuando solo necesita haber uno, es trivial eliminar uno de ellos. Entonces, donde los dos procesos se encuentran, generalmente tiene un registro que puede llamar la salida del proceso anterior o la entrada del siguiente. La convención del MIT es que llamas a ese registro parte del anterior.

Si no usa un registro después de su última etapa, está fusionando efectivamente la última etapa con cualquier lógica siguiente. Su diagrama no mostrará la tubería completa y será inútil para verificar las restricciones de tiempo.

Desde una perspectiva técnica, perfectamente podría conectar su última etapa a un controlador de salida e incluso enrutarlo fuera del chip sin ningún registro. Pero en la vista de diseño (al menos para la sincronización), toda la lógica hasta el siguiente registro debe considerarse como parte de esa etapa.

Lo que te falta con la pregunta es que esta tubería es solo una parte de un diseño más grande. Algo siempre consumirá el resultado de la tubería, con frecuencia otra unidad que puede tratarse como una tubería. Si observa el fragmento que ha dibujado, puede tomar varios de estos fragmentos y apilarlos de un extremo a otro para crear una canalización más larga; esto también sigue el mismo patrón. Si omitió el flop final, pero conectó dos tuberías pequeñas, encontrará el doble de la profundidad lógica en una etapa. De ahí la convención que lo convierte en un elemento fácil de transformar.

Una convención más real podría insistir en 3 flops para una canalización de 2 etapas (agregando un flop de captura de entrada redundante). Esto agregaría un margen de tiempo para el escenario en el que tiene una separación física entre las dos tuberías, pero ahora no es tan trivial subdividir, por lo que esta segunda convención no es tan buena para enseñar. Obviamente, en un escenario del mundo real, esta convención es solo un punto de partida, puede realizar optimizaciones en algunas o todas las interfaces (como ya ha identificado, podría ser posible una vez que la imagen completa esté unida).

Las fallas debido a errores leves pueden actuar como un impedimento severo para las operaciones de circuitos asíncronos. Un registro mejora el funcionamiento básico para latencia variable.

Una canalización envía comandos o datos sin tener que esperar una respuesta. Un registro es un apretón de manos de 2 vías en el registro, por lo que el extremo receptor puede controlar el flujo. Una vez leído por el receptor, el remitente puede actualizar el registro. Lo mismo sucede en la ráfaga de respuestas con el control del lado del cliente.

El servidor es siempre "el oyente" y el cliente el "solicitante" original