KR20150021952A - 네트워크 온 어 칩에 대한 스케일러블 캐시 코히어런스 - Google Patents

Abstract

다수의 캐시 코히어런트 마스터 IP 코어들(CCM들) 및 비-캐시 코히어런트 마스터 IP 코어들(NCM들)을 갖는 시스템 온 어 칩에서 캐시 코히어런스를 유지하는 것에 관한 것이다. 플러그-인 캐시 코히어런스 관리자(CM), 에이전트들의 코히어런스 로직 및 상호연결은 SoC에서 CCM들의 양을 스케일링하는 스케일러블 캐시 코히어런스 방식을 제공하도록 SoC에 대해 이용된다. CCM들은 각각 CM을 통해 그 CCM에 대한 데이터를 저장하는 적어도 하나의 캐시에 동작 가능하게 커플링된 적어도 하나의 프로세서를 포함한다. CM은 캐시들 중 제 1 캐시 상의 캐시 라인의 캐시 미스에 응답하여 캐시 코히어런스를 유지하고, 이어서 제 1 캐시의 캐시 라인의 캐시 미스에 대응하는 저장된 데이터의 인스턴스에 대한 요청을 브로드캐스트한다. 각각의 CCM은 그 자신의 코히어런트 캐시를 유지하고 각각의 NCM은 코히어런트 및 비-코히어런트 어드레스 공간으로 통신 트랜잭션들을 발행하도록 구성된다.

Description

칩 상에서 네트워크에 대한 스케일러블 캐시 코히어런스{SCALABLE CACHE COHERENCE FOR A NETWORK ON A CHIP}

[01] 본 출원은, 35 U.S.C.§119 하에서, 2012년 5월 24일 출원되고 발명의 명칭이 "Scalable Cache Coherence for a Network on a Chip"인 미국 가특허 출원 번호 제61,651,202호, 및 2013년 5월 21일 출원되고 발명의 명칭이 "Scalable Cache Coherence for a Network on a Chip"인 미국 정식(Non-Provisional) 특허 출원 번호 제13/899,258호의 이익 및 그에 대한 우선권을 주장한다.

저작권의 통지

[02] 본 특허 문서의 개시의 일부는 저작권 보호를 준수해야 하는 자료를 포함한다. 자료가 특허 및 등록상표청 출원 또는 기록들에 나타날 때, 저작권 소유자는 상호연결에 의한 팩스 재생에 반대하지 않지만, 그렇지 않으면 무엇이던지 모든 저작권을 보유한다.

분야

[03] 일반적으로, 본 발명의 하나 이상의 실시예들은 캐시 코히어런트 시스템(cache coherent system)들에 관한 것이다. 일 실시예에서, 캐시 코히어런트 시스템은 집적 회로에 구현된다.

[04] 컴퓨팅에 있어서, 캐시 코히어런스(cache coherence)(또한 캐시 코히어런시(cache coherency))는 공유된 자원의 로컬 캐시들에 저장된 데이터의 일관성을 지칭한다. 각각의 프로세서에 대한 별개의 캐시 메모리를 갖는 공유된 메모리 타겟 IP 코어 멀티프로세서 시스템에서 임의의 하나의 명령 피연산자의 다수의 카피들(하나의 카피는 메인 메모리 타겟 IP 코어에 있고 하나는 각각의 캐시 메모리에 있음)을 갖는 것이 가능하다. 피연산자의 하나의 카피가 변경될 때, 피연산자의 다른 카피들이 또한 변경되어야 한다. 캐시 코히어런스는 공유된 피연산자들의 값들의 변경들이 적절한 방식으로 시스템에 걸쳐서 전파되는 것을 보장하기 위한 방식이다. 코히어런스는 동일한 메모리 위치에 대한 판독들 및 기록들의 행동을 정의할 수 있다. 통상적으로 연구되는 2개의 가장 흔한 타입들의 코히어런스는 스누핑 및 디렉토리-기반(Snooping and Directory-based)이며, 각각은 그 자신의 이점들 및 단점들을 갖는다.

다양한 방법들 및 장치들이 캐시 코히어런스 시스템을 대해 설명된다. 일 실시예에서, 시스템 온 어 칩은 적어도, 클러그-인 캐시 코히어런스 관리자, 하나 이상의 에이전트들의 코히어런스 로직, 하나 이상의 비-캐시-코히어런트 마스터들, 2개 이상의 캐시-코히어런트 마스터들 및 상호연결을 포함할 수 있다. 시스템 온 어 칩을 위한 플러그-인 캐시 코히어런스 관리자, 하나 이상의 에이전트들의 코히어런스 로직 및 상호연결은 시스템 온 어 칩에서 캐시 코히어런트 마스터 지적 재산 코어들의 양을 스케일링하는 시스템 온 어 칩에 대한 스케일러블 캐시 코히어런스 방식을 제공하도록 구성된다. 플러그-인 캐시 코히어런스 관리자 및 코히어런스 로직은 제 1 캐시 코히어런트 마스터 지적 재산 코어에 대한 제 1 로컬 메모리 캐시 및 제 2 캐시-코히어런트 마스터 지적 재산 코어에 대한 제 2 로컬 메모리 캐시를 포함하는 하나 이상의 로컬 메모리 캐시들에 잠재적으로 저장되는 메모리 데이터의 일관성을 유지한다. 제 1 및 제 2 지적 재산 코어들을 포함하는 2개 이상의 마스터 지적 재산 코어들은 상기 상호연결을 통해 판독 또는 기록 통신 트랜잭션들(이를 테면, 요청 및 응답 패킷 포맷팅된 통신 및 요청 및 응답 비-패킷 포맷팅된 통신들)을 IP 타겟 메모리 코어에 송신하도록 구성된다. 시스템 온 어 칩에서 하나 이상의 부가적인 지적 재산 코어들은 캐시되지 않은 마스터(un-cached master) 또는 비-캐시-코히어런트 마스터 중 어느 하나이며, 이는 또한 상호연결을 통해 IP 타겟 메모리 코어에 판독 및/또는 기록 통신 트랜잭션들을 송신하도록 구성된다.

[06] 다수의 도면들은 본 발명의 실시예들을 참조한다.

도 1은 시스템 온 어 칩에서 캐시 코히어런트 마스터 지적 재산 코어들의 양을 스케일링하는 시스템 온 어 칩에 대한 스케일러블 캐시 코히어런스 방식을 제공하기 위해 스눕-기반 캐시 코히어런스 관리자의 실시예의 블록도를 예시한다.
[08] 도 2는 중앙에 로케이팅되는 스눕-필터-기반 캐시 코히어런스 관리자의 실시예의 블록도를 예시한다.
도 3은 시스템 내의 각각의 제어기에 의해 로케이팅되는 인스턴스에 물리적으로 분배되는 디렉토리-기반 캐시 코히어런스 관리자의 실시예의 블록도를 예시한다.
도 4는 3개의 캐시 코히어런트 마스터들을 갖는 시스템에 대한 4-홉 프로토콜을 구현하는 플러그-인 캐시 코히어런스 관리자의 실시예의 도면을 예시한다.
도 5는 스눕 필터 테이블 룩업을 갖는 3-홉 프로토콜을 구현하는 스눕 필터 기반 캐시 코히어런스 관리자의 실시예의 도면을 예시한다.
도 6은 스눕 필터 기반 캐시 코히어런트 관리자의 조직의 실시예의 도면을 예시한다.
도 7a 및 도 7b는 디렉토리-기반 캐시 코히어런스 관리자, 스눕-기반 캐시 코히어런스 관리자, 및 스눕-필터-기반 캐시 코히어런스 관리자 중 어느 하나를 지원하기 위한 표준 인터페이스의 실시예에 대한 예시적인 내부 트랜잭션 흐름을 갖는 테이블들을 예시한다.
[14] 도 8은 본 명세서에 설명된 시스템들과 방법들에 따라, 시스템-온-어-칩과 같은, 디바이스를 발생하기 위한 프로세스의 예의 실시예의 흐름도를 예시한다.

[15] 비록 본 발명이 다양한 변경들과 대안적인 형태들을 갖긴 하지만, 이들 중 특정한 실시예들은 도면들에서 예로서 도시되었으며 본 명세서에서 상세히 기술될 것이다. 발명은 개시된 특별한 형태들로 제한되지 않으며, 반대로, 의도는 발명의 사상 및 범주에 속하는 모든 변경들, 등가물들, 그리고 대안들을 커버하기 위한 것으로 이해되어야 한다.

[016] 이어지는 설명에서, 본 발명의 완전한 이해를 제공하기 위해, 특정한 루틴들, 지정된 컴포넌트들, 연결들, 서비스들의 타입들 등의 예들과 같은, 수많은 특정한 세부사항들이 설명된다. 그러나, 본 발명이 이들 특정한 세부사항들 없이 실행될 수 있다는 것이 당업자에게 자명할 것이다. 다른 예들에서, 잘 알려진 컴포넌트들 또는 방법들이 상세히 기술되지 않았으며, 오히려 본 발명의 발명을 불필요하게 모호하게 하는 것을 피하기 위해 블록도로 기술되었다. 따라서, 특정한 세부사항들 설명은 단지 예시적이다. 특정한 세부사항들이 변할 수 있으며, 그리고 그들은 여전히 본 발명의 사상 및 범위 내에 존재하는 것으로 생각될 수 있다.

[017] 네트워크 온 어 칩(network on a chip)에 대한 스케일러블 캐시 코히어런스(scalable cache coherence)를 제공하기 위한 다수의 예시적인 프로세스들 및 장치들이 설명된다. 마스터/개시자 코어들 및 슬래이브 타겟 코어들의 이질적인 성질 및 구성성(configurability)를 고려하는, 시스템 온 어 칩(System on a Chip; SoC) 상호연결에서 하나 이상의 라우터들을 통해 마스터/개시자 코어들(IC들)로부터 슬래이브 타겟 코어들(TC들)로 정보를 라우팅하는 것에 연관된 다양한 방법들 및 장치가 개시된다. 방법들 및 장치는 네트워크 온 어 칩(Network on a chip)/상호연결을 통한 정보의 효율적인 전송을 가능케 한다. 다음의 도면들 및 텍스트는 설계의 다양한 예시적인 구현들을 설명한다.

[018] 네트워크 온 어 칩에 대한 스케일러블 캐시 코히어런스는 풀(full) 코히어런스를 지원할 수 있다. 스케일러블 캐시 코히어런스는 디렉토리 기반, 또는 스눕 기반, 또는 스눕 필터 기반 코히어런스 관리자에 대한 로직의 플러그 인 세트(plug in set)를 포함하는 이점들을 제공하며, 여기서,

1. 스눕 기반(제한된 스케일러블) 아키텍처는 이전에 지원된 에이전트들의 수를 수월하게 초과하게 되고;

2. 스눕-필터 기반 아키텍처는 더 높은 스케일성(scalability)(8 내지 16 또는 그 초과의 수의 코히어런트 마스터들)에 대한 스눕(제한된 스케일) 아키텍처를 끊김없이 연장하고,

3. 파티셔닝 전략은 다른 지적 재산 블록들이 혼합되고 코히어런트 및 비-코히어런트 IP 블록들 둘 다와 매칭하도록 허용한다.

[019] 일반적으로, 플러그-인 캐시 코히어런스 관리자, 하나 이상의 에이전트들의 코히어런스 로직 및 상호연결은 다수의 캐시 코히어런스 관리자 마스터 IP 코어들(CCM들) 및 캐시되지 않은 코히어런트 마스터 IP 코어들(UCM들) 둘 다로 시스템 온 어 칩의 캐시 코히어런스를 유지하도록 협력한다. 플러그-인 캐시 코히어런스 관리자(CM), 에이전트들의 코히어런스 로직 및 상호연결들은 시스템-온-어-칩에서 캐시 코히어런트 마스터 IP 코어들의 양을 스케일링하는 스케일러블 캐시 코히어런스 방식을 제공하기 위해 시스템-온-어-칩에 대해 이용된다. 캐시 코히어런트 마스터 IP 코어들은 각각 캐시 코히어런스 관리자를 통해 그 캐시 코히어런트 마스터 IP 코어에 대한 데이터를 저장하는 적어도 하나의 캐시에 동작 가능하게 커플링되는 적어도 하나의 프로세서를 포함한다. 캐시 코히어런스 관리자는 캐시들 중 제 1 캐시 상의 캐시 라인의 캐시 미스(cache miss)에 응답하여 캐시 코히어런스를 유지하고, 이어서 제 1 캐시에서 캐시 라인의 캐시 미스에 대응하는 저장된 데이터의 인스턴스에 대한 요청을 브로드캐스트한다. 각각의 캐시 코히어런트 마스터 IP 코어는 그 자신의 코히어런트 캐시를 유지하고, 각각의 캐시되지 않은 코히어런트 마스터 IP 코어는 코히어런트 및 비-코히어런트 어드레스 공간들 둘 다에 통신 트랜잭션들을 발행하도록 구성된다.

[020] 도 1은 시스템 온 어 칩에서 캐시 코히어런트 마스터 지적 재선 코어들의 양을 스케일링하는 시스템 온 어 칩에 대한 스케일러블 캐시 코히어런스 방식을 제공하기 위한 스눕-기반 캐시 코히어런스 관리자의 실시예의 블록도를 예시한다. 시스템 온 어 칩(100)은 플러그-인 캐시 코히어런스 관리자(CM), 상호연결, 캐시 코히어런트 마스터 지적 재산 코어(CCM), 캐시되지 않은 코히어런트 마스터 지적 재산 코어들(UCM), 비-코히어런트 마스터 지적 재산 코어들(NCM), 마스터 에이전트들(IA), 타겟 에이전트들(TA), 스눕 에이전트들(STA), DVM 타겟 에이전트(DTA), 메모리 관리 유닛들(MMU), 메모리 타겟 IP 코어를 포함하는 타겟 IP 코어들 및 그의 메모리 제어기를 포함할 수 있다.

[021] 시스템 온 어 칩(100)에 대한 플러그-인 캐시 코히어런스 관리자, 하나 이상의 에이전트들의 코히어런스 로직 및 상호연결은 시스템 온 어 칩(100)에서 캐시 코히어런트 마스터 지적 재산 코어들의 양을 스케일링하는 시스템 온 어 칩(100)에 대한 스케일러블 캐시 코히어런스 방식을 제공한다. 플러그-인 캐시 코히어런스 관리자 및 코히어런스 로직은 제 1 캐시 코히어런스 마스터 지적 재산 코어에 대한 제 1 로컬 메모리 캐시 및 제 2 캐시-코히어런트 마스터 지적 재산 코어에 대한 제 2 로컬 메모리 캐시를 포함하는 하나 이상의 로컬 메모리 캐시들에 잠재적으로 저장된 메모리 데이터의 일관성을 유지한다. 제 1 및 제 2 캐시-코히어런트 마스터 지적 재산 코어들, 캐시되지 않은 마스터 IP 코어들, 및 비-캐시-코히어런트 마스터 IP 코어들을 포함하는 마스터 지적 재산 코어들은 상호연결을 통해 IP 타겟 메모리 코어로 판독 또는 기록 통신 트랜잭션들을 송신하도록 구성된다. 임의의 타입의 다수의 마스터 코어들이 상호연결 및 플러그-인 캐시 코히어런트 관리자에 연결되지만, 도면들에서 도시된 양은 단지 예시 목적들을 위한 것이라는 점에 주목한다.

[022] 플러그-인 캐시 코히어런트 관리자는 메모리의 각각의 로컬 캐시 및 메모리 IP 타겟 코어에 저장된 명령 피연산자들의 인스턴스들의 일관성을 유지한다. 피연산자의 하나의 카피가 변경될 때, 그 피연산자의 다른 인스턴스들은 공유된 피연산자들의 값이 적절한 방식으로 직접 회로에 걸쳐서 전파되는 것을 보장하도록 또한 변경되어야 한다.

