하버드 아키텍처는 어떻게 도움이됩니까?

Arduino와 AVR 아키텍처에 대해 읽고 있었고 AVR의 Harvard 아키텍처 도입으로 파이프 라인 스톨 또는 버블 링이 어떻게 해결되는지에 멈췄습니다. 연산자없이 프로그램을로드 할 수 있지만 위의 문제를 해결하는 데 어떻게 도움이됩니까?

AVR이 발명되기 오래 전에 사용 된 하버드 아키텍처에는 실제로 프로그램 메모리와 데이터 메모리를위한 별도의 주소 공간이 있습니다. 이것이 파티에 가져 오는 것은 별도의 버스와 제어 회로를 사용하여 프로그램 메모리에서 정보 흐름과 데이터 메모리로 정보 흐름을 처리하는 데 사용할 수있는 방식으로 회로를 설계 할 수 있다는 것입니다. 별도의 버스를 사용하면 가끔씩 데이터가 데이터 메모리로 전송되는 것을 방해하지 않고 프로그램 페치 및 실행을 계속할 수 있습니다. 예를 들어, 아키텍처의 가장 간단한 버전에서, 프로그램 페치 유닛은 이전 프로그램 명령의 일부일 수있는 데이터 전송 동작과 병행하여 프로그램 시퀀스에서 다음 명령을 페치하는 중일 수있다.

이 가장 단순한 수준에서 하버드 아키텍처는 일반적으로 프로그램 코드를 데이터 메모리에 넣고 실행할 수 없다는 한계가 있습니다.

내가 설명한 가장 간단한 형태의 아키텍처 위에 추가 할 수있는 많은 변형과 복잡성이 있습니다. 하나의 일반적인 추가 사항은 명령 캐싱을 프로그램 정보 버스에 추가하여 명령 실행 장치가 필요할 때마다 프로그램 단계를 페치하기 위해 느린 메모리로 이동하지 않고도 다음 프로그램 단계에 더 빠르게 액세스 할 수 있도록하는 것입니다.

마이클스 외에 몇 가지 메모가 있습니다.

1) 하버드 아키텍처는 데이터와 코드를위한 두 개의 별도 공간 이 필요하지 않으며 단지 두 개의 서로 다른 버스를 통해 가져옵니다 .

2) 하버드 아키텍처로 해결되는 문제는 버스 경합입니다. 코드 메모리가 CPU를 최고 속도로 실행하기에 충분한 명령을 빠르게 제공 할 수있는 시스템의 경우 데이터 페치 / 저장의 추가 부담으로 인해 CPU 속도가 느려집니다. 내려가는. 이 문제는 Hardvard 아키텍처, 즉 CPU 속도에 비해 너무 느린 메모리 (비트)로 해결됩니다.

캐싱은이 문제를 해결하는 또 다른 방법입니다. 하버드와 캐싱은 종종 흥미로운 조합으로 사용됩니다.

하버드는 두 개의 버스를 사용합니다. 매우 특별한 경우에는 주로 DSP (Digital Signal processor)에서 두 개 이상이 사용됩니다.

메모리 뱅킹 (다른 칩 세트에 메모리 액세스를 분배한다는 의미에서)은 데이터 / 코드 구별이 아니라 주소의 특정 비트를 기준으로 메모리 시스템 내부의 일종의 하버드로 간주 될 수 있습니다.

순수한 Harvard 아키텍처는 일반적으로 코드와 데이터 메모리간에 리소스를 공유 할 필요가없는 경우 특정 수준의 복잡성을 가진 컴퓨터를 Von Neuman 아키텍처보다 빠르게 실행할 수 있습니다. 핀아웃 제한이나 다른 요소로 인해 하나의 버스를 사용하여 두 메모리 공간에 액세스해야하는 경우 이러한 이점은 거의 무효화 될 수 있습니다.

"순수한"하버드 아키텍처는 코드를 실행할 프로세서 이외의 메커니즘에 의해 메모리에 저장되는 코드 실행으로 제한됩니다. 이것은 공장에서 목적을 설정하지 않은 장치 (또는 특수한 프로그래밍 장비를 가진 사람)를위한 그러한 아키텍처의 유틸리티를 제한합니다. 이 문제를 완화하기 위해 두 가지 접근 방식을 사용할 수 있습니다.

