¿Cómo ayuda la arquitectura de Harvard?

Estaba leyendo sobre arduino y la arquitectura AVR y me quedé atascado en el punto de cómo se resuelve el estancamiento o el burbujeo de la tubería mediante la introducción de la arquitectura Harvard en el AVR. Quiero decir, lo que hace Harvard es simplemente proporcionar una ubicación de almacenamiento diferente para la memoria de datos y la memoria del programa que hace posible cargar el programa sin un operador. Pero, ¿cómo ayuda a resolver el problema anterior?

Esto es un poco una suposición, por lo que no publicaré como respuesta, pero supongo que la arquitectura de Harvard ayuda porque no existe la posibilidad de automodificar el código mediante una instrucción previa en la tubería.
no estoy seguro si te entiendo... ¿quieres decir que una vez que la instrucción ha sido "recuperada" no se puede modificar o devolver?
Sí, así es, para los que no son de Harvard, debido a que el código puede cambiarse a sí mismo, existe la posibilidad de que la instrucción anterior pueda modificar la instrucción que sigue. Pero espera un poco, probablemente alguien tendrá una respuesta más definitiva y clara.

Respuestas (4)

La arquitectura de Harvard, que por cierto se usó mucho antes de que se inventaran los AVR, tiene espacios de direcciones separados para la memoria del programa y para la memoria de datos. Lo que esto aporta a la fiesta es la capacidad de diseñar el circuito de tal manera que se pueda usar un bus y un circuito de control separados para manejar el flujo de información desde la memoria del programa y el flujo de información hacia la memoria de datos. El uso de los buses separados significa que es posible que la obtención y ejecución del programa continúe sin interrupción por una transferencia de datos ocasional a la memoria de datos. Por ejemplo, en la versión más simple de la arquitectura, la unidad de obtención de programas puede estar ocupada obteniendo la siguiente instrucción en la secuencia del programa en paralelo con la operación de transferencia de datos que puede haber sido parte de la instrucción del programa anterior.

En este nivel más simple, la arquitectura de Harvard tiene la limitación de que generalmente no es posible colocar el código del programa en la memoria de datos y ejecutarlo desde allí.

Hay muchas variaciones y complejidades que se pueden agregar a esta forma más simple de la arquitectura que he descrito. Una adición común es agregar el almacenamiento en caché de instrucciones al bus de información del programa que permite a la unidad de ejecución de instrucciones un acceso más rápido al siguiente paso del programa sin tener que ir a una memoria más lenta para buscar el paso del programa cada vez que se requiere.

muchas gracias... realmente me ayudó a conseguirlo, pero solo una cosa más... ¿no podemos tener diferentes buses pero la misma memoria y trabajo al mismo tiempo?
@Ayush: si tuviera dos buses que iban al mismo espacio de memoria, entonces dos solicitudes de transacciones de memoria que llegaron a la memoria al mismo tiempo aún tendrían que competir por el acceso a la memoria. ¡Uno tiene que esperar a que el otro se complete! Dicho esto, algunos diseñadores han "resuelto" ese problema al diseñar la memoria para operar al doble de la velocidad normal y luego permitir que un bus tenga acceso a la memoria alternando con accesos desde el otro bus. Es decir, las cosas están diseñadas de tal manera que el primer bus siempre está sincronizado con las ranuras de acceso impares a la memoria y (cont. siguiente comentario)
(continuación del comentario anterior) segundo bus sincronizado con las ranuras de acceso pares de la memoria, entonces ambos buses pueden proceder a operar a velocidad sin contención de acceso a la memoria.
@MichaelKaras: Uno podría hacer eso. Por otro lado, en la mayoría de los casos, el principal factor limitante de la velocidad general del sistema es la velocidad de la memoria. Si uno tuviera una memoria que pudiera funcionar el doble de rápido de lo que se necesitaría solo para datos o solo para código, dividir el sistema de memoria en uno para datos y otro para código permitiría que las cosas fueran el doble de rápido.

Algunas notas además de la respuesta de Michaels:

1) la arquitectura de Harvard no requiere que haya dos espacios separados para datos y código, solo que (en su mayoría) se recuperan en dos buses diferentes .