[023] 캐시 코히어런트 마스터들, 캐시되지 않은 코히어런트 마스터들 및 집적 회로의 메인 메모리 타겟 IP 코어 간에 코히어런스를 유지하는 캐시 코히어런스 관리자는 상호연결을 위한 컴포넌트이다. 따라서, 플러그-인 캐시 코히어런트 관리자는 다수의 캐시 코히어런트 마스터 IP 코어들, 캐시되지 않은 코히어런트 마스터 지적 재산 코어들 및 비-캐시 코히어런트 마스터 IP 코어들로 시스템 온 어 칩(100)의 캐시 코히어런스를 유지한다.

[024] 마스터 IP 코어는 공통 상호연결 상에서 통신한다. 각각의 캐시 코히어런트 마스터는 플러그-인 캐시 코히어런스 관리자를 통해 그 캐시 코히어런트 마스터 IP 코어에 대한 데이터를 저장하는 적어도 하나의 캐시에 동작 가능하게 커플링되는 적어도 하나의 프로세서를 포함한다. 캐시로부터의 데이터는 또한 메인 메모리 타겟 IP 코어에 영구적으로 저장된다. 메인 메모리 타겟 IP 코어는 다수의 마스터 IP 코어들 간에 공유된다. 플러그-인 캐시 코히어런스 관리자는 캐시들 중 제 1 캐시 상의 캐시 라인의 캐시 미스에 응답하여 캐시 코히어런스를 유지하고, 이어서 제 1 캐시의 캐시 라인의 캐시 미스에 대응하는 저장된 데이터의 인스턴스에 대한 요청을 브로드캐스트한다. 각각의 캐시 코히어런트 마스터는 그 자신의 코히어런트 캐시를 유지한다. 각각의 캐시되지 않은 코히어런트 마스터는 코히어런트 및 비-코히어런트 어드레스 공간들로 통신 트랜잭션들을 발행하도록 구성된다.

[025] 캐시 코히어런스 관리자의 스누핑 버전(snooping version)들에서, 캐시 코히어런스 관리자는 캐시 미스에 대응하는 데이터의 인스턴스에 대한 요청을 다른 캐시 제어기들에 브로드캐스트한다. 다음으로, 브로드캐스트 요청의 수신에 응답하여, 캐시 코히어런스 관리자는, 다른 캐시들 중 적어도 하나가 동일한 캐시 라인 상태에서 캐시 라인의 올바른 인스턴스 카피를 갖는지를 결정하고 미스된 캐시로의 캐시 라인의 올바른 카피의 전송을 야기한다. 다음으로, 캐시 코히어런스 관리자는 각각의 노드에 대한 캐시 라인에 저장되고 있는 데이터의 현재 상태의 각각의 캐시를 업데이트한다.

[026] 상호연결은 1) 데이터 흐름 버스 패브릭 및 이와 별개의 2) 캐시 코히어런스 관리자의 유연한 구현으로 커플링되는 그의 코히어런스 커맨드 및 시그널링 패브릭으로 구성된다.

[027] 스케일러블 캐시 코히어런스 방식은, 1) 스누핑-기반 캐시 코히어런스 매커니즘, 2) 스눕-필터링-기반 캐시 코히어런스 매커니즘 또는 3) 분배된 디렉토리-기반 캐시 코히어런스 매커니즘으로서 구현될 수 있으며, 이들 모두는 위의 3개의 시스템 코히어런스 방식들 중 하나를 지원하기 위해 그의 하드웨어 컴포넌트들과 플러그 인(plug in)한다. 따라서, 캐시 코히어런스 관리자에 대한 로직 블록은 상호연결 및 에이전트들의 코히어런스 로직을 변경함 없이 위의 3개의 시스템 코히어런스 방식들 중 하나를 지원하도록 로직 블록 내의 다양한 하드웨어 컴포넌트들을 플러그 인할 수 있다.

[028] 캐시 관리자의 유연한 구현의 플러그 인 성질은 4 또는 그 미만과 같이 제한된 수의 코히어런트 마스터들을 갖는 스누핑 기반 코히어런스 로직 매커니즘을 통한 스케일성 및 캐시 제어기를 통해 적어도 하나의 캐시(캐시 코히어런트 마스터로서 알려짐)에 동작 가능하게 커플링되는 매우 다수의 마스터 IP 코어들에 대한 분배된 디렉토리 기반 코히어런스 매커니즘을 통한 높은 스케일성 둘 다를 허용한다(8+).

[029] 플러그-인 캐시 코히어런스 관리자는 캐시 코히어런스 관리자의 로직 블록과 코히어런스 커맨드 및 시그널링 패브릭 간의 경계에서 표준 인터페이스를 통해 3개의 시스템 코히어런스 방식들 중 임의의 것을 지원한다. 시스템의 사용자는 그들의 계획된 시스템 온 어 칩(100)에 가장 적합한, 3개의 상이한 플러그-인 코히어런스 관리자들 중 하나를 선택하도록 허용된다. 표준 인터페이스는 이러한 다양한 시스템 코히어런스 방식들을 지원하는 것을 가능하게 하기 위해 상이한 형태들의 로직이 캐시 코히어런스 관리자의 로직 블록에 플러깅되도록 허용한다. 제어 신호들의 표준 인터페이스는 코히어런스 관리자와 코히어런스 커맨드 및 시그널링 패브릭 간의 경계 사이에 존재한다.

[030] 도 1은 시스템 온 어 칩(100)의 캐시 코히어런트 마스터 IP 코어들에 대해, 모든 다른 로컬 메모리 캐시들로의 각각의 로컬 메모리 캐시의 캐시 액세스를 브로드캐스트하도록 코히어런스 로직과 협력하는 스눕-기반 캐시 코히어런스 관리자로서 구현되는 플러그-인 캐시 코히어런스 관리자를 그래픽적으로 도시한다. 스눕-기반 캐시 코히어런스 관리자는 스누핑을 위한 스눕 브로드캐스트에 의존하고, 1) 캐시 코히어런트 마스터 IP 코어들 및 캐시되지 않은 코히어런트 마스터 IP 코어들 둘 다로부터의 통신 트랜잭션들을 지원한다. 마스터 에이전트 및 타겟 에이전트는 주로 임의의 비-캐시 코히어런트 마스터 IP 코어들에 대한 통신 트랜잭션들을 핸들링한다. 스누핑은, 개별 캐시들이 캐시한 메모리 위치들로의 액세스들을 위한 어드레스 라인들을 개별 캐시들이 모니터링하고, 스눕에 응답하여 코히어런스 관리자에 역으로 리포트하는 프로세스일 수 있다. 스누핑-기반 캐시 코히어런스 관리자는 1-4개의 CCM들을 갖는 시스템들과 같은 소규모 시스템들을 핸들링하도록 구성되며, 다수의 UCM들은 모든 CCM들에 브로드캐스트를 스누핑하거나 모든 CCM들로부터 수집된다. 스눕-기반 캐시 코히어런스 관리자는 모든 CCM들로의 브로드캐스트를 스누핑한다. 스누핑된 응답 및 가능하게는 데이터가 모든 CCM들로부터 스누핑-기반 캐시 코히어런스 관리자에 역으로 송신된다. 스누핑-기반 캐시 코히어런스 관리자는, 필요한 경우 메모리 IP 타겟 코어를 업데이트하고 순서화 목적들을 위해 메모리 IP 타겟 코어로부터의 응답을 계속 트래킹한다.

[031] 도 2는 중앙에 로케이팅된 스눕-필터-기반 캐시 코히어런스 관리자의 실시예의 블록도를 예시한다. 플러그-인 캐시 코히어런스 관리자는 그들이 캐시한 메모리 위치들로의 액세스를 위해 개별 캐시들을 관리하도록 코히어런스 로직과 협력하는 단일-스눕 필터-기반 캐시 코히어런스 관리자로서 구현될 수 있다. 스눕-필터 기반 캐시 코히어런스 관리자(202)는 스눕 동작들을 제어하기 위한 관리 로직 부분, 다른 동작들을 위한 제어 로직 및 트래킹된 캐시 라인들의 코히어런스 시에 데이터를 유지하기 위한 저장 섹션을 가질 수 있다. 스눕-필터 기반 캐시 코히어런스 관리자(202) 개별 캐시들은 기록 무효화 프로토콜(write invalidate protocol)을 통해 이들이 캐시한 메모리 위치들에 대한 액세스를 위해 그 자신의 어드레스 라인들을 모니터링한다. 스눕-필터 기반 방식은 또한 룩업 방식을 이용하는 것과 함께 스누핑을 위한 근본적인 스눕 브로드캐스트 방식에 의존할 수 있다. 캐시 코히어런스 마스터 IP 코어들은 코히어런스 커맨드 및 시그널링 패브릭들 통해 단일 스눕 필터-기반 캐시 코히어런스 관리자(202)와 통신한다.

[032] 스눕 필터-기반 캐시 코히어런스 관리자(202)는 각각의 로컬 캐시에서 캐시 코히어런트 데이터에 관한 상태를 검사하기 위한 주기적인 스누핑은 물론 모든 로컬 캐시 메모리들의 캐시 라인 엔트리들의 상태를 결정하기 위해 복수의 엔트리들에 관한 테이블 룩업(table look up)을 수행한다. 스눕-필터는 복수의 엔트리들을 유지함으로써 스누핑 트래픽을 감소시키며, 각각의 엔트리는 하나 이상의 노드들에 의해 소유될 수 있는 캐시 라인을 표현한다. 엔트리들 중 하나의 교체(replacement)가 요구될 때, 스눕-필터는 엔트리들 각각의 존재 벡터(presence vector)로부터 결정된 바와 같이, 가장 적은 노드들에 의해 소유되는 캐시 라인 또는 라인들을 표현하는 엔트리를 교체하도록 선택한다.

[033] 저장 비용들에 민감하고 DRAM 설계들이 표준인 SoC 아키텍처들에서, 스눕 필터 디렉토리 엔트리들이 캐시된다. 태그 정보 및 존재 벡터들의 캐싱을 위한 주요한 2개의 구조들이 있다. 스눕-필터 기반 캐시 코히어런스 관리자(202)는 메모리 기반 필터 및 캐시 기반 필터 아키텍처의 양상들을 결합할 수 있다.

[034] 메모리 기반 필터: 디렉토리 캐시로서 또한 알려짐. 캐싱된 임의의 라인은 이 라인이 얼마나 많은 코히어런스 마스터 IP 코어들에 캐시되는지에 무관하게 필터에서 기껏해야 하나의 엔트리를 갖는다.

[035] 캐시 기반 필터: 분배된 스눕 필터 방식으로서 또한 알려짐. 그의 최고 레벨(L2) 캐시들에서 CCM들의 캐시 라인들의 디렉토리인 스눕 필터. 캐싱되는 라인은 캐시 코히어런스 마스터 IP 코어들의 각각의 식별된 세트에 대한 필터에서 기껏해야 하나의 엔트리를 갖는다. 따라서, 라인은 캐시 코히어런스 마스터 IP 코어들의 전체 세트에 걸쳐서 1개 초과의 엔트리를 가질 수 있다.

[036] 캐시 코히어런스 마스터 IP 코어들이 코히어런스 패브릭을 통해 단일 로직 코히어런스 관리자(202)와 통신하는 SoC 아키텍처들에서, 메모리 기반 필터 및 캐시 기반 필터 아키텍처들은 스눕-필터 기반 아키텍처 내로 넣어진다(collapse).

[037] 디렉토리 캐시 기반 구조의 주요 이점은 그의 비교적 간단함이다(디렉토리 캐시는 에이전트들의 코히어런스 로직과 연관됨). 스눕 필터 기반 캐시 코히어런스 관리자(202)는 스누핑하지만 종래의 브로드캐스트를 수행하지 않고, 대신 "스눕 필터 구조"에서 각각의 캐시 코히어런트 마스터의 모든 최고 레벨 캐시 (HLC)* 태그들의 카피를 유지하는 중앙식 디렉토리로서 구현될 수 있다. 스눕 필터의 각각의 태그는 각각의 캐시 코히어런트 마스터의 대응하는 HLC의 대략적(그러나 안전한) 상태와 연관된다. 단일 디렉토리가 각각의 메모리 제어기와 토크(talk)한다. 주 단점은 비-로컬 디렉토리 캐시들을 액세스하는데 몇 개의 사이클들의 레이턴시가 걸린다는 것이다. 이 단점은 교체 정책에서 공간 및 일부 복잡도의 희생으로 캐시 기반 필터로 극복한다. 분배된 디렉토리는 그것이 제어하는 메모리와 연관된 인스턴스를 갖는다. 디렉토리 기반 설계는 물리적으로 분배되며 - 시스템에서 각각의 메모리 제어기와 연관된다. 디렉토리는 그것이 "집"인 (캐시 라인 크기의) 각각의 메모리 블록에 대한 존재 벡터를 저장한다. 분배된 디렉토리에 기초하면, 디렉토리 인스턴스는 각각의 메모리 IP 타겟 코어와 연관된다.

[038] 스눕 필터 기반 캐시 코히어런스 관리자의 실시예의 특정한 구현에 대해, 도 6을 참조하면, 도 2는 중앙 디렉토리 구현을 갖는 예시적인 플러그-인 캐시 코히어런스 관리자를 도시하는 반면에, 도 3은 분배된 디렉토리들의 세트를 갖는 예시적인 플러그-인 캐시 코히어런스 관리자를 도시한다.

[039] 도 3은 시스템 내의 각각의 메모리 제어기에 의해 로케이팅되는 인스턴스에 물리적으로 분배되는 디렉토리-기반 캐시 코히어런스 관리자의 실시예의 블록도를 예시한다. 플러그-인 캐시 코히어런스 관리자는 적어도 제 1 및 제 2 로컬 메모리 캐시들 간의 코히어런스를 유지하는 공통 디렉토리에서 공유되는 데이터를 계속 트래킹하는 디렉토리-기반 캐시 코히어런스 관리자로서 구현될 수 있다. 디렉토리 기반 캐시 코히어런스 관리자는 레이턴시를 개선하기 위한 중앙에 로케이팅된 디렉토리 또는 디렉토리-기반 캐시 코히어런스 관리자(302A) 내지 디렉토리-기반 캐시 코히어런스 관리자(302D)의 제 4 분배된 인스턴스와 같은 분배된 디렉토리의 세트일 수 있어서, 코히어런스 커맨드 및 시그널링 패브릭을 통한 협력은 시스템 초크 포인트들(system choke points)을 감소시킨다. 디렉토리는 각각의 로컬 캐시 내의 캐시 코히어런트 데이터에 관한 상태를 검사하도록 테이블 룩 업을 수행한다. 각각의 로컬 캐시는, 상태의 변경이 그 캐시에 저장된 캐시 데이터에 대해 발생할 때 코히어런트 관리자로의 통신을 송신한다는 것을, 그 캐시 코히어런스 마스터의 스눕 에이전트의 코히어런스 로직을 통해 인지한다. 각각의 캐시 라인에 대해 하나의 디렉토리 엔트리를 갖는 종래의 디렉토리 아키텍처는 저장 필요성들의 견지들에서 매우 고가이다. 그러나 이것은 일반적으로 분배된 메모리 설계들에 있어서 보다 적절하다.

[040] 스눕 필터 기반 캐시 코히어런스 관리자와 같은 디렉토리-기반 캐시 코히어런스 관리자는 네트워크에 걸쳐서 분배될 수 있으며, 이 경우 캐시 코히어런스 관리자(302A 내지 302D) 중 2개 이상의 분배된 인스턴스들은 (도 3에서 도시된 바와 같이) 코히어런스 커맨드 및 시그널링 패브릭을 통해 서로 통신한다. 분배된 디렉토리-기반 캐시 코히어런스 관리자(302A 내지 302D)의 인스턴스들 각각은 분배된 디렉토리-기반 캐시 코히어런스 관리자의 그 인스턴스에 의해 트래킹된 로컬 캐시들에서의 변경들을 다른 인스턴스들에 통신한다.