일부 시스템에는 별도의 코드와 메모리 영역이 있지만 코드 버스를 간단히 인계하고 일부 작업을 수행하며 이러한 작업이 완료되면 CPU로 제어권을 반환하도록 요청하는 특수 하드웨어를 제공합니다. 이러한 시스템 중 일부는 이러한 작업을 수행하기 위해 상당히 정교한 프로토콜이 필요하고, 일부는 이러한 작업을 수행하기위한 특별한 지침이 있으며, 일부는 특정 "데이터 메모리"주소를 감시하고 액세스하려고 할 때 인계 / 릴리스를 트리거하기도합니다. . 이러한 시스템의 주요 측면은 "코드"및 "데이터"에 대해 명시 적으로 정의 된 메모리 영역이 있다는 것입니다. CPU가 "코드"공간을 읽고 쓰는 것이 가능하더라도 여전히 데이터 공간과 의미 적으로 다른 것으로 인식됩니다. '

일부 고급 시스템에서 사용되는 대체 방법은 메모리 중재 장치에 연결되는 두 개의 메모리 버스 (코드 용 및 데이터 용)가있는 컨트롤러를 사용하는 것입니다. 해당 장치는 각각 별도의 메모리 버스를 사용하여 다양한 메모리 하위 시스템에 연결됩니다. 하나의 메모리 서브 시스템에 대한 코드 액세스는 다른 메모리 서브 시스템에 대한 데이터 액세스와 동시에 처리 될 수 있으며; 코드와 데이터가 동일한 서브 시스템에 동시에 액세스하려고 할 때만 기다려야합니다.

이 방법을 사용하는 시스템에서 프로그램의 성능이 중요하지 않은 부분은 메모리 하위 시스템 간의 경계를 무시할 수 있습니다. 코드와 데이터가 동일한 메모리 하위 시스템에 상주하는 경우 별도의 하위 시스템에있는 것처럼 빠른 속도로 실행되지 않지만 일반적인 프로그램의 많은 부분에서는 중요하지 않습니다. 일반적인 시스템에는 성능이 실제로 중요한 작은 부분의 코드가 있으며 시스템에서 보유한 데이터의 작은 부분에서만 작동합니다. 하나의 시스템에 16K RAM이있는 시스템을 두 개의 8K 파티션으로 나눈 경우에는 링커 명령을 사용하여 성능에 중요한 코드가 전체 메모리 공간의 시작 부분에 위치하고 성능에 중요한 데이터가 종료. 전체 코드 크기가 9K로 증가하면 마지막 1K 내의 코드는 다른 곳에 배치 된 코드보다 느리게 실행되지만 해당 코드는 성능에 중요하지 않습니다. 마찬가지로 코드가 6K에 불과하지만 데이터가 9K로 증가한 경우 가장 낮은 1K의 데이터에 대한 액세스는 느리지 만 성능에 중요한 데이터가 다른 곳에 있으면 문제가되지 않습니다.

코드가 8K 미만이고 데이터가 8K 미만인 경우 성능이 최적이지만 앞에서 언급 한 메모리 시스템 설계는 코드와 데이터 공간 사이에 엄격한 파티션을 부과하지 않습니다. 프로그램에 1K의 데이터 만 필요한 경우 코드는 최대 15K까지 커질 수 있습니다. 2K 코드 만 필요한 경우 데이터가 14K로 커질 수 있습니다. 코드 전용 8K 영역과 데이터 전용 8K 영역을 사용하는 것보다 훨씬 다재다능합니다.

논의되지 않은 한 가지 측면은 일반적으로 16 비트 주소 버스 만있는 소형 마이크로 컨트롤러의 경우 하버드 아키텍처가 주소 공간을 효과적으로 두 배로 늘리는 것입니다. 64K의 코드, 64K의 RAM 및 64k의 메모리 매핑 된 I / O를 가질 수 있습니다 (시스템이 포트 번호 대신 메모리 매핑 된 I / O를 사용하는 경우 후자는 이미 코드에서 I / O 주소를 분리하고 & RAM 공간).

그렇지 않으면 동일한 64K 주소 공간 내에서 코드, RAM 및 선택적으로 I / O 주소를 모두 작성해야합니다.