2) el problema que resuelve la arquitectura Harvard es la contención del bus: para un sistema en el que la memoria de código puede proporcionar las instrucciones lo suficientemente rápido como para mantener la CPU funcionando a toda velocidad, la carga adicional de búsqueda/almacenamiento de datos ralentizará la CPU abajo. Ese problema se resuelve con una arquitectura Hardvard: una memoria que es (un poco) demasiado lenta para la velocidad de la CPU.

Tenga en cuenta que el almacenamiento en caché es otra forma de resolver este problema. A menudo, Harvarding y el almacenamiento en caché se utilizan en combinaciones interesantes.

Harvard utiliza dos autobuses. No hay una razón inherente para ceñirse a dos, en casos muy especiales se utilizan más de dos, principalmente en DSP (procesadores de señal digital).

La banca de memoria (en el sentido de distribuir los accesos a la memoria a diferentes conjuntos de chips) puede verse como una especie de Harvarding dentro del propio sistema de memoria, no basada en la distinción de datos/código, sino en ciertos bits de la dirección.

En realidad, una arquitectura Harvard "pura" requiere memorias separadas (espacios de direcciones) para instrucciones y datos. Sin embargo, dado que esto evita que una computadora se inicie sola, muchas máquinas implementan una arquitectura Harvard "modificada", en la que se permiten escrituras en la memoria de instrucciones.
Los bancos de memoria no ayudan a menos que haya dos (o más) buses entre la CPU y cada uno de los bancos de memoria.
@Dave 2: la banca ayuda en ciertas circunstancias, por ejemplo, si el problema es el tiempo de la memoria Y el bus a la memoria no bloquea (pueden estar pendientes múltiples transacciones).
@ Dave1: ¿puede dar una referencia?
Wikipedia , también la Universidad de Princeton (que en realidad es solo una copia de la página de Wikipedia). Además, la mayoría de los microcontroladores de un solo chip tienen arquitectura Harvard, y muchas hojas de datos en realidad analizan cómo proporcionar un mecanismo para autoescribir el código de la memoria flash crea una arquitectura Harvard modificada.
La banca de memoria con múltiples transacciones pendientes puede mejorar el ancho de banda para una memoria de alta latencia, pero no oculta el hecho de que los accesos a instrucciones y datos deben competir por el mismo bus. Llamarlo "una especie de Harvard" solo enturbia las aguas, en lugar de aclarar las cosas. La arquitectura de Harvard explota un cierto tipo de paralelismo, pero no se puede empezar a llamar a todas las formas de paralelismo "Harvarding".
@DaveTweed: si una máquina usara un reloj de cuatro fases donde la fase 1 emitiera una dirección de instrucción que estaría bloqueada por un circuito externo, la fase 2 bloquearía una dirección de datos, la fase 3 leyó una instrucción y la fase 4 leyó o escribió un byte en el dirección indicada, no consideraría el hecho de compartir los mismos pines de bus como un impedimento para que el sistema se llame "Arquitectura de Harvard" si el bus multiplexado se expandiera a distintos buses de dirección/datos, y hubiera una subdivisión rígida de que la fase 1 siempre es dirección de código, la fase 2 es siempre dirección de datos, etc.
@supercat: Realmente no estoy seguro de cuál es el punto que estás diciendo. La arquitectura Harvard vs. von Neumann no se trata de la sincronización del bus, se trata de tener espacios de memoria separados para I y D. Incluso el humilde 8051 comparte los mismos pines para ambos tipos de acceso, pero tiene un pin adicional que indica qué espacio de memoria es siendo accedido en cualquier ciclo dado.
@DaveTweed: El término "Arquitectura de Harvard" tiene aspectos de hardware y software; para el aspecto del hardware, diría que una característica definitoria sería que las búsquedas de datos se pueden realizar sin retrasar las búsquedas de código. En el 8x31, la instrucción MOVX hará que el bus que normalmente se usaría para la obtención de códigos se bloquee procesando la obtención de datos, por lo que con respecto a MOVX, no consideraría que el 8x51 sea una arquitectura Harvard. Sin embargo, el espacio de datos principal del 8x51 es una RAM interna a la que se puede acceder independientemente del bus de código.

Una arquitectura Harvard pura generalmente permitirá que una computadora con un nivel dado de complejidad funcione más rápido que una arquitectura Von Neuman, siempre que no sea necesario compartir recursos entre el código y las memorias de datos. Si las limitaciones de asignación de pines u otros factores obligan al uso de un bus para acceder a ambos espacios de memoria, es probable que tales ventajas se anulen en gran medida.