[041] 디렉토리-기반 시스템에서, 공유되는 데이터는 캐시들 간의 코히어런스를 유지하는 공통 디렉토리에 배치된다. 디렉토리는 프로세서가 메인 메모리 타겟 IP 코어로부터 그의 캐시로 엔트리를 로딩하기 위한 허가(permission)를 요청해야 하는 필터로서 작용한다. 엔트리가 공통 디렉토리에서 변경될 때, 디렉토리는 그 엔트리로 다른 로컬 메모리 캐시들을 업데이트하거나 무효화한다. 디렉토리는 각각의 로컬 캐시에서 캐시 코히어런트 데이터에 관한 상태를 검사하도록 테이블 룩 업을 수행한다.

[042] 일 실시예에서, 단일 디렉토리는 각각의 메모리 제어기와 토크한다. 분배된 디렉토리에 비해 주요 단점은 비-로컬 디렉토리 캐시들에 액세스하는데 다수의 사이클들의 레이턴시가 걸린다는 것이다. 단점은 교체 정책에서 공간 및 일부 복잡도의 희생으로 캐시 기반 필터로 극복된다. 분배된 디렉토리는 그것이 제어하는 메모리와 연관되는 캐시 관리자의 인스턴스를 갖는다. 디렉토리 기반 설계는 시스템에서 각각의 메모리 제어기에 의해 로케이팅되는 인스턴스에 물리적으로 분배된다. 디렉토리는 그것이 "집"인 (캐시 라인 크기의) 각각의 메모리 블록에 대한 존재 벡터를 저장한다.

[043] 전반적으로, 스누핑 및 디렉토리-기반의 코히어런스의 타입들은 그 자신의 이익들 및 단점들을 각각 가지며, 구성 로직은 3개의 타입들의 캐시 코히어런트 관리자들 중 하나에 플러그 인하기 위한 옵션을 사용자에게 제시한다. 스누핑 프로토콜들은 충분한 대역폭이 이용 가능한 경우, 모든 트랜잭션들이 모든 프로세서들에 의해 인식되는 요청/응답이므로 더 빠른 경향이 있다. 단점은 스누핑이 4 캐시 코히어런트 마스터 IP 코어들을 지나 매우 스케일러블하지 않다는 것이다. 각각의 요청은 시스템의 모든 노드들에 브로드캐스트되어야 하며, 이는 시스템이 더 커져야 하기 때문에,　(논리적 또는 물리적) 버스 및 그것이 제공하는 대역폭의 크기가 증가해야 한다는 것을 의미한다. 다른 한편, 디렉토리들은 더 긴 레이턴시들(3홉 또는 4홉 요청/포워드/응답 프로토콜에 있어서)를 갖지만, 메시지들이 브로드캐스트가 아닌 점 대 점(point to point)이기 때문에 훨씬 적은 대역폭을 이용하는 경향이 있다. 이러한 이유로, 더 큰 시스템(64개 초과의 독립적 프로세서들/독립적 마스터들) 대부분은 이러한 타입의 디렉토리 기반 캐시 코히어런스 관리자를 이용한다.

[044] 다음으로, 플러그-인 캐시 코히어런스 관리자는 3-홉 또는 4-홉 프로토콜 중 어느 하나를 구현하기 위한 홉 로직을 갖는다. 캐시 코히어런스 관리자는 시스템 온 어 칩의 2개 이상의 마스터 IP 코어들 간의 캐시 액세스를 순서화하도록 구성된 순서화 로직(ordering logic)을 또한 갖는다. 플러그-인 캐시 코히어런스 관리자는 1) 캐시 코히어런트 마스터들 및 비-캐시 코히어런트 마스터들로부터의 캐시 데이터 요청들의 모든 코히어런스를 핸들링하고, 2) 시스템 온 어 칩의 2개 이상의 마스터 IP 코어들 간의 캐시 액세스들을 순서화하고, 3) 시스템 온 어 칩의 2개 이상의 마스터 IP 코어들 간의 충돌들을 해결하고 4) 스눕 브로드캐스트들을 생성하고 및/또는 테이블 룩업을 수행하고, 그리고 5) 추론적(speculative) 메모리 액세스를 지원하도록 구성된 로직을 가질 수 있다.

[045] 도 4는 3개의 캐시 코히어런트 마스터들을 갖는 시스템에 대한 4-홉 프로토콜을 구현하는 플러그-인 캐시 코히어런스 관리자의 도면을 예시한다. 예시적인 시스템은 3개의 캐시 코히어런트 마스터 IP 코어들(CCM1 내지 CCM3), 플러그 인 스눕 브로드캐스트 기반 캐시 코히어런트 관리자의 예시적인 인스턴스(CM_B), 타겟 메모리 IP 코어(슬래이브 DRAM) 및 마스터 에이전트들(IA) 및 스눕 에이전트들(STA)의 코히어런스 로직을 포함한다. 2개의 예시적인 타입들이 캐시 코히어런스 관리자 - 3 홉 및 4 홉 프로토콜에 의해 구현될 수 있다. 도 4는 X-축 상의 4-홉 프로토콜 및 Y-출 상의 시간(위에서 아래로의 시간 흐름)에 대해 컴포넌트들 간의 트랜잭션 통신들을 갖는 트랜잭션 흐름도(400)를 도시한다. 각각의 화살표는 트랜잭션을 표현하고 id를 갖는다. 예시적인 요청/응답 트랜잭션 통신들은 요청에 대한 실선 화살표 및 응답에 대한 파선 화살표들에 의해 표시된다. 4-홉 프로토콜에서, 스눕 캐시 라인 상태가 먼저 캐시 코히어런트 관리자에게 송신되고, 이어서 코히어런트 관리자는 요청 캐시 코히어런트 마스터 IP 코어로의 데이터의 송신의 배열을 담당한다. 따라서, 4 홉 프로토콜은 요청자 캐시 코히어런트 마스터/개시자 IP 코어로의 캐시 라인 전달을 갖는다. 4-홉 프로토콜에 있어서, 캐시 코히어런트 마스터/개시자 IP 코어로의 캐시 라인 전달은 4개까지의 프로토콜 단계들을 거친다. 4-홉 프로토콜의 단계 1에서, 캐시 코히어런트 마스터/개시자들의 요청은 캐시 코히어런트 관리자(CM)에 송신된다. 단계 2에서, 코히어런트 관리자는 다른 캐시 코히어런트 마스터/개시자들을 스누핑한다. 단계 3에서, 다른 캐시 코히어런트 마스터/개시자들로부터의 응답들은, 가능하게는 이들 중 하나 이상이 코히어런트 관리자에게 캐시 라인의 최근의 카피를 제공한다. 단계 4에서, 코히어런트 관리자로부터 요청 캐시 코히어런트 마스터/개시자 IP 코어로의 데이터의 전달은 메모리 타겟 IP 코어로의 가능한 기록과 함께 발생한다.

[046] 도 5는 스눕 필터 테이블 룩 업을 갖는 3-홉 프로토콜을 구현하는 스눕 필터 기반 캐시 코히어런스 관리자의 도면을 예시한다. 예시적인 시스템은 3개의 캐시 코히어런트 마스터 IP 코어들(CCM1 내지 CCM3), 플러그 인 스눕-필터 기반 캐시 코히어런트 관리자의 예시적인 인스턴스(CM_SF), 타겟 메모리 IP 코어(슬래이브 DRAM), 및 마스터 에이전트들(IA) 및 스눕 에이전트들(STA)의 코히어런스 로직을 포함한다. 에이전트들의 캐시 코히어런트 관리자 및 코히어런스 로직은 3-홉 프로토콜을 통한 직접적인 "캐시-투-캐시(cache-to-cache)" 전달을 지원한다. 3-홉 프로토콜에 있어서, 캐시 코히어런트 마스터/개시자 IP 코어로의 캐시 라인 전달들은 3개까지의 프로토콜 단계들을 거친다. 도면(500)에서 3-홉 프로토콜의 단계 1에서, 캐시 코히어런트 마스터/개시자의 요청은 호스트 시스템 관리자(CM)에 송신된다. 단계 2에서, 코히어런트 관리자는 다른 캐시 코히어런트 마스터/개시자들 IP 코어들의 캐시들을 스누핑한다. 단계 3에서, 캐시 코히어런트 마스터/개시자들로부터의 응답들은 코히어런트 관리자에 송신되고, 단순한 핸드쉐이크(handshake) 이후에, 응답 캐시 코히어런트 마스터/개시자로부터의 데이터는 메모리로의 가능한 기록백(wirteback)과 더불어 요청 캐시 코히어런트 마스터/개시자에 직접 송신된다.

[047] 전체적으로, 3-홉 프로토콜은 데이터 리턴에 대한 더 낮은 레이턴시 및 더 낮은 전력 소비를 갖는 반면에, 4-홉 프로토콜은 더 단순한 트랜잭션 흐름(응답 캐시 코히어런스 마스터 IP 코어는 코히어런스 관리자에만 모든 응답들을 송신하고; 이것은 원 요청자에게 데이터를 역으로 송신하거나 가능하게는 메모리에 기록백할 필요가 없음) 및 가능하게는 더 적은 경쟁 조건들 및 이에 따른 더 낮은 검증 비용들을 갖는다. 레이턴시를 감소시키고 전력을 감소시키는 관점에서, 3-홉 프로토콜 바람직할 수 있다. 사용자는 플러그 인 캐시 코히어런스 관리자로 어느 버전의 홉 프로토콜이 구현될지 선택할 수 있다.

[048] 일 실시예에서, 캐시 코히어런스 관리자는 캐시 데이터 요청들의 모든 코히어런스를 핸들링하도록 구성된 로직을 갖는다. 전체 트랜잭션 흐름은 아래에 제시된다.

[049] 1. 1) 코히어런트 판독 요청(통상적으로 로드로부터 발생함) 또는 2) 코히어런트 무효화 요청(통상적으로 저장소로부터 발생함) 중 어느 하나가 마스터 에이전트에서 캐시 코히어런스 마스터 IP 코어에 의해 제시될 때.

2. 마스터 에이전트는 이 요청을 디코딩하고 코히어런트 패브릭을 통해 이것을 코히어런스 관리자에게 라우팅한다.

3. (스눕 브로드캐스트 기반 및 스눕-필터 기반) 코히어런스 관리자는 코히어런스 패브릭을 이용하여 관련된 캐시 코히어런스 마스터들에게 스눕 요청들을 브로드캐스트한다. "관련된" 캐시 코히어런스 마스터들은 트랜잭션에서 특정된 공유성 도메인(shareability domain)에 기초하여 결정된다. 대안적으로, 디렉토리-기반 코히어런스 관리자는 캐시 상태에 관한 룩업을 수행한다.

4. 스눕 요청들은 실질적으로 캐시 코히어런스 마스터 IP 코어와 인터페이싱하는 스눕 에이전트(STA)로 타겟팅된다. 스눕 에이전트는 일부 북키핑(bookkeeping)를 행하고 캐시 코히어런스 마스터 IP 코어에 요청을 포워딩한다.

5. 스눕 에이전트는 가능하게는 데이터를 갖는 캐시 코히어런스 마스터 IP 코어로부터의 스눕 응답을 수신한다. 이것은 먼저 코히어런스 패브릭을 통해 코히어런스 관리자에 데이터 없이 스눕 응답을 송신한다.

6. 코히어런스 관리자는 이어서 코히어런스 패브릭을 이용하여 원래의 요청자에게 데이터를 포워딩하도록 데이터를 스누핑한 제 1 스눕 에이전트에 요청한다. 동시에, 그것은 다른 스눕 에이전트들로부터의 스눕 응답들을 프로세싱하고 - 코히어런 관리자는 트랜잭션 완료를 고려하고 가능하게는 임의의 스누핑된 데이터를 드롭(drop)하도록 이들 스눕 에이전트들에게 알리고 - 그것은 재차 이들 요청들을 위해 코히어런스 패브릭을 이용한다.

[055] 7A. 선택된 스눕 에이전트는 시스템 패브릭을 이용하여 원래의 요청자에게 데이터를 송신한다.

[056] 7B. 캐시 코히어런스 마스터 IP 코어들 중 어느 것도 데이터에 응답하지 않는 경우, 코히어런스 관리자는 비-코히어런스 패브릭(코히어런스 패브릭은 또한 특히 고 성능 해결책을 위해 이 기능을 수행하도록 확장될 수 있음)을 이용하여 메모리 요청을 시작한다.

[057] 8. (단계 7A 또는 단계 7B 중 어느 하나에서 그 데이터를 획득한) 요청 마스터 에이전트는 응답을 캐시 코히어런스 마스터 IP 코어에 송신한다.

[058] 9. 캐시 코히어런스 마스터 IP 코어는 R_Acknowledge 트랜잭션 - 이는 마스터 에이전트에 의해 수신되고 코히어런스 패브릭에 의해 코히어런스 관리자에 전달됨 - 에 응답한다. 트랜잭션은 마스터 에이전트의 관점에서 이제 완료된다(그것은 크로스오버 큐(crossover queue)로부터의 할당해제를 포함하는 북키핑 동작들을 행함).

[059] 10. 트랜잭션은 그것이 R_Acknowledge 트랜잭션을 수신하고 그것이 모든 스눕 응답들을 수신 - 동시에, 그것은 그의 크로스오버 큐로부터의 할당 해제를 포함하는 북키핑 동작들을 행함 - 할 때만 코히어런스 관리자 관점에서 완료된다.

[060] 위의 흐름은 예시 목적을 위한 것이며, 코히어런스 아키텍처에서 다양한 컴포넌트들에 관한 폭넓은 아이디어를 제공한다. 캐시 코히어런스 마스터 IP 코어들 중 어느 것도 스누핑된 데이터 등을 리턴하지 않는 경우에 추론적 메모리 액세스들이 트랜잭션 레이턴시를 개선하도록 수행되든지 간에, 상이한 트랜잭션들(예를 들어, 기록백 트랜잭션)로부터 발생하는 다양한 변형들이 있다. 일 실시예에서, 마스터 에이전트들은 1) 코히어런트 커맨드들 및 시그널링 패브릭에 코히어런트 커맨드들 및 시그널링 트래픽을 라우팅하고 2) 데이터흐름 패브릭을 통해 모든 데이터 트랜잭션들을 라우팅하도록 구성된 코히어런스 로직을 갖는다.

[061] 위에서 간략히 논의한 바와 같이, 캐시 코히어런스 관리자는 다양한 기능들을 구현하기 위한 로직을 갖는다. 코히어런스 관리자는 트랜잭션 할당/할당해제, 순서화, 충돌들, 스눕, DVM 브로드캐스트/응답들 및 추론적 메모리 요청들을 핸들링하기 위한 로직 구조들을 갖는다.

