¿Por qué la CPU necesita ser multiplicada por el bus frontal?

El bus suele ser más lento que el procesador porque se ocupa del mundo sin chip donde la ingeniería es más fácil (posible en lugar de imposible en muchos casos).

Como dice Alex, el diseño es mucho más simple con una relación simple entre el reloj del procesador y el bus. Si se aleja de esto, debe construir una interfaz más compleja (asíncrona) que puede ser difícil de diseñar, verificar y probar. También agrega latencia a la interfaz, por lo que se requieren más ciclos para que una solicitud o respuesta cruce la interfaz del procesador al bus, o viceversa. No necesariamente reduce la velocidad de datos alcanzable en la interfaz, pero en la práctica a menudo lo hará.

En los últimos años, el uso del diseño Globally Asynchronous, Locally Synchronous (GALS) en chips grandes se ha vuelto común a medida que los diseñadores han adoptado la escala de frecuencia / voltaje para reducir la potencia. [Para un número dado de operaciones, es más eficiente energéticamente realizarlas lentamente que hacerlo rápidamente y dormir; la razón es que si baja la frecuencia, puede reducir el voltaje y, dado que la potencia es proporcional al voltaje al cuadrado usa menos energía al tomar más tiempo]. En la práctica, el procesador es solo una parte de un sistema grande, la mayoría de los cuales no tienen su frecuencia reducida cuando la frecuencia del procesador se reduce, por lo que tiene que haber un mecanismo para permitir que cambien las relaciones de frecuencia. Esto se puede hacer entre (p. Ej.) 3: 1 y 2: 1, pero cuando estamos interesados ​​en cambiar la frecuencia del procesador en (p. Ej.) 20%, no hay una forma sencilla de pasar de 3: 1 a 2.4: 1, de modo que se utilizan interfaces asíncronas .

Porque sincronizar dos buses es mucho más fácil si uno es un multiplicador entero del otro. Si la CPU realiza un cambio en el FSB y sabe que los datos estarán listos exactamente 5.0 ciclos más tarde, es relativamente fácil de manejar. Si los relojes no están sincronizados entre sí, debe colocar un circuito Clock Crossing Crossing, que tiende a ralentizar los datos y usar la energía.

Como analogía, considere sus comidas. Puede comer en el árbol al día: mañana, mediodía y noche. Su bus de comida tiene una frecuencia tres veces mayor que su bus de sueño. Pero supongamos que su bus de comida estaba conectado a 2.7. veces tu bus para dormir. Algunos días solo recibirías dos comidas. O la primera comida llega antes de que termine de lavarse en la mañana, o la última mientras se prepara para la cama. Y si fuera 3,1 veces tu autobús para dormir, ocasionalmente obtendrías cuatro comidas en un día.

Respuesta corta: es más barato y más fácil no proporcionar la capacidad porque hace que la sincronización de comunicaciones entre partes sea mucho más simple.

“¿Por qué no puedes?” Es la pregunta equivocada. Usted puede. Simplemente aumentaría la complejidad en gran medida por poco o ningún beneficio en el rendimiento.

La razón, según tengo entendido, se debe a que la interfaz entre la CPU y el FSB depende en gran medida del tiempo. Para divorciarse de la sincronización de la CPU y el FSB, se requeriría un búfer dependiente de la sincronización diferente entre ellos y eso tendría que escalarse al mismo nivel que la CPU. El tamaño de ese búfer tendría que escalarse para acomodar la frecuencia de reloj teórica máxima de la CPU para evitar el estancamiento. Es un problema difícil y personalmente creo que se ha cumplido un compromiso razonable.