Una arquitectura Harvard "pura" se limitará a ejecutar el código que se coloca en la memoria mediante algún mecanismo que no sea el procesador que ejecutará el código. Esto limita la utilidad de tales arquitecturas para dispositivos cuyo propósito no está establecido de fábrica (o alguien con equipo de programación especializado). Se pueden utilizar dos enfoques para aliviar este problema:

Algunos sistemas tienen áreas separadas de código y memoria, pero proporcionan hardware especial al que se le puede pedir que se haga cargo brevemente del bus de código, realice alguna operación y devuelva el control a la CPU una vez que se complete dicha operación. Algunos de estos sistemas requieren un protocolo bastante elaborado para llevar a cabo tales operaciones, algunos tienen instrucciones especiales para realizar dicha tarea, y algunos incluso buscan ciertas direcciones de "memoria de datos" y activan la adquisición/liberación cuando se intenta acceder a ellas. . Un aspecto clave de tales sistemas es que hay áreas de memoria explícitamente definidas para "código" y "datos"; incluso si es posible que la CPU lea y escriba espacio de "código", todavía se reconoce como semánticamente diferente del espacio de datos.'

Un enfoque alternativo que se utiliza en algunos sistemas de gama alta es tener un controlador con dos buses de memoria, uno para código y otro para datos, los cuales se conectan a una unidad de arbitraje de memoria. Esa unidad, a su vez, se conectaba a varios subsistemas de memoria utilizando un bus de memoria separado para cada uno. Un acceso de código a un subsistema de memoria puede procesarse simultáneamente con un acceso de datos a otro; solo si el código y los datos intentan acceder al mismo subsistema simultáneamente, cualquiera de los dos tendrá que esperar.

En los sistemas que utilizan este enfoque, las partes de un programa que no son críticas para el rendimiento pueden simplemente ignorar los límites entre los subsistemas de memoria. Si el código y los datos residen en el mismo subsistema de memoria, las cosas no funcionarán tan rápido como si estuvieran en subsistemas separados, pero para muchas partes de un programa típico eso no importará. En un sistema típico, habrá una pequeña parte del código donde el rendimiento realmente importa, y solo operará en una pequeña porción de los datos que posee el sistema. Si uno tuviera un sistema con 16K de RAM que estuviera dividido en dos particiones de 8K, podría usar las instrucciones del enlazador para asegurarse de que el código crítico para el rendimiento estuviera ubicado cerca del inicio del espacio de memoria general y que los datos críticos para el rendimiento estuvieran cerca del final. fin. Si el tamaño total del código crece hasta, por ejemplo, 9K, el código dentro de los últimos 1K se ejecutaría más lentamente que el código colocado en otro lugar, pero ese código no sería crítico para el rendimiento. Del mismo modo, si el código tuviera, por ejemplo, solo 6K, pero los datos aumentaran a 9K, el acceso al 1K de datos más bajo sería lento, pero si los datos críticos para el rendimiento estuvieran ubicados en otro lugar, eso no representaría un problema.

Tenga en cuenta que si bien el rendimiento sería óptimo si el código estuviera por debajo de 8K y los datos estuvieran por debajo de 8K, el diseño del sistema de memoria antes mencionado no impondría una partición estricta entre el código y el espacio de datos. Si un programa solo necesita 1K de datos, el código podría crecer hasta 15K. Si solo necesita 2K de código, los datos podrían crecer hasta 14K. Mucho más versátil que tener un área de 8K solo para código y un área de 8K solo para datos.

Un aspecto que no se ha discutido es que para microcontroladores pequeños, normalmente con solo un bus de direcciones de 16 bits, una arquitectura Harvard duplica (o triplica) efectivamente el espacio de direcciones. Puede tener 64 K de código, 64 K de RAM y 64 K de E/S asignadas a la memoria (si el sistema usa E/S asignadas a la memoria en lugar de números de puerto, este último ya separa el direccionamiento de E/S del código y espacios RAM).

De lo contrario, debe incluir el código, la RAM y, opcionalmente, la dirección de E/S, todo dentro del mismo espacio de direcciones de 64K.

¿Cómo ayuda la arquitectura de Harvard?
RespuestasAquíPolítica de privacidad1y, 0v