[062] 전체적으로, 캐시 코히어런스 관리자의 로직의 기능은 다음 중 하나 이상을 수행할 수 있다. 캐시 코히어런스 관리자는, AXI4_ACE의 "캐시 유지" 트랜잭션들을 포함하는 캐시 데이터 요청들의 모든 코히어런스를 핸들링한다. 캐시 코히어런스 관리자는 스눕 생성(순차적 또는 유니캐스트 또는 멀티캐스트로서 브로드캐스트-브로드캐스트), 모음을 수행한다. 소형 설계들에 대해 그리고 그것이 스케일러블한 4 초과의 캐시 코히어런트 마스터들의 대형 설계들에 대해 설계를 단순하게 유지하기 위해 마스터 에이전트들로부터 어떠한 소스 스누핑도 없다. 캐시 코히어런스 관리자는 4-홉 또는 3-홉 트랜잭션들로 원래의 요청자에 스누핑된 데이터를 송신한다. 캐시 코히어런스 관리자는 어느 응답 캐시 코히어런스 마스터 IP 코어가 요청 캐시 코히어런스 마스터 IP 코어에 데이터를 공급하는지를 결정하고; 데이터를 제공할 수 있는 다른 캐시 코히어런스 마스터 IP 코어들이 데이터를 드롭하도록 요청한다. 캐시 코히어런스 관리자는 어떠한 캐시 코히어런스 마스터 IP 코어도 공급할 데이터를 갖지 않을 때 메모리 타겟 IP 코어로부터 데이터를 요청한다. 캐시 코히어런스 관리자는 필요한 경우 메모리 및 다운스트림 캐시들을 업데이트한다. CM은 요청 마스터가 복잡하지 않은 몇몇 경우들에 책임(responsibility)을 넘겨받으며, 예를 들어, 본 명세서에서의 "간접 기록백 플래그(indirect Writeback Flag)"에 관한 논의를 참조한다. 캐시 코히어런스 관리자는 캐시 유지 트랜잭션들을 다운스트림 캐시(들)에 송신하기 위한 책임을 넘겨받는다. 캐시 코히어런스 관리자는 추론적 메모리 액세스들을 지원한다. 로직은 모든 가상 메모리 관련 브로드캐스트 및 수집 동작들을 핸들링하는데, 그 이유는 요구되는 동작이 여기서 또한 구현되는 수집 로직 및 스눕 브로드캐스트와 유사하기 때문이다. 캐시 코히어런스 관리자는 충돌들/경쟁들을 해결하고 코히어런트 요청들의 트랜잭션들 간의 순서를 결정한다. 로직은 기록 요청들을 시리즈화하여 코히어런트 공간에(즉, 기록-기록, 판독-기록, 또는 기록-판독 액세스 시퀀스를 동일한 캐시 라인에) 넣는다. 또한 기록 트랜잭션인 기록 백(write back) 트랜잭션은, 이들이 스눕들을 생성하지 않기 때문에 상이하게 취급된다. 따라서, 시리즈화 지점은 충돌하는 요청들을 순서화 또는 시리즈화하는 코히어런스 관리자 내의 로직이다. 캐시 코히어런스 관리자는 코히어런스 관리자에서 엄격한 순서로 체이닝(chained)되고, 이 순서는 그 도메인에서 모든 코히어런스 마스터들에 의해 인지된다. 캐시 코히어런스 관리자는 코히어런트 트랜잭션 완료를 위해 엄격한 히에라키(hierarchy)를 보장함으로써 프로토콜 데드록들(protocol deadlocks)을 방지한다. 캐시 코히어런스 관리자는 마스터로부터의 스눕 가능한 요청들 → 코히어런스 관리자로부터의 스눕들 → 마스터로부터의 비-스눕 가능한 요청들로 시퀀싱할 수 있다(A → B는 A의 완료가 B의 완료에 의존한다는 것을 의미함). 캐시 코히어런스 관리자는 충돌 해결을 위해 CCM들로부터 NO 헬프(help)를 획득한다고 가정하며 - 이는 모든 충돌들을 추론하고 이들을 해결한다.

[063] 캐시 코히어런스 관리자의 로직은 또한 상호연결 내에서 프로토콜 채널 상의 송신자-수신자 쌍 간의 트랜잭션들의 순서화를 또한 수행하고, "어드레스-당(per-address)"(또는 캐시 라인 당) FIFO 순서화를 유지한다.

[064] 코히어런스 관리자 아키텍처는 또한 저장 하드웨어를 포함할 수 있다. 스눕, 스눕-필터 및/또는 디렉토리 코히어런스 관리자들에 대한 저장 옵션들은 다음과 같을 수 있다. 이들은 표준 TSMC 라이브러리 - 기본적으로 판독/기록 포트들에 대한 부가적인 제어를 갖는 SRAM -로부터 이용 가능한 컴파일된 메모리를 이용할 수 있다. 일 실시예에서, 아키텍처 구조는 다수의 트랜잭션들 - 캐시 라인들 특유의 트랜잭션들 및 동일한 캐시 라인에 대한 트랜잭션들 -을 핸들링할 수 있는 CAM 메모리 구조를 포함한다. 동일한 캐시 라인에 대한 다수의 트랜잭션들은 충돌 체인 상에 배치된다. 충돌 체인은 보통 도달 순서로 정렬된 채로 유지된다(예외는 기록 백 및 그의 부분인 기록 클린(write clean) 트랜잭션들 - 이들은 스눕 ↔ WB/WC 상호작용을 핸들링하기 위해 순향? 프로그래스(forward progress)를 행할 필요가 있음).

[065] CAM에서 각각의 트랜잭션 엔트리는 다수의 필드들이다. 통상을 것들(예를 들어, 트랜잭션 ID) 외에, 다음의 필드들이 다음과 같이 정의된다.

[066] 추론 플래그(Speculation flag): 메모리 추론이 이 트랜잭션에 대해 인에이블되는지 여부, 이것은 이 트랜잭션이 생성된 캐시 코히어런스 마스터 IP 코어에 대한 파라미터 세팅 뿐만 아니라 전체 시스템의 현재 상태(이는 DRAM 채널에 대한 트래픽이 매우 높아서, 추론적 요청들을 송신할만한 가치가 없고 - 이는 Sonics IP가 DRAM 채널로의 트랙픽을 모니터링한다고 가정한다)에 의존한다.

[067] 스눕 카운트 : 브로드캐스트 스눕 이전에 미해결(outstanding) 스눕 응답의 수. 이 필드는 (공유성 도메인에 의존하여) 송신될 스눕 요청들의 수로 초기화된다. 각각의 스눕 응답이 수신되면, 이 카운터는 감소된다. 트랜잭션 할당해제에 대한 필요한 조건은 이 카운터가 0이 되는 것이다.

[068] 간접 기록백 플래그: 이 플래그는 초기에 리셋된다. 이것은 응답 캐시 코히어런스 마스터 IP 코어가 라인의 소유권을 포기하고 요청 캐시 코히어런스 마스터 IP 코어가 라인의 소유권을 수락하지 않기 때문에 응답 스눕 에이전트가 또한 메모리 타겟 IP 코어를 업데이트할 필요가 있을 때 세팅된다. 이 경우에, 스눕 에이전트는 그의 스눕 응답을 통해, 그것이 메모리 타겟 IP 코어를 업데이트할 것이라고 CM에 표시하며 - 이것은 메모리 타겟 IP 코어로부터의 완료 응답이 CM에 송신될 것을 제안한다. 이 스눕 응답이 수신되면, 간접 기록백 플래그가 세팅된다. 메모리 타겟 IP 코어로부터의 응답이 수신될 때, 이 플래그는 리셋된다.

[069] 코히어런스 관리자는 그의 지능(intelligence)을, 1) 도 1 및 도 2에서 도시된 바와 같이 상호연결 내에 또는 2) 도 3에서 도시된 바와 같이 메모리 제어기 내에 또는 3) 이들 둘의 임의의 결합으로 분배되게 할 수 있다. 따라서, 캐시 코히어런스 관리자는 메모리 제어기에서 타겟 에이전트의 다운스트림의 다수의 위치들 간에 지리적으로 분배될 수 있다. 플러그-인 가능한 캐시 코히어런스 관리자는 클록 도메인 경계들을 가로지르기 위한 더 폭넓은 능력을 갖는다.

[070] 플러그 인 캐시 코히어런스 관리자, 에이전트들 내의 코히어런스 로직 및 분할된 상호연결 설계는 성능 및 영역을 최적화하면서, 다양한 캐시 코히어런트 마스터들 및 캐시되지 않은 마스터들을 피처링하는 폭넓은 범위의 시스템 온 어 칩을 구현하기 위해 공통적인 유연한 아키텍처를 이용하는 스케일성을 허용한다. 설계는 또한 다른 지적 재산 블록들이 혼합되고 코히어런트 및 비-코히어런트 IP 블록들 둘 다에 매칭되도록 허용하는 파티셔닝 전략을 허용한다. 따라서 SoC는 1) 각각이 그 자신의 코히어런트 캐시들을 유지하는 2개 이상의 캐시 코히어런트 마스터/개시자들 및 2) 코히어런트 및 비-코히어런트 어드레스 공간들에 통신 트랜잭션들을 발행하는 하나 이상의 캐시되지 않은 마스터/개시자들을 갖는다. 예를 들어, UCM들 및 NCM들은 또한 캐시 코히어런스 마스터 IP 코어들을 핸들링하는 상호연결에 연결될 수 있다. 도 1은 예를 들어, 코히어런트 트래픽을 핸들링하는 상호연결에 연결되는 CCM들, UCM들 및 NCM들을 또한 도시한다.

[071] 캐시 코히어런스는 캐시 코히어런트 시스템이 다음의 2개의 조건들이 만족되도록 요구하는 것으로서 정의될 수 있다:

[072] 기록은 결국 모든 마스터 엔티티들에게 가시적으로 행해져야 한다 - 이는 업데이트된 것 이외의 다른 모든 캐시된 카피들이 무효화된 이후에만 기록이 완료된 것으로 간주하는 것을 보장함으로써 무효화 프로토콜들에서 달성된다.

[073] 동일한 위치로의 기록들은 모든 마스터들에 의해 동일한 순서로 인지되는 것으로 나타나야 한다.

[074] 이것을 보장하는 2개의 조건들은 다음과 같다:

i. 다수의 마스터들에 의한 동일한 위치로의 기록은 시리즈화되는데, 즉 모든 마스터는 이러한 기록들을 동일한 순서로 지각하며 - 이는 위치에 대한 모든 무효화된 동작들이 코히어런트 제어기의 단일의 지점으로부터 발생하고 상호연결이 2개의 엔티티들 간의 메시지들의 순서화를 보존한다는 것을 보장함으로써 달성된다.

ii. 동일한 메모리 위치로의 기록 동작에 이은 판독은 기록이 완료된 이후에만 리턴된다.

[075] 일 구현에서, 마스터/개시자 지적 재산 코어들은 "코히어런트" 및 "비-코히어런트"로서 분류될 수 있다. 코히어런트 트랜잭션들을 발행 가능한 코히어런트 마스터들은 추가로 캐시된 코히어런트 마스터들 및 캐시되지 않은 코히어런트 마스터들로서 분류된다.

[076] 캐시 코히어런스 마스터 IP 코어는 그 마스터와 연관된 코히어런트 캐시를 갖고 (시스템 관점에서, 주어진 마스터 지적 재산 코어 내에 내부적이기 때문에 다수의 로컬 캐시들이 있을 수 있지만, 시스템 관점에서, 그 마스터/개시자 지적 재산 코어에 적어도 하나가 있음), AXI4와 같은 프로토콜의 맥락에서, ACE 트랜잭션들과 같은 트랜잭션들의 풀(full) 세트를 발행할 수 있다. 코히어런트 마스터 IP 코어는 일반적으로 그 자신의 코히어런트 캐시들을 유지한다. 코히어런트 트랜잭션들은 공유 가능한 어드레스 공간으로의 의도된 목적지를 갖는 통신 트랜잭션들을 갖지만, 비-코히어런트 트랜잭션들이 비-공유 가능한 어드레스 공간을 타겟팅한다. 캐시 코히어런스 마스터 IP 코어는 부가적인 스눕 포트 및 상호연결 인터페이스 경계에 부가되는 그의 코히어런스 로직을 갖는 스눕 타겟 에이전트를 요구한다.

[077] 캐시되지 않은 코히어런트 마스터(UCM)는, 그것이 하나를 갖는 경우 그 자신 상에 코히어런트 캐시를 유지하지 않고, AXI4의 맥락에서, 코히어런트 트랜잭션들의 서브세트를 단지 발행할 수 있다. 캐시되지 않은 코히어런트 마스터는 코히어런트 및 비-코히어런트 어드레스 공간들에 트랜잭션들을 발행할 수 있다. UCM은 코히어런트를 유지하지 않는 캐시를 가질 수 있다는 것에 주의한다. 코히어런트 트랜잭션들은 공유 가능한 어드레스 공간을 타겟팅하지만, 비-코히어런트 트랜잭션들은 비-공유 가능한 어드레스 공간을 타겟팅한다.

[078] 비-코히어런트 마스터(NCM)는 비-공유 가능한 어드레스 공간을 타겟팅하는 비-코히어런트 트랜잭션들만을 발행한다. 따라서, 비-코히어런트 마스터는 단지 IP 타겟 코어들의 비-코히어런트 어드레스 공간에 트랜잭션을 발행한다. AXI의 맥락에서, 그것은 AXI3 또는 AXI4의 비-ACE 관련 트랜잭션들을 발행할 수 있다. NCM은 코히어런트 캐시를 갖는 것이 아니라, UCM과 유사하게, 코히어런트를 유지하지 않는 캐시를 가질 수 있다.

[079] 위에서 간략히 논의한 바와 같이, 마스터 에이전트들, 타겟 에이전트들, 및 스눕 에이전트들을 포함하는 에이전트들은 데이터흐름 패브릭 및 코히어런스 커맨드 및 시그널링 패브릭을 둘러싸는 지능형 코히어런스 제어 로직을 갖도록 구성될 수 있다. 지능형 로직은 코히어런트 전달 통신들에 대한 레이턴시를 감소시키면서 코히어런트 및 비-코히어런트 통신 트랜잭션들의 시퀀싱을 제어하도록 구성된다. 예를 들어, 도 1을 참조하면, 코히어런스 로직은 정규 마스터 에이전트 및 제 1 캐시 호스트 시스템 마스터 지적 재산 코어에 대한 스눕 에이전트를 포함하는 하나 이상의 에이전트들에서 로케이팅된다. 제 1 캐시 코히어런트 마스터 지적 재산 코어는, 정규 마스터 에이전트가 제 1 포트이고 스눕 에이전트가 제 2 포트인 2개의 별개의 포트들을 갖는다. 스눕 에이전트는 스눕 코히어런스 트래픽에 대한 커맨드 및 시그널링을 핸들링하도록 구성된 코히어런스 로직을 갖는다. 제 1 캐시 코히어런트 마스터에 대한 스눕 에이전트 포트는 요청들 및 응답들을 논리적으로 트래킹 및 응답하고, 정규 마스터 에이전트는 제 1 캐시 코히어런트 마스터 지적 재산 코어에 대한 데이터 트래픽을 핸들링하도록 구성된다. 지능형 코히어런스 제어 로직은 상호연결 내의 라우터들에서 상호연결 내의 내부의 또는 상호연결의 에지 경계들에서의 에이전트들에서 로케이팅될 수 있다. 지능은 마스터 에이전트로부터의 요청 트래픽과 같은 통신 트래픽을 코히어런트 패브릭 및 시스템 요청 패브릭들로 그리고 스눕 에이전트로부터의 응답 트래픽을 코히어런트 패브릭 및 데이터흐름 응답 패브릭으로 분할할 수 있다. 2개의 별개의 포트들은 상호연결과 IP 코어; 제 1 포트 상의 정규 에이전트 및 제 2 포트 상의 스누핑 에이전트 간의 인터페이스에서 코히어런트 마스터들/개시자들을 위해 존재한다.

[080] 스눕 에이전트(STA)는 스눕 코히어런스 트래픽에 대한 커맨드 및 시그널링을 핸들링하도록 구성된 코히어런스 로직을 가지며, 여기서 그 캐시 코히어런트 마스터에 대한 스눕 에이전트 포트는 스눕 요청들 및 응답들을 논리적으로 트래킹하고 응답한다. 예를 들어, AXI의 맥락에서, 이것은 에이전트가 모든 3개의 채널들을 갖는다는 것을 의미한다. 또한, 버전은 또한 분배된 가상 메시지 트래픽을 핸들링할 수 있다.

