KR20140014273A - 휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템 - Google Patents

휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템 Download PDF

Info

Publication number
KR20140014273A
KR20140014273A KR1020137032235A KR20137032235A KR20140014273A KR 20140014273 A KR20140014273 A KR 20140014273A KR 1020137032235 A KR1020137032235 A KR 1020137032235A KR 20137032235 A KR20137032235 A KR 20137032235A KR 20140014273 A KR20140014273 A KR 20140014273A
Authority
KR
South Korea
Prior art keywords
slave
master
node
bandwidth
route
Prior art date
Application number
KR1020137032235A
Other languages
English (en)
Other versions
KR101503209B1 (ko
Inventor
푸란다 무쿤단
브라이언 제이 샐스베리
노먼 에스 가르가쉬
로버트 엔 깁슨
션 디 스위니
Original Assignee
퀄컴 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Publication of KR20140014273A publication Critical patent/KR20140014273A/ko
Application granted granted Critical
Publication of KR101503209B1 publication Critical patent/KR101503209B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/15—Interconnection of switching modules
    • H04L49/1553—Interconnection of ATM switching modules, e.g. ATM switching fabrics
    • H04L49/1576—Crossbar or matrix
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H04L49/253—Routing or path finding in a switch fabric using establishment or release of connections between ports
    • H04L49/254—Centralised controller, i.e. arbitration or scheduling

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

휴대용 컴퓨팅 디바이스 ("PCD") 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템이 설명된다. 그 시스템 및 방법은 마스터-슬레이브 쌍을 포함하는 클라이언트 요청을 수신하는 것과 마스터-슬레이브 쌍에 대응하는 슬레이브에 대한 탐색을 행하는 것을 포함한다. 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 통신들의 루트가 생성되고 그것은 마스터-슬레이브 쌍에 대응한다. 생성된 루트에 대응하는 하나 이상의 핸들들 또는 어레이들이 메모리 디바이스에 저장될 수도 있다. 다음으로, 그 루트에 걸친 대역폭이 설정될 수도 있다. 새로 생성된 루트에 걸친 대역폭이 설정된 후, 마스터-슬레이브 쌍으로부터 유래하는 클라이언트 요청이 생성된 루트를 이용하여 서비스될 수도 있다. 슬레이브에 대한 탐색을 행하는 것은, 마스터-슬레이브 계층구조에서의 각각의 슬레이브에 할당된 고유 식별자들을 비교하는 것을 포함할 수도 있다. 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 탐색은 또한 스위치 패브릭 내에서 질의될 수 있는 슬레이브들에 대한 패브릭 루트 점검 테이블을 검토하는 것을 포함할 수도 있다.

Description

휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템{METHOD AND SYSTEM FOR DYNAMICALLY CREATING AND SERVICING MASTER-SLAVE PAIRS WITHIN AND ACROSS SWITCH FABRICS OF A PORTABLE COMPUTING DEVICE}
휴대용 컴퓨팅 디바이스들 (portable computing devices; "PCDs") 은 개인 및 전문가 수준들의 사람들에게 필수품들이 되어가고 있다. 이들 디바이스들은 셀룰러 전화기들, 휴대용/개인휴대 정보 단말들 ("PDAs"), 휴대용 게임 콘솔들, 휴대용 내비게이션 유닛들, 팜톱 컴퓨터들, 및 다른 휴대용 전자 디바이스들을 포함할 수도 있다.
PCD들은 다양한 기능들 및 특징들을 제공하기 위해 다양한 유형들의 소프트웨어를 실행할 수도 있다. 예를 들어, PCD들은 비디오들을 시청하고 비디오 게임들을 플레이하는 것과 같은 기능들을 제공할 수도 있는 엔트테인먼트 소프트웨어를 실행할 수도 있다. PCD들은 또한 비즈니스 소프트웨어 또는 작문 (writing) 소프트웨어와 같은 다른 유형들의 소프트웨어, 이를테면 스프레드시트들, 이메일, 및/또는 워드 프로세싱 소프트웨어를 지원할 수도 있다.
보통, PCD 상에서 가동 중인 위에서 설명된 소프트웨어는 마스터-슬레이브 쌍들로서 함께 링크되는 다양한 하드웨어로부터의 액션들을 필요로 한다. 예를 들어, 마스터-슬레이브 쌍은 외부 버스 인터페이스와 같은 슬레이브에 커맨드들을 발행하는 마스터로서 역할을 하는 모바일 디스플레이 프로세서를 포함할 수도 있다. 기존의 PCD들에서, 마스터-슬레이브 쌍들 사이의 관계들은 보통 정적이고 PCD가 위에서 설명된 소프트웨어를 실행하기 시작할 때 런타임 전에 확립된다.
기존의 PCD들에서, 마스터-슬레이브 쌍들 사이의 관계들은, 런타임 전에 생성된 테이블에 보통 기록된다. 그 테이블은 보통 특정 마스터-슬레이브 쌍에 대한 상이한 작업부하들에 대응하는 상이한 대역폭들을 지원하는 여러 상이한 시나리오들을 열거한다.
기존의 PCD들에게 있는 하나의 문제는 마스터-슬레이브 쌍들이 서로에 대해 상이한 스위치 패브릭들 (switch fabrics) 에 존재하는 경우에 마스터-슬레이브 테이블들이 매우 복잡하게 된다는 것이다. 그 테이블들에게 있는 다른 문제는 그 테이블들이 단지 테이블들이 생성될 때에 설정된 고정된 값들에 기초하여 대역폭 요구들을 다룰 수도 있다는 것이다. 새로운 마스터-슬레이브 쌍이 PCD를 위해 도입되는 경우에 부가적인 문제가 발생한다. 새로운 마스터-슬레이브 쌍은 PCD가 오프라인인 경우에 작성된 정체된 (stagnant) 마스터-슬레이브 테이블들의 상당한 재작성을 필요로 할 수도 있다.
따라서, 당해 분야에서 필요한 것은 이들 문제들을 다루는 방법 및 시스템이다. 구체적으로는, 유사한 스위치 패브릭들 내에서 그리고/또는 상이한 스위치 패브릭들에 걸쳐 존재할 수도 있는 하드웨어 컴포넌트들에 대한 런타임에서 마스터-슬레이브 쌍들을 동적으로 생성하는 방법 및 시스템이 당해 기술분야에서 필요하다. 정체된 테이블들을 사용하는 일 없이 그때그때 (on-the-fly) 또는 실시간으로 스위치 패브릭들 및 버스들에 대한 대역폭들을 계산하고 조정하는 방법 및 시스템에 대한 다른 필요가 당해 기술분야에서 존재한다.
휴대용 컴퓨팅 디바이스 ("PCD") 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템이 설명된다. 그 시스템 및 방법은 마스터-슬레이브 쌍을 포함하는 클라이언트 요청을 수신하는 것과 마스터-슬레이브 쌍에 대응하는 슬레이브에 대한 탐색을 행하는 것을 포함한다. 마스터-슬레이브 쌍에 대응하는, 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 통신들의 루트가 생성될 수도 있다. 생성된 루트에 대응하는 하나 이상의 핸들들 또는 어레이들이 메모리 디바이스에 저장될 수도 있다. 다음으로, 그 루트에 걸친 대역폭이 설정될 수도 있다. 새로 생성된 루트에 걸친 대역폭이 설정된 후, 마스터-슬레이브 쌍으로부터 유래하는 클라이언트 요청이, 생성된 루트를 이용하여 서비스될 수도 있다. 슬레이브에 대한 탐색을 행하는 것은, 마스터-슬레이브 계층구조에서의 각각의 슬레이브에 할당된 고유 식별자들을 비교하는 것을 포함할 수도 있다. 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 탐색은 또한 스위치 패브릭 내에서 질의될 수 있는 슬레이브들에 대한 패브릭 루트 점검 테이블을 검토하는 것을 포함할 수도 있다.
도면들 중, 유사한 참조 부호들은 달리 표시되지 않는 한 여러 도면들을 통하여 유사한 부분들을 지칭한다. "102A" 또는 "102B"와 같은 문자 캐릭터들을 갖는 참조 부호들에 대해, 문자 캐릭터 지정은 동일한 도면에서 2 개의 유사한 부분들 또는 요소들을 구별할 수도 있다. 참조 부호들에 대한 문자 캐릭터 지정은 참조 부호가 모든 도면들에서 동일한 참조 부호를 갖는 모든 부분들을 포함하도록 하는 의도인 경우에 생략될 수도 있다.
도 1은 휴대용 컴퓨팅 디바이스 (portable computing device; "PCD") 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 시스템의 예시적인 엘리먼트들을 도시하는 기능 블록도이다;
도 2는 PCD (100) 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 여러 상이한 마스터-슬레이브 쌍들을 형성하는 것을 돕는 각각의 프로세서 (110) 에 상주하는 내부 칩 버스 (internal chip bus; "ICB") 드라이버 모듈 (103) 을 포함하는 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 시스템 (101) 을 예시하는 기능 블록도이다;
도 3은 버스 아키텍처를 위한 스위치 패브릭의 세부사항들을 예시하는 기능 블록도이다;
도 4는 상이한 스위치 패브릭들 내에 위치된 마스터-슬레이브 쌍들 사이에서 다양한 루트들을 지원하는 노드 그래프의 다이어그램이다;
도 5는 도 4에 예시된 제 1 스위치 패브릭의 마스터 레벨 노드들을 위한 제 1 루트 점검 테이블이다;
도 6은 도 4에 예시된 제 2 스위치 패브릭의 마스터 레벨 노드들을 위한 제 2 루트 점검 테이블이다;
도 7은 휴대용 컴퓨팅 디바이스 ("PCD") 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법을 예시하는 논리 흐름도이다;
도 8은 슬레이브 식별자를 이용하여 슬레이브를 탐색하는 서브방법 또는 루틴을 예시하는 논리 흐름도이다;
도 9a는 예시적인 제 1 소프트웨어 요청 유형을 예시한다;
도 9b는 예시적인 제 2 소프트웨어 요청 유형을 예시한다;
도 9c는 도 9a 및 도 9b에 예시된 소프트웨어 요청 유형들로부터 유도된 Ib 및 Ab 값들을 활용하여 PCD의 소프트웨어 요청들로부터의 현재 요구에 기초하여 버스 또는 스위치 패브릭 설정들을 동적으로 조정하는, 도 7에 대응하는 서브방법 또는 루틴을 예시하는 논리 흐름도이다;
도 9d는 마스터-슬레이브 쌍이 시스템 및 방법에 의해 생성되는 경우에 생성되는 핸들들을 예시하는 다이어그램이다;
도 10a는 도 1의 휴대용 컴퓨팅 디바이스의 자원들을 관리하는 노드 아키텍처의 제 1 양태의 다이어그램이다;
도 10b는 도 1의 PCD의 자원들을 관리하는 노드 아키텍처의 제 2 양태의 일반적인 다이어그램이다;
도 10c는 도 1의 PCD의 자원들을 관리하는 노드 아키텍처의 제 2 양태의 특정 다이어그램이다;
도 10d는 PCD의 자원(들)을 관리하는 노드 아키텍처를 생성하는 방법을 예시하는 흐름도이다;
도 10e는 PCD의 자원(들)을 관리하는 노드 아키텍처를 생성하는 방법을 예시하는 도 10d의 계속하는 흐름도이다;
도 11은 PCD의 소프트웨어 아키텍처에서 노드 구조 데이터를 수신하는 도 10d의 서브방법 또는 루틴을 예시하는 흐름도이다;
도 12는 PCD를 위한 소프트웨어 아키텍처에서 노드를 생성하는 도 10d 및 도 10e의 서브방법 또는 루틴을 예시하는 흐름도이다;
도 13은 PCD의 소프트웨어 아키텍처에서 클라이언트를 생성하는 도 12의 서브방법 또는 루틴을 예시하는 흐름도이다; 그리고
도 14는 PCD를 위한 소프트웨어 아키텍처에서 자원에 대한 클라이언트 요청을 생성하는 방법을 예시하는 흐름도이다.
단어 "예시적"은 여기서는 "예, 사례, 또는 예시로서 기능하는 것"을 의미하기 위해 사용된다. "예시적인" 것으로서 본 명세서에서 설명된 임의의 양태가 다른 양태들보다 바람직하거나 유익하다고 반드시 생각할 필요는 없다.
본 명세서에서, 용어 "애플리케이션"은 또한 실행가능 콘텐츠, 이를테면 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들을 갖는 파일들을 포함할 수도 있다. 덧붙여서, 본 명세서에서 말하는 "애플리케이션"은, 또한 원래 실행가능하지 않은 파일들, 이를테면 열 필요가 있을 수도 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들을 포함할 수도 있다.
용어 "콘텐츠"는 또한 실행가능 콘텐츠를 갖는 파일들, 이를테면 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들을 포함할 수도 있다. 덧붙여서, 본 명세서에서 말하는 "콘텐츠"는, 또한 원래 실행가능하지 않은 파일들, 이를테면 열 필요가 있을 수도 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들을 포함할 수도 있다.
본 명세서에서 사용되는 바와 같이, "컴포넌트", "데이터베이스", "모듈", "시스템" 등의 용어들은 하드웨어, 펌웨어, 하드웨어 및 소프트웨어의 조합, 소프트웨어, 또는 실행 소프트웨어 (software in execution) 중 어느 하나의 컴퓨터 관련 엔티티를 말하는 것으로 의도된다. 예를 들어, 컴포넌트는 프로세서 상에서 가동 중인 프로세스, 프로세서, 오브젝트, 실행가능물 (executable), 실행 스레드 (thread of execution), 프로그램, 및/또는 컴퓨터일 수도 있지만 이들로 제한되지 않는다. 예시로서, 컴퓨팅 디바이스 상에서 가동 중인 애플리케이션 및 컴퓨팅 디바이스 양쪽이 구성요소일 수 있다. 하나 이상의 컴포넌트들이 프로세스 및/또는 실행 스레드 내에 상주할 수도 있고, 컴포넌트가 하나의 컴퓨터 상에 국소화될 수도 있거나 그리고/또는 둘 이상의 컴퓨터들 상에 분산될 수도 있다. 덧붙여서, 이들 컴포넌트들은 다양한 데이터 구조들을 저장하고 있는 다양한 컴퓨터 판독가능 매체들로부터 실행될 수도 있다. 컴포넌트들은 로컬 및/또는 원격 프로세스들에 의해 이를테면 하나 이상의 데이터 패킷들을 갖는 신호 (예컨대, 로컬 시스템, 분산형 시스템에서의 다른 컴포넌트들과 상호작용하며 그리고/또는 다른 시스템들과는 인터넷과 같은 네트워크에 걸쳐 그 신호에 의해 상호작용하는 하나의 컴포넌트로부터의 데이터) 에 따라 통신할 수도 있다.
이 설명에서, 용어들 "통신 디바이스", "무선 디바이스", "무선 전화기", "무선 통신 디바이스", 및 "무선 핸드셋"은 상호교환적으로 사용된다. 제 3 세대 ("3G") 및 제 4 세대 ("4G") 무선 기술의 도래로, 더 큰 대역폭 가용성은 더 많은 휴대용 컴퓨팅 디바이스들이 더 많은 다양한 무선 능력들을 가질 수 있게 하였다.
이 설명에서, 용어 "휴대용 컴퓨팅 디바이스 (portable computing device)" ("PCD") 는 제한된 용량의 전원 공급부, 이를테면 배터리 상에서 작동하는 임의의 디바이스를 설명하는데 이용된다. 비록 배터리 작동식 PCD들이 수십년간 사용되었지만, 제 3 세대 ("3G") 및 제 4 세대 ("4G") 무선 기술의 도래와 연결된 재충전가능 배터리들에서의 기술 발전은 수많은 PCD들이 다수의 능력들을 갖는 것을 가능하게 하였다. 그러므로, PCD는 그 중에서, 셀룰러 전화기, 위성 전화기, 페이저, 개인휴대 정보 단말 ("PDA"), 스마트폰, 내비게이션 디바이스, 스마트북 또는 판독기, 미디어 플레이어, 앞서 언급된 디바이스들의 조합, 및 무선 접속을 갖는 랩톱 컴퓨터일 수도 있다.
도 1: PCD (100) 의 마스터- 슬레이브 쌍들을 동적으로 생성하고 서비스하는 시스템 엘리먼트들
도 1을 참조하면, 이 도면은 스위치 패브릭들 (switch fabrics) 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법들 및 시스템들을 구현하는 무선 전화기의 형태의 PCD (100) 의 예시적, 비제한적 양태의 기능 블록도이다. 보인 바와 같이, PCD (100) 는 멀티-코어, 중앙 프로세싱 유닛 ("CPU") (110A), 그래픽스 프로세서 (110B), 및 아날로그 신호 프로세서 (126) 를 갖는 온-칩 시스템 (102) 을 구비한다. 이들 프로세서들 (110A, 110B, 126) 은 서로 연결될 수도 있다.
CPU (110A) 는 당업자에 의해 이해될 바와 같은 제 0 코어 (222), 제 1 코어 (224), 및 제 N 코어 (226) 를 포함할 수도 있다. 대체 실시형태에서, CPU (110A) 및 그래픽스 프로세서 (110B) 를 사용하는 대신, 하나 이상의 디지털 신호 프로세서들 ("DSPs") 이 또한 당업자에 의해 이해될 바와 같이 채용될 수도 있다.
PCD (100) 는 프로세서들 (110) 에 의해 실행되는 내부 칩 버스 (internal chip bus; "ICB") 드라이버 모듈들 (103) 을 포함할 수도 있다. 당업자는 본 개시물로부터 벗어남 없이 다양한 부분들로 나누어지고 상이한 프로세서들 (110, 126) 에 의해 실행될 수도 있는 하나 이상의 소프트웨어 모듈들을 각각의 ICB 드라이버 모듈 (103) 이 포함할 수도 있다는 것을 인식할 것이다.
ICB 드라이버 모듈들 (103) 은 애플리케이션 프로그램 모듈들 (105) 에 의해 발행된 소프트웨어 요청들을 프로세싱하고 지원하는 마스터-슬레이브 쌍들의 동적 생성 및 서비스를 담당할 수도 있다. ICB 드라이버 모듈들 (103) 의 2 개의 유형들, 즉, 상위 계층 (upper layer; "UL") 유형 (103A) 및 하위 계층 (lower layer; "LL") 유형 (103B) 이 있을 수도 있다. 일반적으로, UL ICB 드라이버 유형들 (103A) 은 다양한 애플리케이션 모듈들 (105) 을 지원할 수도 있는 하나 이상의 프로세서들 (110, 126) 에 의해 보통 실행될 것이다. LL ICB 드라이버 유형들 (103B) 은 자원 전력 관리자 (107) 라고 지칭되는 하나의 하드웨어 엘리먼트에 의해 보통 실행될 것이다.
LL ICB 드라이버 (103B) 를 실행시키는 자원 전력 관리자 (107) 는 대역폭 값들을 적용하고 설정하는 것을 일반적으로 담당할 것이다. 이들 대역폭 값들은 도 2에 관련하여 아래에서 설명되는 하나 이상의 버스들 및/또는 스위치 패브릭들에 자원 전력 관리자 (107) 에 의해 적용될 것이다. 자원 전력 관리자 (107) 는 스위치 패브릭들 및 버스들을 위한 클록 속도들뿐만 아니라 슬레이브들을 위한 클록 속도들을 설정하는 것을 일반적으로 담당한다. 슬레이브들은 일반적으로 애플리케이션 프로그램들 (105) 을 실행하는 마스터 프로세서들 (110) 로부터의 요청들을 지원하는 하드웨어 컴포넌트들이다.
ICB 드라이버들 (103A, 103B) 은 자원 전력 관리자 (107) 와 조합하여, 유사한 스위치 패브릭들 내에 그리고/또는 상이한 스위치 패브릭들에 걸쳐 존재할 수도 있는 하드웨어 컴포넌트들에 대해 런타임에서 마스터-슬레이브 쌍들의 동적 생성을 허용한다. ICB 드라이버들 (103A, 103B) 및 자원 전력 관리자 (107) 는 그때그때 또는 실시간으로 스위치 패브릭들 및 버스들에 대한 대역폭들을 계산하고 조정할 수도 있다.
특정 양태에서, 본원에서 설명되는 방법 단계들 중 하나 이상은 ICB 드라이버들 (103A, 103B) 을 포함하는, 메모리 (112) 에 저장된 실행가능 명령들 및 파라미터들에 의해 구현될 수도 있다. ICB 드라이버들 (103A, 103B) 을 형성하는 이들 명령들은 CPU (110), 아날로그 신호 프로세서 (126), 및 자원 전력 관리자 (107) 에 의해 실행될 수도 있다. 게다가, 프로세서들 (110A, 126), 메모리 (112), 그 속에 저장된 명령들, 또는 그 조합은 본 명세서에서 설명되는 방법 단계들 중 하나 이상을 수행하는 수단으로서 기능을 할 수도 있다.
도 1: PCD (100) 의 다른 엘리먼트들
도 1에 도시된 바와 같이, 디스플레이 제어기 (128) 와 터치 스크린 제어기 (130) 가 멀티코어 CPU (110A) 에 연결된다. 온-칩 시스템 (102) 외부의 터치스크린 디스플레이 (132) 가 디스플레이 제어기 (128) 및 터치스크린 제어기 (130) 에 연결된다.
도 1은 비디오 코더/디코더 ("codec") (134), 예컨대, "PAL" (phase alternating line) 인코더, "SECAM" (sequential couleur memoire) 인코더, "NTSC" (national television system(s) committee) 인코더 또는 멀티코어 중앙 프로세싱 유닛 ("CPU") (110A) 에 연결된 임의의 다른 유형의 비디오 인코더 (134) 를 추가로 나타낸다. 비디오 증폭기 (136) 가 비디오 인코더 (134) 및 터치 스크린 디스플레이 (132) 에 연결된다. 비디오 포트 (138) 가 비디오 증폭기 (136) 에 연결된다. 도 2에 묘사된 바와 같이, 유니버셜 직렬 버스 ("USB") 제어기 (140) 가 CPU (110A) 에 연결된다. 또한, USB 포트 (142) 가 USB 제어기 (140) 에 연결된다. 가입자 식별 모듈 (SIM) 카드 (146) 가 또한 CPU (110A) 에 연결될 수도 있다. 게다가, 도 1에 보인 바와 같이, 디지털 카메라 (148) 가 CPU (110A) 에 연결될 수도 있다. 예시적인 양태에서, 디지털 카메라 (148) 는 전하 결합 소자 ("CCD") 카메라 또는 상보성 금속산화물 반도체 ("CMOS") 카메라이다.
도 1에 추가로 예시된 바와 같이, 스테레오 오디오 CODEC (150) 이 아날로그 신호 프로세서 (126) 에 연결될 수도 있다. 더구나, 오디오 증폭기 (152) 가 스테레오 오디오 CODEC (150) 에 연결될 수도 있다. 예시적인 양태에서, 제 1 스테레오 스피커 (154) 및 제 2 스테레오 스피커 (156) 가 오디오 증폭기 (152) 에 연결된다. 도 1은 마이크로폰 증폭기 (158) 가 또한 스테레오 오디오 CODEC (150) 에 연결될 수도 있음을 보여준다. 덧붙여, 마이크로폰 (160) 이 마이크로폰 증폭기 (158) 에 연결될 수도 있다. 특정 양태에서, 주파수 변조 ("FM") 라디오 튜너 (162) 가 스테레오 오디오 CODEC (150) 에 연결될 수도 있다. 또한, FM 안테나 (164) 가 FM 라디오 튜너 (162) 에 연결될 수도 있다. 게다가, 스테레오 헤드폰들 (166) 이 스테레오 오디오 CODEC (150) 에 연결될 수도 있다.
도 1은 무선 주파수 ("RF") 트랜시버 (168) 가 아날로그 신호 프로세서 (126) 에 연결될 수도 있음을 추가로 나타낸다. RF 스위치 (170) 가 RF 트랜시버 (168) 및 RF 안테나 (172) 에 연결될 수도 있다. 도 1에 보인 바와 같이, 키패드 (174) 가 아날로그 신호 프로세서 (126) 에 연결될 수도 있다. 또한, 마이크로폰 구비 모노 헤드셋 (176) 이 아날로그 신호 프로세서 (126) 에 연결될 수도 있다. 게다가, 진동기 디바이스 (178) 가 아날로그 신호 프로세서 (126) 에 연결될 수도 있다. 도 1은 또한 전원 공급부 (180), 예를 들어 배터리가 온-칩 시스템 (102) 에 연결될 수도 있음을 보여준다. 특정 양태에서, 전원 공급부 (180) 는 재충전가능 DC 배터리 또는 AC 전원에 접속되는 교류 ("AC") 대 DC 변압기로부터 유도되는 DC 전원 공급부이다.
도 1에 묘사된 바와 같이, 터치스크린 디스플레이 (132), 비디오 포트 (138), USB 포트 (142), 카메라 (148), 제 1 스테레오 스피커 (154), 제 2 스테레오 스피커 (156), 마이크로폰 (160), FM 안테나 (164), 스테레오 헤드폰들 (166), RF 스위치 (170), RF 안테나 (172), 키패드 (174), 모노 헤드셋 (176), 진동기 (178), 열 센서들 (157B), 및 전원 공급부 (180) 는 온-칩 시스템 (322) 외부에 있다.
도 2는 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 시스템 (101) 을 예시하는 기능 블록도이다. 그 시스템은 각각의 프로세서 (110) 내에 보통 상주하는 상위 계층 ("UL") 내부 칩 버스 ("ICB") 드라이버 모듈 (103A) 을 구비한다. ICB 드라이버 모듈 (103A) 은 PCD (100) 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 여러 상이한 마스터-슬레이브 쌍들을 형성하는 것을 도울 수도 있다. 시스템 (101) 은 또한 자원 전력 관리자 (102) 내에 보통 상주하는 하위 계층 ("LL") ICB 드라이버 (103B) 를 구비한다.
위에서 지적했듯이, ICB 드라이버 모듈 (103) 은 일반적으로 소프트웨어를 포함한다. 그러나, 드라이버 모듈 (103) 은 하드웨어 그리고/또는 하드웨어 및 소프트웨어의 조합으로서 구현될 수도 있다. 각각의 UL ICB 드라이버 모듈 (103A) 은 개별 프로세서 (110) 에 의해 실행되는 개별 애플리케이션 프로그램 모듈들 (105) 에 연결될 수도 있다. 예를 들어, 제 1 UL ICB 모듈 (103A1) 은 제 1 애플리케이션 모듈 (105A1) 및 제 2 애플리케이션 프로그램 모듈 (105A2) 에 연결될 수도 있다.
애플리케이션 프로그램 모듈들 (105) 은 PCD들 (100) 에 대해 이용가능한 임의의 수의 상이한 유형들의 프로그램 모듈들을 포함할 수도 있다. 예를 들어, 프로그램 모듈 (105) 은, 비디오 게임들, 오디오 파일들, 및 비디오들과 같은 엔트테인먼트 프로그래밍을 지원하는 그래픽스 프로세싱 소프트웨어; 워드 프로세싱, 이메일들, 스프레드시트들, 캘린더들 등과 같은 비즈니스 애플리케이션들을 지원하는 비즈니스 소프트웨어를 포함할 수도 있으나 이들로 제한되지 않는다. 다른 프로그램 모듈들 (105) 은 글로벌 포지셔닝 위성 ("GPS") 프로그램들과 같은 내비게이션 프로그램들, 쇼핑, 학습 등을 위한 것과 같은 다운로드가능 맞춤화된 애플리케이션들을 포함하지만 이들로 제한되지 않는다.
도 2에서, 4 개의 중앙 프로세싱 유닛들 ("CPU들") (110A, 110B, 110C, 및 110N) 이 예시된다. 각각의 CPU (110) 는 개별 스위치 패브릭 (107) 에 연결될 수도 있다. 스위치 패브릭들 (107) 에 관한 추가의 세부사항들은 도 3에 관련하여 아래에서 상세히 설명될 것이다.
제 1 스위치 패브릭 (107A) 은 제 1 및 제 2 CPU들 (110A, 110B), 모바일 디스플레이 프로세서 (110D), 더블 데이터 레이트 동기식 다이나믹 랜덤 액세스 메모리 ("DDR SDRAM") (112), 구성 포트 (111), 및 자원 전력 관리자 (102) 에 연결될 수도 있다. 제 2 스위치 패브릭 (107B) 은 제 3 CPU (110C), 동적 메모리 할당/액세스 ("DMA") 엔진 (109), 자원 전력 관리자 (102), 외부 버스 인터페이스 (113), 및 디지털 신호 프로세서 (114) 에 연결될 수도 있다. 제 3 스위치 패브릭 (107N) 은, 제 4 CPU (110N), 마스터 하드웨어 엘리먼트 (115), 및 슬레이브 하드웨어 엘리먼트 (117) 에 연결된다.
제 1 CPU (110A) 는 시스템 (1010) 을 위한 마스터-슬레이브 계층구조에서 제 1 마스터로서 언급될 수도 있다. 제 2 CPU (110B), 제 3 CPU (110C), 및 제 4 CPU (110N) 는 제 2, 제 3, 및 제 4 마스터들로서 각각 언급될 수도 있다. 다른 마스터들은 제 5 마스터로서 역할을 하는 모바일 디스플레이 프로세서 (110D), 제 6 마스터로서 역할을 하는 디지털 신호 프로세서 ("DSP"), 및 제 7 마스터로서 역할을 하는 동적 메모리 할당/액세스 ("DMA") 엔진 (109) 을 포함할 수도 있지만 이들로 제한되지 않는다.
한편, 구성 포트 (111), DDR 메모리 (112), 및 외부 버스 인터페이스 (113) 는, 시스템 (101) 을 위한 마스터-슬레이브 계층구조에서 제 1, 제 2, 및 제 3 슬레이브들로서 언급될 수도 있다. 이들 슬레이브들의 각각은 개별 마스터에 의해 생성된 소프트웨어 요청들을 서비스할 수도 있다.
이전에 언급했듯이, 7 개의 마스터들이 도 2에 도시되어 있다. 당업자는 적은 수 또는 많은 수의 마스터들이 시스템 (101) 내에 그의 범위를 변경하지 않고서 채용될 수도 있다는 것이 이해될 것이다. 이는 또한 슬레이브들에 대해서도 해당된다: 적은 수 또는 많은 수의 슬레이브들이 당업자에 의해 이해되는 바와 같이 채용될 수도 있다.
CPU들 (110) 상에 상주하는 UL ICB 드라이버들 (103A) 은 개별 마스터 CPU (110) 의 각각의 애플리케이션 프로그램 모듈 (105) 에 의해 발행된 소프트웨어 요청들을 검토할 수도 있다. UL ICB 드라이버들 (103A) 은 LL ICB 드라이버 (103B) 와 조합하여, 이들의 소프트웨어 요청들의 검토 및 이들의 대응하는 요구들에 응답하여 스위치 패브릭들 (107) 의 설정들을 또한 조정할 수도 있다.
PCD (100) 의 예시적인 실시형태들에서, 시스템 (101) 에서의 마스터들의 수는 종종 슬레이브들의 수를 초과할 것이다. 예를 들어, 시스템 (101) 을 갖는 PCD (100) 는 약 40 내지 약 50 개 사이의 마스터들과, 약 10 내지 약 15 개 사이의 슬레이브들을 가질 수도 있다.
예시적인 시스템 (101) 에 따르면, UL ICB 드라이버 (103) 는 애플리케이션 프로그램 모듈 (105) 로부터 클라이언트 요청을 수신할 수도 있다. 예를 들어, 제 1 UL ICB 드라이버 (103A1) 는 제 1 애플리케이션 모듈 (105A1) 로부터 클라이언트 생성 요청을 수신할 수도 있다. 클라이언트 생성 요청은 마스터-슬레이브 쌍, 이를테면 모바일 디스플레이 프로세서 (mobile display processor; "MDP") (110D) (마스터) 및 외부 버스 인터페이스 (113) (슬레이브) 를 포함할 수도 있다.
MDP (110D) (마스터) 는 제 1 스위치 패브릭 (107A) 내에 상주하는 반면 외부 버스 인터페이스 (113) (슬레이브) 는 제 2 스위치 패브릭 (107B) 내에 상주한다. 기존의 기술에서, 정적 또는 정체된 테이블은 클라이언트 요청의 생성 이전인 런타임에 앞서 생성될 필요가 있다. 이 정적 테이블은 MDP (110D) (마스터) 와 외부 버스 인터페이스 (113) (슬레이브) 사이의 관계들 및 루트들을 열거할 것이다.
이 시점에서 정적 테이블에 액세스하는 대신, 시스템 (101) 은 MDP (110D) (마스터) 와 외부 버스 인터페이스 (113) (슬레이브) 사이의 하나 이상의 통신 루트들을 결정하기 위해 스위치 패브릭들 (107) 에 걸친 탐색을 행할 수도 있다. 일단 이 마스터와 슬레이브 사이의 루트가 결정되면, 시스템 (101) 은 상이한 스위치 패브릭들 (107) 내에서 그리고 스위치 패브릭들에 걸쳐 연장할 수도 있는 통신 루트들을 위한 대역폭들을 설정할 수도 있다. PCD (100) 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법의 추가의 세부사항들이 도 4 내지 도 10에 관련하여 아래에서 상세히 설명될 것이다.
도 3은 도 2의 제 1 스위치 패브릭 (107A) 의 세부사항들을 예시하는 기능 블록도이다. 스위치 패브릭 (107A) 이 당업자에 의해 이해될 바와 같은 버스 아키텍처라고 일반적으로 지칭될 수도 있다. 이 도면에서의 문자 "M"은 스위치 패브릭 (107A) 에 대한 마스터-슬레이브 계층구조에서의 마스터들을 나타내는 반면 이 도면에서의 문자 "S"는 슬레이브들을 나타낸다.
제 1 스위치 패브릭 (107A) 은 네트워크 노드들 (M1, M2, M5, S1, S2) 이 하나 이상의 네트워크 스위치들을 통해 이를테면 크로스바 스위치들 (307) 에 의해 서로 접속되는 네트워크 토폴로지를 포함한다. 도 3에 예시된 이 제 1 스위치 패브릭 (107A) 은 일반적으로 도 2의 제 1 스위치 패브릭 (107A) 과 대응한다. 스위치 패브릭 (107A) 은 다른 버스 설계들에 비해 양호한 총 스루풋을 제공할 수도 있는데, 이는 트래픽이 다수의 물리적 링크들에 걸쳐 분산되기 때문이다.
도 3의 예시적인 실시형태에서, 제 1 마스터 1 (110A) 은 제 1 슬레이브 1 (111) 및 제 2 슬레이브 2 (112) 에 연결될 수도 있다. 마찬가지로, 제 2 마스터 2 (110B) 는 제 1 슬레이브 1 (111) 및 제 2 슬레이브 2 (112) 등에 연결될 수도 있다. 본 문서에서의 현재의 스위치 패브릭 (107) 의 예시적인 구현예는 PCI Express이다. 도 3에 예시된 바와 같이, 예시적인 제 1 스위치 패브릭 (107A) 의 3 개의 마스터들 (M1, M2, 및 M5) 은 개별 슬레이브에 접속하기 위해 다양한 크로스바 스위치들 (307A, 307B, 및 307C) 각각을 활용할 수도 있다.
도 4는 3 개의 상이한 스위치 패브릭들 (107A, 107B, 및 107C) 내에 위치된 마스터-슬레이브 쌍들 사이에서 다양한 루트들을 지원하는 노드 그래프 또는 노드 아키텍처 (403) 의 다이어그램이다. 노드 아키텍처 (403) 는 ICB 드라이버 (103) 가 상이한 스위치 패브릭들 (107) 내에 그리고 이들 사이에 위치된 마스터-슬레이브 쌍들 사이의 관계들을 특징화하는 방법을 예시한다.
노드 아키텍처 (403) 는 제 1 스위치 패브릭 (107A) 에 연결되는 중재자 노드 (405) 를 포함한다. 중재자 노드 (405) 가 각각의 스위치 패브릭 (107) 마다 존재할 수도 있다. 그러나, 도 4는 단지 제 1 스위치 패브릭 (107A) 에 대한 단일 중재자 노드 (405) 만을 예시한다. 중재자 노드 (405) 는 특정 마스터 하드웨어 디바이스 상에서 가동 중인 애플리케이션 모듈들 (105) 각각으로부터 소프트웨어 요청들을 수신할 수도 있다.
제 1 스위치 패브릭은 3 개의 마스터들, 즉, 도 2의 제 1 CPU (110A) 에 대응하는 제 1 마스터 노드 M1 (110A), 제 2 CPU (110B) 에 대응하는 제 2 마스터 노드 M2 (110B), 및 MDP (110D) 에 대응하는 제 5 마스터 노드 M5 (110D) 를 포함한다.
제 1 스위치 패브릭 (107A) 은 2 개의 슬레이브들, 즉, 도 2의 구성 포트 (111) 에 대응하는 제 1 슬레이브 노드 S1 (111), 및 DDR SDRAM (112) 에 대응하는 제 2 슬레이브 노드 S2 (112) 를 가진다. 제 1 스위치 패브릭 (107) 은 제 1 게이트웨이 노드 G1 (400A1) 및 제 2 게이트웨이 노드 G2 (402A1) 를 더 포함할 수도 있다. 스위치 패브릭 (107) 의 각각의 제 2 게이트웨이 노드 G2 (402) 는 다른 스위치 패브릭의 제 1 게이트웨이 노드 G1 (400) 에 연결된다. 각각의 제 2 게이트웨이 노드 G2 (402) 는 2 개의 상이한 스위치 패브릭들 (107) 사이의 통신을 발생시키는 한편 각각의 대응하는 제 1 게이트웨이 노드 G1 (400) 은 그 통신을 수신한다.
예를 들어, 제 1 스위치 패브릭 (107A) 의 제 2 게이트웨이 노드 G2 (402A1) 는 제 1 스위치 패브릭 (107A) 으로부터 제 2 스위치 패브릭의 제 1 게이트웨이 노드 G1 (400B1) 로 전송되는 통신을 발생시킬 수도 있다. 반대로, 제 2 게이트웨이 노드 G2 (402B1) 는 제 2 스위치 패브릭 (107B) 으로부터 제 1 스위치 패브릭 (107A) 의 제 1 게이트웨이 노드 G1 (400A1) 로 전송되는 통신을 발생시킬 수도 있다.
특정 스위치 패브릭 (107) 의 각각의 제 2 게이트웨이 노드 G2 (402) 는, 특정 스위치 패브릭 (107) 의 마스터에 대한 슬레이브로서 기능을 한 다음 제 2 게이트웨이 노드 G2 (402) 가 다른 게이트웨이 노드, 이를테면 다른 스위치 패브릭 (107) 상의 제 1 게이트웨이 노드 G1 (400) 과 통신들을 확립하는 경우에 마스터로서 기능을 할 수도 있다. 예를 들어, 제 2 마스터 M2 (110B) 로부터 제 2 게이트웨이 노드 G2 (402A1) 로 흐르는 통신들의 경우, 제 2 게이트웨이 노드 G2 (402A1) 는 제 2 마스터 M2 (110B) 에 대한 슬레이브로서 기능을 한다. 그러나, 제 2 스위치 패브릭 (107B) 상의 제 1 게이트웨이 노드 G1A (400B1) 에 대해, 제 2 마스터 M2 (110B) 는 마스터로서 기능을 하는 반면 제 1 게이트웨이 노드 G1A (400B1) 는 제 2 게이트웨이 노드 G2 (402A1) 에 대해 슬레이브로서 기능을 한다. 다른 예시적인 실시형태들에서, 상이한 스위치 패브릭들 (108) 에 걸친 제 1 및 제 2 게이트웨이들 G1 (400) 과 G2 (402) 사이의 이들 페어링들은, 슬레이브 및 마스터 양쪽 모두로서 역할을 하는 단일 게이트웨이 노드 (미도시) 에 의해 소프트웨어적으로 표현될 수도 있다.
제 1 및 제 2 게이트웨이 노드들 G1 (400) 및 G2 (402) 는 상이한 스위치 패브릭들 (107) 사이의 통신들을 허용한다. 제 1 및 제 2 게이트웨이 노드들 G1 (400) 및 G2 (402) 를 사용함으로써, 제 1 패브릭 (107A) 의 마스터 (M) 는 상이한 스위치 패브릭 (107) 이를테면 도 4에 예시된 바와 같은 제 2 스위치 패브릭 (107B) 에 상주할 수도 있는 특정 슬레이브 노드 (S) 를 위치결정할 수도 있다.
예를 들어, 제 1 패브릭 (107) 에 대한 중재자 노드 (405) 로부터 유래하는 소프트웨어 요청이 제 1 스위치 패브릭 (107A) 의 제 5 마스터 노드 M5 (110D) 및 제 2 스위치 패브릭 (107B) 의 제 3 슬레이브 노드 S3 (113) 를 포함하는 마스터-슬레이브 쌍을 요청했다고 가정한다. ICB 드라이버 (103) 는 요청된 제 3 슬레이브 노드 S3 (113) 이 제 1 스위치 패브릭 (107A) 의 부분이었는지를 먼저 결정할 것이다. ICB 드라이버 (103) 는 요청된 제 3 슬레이브 S3 (113) 의 식별자와 제 1 스위치 패브릭 (107A) 의 제 1 및 제 2 슬레이브 노드들 (S1 및 S2) 에 대한 식별자들을 비교할 것이다.
일단 요청된 제 3 슬레이브 노드 S3 (113) 이 제 1 스위치 패브릭 내에 존재하지 않는다고 ICB 드라이버 (103) 가 결정하면, ICB 드라이버 (103) 는 다음의 스위치 패브릭 (107B) 에서의 탐색을 행하기 위한 요청을 (라인 세그먼트 A를 따라) 제 2 게이트웨이 노드 G2 (402A1) 로 발행할 것이다. 제 2 게이트웨이 노드 G2 (402A1) 는 그 후에, 요청된 제 3 슬레이브 노드 S3 (113) 에 대한 제 2 스위치 패브릭 (107D) 의 탐색을 행하기 위한 커맨드 또는 명령을 (라인 세그먼트 B를 따라) 제 1 게이트웨이 (400B1) 로 발행할 것이다. 제 2 스위치 패브릭 (107B) 의 것인 제 1 게이트웨이 (400B) 는 그 후에, 제 2 스위치 패브릭 (107B) 으로부터의 슬레이브 노드들 (S) 에 대한 비교에 기초하여 제 3 슬레이브 노드에 대한 고유 식별자를 3으로서 이용하여 제 3 슬레이브 노드 S3 (113) 에 대한 탐색을 행할 것이다.
일단 제 3 슬레이브 노드 S3 (113) 이 발견되면, 제 1 게이트웨이 G1 (400B1) 은 제 3 슬레이브 노드 S3 (113) 과 제 1 스위치 패브릭 (107B) 의 제 1 게이트웨이 노드 G1 (400B1) 사이에 통신 링크를 확립하기 위한 커맨드를 (라인 세그먼트 C를 따라) 발행할 것이다. 그러므로, ICB 드라이버 (103) 는 제 1 스위치 패브릭 (107A) 의 제 5 마스터 (110D) 와 제 2 스위치 패브릭 (107B) 의 요청된 제 3 슬레이브 S3 (113) 사이에 확립된 루트를 기록할 것이다.
도 4에 예시된 바와 같이, 제 2 스위치 패브릭 (107B) 은 3 개의 마스터 노드들 M3 (110C), M6 (114), 및 M7 (109) 을 포함할 수도 있으며, 마스터 노드 M3 (110C) 는 도 2의 제 3 프로세서 (110C) 에 대응하며; 마스터 노드 M6는 도 2의 DSP (114) 와 대응하며; 그리고 마스터 노드 M7 (109) 은 도 2의 DMA 엔진 (109) 과 대응한다. 제 2 스위치 패브릭 (107B) 은 제 2 스위치 패브릭 (107B) 을 제 3 스위치 패브릭 (107C) 에 연결시키는 부가적인 게이트웨이 노드들 G1B (400B2) 및 G2B (402B2) 를 더 포함할 수도 있다. 마찬가지로, 제 3 스위치 패브릭 (107C) 은 2 개의 마스터 노드들 M4 (110N) 및 Mn (115) 과 단일 슬레이브 노드 SN (117) 을 포함할 수도 있다.
노드 아키텍처 (403) 는 RPM 노드 (102) 에 연결되는 3 개의 스위치 패브릭 노드들 (407A, 407B, 및 407C) 을 더 포함할 수도 있다. 스위치 패브릭 노드들 (407) 은 도 2의 스위치 패브릭들 (107) 과 대응할 수도 있다. 마찬가지로, RPM 노드 (102) 는 도 2의 자원 전력 관리자 (102) 와 대응할 수도 있다.
RPM 노드 (102) 는 스위치 패브릭 노드들 (407) 에 이들의 개별 대역폭 파라미터들을 특정 스위치 패브릭 (107) 내의 노드들에 대해 제어하기 위하여 커맨드들을 발행할 수도 있다. 도 4에 예시된 바와 같이, 스위치 패브릭 (107) 의 각각의 슬레이브 (S) 또는 제 2 게이트웨이 (G2) 는 대응하는 패브릭 노드 (407) 에 연결된다.
도 5는 도 4에 예시된 제 1 스위치 패브릭 (107A) 의 마스터 레벨 노드들을 위한 제 1 루트 점검 테이블 (507) 이다. 제 1 루트 점검 테이블 (507) 은 ICB 드라이버 모듈 (103) 이 그때그때 또는 동적으로 마스터-슬레이브 쌍을 형성하는 개별 마스터에 의해 점검될 수도 있는 제 1 스위치 패브릭 (107A) 의 슬레이브들을 열거한다. 이 루트 점검 테이블 (507) 은 ICB 드라이버 모듈 (103) 이 특정 소프트웨어 애플리케이션 모듈 (105) 에 의해 발행된 소프트웨어 요청으로 요구되었던 특정 슬레이브를 제 1 스위치 패브릭 (107A) 내에서 탐색하는 경우에 그 ICB 드라이버 모듈에 의해 사용된다. 테이블 (507) 에서의 일 (1) 값들은 특정 슬레이브가 소프트웨어 요청에서의 슬레이브에 매칭하는지를 결정하기 위해 개별 마스터가 특정 슬레이브와 협의할 수도 있다는 것을 나타낸다. 테이블 (507) 에서의 제로 (0) 값들은 특정 슬레이브가 소프트웨어 요청에서의 슬레이브에 매칭하는지를 결정하기 위해 개별 마스터가 특정 슬레이브와 협의하지 않을 수도 있다는 것을 나타낸다.
예를 들어, 도 4의 제 1 게이트웨이 G1 (400A1) 이 제 2 스위치 패브릭 (107B) 의 제 2 게이트웨이 G2A (402B1) 로부터 유래하는 통신에 대한 마스터로서 역할을 하는 경우, 제 1 게이트웨이 G1 (400A1) 은 테이블 (507) 의 제 4 행 및 제 4 열에서의 제로로 반영된 바와 같이 제 2 게이트웨이 G2 (402A1) 로 슬레이브에 대한 탐색을 행하는 것이 허용되지 않는다. 제 2 게이트웨이 G2 (402A1) 에 대한 슬레이브의 탐색의 차단은 그런 탐색이 제 1 게이트웨이 G1 (400A1) 과 제 2 게이트웨이 G2 (402A1) 사이에서 허용된다면 발생할 끝없는 프로그래밍 루프를 방지할 수도 있다.
도 6은 도 4에 예시된 제 2 스위치 패브릭 (107B) 의 마스터 레벨 노드들을 위한 제 2 루트 점검 테이블 (607) 이다. 제 2 루트 점검 테이블 (607) 은 ICB 드라이버 모듈 (103) 이 그때그때 또는 동적으로 마스터-슬레이브 쌍을 형성하는 개별 마스터에 의해 점검될 수도 있는 제 2 스위치 패브릭 (107B) 의 슬레이브들을 열거한다. 이 루트 점검 테이블 (607) 은 ICB 드라이버 모듈 (103) 이 특정 소프트웨어 애플리케이션 모듈 (105) 에 의해 발행된 소프트웨어 요청으로 요구되었던 특정 슬레이브를 제 2 스위치 패브릭 (107B) 내에서 탐색하는 경우에 그 ICB 드라이버 모듈에 의해 사용된다. 테이블 (607) 에서의 일 (1) 값들은 특정 슬레이브가 소프트웨어 요청에서의 슬레이브에 매칭하는지를 결정하기 위해 개별 마스터가 특정 슬레이브와 협의할 수도 있다는 것을 나타낸다. 테이블 (607) 에서의 제로 (0) 값들은 특정 슬레이브가 소프트웨어 요청에서의 슬레이브에 매칭하는지를 결정하기 위해 개별 마스터가 특정 슬레이브와 협의하지 않을 수도 있다는 것을 나타낸다.
예를 들어, 제 1 게이트웨이 G1B (400B2) 가 제 3 스위치 패브릭 (107C) 의 제 2 게이트웨이 G2 (402C1) 로부터 유래하는 통신에 대한 마스터로서 역할을 하는 경우, 제 1 게이트웨이 G1B (400B2) 는 테이블 (607) 의 제 4 행 및 제 4 열에서의 제로로 반영된 바와 같이 제 2 게이트웨이 G2B (402B2) 로 슬레이브에 대한 탐색을 행하는 것이 허용되지 않는다. 제 2 게이트웨이 G2B (402B2) 에 대한 슬레이브의 탐색의 차단은 그런 탐색이 제 1 게이트웨이 G1B (400B2) 와 제 2 게이트웨이 G2B (402B2) 사이에서 허용된다면 발생할 끝없는 프로그래밍 루프를 방지할 수도 있다. 제 3 스위치 패브릭 (107C) 은 또한 루트 점검 테이블을 가질 것이다. 그러나, 제 3 스위치 패브릭 (107) 에 대한 그런 루트 테이블이 예시되지 않았으나 당업자에 의해 이해되는 바와 같이 쉽사리 생성될 것이다.
도 7은 휴대용 컴퓨팅 디바이스 ("PCD") 의 스위치 패브릭들 (107) 내에서 그리고 스위치 패브릭들 (107) 에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 (700) 을 예시하는 논리 흐름도이다. 블록 705는 방법 (700) 의 제 1 단계이다. 블록 705에서, ICB 드라이버 모듈 (103) 은 마스터-슬레이브 쌍을 포함하는 클라이언트 요청을 수신할 수도 있다. 그 클라이언트 요청은 도 2에 예시된 바와 같은 제 1 CPU (110) 와 같은 프로세서 상에서 가동 중인 애플리케이션 프로그램 모듈 (105) 에 의해 생성될 수도 있다.
다음으로, 루틴 블록 710에서, ICB 드라이버 (103) 는 블록 705에서의 클라이언트 요청으로 제공되었던 마스터-슬레이브 쌍으로 슬레이브에 대한 탐색을 행할 수도 있다. ICB 드라이버 (103) 는 그 탐색을 수행하기 위하여 요청된 슬레이브에 대응하는 고유 식별자를 이용할 수도 있다. 이 루틴 블록 710에서, ICB 드라이버 모듈 (103) 은 요청된 슬레이브에 대한 탐색을 행하기 위하여 도 4에 예시된 노드 아키텍처 (403) 를 활용할 것이다. 이 루틴 블록 710의 추가의 세부사항들은 도 8에 관련하여 아래에서 설명될 것이다. 보통, 도 2에 예시된 바와 같은 대응하는 CPU (110) 상에 상주할 수도 있는 상위 계층 ICB ("UL ICB") 드라이버 (103A) 는 이 루틴 블록 710의 단계들을 수행할 수도 있다.
루틴 블록 710 후, 블록 715에서, ICB 드라이버 모듈 (103) 은 루틴 블록 710에서 행해졌던 탐색에 기초하여 마스터-슬레이브 쌍에 대해 스위치 패브릭들 (107) 내에서 그리고 스위치 패브릭들 (107) 에 걸쳐 루트를 생성할 것이다. 이 루트는 마스터 이를테면 도 4에 예시된 바와 같은 제 5 마스터 M5 (110D) 를 보통 포함하는 시작 포인트를 열거할 것이다. 그 루트는 또한 선택된 마스터-슬레이브 쌍 사이에서 통신들을 확립하기 위해 횡단될 것인 도 4에 예시된 바와 같은 3 개의 세그먼트들 (A, B, 및 C) 을 포함할 것이다.
다음으로, 블록 720에서, 상이한 스위치 패브릭들 (107) 내에 그리고/또는 그 스위치 패브릭들 (107) 에 걸쳐 존재할 수도 있는 마스터-슬레이브 쌍을 형성하는 특정 노드들을 열거하는 핸들 또는 어레이는, 클라이언트 요청을 발생했던 애플리케이션 프로그램 모듈 (105) 로 다시 제공될 것이다. 그 뒤에, 루틴 블록 725에서, ICB 드라이버 모듈 (103) 은 임의의 스위치 패브릭들 (107) 내에서 그리고 그 스위치 패브릭들 (107) 에 걸쳐 확립된 루트의 대역폭을 설정할 수도 있다. 이 루틴 블록 725에 따르면, 하위 계층 ICB ("LL ICB") 드라이버 모듈 (103B) 은 이 루틴의 단계들을 실행할 것이다. RPM (102) 상에 상주하는 LL ICB 드라이버 모듈 (103B) 은 RPM 노드 (102) 로부터 패브릭 노드들 (407) 뿐만 아니라 도 4에 예시된 바와 같은 특정 패브릭 (107) 의 노드들로 커맨드들을 발행함으로써 확립된 루트에 걸쳐 대역폭들을 설정할 것이다. 루틴 블록 725에 관한 추가의 세부사항들은 도 9에 관련하여 더 상세히 설명될 것이다.
다음으로 블록 730에서, 클라이언트 요청 내의 요청된 액션은 그 후에 상이한 스위치 패브릭들 (107) 내에서 그리고 그 스위치 패브릭들 (107) 에 걸쳐 존재할 수도 있는 마스터-슬레이브 쌍에 의해 수행될 것이다. 방법 (700) 은 블록 705로 복귀되거나 또는 그것은 종료할 수도 있다.
도 8은 슬레이브 식별자를 이용하여 마스터-슬레이브 쌍의 슬레이브를 탐색하는 서브방법 또는 루틴 (715) 을 예시하는 논리 흐름도이다. 블록 805는 서브방법 또는 루틴 715의 제 1 단계이다. 블록 805에서, ICB 드라이버 모듈 (103A) 은, 클라이언트 요청으로부터 마스터-슬레이브 쌍의 요청된 슬레이브를 식별하기 위해 특정 패브릭 (107) 내에서 어떤 슬레이브들에게 질의할지를 결정하기 위하여, 패브릭 루트 점검 테이블, 이를테면 5 및 도 6에서 각각 예시된 테이블 (500) 및 테이블 (600) 을 검토한다.
다음으로, 블록 810에서, ICB 드라이버 모듈 (103A) 은 요청된 슬레이브의 슬레이브 식별자와 루트 점검 테이블에서 열거된 슬레이브 식별자를 비교할 수도 있다. 다음으로, 결정 블록 815에서, ICB 드라이버 모듈 (103A) 은 현재 슬레이브 식별자들 사이에 매칭하는 것이 있는지를 결정한다. 결정 블록 815에 대한 조회 (inquiry) 가 긍정적이면, "예" 분기가 블록 825로 이어진다. 결정 블록 815에 대한 조회가 부정적이면, "아니오" 분기가 결정 블록 820으로 이어진다.
블록 825에서, ICB 드라이버 (103A) 는 매칭된 슬레이브에 도달하도록 횡단된 루트를 기록한다. 이 루트는 하나 이상의 상이한 스위치 패브릭들 (107) 을 횡단하는 단일 스위치 패브릭 (107) 또는 통신 세그먼트들 내에서만 발생하는 통신 세그먼트들을 포함할 수도 있다. 다음으로, 블록 830에서, ICB 드라이버 모듈 (103A) 은 애플리케이션 프로그램 모듈 (105) 에 의해 발행된 클라이언트 요청에 포함되었던 마스터-슬레이브 쌍을 확립하기 위해 횡단되는 노드들 모두를 열거하는 핸들 또는 어레이를 반환할 수도 있다. 서브방법 또는 루틴 715는 그 후에 도 7의 단계 715로 복귀한다.
결정 블록 815의 부정적 상황이 도달되는 경우에 발생하는 결정 블록 820을 다시 참조하면, ICB 드라이버 모듈 (103A) 은 특정 스위치 패브릭의 슬레이브들 모두가 요청된 슬레이브를 위해 질의되었는지를 결정한다. 결정 블록 820에 대한 조회가 부정적이면, "아니오" 분기가 블록 805로 다시 이어진다. 결정 블록 820에 대한 조회가 긍정적이면, "예" 분기가 블록 835로 이어지고 그 블록에서는 ICB 드라이버 모듈 (103A) 이 게이트웨이 노드, 이를테면 도 4에 예시된 바와 같은 게이트웨이 노드 G2 (402A1) 로 진행한다.
다음으로, 블록 840에서, 게이트웨이 식별자는 ICB 드라이버 모듈 (103A) 에 의해 저장된다. 블록 845에서의 ICB 드라이버 모듈 (103A) 은 다음의 스위치 패브릭 (107), 이를테면 제 2 스위치 패브릭 (107B) 으로 진입하고, 블록 805로 복귀함으로써 새로운 탐색을 시작한다. 블록 845는 제 1 게이트웨이 노드 G1A (400B1) 를 마스터로서 활용하는 ICB 드라이버 모듈 (103A) 에 일반적으로 대응할 수도 있다. 블록 805에서, 제 1 게이트웨이 G1A (400B1) 가 탐색을 위해 활용 중인 현재 마스터라고 가정하면, ICB 드라이버 모듈 (103A) 은 도 6에 예시된 바와 같은 패브릭 루트 점검 테이블 (600) 의 제 3 행을 조사할 것이다.
아래에서 더 상세히 설명될 바와 같이, 방법 (700) 과 시스템 (101) 은 스위치 패브릭들 (107) 내에서 그리고 스위치 패브릭들 (107) 에 걸쳐 대역폭을 관리하기 위해 특정한 메트릭들을 활용한다. 도 9a 및 도 9b는 보통은 특정 프로세서 (110) 상에서 가동 중인 애플리케이션 프로그램 모듈 (105) 에 의해 발행된 임의의 소프트웨어 요청의 부분인 대역폭 요건들을 관리하기 위해 방법 (700) 및 시스템 (101) 에 의해 사용된 메트릭들을 예시한다.
구체적으로는, 도 9a는 예시적인 제 1 소프트웨어 요청 유형 (401) 을 도시한다. 이 제 1 소프트웨어 요청 유형 (401) 은 "버스티 (bursty)"로서 특징화된 것으로부터 유래할 수도 있다. 각각의 소프트웨어 요청, 이를테면 제 1 "버스티" 소프트웨어 요청 유형 (401) 은, 다음의 2 개의 상이한 메트릭들: 순간 대역폭 (instantaneous bandwidth; Ib) 및 평균 대역폭 (average bandwidth; Ab) 으로 측정될 수도 있다.
순간 대역폭 (Ib) 은 스위치 패브릭 (107) 에 대한 마스터-슬레이브 계층구조에서 모든 마스터들에 걸친 스위치 패브릭 (107) 에 대한 최악의 경우의 필요/시나리오를 나타낼 수도 있다. Ib 는 버스 또는 스위치 패브릭의 "제한 속도 (speed limit)"로서 일반적으로 특징화될 수도 있는데, 이 파라미터가 스위치 패브릭들 (107) 의 주파수를 설정하기 위해 ICB 드라이버 모듈 (103) 에 의해 사용될 수도 있어서이다. Ib 를 결정하기 위한 계산 및/또는 대응하는 식은 특정 애플리케이션 프로그램 모듈 (105) 로부터 유래하는 소프트웨어 요청의 각각의 유형마다 고유할 수도 있다.
평균 대역폭 (Ab) 은 하나 이상의 스위치 패브릭들 (107) 을 통해 전파되는 실제 데이터 사이즈를 나타낼 수도 있다. Ab 는 하나 이상의 스위치 패브릭들 (107) 에 대한 마스터들과 슬레이브들 간에서 중재 규칙들을 설정하기 위해 ICB 드라이버 모듈 (103) 에 의해 사용될 수도 있다.
제 1 소프트웨어 요청 유형 (401) 은 하나 이상의 스위치 패브릭들 (107) 의 불연속적 사용에 대비하는 소프트웨어 요청들을 다루기 위해 "버스티"로서 특징화되었다. 이들 소프트웨어 요청 유형들은 스위치 패브릭들 (107) 을 통해 데이터의 큰 블록들을 매우 짧은 시간 간격들 내에서 송신한 다음, 일부 기간 동안 휴면 상태를 유지할 수도 있다. 휴면 스테이지는 데이터의 큰 블록들을 송신하는데 이용된 액티브 시간보다 보통은 더 오래 지속될 수도 있다.
제 1 "버스티" 소프트웨어 요청 유형 (401) 에 대해, Ib 값은 다음 식에 의해 결정될 수도 있다:
식 1: Ib = BS/W
여기서 "Ib" 는 순간 대역폭이며; "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "W" 는 시간 단위들, 이를테면 밀리초로 나타내는 윈도우 사이즈이다.
제 1 "버스티" 소프트웨어 요청 유형에 대한 Ab 값은 다음 식에 의해 결정될 수도 있다:
식 2: Ab = BS/P
여기서 "Ab" 는 평균 대역폭이며; "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "P" 는 시간 단위들, 이를테면 밀리초로 나타내는 기간이다.
도 9a는 2 개의 상이한 "버스티" 소프트웨어 요청들 (401A, 401B) 을 예시한다. 제 1 소프트웨어 요청 (401A) 은 제 1 데이터 블록 (402A) 을 가지는 반면 제 2 소프트웨어 요청 (401B) 은 제 2 데이터 블록 (402B) 을 가진다.
이 예시적인 실시형태에서, 제 1 및 제 2 기간들 P1 (404A), P2 (404A) 의 크기는 동일한 반면, 제 1 및 제 2 윈도우들 W1 (406A), W2 (406B) (이들은 기간들 (P1 및 P2) 내의 시간 프레임들임) 은 서로에 대해 상이한 크기들을 가진다. 제 1 및 제 2 블록 사이즈들 BS1 (408A), BS2 (408B) 은 또한 서로에 대해 상이한 크기들을 가진다.
제 1 블록 사이즈 BS1 (402A) 의 크기가 제 1 기간 P1 (404A) 에 비해 상대적으로 작으므로, 제 1 버스티 소프트웨어 요청 (401A) 에 대한 평균 대역폭 (Ab) 값은 이 소프트웨어 요청 유형에 대해 식 (2) 의 관점에서 중요한 것이 아닐 것이다. 한편, 제 2 블록 사이즈 BS2 (402B) 의 크기가 제 2 기간 P1 (404B) 에 비해 상대적으로 크므로, 제 2 버스티 소프트웨어 요청 (401B) 에 대한 평균 대역폭 (Ab) 값은 제 1 소프트웨어 요청 (401A) 보다 약간 더 클 것이다.
각각의 소프트웨어 요청 (401A, 401B) 에 대한 블록 사이즈들 (BS) 이 이들의 윈도우 사이즈들 W1 (406A), W2 (406B) 에 가까운 크기들을 가지기 때문에, 이들 2 개의 요청들 (401) 에 대한 순간 대역폭 값들 (Ib) 은 이 소프트웨어 요청 유형에 대해 식 (1) 의 관점에서 중요할 수도 있다. 이들 요청들 (401A, 401B) 에 대한 양쪽 모두의 Ib 값들이 또한 서로에 대해 크기가 매우 가까울 수도 있다.
도 9b는 "CPU" 유형 (501) 으로 특징화될 수도 있는 예시적인 제 2 소프트웨어 요청 유형 (501) 을 도시한다. CPU 소프트웨어 요청 유형들 (501) 은 보통 중앙 프로세싱 유닛들 (CPU들) (110) 로부터 유래한다. 순간 대역폭 (Ib) 값은 다음과 같이 결정될 수도 있다:
식 3: Ib = 스루풋 대역폭
여기서 "Ib" 는 순간 대역폭이고; 스루풋 대역폭은 CPU (110) 의 소망의 클록 속도이다.
CPU 소프트웨어 요청 유형들 (501) 에 대한 평균 대역폭 (Ab) 값은 다음과 같이 결정될 수도 있다:
식 4: Ab = T × Z% (백분율)
여기서 "Ab" 는 평균 대역폭이며; "T" 는 위에서 설명된 스루풋 대역폭이고; "Z%" 는 도 9b에 예시된 바와 같이, 사용의 백분율, 또는 캐시 미스들 (cache misses) 의 백분율이다.
예를 들어, 50%의 사용율로 초 당 100 Mb로 데이터를 이동시키는 DMA 엔진 (109) 의 경우, 평균 대역폭 (Ab) 값은 초 당 50 Mb인 100 × 0.50와 동일할 것이다. 이 DMA 엔진 (109) 에 대한 순간 대역폭 (Ib) 은 초 당 100 Mb와 동일할 것이다.
한편, 1 GHz로 가동 중인 CPU (110) 는 초 당 800 Mb의 스루풋으로 해석된다. 이 스루풋 값은 순간 대역폭 (Ib) 과 동일할 것이다. CPU (110) 가 10%의 캐시 미스 레이트로 캐시를 활용한다면, 평균 대역폭 (Ab) 값은 초 당 80 Mb 인 (800 × 0.10) 과 동일할 것이다.
당업자는 다른 소프트웨어 요청 유형들이 순간 대역폭 (Ib) 및 평균 대역폭 (Ab) 값들의 측면에서 상이하게 정의될 수도 있다는 것을 인식할 것이다. 이러한 언젠가는 결정되어야 하는 소프트웨어 요청 유형들은 Ib 및 Ab 값들에 도달하기 위한 상이한 식들을 포함할 수도 있다. 하지만 소프트웨어 요청 유형들이 Ib 및 Ab 값들의 측면에서 표현될 것이기 때문에, 상이한 소프트웨어 요청 유형들은 버스 (107) 에 대한 현재의 요구의 양호한 추정을 ICB 드라이버 모듈 (103) 에 제공하기 위해 함께 종합될 수도 있다.
도 9c는 PCD (100) 의 소프트웨어 요청들로부터의 현재의 요구에 기초하여 버스 또는 스위치 패브릭 설정들을 동적으로 조정하기 위한 (도 7에 대응하는) 서브방법 또는 루틴 (725) 을 예시하는 논리 흐름도이다. 이 서브방법 (725) 의 경우, 보통 도 2에 예시된 바와 같이 RPM (102) 상에 상주하는 LL ICB 드라이버 모듈 (103B) 은 이들 단계들을 수행할 것이다. 그러나, 당업자는 CPU들 (110) 상에 상주하는 UL ICB 드라이버들 (103A) 이 또한 본 개시물의 범위로부터 벗어남 없이 사용될 수도 있다는 것을 인식한다.
결정 블록 915는 서브방법 (725) 의 제 1 단계이다. 블록 915에서, ICB 드라이버 모듈 (103B) 은 소프트웨어 요청이 표준화된 순간 대역폭 (Ib) 및 평균 대역폭 (Ab) 값들로 변환될 필요가 있는지를 결정한다. 결정 블록 915에 대한 조회가 부정적이면, "아니오" 분기가 블록 925로 이어진다. 결정 블록 915에 대한 조회가 긍정적이면, "예" 분기가 블록 920으로 이어진다.
블록 920에서, ICB 드라이버 모듈 (103B) 은 소프트웨어 요청 유형 및 대응하는 식들, 이를테면 도 9a 및 도 9b에 관련하여 위에서 설명된 식 (1) 내지 식 (4) 에 기초하여, 소프트웨어 요청의 대역폭 파라미터들을 순간 대역폭 (Ib) 및 평균 대역폭 (Ab) 값들로 변환한다.
블록 925에서, ICB 드라이버 모듈 (103B) 은 PCD (100) 의 개별 마스터들 (110) 에 의해 발행된 모든 소프트웨어 요청들에 대해 모든 평균 대역폭 (Ab) 값들의 합을 계산한다. 다음으로, 블록 930에서 ICB 드라이버 모듈 (103B) 은 2 개의 값들 사이의 최대치를 결정한다: 모든 소프트웨어 요청들에 대한 모든 평균 대역폭 (Ab) 값들의 합 (이것은 블록 925에서 계산된 값이다) 에 비교되는 최대 순간 대역폭 (Ib) 값.
다음으로, 블록 935에서, ICB 드라이버 모듈 (103B) 은 블록 930에서 계산된 최대 값 (단일 최대 Ib 값과 모든 Ab 값들의 합 사이의 최대 값) 에 기초하여 버스 주파수를 설정한다. 블록 940에서, ICB 드라이버 모듈 (103B) 은 모든 소프트웨어 요청들에 걸친 합산된 평균 대역폭 (Ab) 및 블록 935에서 확립된 클록 주파수 값에 기초하여 버스 (107) 에 대한 버스 중재 구성을 설정한다.
블록 945에서, ICB 드라이버 모듈 (103B) 은 버스 주파수 및 버스 중재 구성을 각각의 스위치 패브릭 (107) 으로 송신한다. 그 다음에, 서브방법 (725) 은 블록 730으로 복귀한다.
도 9d는 마스터-슬레이브 쌍이 시스템 (101) 및 방법 (700) 에 의해 생성되는 경우에 형성된 핸들들 또는 어레이 데이터 구조들 (1002) 을 예시하는 다이어그램이다. 핸들들 (1002) 은 도 4에 예시된 노드들에 관련하여 ICB 드라이버 모듈 (103B) 에 의해 사용된다. 도 4에 예시된 각각의 노드에는 형성되는 마스터-슬레이브 쌍에 대한 핸들 (1002) 이 제공된다. 도 9d에 예시된 특정 세트의 핸들들 (1002) 은 도 4에 예시된 바와 같은 제 1 스위치 패브릭 (107A) 의 제 5 마스터 M5 (110D) 와 제 2 스위치 패브릭 (107D) 의 제 3 슬레이브 S3 (113) 사이의 마스터-슬레이브 쌍 형태에 대응한다.
도 4의 마스터-슬레이브 쌍 (M5/S3) 에 대한 제 1 핸들 (1002A) 은, 도 9d에 예시된 바와 같이, 제 1 스위치 패브릭 (107A) 의 중재자 노드 (405) 에 할당된다. 제 2 핸들 (1002B) 은 도 4에 예시된 제 1 스위치 패브릭 (107) 의 제 5 마스터 M5 (110D) 에 할당될 것이다. 마찬가지로, 제 3 핸들 (1002C) 은 도 4의 제 1 스위치 패브릭 (107A) 의 제 2 게이트웨이 G2 (402A1) 에 할당될 것이다. 제 4 핸들 (1002D) 은 도 4의 제 2 스위치 패브릭 (107A) 의 제 1 게이트웨이 G1A (400B1) 등에 할당될 것이다.
각각의 핸들 (1002) 은 핸들 (1002) 에 할당된 현재 노드와, 현재 노드로부터 정보를 수신하기 위한 또는 정보를 현재 노드로 송신하기 위한 것인 다른 노드를 포함할 수도 있다. 예를 들어, 제 2 핸들 (1002B) 은 제 1 스위치 패브릭 (107A) 의 제 5 마스터 (110D) 에 대응하는 할당된 노드 (M5) 와 제 1 스위치 패브릭 (107A) 의 제 2 게이트웨이 노드 G2 (402A1) 를 포함할 수도 있다.
마찬가지로, 제 4 핸들 (1002D) 은 제 4 핸들 (1002D) 이 할당되는, 제 2 스위치 패브릭 (107B) 의 제 1 게이트웨이 G1A (400B1) 인 현재 노드를 포함할 수도 있다. 제 4 핸들 (1002D) 은 제 1 스위치 패브릭 (107A) 의 제 2 게이트웨이 G2 (402A1) 를 더 포함할 수도 있다. 제 4 핸들 (1002D) 은 제 1 스위치 패브릭 (107A) 의 제 2 게이트웨이 노드 G2 (402A1) 와 제 2 스위치 패브릭 (107B) 의 제 1 게이트웨이 노드 G1A (400B1) 사이에 존재하는 도 4의 통신 세그먼트 "B"에 대응한다. 이들 핸들들 (1002) 의 각각은 ICB 드라이버 모듈 (103) 에 의해 메모리에 저장될 수도 있다.
아래에서 설명되는 바와 같은 도 10a 내지 도 13은 도 4의 노드 아키텍처가 확립되고 유지되는 방법을 설명하기 위해 제공된다. 도 10a는 도 4에 예시된 노드 아키텍처를 확립하고 유지하기 위한 소프트웨어 아키텍처 (500A) 의 제 1 양태의 다이어그램이다.
도 10a는 소프트웨어 또는 하드웨어 (또는 양쪽 모두) 를 나타내는 기능 블록도들을 포함하는 다이어그램이다. 도 10a는, 이를테면, ICB 드라이버 모듈 (103); 제 1 하드웨어 엘리먼트 (하드웨어 엘리먼트 #1) 라고도 또한 일반적으로 지칭되는 중앙 프로세싱 유닛 (110); 제 2 하드웨어 엘리먼트 (하드웨어 엘리먼트 #2) 라고도 또한 일반적으로 지칭되는, CPU (110) 용 클록 (442); 제 3 하드웨어 엘리먼트 (하드웨어 엘리먼트 #3) 라고도 또한 일반적으로 지칭되는 버스 중재자 또는 스케줄러 (422); 제 1 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #1) 라고도 또한 일반적으로 지칭되는 버스 프로그램 A (444A); 제 2 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #2) 라고도 또한 일반적으로 지칭되는 버스 프로그램 B (444B); 제 3 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #3) 라고도 일반적으로 지칭되는 클록 프로그램 (AHB); 키누름 (448) 으로서 일반적으로 나타내는 소프트웨어 엘리먼트에 의해 모니터링되는 액션 또는 기능; 및 소프트웨어 엘리먼트 또는 하드웨어 엘리먼트 또는 양쪽 모두를 포함하는 레거시 엘리먼트 (450) 와 같은 (그러나 이들로 제한되지 않는다) 복수의 하드웨어 및 소프트웨어 엘리먼트들에 연결되는 아키텍처 또는 프레임워크 관리자 (440) 를 예시한다.
레거시 소프트웨어 엘리먼트의 일 예는 동적 환경 관리자 (Dynamic Environment Manager; DEM) 를 포함할 수도 있으나 이들로 제한되지 않는다. 이는 프로세서 슬립 이벤트들의 프로세서간 통지를 핸들링하는 소프트웨어 모듈이다. 예를 들어, 제 1 프로세서 (A) 는 제 2 프로세서 (B) 가 유휴상태로 갔다/유휴상태로부터 복귀했다는 통지를 DEM을 이용하여 수신한다. 보다 새로운 하드웨어 상에서는, 이 소프트웨어 기능이 루트 프로세서 모듈 (route processor module; RPM) 서브시스템/통신 프로토콜 내에 포함되고 있다. 다른 레거시 소프트웨어 엘리먼트들이 존재하고 본 발명의 범위 내에 포함된다.
레거시 하드웨어 엘리먼트의 일 예는 AMBA (Advanced Microcontroller Bus Architecture) 고성능 버스 (AHB) 를 포함할 수도 있으나 이들로 제한되지 않는다. 보다 이전의 PCD들 (100) 상에서, AHB는 1 차 시스템 버스를 포함할 수도 있는 반면, 보다 새로운 PCD들 (100) 상에서, 시스템 버스 패브릭 (107) 은 완전히 상이하고 AHB 버스는 새로운 시스템 버스 패브릭을 통해 통신하기 위해 아직 업데이트되지 않은 모듈들과 통신하는 특수한 애플리케이션들을 위해서만 사용된다. 다른 레거시 하드웨어 엘리먼트들이 존재하고 본 발명의 범위 내에 포함된다.
프레임워크 관리자 (440) 는 앞서 언급된 하드웨어 및 소프트웨어 엘리먼트들의 각각과 통신하는 노드들과 같은 데이터 구조들을 관리하는 컴퓨터 명령들의 라이브러리를 포함할 수도 있다. 프레임워크 관리자 (440) 는 도 10a의 파선 A의 우측에 도시된 바와 같은 노드들 (602, 622, 642, 및 646) 을 형성할 수도 있는 하나 이상의 자원들을 생성하는 것을 담당하게 될 수도 있다.
프레임워크 관리자 (440) 는 CPU (110) 상에 상주하는 각각의 ICB 드라이버 모듈 (103) 과 직접 통신할 수도 있다. 도 10a의 우측의 각각의 노드 (602, 622, 642, 및 646) 는 도 10a의 파선 A의 좌측의 각각의 소프트웨어 또는 하드웨어 엘리먼트의 표현 또는 모델이다. 도 10a의 우측은 위에서 설명된 도 4에서 반영된 노드 아키텍처에 일반적으로 대응한다. 본 개시물의 나머지에 대해, 일반적인 또는 비특정 노드가 도 10b에 예시된 바와 같은 참조 부호 601 로 지정될 것이다.
이전에 언급했듯이, 도 10a의 각각의 예시적인 노드 (602, 622, 642, 및 646) 는 하나 이상의 자원들을 포함할 수도 있다. 자원은 소프트웨어 엘리먼트 또는 하드웨어 엘리먼트 또는 양쪽 모두를 포함할 수도 있다. 예를 들어, 제 1 노드 (602) 는 제 1 하드웨어 엘리먼트 또는 중앙 프로세싱 유닛 (110) 과 일반적으로 대응하는 단일 자원을 포함한다. 본 개시물에서 설명된 소프트웨어 아키텍처로, 노드 (601) 의 각각의 자원에는 하나 이상의 영숫자 캐릭터들을 포함하는 고유한 이름이 제공될 수도 있다. 도 10a에 도시된 예시적인 실시형태에서, 제 1 노드 (602) 의 자원에는 "core/cpu"라는 자원 이름이 할당되었다. 이 예시적인 자원 이름은 일반적으로 당업자에게 알려진 기존의 파일 명명 구조들에 대응한다. 그러나, 당업자에 의해 인식될 바와 같이, 영숫자 캐릭터들 및/또는 기호들의 임의의 다른 조합을 포함하는 자원 이름들의 다른 유형들은 또한 본 발명의 범위 내에 있다.
도 10a의 예시적인 실시형태에서, 제 2 노드 (622) 는 복수의 자원들을 포함한다. 구체적으로는, 이 특정한 예시적인 실시형태에서, 제 2 노드 (622) 는 버스 중재자 또는 스케줄러 (422) 에 대응하는 단일 하드웨어 엘리먼트를 포함하는 제 1 자원을 가진다. 제 2 노드 (622) 의 제 2 자원은 버스 프로그램 A (444A) 의 제 1 소프트웨어 엘리먼트에 일반적으로 대응하는 소프트웨어 엘리먼트를 포함한다. 제 2 노드 (622) 의 제 3 자원은 버스 프로그램 B (444B) 의 제 2 소프트웨어 엘리먼트에 일반적으로 대응하는 다른 소프트웨어 엘리먼트를 포함한다. 당업자는 주어진 노드 (601) 에 대한 임의의 조합 및 임의의 수의 자원들 및 자원 유형들이 역시 본 발명의 범위 내에 있다는 것을 인식한다.
노드들 (601) 을 생성하는 것 외에도, 프레임워크 관리자 (440) 는 또한 마커들 (650) 을 생성하거나 또는 인스턴스화할 수도 있다. 마커는 프레임워크 관리자 (440) 에 의해 관리되는 소프트웨어 아키텍처와 쉽사리 호환되지 않거나 쉽사리 자신들을 매핑하지 않는 하나 이상의 레거시 엘리먼트들, 이를테면 하드웨어 엘리먼트 또는 소프트웨어 엘리먼트 (또는 양쪽 모두뿐만 아니라 복수의 이들 엘리먼트들) 를 포함할 수도 있다. 마커 (650) 는 노드 (601) 의 자원을 지원할 수 있으며 이는 노드 (601) 의 자원이 마커 (650) 에 의존될 수도 있다는 것을 의미한다. 마커 (650) 의 하나의 예는 스트링 드라이버를 포함할 수도 있다. 스트링 드라이버는 도 10a에 관련하여 설명된 아키텍처 내에 쉽사리 맞지 않을 수도 있다. 마커 (650) 는 노드 (601) 및 도 11의 블록 1125에서 수집된 그의 의존성 어레이 데이터에 의해 참조될 수도 있다.
도 10a는 또한 2 개의 소프트웨어 엘리먼트들 (448, 450) 의 액션 또는 기능에 일반적으로 대응하는 제 1 클라이언트 (648) 를 예시한다. 도 10a에 도시된 예시적인 실시형태에서, 제 1 클라이언트 (648) 는 일반적으로 휴대용 컴퓨팅 디바이스 (100) 에 의해 지원되는 특정 애플리케이션 프로그램 모듈 (105) 내에서 발생할 수도 있는 키누름 액션에 대응한다. 그러나, 당해 기술분야의 통상의 지식을 가진 자는 소프트웨어 엘리먼트들의 다른 액션들 및/또는 기능들 역시 본 발명의 범위 내에 있다는 것을 인식한다. 클라이언트 요청들 (648) 및 이들의 개별 생성에 관한 추가의 세부사항들은 도 13에 관련하여 아래에서 상세히 설명될 것이다.
도 10a는 또한 특정 아키텍처적 엘리먼트들 사이의 관계들을 예시한다. 예를 들어, 도 10a는 클라이언트 (648) 와 제 1 노드 (602) 사이의 관계를 예시한다. 구체적으로는, 제 1 클라이언트 (648) 는 자원 "/core/cpu"를 포함하는 제 1 노드 (602) 에 의해 관리되거나 또는 핸들링되는, 파선들로 도시된 클라이언트 요청 (675A) 을 생성할 수도 있다. 보통, 소정의 또는 설정된 수의 유형들의 클라이언트 요청들 (675) 이 있다. 클라이언트 요청들 (675) 은 도 13에 관련하여 아래에서 더 상세히 설명될 것이다.
도 10a에서 표시되는 다른 관계들은 파선들 (680) 로 도시된 의존성들을 포함한다. 의존성들은 다른 노드 (601) 의 개별 자원들 사이의 관계들이다. 의존성 관계는 보통 제 1 자원 (A) 에 정보를 제공할 수도 있는 제 2 자원 (B) 에 제 1 자원 (A) 이 의존한다는 것을 나타낸다. 이 정보는 제 2 자원 (B) 에 의해 수행된 동작의 결과일 수도 있거나 또는 그것은 단순히 제 1 자원 (A) 에 의해 필요하게 되는 스테이터스 정보 또는 이들의 임의의 조합을 포함할 수도 있다. 제 1 자원 (A) 및 제 2 자원 (B) 은 동일한 노드 (601) 의 부분일 수도 있거나 또는 이들은 상이한 노드들 (601) 의 부분일 수도 있다.
도 10a에서, 제 1 노드 (602) 는 제 1 노드 (602) 에서 비롯되고 제 2 노드 (622) 로 연장하는 의존성 화살표 (680B) 에 의해 나타낸 바와 같이 제 2 노드 (622) 에 의존한다. 도 10a는 제 1 노드 (602) 가 또한 의존성 화살표 (680A) 에 의해 예시된 바와 같이 제 3 노드 (642) 에 의존한다는 것을 또한 예시한다. 도 10a는 제 2 노드 (622) 가 또한 의존성 화살표 (680C) 에 의해 예시된 바와 같이 제 3 노드 (646) 에 의존한다는 것을 또한 예시한다. 당해 기술분야의 통상의 지식을 가진 자는 도 10a의 파선 화살표들로 도시된 의존성들 (680) 이 단지 사실상 예시적인 것이라는 것과 개별 노드들 (601) 사이의 의존성들의 다른 조합들이 본 발명의 범위 내에 있다는 것을 인식한다.
아키텍처 또는 프레임워크 관리자 (440) 는 도 10a에 예시된 클라이언트 요청들 (675) 및 의존성들 (680) 을 포함하지만 이들로 제한되지 않는, 위에서 설명된 관계들을 유지하는 것을 담당한다. 프레임워크 관리자 (440) 는 임의의 주어진 노드 (601) 에 대한 의존성들 (680) 이 완전한 한 그것이 할 수 있는 한 많은 노드들 (601) 을 인스턴스화하거나 또는 생성하려고 시도할 것이다. 의존성 (680) 은, 의존성을 지원하는 자원이 존재하거나 또는 의존성 (680) 에 관계하는 정보를 핸들링하기 위한 준비 상태에 있는 경우에 완전하다.
예를 들어, 단일 자원 "/clk/cpu"를 포함하는 제 3 노드 (642) 가 제 1 노드 (602) 와 제 3 노드 (642) 사이에 존재하는 의존성 관계 (680A) 때문에 생성되지 않았다면, 단일 자원 "/core/cpu"를 포함하는 제 1 노드 (602) 는 프레임워크 관리자 (440) 에 의해 생성되지 않거나 또는 확립되지 않을 수도 있다. 일단 제 3 노드 (642) 가 프레임워크 관리자 (440) 에 의해 생성되지 않았다면, 프레임워크 관리자 (440) 는 의존성 관계 (680A) 때문에 제 2 노드 (602) 를 생성할 수도 있다.
프레임워크 관리자 (440) 가 특정 노드 (601) 를 그의 의존성들 (680) 중 하나 이상이 불완전하기 때문에 생성하거나 또는 인스턴스화하는 것이 가능하지 않다면, 프레임워크 관리자 (440) 는 프레임워크 관리자 (440) 에 의해 성공적으로 생성되었던 그들 노드들 (601) 에 대응하는 단계들을 계속 동작시킬 것이거나 실행시킬 것이다. 프레임워크 관리자 (440) 는 의존성 자원들이 불완전한 스테이터스를 반영하는 호출에 대해 메시지들을 생성하고 반환하지 않은 불완전한 의존성들로 인해 존재하지 않을 수도 있는 특정 노드 (601) 에 대한 호출을 보통 건너뛸 것이다.
이를테면 도 1에 예시된 멀티코어 환경에서, 프레임워크 관리자 (440) 는 도 1의 제 1, 제 2 및 제 N 코어들 (222, 224, 및 226) 과 같은 별개의 코어들에 대해 노드들 (601) 을 생성하거나 또는 인스턴스화할 수도 있다. 노드들 (601) 이 서로 의존하지 않는 한 그리고 특정 노드의 대응하는 의존성들 모두가, 아래에서 설명되는 바와 같이, 완전하다면, 노드들 (601) 은 별개의 코어들에 대한 멀티코어 환경에서 그리고 병렬로 일반적으로 생성될 수도 있다.
도 10b는 도 1의 PCD (100) 의 자원들을 관리하는 시스템에 대한 소프트웨어 아키텍처 (500B1) 의 제 2 양태의 일반적인 다이어그램이다. 이 일반적인 다이그램에서, 각각의 노드 (601) 의 하나 이상의 자원들에는 고유한 이름들이 제공되지 않았다. 도 10b의 노드 또는 자원 그래프 (500B1) 는 아키텍처 또는 프레임워크 관리자 (440) 에 의해 지원되는 노드들 (601), 마커들 (650), 클라이언트들 (648), 이벤트들 (690), 및 쿼리 기능들 (695) 만을 포함한다. 각각의 노드 (601) 는 노드 (601) 내의 자원들 사이의 개별 의존성들을 표현하는 특정한 방향들을 갖는 타원 형상 및 화살표들 (680) 로 예시되었다.
도 10a 및 도 10b에 예시된 노드 아키텍처 내의 호출들은 노드 (601) 내의 자원의 별칭, 또는 실제 자원 이름으로 만들어질 수도 있다. 하나의 예시적인 실시형태에 따르면, 마커 (650) 에 대해 클라이언트 요청 (675) 을 하는 방법이 없는데, 이는 클라이언트들 (648) 과 마커들 (650) 사이에 인터페이스가 없고 그래서 이는 일반적으로 마커들 (650) 과 교환된 정보가 보통 노드 (601) 또는 자원으로부터 유래되고 클라이언트 (648) 로부터 유래되지 않음을 의미하기 때문이다.
예를 들어, 도 10b의 제 1 노드 (601A) 는 제 1 노드 (601A) 가 제 2 노드 (601B) 의 2 개의 자원들 (자원들 #2 및 #3) 에 의존한다는 것을 나타내는 의존성 화살표 (680A) 를 가진다. 마찬가지로, 제 1 노드 (601A) 는 제 1 노드 (601A) 가 또한 하드웨어 또는 소프트웨어 또는 이들의 조합의 레거시 엘리먼트를 통상 포함하는 제 1 마커 (650) 에 의존한다는 것을 나타내는 의존성 화살표 (680B) 를 가진다.
도 10b는 또한 제 1 노드 (601A) 의 클라이언트 (648) 가 클라이언트 요청 (675) 을 제 1 노드 (601A) 로 발행할 수도 있는 방법을 예시한다. 이들 클라이언트 요청들 (675) 이 발행된 후, 제 2 노드 (601B) 는 이벤트 (690) 를 트리거하거나 또는 쿼리 (695) 에 응답을 제공할 수도 있어서, 이벤트 (690) 및 쿼리 (695) 에 대응하는 메시지들이 클라이언트 (648) 로 반환된다.
도 10c는 도 1의 PCD (100) 의 자원들을 관리하는 시스템에 대한 소프트웨어 아키텍처 (500B2) 의 제 2 양태의 특정 다이어그램이다. 도 10c는 특정된, 여전히 예시적인 자원 이름들 뿐만 아니라 도 10a의 이들에 대응하는 클라이언트들 (648), 이벤트들 (690), 및 쿼리 기능들 (695) 을 갖는 노드들 (601) 만을 포함하는 노드 또는 자원 그래프 (500B2) 를 예시한다. 각각의 노드 (601) 는 노드 (601) 내의 자원들 사이의 개별 의존성들을 표현하는 특정한 방향들을 갖는 타원 형상 및 화살표들 (680) 로 예시되었다.
예를 들어, 제 1 노드 (602) 는 제 1 노드 (602) 가 제 2 노드 (622) 의 3 개의 자원들에 의존한다는 것을 나타내는 의존성 화살표 (680B) 를 가진다. 마찬가지로, 제 2 소프트웨어 엘리먼트 (444B) 를 포함하고 도 10c에서 참조 문자 "C"로 일반적으로 지정된 제 3 자원 "/bus/ahb/sysB/"는 이 제 3 자원 (C) 이 제 4 노드 (646) 의 단일 "/clk/sys/ahb" 자원에 의존한다는 것을 나타내는 의존성 화살표 (680C) 를 가진다.
도 10c는 또한 하나 이상의 이벤트들 (690) 또는 쿼리 기능들 (695) 을 포함할 수도 있는, 노드들 (601) 로부터의 출력 데이터를 예시한다. 쿼리 기능 (695) 은 이벤트 (690) 와 유사하다. 쿼리 기능 (695) 은 고유할 수도 있거나 고유하지 않을 수도 있는 쿼리 핸들을 가질 수도 있다. 쿼리 기능은 일반적으로 위부에서 식별되지 않고 일반적으로 그것은 상태를 가지지 않는다. 쿼리 기능 (695) 은 노드 (601) 의 특정 자원의 상태를 결정하는데 사용될 수도 있다. 쿼리 기능 (695) 과 이벤트들 (690) 은 확립된 클라이언트 (648) 와의 관계들을 가질 수도 있고 이들 관계들은 개별 이벤트 (690) 및 쿼리 기능 (695) 으로부터의 정보가 특정 클라이언트 (648) 로 전해진다는 것을 나타내는 방향성 화살표들 (697) 에 의해 표현된다. 도 10c는 또한 도 10c의 제 2 노드 (622) 가 의존성 화살표 (680D) 를 통해 제 1 마커 (650) 에 의존하는 방법을 예시한다.
도 10b 및 도 10c의 노드 또는 자원 그래프들 (500B) 은, 메모리 내에 존재하고 프레임워크 관리자 (440) 와 노드들 (601) 을 포함할 수도 있는 관련된 데이터 구조들에 의해 관리되는 관계들을 나타낸다. 노드 또는 자원 그래프 (500B) 는 프레임워크 관리자 (440) 에 의해 관리되는 개별 엘리먼트들 사이의 관계들을 식별하기 위한 그리고 소프트웨어 팀에 의한 문제해결을 위한 유용한 도구로서 프레임워크 관리자 (440) 에 의해 자동으로 생성될 수 있다.
도 10d는, 이를테면 PCD (100) 의 자원(들)을 관리하기 위해 도 4에 예시된 소프트웨어 아키텍처를 생성하는 방법 (1000A) 을 예시하는 흐름도이다. 블록 1005는 PCD (100) 의 자원들을 관리하는 방법 또는 프로세스 (1000) 의 제 1 루틴이다. 루틴 블록 1005에서, 루틴은 노드 구조 데이터를 수신하기 위해 프레임워크 관리자 (440) 에 의해 실행되거나 또는 동작될 수도 있다. 노드 구조 데이터는 특정 노드 (601) 가 다른 노드들 (601) 과 가질 수도 있는 의존성들을 약술하는 의존성 어레이를 포함할 수도 있다. 노드 구조 데이터 및 이 루틴 또는 서브방법 (705) 에 관한 추가의 세부사항들은 도 11에 관련하여 아래에서 더 상세히 설명될 것이다.
다음으로, 블록 1010에서, 프레임워크 관리자 (440) 는 블록 1005에서 수신된 노드 구조 데이터의 부분인 의존성 데이터를 검토할 수도 있다. 결정 블록 715에서, 프레임워크 관리자 (440) 는 노드 구조 데이터가 리프 노드 (leaf node; 601) 를 정의하는지를 결정할 수도 있다. 리프 노드 (601) 는 일반적으로 노드 구조 데이터에 기초하여 생성될 노드가 어떠한 의존성도 갖지 않는다는 것을 의미한다. 결정 블록 1015에 대한 조회가 현재 노드를 생성하기 위한 노드 구조 데이터가 어떠한 의존성들도 갖지 않는다는 것을 의미하는 긍정적이면, 프레임워크 관리자 (440) 는 루틴 블록 1025로 계속된다.
결정 블록 1015에 대한 조회가 부정적이면, "아니오" 분기는 결정 블록 1020로 이어져 그 결정 블록에서 프레임워크 관리자는 노드 구조 데이터 내의 모든 하드 의존성들이 존재하는지를 결정한다. 하드 의존성은 자원이 그것 없이는 존재할 수 없는 것을 포함할 수도 있다. 한편, 소프트 의존성은 자원이 의존성 자원을 옵션의 단계로서 이용할 수도 있는 것을 포함할 수도 있다. 소프트 의존성은, 심지어 소프트 의존성이 존재하지 않는 경우에도 노드 아키텍처 내에 있는 경우에 소프트 의존성을 갖는 노드 (601) 또는 노드 (601) 의 자원이 생성되거나 또는 인스턴스화될 수도 있다는 것을 의미한다. 마커 (650) 는 위에서 설명된 바와 같은 소프트 의존성으로서 참조될 수도 있다.
소프트 의존성의 일 예는 다수의 자원들을 포함하는 지향된 자원 (601) 에 대한 동작에 대해 임계적이지 않은 최적화 특징을 포함할 수도 있다. 프레임워크 관리자 (440) 는 존재하는 모든 하드 의존성들에 대해 그리고 심지어 생성되지 않은 소프트 의존성들을 가지는 그들 노드들 또는 자원들에 대한 소프트 의존성이 존재하지 않는 경우에 노드 또는 자원을 생성하거나 또는 인스턴스화할 수도 있다. 콜백 (call back) 특징은 소프트 의존성을 참조하는데 이용될 수도 있어서 소프트 의존성이 프레임워크 관리자 (440) 에 대해 이용가능하게 되는 경우, 프레임워크 관리자 (440) 는 소프트 의존성을 참조하는 각각의 콜백에게 소프트 의존성들이 지금 이용가능하다는 것을 알려줄 것이다.
결정 블록 1020에 대한 조회가 부정적이면, "아니오" 분기가 블록 1027로 이어져서 그 블록에서 노드 구조 데이터는 메모리와 같은 임시 스토리지에 프레임워크 관리자 (440) 에 의해 저장되고 프레임워크 관리자 (440) 는 이 인스턴스화되지 않은 노드에 연관된 콜백 특징을 생성한다.
결정 블록 1015에 대한 조회가 긍정적이면, "예" 분기가 루틴 1025로 이어져서 그 루틴에서는 노드 (601) 가 루틴 블록 1005에서 수신된 노드 구조 데이터에 기초하여 생성되거나 또는 인스턴스화된다. 루틴 블록 1025의 추가의 세부사항들은 도 13에 관련하여 아래에서 설명될 것이다. 다음으로, 블록 1030에서, 프레임워크 관리자 (440) 는 새로이 생성된 노드 (601) 를 그의 고유한 자원 이름(들)을 이용하여 공표하여서 다른 노드들 (601) 은 새로이 생성된 노드 (601) 에 정보를 전송하거나 또는 그로부터 정보를 수신할 수도 있다.
도 10d의 계속하는 흐름도인 도 10e를 이제 참조하면, 블록 1035에서, 프레임워크 관리자 (440) 는 새로이 생성된 노드 (601) 에 의존하는 다른 노드들 (601) 에게 새로이 생성된 노드 (601) 가 인스턴스화되었고 정보를 수신하거나 또는 송신할 준비가 되었다는 것을 통지한다. 하나의 예시적인 양태에 따르면, 통지들은 도 10b의 노드 (601B) 와 같은 의존성 노드가 생성되는 경우에 즉시 트리거된다, 즉, 통지들은 재귀적으로 수행된다. 그래서 도 10b의 노드 (601B) 가 구성되면, 노드 (601A) 는 즉시 통지된다. 이 통지는 (노드 (601B) 가 노드 (601A) 의 최종 의존물이었으므로) 노드 (601A) 가 구성되는 것을 허용할 수도 있다. 노드 (601B) 의 구성은 다른 노드들 (601) 이 통지를 받게 하는 등등을 할 수도 있다. 노드 (601B) 는 노드 (601B) 에 의존하는 최종 자원이 완성될 때까지 완성되지 않는다.
제 2 의, 약간 더 복잡한 구현예는 통지들 모두를 별개의 통지 큐에 풋 (put) 한 다음, 단일 시점에서 큐를 통해 동작한다, 즉, 통지들은 반복적으로 수행된다는 것이다. 그래서 도 10b의 노드 (601B) 가 구성되는 경우, 노드 (601A) 로의 통지는 목록 상으로 푸시된다. 그 후에 그 목록은 실행되고 노드 (601A) 는 통지를 받는다. 이는 (노드 (601A) 이외의, 도 10b에는 예시되지 않은) 다른 부가적인 노드들 (601) 에 대한 통지가 동일한 목록에 풋되게 하고, 그 통지는 그 후에 노드 (601A) 로의 통지가 전송된 후에 전송된다. 노드 (601B) 및 노드 (601A) 에 연관된 모든 작업이 완료된 후까지 (노드 (601A) 로의 통지 이외의) 다른 노드들 (601) 로의 통지들은 일어나지 않는다.
논리적으로, 이들 2 개의 구현예들은 정확히 동등하지만, 이들은 구현되는 경우 상이한 메모리 소비 성질들을 가진다. 재귀적 실현은 간단하지만 스택 소비가 의존성 그래프의 깊이의 함수가 되어 임의의 양의 스택 공간을 낭비할 수 있다. 반복적 구현예는 약간 더 복잡하고 약간 더 정적인 메모리 (통지 목록) 를 필요로 하지만, 스택 사용은 도 10b에서 예시된 바와 같이, 의존 그래프의 깊이에 무관하게 일정하다.
또한, 블록 1035에서의 노드 생성의 통지는 다른 노드들로 제한되지 않는다. 그것은 또한 에일리어스 구성에 내부적으로 사용될 수도 있다. 시스템 (500) 에서의 어떤 임의의 엘리먼트는, 노드 (또는 마커) 가 이용가능하게 되는 경우, 뿐만 아니라 다른 노드들에 대해서도, 통지를 요청하기 위한 동일한 메커니즘을 이용할 수 있다. 노드들 및 비-노드들 양쪽 모두는 동일한 통지 메커니즘을 이용할 수도 있다.
결정 블록 1040에서, 프레임워크 관리자 (440) 는 현재 노드 (601) 의 생성에 기초하여, 다른 노드들 (601) 또는 소프트 의존성들이 생성 또는 인스턴스화를 위해 이제 해제되는지를 결정한다. 결정 블록 1040은 자원들이 이제 생성될 수도 있는지를 일반적으로 결정하고 있는데, 이는 특정한 의존성 관계들 (680) 이 최근에 생성 또는 인스턴스화를 겪은 현재 노드에 의해 충족되기 때문이다.
결정 블록 1040에 대한 조회가 긍정적이면, "예" 분기가 루틴 블록 1025로 이어져서 그 루틴 블록에서는, 방금 생성되었던 노드 (601) 에 의한 의존성의 충족 때문에, 해제된 노드 (601) 는 이제 생성되거나 또는 인스턴스화될 수도 있다.
결정 블록 1040에 대한 조회가 부정적이면, "아니오" 분기가 블록 1045로 이어져서 그 블록에서 프레임 작업 관리자 (440) 는 도 4에 예시된 바와 같은 소프트웨어 아키텍처의 엘리먼트들 사이의 통신들을 관리할 수도 있다. 다음으로, 블록 1050에서, 프레임워크 관리자 (440) 는 특정 자원에 연관된 자원 이름들을 이용함으로써 자원들에 의해 취해진 액션들을 계속해서 로그 (log) 또는 기록할 수도 있다. 블록 1045는, 프레임워크 관리자 (440) 또는 프레임워크 관리자 (440) 에 의해 관리되는 엘리먼트들 중 임의의 것, 이를테면 자원들, 노드들 (601), 클라이언트들 (648), 이벤트들 (695), 및 쿼리 기능들 (697) 에 의해 취해진 임의의 액션 후에 프레임워크 관리자 (440) 에 의해 실행될 수도 있다. 블록 1045는, 각각의 엘리먼트에 의해 수행된 액션들을 특정 엘리먼트, 이를테면 노드 (601) 의 자원을 생성했던 저자들에 의해 제공된 이들의 고유 식별자 또는 이름에 따라 열거하는 활동의 실행 로그를 프레임워크 관리자 (440) 가 유지할 수도 있는 또 하나의 중요한 노드 아키텍처의 양태이다.
선행 기술에 비해, 시스템의 각각의 자원에 할당된 고유한 이름들을 열거하는 블록 1050에서의 이 활동 로깅은 고유하고 디버깅 및 오류 문제해결에 사용되는 것과 같은 상당한 이점들을 제공할 수도 있다. 노드 아키텍처 (500) 를 고유하게 만드는 많은 것들 중 다른 양태는, 별개의 팀들이 서로 독립적인 상이한 하드웨어 및/또는 소프트웨어 엘리먼트들로 작업할 수도 있어, 각각의 팀이 다른 팀들 및/또는 원래의 장비 제조업자 (OEM) 에 의해 지정된 의미가 덜하고 보통 혼동스러운 자원 이름들을 해석하기 위한 테이블들을 생성할 필요 없이 쉽사리 추적하고 고유한 자원 이름들을 사용할 수 있게 될 그것이다.
다음으로, 결정 블록 1055에서, 프레임워크 관리자 (440) 는 프레임워크 관리자 (440) 에 의해 기록된 활동의 로그가 요청되었는지를 결정한다. 결정 블록 1055에 대한 조회가 부정적이면, "아니오" 분기가 프로세스의 말단으로 이어져서 프로세스는 루틴 1005로 되돌아간다. 결정 블록 1055에 대한 조회가 긍정적이면, "예" 분기가 블록 1060으로 이어져서 그 블록에서 프레임워크 관리자 (440) 는 의미있는 자원 이름들 및 그 자원 이름들에 의해 수행된 개별 액션들을 포함하는 활동 로그를 출력 디바이스, 이를테면 프린터 또는 디스플레이 스크린 및/또는 양쪽 모두로 전송한다. 그 프로세스는 그 다음에 위에서 설명된 루틴 블록 1005로 복귀한다.
도 11은 PCD (100) 의 소프트웨어 아키텍처에서 노드 구조 데이터를 수신하는 도 10d의 서브방법 또는 루틴 (1005) 을 예시하는 흐름도이다. 블록 1105는 도 10d의 서브 방법 또는 루틴 (1005) 에서의 제 1 단계이다. 블록 1105에서, 프레임워크 관리자 (440) 는 소프트웨어 또는 하드웨어 엘리먼트, 이를테면 도 10d의 CPU (110) 및 클록 (442) 에 대한 고유한 이름을 수신할 수도 있다. 이전에 논의된 바와 같이, 노드 (601) 는 적어도 하나 자원을 참조해야만 한다. 각각의 자원은 이름을 가지고 그 이름은 시스템 (500) 에서 고유해야만 한다. 시스템 (500) 내의 모든 엘리먼트들은 고유한 이름들로 식별될 수도 있다. 각각의 엘리먼트는 캐릭터 관점에서 고유한 이름을 가진다. 다르게 말하면, 일반적으로, 시스템 (500) 내에는 동일한 이름을 가지는 2 개의 엘리먼트들이 없다. 시스템의 예시적인 양태들에 따르면, 노드들 (601) 의 자원들은 시스템에 걸쳐 고유한 이름들을 일반적으로 가질 수도 있지만, 클라이언트 또는 이벤트 이름들이 고유할 필요는 없다, 다만 이들은 바람직하게는 고유할 수도 있다.
편이를 위해, 고유한 이름들을 생성하기 위해 포워드 슬래시 "/" 캐릭터들을 채용하는 기존의 트리 파일 명명 구조 또는 파일 명명법 "메타포 (metaphor)"가 CPU (110) 에 대한 "/core/cpu" 및 클록 (442) 에 대한 "/clk/cpu"처럼 (그러나 이들로 제한되지 않는다) 채용될 수도 있다. 그러나, 당업자에 의해 인식될 바와 같이, 영숫자 캐릭터들 및/또는 기호들의 임의의 다른 조합을 포함하는 자원 이름들의 다른 유형들은 또한 본 발명의 범위 내에 있다.
다음으로, 블록 1110에서, 프레임워크 관리자 (440) 는 생성 중인 노드 (601) 의 하나 이상의 자원들에 연관된 하나 이상의 드라이버 기능들을 위한 데이터 수신할 수도 있다. 드라이버 기능은 일반적으로 특정 노드 (601) 에 대해 하나 이상의 자원들에 의해 완료될 액션을 포함한다. 예를 들어, 도 10a 및 도 10b에서, 노드 (602) 의 자원 /core/cpu에 대한 드라이버 기능은 요구된 프로세싱의 요청된 양을 제공하기 위하여 그것이 요구하는 버스 대역폭의 양 및 CPU 클록 주파수를 요청할 수도 있다. 이들 요청들은 노드들 (642) 및 노드 (622) 에서 자원들의 클라이언트들 (미도시) 을 통해 이루어질 것이다. 노드 (642) 에서의 /clk/cpu 에 대한 드라이버 기능은 노드 (602) 의 /core/cpu 자원으로부터 그것이 수신했던 요청에 따라서 물리적 클록 주파수를 실제로 설정하는 것을 보통 담당할 것이다.
블록 1115에서, 프레임워크 관리자 (440) 는 노드 속성 데이터를 수신할 수도 있다. 노드 속성 데이터는 일반적으로, (노드가 사용자 공간 애플리케이션들을 통해 액세스되게 할 수 있는) 보안, (노드가 시스템에서 다른 프로세서들로부터 액세스될 수 있는) 원격실행성 (remotability), 및 (자원이 다수의 병행하는 클라이언트들을 지원할 수 있는) 접근성 (accessibility) 과 같은 노드 정책들을 규정하는 데이터를 포함한다. 프레임워크 관리자 (440) 는 또한 자원이 디폴트 프레임워크 거동, 이를테면 요구 평가 또는 로깅 정책을 번복하는 것을 허용하는 속성들을 정의할 수도 있다.
그 뒤에, 블록 1120에서, 프레임워크 관리자 (440) 는 생성 중인 특정 노드 (601) 에 대한 맞춤화된 사용자 데이터를 수신할 수도 있다. 사용자 데이터는 "C" 프로그래밍 언어에 대해 당업자에 의해 이해되는 바와 같은 보이드 (void) "star" 필드를 포함할 수도 있다. 사용자 데이터는 당업자에게 "trust me" 필드라고도 또한 알려져 있다. 예시적인 맞춤화된 사용자 데이터는 주파수 테이블들, 레지스터 맵들 등과 같은 테이블들을 포함할 수도 있으나 이들로 제한되지 않는다. 블록 1120에서 수신된 사용자 데이터는 시스템 (500) 에 의해 참조되지 않지만, 맞춤화가 프레임워크 관리자 (440) 에 의해 인식되지 않거나 또는 충분히 지원되지 않는다면 자원의 맞춤화를 허용한다. 이 사용자 데이터 구조는 특정한 또는 특정 용도들을 위해 확장되도록 의도되는 "C" 프로그래밍 언어에서의 기본 클래스이다.
당업자는 특정 클래스의 특정 용도들을 확장하기 위한 다른 종류들의 데이터 구조들이 본 발명의 범위 내에 있다는 것을 인식한다. 예를 들어, "C++" (C-플러스-플러스) 의 프로그래밍 언어에서, 동등한 구조가 노드 (601) 내의 자원에 대한 확장 메커니즘이 되는 키 워드 "public"을 포함할 수도 있다.
다음으로, 블록 1125에서, 프레임워크 관리자 (440) 는 의존성 어레이 데이터를 수신할 수도 있다. 의존성 어레이 데이터는 생성 중인 노드 (601) 가 의존하는 하나 이상의 자원들 (601) 의 고유하고 특정한 이름들을 포함할 수도 있다. 예를 들어, 도 10c의 제 1 노드 (602) 가 생성되어 있다면, 이 블록 1125에서, 의존성 어레이 데이터는 제 1 노드 (602) 가 의존하는 제 3 노드 (642) 의 단일 자원 이름과 제 2 노드 (622) 의 3 개의 자원들의 자원 이름들을 포함할 수도 있다.
그 뒤에, 블록 1130에서, 프레임워크 관리자 (440) 는 자원 어레이 데이터를 수신할 수도 있다. 그 자원 어레이 데이터는 생성 중인 현재 노드를 위한 파라미터들, 이를테면 제 1 노드 (602) 가 생성되어 있다면 도 10b 및 도 10c의 제 1 노드 (602) 에 관계가 있는 파라미터들을 포함할 수도 있다. 자원 어레이 데이터는 다음의 데이터: 다른 자원들의 이름들; 단위; 최대 값; 자원 속성들; 플러그 인 데이터; 및 블록 1120의 맞춤화 사용자 데이터와 유사한 임의의 맞춤화된 자원 데이터 중 하나 이상을 포함할 수도 있다. 플러그인 데이터는 일반적으로는 소프트웨어 라이브러리로부터 취출된 기능들을 식별하고 보통은 생성 중인 특정 노드 또는 복수의 노드들에 의해 지원될 수도 있는 클라이언트 유형들을 열거한다. 플러그인 데이터는 또한 클라이언트 생성 및 파괴의 맞춤화를 허용한다. 블록 1130 후, 프로세스는 도 10d의 블록 1010으로 복귀한다.
도 11에서, 속성 데이터 블록 1115는, 사용자 데이터 블록 1120을 맞춤화하고, 의존성 어레이 데이터 블록 1125는 이들 특정한 단계들이 옵션이고 임의의 주어진 노드 (601) 에 필요하지 않다는 것을 나타내는 파선들로 도시되어 있다. 한편 고유 이름 블록 1105, 드라이버 기능 블록 1110, 및 자원 어레이 데이터 블록 1130은 루틴 (1005) 의 이들 단계들이 일반적으로 노드 (601) 를 생성하는데 필수적임을 나타내기 위해 실선으로 도시되어 있다.
도 12는 PCD (100) 를 위한 소프트웨어 아키텍처에서 노드를 생성하는 도 10d의 서브방법 또는 루틴 (1025) 을 예시하는 흐름도이다. 루틴 블록 1205는 하나의 예시적인 실시형태에 따라 노드 (601) 를 인스턴스화하고 생성하는 서브방법 또는 루틴 (1025) 에서의 제 1 루틴이다. 루틴 블록 1205에서, 인스턴스화 중인 노드 (601) 에 연관되는 하나 이상의 클라이언트들 (648) 이 이 단계에서 생성된다. 루틴 블록 1205에 관한 추가의 세부사항들은 도 13에 관련하여 더 상세히 설명될 것이다.
블록 1210에서, 프레임워크 관리자는 블록 705의 노드 구조 데이터에 대응하는 하나 이상의 자원들을 생성하거나 또는 인스턴스화할 수도 있다. 다음으로, 블록 1215에서, 프레임워크 관리자 (440) 는 루틴 블록 1005의 루틴 블록 1110에서 수신된 드라이버 기능들을 활성화할 수도 있다. 하나의 예시적인 양태에 따르면, 드라이버 기능들은 루틴 블록 1005의 자원 어레이 데이터 블록 1130에서 수신된 최대 값들을 이용하여 활성화될 수도 있다. 다른 바람직한 예시적인 양태에 따르면, 각각의 드라이버 기능은 루틴 (1005) 으로부터 노드 구조 데이터와 함께 전해진 옵션의 초기 값으로 활성화될 수도 있다. 초기 데이터가 제공되지 않으면, 드라이버 기능은 0 (최소 값) 으로 초기화된다. 드라이버 기능은 또한 보통 그것이 초기화 중임이 알려지도록 하는 방식으로 활성화된다. 이는 자원이 초기화에 특정된 임의의 동작들을 수행하는 것을 가능하게 하지만, 정상 또는 루틴 동작 동안에 수행될 필요는 없다. 프로세스는 그 다음에 도 10d의 단계 1030으로 복귀한다.
도 13은 PCD (100) 의 소프트웨어 아키텍처에서 클라이언트 (648) 를 생성하는 도 12의 서브방법 또는 루틴 (1205) 을 예시하는 흐름도이다. 블록 1305는 하나 이상의 자원들 (601) 의 클라이언트 (648) 가 생성되는 루틴 블록 1205의 제 1 단계이다. 블록 1205에서, 프레임워크 관리자 (440) 는 생성 중인 클라이언트 (648) 에 할당된 이름을 수신한다. 자원 이름들과 유사하게, 클라이언트 (648) 에 대한 이름은 임의의 유형의 영숫자 및/또는 기호들을 포함할 수도 있다.
다음으로, 블록 1310에서, 생성 중인 이 클라이언트 (648) 에 대한 임의의 특정한 맞춤화들이 있다면 맞춤화된 사용자 데이터가 프레임워크 관리자 (440) 에 의해 수신될 수도 있다. 블록 1310은 단계가 옵션임을 나타내는 파선들로 도시되어 있다. 블록 1310의 맞춤화된 사용자 데이터는 노드들 (601) 에 대한 자원들의 생성에 관련하여 위에서 논의된 맞춤화된 사용자 데이터와 유사하다.
블록 1315에서, 프레임워크 관리자 (440) 는 생성 중인 특정 클라이언트에 할당된 클라이언트 유형 범주를 수신한다. 본 문서에서의 클라이언트 유형 범주는 다음 4 개의 유형들: (a) 필수, (b) 충동 (impulse), (c) 벡터, 및 (d) 등시 (sochronous) 중 하나를 포함할 수도 있다. 클라이언트 유형 범주는 시스템 (101) 에 의해 관리 중인 자원들에 그리고 노드들 (601) 의 자원들에 의존하는 애플리케이션 프로그램들에 의존하여 확장될 수도 있다.
필수 범주는 일반적으로는 요청된 클라이언트 (648) 로부터 특정 자원 (601) 으로 전해진 스칼라 값의 프로세싱과 대응한다. 예를 들어, 필수 요청은 초당 일백만 개의 명령들 (millions of instructions per second; MIPs) 중 특정한 수를 포함할 수도 있다. 한편, 충동 범주는 일반적으로는 시작 시간 또는 중단 시간의 임의의 지정 없이 일정한 기간 내에 일부 활동을 완료하기 위한 요청의 프로세싱과 대응한다.
등시 범주는 일반적으로는 일반적으로 재발하고 명확한 시작 시간 및 명확한 종료 시간을 갖는 액션에 대한 요청과 대응한다. 벡터 범주는 일반적으로는 보통 직렬로 또는 병렬로 요청되는 다수의 액션들의 부분인 데이터의 어레이와 대응한다.
그 뒤에, 블록 1320에서, 프레임워크 관리자 (440) 는 클라이언트 (648) 가 동기식으로 또는 비동기식으로 지정되었는지를 나타내는 데이터를 수신한다. 동기식 클라이언트 (648) 는, 자원 (601) 이 동기식 클라이언트 (648) 로부터의 요청된 태스크를 완료하여 자원 (601) 이 종료되었다는 데이터 및 표시를 반환할 때까지 프레임워크 관리자 (442) 가 노드 (601) 의 자원을 잠그는 것을 일반적으로 요구하는 것이다.
다른 한편으로는, 비동기식 클라이언트 (648) 는 프레임워크 관리자 (440) 에 의해 액세스되는 하나 이상의 스레드들 (436) (도 4 참조) 에 의해 병렬로 핸들링될 수도 있다. 프레임워크 (440) 는 스레드 (436) 에 대한 콜백을 생성할 수도 있고 그 콜백이 개별 스레드 (436) 에 의해 실행된 때에 값을 반환할 수도 있다. 당업자는 동기식 클라이언트 (648) 의 태스크가 실행 중인 경우에 동기식 클라이언트 (648) 가 한 것처럼 비동기식 클라이언트 (648) 가 자원을 잠그지 못한다는 것을 인식한다.
블록 1320 후, 결정 블록 1325에서, 프레임워크 관리자 (440) 는 클라이언트 (645) 에 의해 식별된 자원이 이용가능한지를 결정한다. 결정 블록 1325에 대한 조회가 부정적이면, "아니오" 분기가 블록 1330으로 다시 이어져 그 블록에서는 클라이언트 (648) 가 이 시각에 생성될 수 없다는 것을 나타내는 널 값 또는 메시지가 사용자에게 반환된다.
결정 블록 1325에 대한 조회가 긍정적이면, "예" 분기가 결정 블록 1335로 이어져 그 결정 블록에서 프레임워크 관리자 (440) 는 클라이언트 (648) 에 의해 식별된 각각의 자원이 블록 1310에서 제공된 클라이언트 유형을 지원하는지를 결정한다. 결정 블록 1335에 대한 조회가 부정적이면, "아니오" 분기가 블록 1330으로 다시 이어져 그 블록에서는 클라이언트 (648) 가 이 시각에 생성될 수 없다는 것을 나타내는 널 값 또는 메시지가 반환된다.
결정 블록 1335에 대한 조회가 긍정적이면, "예" 분기가 블록 1340으로 이어져 그 블록에서 프레임워크 관리자 (440) 는 메모리 내에서 클라이언트 (648) 를 생성하거나 또는 인스턴스화한다. 다음으로, 블록 1345에서, 임의의 맞춤화된 사용자 데이터, 이를테면 옵션적인 인수들 (arguments) 이 블록 1310에서 수신되면, 이들 옵션적인 인수들은 이들의 개별 자원들인 특정 노드들 (601) 과 매핑될 수도 있다. 다음으로, 블록 1350에서, 새로이 생성된 클라이언트 (645) 는 위에서 설명된 도 10c에서 예시된 바와 같은 유휴 상태 또는 요청된 상태에서 그의 대응하는 하나 이상의 자원들에 연결된다. 프로세스는 그 다음에 도 12의 단계 1210으로 복귀한다.
도 14는 PCD (100) 를 위한 소프트웨어 아키텍처에서 자원 (601) 에 대한 클라이언트 요청 (675) 을 생성하는 방법 (1400) 을 예시하는 흐름도이다. 그 방법 (1400) 은 일반적으로는 도 10d 내지 도 10e 및 도 13에 관련하여 위에서 설명된 바와 같은 클라이언트 생성 및 노드 생성 후에 실행된다.
블록 1405는 자원 (601) 에 대해 클라이언트 요청 (675) 을 생성하는 방법 (1400) 에서의 제 1 단계이다. 이 방법 (1400) 은 요청들 (675) 의 다음 3 가지 유형들: (a) 필수, (b) 충동, 및 (c) 벡터가 프레임워크 관리자 (440) 에 의해 핸들링되는 방법을 설명할 것이다. 위에서 언급된 요청들 (675) 의 이름들이 제안하는 바와 같이, 클라이언트 요청들 (675) 은 일반적으로는 도 14에 관련하여 위에서 설명되고 생성된 클라이언트 유형들과 대응한다.
블록 1405에서, 프레임워크 관리자 (440) 는 위에서 언급된 3 개: (a) 필수, (b) 충동, 및 (c) 벡터 중 하나와 같은 특정 클라이언트 요청 (675) 에 연관된 데이터를 수신할 수도 있다. 필수 요청에 연관된 데이터는 일반적으로는 요청된 클라이언트 (648) 로부터 특정 자원 (601) 으로 전해지는 스칼라 값을 포함한다. 예를 들어, 필수 요청은 초당 일백만 개의 명령들 (MIPs) 중 특정한 수를 포함할 수도 있다. 한편, 충동 요청은 시작 시간 또는 중단 시간의 임의의 지정 없이 일정한 기간 내에 일부 활동을 완료하기 위한 요구를 포함한다. 벡터 요청에 대한 데이터는 일반적으로는 직렬로 또는 병렬로 완료될 필요가 있는 다수의 액션들의 어레이를 포함한다. 벡터 요청은 값들의 임의의 길이를 포함할 수도 있다. 벡터 요청은 보통 사이즈 값 및 값들의 어레이를 가진다. 노드 (601) 의 각각의 자원은 벡터 요청을 지원하기 위하여 포인터 필드를 갖도록 연장될 수도 있다. "C" 프로그래밍 언어에서, 포인터 필드는 당업자에 의해 이해되는 바와 같이 유니온 함수에 의해 지원된다.
다음으로, 블록 1410에서, 프레임워크 관리자 (440) 는 도 13에 관련하여 위에서 설명된 방법에 의해 생성되었던 클라이언트 (648) 를 통해 요청을 발행한다. 그 뒤에, 블록 1415에서, 프레임워크 관리자 (440) 는 요청이 필수 유형 또는 벡터 유형이면 클라이언트를 통해 전해진 요청 데이터를 이중으로 버퍼링한다. 요청이 충동 유형이면, 블록 1415는 프레임워크 관리자 (440) 에 의해 건너뛰어진다.
필수 요청들에 대해, 이 블록 1415에서, 이전 요청으로부터의 값들은 메모리에 유지되어서 프레임워크 관리자 (440) 는 현재 요청된 값들의 세트에서 이전의 요청된 값들과의 임의의 차이가 있는지를 결정할 수 있다. 벡터 요청들에 대해, 이전의 요청들은 보통 메모리에 유지되지 않지만, 다만 노드 (601) 의 자원은 특정 구현예에 대해 소망하는 대로 그것을 유지할 수도 있다. 그러므로, 블록 1415는 요청들의 벡터 유형들에 대해 옵션적이다.
블록 1420에서, 프레임워크 관리자 (440) 는 현재 요청된 값들의 세트에서 이전의 요청된 값들의 세트와의 델타 또는 차이를 계산한다. 결정 블록 1425에서, 프레임워크 관리자는 현재 요청된 값들의 세트가 이전의 요청된 값들의 세트와 동일한지를 결정한다. 다르게 말하면, 프레임워크 관리자 (440) 는 현재 요청된 값들의 세트와 이전의 요청된 값들의 세트 사이에 차이가 존재하는지를 결정한다. 요청된 값들의 현재 세트와 이전 세트 사이에 차이가 없다면, "예" 분기 (는 블록 1430 내지 블록 1470을 건너뜀) 가 블록 1475로 이어져 그 블록에서 프로세스가 종료된다.
결정 블록 1425에 대한 조회가 요청된 값들의 세트가 미리 이전에 요청된 값들의 세트에 비교하여 상이하다는 것을 의미하는 부정적이면, "아니오" 분기가 결정 블록 1430으로 이어진다.
결정 블록 1430에서, 프레임워크 관리자 (440) 는 현재 요청이 비동기식 요청인지를 결정한다. 결정 블록 1430에 대한 조회가 부정적이면, "아니오" 분기가 블록 1440으로 이어져서 그 블록에서 클라이언트 요청 (675) 에 대응하는 자원 (601) 은 프레임워크 관리자 (440) 에 의해 잠금된다. 결정 블록 1430에 대한 조회가 현재 요청이 비동기식 요청 유형임을 의미하는 긍정적이면, "예" 분기가 블록 1435로 이어져서 그 블록에서는 요청이 다른 스레드로 푸시될 수도 있고, 멀티코어 시스템이, 도 1의 것과 같이, 프레임워크 관리자 (440) 에 의해 현재 관리된다면, 다른 코어에 의해 실행될 수도 있다. 블록 1435는 PCD (100) 가 단일 코어 중앙 프로세싱 시스템이면 이 단계가 옵션적일 수도 있다는 것을 나타내는 파선들로 도시되어 있다.
그 뒤에, 블록 1440에서, 요청 (675) 에 대응하는 자원들 (601) 이 프레임워크 관리자 (440) 에 의해 잠금된다. 다음으로, 블록 1445에서, 자원 (601) 은 도 11의 블록 1130에서 수신된 자원 어레이 데이터의 플러그인 데이터에 일반적으로 대응하는 업데이트 기능을 실행한다. 업데이트 기능은 일반적으로 새로운 클라이언트 요청 관점에서 새로운 자원 상태를 담당하는 기능을 포함한다. 업데이트 기능은 그의 이전의 상태를 클라이언트 요청으로 요청된 상태와 비교한다. 요청된 상태가 이전의 상태보다 크면, 업데이트 기능은 클라이언트 요청을 수행할 것이다. 그러나, 요청된 상태가 현재 상태 이하이고 자원이 운영하는 것이면, 클라이언트 요청은 효율을 증가시키기 위하여 수행되지 않을 것인데, 이는 이전 상태가 요청된 상태를 달성하거나 또는 충족하기 때문이다. 업데이트 기능은 클라이언트로부터 새로운 요청을 취하고 그것을 모든 다른 액티브 요청들과 종합하여 자원에 대한 새로운 상태를 결정한다.
일 예로서, 다수의 클라이언트들은 버스 클록 주파수를 요청하는 것일 수도 있다. 버스 클록에 대한 업데이트 기능은 보통은 모든 클라이언트 요청들의 최대치를 취득하고 그것을 버스 클록에 대한 새로운 소망의 상태로서 사용한다. 모든 자원들이 동일한 업데이트 기능을 이용할 것이라는 것은 사실이 아니지만, 다수의 자원들에 의해 사용될 일부 업데이트 기능들은 존재한다. 일부 공통 업데이트 기능들은 클라이언트 요청들의 최대치를 취득하고, 클라이언트 요청들의 최소치를 취득하며 클라이언트 요청을 합산해야 할 것이다. 또는 자원들은 이들의 자원이 어떤 고유한 방법으로 요청들을 종합할 필요가 있다면 이들 자신의 맞춤식 업데이트 (custom update) 기능을 정의할 수도 있다.
다음으로, 블록 1450에서, 프레임워크 관리자 (440) 는 데이터를 클라이언트 (648) 에 대응하는 자원에 전해주어서 자원은 노드 (601) 의 자원에 특정되는 드라이버 기능을 실행할 수도 있다. 드라이버 기능은 업데이트 기능에 의해 컴퓨팅되는 바와 같이 자원 상태에 적용된다. 이는 하드웨어 설정들을 업데이트하는 것, 의존 자원들에 요청들을 발행하는 것, 레거시 기능들을 호출하는 것 또는 전술한 것들의 일부 조합을 수반할 수도 있다.
이전의 예에서, 업데이트 기능은 요청된 버스 클록 주파수를 컴퓨팅했다. 드라이버 기능은 그 요청된 주파수를 수신할 수도 있고 그것은 그 주파수에서 동작하기 위해 클록 주파수 제어 HW를 업데이트할 수도 있다. 때때로 드라이버 기능은 업데이트 기능이 컴퓨팅했던 정확한 요청 상태를 만족시키는 것이 가능하지 않다는 것에 주의한다. 이 경우, 드라이버 기능은 요청을 가장 잘 만족시키는 주파수를 선택할 수도 있다. 예를 들어, 버스 클록 HW는 128 MHz 및 160 MHz에서 동작하는 것만 가능할 수도 있지만, 요청된 상태는 150 MHz일 수도 있다. 이 경우, 드라이버 기능은 160 MHz에서 동작하여야 하는데, 그것이 요청된 상태를 초과해서이다.
다음으로, 블록 1455에서, 프레임워크 (440) 는 블록 1450에서 드라이버 기능을 실행했던 자원으로부터 상태 제어를 수신한다. 그 뒤에, 블록 1460에서, 자원에 대해 정의되었다면, 이벤트들 (690) 은 데이터가 이벤트 (690) 에 대응하는 클라이언트 (648) 로 다시 전해지도록 트리거될 수도 있다. 이벤트들은 다른 스레드에서 프로세싱될 수도 있다. 이는 자원들이 잠기는 것으로 소비된 시간량을 최소화할 수도 있고, 도 1에 예시된 바와 같은 멀티코어 시스템에서 더 많은 병렬 동작을 허용한다. 하나 이상의 이벤트들 (690) 은 이 방법 (1400) 에서 설명되는 바와 같이 요청이 자원에 대해 정의될 수도 있는 방법과 유사한 방법으로 자원에 대해 정의될 수도 있다. 다르게 말하면, 이벤트 생성 프로세스는 클라이언트 생성 프로세스와 크게 유사할 수도 있다. 이벤트들과 상이한 한 가지는 특정한 임계값들을 넘을 때에만 트리거되는 이벤트들을 정의하는 것이 가능하다는 것이다.
임계값들에만 기초하여 트리거되는 이 이벤트들의 정의는, 시스템 과부하 상태를 나타내는, 자원이 필요이상으로 산정된 경우 (그것이 지원할 수 있는 것보다 많은 동시 사용자들을 가지는 경우) 또는 자원이 줄어드는/고갈되는 경우의 통지를 허용하며, 이는 다른 것들이 중단되는 것을 허용하며, 시스템이 필요 이상으로 산정되게 된 경우를 가능하지 않게 하였던 기능을 복원하는 것 등을 할 수도 있다. 이벤트 등록이 임계값들로 행해질 수도 있기 때문에, 그것은 정말 필요한 무언가가 있는 경우에만 일어날 이벤트 통지에 대해서만 시스템이 해야 하는 작업의 양을 줄인다. 모든 상태 변경에 대해 이벤트를 등록하는 것이 또한 가능하다.
다음으로, 옵션의 블록 1465에서, 프로세싱 중인 요구가 벡터 요청이면, 이 옵션적 블록 1465는 보통 수행된다. 옵션적 블록 1465는 일반적으로는 사용자가 벡터에 전해주었던 동일한 데이터를 벡터 포인터가 여전히 가리키고 있는지의 여부를 평가하기 위한 점검 또는 결정을 포함한다. 이 옵션적 블록 1465에 대한 조회가 사용자에 의해 벡터에 전해졌던 동일한 데이터를 포인터가 여전히 가리키고 있다는 것을 의미하는 긍정적이면, 그 포인터는 제거되어서 이전 데이터에 대한 참조는 유지되지 않는다. 이 옵션적 블록 1465는 충동 요청 및 필수 요청과 비교하여, 벡터 요청이 프로세싱 중인 경우 위에서 설명된 이중 버퍼링 블록 1415 를 설명하기 위해 일반적으로 수행된다.
그 뒤에, 블록 1470에서, 프레임워크 (440) 는 요청된 자원을 잠금해제하여서 다른 클라이언트 요청들 (648) 은 특정 노드 (601) 의 현재이지만 이제 해제된 요청된 자원에 의해 핸들링될 수도 있다. 프로세스는 그 다음에 다음의 클라이언트 요청을 수신하기 위해 제 1 블록 1405로 복귀한다.
위의 개시물의 관점에서, 프로그래밍에서 통상의 지식을 가진 자는, 예를 들어 컴퓨터 코드를 작성하거나 또는 적절한 하드웨어 및/또는 회로들을 식별하여, 본 명세서에서의 흐름도들 및 관련된 설명에 기초하여 어려움 없이 개시된 본 발명을 구현할 수 있다. 그러므로, 프로그램 코드 명령들의 특정 세트 또는 상세한 하드웨어 디바이스들의 개시내용은 본 발명을 만들고 이용하는 방법의 적절한 이해를 위해 필요하다고 생각되지는 않는다. 청구된 컴퓨터 구현 프로세스들의 발명적 기능은 위의 설명에서 그리고 다양한 프로세스 흐름들을 예시할 수도 있는 도면들에 연계하여 더 상세히 설명되어 있다.
하나 이상의 예시적인 양태들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수 있다. 소프트웨어로 구현된다면, 기능들은 하나 이상의 명령들 또는 코드로서 컴퓨터 판독가능 매체 상에 저장되거나 인코딩될 수도 있다. 컴퓨터 판독가능 매체들은 한 장소에서 다른 장소로의 컴퓨터 프로그램의 전송을 용이하게 하는 임의의 매체를 포함하는 컴퓨터 저장 매체 및 통신 매체 양쪽 모두를 포함한다. 저장 매체들은 컴퓨터에 의해 액세스될 수도 있는 임의의 이용가능한 매체들일 수도 있다. 비제한적인 예로, 이러한 컴퓨터 판독가능 매체들은 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 스토리지, 자기 디스크 스토리지, 또는 다른 자기적 저장 디바이스들, 또는 소망의 프로그램 코드를 컴퓨터에 의해 액세스될 수도 있는 명령들 또는 데이터 구조들의 형태로 운반하거나 저장하는데 사용될 수도 있는 임의의 다른 매체를 포함할 수도 있다.
또한, 임의의 접속이 컴퓨터 판독가능 매체로 적절히 칭해진다. 예를 들어, 소프트웨어가 웹사이트, 서버, 또는 다른 원격 자원으로부터 동축 케이블, 광섬유 케이블, 연선 (twisted pair), 디지털 가입자 회선 ("DSL"), 또는 무선 기술들 이를테면 적외선, 라디오, 및/또는 마이크로파를 이용하여 전송된다면, 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들은 매체의 정의에 포함된다.
디스크 (disk 및 disc) 는 본원에서 사용되는 바와 같이, 콤팩트 디스크 (compact disc, "CD"), 레이저 디스크, 광 디스크, 디지털 다기능 디스크 ("DVD"), 플로피 디스크 (floppy disk) 및 블루레이 디스크를 포함하는데, 디스크 (disk) 들은 보통 데이터를 자기적으로 재생하지만, 디스크 (disc) 들은 레이저들로 광적으로 데이터를 재생한다. 상기한 것들의 조합들은 또한 컴퓨터 판독가능 매체들의 범위 내에 포함되어야 한다.
선택된 다수의 양태들이 도시되고 상세히 설명되었지만, 갖가지 대체물들 및 개조물들이, 다음의 청구항들에 의해 정의된 바와 같은 본 발명의 정신 및 또는 범위로부터 벗어나지 않고 만들어질 수도 있다는 것이 이해될 것이다.

Claims (40)

  1. 휴대용 컴퓨팅 디바이스 (portable computing device; PCD) 의 스위치 패브릭들 (switch fabrics) 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법으로서,
    마스터-슬레이브 쌍을 포함하는 클라이언트 요청을 수신하는 단계;
    상기 마스터-슬레이브 쌍에 대응하는 슬레이브에 대한 탐색을 행하는 단계;
    상기 마스터-슬레이브 쌍에 대응하는 통신들에 대한 루트를 생성하는 단계;
    상기 루트에 대응하는 하나 이상의 핸들들을 메모리 디바이스 내에 저장하는 단계;
    상기 루트의 대역폭을 설정하는 단계; 및
    생성된 상기 루트를 이용하여 그리고 상기 루트의 상기 대역폭이 설정된 후에 상기 클라이언트 요청을 프로세싱하는 단계를 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  2. 제 1 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 단계는, 마스터-슬레이브 계층구조에서의 각각의 슬레이브에 할당된 고유 식별자들을 비교하는 단계를 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  3. 제 1 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 단계는, 스위치 패브릭 내에서 질의될 수 있는 슬레이브들에 대한 패브릭 루트 점검 테이블을 검토하는 단계를 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  4. 제 1 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 단계는, 상기 PCD의 하나 이상의 상이한 스위치 패브릭들에 걸쳐 탐색하는 단계를 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  5. 제 1 항에 있어서,
    각각의 마스터가 노드로 표현되고 각각의 슬레이브가 노드로 표현되는 노드 아키텍처를 활용하여 통신들을 추적하는 단계를 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  6. 제 1 항에 있어서,
    상기 루트의 대역폭을 설정하는 단계는, 상기 클라이언트 요청의 파라미터들을 순간 대역폭 (instantaneous bandwidth; Ib) 및 평균 대역폭 (average bandwidth; Ab) 값들로 변환하는 단계를 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  7. 제 6 항에 있어서,
    상기 순간 대역폭 (Ib) 은 다음 식에 의해 결정되며:
    Ib = BS/W
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "W" 는 시간 단위들로 나타내는 윈도우 사이즈인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  8. 제 6 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = BS/P
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "P" 는 시간 단위들로 나타내는 기간인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  9. 제 6 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = T × (Z%)
    여기서 "Ab" 는 평균 대역폭이고; "T" 는 소프트웨어 요청을 발행하는 중앙 프로세싱 유닛의 소망의 클록 속도이며; "Z%" 는 사용 및 캐시 미스들 (cache misses) 의 백분율 중 적어도 하나의 백분율인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  10. 제 6 항에 있어서,
    상기 평균 대역폭 (Ab) 은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 합산으로부터 계산되고,
    상기 순간 대역폭은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 최대치로부터 계산되는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법.
  11. 휴대용 컴퓨팅 디바이스 (portable computing device; PCD) 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템으로서,
    상기 컴퓨터 시스템은 프로세서를 포함하고,
    상기 프로세서는,
    마스터-슬레이브 쌍을 포함하는 클라이언트 요청을 수신하는 것;
    상기 마스터-슬레이브 쌍에 대응하는 슬레이브에 대한 탐색을 행하는 것;
    상기 마스터-슬레이브 쌍에 대응하는 통신들에 대한 루트를 생성하는 것;
    상기 루트에 대응하는 하나 이상의 핸들들을 메모리 디바이스 내에 저장하는 것;
    상기 루트의 대역폭을 설정하는 것; 및
    생성된 상기 루트를 이용하여 그리고 상기 루트의 상기 대역폭이 설정된 후에 상기 클라이언트 요청을 프로세싱하는 것
    을 위해 동작가능한, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  12. 제 11 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 것은, 마스터-슬레이브 계층구조에서의 각각의 슬레이브에 할당된 고유 식별자들을 비교하는 것을 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  13. 제 11 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 것은, 스위치 패브릭 내에서 질의될 수 있는 슬레이브들에 대한 패브릭 루트 점검 테이블을 검토하는 것을 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  14. 제 11 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 것은, 상기 PCD의 하나 이상의 상이한 스위치 패브릭들에 걸쳐 탐색하는 것을 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  15. 제 11 항에 있어서,
    상기 프로세서는 또한, 각각의 마스터가 노드로 표현되고 각각의 슬레이브가 노드로 표현되는 노드 아키텍처를 활용하여 통신들을 추적하는 것을 위해 동작가능한, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  16. 제 11 항에 있어서,
    상기 루트의 대역폭을 설정하는 것은, 상기 클라이언트 요청의 파라미터들을 순간 대역폭 (instantaneous bandwidth; Ib) 및 평균 대역폭 (average bandwidth; Ab) 값들로 변환하는 것을 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  17. 제 16 항에 있어서,
    상기 순간 대역폭 (Ib) 은 다음 식에 의해 결정되며:
    Ib = BS/W
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "W" 는 시간 단위들로 나타내는 윈도우 사이즈인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  18. 제 16 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = BS/P
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "P" 는 시간 단위들로 나타내는 기간인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  19. 제 16 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = T × (Z%)
    여기서 "Ab" 는 평균 대역폭이고; "T" 는 소프트웨어 요청을 발행하는 중앙 프로세싱 유닛의 소망의 클록 속도이며; "Z%" 는 사용 및 캐시 미스들의 백분율 중 적어도 하나의 백분율인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  20. 제 16 항에 있어서,
    상기 평균 대역폭 (Ab) 은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 합산으로부터 계산되고,
    상기 순간 대역폭은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 최대치로부터 계산되는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  21. 휴대용 컴퓨팅 디바이스 (portable computing device; PCD) 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템으로서,
    마스터-슬레이브 쌍을 포함하는 클라이언트 요청을 수신하는 수단;
    상기 마스터-슬레이브 쌍에 대응하는 슬레이브에 대한 탐색을 행하는 수단;
    상기 마스터-슬레이브 쌍에 대응하는 통신들에 대한 루트를 생성하는 수단;
    상기 루트에 대응하는 하나 이상의 핸들들을 메모리 디바이스 내에 저장하는 수단;
    상기 루트의 대역폭을 설정하는 수단; 및
    생성된 상기 루트를 이용하여 그리고 상기 루트의 상기 대역폭이 설정된 후에 상기 클라이언트 요청을 프로세싱하는 수단을 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  22. 제 21 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 수단은, 마스터-슬레이브 계층구조에서의 각각의 슬레이브에 할당된 고유 식별자들을 비교하는 수단을 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  23. 제 21 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 수단은, 스위치 패브릭 내에서 질의될 수 있는 슬레이브들에 대한 패브릭 루트 점검 테이블을 검토하는 수단을 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  24. 제 21 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 수단은, 상기 PCD의 하나 이상의 상이한 스위치 패브릭들에 걸쳐 탐색하는 수단을 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  25. 제 21 항에 있어서,
    각각의 마스터가 노드로 표현되고 각각의 슬레이브가 노드로 표현되는 노드 아키텍처를 활용하여 통신들을 추적하는 수단을 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  26. 제 21 항에 있어서,
    상기 루트의 대역폭을 설정하는 수단은, 상기 클라이언트 요청의 파라미터들을 순간 대역폭 (instantaneous bandwidth; Ib) 및 평균 대역폭 (average bandwidth; Ab) 값들로 변환하는 수단을 더 포함하는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  27. 제 26 항에 있어서,
    상기 순간 대역폭 (Ib) 은 다음 식에 의해 결정되며:
    Ib = BS/W
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "W" 는 시간 단위들로 나타내는 윈도우 사이즈인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  28. 제 26 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = BS/P
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "P" 는 시간 단위들로 나타내는 기간인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  29. 제 26 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = T × (Z%)
    여기서 "Ab" 는 평균 대역폭이고; "T" 는 소프트웨어 요청을 발행하는 중앙 프로세싱 유닛의 소망의 클록 속도이며; "Z%" 는 사용 및 캐시 미스들의 백분율 중 적어도 하나의 백분율인, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  30. 제 26 항에 있어서,
    상기 평균 대역폭 (Ab) 은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 합산으로부터 계산되고,
    상기 순간 대역폭은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 최대치로부터 계산되는, 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 컴퓨터 시스템.
  31. 컴퓨터 판독가능 프로그램 코드를 포함하고 있는 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품으로서,
    상기 컴퓨터 판독가능 프로그램 코드는, 휴대용 컴퓨팅 디바이스 (portable computing device; PCD) 의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 생성하고 서비스하는 방법을 구현하기 위해 실행되도록 구성되고,
    상기 방법은,
    마스터-슬레이브 쌍에 대응하는 슬레이브에 대한 탐색을 행하는 단계;
    상기 마스터-슬레이브 쌍에 대응하는 통신들에 대한 루트를 생성하는 단계;
    상기 루트에 대응하는 하나 이상의 핸들들을 메모리 디바이스 내에 저장하는 단계;
    상기 루트의 대역폭을 설정하는 단계; 및
    생성된 상기 루트를 이용하여 그리고 상기 루트의 상기 대역폭이 설정된 후에 클라이언트 요청을 프로세싱하는 단계를 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  32. 제 31 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 단계는, 마스터-슬레이브 계층구조에서의 각각의 슬레이브에 할당된 고유 식별자들을 비교하는 단계를 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  33. 제 31 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 단계는, 스위치 패브릭 내에서 질의될 수 있는 슬레이브들에 대한 패브릭 루트 점검 테이블을 검토하는 단계를 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  34. 제 31 항에 있어서,
    상기 슬레이브에 대한 탐색을 행하는 단계는, 상기 PCD의 하나 이상의 상이한 스위치 패브릭들에 걸쳐 탐색하는 단계를 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  35. 제 31 항에 있어서,
    상기 방법을 구현하는 상기 컴퓨터 판독가능 프로그램 코드는,
    각각의 마스터가 노드로 표현되고 각각의 슬레이브가 노드로 표현되는 노드 아키텍처를 활용하여 통신들을 추적하는 것을 더 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  36. 제 31 항에 있어서,
    상기 루트의 대역폭을 설정하는 단계는, 상기 클라이언트 요청의 파라미터들을 순간 대역폭 (instantaneous bandwidth; Ib) 및 평균 대역폭 (average bandwidth; Ab) 값들로 변환하는 단계를 더 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  37. 제 36 항에 있어서,
    상기 순간 대역폭 (Ib) 은 다음 식에 의해 결정되며:
    Ib = BS/W
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "W" 는 시간 단위들로 나타내는 윈도우 사이즈인, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  38. 제 36 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = BS/P
    여기서 "BS" 는 바이트들의 수로 나타내는 블록 사이즈이고, "P" 는 시간 단위들로 나타내는 기간인, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  39. 제 36 항에 있어서,
    상기 평균 대역폭 (Ab) 은 다음 식에 의해 결정되며:
    Ab = T × (Z%)
    여기서 "Ab" 는 평균 대역폭이고; "T" 는 소프트웨어 요청을 발행하는 중앙 프로세싱 유닛의 소망의 클록 속도이며; "Z%" 는 사용 및 캐시 미스들의 백분율 중 적어도 하나의 백분율인, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  40. 제 36 항에 있어서,
    상기 평균 대역폭 (Ab) 은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 합산으로부터 계산되고,
    상기 순간 대역폭은, 생성된 상기 루트에 대응하는 스위치 패브릭들 내의 그리고 스위치 패브릭들에 걸친 모든 클라이언트 요청들의 최대치로부터 계산되는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
KR1020137032235A 2011-05-05 2012-04-30 휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템 KR101503209B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/101,937 US8595366B2 (en) 2011-05-05 2011-05-05 Method and system for dynamically creating and servicing master-slave pairs within and across switch fabrics of a portable computing device
US13/101,937 2011-05-05
PCT/US2012/035847 WO2012151162A2 (en) 2011-05-05 2012-04-30 Method and system for dynamically creating and servicing master-slave pairs within and across switch fabrics of a portable computing device

Publications (2)

Publication Number Publication Date
KR20140014273A true KR20140014273A (ko) 2014-02-05
KR101503209B1 KR101503209B1 (ko) 2015-03-24

Family

ID=46062763

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137032235A KR101503209B1 (ko) 2011-05-05 2012-04-30 휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템

Country Status (6)

Country Link
US (1) US8595366B2 (ko)
EP (1) EP2705433B1 (ko)
JP (1) JP5759619B2 (ko)
KR (1) KR101503209B1 (ko)
CN (1) CN103597784B (ko)
WO (1) WO2012151162A2 (ko)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9600434B1 (en) * 2011-12-30 2017-03-21 Bedrock Automation Platforms, Inc. Switch fabric having a serial communications interface and a parallel communications interface
US9467297B2 (en) 2013-08-06 2016-10-11 Bedrock Automation Platforms Inc. Industrial control system redundant communications/control modules authentication
US12061685B2 (en) 2011-12-30 2024-08-13 Analog Devices, Inc. Image capture devices for a secure industrial control system
US11314854B2 (en) 2011-12-30 2022-04-26 Bedrock Automation Platforms Inc. Image capture devices for a secure industrial control system
US10834820B2 (en) 2013-08-06 2020-11-10 Bedrock Automation Platforms Inc. Industrial control system cable
US11967839B2 (en) 2011-12-30 2024-04-23 Analog Devices, Inc. Electromagnetic connector for an industrial control system
US8868813B2 (en) 2011-12-30 2014-10-21 Bedrock Automation Platforms Inc. Communications control system with a serial communications interface and a parallel communications interface
US9727511B2 (en) 2011-12-30 2017-08-08 Bedrock Automation Platforms Inc. Input/output module with multi-channel switching capability
US9191203B2 (en) 2013-08-06 2015-11-17 Bedrock Automation Platforms Inc. Secure industrial control system
US8971072B2 (en) * 2011-12-30 2015-03-03 Bedrock Automation Platforms Inc. Electromagnetic connector for an industrial control system
US8862802B2 (en) * 2011-12-30 2014-10-14 Bedrock Automation Platforms Inc. Switch fabric having a serial communications interface and a parallel communications interface
US10834094B2 (en) 2013-08-06 2020-11-10 Bedrock Automation Platforms Inc. Operator action authentication in an industrial control system
US9437967B2 (en) 2011-12-30 2016-09-06 Bedrock Automation Platforms, Inc. Electromagnetic connector for an industrial control system
US11144630B2 (en) 2011-12-30 2021-10-12 Bedrock Automation Platforms Inc. Image capture devices for a secure industrial control system
CN103748943A (zh) * 2012-08-17 2014-04-23 华为技术有限公司 用户设备配对处理方法、网络侧设备和用户设备
US10613567B2 (en) 2013-08-06 2020-04-07 Bedrock Automation Platforms Inc. Secure power supply for an industrial control system
CN105281061A (zh) 2014-07-07 2016-01-27 基岩自动化平台公司 工业控制系统电缆
US10013172B2 (en) * 2015-07-10 2018-07-03 The Keyw Corporatin Electronic data storage device with multiple configurable data storage mediums
KR102409158B1 (ko) 2016-05-10 2022-06-14 엘에스일렉트릭(주) 슬레이브 디바이스 제어 방법
US10169274B1 (en) 2017-06-08 2019-01-01 Qualcomm Incorporated System and method for changing a slave identification of integrated circuits over a shared bus
JP7106984B2 (ja) * 2018-05-22 2022-07-27 富士フイルムビジネスイノベーション株式会社 情報処理装置、情報処理システム及びプログラム
SE2030332A1 (en) * 2020-11-06 2022-05-07 Aakerfeldt Erik Seamless multiplayer experience

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE38428E1 (en) 1995-05-02 2004-02-10 Apple Computer, Inc. Bus transaction reordering in a computer system having unordered slaves
US6072798A (en) 1995-11-01 2000-06-06 Whittaker Corporation Network access communication switch
KR100266256B1 (ko) * 1997-12-31 2000-09-15 강병호 프로세서와 디바이스들 간의 통신 장치
US7028096B1 (en) * 1999-09-14 2006-04-11 Streaming21, Inc. Method and apparatus for caching for streaming data
US6570849B1 (en) * 1999-10-15 2003-05-27 Tropic Networks Inc. TDM-quality voice over packet
US6920171B2 (en) * 2000-12-14 2005-07-19 Motorola, Inc. Multiple access frequency hopping network with interference anticipation
TWI223942B (en) * 2001-02-20 2004-11-11 Li Jian Min Contents transmission network system and creating method thereof
US20030208572A1 (en) 2001-08-31 2003-11-06 Shah Rajesh R. Mechanism for reporting topology changes to clients in a cluster
US7283579B2 (en) * 2003-06-19 2007-10-16 Motorola, Inc. Diversity synchronous connection-oriented audio communication modes
US7188202B1 (en) 2003-09-29 2007-03-06 Emc Corporation Techniques for accessing devices through a set of serial buses
US20050091432A1 (en) 2003-10-28 2005-04-28 Palmchip Corporation Flexible matrix fabric design framework for multiple requestors and targets in system-on-chip designs
US7623524B2 (en) 2003-12-22 2009-11-24 Intel Corporation Scheduling system utilizing pointer perturbation mechanism to improve efficiency
JP2005250833A (ja) * 2004-03-04 2005-09-15 Nec Electronics Corp バスシステム及びアクセス制御方法
US7773591B2 (en) * 2007-07-06 2010-08-10 Integrated Device Technology, Inc. Integrated memory for storing egressing packet data, replay data and to-be egressed data
US20090259736A1 (en) * 2008-04-15 2009-10-15 Juniper Networks, Inc. Label-based target host configuration for a server load balancer
US20090307408A1 (en) 2008-06-09 2009-12-10 Rowan Nigel Naylor Peer-to-Peer Embedded System Communication Method and Apparatus
US7934046B2 (en) 2008-07-02 2011-04-26 International Business Machines Corporation Access table lookup for bus bridge
US20100114826A1 (en) * 2008-10-24 2010-05-06 Microsoft Corporation Configuration management in distributed data systems
US8032678B2 (en) * 2008-11-05 2011-10-04 Mediatek Inc. Shared resource arbitration
JP2011095966A (ja) 2009-10-29 2011-05-12 Yamaha Corp アクセスコントローラ
US8539132B2 (en) * 2011-05-16 2013-09-17 Qualcomm Innovation Center, Inc. Method and system for dynamically managing a bus of a portable computing device

Also Published As

Publication number Publication date
WO2012151162A3 (en) 2013-01-10
CN103597784A (zh) 2014-02-19
JP2014513494A (ja) 2014-05-29
KR101503209B1 (ko) 2015-03-24
US20120284354A1 (en) 2012-11-08
CN103597784B (zh) 2016-09-28
EP2705433B1 (en) 2015-05-20
US8595366B2 (en) 2013-11-26
JP5759619B2 (ja) 2015-08-05
EP2705433A2 (en) 2014-03-12
WO2012151162A2 (en) 2012-11-08

Similar Documents

Publication Publication Date Title
KR101503209B1 (ko) 휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템
US8806502B2 (en) Batching resource requests in a portable computing device
US8631414B2 (en) Distributed resource management in a portable computing device
US8601484B2 (en) System and method for managing resources and markers of a portable computing device
US8615755B2 (en) System and method for managing resources of a portable computing device
US9098521B2 (en) System and method for managing resources and threshsold events of a multicore portable computing device
JP2013516711A (ja) 電子デバイスにおける電力を制御するシステムおよび方法
WO2013158241A2 (en) Method and system for minimal set locking when batching resource requests in a portable computing device
EP2751687B1 (en) Method and system for managing parallel resource requests in a portable computing device
CN111030856B (zh) 一种基于云的数据接入方法、电子设备及计算机可读介质

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20171228

Year of fee payment: 4

LAPS Lapse due to unpaid annual fee