[081] 스눕 에이전트 포트는 스눕 요청들 및 응답들을 핸들링하기 위해 상호연결과 인터페이싱하는 캐시 코히어런스 마스터 IP 코어를 위해 부가된다. 스눕 에이전트는 코히어런스 패브릭으로부터의 요청들(데이터를 갖지 않음)을 핸들링한다. 스눕 에이전트 코히어런스 관리자와 상호작용하고 - 이는 스눕 응답 데이터를 요청 캐시 코히어런스 마스터 IP 코어에 포워딩하고나 스눕된 데이터를 드롭한다. 스눕 에이전트는 원래의 요청자에 대한 코히어런스(스눕 응답) 및 비-코히어런트 패브릭들(데이터 리턴) 둘 다에 응답한다. 스눕 에이전트는 스눕 응답들을 핸들링하기 위한 로직을 갖는다.

[082] 2개의 대안들은 파티셔닝: 1) 마스터 에이전트가 코히어런트 트래픽(커맨드들만)을 코히어런트 패브릭에 송신하는 경우 또는 2) 마스터 에이전트가 모든 요청들을 시스템 패브릭에 송신하는 경우로 구현될 수 있는데, 이 시스템 패브릭은 결국 요청들을 코히어런트 패브릭에 라우팅한다. 전자의 주요한 이점은 통상적으로 레이턴시에 민감한 코히어런트 요청들이 더 낮은 레이턴시(w.r.t 수의 홉들 및 트래픽 혼잡 둘 다)를 갖는다는 것이다. 후자의 주요한 이점은 마스터 에이전트에서의 비교적 단순함이며 - FIP는 계속 1-in, 1-out 컴포넌트지만, 전자에서, FIP는 라우팅을 또한 수행하도록 강화되어야 한다(1-in, 2-out).

[083] 도 1을 참조하여 위에서 간략히 논의된 바와 같이, 구조적으로, 상호연결은 서로 협력하도록 구성된 2개의 별개의 패브릭들:1) 데이터 흐름 버스 패브릭 2) 이와 별개로, 캐시 코히어런스 관리자의 유연한 구현으로 커플링되는 그의 코히어런스 커맨드 및 시그널링 패브릭으로 구성된다. 코히어런스 커맨드 및 시그널링 패브릭은 시스템 캐시 코히어런스 방식을 유지하기 위해 시그널링 및 커맨드들을 전달하도록 구성된다. 데이터 흐름 버스 패브릭은 시스템 온 어 칩(100)에서 IP 타겟 메모리 코어와 3개 이상의 마스터 지적 재산 코어들 간의 모든 데이터 트래픽 전달들 및 비-코히어런트 트래픽을 전달하도록 구성된다. 따라서, 코히어런스 커맨드 및 시그널링 패브릭은 코히어런트 트래픽의 비-데이터 부분 - 즉, (데이터 없는) 코히어런트 커맨드 요청들, 스눕 요청들, (데이터 없는)　스눕 응답들을 전달한다. 데이터 흐름 버스 패브릭은 비-코히어런트 트래픽 및 모든 데이터 트래픽을 전달한다. 코히어런스 커맨드 및 시그널링 패브릭 및 데이터 흐름 버스 패브릭은 내부 프로토콜을 통해 통신한다.

[084]도 6은 캐시 코히어런트 관리자에 기초한 스눕 필터의 조직의 실시예의 도면을 예시한다. 스눕-필터 기반 캐시 코히어런스 관리자(602)의 각각의 인스턴스는 SRAM 버퍼, CAM 구조, 또는 다른 저장 구조로서 조직되는 세팅된 양의 저장 엔트리를 가질 수 있다. 각각의 스눕-필터 저장 엔트리는 다음의 필드들: 물리적 어드레스의 서브세트인 태그 id, 존재 벡터(Presence Vector; PV), 소유 백터(Owned Vector; OV), 선택적인 교체 힌트들(replacement hints; RH) 상태를 가질 수 있다.

[085] 캐시 코히어런트 마스터 IP 코어 또는 캐시 코히어런트 마스터 IP 코어들의 그룹 당 1 존재 비트가 있을 수 있다. 존재 벡터는, Cache Coherence Master_i가, 유효 상태(UD, SD, UC, SC 상태들)에 또는 유효하지 않은 상태(I 상태)에서, tagid에 의해 표현되는 관심의 캐시 라인을 갖는지를 표시하는 비트[i]를 갖는 플랫 조직을 갖는다. 플랫 방식은, 캐시 코히어런스 마스터 IP 코어들이 되는 클러스터들의 수가 4-8이 되는 것으로 기대하기 때문에 충분해야 한다. 통상적으로, 이러한 조직은 16개까지의 캐시 코히어런스 마스터 IP 코어들로 스케일링될 수 있다. 캐시 코히어런스 마스터 IP 코어들의 수가 크게 되면(즉, 16 초과), 다수의 상호연결들이 코히어런스를 핸들링할 것이라고 기대된다. 존재 벡터는 이어서 다른 상호연결에 의해 관리되는 캐시 코히어런스 마스터 IP 코어들 중 하나 간에 캐시 라인의 존재를 표시하는, 각각의 상호연결에 대한 부가적인 비트를 가질 것이다. 이 히에라키 조직은 이러한 아키텍처가 아직 개념적이 수준이기 때문에 본 명세서에서 논의되지 않는다.

[086] 소유 벡터는 더티(dirty), 미사용, 소유 등과 같은 상태들을 표시하기 위한 인코딩들을 가질 수 있다.

[087] 따라서, 스눕-필터 기반 캐시 코히어런스 관리자(602)는 UD/SD 라인들에 대한 소유 비트 및 CCM 당 1비트를 갖는 존재 벡터를 갖는 플랫 방식을 이용할 수 있다.

[088] 일 실시예에서, 스눕-필터 기반 캐시 코히어런스 관리자는 타이밍/영역/비용 간의 양호한 트래이드오프를 위해 세트 연관성 CAM 조직을 이용한다. 세팅된 연관성(k) 및 SF 엔트리들의 총 수는 사용자가 구성 가능할 수 있다.

[089] 스눕-필터 기반 캐시 코히어런스 관리자(602)는 백 무효화(back invalidation)를 가정하여 구축된 로직 아키텍처를 이용하고 CCM 캐시에서 용량/충돌 라인들을 무효화하기 위해 AC 캐시 유지 트랜잭션들을 이용할 수 있다.

[090] 스눕-필터 기반 캐시 코히어런스 관리자(602)는: 1)디렉토리 높이(저장 엔트리들의 수) 및 연관성을 포함하는 사용자 구성 가능한 조직을 가지며, 이는 영역을 점유하는 스눕-필터 및/또 코히어런트 통신들의 프로세싱에 부가되는 타이밍 대 백 무효화들의 최소화 간의 트래이드오프이다. 스눕-필터 기반 캐시 코히어런스 관리자는 정밀한 "퇴거(evict)" 정보를 이용할 수 있고, 적절한 크기의 스눕 필터, CCM 캐시들에서 잠재적으로 유효한 라인들의 백 무효화들이 제거될 수 있다.

[091] 스눕-필터 기반 캐시 코히어런스 관리자(602)는 시스템을 파티셔닝하는데 도움을 준다. 스눕-필터는, 그것에 대한 액세스가 용량 또는 충돌 미스를 거의 전혀 발생하지 않도록 조직될 수 있다. 설명의 용이함을 위해, 각각의 캐시 코히어런스 마스터 IP 코어는 최고 레벨 캐시(즉, 12)를 갖는 포괄적 캐시 히에라키를 갖고, L2의 캐시 조직은 모든 캐시 코히어런스 마스터 IP 코어들(c-웨이(way) 세트 연관성, 세트들의 수 = n)에 걸쳐서 동일하다. 캐시 코히어런스 마스터 IP 코어들의 수는 n이라고 하자. 스눕-필터가 k의 저장 엔트리들의 양을 갖도록 조직되는 경우(n= n*c이고, 높이(즉, 행들의 수) = 2임), 스눕 필터에 대한 각각의 비-의무적인 액세스는 히트를 발생시킨다. 이는 이 조직에 있어서, 스눕-필터 액세스가 스눕-필터의 용량 또는 충돌 미스로 인해 하나 이상의 캐시 코히어런스 마스터의 L2의 라인을 무효화할 필요성을 거의 전혀 발생시키지 않을 것이라는 것을 의미한다. 스눕-필터에서 용량 또는 충돌 미스로부터 발생하는 무효화는 백 무효화라 불린다.

[092] 백 무효화들을 초래하지 않는 중앙식 또는 분배된 스눕-필터 기반 캐시 코히어런스 관리자를 구축하는 것은 영역(로직 게이트들) 및 타이밍(높은 연관성) 둘 다에서 고가이지만, L2의 캐시 라인들이 무효화될 필요가 없기 때문에(무효화 비용들은 무효화 레이턴시이고, L2의 교체된 라인이 미래에 캐시 코히어런스 마스터 IP 코어에 의해 필요로 될 것이라는 것이 보다 중요함) 더 높은 성능을 발생시킨다는 것에 주의한다. 스눕-필터 조직은 높이(세트들의 #) 및 폭(연관성) 둘 다가, 적절한 성능-영역-타이밍 트래이드오프들을 위해 그의 코히어런스 방식을 맞춤제작하도록 사용자에 의해 구성 가능하게 되게 허용할 것이다. 사용자는 아래에서 정의된 커버리지 비를 갖는 스눕-필터들의 유효성에 대한 예시적인 측정을 통해 저장 엔트리들의 선택 시에 가이드될 수 있다.

[093] 여기서 #스눕-필터 저장 엔트리들 = 스눕-필터의 엔트리들의 수(즉, k * #행들, 도 X 참조)이고, #L2 캐시 라인들 = c(세트-연관성) * 각각의 캐시 코히어런스 마스터 IP 코어의 #세트들이고, #캐시 코히어런스 마스터들 = 캐시 코히어런스 마스터 IP 코어들의 수이다.

[094] 스눕 필터(Snoop Filter; SF) 동작들은 다음을 포함할 수 있다.

[095] 그의 저장 엔트리의 스눕-필터 기반 캐시 코히어런스 관리자 룩업(602)은 비-스누핑, 배리어 및 DVM에 속하는 것들을 제외한 모든 요청 트랜잭션 타입들에 대해 수행된다. 메모리 업데이트 트랜잭션들에 대해, 어떠한 스눕들도 생성되지 않고; 부가적으로, 퇴거 트랜잭션은 메모리 타겟 IP 코어에 대한 임의의 트랜잭션을 발생시키는 것이 아니라, 스눕-필터 상태 벡터들의 업데이트를 발생시킨다.

[096] 스눕-필터 저장 엔트리 룩업은 히트 또는 미스를 발생시킨다. 먼저, 각각의 트랜잭션 타입에 대한 트랜잭션 흐름은, 히트에 이어 룩업이 미스를 발생시킬 때와 유사한 흐름들이 이어진다고 가정하에 설명된다. 아래에서 주어지는 3개의 흐름 경우 예들에서, 주어진 캐시 코히어런스 마스터 IP 코어[i]로부터의 요청이 있다고 가정한다. 스눕-필터 기반 캐시 코히어런스 관리자(602)에서 시트에 대한 트랜잭션 흐름들은 다음과 같을 수 있다.

[097] 1) 경우 : 캐시 코히어런스 마스터[i]로부터의 무효화 요청 트랜잭션: 무효화 스눕 트랜잭션은 존재 벡터[j] = 1(j ≠ i)인 각각의 캐시 코히어런스 마스터[j]에 송신된다. 단지 존재 벡터[i] = 'b1일 때, 이것은 라인이 다른 캐시들의 임의의 것에 존재하지 않고, 이에 따라 다른 캐시들을 스눕할 필요가 없다는 것을 의미한다.

[098] 무효화 요청 트랜잭션이 또한 데이터 전달을 요구할 때, 다음과 같이 로직에 대해 사용자에게 제시되는 2개의 의미있는 아키텍처가 있다.

[099] 캐시 코히어런스 마스터 IP 코어들은 퇴거 매커니즘을 구현하고, 스눕-필터 기반 캐시 코히어런스 관리자(602)가 상당히 정확하게 유지한다. 스누핑 부분은 "판독 및 무효화" 스눕을, 존재 벡터[j]=1인 편의상 선택된 캐시 코히어런스 마스터[j]에 송신한다. 스누핑 부분은 데이터 전달이 이루어지거나 존재 벡터의 모든 캐시 코히어런스 마스터 IP 코어들이 스누핑될 때까지 이 프로시저를 반복한다. 스누핑된 최초의 캐시 코히어런스 마스터는, SF가 상당히 정확하게 유지되므로 데이터 전달을 발생시킬 가능성이 매우 높다는 것에 주의한다. 어떠한 캐시 코히어런스 마스터 IP 코어도 데이터를 리턴하지 않는 매우 드문 경우들에, 메모리 요청이 이루어진다.

[0100] 제 1 데이터가 리턴된 이후, 1로 세팅된 그의 존재 벡터 비트들을 갖는 캐시 코히어런스 마스터들 중 나머지가 무효화 트랜잭션에 각각 송신된다. 이들 스눕들은 동시에 송신되고, 트랜잭션 레이턴시 임계 경로에 있지 않는다.

[0101] (캐시 코히어런스 마스터들이 퇴거 매커니즘을 구현하지 않을 때, 즉, 이들은 SC 또는 SD에서 캐시 라인들을 묵시적으로 드롭할 때) 스누핑 매커니즘은 어떠한 스눕-필터도 없는 경우와 유사하다는 것에 주의한다.

[0102] 무효화 요청 트랜잭션이 데이터 전달을 요구하지 않을 때(캐시 코히어런스 마스터[i]가 데이터를 갖고 무효화를 단지 요청함), 무효화 스눕들(데이터 전달 없음)이 존재 벡터[i] = 'b1인 캐시 코히어런스 마스터에 송신된다.

[0103] 스눕 응답(들)이 가능한 데이터 전달과 함께 수신된 이후, SF 저장 엔트리는 업데이트되어, 1) 존재 벡터[i] ← 'b1, 모든 다른 비트들은 'b0으로 세팅되고; 2) 소유 벡터 ← 고유 더티('b01); 및 3) 업데이트된 교체 힌트 상태가 된다.

[0104] 2) 경우 : 캐시 코히어런스 마스터[i]로부터 판독 공유 트랜잭션(주의: 존재 벡터[i]는 'b0이 되어야 하고 - 준수 검사(compliance check)로서 이용함): 데이터를 전달하기 위해 로직이 따르도록 사용자에게 제시되는 2개의 의미있는 아키텍처 옵션들이 있다.

[0105] 캐시 코히어런스 마스터 IP 코어들은 퇴거 매커니즘을 구현하고, 스눕-필터 기반 캐시 코히어런스 관리자(602)를 상당히 정확하게 유지한다. 스누핑 매커니즘은 "판독 공유" 스눕을, 존재 벡터[j] = 1인 편의상 선택된 캐시 코히어런스 마스터[j]에 송신한다. 캐시 코히어런스 마스터[j]가 데이터를 갖지 않는 경우, 스누핑 매커니즘은, 데이터 전달이 이루어지거나 존재 벡터 비트 위치 = 'b1인 모든 캐시 코히어런스 마스터들이 스눕될 때까지 이 프로시저를 반복한다. 스눕된 최초의 캐시 코히어런스 마스터는, 스눕-필터 기반 캐시 코히어런스 관리자가 상당히 정확하게 유지되므로 데이터 전달을 발생시킬 가능성이 매우 높다는 것에 주의한다. 어떠한 캐시 코히어런스 마스터도 데이터를 리턴하지 않는 매우 드문 경우에, 메모리 요청이 이루어진다.

[0106] 캐시 코히어런스 마스터들이 퇴거 매커니즘은 구현하지 않을 때, 즉 이들이 SC 또는 SD를 암묵적으로 드롭할 때, 스누핑 매커니즘은 어떠한 스눕-필터도 없을 때의 경우와 유사하다.

[0107] 스눕 응답(들)이 가능한 데이터 전달과 함께 수신될 때, SF 엔트리가 업데이트되어, 1) 존재 벡터[i] ← 'b1 /*(주의: 스눕 응답(들)은 SF가 스눕된 캐시 코히어런스 마스터로부터 최근 업데이트된 값을 획득하므로 존재 벡터가 업데이트되게 할 수 있음) 2) 이전의 소유 벡터 상태가 고유 더티 또는 공유 더티였던 경우 소유 벡터 ← 공유 더티('b11) 및 2b) 이전의 소유 벡터가 소유되지 않음(Not Owned)이었던 경우 소유 벡터 ← 공유 더티('b11); 3) 업데이트되는 교체 힌트 상태가 된다.

[0108] 3) 경우: 캐시 코히어런스 마스터[i]로부터 기록백 / 기록클린 /퇴거 트랜잭션(주의:WB/WC에 대해, 소유된 벡터는 공유 더티 또는 고유 더티 중 어느 하나가 되어야 하고; 소유 벡터가 고유 벡터인 경우, 존재 벡터는 하나의 핫(hot)이 되어야 하고, 그렇지 않으면 존재 벡터는 적어도 'b1로 세팅된 그의 벡터의 엘리먼트를 갖고, 퇴거를 위해, 존재 벡터가 하나의 핫(즉, PV[i] = 'b1)인 경우, 소유 벡터는 ≠ 소유되지 않음 이다.

[0109] 프로토콜들을 위해 위의 조건들의 이용은 : 1) 존재 벡터[i[ ← 'b1; 소유 벡터 ← 소유되지 않음(WB 및 소유 벡터가 = 고유 더티 또는 공유 더티인 경우), 2) 소유 벡터 ← 소유되지 않음 (WC인 경우) 및 3) 존재 벡터 [i] ← 'b0 (퇴거인 경우)를 검사한다.

[0110] 도 7a 및 도 7b는 디렉토리-기반 캐시 코히어런스 관리자, 스눕-기반 캐시 코히어런스 관리자 및 스눕-필터 기반 캐시 코히어런스 관리자 중 어느 하나를 지원하기 위해 표준 인터페이스에 대한 예시적인 내부 트랜잭션 흐름을 갖는 테이블을 예시한다.

[0111] 도 7a는 모든 요청 메시지 채널들 및 각각의 채널과 연관된 관련된 세부사항들을 나열하는 예시적인 테이블(700a)을 도시한다. 메시지 채널들은 이어서 제품 아키텍처의 적절한 "캐리어들" - 예를 들어, PL 기반 구현에서 가상 채널들에 맵핑된다. 이 맵핑은 1대1(높은 성능) 또는 다대1(영역 효율을 위해)일 수 있다. 판독 요청을 주로 별개의 메시지 채널들로 분리하는데, 이는 이들이 상이한 에이전트들(TA, CM)을 향하기 때문이다. 코히어런트 기록 백들을 커맨드 전용(only)(코히어런트 관리자로 향함) 및 정규 네트워크를 이용하는 데이터를 갖는 커맨드로 분리한다. (정규 네트워크를 이용하는) 비-코히어런트 기록들에 대한 부가적인 메시지 채널들을 더한다.

[0112] 도 7b는 모든 응답 메시지 채널들 및 각각의 채널과 연관되는 관련된 세부사항들을 나열하는 예시적인 테이블(700b)을 도시한다. 표준 인터페이스는 상이한 메시지 클래스들로부터의 트래픽을 결합한다. Coh_ACK 클래스로부터의 메시지들은 임의의 다른 메시지 클래스로부터의 메시지들과 결합되어야 한다. 이는 데드록/스타베이션(starvation)을 방지한다. VCs로 구현될 때, 이는 Coh_ACK 메시지 클래스가 코히어런스 관리자 경로로 마스터 에이전트를 가로지르기 위해 전용 가상 채널을 가져야 한다는 것을 의미한다. 표준 인터페이스는 별개의 채널들 상에 RACK들 및 WACK들을 가질 수 있으며, 이는 트랜잭션 할당해제를 위해 CM에 대한 빠른 트랙을 요구하여, "충돌 횟수"를 최소화하고, 어드레스 룩업을 또한 요구하지 않는다.

[0113] Coh_Rd, Coh_Wb, NonCoh_Rd, 및 NonCoh_Wr로부터의 메시지들이 모두 결합될 수 있다(즉, 프로토콜 데드록들을 야기하지 않고 하나 이상의 가상 채널을 횡단함). 마스터 에이전트-코히어런스 관리자(코히어런스 패브릭을 이용함) 및 마스터 에이전트 - TA(시스템 패브릭을 이용함) 경로들이 분리되므로, 표준 인터페이스는 코히어런스 및 비-코히어런스 요청 트래픽을 별개의 가상 채널들로 분리한다. 표준 인터페이스는, 이들이 상이한 에이전트들(IA, STA)로 향하기 때문에, 주로 스눕 응답 및 데이터를 갖는 스눕 응답에 대해 별개의 채널들을 가질 수 있다.

[0114] 시스템 캐시 코히어런스 지원은 기능적으로 다수의 이점들을 제공한다. 몇몇 상호연결들에서의 트랜잭션들은 비교적 단순한 흐름을 갖고 - 요청은 단일 타겟으로 지향되고 그 타겟으로부터 응답을 획득한다. 이 문서는 비교적 복잡한 트랜잭션 흐름들의 상세된 예들 및 특정한 캐시된 마스터에서 데이터의 가용성에 동적으로 기초하여 흐름이 어떻게 변하는지를 보여준다. 이 트랜잭션 흐름들이 다수의 파라미터들; 예를 들어, 레이턴시, 대역폭, 전력, 구현 및 검증 복잡도를 최적화하기 위해 시퀀싱되는데 있어 다수의 이점들이 있다.

[0115] 일반적으로, 상호연결 네트워크에서, 다수의 이종의 개시자 에이전트들(IA들) 및 타겟 에이전트들(TA들) 및 라우터들이 있다. 패킷이 요청 네트워크에서 IA들로부터 TA들로 이동할 때, 그의 폭은 링크 폭 변환이라 지칭되는 동작들에 의해 조정될 수 있다. 동작들은 개별 서브필드들을 조사할 수 있으며, 이는 타이밍 지연을 야기하고 복잡한 로직을 요구할 수 있다.

[0116] 설계는 스마트 전화들, 서버들, 셀 전화 타워, 라우터들 및 다른 이러한 전자 장비에서 이용될 수 있다. 플러그-인 캐시 코히어런스 관리자, 에이전트들의 코히어런스 로직 및 분할된 상호연결 설계는 주로 인터페이싱하지만 물리적으로 디커플링되는 "코히어런스" 및 "비-코히어런스" 부분들을 유지한다. 이는 모든 이러한 부분들이 독립적인 최적화, 개발 및 비준을 돕는다.

시뮬레이션 및 모델링

[0117] 도 8은 본 명세서에 설명된 시스템들과 방법들에 따라서, 시스템-온-어-칩과 같은, 디바이스를 생성하기 위한 프로세스의 예의 실시예의 흐름도를 예시한다. 상호연결 및 메모리 스케줄러의 설계들을 갖는 디바이스를 발생하기 위한 예시적인 프로세스는 전자 설계 자동화(EDA) 툴셋의 일부를 형성하기 위해, 시스템-온-어-칩 컴파일러와 같은, 전자 회로 설계 발생기를 활용할 수 있다. 하드웨어 로직, 코딩된 소프트웨어, 그리고 둘의 조합이 EDA 툴셋의 실시예를 이용한 후속하는 설계 프로세스 단계들을 구현하기 위해 사용될 수 있다. 이와 같은 EDA 툴셋은 단일 툴 또는 둘 또는 둘을 초과하는 별개의 툴들의 모음일 수 있다. 상호연결 메모리 스케줄러, 등의 회로를 위한 장치들 및/또는 방법들을 나타내는 정보가 셀 라이브러리, 전자 회로 설계 발생기내 소프트 명령들, 또는 이러한 정보를 저장하는 유사한 머신-판독가능 저장 매체와 같은 인스턴스에 포함될 수 있다. 머신-판독가능 저장 매체 상에 저장된 장치들 및/또는 방법들을 나타내는 정보는 장치들을 생성하는 프로세스, 또는 시뮬레이션들 및 리소그라픽 마스크들과 같은 장치 및/또는 본 명세서에 설명된 방법들과 같은 방법들의 모델 표현들에 사용될 수 있다.

[118] 상기 설계의 양상들은 스케줄러와 상호연결 그리고 연관된 부분들을 구성하는 컴포넌트들을 위한 설계들의 세트를 포함하는 소프트웨어 라이브러리의 일부일 수 있다. 라이브러리 셀들은 산업 표준들에 따라서 개발된다. 설계 엘리먼트들을 포함하는 파일들의 라이브러리는 EDA 툴셋의 일부일 뿐만 아니라 그 자체 독립형 프로그램일 수 있다.

[119] EDA 툴셋은, 기타 기능들 뿐만 아니라, 입력 및 출력 데이터, 제어, 디버그 및 테스트 흐름들을 통합적으로 관리하는 고도로 구성가능하고, 스케일러블한 시스템-온-어-칩(SoC) 인터 블록 통신 시스템을 만들기 위해 사용될 수 있다. 실시예에서, 예시적인 툴셋은 다음을 포함할 수 있다: 그래픽 사용자 인터페이스; 프로세싱 엘리먼트들의 공통 세트; 그리고 EDA 툴셋을 정의하는 회로들, 제어 로직, 그리고 셀 어레이들과 같은 설계 엘리먼트들을 포함하는 파일들의 라이브러리. EDA 툴셋은 회로 설계를 발생하고, 설계를 테스트하며, 그리고/또는 타겟 칩 위 활용가능한 공간에 설계의 레이아웃을 배치하기 위한 다중 알고리즘들과 설계들로 구성된 하나 또는 하나를 초과하는 소프트웨어 프로그램들일 수 있다. EDA 툴셋은 실행가능한 소프트웨어 프로그램들의 세트에 객체 코드를 포함할 수 있다. EDA 툴셋의 어플리케이션-특정 알고리즘들과 인터페이스들의 세트는 개별적인 IP 코어 또는 특정한 어플리케이션을 위한 IP 코어들의 전체 시스템을 신속하게 생성하기 위해 시스템 집적 회로(IC) 적분기들에 의해 사용될 수 있다. EDA 툴셋은 타이밍도들, 전력 그리고 각각의 컴포넌트의 영역 양상들을 제공하며 실제 동작과 구성 시뮬레이션들을 구동하기 위해 컴포넌트들을 표시하도록 코딩된 모델들과 함께 시뮬레이트된다. EDA 툴셋은 타겟 칩 위 활용가능한 공간에 꼭 맞도록 타겟된 네트리스트(netlist)와 레이아웃을 발생할 수 있다. EDA 툴셋은 또한 머신-판독가능 저장 매체에 상호연결 및 로직 회로를 표시하는 데이터를 또한 저장할 수 있다. 머신-판독 가능한 매체는 데이터 명령들이 저장되어 있을 수 있고, 이 데이터 및 명령들은 머신에 의해 실행될 때, 머신으로 하여금 위에서 설명됨 물리적 컴포넌트의 표현을 생성하게 한다. 이 머신-판독 가능한 매체는 시스템 온 어 칩 설계 프로세스에서 이용되는 EDA(Electronic Design Automation) 툴셋을 저장하고, 툴들은 이 설계에 대한 다른 기능들을 예시하고, 검증하고, 시뮬레이팅하고, 실행하기 위해 이들 컴포넌트들의 표현을 생성하기 위한 데이터 및 명령들을 갖는다. 비-일시적인 컴퓨터 판독 가능한 저장 매체는 명령들을 포함하며, 이 명령들은 머신에 의해 실행될 때, 머신으로 하여금 이 명령들이 장치의 소프트웨어 표현을 생성하게 하도록 구성된다.

[120] 일반적으로, EDA 툴셋은 SOC 설계의 2개의 메이저 스테이지들에서 사용된다: 프론트 엔드 프로세싱과 백 엔드 프로그래밍. EDA 툴셋은 RTL 발생기, 로직 합성 스크립트들, 완전 입증 테스트벤치(full verification test), 그리고 시스템C 모델들 중 하나 또는 하나를 초과하여 포함할 수 있다.

[121] 프론트 엔드 프로세싱은 설계 및 아키텍처 스테이지들을 포함하며, 이는 도식적인 SOC의 설계를 포함한다. 프론트 엔드 프로세싱은 연결 모델들, 설계의 구성, 그리고 아키텍처 탐색 동안 설계의 시뮬레이팅, 테스팅, 그리고 튜닝을 포함할 수 있다. 설계는 전형적으로 시뮬레이트되고 테스트된다. 프론트 엔드 프로세싱은 전통적으로 SOC내 회로들의 시뮬레이션과 회로들이 정확히 작동해야 한다는 입증을 포함한다. 그 다음 테스트되고 입증된 컴포넌트들이 독립형 라이브러리의 일부 또는 칩상의 IP 블록들의 일부로서 저장될 수 있다. 프론트 엔드 뷰들은 문서화, 시뮬레이션, 디버깅, 그리고 테스팅을 지원한다.

[122] 블록(1305)에서, EDA 툴셋은 구성 파라미터들을 설명하는 데이터를 갖는 사용자-공급형 테스트 파일과 스레드내 그리고 다중 스레드들에 걸쳐서 매-스레드와 매-태그 메모리 액세스 스케줄링을 동시에 수행하도록 구성된 태그 로직의 적어도 일부를 위한 설계를 수신할 수 있다. 데이터는 그러한 IP 블록을 위해 하나 또는 하나를 초과하는 구성 파라미터들을 포함할 수 있다. IP 블록 상세한 설명은 상호연결, 메모리 스케줄러, 등과 같은 그러한 IP 블록의 전체적인 기능일 수 있다. 상호연결 IP 블록과 스케줄러를 위한 구성 파라미터들은 앞서 설명된 바와 같은 파라미터들을 포함할 수 있다.

[123] EDA 툴셋은 그러한 IP 블록의 컴포넌트 레벨 제조, 그러한 기술에서 셀에 의해 점유된 크기의 추정, 그러한 기술에서 구현된 컴포넌트 레벨 로직의 동작 전압, 그러한 기술에서 표준 셀들을 위한 평균 게이트 지연, 등을 구현하기 위한 제조 프로세스와 같은 사용자-공급형 구현 기술 파라미터들을 수신한다. 기술 파라미터들은 의도된 구현 기술의 요약을 기술한다. 사용자-공급형 기술 파라미터들은 문자 설명이거나 단지 알려진 가능성의 범위에 응답하여 제출된 값일 수 있다.

[124] EDA 툴셋은 IP 블록 설계를 형성하는 각각의 IP 서브 컴포넌트를 위한 개략적인 실행가능한 표시를 생성함으로써 IP 블록 설계를 분할할 수 있다. 개략적인 실행가능한 표시는 각각의 IP 서브 컴포넌트를 위한 TAP 특성들을 모델로 하며 실제 IP 블록 설계의 특성들과 유사한 특성들을 모방한다. 모델은 그러한 IP 블록의 하나 또는 하나를 초과하는 행동 특성들에 집중할 수 있다. EDA 툴셋은 IP 블록 설계의 일부 또는 전부의 모델들을 실행한다. EDA 툴셋은 그러한 IP 블록의 모델이된 행동 특성들의 결과들을 요약하고 보고한다. EDA 툴셋은 또한 어플리케이션의 성능을 분석하고 사용자가 IP 블록 설계의 새로운 구성 또는 새로운 기술 파라미터들을 이용한 기능 설명을 공급하도록 허용할 수 있다. 사용자가 IP 설계 파라미터들과 기술 파라미터들 구동(run)의 공급형 구성의 반복들 중 하나의 성능 결과들에 만족한 후, 사용자는 자신의 연관된 기술 파라미터들과 함께 궁극적인 IP 코어 설계를 정할 수 있다.

[125] EDA 툴셋은 IP 블록을 위한 합성 스크립트들을 발생하기 위해 개략적인 실행가능한 표시들로부터의 결과들과 잠재적으로 추가적인 정보를 통합한다. EDA 툴셋은 전체적인 성능 및 영역 추정들의 결과가 사용자에게 제공된 후 IP 블록을 위한 다양한 성능 및 영역 목적들을 설정하기 위해 합성 스크립트들을 공급할 수 있다.

[126] EDA 툴셋은 또한 사용자 공급형 구성 파라미터들과 구현 기술 파라미터들에 기초하여 로직 합성을 위해 그러한 IP 블록 설계의 RTL 파일을 발생할 수 있다. 논의된 바와 같이, RTL 파일은 레지스터들, 불 방정식들, "if-then-else" 명령문들과 같은 제어 로직, 그리고 복잡한 이벤트 시퀀스들의 집합으로 전자 회로들을 설명하는 높은-레벨 하드웨어 상세한 설명일 수 있다.

[127] 블록(1310)에서, ASIC 또는 SOC 칩 설계에서 분리된 설계 경로는 통합 스테이지로 불리운다. IP 블록들의 시스템의 통합은 그러한 IP 블록을 위한 합성 스크립들과 IP 블록의 RTL 파일의 발생과 동시에 일어날 수 있다.

[128] EDA 툴셋은 설계 작업들의 동작을 정확히 시뮬레이트하고 입증하기 위해 회로들과 로직 게이트들의 설계들을 제공할 수 있다. 시스템 설계자는 함께 작동하도록 IP 블록들의 시스템을 코딩한다. EDA 툴셋은 기능적으로 테스트되고, 타이밍 테스트되며, 디버그되고 실증될 수 있는 상기 설명된 회로들의 표시들의 시뮬레이션들을 발생한다. EDA 툴셋은 IP 블록의 행동의 시스템을 시뮬레이트한다. 시스템 설계자는 IP 블록의 행동의 시스템을 입증하고 디버그한다. EDA 툴셋은 IP 코어 툴을 패키지한다. 머신-판독가능 저장 매체는 또한 외부 테스트기를 위한 명령들을 발생하기 위한 테스트 발생 프로그램과 본 명세서에 설명된 테스트들을 위한 테스트 시퀀스들을 구동하기 위한 상호연결을 위한 명령들을 또한 저장할 수 있다. 전자 설계 자동화의 당업자는 설계 엔지니어가 유형의 유용한 정보 및/또는 결과들을 발생하는데 도움을 주기 위해, 소프트웨어 코딩된 모델들과 같은, 상이한 표시들을 생성하고 사용한다는 것을 안다. 이들 표시들 중 많은 표시들이 (개략적이고 덜 상세한) 하이-레벨이거나 평면도들일 수 있으며 시스템 레벨로부터 시작하는 전자 설계를 최적화하는 것을 돕기 위해 사용될 수 있다. 게다가, 설계 프로세스는 통상적으로 단계들로 나누어질 수 있으며 각각의 단계의 끝에서, 단계에 대한 맞춤형 표시가 통상적으로 출력으로서 발생되며 다음 단계에 의해 입력으로서 사용된다. 숙련된 엔지니어들은 이들 표시들을 이용할 수 있으며 죄종 단계로부터 나오는 최종 결과들의 품질을 개선하기 위해 경험적인 알고리즘들을 적용할 수 있다. 이들 표시들은 전자 설계 자동화 세계가 회로들을 설계하고, 회로들을 테스트하고 입증하며, 회로의 네트리스트로부터 리소그라픽 마스크를 이끌어내며 그리고 다른 유사한 유용한 결과들을 이끌어내는 것을 허용한다.

[129] 다음으로, 블록(1315)에서, 시스템 통합은 집적 회로 설계 프로세스에서 일어날 수 있다. 백 엔드 프로그래밍은 일반적으로 컴포넌트들 간의 모든 금속선들의 라우팅뿐만 아니라, 칩 레이아웃위 회로 엘리먼트들의 배치 및 라우팅, 또는 플로어 플래닝(floor planning)과 같은 SOC의 물리적인 레이아웃의 프로그래밍을 포함한다. 레이아웃, 물리적인 라이브러리 교환 포맷(Library Exchange Format : LEF), 등과 같은 백 엔드 파일들은 레이아웃과 제조를 위해 발생된다.

[130] 발생된 디바이스 레이아웃은 칩을 위한 레이아웃의 나머지와 통합될 수 있다. 로직 합성 툴은 IP 코어와 IP 코어들의 RTL 설계 파일을 위한 합성 스크립트들을 수신한다. 로직 합성 툴은 또한 셀 라이브러리로부터 설계시 사용된 로직 게이트들의 특성들을 수신한다. RTL 코드는 IP 블록들의 시스템을 포함하는 SOC를 예시하기 위해 발생될 수 있다. 고정 RTL 및 합성 스크립트들과 함께 IP 블록들의 시스템은 시뮬레이트되고 입증될 수 있다. 레지스터 전달 레벨(Register Transfer Level : RTL)과 함께 설계의 합성이 일어날 수 있다. 로직 합성 도구는 게이트 레벨 네트리스트 회로 설계(즉, IP 서브 컴포넌트 블록들의 전부를 형성하는 개별적인 트랜지스터들과 로직 게이트들의 상세한 설명)를 생성하기 위해 RTL 설계를 합성한다. 설계는 베리로그(Verilog) VHDL(초고속 집적 회로 하드웨어 상세설명 언어(Very-High-Speed Integrated Circuit Hardware Description Language)) 또는 SPICE(집적 회로 강조를 위한 시뮬레이션 프로그램(Simulation Program for Integrated Circuit Emphasis))와 같은 하나 또는 하나를 초과하는 하드웨어 설계 언어들(HDL)의 네트리스트내로 출력될 수 있다. 네트리스트는 또한 설계에 포함된 컴포넌트들, 각각의 컴포넌트의 속성들 그리고 컴포넌트들 중 상호연결성과 같은 전자 설계의 연결성을 설명할 수 있다. EDA 툴셋은 칩위의 XY 좌표와 같은 칩위에서 활용가능한 공간에 컴포넌트 배치를 위한 제약들의 추가를 포함하는 컴포넌트들의 플로어 플래닝을 용이하게 하고, 그들 컴포넌트들을 위해 금속 연결들을 라우트한다. EDA 툴셋은 제조동안 칩위로 회로 설계를 전달하기 위해 IP 코어의 이러한 표시로부터 발생될 리소그라픽 마스크들을 위한 정보, 또는 상기 설명된 회로들의 기타 유사한 유용한 도출들을 제공한다. 따라서, 백 엔드 프로그래밍은 백 엔드 프로그래밍이 물리적으로 제조가능하며 결과적인 SOC가 임의의 기능-방해 물리적 결함들을 갖지 않을 것이라는 것을 입증하기 위해 레이아웃의 물리적인 입증을 더 포함할 수 있다.

[131] 블록(1320)에서, 제조 설비는 EDA 툴셋의 회로 설계 및 레이아웃으로부터 발생된 리소그라픽 마스크들을 활용한 신호 발생 회로와 함께 하나 또는 하나를 초과하는 칩들을 제조할 수 있다. 제조 설비들은 칩들을 제조하기 위해 1.0um, 0.50um, 0.35um, 0.25um, 0.18um, 0.13um, 0.10um, 90nm, 65nm, 또는 보다 작은 것과 같은 최소선 폭들을 갖는 표준 CMOS 로직 프로세스를 이용할 수 있다. 전형적으로 활용된 CMOS 로직 프로세스의 크기는 리소그라픽 마스크들을 이용해 칩상에 제조될 수 있는 가장 작은 최소 리소그라픽 치수를 정의하며, 이것은 차례로, 최소 컴포넌트 크기를 결정한다. 일 실시예에 따르면, X-선들과 극자외선을 포함하는 빛이 테스트 회로를 위한 회로 설계와 레이아웃을 칩 자체 위로 전달하기 위해 칩위로 이들 리소그라픽 마스크들을 통과할 수 있다.

[132] EDA 툴셋은 그래픽 사용자 인터페이스를 위한 구성 다이얼로그 플러그-인들을 가질 수 있다. EDA 툴셋은 SocComp를 위해 RTL 발생기 플러그-인을 가질 수 있다. EDA 툴셋은 SocComp를 위한 SystemC 발생기 플러그-인을 가질 수 있다. EDA 툴셋은 RTL 시뮬레이션에 포함될 수 있는 컴포넌트들에 대한 유닛-레벨 입증을 수행할 수 있다. EDA 툴셋은 테스트 검증 테스트벤치 발생기를 가질 수 있다. EDA 툴셋은 가상 및 하드웨어 디버그 포트 트레이스 파일들을 위해 디스-어셈블러를 가질 수 있다. EDA 툴셋은 오픈 코어 프로토콜 표준들을 따를 수 있다. EDA 툴셋은 트랜잭터 모델들, 번들 포로토콜 체커들, 소켓 활동을 디스플레이하기 위한 OCPDis2, 번들의 성능을 분석하기 위한 OCPPer2 및 기타 유사한 프로그램들을 가질 수 있다.

[133] 논의된 바와 같이, EDA 툴셋은 머신-판독가능 매체상에 저장된, 하나의 프로그램내 소프트웨어 셀 라이브러리와 함께 실행가능한 프로그램으로 이루어진 EPA 툴셋 또는 기타 프로그램들이라 칭할 수 있는 소프트웨어 라이브러리내 인스턴스와 같은, 데이터와 명령들의 세트로서 소프트웨어로 구현될 수 있다. 머신-판독가능 저장 매체는 머신(예를 들어, 컴퓨터)에 의해 판독가능한 형태로 정보를 저장하는 임의의 메커니즘을 포함할 수 있다. 예를 들어, 머신-판독가능한 매체는 판독 전용 메모리(ROM); 랜덤 액세스 메모리(RAM); 자기 디스크 저장 매체; 광 저장 매체; 플래시 메모리 디바이스들; DVD들; EPROM들; EEPRM들; 플래시, 자기 또는 광 카드들; 또는 천이 시간의 기간 초과하여 전자 명령들을 저장하기에 적합한 임의의 다른 형태의 매체를 포함하지만, 이에 제한되지 않는다. 명령들과 동작들은 또한 머신-판독가능 매체가 저장되고/되거나 하나를 초과하는 컴퓨터 시스템에 의해 실행되는 분산 컴퓨팅 환경에서 실행될 수 있다. 게다가, 컴퓨터 시스템들 간에 전달된 정보는 컴퓨터 시스템들을 연결하는 통신 매체에 걸쳐서 끌리거나 밀릴 수 있다.

[134] 상기 상세한 설명들의 몇몇 부분들은 컴퓨터 메모리내에 데이터 비트들에 대한 동작들의 알고리즘들과 부호표시들에 관하여 제공된다. 이들 알고리즘적인 상세한 설명들과 표시들은 그들의 작업의 본질을 다른 당업자에게 가장 효과적으로 전달하기 위해 데이터 프로세싱 기술의 당업자에 의해 사용된 수단이다. 알고리즘은 여기서, 그리고 일반적으로, 원하는 결과를 초래하는 동작들의 일관성있는 시퀀스일 것으로 간주된다. 동작들은 물리적인 양들의 물리적인 조작들을 요구하는 동작들이다. 통상적으로, 비록 반드시 필요한 것은 아니라고 하더라도, 이들 양들은 저장되고, 전달되며, 조합되고, 비교되며, 그리고 그렇지 않으면 조작될 수 있는 전기 또는 자기 신호들의 형태를 취한다. 예를 들어, CDF로부터 또는 이 CDF로의 메시지들의 인코딩 및 디코딩은 하드웨어, 소프트웨어 또는 하드웨어 및 소프트웨어 둘 다의 결합으로 수행될 수 있다. 주로 보편적인 용법상 이들 신호들을 비트들, 값들, 엘리먼트들, 부호들, 문자들, 용어들, 숫자들, 등으로 지칭하는 것이 때때로 편리하다는 것이 입증되었다.

[135] 비록 본 발명의 몇몇 특정한 실시예들이 도시되었지만 본 발명은 이들 실시예들에 제한되지 않을 것이다. 본 발명은 본 명세서에 설명된 특정한 실시예들에 의해 제한되지 않고, 첨부된 청구항들의 범위에 의해서만 제한되는 것으로서 이해될 것이다.

Claims (20)

1. 장치로서,
   시스템 온 어 칩(System on a Chip)에서 캐시 코히어런트 마스터 지적 재산 코어(cache coherent master intellectual property core)들의 양을 스케일링하는 시스템 온 어 칩에 대한 스케일러블 캐시 코히어런스 방식(scalable cache coherence scheme)을 제공하도록 구성되는 시스템 온 어 칩을 위한 플러그-인 캐시 코히어런스 관리자, 하나 이상의 에이전트들의 코히어런스 로직 및 상호연결을 포함하고,
   상기 플러그-인 캐시 코히어런스 관리자 및 코히어런스 로직은 제 1 캐시 코히어런트 마스터 지적 재산 코어에 대한 제 1 로컬 메모리 캐시 및 제 2 캐시-코히어런트 마스터 지적 재산 코어에 대한 제 2 로컬 메모리 캐시를 포함하는 하나 이상의 로컬 메모리 캐시들에 저장되는 메모리 데이터의 일관성(consistency)을 유지하고,
   상기 제 1 및 제 2 지적 재산 코어들을 포함하는 2개 이상의 마스터 지적 재산 코어들은 상기 상호연결을 통해 판독 또는 기록 통신 트랜잭션들을 IP 타겟 메모리 코어는 물론, 상기 시스템 온 어 칩 내의 제 3 지적 재산 코어에 송신하도록 구성되고,
   상기 제 3 지적 재산 코어는 상기 상호연결을 통해 판독 또는 기록 통신 트랜잭션을 상기 IP 타겟 메모리 코어에 송신하도록 또한 구성되는 비-캐시-코히어런트 마스터 지적 재산 코어인,
   장치.
2. 제 1 항에 있어서,
   상기 상호연결은,
   1) 데이터 흐름 버스 패브릭(data flow bus fabric) 및 2) 상기 데이터 흐름 버스 패브릭와 별개로, 캐시 코히어런스 관리자의 유연한 구현으로 커플링되는 그의 코히어런스 커맨드 및 시그널링 패브릭으로 구성되고,
   상기 코히어런스 커맨드 및 시그널링 패브릭은 상기 시스템 캐시 코히어런스 방식을 유지하기 위해 시그널링 및 커맨드들을 전달하도록 구성되고,
   상기 데이터 흐름 버스 패브릭은 비-코히어런트 트래픽 및 상기 시스템 온 어 칩 내의 3개 이상의 마스터 지적 재산 코어들과 상기 IP 타겟 메모리 코어 간의 모든 데이터 트래픽 전달들을 전달(carry)하도록 구성되는,
   장치.
3. 제 1 항에 있어서,
   상기 플러그-인 캐시 코히어런스 관리자는,
   1) 스누핑-기반 캐시 코히어런스 관리자, 2) 스눕-필터링-기반 캐시 코히어런스 관리자 및 3) 분배된 디렉토리-기반 캐시 코히어런스 관리자 중 임의의 하나로서 구현되고, 상기 캐시 코히어런스 관리자를 위한 로직 블록은 상기 상호연결 및 상기 에이전트들의 코히어런스 로직을 변경함 없이 위의 3개의 시스템 코히어런스 방식들 중 하나를 지원하기 위해 상기 로직 블록 내의 다양한 하드웨어 컴포넌트들에 플러그 인할 수 있는,
   장치.
4. 제 3 항에 있어서,
   상기 플러그-인 캐시 코히어런스 관리자는 상기 코히어런트 커맨드 및 시그널링 패브릭과 상기 캐시 코히어런스 관리자의 로직 블록 간의 경계에서 표준 인터페이스를 통해 상기 3개의 시스템 코히어런스 방식들 중 임의의 것을 지원하고,
   상기 표준 인터페이스는 다양한 시스템 코히어런스 방식들의 지원을 가능하게 하기 위해 상이한 형태들의 로직이 상기 캐시 코히어런스 관리자의 로직 블록에 플러깅되도록 허용하는,
   장치.
5. 제 3 항에 있어서,
   상기 플러그-인 캐시 코히어런스 관리자는 상기 시스템 온 어 칩에서 상기 캐시 코히어런트 마스터 IP 코어들을 위해 상기 제 1 로컬 메모리 캐시의 캐시 액세스를 모든 다른 로컬 메모리 캐시들에 그리고 그 반대로 브로드캐스트하도록 코히어런스 로직과 협력하는 스눕-기반 캐시 코히어런스 관리자로서 구현되고,
   상기 스눕-기반 캐시 코히어런스 관리자는 스누핑을 위해 스눕 브로드캐스트 방식에 의존하고 캐시 코히어런트 마스터 IP 코어들 및 임의의 캐시되지 않은 코히어런트 마스터 IP 코어들 둘 다를 지원하는,
   장치.
6. 제 3 항에 있어서,
   상기 플러그-인 캐시 코히어런스 관리자는, 그들이 캐시한 메모리 위치들에 대한 액세스를 위해 개별 캐시들을 관리하도록 상기 코히어런스 로직과 협력하는 단일 스눕 필터-기반 캐시 코히어런스 관리자로서 구현되고,
   스눕-필터는 각각의 엔트리가 하나 이상의 노드들에 의해 소유되는 캐시 라인을 표현하는 복수의 엔트리들을 유지함으로써 스누핑 트래픽을 감소시키고,
   상기 캐시 코히어런스 마스터 IP 코어들은 코히어런스 커맨드 및 시그널링 패브릭을 통해 상기 단일 스눕 필터-기반 캐시 코히어런스 관리자와 통신하고,
   상기 스눕 필터-기반 캐시 코히어런스 관리자는 모든 로컬 캐시 메모리들의 캐시 라인 엔트리들의 상태를 결정하기 위해 상기 복수의 엔트리들에 관한 테이블 룩 업(table look up)은 물론, 각각의 로컬 캐시의 캐시 코히어런트 데이터에 관한 상태를 검사하도록 주기적인 스누핑을 수행하는,
   장치.
7. 제 3 항에 있어서,
   상기 플러그-인 캐시 코히어런스 관리자는 적어도 상기 제 1 및 제 2 로컬 메모리 캐시들 간의 코히어런스를 유지하는, 공통 디렉토리에서 공유되는 데이터를 계속 트래킹하는 디렉토리-기반 캐시 코히어런스 관리자로서 구현되고,
   엔트리가 상기 공통 디렉토리에서 변경될 때, 상기 디렉토리는 그 엔트리를 갖는 다른 로컬 메모리 캐시들을 업데이트하거나 무효화하고,
   상기 디렉토리는 각각의 로컬 캐시의 캐시 코히어런트 데이터에 관한 상태를 검사하도록 테이블 룩 업을 수행하고
   상기 디렉토리-기반 캐시 코히어런스 관리자는 코히어런스 커맨드 및 시그널링 패브릭을 통해 서로 통신하는 디렉토리의 2개의 상의 인스턴스들로 구성되는,
   장치.
8. 제 1 항에 있어서,
   상기 플러그-인 캐시 코히어런스 관리자는 3-홉 또는 4-홉 프로토콜 중 어느 하나를 구현하도록 구성된 홉 로직(hop logic)을 갖고,
   상기 4-홉 프로토콜에서, 스눕된 캐시 라인 상태가 먼저 캐시 코히어런트 관리자에게 송신되고, 이어서 상기 코히어런트 관리자는 요청 캐시 코히어런트 마스터 IP 코어로의 데이터의 송신을 배열하는 것을 담당하고, 상기 3-홉 프로토콜은 직접 '캐시-투-캐시(cache-to-cache)' 전달을 지원하고, 상기 캐시 코히어런스 관리자는 또한 상기 시스템 온 어 칩에서 2개 이상의 마스터 IP 코어들 간의 캐시 액세스들을 순서화하도록 구성되는 순서화 로직을 또한 갖는,
   장치.
9. 제 1 항에 있어서,
   상기 플러그-인 캐시 코히어런스 관리자는,
   1) 상기 캐시 코히어런트 마스터들 및 비-캐시 코히어런트 마스터들로부터 캐시 데이터 요청들의 모든 코히어런스를 핸들링하고, 2) 상기 시스템 온 어 칩 내의 2개 이상의 마스터 IP 코어들 간의 캐시 액세스들을 순서화하고, 3) 상기 시스템 온 어 칩에서 2개 이상의 마스터 IP 코어들 간에 충돌들을 해결하고, 4) 스눕 브로드캐스트들을 생성하고 테이블 룩업을 수행하고 5) 추론적 메모리 액세스들을 지원하도록 구성된 로직을 갖는,
   장치.
10. 제 2 항에 있어서,
    상기 하나 이상의 에이전트들의 코히어런스 로직은,
    상기 데이터흐름 패브릭 및 상기 코히어런스 커맨드 및 시그널링 패브릭을 둘러싸고,
    상기 코히어런스 로직은 코히어런트 전달 통신들을 위한 레이턴시를 감소시키면서 상기 코히어런트 및 비-코히어런트 통신 트랜잭션들의 시퀀싱(sequencing)을 제어하도록 구성되는,
    장치.
11. 제 2 항에 있어서,
    상기 코히어런스 로직은 상기 제 1 캐시 코히어런트 마스터 지적 재산 코어를 위한 스눕 에이전트 및 정규 마스터 에이전트를 포함하는 하나 이상의 에이전트들에서 로케이팅되고,
    상기 제 1 캐시 코히어런트 마스터 지적 재산 코어는 2개의 별개의 포트들을 갖고,
    상기 정규 마스터 에이전트는 제 1 포트 상에 있고, 상기 스눕 에이전트는 제 2 포트 상에 있고,
    상기 스눕 에이전트는 스눕 코히어런스 트래픽에 대한 커맨드 및 시그널링을 핸들링하도록 구성된 코히어런스 로직을 갖고,
    상기 제 1 캐시 코히어런트 마스터에 대한 스눕 에이전트 포트는 스눕 요청들 및 응답들을 논리적으로 트래킹 및 응답하고,
    상기 정규 마스터 에이전트는 상기 제 1 캐시 코히어런트 마스터 지적 재산 코어에 대한 데이터 트래픽을 핸들링하도록 구성되는,
    장치.
12. 명령들을 포함하는 비-일시적인 컴퓨터 판독 가능한 저장 매체로서, 상기 명령들은, 머신(machine)에 의해 실행될 때, 상기 머신으로 하여금 제 1 항의 장치의 소프트웨어 표현을 생성하게 하도록 구성되는,
    비-일시적인 컴퓨터 판독 가능한 저장 매체.
13. 다수의 캐시 코히어런트 마스터 IP 코어들 및 캐시되지 않은 코히어런트 마스터 IP 코어들 둘 다와 함께 시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법으로서,
    시스템 온 어 칩(System on a Chip)에서 캐시 코히어런트 마스터 지적 재산 코어(cache coherent master intellectual property core)들의 양을 스케일링하는 시스템 온 어 칩에 대한 스케일러블 캐시 코히어런스 방식을 제공하도록 시스템 온 어 칩을 위한 플러그-인 캐시 코히어런스 관리자, 하나 이상의 에이전트들의 코히어런스 로직 및 상호연결을 이용하는 단계;
    상기 상호연결을 통해 상기 마스터 IP 코어들 중 2개 이상과 통신하는 단계
    를 포함하고,
    상기 마스터 IP 코어들은, 상기 플러그-인 캐시 코히어런스 관리자를 통해 그 마스터 IP 코어에 대한 데이터를 저장하는 적어도 하나의 캐시에 동작 가능하게 커플링되는 적어도 하나의 프로세서를 각각 포함하는 캐시 코히어런트 마스터들이고,
    상기 캐시로부터의 데이터는 또한 메인 메모리 타겟 IP 코어에 영구적으로 저장되고, 상기 메인 메모리 타겟 IP 코어는 상기 메인 메모리 타겟 IP 코어를 공유하는 캐시되지 않은 코히어런트 마스터 IP 코어를 또한 포함하는 다수의 마스터 IP 코어들 간에 공유되고, 상기 플러그-인 캐시 코히어런스 관리자는 상기 캐시들 중 제 1 캐시 상의 캐시 라인의 캐시 미스(cache miss)에 응답하여 캐시 코히어런스를 유지하고, 이어서 상기 제 1 캐시에서 상기 캐시 라인의 캐시 미스에 대응하는 저장된 데이터의 인스턴스에 대한 요청을 브로드캐스트하고,
    각각의 캐시 코히어런트 마스터는 그 자신의 코히어런트 캐시를 유지하고, 각각의 캐시되지 않은 코히어런트 마스터는 코히어런트 및 비-코히어런트 어드레스 공간들에 통신 트랜잭션을 발행하도록 구성되는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.
14. 제 13 항에 있어서,
    상기 상호연결은,
    1) 데이터 흐름 버스 패브릭(data flow bus fabric) 및 2) 데이터 흐름 버스 패브릭와 별개로, 캐시 코히어런스 관리자의 유연한 구현에 커플링되는 그의 코히어런스 커맨드 및 시그널링 패브릭을 이용하고,
    상기 코히어런스 커맨드 및 시그널링 패브릭은 상기 시스템 캐시 코히어런스 방식을 유지하기 위해 시그널링 및 커맨드들을 전달하고,
    상기 데이터 흐름 버스 패브릭은 비-코히어런트 트래픽 및 상기 시스템 온 어 칩 내의 마스터 지적 재산 코어들과 상기 IP 타겟 메모리 코어 간의 모든 데이터 트래픽 전달들을 전달(carry)하는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.
15. 제 13 항에 있어서,
    상기 플러그-인 캐시 코히어런스 관리자는,
    1) 스누핑-기반 캐시 코히어런스 관리자, 2) 스눕-필터링-기반 캐시 코히어런스 관리자 및 3) 분배된 디렉토리-기반 캐시 코히어런스 관리자 중 임의의 하나로서 구현되고, 상기 캐시 코히어런스 관리자를 위한 로직 블록은 상기 상호연결 및 상기 에이전트들의 코히어런스 로직을 변경함 없이 위의 3개의 시스템 코히어런스 방식들 중 하나를 지원하기 위해 상기 로직 블록 내의 다양한 하드웨어 컴포넌트들에 플러그 인할 수 있는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.
16. 제 15 항에 있어서,
    상기 플러그-인 캐시 코히어런스 관리자는 상기 코히어런트 커맨드 및 시그널링 패브릭과 상기 캐시 코히어런스 관리자의 로직 블록 간의 경계에서 표준 인터페이스를 통해 상기 3개의 시스템 코히어런스 방식들 중 임의의 것을 지원하고,
    상기 표준 인터페이스는 다양한 시스템 코히어런스 방식들의 지원을 가능하게 하기 위해 상이한 형태들의 로직이 상기 캐시 코히어런스 관리자의 로직 블록에 플러깅되도록 허용하는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.
17. 제 15 항에 있어서,
    상기 플러그-인 캐시 코히어런스 관리자는 상기 시스템 온 어 칩에서 상기 캐시 코히어런트 마스터 IP 코어들을 위해 제 1 로컬 메모리 캐시의 캐시 액세스를 모든 다른 로컬 메모리 캐시들에 브로드캐스트하도록 코히어런스 로직과 협력하는 스눕-기반 캐시 코히어런스 관리자로서 구현되고,
    상기 스눕-기반 캐시 코히어런스 관리자는 스누핑을 위해 스눕 브로드캐스트 방식에 의존하고 캐시 코히어런트 마스터 IP 코어들 및 임의의 캐시되지 않은 코히어런트 마스터 IP 코어들 둘 다를 지원하는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.
18. 제 15 항에 있어서,
    상기 플러그-인 캐시 코히어런스 관리자는, 그들이 캐시한 메모리 위치들에 대한 액세스를 위해 개별 캐시들을 관리하도록 상기 코히어런스 로직과 협력하는 단일 스눕 필터-기반 캐시 코히어런스 관리자로서 구현되고,
    스눕-필터는 각각이 하나 이상의 노드들에 의해 소유되는 캐시 라인을 표현하는 복수의 엔트리들을 유지함으로써 스누핑 트래픽을 감소시키고,
    상기 캐시 코히어런스 마스터 IP 코어들은 코히어런스 커맨드 및 시그널링 패브릭을 통해 상기 단일 스눕 필터-기반 캐시 코히어런스 관리자와 통신하고,
    상기 스눕 필터-기반 캐시 코히어런스 관리자는 모든 로컬 캐시 메모리들의 캐시 라인 엔트리들의 상태를 결정하기 위해 상기 복수의 엔트리들에 관한 테이블 룩 업(table look up)은 물론, 각각의 로컬 캐시의 캐시 코히어런트 데이터에 관한 상태를 검사하도록 주기적인 스누핑을 수행하는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.
19. 제 15 항에 있어서,
    상기 플러그-인 캐시 코히어런스 관리자는 3-홉 또는 4-홉 프로토콜 중 어느 하나를 구현하도록 구성된 홉 로직(hop logic)을 갖고,
    상기 4-홉 프로토콜에서, 스눕된 캐시 라인 상태가 먼저 캐시 코히어런트 관리자에게 송신되고, 이어서 상기 코히어런트 관리자는 요청 캐시 코히어런트 마스터 IP 코어로의 데이터의 송신을 배열하는 것을 담당하고, 상기 3-홉 프로토콜은 직접 '캐시-투-캐시(cache-to-cache)' 전달을 지원하고, 상기 캐시 코히어런스 관리자는 또한 상기 시스템 온 어 칩에서 2개 이상의 마스터 IP 코어들 간의 캐시 액세스들을 순서화하도록 구성되는 순서화 로직을 또한 갖는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.
20. 제 14 항에 있어서,
    상기 코히어런스 로직은 상기 제 1 캐시 코히어런트 마스터 지적 재산 코어를 위한 스눕 에이전트 및 정규 마스터 에이전트를 포함하는 하나 이상의 에이전트들에서 로케이팅되고,
    상기 제 1 캐시 코히어런트 마스터 지적 재산 코어는 2개의 별개의 포트들을 갖고,
    상기 정규 마스터 에이전트는 제 1 포트 상에 있고, 상기 스눕 에이전트는 제 2 포트 상에 있고,
    상기 스눕 에이전트는 스눕 코히어런스 트래픽에 대한 커맨드 및 시그널링을 핸들링하도록 구성된 코히어런스 로직을 갖고,
    상기 제 1 캐시 코히어런트 마스터에 대한 스눕 에이전트 포트는 스눕 요청들 및 응답들을 논리적으로 트래킹 및 응답하고,
    상기 정규 마스터 에이전트는 상기 제 1 캐시 코히어런트 마스터 지적 재산 코어에 대한 데이터 트래픽을 핸들링하도록 구성되는,
    시스템 온 어 칩에서 캐시 코히어런스를 유지하기 위한 방법.

Images