KR100305138B1

KR100305138B1 - 멀티프로세서 시스템에서 버스의 병렬 액세스를 위한 신호화 프 로토콜

Info

Publication number: KR100305138B1
Application number: KR1019960703806A
Authority: KR
Inventors: 브라이언 에프. 베네트
Original assignee: 윤종용; 삼성전자 주식회사
Priority date: 1994-01-14
Filing date: 1995-01-06
Publication date: 2001-11-22
Also published as: WO1995019600A1; CN1111799C; AU1523595A; CN1143421A; KR970700879A; US5426740A

Abstract

멀티프로세서 시스템(10) 용의 향상된 신호화 프로토콜은 I/O 버스 액세스시 공통

시스템 버스(18)에 대한 병렬 액세스를 가능하게 한다. 이것은 전체 버스 대역폭

의 증가를 감소시킬 수 있는 시스템 버스 아키텍처의 복잡성을 유발하지 않고도 시

스템 버스의 아이들링 타임을 줄인다. 향상된 버스 아키텍처는 I/O 버스(20)가 사

용중이고 모든 다른 I/O 요구가 현재의 트랜잭션이 완료될 때까지 유지되어야 하는

것을 모든 프로세서(12)에게 나타내기 위해 시스템 생성의 I/O 버스 비지(IOBUS_BSY-) 신호를 사용한다. 다른 프로세서(12)가 I/O 요구를 수행하는 것을 방지함으로써 시스템 버스(18)는 아이들을 유지할 필요가 없어서 I/O 버스(20)의 사용중에 메모리 프로세서간 및 프로세서 프로세서간의 트랜잭션 용으로 사용될 수 있다. 시스템 버스(18)의 아이들 시간을 감소시킴으로써 시스템 버스의 전체 성능은 아주 증가된다.

Description

[발명의 명칭]

멀티프로세서 시스템에서 버스의 병렬 액세스를 위한 신호화 프로토콜

[발명의 배경]

[발명의 분야]

본 발명은 멀티프로세서 시스템에서 I/O 버스 및 시스템 버스의 병렬 액세스를 인에이블하는 향상된 버스 브릿지에 관한 것이다.

[종래 기술에 대한 설명]

멀티프로세서 시스템에서, 시스템 내의 모든 프로세서들은 공통 시스템 버스 및 공통 I/O 버스를 공유한다. 이러한 공통 버스 아키텍처는 시스템 버스 및 I/O 버스 둘다에 대해서 한번에 한번의 전송으로 제한한다. I/O 버스 브릿지는 시스템 버스를 I/O 버스에 링크시킨다. 그러므로, 1개의 프로세서가 시스템 또는 I/O 버스와 통할 때, 다른 프로세서들은 자체 내부 동작으로 비지 상태이거나, 시스템 및 I/O 버스들에 대해 대기 상태가 되고, 결국 프리 상태로 된다. 프로세서가 이용가능한 버스에 대해 대기 상태를 보내는 시간은 버스 대기 시간으로 인용된다.

종래의 멀티프로세서, 즉 공통 버스 아키텍처에서는 I/O 요구 중에 시스템 버스는 요구된 어드레스를 프로세서로부터 I/O 버스 브릿지로 전송하는 짧은 시간 동안에만 사실상 필요하다. 그러나, 버스 브릿지는 전체 데이타 전송을 위해 시스템 버스를 아이들 상태로 유지한다. I/O 버스 상의 I/O 제어기는 I/O 버스 브릿지로부터의 어드레스를 래치하고, 요구를 처리한다. 데이타 전송 시간은 I/O 디바이스의 액세스 시간에 따라 상당히 길 수 있다. I/O 사이클이 완료되면, 시스템 버스 및 I/O 버스 둘다는 다른 프로세서에 이용가능하게 된다.

1개의 프로세서가 I/O 버스를 사용하는 주기 동안에, 버스 브릿지는 시스템 버스를 앙들 상태로 유지하고; 다른 프로세서는 소정 형태의 데이타 전송을 개시하기 위해 이용해야 하는 버스를 대기해야만 한다. 프로세서들의 수가 증가할 때, 버스 액세스의 회수가 증가하므로, 버스 대기 시간은 증가한다. 본래, 전형적으로 버스 아키텍처는 I/O 버스가 액세스되고 시스템 버스가 I/O 사이클의 완료를 대기하는 동안 아이들 상태를 유지할 때의 시간 주기이다. 이 시간 동안, 요구 프로세서는 시스템 버스를 사용하지 않는다. 오히려, 요구 프로세서는 I/O 사이클의 완료를 나타내는 I/O 버스로부터의 회답을 수신할 때까지 다른 프로세서가 시스템 버스를 액세스 하지 못하게 하도록 시스템 버스를 유지한다. I/O 사이클이 완료되는 것을 대기하는 동안 시스템 버스가 활동화되지 않게 유지되는 시간은 멀티프로세서 시스템 내에서의 버스 대기 시간의 주된 원인이다.

시스템 버스의 아이들링 시간을 줄이기 위해서는, 시스템 버스 레벨 트랜잭션이 발생하도록 인에이블링시키면서, 소정의 새로운 I/O 레벨 트랜잭션이 발생하는 것을 방지하도록 프로토콜이 개발될 필요가 있다. 한가지 가능한 해결책은 I/O 버스에 대한 트랜잭션이 일단 시작된 때 개시된 소정의 I/O 요구를 취소하기 위해서 "백-오프(back-off)" 동작을 사용하여, 메모리 및 프로세서간 전송을 위해 시스템 버스를 해제시키는 것이다. 문제점은 EISA 버스와 같은 소정의 I/O 버스가 깨끗한 "백-오프" 동작을 허용하지 않는다는 것이다. EISA 버스에 의해 제공된 "백-오프" 동작만이 바람직하지 않은 요구 프로세서에 의한 에러 상태를 수신하게 한다.

EISA 버스의 경우에 I/O 버스가 깨끗한 백-오프를 위해 제공되지 않으면, 다른 해결책은 시스템 버스를 "백-오프"시키는 것이다. 그러나, 멀티프로세서 시스템에서, I/O 버스를 액세스하려는 프로세서를 "백-오프"하고 시스템 버스 상의 다른 프로세서를 진행시키는 것이 바람직하다. 따라서, 단일 백-오프 신호를 갖는 것은 전체 시스템 버스를 "백-오프"시킨다. 전체 버스의 "백-오프"는 버스 대기 시간의 문제를 해결하지 못하고 또 다른 문제를 발생시킨다.

다른 옵션은 I/O 버스 브릿지 상의 각각의 프로세서에 "백-오프" 신호를 발생하는 것이다. 이 경우, N개의 핀은 버스 브릿지에 추가되어, N개의 프로세서들 또는 각각에 개별 백-오프 신호를 전송한다. 멀티프로세서 시스템 내에서 보통 프로세서들의 수는 5-8이고, 따라서 5-8개의 핀은 평균적으로 I/O 버스 브릿지에 추가된다.

전형적인 버스 브릿지는 핀이 제한된 회로, 즉 출력 신호를 부가하기 위해 이용할 수 있는 여분의 핀이 그다지 많지 않은 회로이다. 부가적으로, 논리는 제어될 필요가 있는 각각의 백-오프 신호를 위해 버스 브릿지에 추가되어야 한다. 이들 추가된 복잡성은 최적의 해결책을 만들지 못한다. 더구나,I/O 버스 브릿지가 데이타를 캐시하게 하면, 캐시 일관성 프로토콜은 백-오프 프로토콜의 개시를 매우 어렵게 만든다. 일단, 요구가 개시되면, 다른 프로세서 모듈은 캐시를 스누핑(snooping)할 수 있고, 일단 스누프되면 "언스누프(unsnooped)"될 수 없다. 따라서, 단일 프로세서 시스템 내에 사용된 간단한 백 오프 프로토콜은 멀티프로세서 시스템에 최적의 해결책은 아니다.

멀티프로세서 시스템 내에서 대기 시간에 기여하는 다른 요인은 대부분의 I/O 버스들이 시스템 버스보다 늦기 때문이다. 예를 들어, 공통 멀티프로세서 시스템 버스는 25 MHz에서 동작하고, 64 비트의 폭을 갖는다. EISA 버스와 같은 공통 I/O버스는 8 MHz에서 동작하고, 단지 32 비트 폭을 갖는다. 따라서, 전형적인 시스템 버스는 데이타를 200 Mbyte/sec의 속도로 전송한다. EISA 버스의 데이타 전송 속도는 겨우 33 Mbyte/sec이다. 그러므로, 시스템 버스는 장기간 동안 비사용 버스 시간으로 유지되고, 반면에 데이타는 더 늦은 데이타 속도로 I/O 버스로부터 시스템으로 전송되며, I/O 버스의 비트 폭보다 작은 폭을 갖는다. 더 빠른 시스템 버스가 트랜잭션을 완료하기 위해 더 늦은 버스를 대기하도록 강제된 시간 주기는 시스템 버스로부터 얻을 수 있는 속도 및 효율을 소모시키고 시스템 버스 대기 시간에 기여하는 요인이다.

따라서,I/O 버스 트랜잭션 및 긴 I/O 데이타 전송 동안 시스템 버스 아이들링에 의해 발생된 버스 대기 시간을 감소시킬 필요성이 멀티프로세서 시스템에는 존재한다.

[발명의 요약]

본 발명의 양호한 실시예는 멀티프로세서 시스템용의 향상된 신호화 프로토콜을 포함한다. 양호하게는, 멀티프로세서 시스템은 공통 시스템 버스에 접속되고 I/O 버스 브릿지를 통해 I/O 버스에 접속된 다수의 CPU 모듈을 포함한다. 본 발명의 디자인은 시스템 버스 아이들 시간을 이용할 수 있게 만들고, I/O 버스 액세스 동안 공통 시스템 버스에 동시성 액세스를 인에이블시킨다. 또한, 본 발명은 전체적 버스 대역폭 증가를 감소시키는 시스템 버스 아키텍처 내에 복잡성을 유입시키지 않는다.

본 실시예의 향상된 버스 아키텍처는 I/O 버스가 사용 상태에 있고 다른 모든 I/O 요구가 현재 트랜잭션이 완료될 때까지 유지되어야 함을 나타내기 위해서 시스템 발생 I/O 버스 비지(TOBUS_BSY_) 신호를 사용한다. 다른 프로세서가 I/O 요구를 실행하지 못하게 방지하므로써, 시스템 버스는 아이들 상태로 유지되지 않고, I/O 버스가 사용중인 동안에 프로세서 메모리간 및 프로세서간 트랜잭션을 위해 사용될 수 있다. 시스템 버스가 아이들 상태로 유지되어야 하는 시간량을 감소시키므로써, 전체 시스템 버스 성능은 상당히 증가한다.

양호한 실시예에서, 멀티프로세서 시스템용의 향상된 신호화 프로토콜 회로는 I/O 버스 프로토콜 회로, 각각의 CPU 모듈에 대한 버스 제어기 논리 회로, 및 각각의 CPU 모듈에 대한 I/O 버스 금지 회로를 포함한다. I/O 버스 프로토콜 회로는 양호하게 I/O 버스 브릿지 상에 위치하고, 제1 및 제2 논리 상태의 I/O 버스 비지 신호를 발생한다.

I/O 버스 비지 신호의 제1 논리 상태는 I/O 버스가 현재 I/O 버스 트랜잭션을 바쁘게 처리 중임을 나타내며, 또 제2 논리 상태는 I/O 버스가 I/O 버스 트랜잭션 처리가 가능하다는 것을 나타낸다. 각각의 CPU 모듈 상의 버스 제어기 논리 회로 각각은 개별적인 CPU로부터 어드레스 요구를 수신하며, CPU 어드레스 요구를 시스템 버스에 전달하는 것을 제어한다. 각각의 CPU 모듈 상의 I/O 버스 금지 회로는 어드레스 및 사이클형 디코더 및 논리 회로를 더 포함한다. 어드레스 및 사이클형 디코더는 제1 및 제2 논리 상태를 갖는 I/O 버스 액세스 신호를 발생한다. I/O 버스 액세스 신호의 제1 논리 상태는 CPU 어드레스 요구가 I/O 버스에 대한 액세스를 요구한다는 것을 나타내며, 또 제2 논리 상태는 CPU 어드레스 요구가 I/O 버스에 대한 액세스를 요구하지 않는다는 것을 나타낸다. 양호하게, 논리 회로는 I/O 버스 액세스 신호에 접속된 제1 입력 및 I/O 버스 비지 신호에 접속된 제2 신호인 제1 및 제2 입력을 갖는다. 논리 회로의 모든 출력은 금지 신호를 발생하는데, 상기 금지 신호는 I/O 버스가 현재의 I/O 버스 트랜잭션을 완료할 때까지 CPU 어드레스 요구가 시스템 버스에 전달되는 것을 금하도록 버스 제어기 논리 회로에 접속된다.

양호한 실시예에서, 개선된 신호화 프로토콜 회로는 시스템 버스와 I/O 버스 사이에 삽입된 버퍼 회로를 더 포함하는데, 이때 시스템 버스로부터 I/O 버스로 전송되는 데이타는 시스템 버스 속도로 버퍼 회로에 전송되고 상기 버퍼로부터 I/O 버스 속도로 출력되며, I/O 버스로부터 시스템 버스로 전송된 데이타는 I/O 버스 속도로 버퍼 회로로 전송되어 버퍼로부터 시스템 버스 속도로 출력된다.

버퍼 회로는 I/O 버스로부터 시스템 버스로 데이타가 전송되는 시간 기간을 감소시킨다. I/O 버스 브릿지 상에 양호하게 위치되는 버퍼 회로는 I/O 버스로부터 I/O 버스의 속도보다 낮은 속도를 데이타를 수신하여 데이타를 저장한다. 데이타가 I/O 버스로부터 버퍼 회로로 전송되는 동안, 시스템 버스는 다른 트랜잭션을 처리할 수 있도록 자유로운 상태가 되며, I/O 버스의 데이타 속도보다 낮은 속도로 데이타를 수신하도록 인터럽팅 되지 않는다. 일단 모든 데이타가 버퍼 회로에 저장되면, 버스 브릿지는 시스템 버스에 통지하며, 버퍼 회로로부터 모든 데이타를 시스템 버스의 데이타 속도보다 빠른 속도로 시스템 버스 상에 내놓는다. 이러한 프로세스는 I/O 버스 대 시스템 버스 데이타 전송의 효율성을 크게 개선시킨다.

멀티프로세서 시스템에서 사용하기 위한 개선된 신호화 프로토콜 방법의 양호한 실시예에는 제1 논리 상태는 I/O 버스가 현재 I/O 버스 트랜잭션을 바쁘게 처리 중임을 나타내며, 또 제2 논리 상태는 I/O 버스가 I/O 버스 트랜잭션 처리가 가능하다는 것을 나타내는 제1 및 제2 논리 상태를 갖는 I/O 버스 비지 신호를 I/O 버스 브릿지상에 발생하는 단계가 포함된다. 경우에 따라서, 각각의 CPU 모듈은 I/O 버스 비지 신호를 수신하여 CPU 어드레스 요구가 I/O 버스에 대한 액세스를 요구하는가를 결정한다. 만일, CPU 요구된 어드레스가 I/O 버스 비지 신호의 상태에 무관하게 I/O 버스에 대한 액세스를 요구하지 않는다면, CPU 어드레스 요구는 공통 시스템 버스가 사용가능한 때에는 공통 시스템 버스 상에서 처리된다. 만일, 어드레스 요구가 I/O 버스에 대한 액세스를 요구하며, 또 I/O 버스 비지 신호가 제1 논리 상태에 있다면, CPU 어드레스 요구가 유지된다. 마지막으로, 만일 어드레스 요구가 I/O 버스에 대한 액세스를 요구하며, I/O 버스 비지 신호가 제2 논리 상태에 있다면, 시스템 버스가 사용가능한 때에 CPU 어드레스 요구가 처리된다.

[도면의 간단한 설명]

제1도는 본 발명의 양호한 실시예의 버스 아키텍처를 구현하는 멀티프로세서 시스템의 시스템 블록도.

제2도는 멀티프로세서 시스템에서 또 이를 시스템 버스와 통신하는데 사용되는 전형적인 CPU 모듈의 블럭도.

제3도는 본 발명의 I/O 버스 프로토콜 회로를 구현하는 버스 브릿지 및 상기 버스 브릿지와 시스템 및 I/O 버스 사이의 통신에 대한 블럭도.

제4도는 본 발명의 버스 신호 프로토콜을 구현하는 각각의 CPU 모듈 상의 버스 제어기의 버스 콘트롤 논리를 도시하는 상태도.

제5(a)도는 I/O 제어기에 의한 동시 I/O 버스 액세스 동안 금지되는 제2 CPU 모듈에 의한 I/O 버스의 시도 액세스 클럭 사이클(1-11)을 도시하는 타이밍도.

제5(b)는 I/O 제어기에 의한 동시 I/O 버스 액세스 동안 금지되는 제2 CPU 모듈에 의한 I/O 버스의 시도 액세스 클럭 사이클(12-22)를 도시하는 타이밍도.

제6(a)도는 I/O 제어기에 의한 I/O 버스 요구와 동시에 발생하기 때문에 금지되지 않는 CPU 모듈에 의한 I/O 버스의 시도 액세스의 클럭 사이클(1-11)을 도시하는 타이밍도.

제6(b)도는 I/O 제어기에 의한 I/O 버스 요구와 동시에 발생하기 때문에 금지되지 않는 CPU 모듈에 의한 I/O 버스의 시도 액세스의 클럭 사이클(12-22)를 도시하는 타이밍도.

제7도는 본 발명의 I/O 버스 프로토콜 회로의 대안적인 실시예를 구현하는 버스 브릿지의 대안적인 실시예에 대한 블럭도.

제8도는 본 발명의 버스 신호화 프로토콜을 구현하는 버스 브릿지의 대안적인 실시예의 콘트롤 논리를 도시하는 상태도.

제9도는 본 발명의 버스 신호화 프로토콜을 구현하는 각각의 CPU 모듈 상의 버스 제어의 대안적인 실시예의 버스 콘트롤 논리를 도시하는 상태도.

제10(a)도는 I/O 버스가 다른 트랜잭션으로 바쁜 때 2개의 CPU 모듈에 의한 I/O 버스에 대한 시도 액세스의 클럭(1-11)을 도시하는 타이밍도.

제1O(b)도는 I/O 버스가 다른 트랜잭션으로 바쁜 때 2개의 CPU 모듈에 의한 I/O 버스에 대한 시도 액세스의 클럭(12-22)를 도시하는 타이밍도.

[양호한 실시예의 상세한 설명]

본 발명의 양호한 실시예는 공통 버스 시스템을 갖는 멀티프로세서 시스템 (10)에서 사용하기 위한 개선된 신호화 프로토콜을 포함한다(즉, 프로세서는 공통 메모리 및 공유 I/O 버스 자원에 대한 액세스를 갖는다). 제1도는 다수의 CPU 모듈(12, 즉, CPU 모듈 #1, CPU 모듈 #2‥‥‥ CPU 모듈 #N), 다수의 메모리 모듈(14, 즉, 메모리 모듈 #1, 메모리 모듈 #2‥‥‥ 메모리 모듈 #M) 및 다수의 I/O 제어기(16, 즉, I/O 제어기 #1, I/O 제어기 #2‥‥‥ I/O 제어기 #P)를 포함하는 종래의 멀티프로세서 시스템(10)을 도시한다. CPU 모듈(12) 및 메모리 모듈(14)들은 시스템 어드레스 버스, 시스템 데이타 버스 및 시스템 콘트롤 버스를 더 포함하는 시스템 버스(18)에 접속된다. I/O 제어기(16)들은 주변 I/O 제어기(16) 및 장치(도시되지 않음)의 동작 콘트롤에 각각 접속된다. 모든 I/O 제어기(16)들은 I/O 버스(20)에 접속된다. I/O 버스는 I/O 어드레스 버스, I/O 데이타 버스 및 I/O 콘트롤 버스를 더 포함한다. 버스 브릿지(22) 또는 I/O 서비스 모듈(ISOM 모듈)은 I/O 제어기(16)과 시스템 버스(18) 사이의 데이타 흐름을 제어하기 위하여 시스템 버스(18) 및 I/O 버스(20) 사이의 인터페이스를 제공한다.

제2도는 제1도의 멀티프로세서 시스템(10)에서 사용되는 전형적인 CPU 모듈의 블럭도를 도시한다. 양호하게, CPU 모듈(12)는 마이크로프로세서(24), 내부 디코더 논리를 갖는 캐시 메모리 시스템(CACHE, 26), CPU 또는 로컬 프로세서 버스(26), 버스 송수신기(30) 및 시스템 버스 제어기 논리(32)를 포함한다. 본 발명의 한 실시예에 따르면, 각각의 CPU 모듈(12)는 I/O 버스 금지 회로(34)를 더 포함한다. I/O 버스 금지 회로의 한 실시예는 어드레스 및 사이클형 디코더(36), 2입력 AND 게이트(38) 및 인버터(40)을 포함한다.

어드레스 및 사이클형 디코더(36)은 마이크로프로세서(24)에 의해 요구된 어드레스가 I/O 버스(20)에 대한 액세스를 요구하는지를 결정한다. 어드레스 및 사이클형 디코더(36)의 출력은 라인(42) 상의 IOBUS_ACCESS 신호이다. IOBUS_ACCESS 신호는 활동 하이 신호, 즉, 참인 때에는 논리 하이 레벨 또 거짓일 때에는 논리 로우 레벨인 신호이다. 라인(42) 상의 IOBUS_ACCESS 신호는 2입력 AND 게이트(38)의 제1 입력(44)에 접속된다. 2입력 AND 게이트(38)의 제2 입력(46)은 인버터(40)의 출력(48)에 접속된다. 인버터(40)의 입력(50)은 라인(52) 상의 IOBUS_BSY 신호에 접속된다. 라인(52) 상의 IOBUS_BSY 신호는 아래에 더 상세하게 설명되는 바와 같이, I/O 버스(20)이 현재 사용 중인 때를 나타내도록 I/O 버스 프로토콜 회로 상의 논리에 의해 발생된다. IOBUS_BSY 신호는 활동 로우, 즉 신호가 참인 때에는 논리 로우 값이고 또 신호가 거짓인 때에는 논리 하이 값인 신호이다.

IOBUS_ASY 신호는 활동 하이 논리 신호인 라인(42) 상의 IOSUB_ACCESS 신호논리를 따르기 위해 인버터(40)에 의해 반전된다. 2-입력 AND 게이트(38)의 출력은라인(54) 상에 INHIBIT_MP_ACCESS 신호를 생성한다. INHIBIT_MP_ACCESS 신호는 활동 하이 신호이고 버스 제어기(32)에게 마이크로프로세서(24)가 현재 사용중인 I/O 버스(20)에의 액세스를 필요로하는 어드레스를 요구하고 있다는 것을 가리켜 준다. 라인(54) 상의 INHIBIT_MP_ACCESS 신호는 I/O 사이클이 완결될 때까지 버스 액세스를 금지하기 위해 버스 제어기 논리(33)에 전달된다. 버스 제어기 논리(33)은 라인(56) 상의 다수의 버스 송수신기 인에이블 신호 TRANS_ENS를 비활동 레벨에 있는 버스 송수신기(30)에 전달하여 이후에 더 자세히 기술된 바와 같이, 현재의 I/O 사이클이 완결될 때까지 마이크로프로세서의 요구받은 어드레스가 시스템 버스(18)에 제공되는 것을 방지한다. 또한, CPU의 어드레스 요구에 응답하여, 시스템 버스 상의 유효한 데이타가 프로세서(24)에 쏟아 부어질 준비가 되었을 때 버스 제어기 논리(33)은 라인(58) 상의 BRDY- 신호를 마이크로프로세서 (24)에 반환한다.

제3도는 제1도의 멀티프로세서 시스템(10)에 사용된 전형적인 버스 브릿지 (22)의 블럭도를 설명한다. 양호하게, 버스 브릿지(22)는 센트럴 아비터(central arbiter,6), 한 세트의 양방향 어드레스 및 데이타 버퍼(62), 및 제어 논리 회로 (63)을 포함한다. 양호하게 제어 논리 회로(63)은 I/O 사이클 타이밍과 몇 시스템 버스 제어 신호의 상태를 제어한다. 본 발명의 한 실시예에 따라, 버스 브릿지(22)는 I/O 버스 프로토콜 회로(64)를 더 포함한다. I/O 버스 프로토콜 회로(64)는 어드레스 디코더(66)과 제어 회로(68)을 포함한다. 논리 회로(68)은 본 발명의 신호 프로토콜(signaling protocol)을 구현하기 위해 부가되는 센트럴 아비터(60)의 일부이다.

I/O 버스 프로토콜 회로(64)는 시스템 버스(18)로부터의 어드레스 요구를 수신하고, 어드레스 디코더(66)으로 전달한다. 어드레스 디코더(66)은 시스템 버스 (18) 상의 어드레스 요구가 I/O 버스(2)에의 액세스를 요구하는지를 결정한다. 어드레스 디코더(42)의 출력은 라인(70) 상의 MP-2-IO-ACCESS 신호이다. 이것은 활동 하이신호이다. 만일 요구된 어드레스가 I/O 버스(20)에의 액세스를 요구한다면, MP-2-IO-ACCESS 신호가 활동될 것이다. 라인(70) 상의 MP-2-IO-ACCESS 신호는 센트럴 아비터(60)으로 전달된다.

센트럴 아비터(60)은 디코드된 MP-2-IO-ACCESS 신호를 수신하고 I/O 버스 (20)이 요구된 어드레스에 응답할 필요가 있는지를 결정한다. 센트럴 아비터(60)은 요구하는 CPU 모듈(12)에 대한 I/O 버스(18)의 허락을 제어하며 I/O 액세스를 개시하고 완결하기 위해 요구되는 핸드쉐이킹 신호를 제어한다. 센트럴 아비터(60)은 각각의 CPU 모듈들(12)로부터 한 세트의 라인(70) 상의 시스템 버스 요구(SBREQx-)신호(즉, SBREQI-,SBREQ2‥‥‥ SBREQN-)를 수신한다. 센트럴 아비터 (60)은 이들 시스템 버스(18)에 대한 요구를 감시하고 한 세트의 라인(74) 상의 시스템 버스 승인(SBACKx-) 신호(즉, SBACK1, SBACK2‥‥ SBACKN-)를 각 CPU 모듈(12)로 반환하여 시스템 버스(18)로의 액세스가 허락된 때를 각 모듈에게 가리켜 준다.

센트럴 아비터(60)은 또한 I/O 제어기들(16)으로부터 I/O 버스(20)에의 액세스에 대한 I/O 요구, 즉, 라인(76) 상의 IOBUS_REQ- 신호를 감시한다. 센트럴 아비터(60)은 CPU 모듈들(12)와 I/O 제어기들(16) 양측 모두로부터의 요구를 재검토한다. 그러나 센트럴 아비터(60)은 어떤 주어진 시간에 I/O 제어기들 중 하나나 CPU 모듈들 중 하나에만 I/O 버스(20)에의 액세스를 허락한다

I/O 제어기(16)이 I/O 버스(20)에의 액세스를 허락받았을 때, 센트럴 아비터(60)은 라인(78)로부터의 버스 승인(IOBUS_ACK-) 신호를 반환한다. IOBUS_ACK- 신호의 수신은 I/O 제어기(16)에게 I/O 버스(20) 상으로 어드레스나 데이타를 위치시켜도 된다는 것을 가리켜 준다.

만일 I/O 제어기(16)이 I/O 버스(18)로의 액세스를 요구하고, I/O 버스(20)이 이용가능하다면, 센트럴 아비터(60)은 라인(52)상에 I/O 버스 BUSY 신호를 액티브 레벨로 셋팅한다. 라인(52) 상의 IOBUS_BSY- 신호는 I/O 버스(20)이 요구 받았다는 것을 CPU 모듈들(12)에게 가리켜주고, CPU 모듈들(12)는 현재의 트랜잭션이 완결될 때까지 그들의 I/O 요구를 보류할 것이다. 다른 CPU 모듈들(12)가 I/O 요구를 실행하는 것을 방지함으로써 시스템 버스(18)은 아이들 상태로 유지될 필요가 없어지고, I/O 버스(20)이 사용 중일 동안에, 캐시 히트 응답(cache hits responses)들과 같은 메모리와 CPU 모듈대 CPU 모듈간 트랜잭션에 사용될 수 있다. 부가적으로 버스 브릿지(22)는 또한 한 셋트의 양방향 어드레스 및 데이타 버퍼(62)를 포함한다.

이것은 I/O 버스(20)에서 시스템 버스(18)로의 데이타 전송에 요구되는 시간을 줄인다. I/O 버스 브릿지(22) 상의 버퍼(62)는 I/O 버스(20)의 더 느린 데이타 속도(rates)로 I/O 버스(20)으로부터 데이타를 수신할 수 있고 임시로 데이타를 저장할 수도 있다. 데이타가 I/O 버스(20)으로부터 버스 버퍼(22)로 전달되는 동안, 시스템 버스(18)은 자유로이 다른 트랜잭션들을 처리하고, I/O 버스(20)의 더 느린 데이타 속도로 데이타를 수신하기 위해 인터럽트되지 않는다. 일단 모든 데이타가 버퍼(62)에 의해 저장되면, 버스 브릿지(22)는 시스템 버스(18)에게 이를 통지하고 버퍼로부터의 모든 데이타를 시스템 버스(18) 상에 시스템 버스(18)의 더 빠른 데이타 속도로 쏟아 붓는다. 이러한 프로세스는 I/O 버스(20)대 시스템 버스(18)간의 데이타 전송 효율을 대단히 개선한다.

본 발명에서, CPU 모듈(123)에 의한 시스템 버스(18)로의 CPU-요구된 어드레스는 아래에 기술된 바와 같이 버스 제어기 논리(32)와 버스 금지 회로(34)에 의해 변경된다. 어드레스 요구가 시스템 버스(18)에 제공되기 전에, 버스 제어기 논리 (32)와 버스 금지 회로(34)는 I/O 버스(20) 액세스가 요구되는지를 검사한다. 만일 I/O 버스 액세스가 요구된다면, 버스 제어기는 자신의 어드레스와 시스템 어드레스 스트로브(SADDS-)를 시스템 버스(18) 상에 놓기 전에 시스템 버스(18)과 I/O 버스(20) 양쪽 모두가 이용가능할 때까지 기다려야 한다.

제2도와 제4도를 참조하면, 양호한 실시예의 I/O 버스 금지 회로를 병합하는 CPU 모듈(12) 상의 버스 제어기(32)에 의한 어드레스 요구 즉, SADDS- 신호 발생의 개시는 제4도의 상태도와 관련해 기술될 것이다. 초기에, 상태 S0에서 버스 제어기(32)는 마이크로프로세서(32)에 의해 라인(80) 상의 CPU 어드레스 스트로브(CADS-) 신호의 발생을 기다린다. CADS- 신호는 활동 로우 신호이고 마이크로프로세서(24)가 어드레스 요구를 제기하고 있다는 것을 가리킨다. 라인(80) 상의 CADS- 신호가 비활동인 중에는, 버스 제어기(32)는 어드레스 요구를 기다리며 상태 S0에 남아있다. 라인(80) 상의 CADS- 신호가 활동되면, 버스 제어기(32)는 상태 S1으로 진행한다.

상태 S1에서 버스 제어기(32)는 라인(82)의 어드레스 버스 이용가능 (ABUSVL) 신호와 라인(74)의 시스템 버스 승인(SBACKBx-)신호의 상태를 검사한다. ABUSAVL 신호는 활동 하이 신호이고 시스템 버스(18)이 CPU 모듈들(12)중의 하나로부터의 어드레스 요구를 수신하기위해 이용가능하다는 것을 가리킨다. SBACKx- 신호는 시스템 버스(18)이 CPU 모듈(12)에 의한 버스 요구를 승인했다는 것을 가리키는 활동 로우가 된다. 만일 ABUSAVL 신호가 활동이 아니라면, 즉 다른 CPU 모듈(12)가 시스템 어드레스 버스를 사용하는 중이고, SBACKx- 신호가 활동이 아니라면, 즉, 시스템 버스(18)이 CPU 모듈(12)에 의한 어드레스 요구를 승인하지 않았다면 버스 제어기(32)는 상태 S1에서 계속 기다린다.

버스 제어기(32)가 활동 레벨에서 SBACKx 신호를 수신하고 활동 레벨에서 ABUSAVL 신호를 수신하면, 버스 제어기(32)는 상태 S2로 이동하게 된다. 상태 S2에서 버스 제어기(32)는 라인(86) 상의 시스템 버스 비지(SBUBSY) 신호의 상태를 검사한다. SBUBSY 신호는 시스템 버스(18)가 다른 CPU 모듈(12)에 의해 개시된 이전의 트랜잭션을 현재 처리하고 있을 때를 나타내는 활동 로우 신호이다. 라인(86) 상의 SBUSBSY 신호가 비활동 레벨에서 수신되면, 시스템 버스(10)는 유효 가능하게 되고, 버스 제어기(32)는 상태 S4로 진행하게 된다. 상태 S2에서 상태 S4로의 전이시에, 버스 제어기(32)는 시스템 어드레스 활동(SADDS) 신호를 발생하고, 이 신호는 유효 어드레스가 나타나 있는 것을 시스템 버스(10)에 표시한다.

SBUSBSY 신호가 활동이면, 버스 제어기(32)는 라인(42) 상의 IOBUS_ACCESS 신호와 라인(52) 상의 IOBUS_BSY 신호의 상태를 체크한다. IOBUS_ACCESS 신호는 CPU 모듈(12) 상의 어드레스 및 사이클 타입 디코더(36)에 의해 발생된다.

IOBUS_ACCESS 신호가 활동 상태에 있으면, 마이크로프로세서(24)에 의해 요구된 어드레스는 I/O 버스(20)의 액세스를 필요로 하게 된다. 상술한 바와 같이, 라인(52) 상의 IOBUS_BSY 신호는 버스 브릿지(22)에 의해 발생되며 I/O 버스(30)가 현재 사용중일 때를 나타낸다. IOBUS_BSY 신호(52)가 비활동이고, SBUSBSY 신호가 활동인 동안 IOBUS_ACCESS 신호가 비활동이면, CPU 요구된 어드레스는 현재 비지 상태인 시스템 버스(16)에의 액세스를 필요로 하고, 이에 따라 버스 제어기(32)는 상태 S2에서 대기하게 된다. IOBUS_ACCESS 신호가 활동이고 SBUSBSY 신호가 활동인 동안 IOBUS_BSY 신호가 활동이면, 요구된 어드레스는 현재 비지 상태인 I/O 버스(20)에의 액세스를 필요로 하고, 이에 따라 버스 제어기(32)는 상태 S3으로 진행하게 된다.

상태 S3에서 버스 제어기는 IOBUS_BSY 신호의 상태를 검사한다. IOBUS_BSY신호가 활동인 동안, I/O 버스(20)가 다른 트랜잭션으로 현재 비지 상태인 것을 나타내게 되고, 버스 제어기(32)는 상태 S3에서 대기한다. 일단 IOBUS_BSY 신호가 비활동이면, 버스 제어기(32)는 I/O 버스(20)가 유효 가능하기 때문에 원하는 어드레스 요구를 다시 시도할 수 있는 상태 S1으로 복귀한다.

상태 S4에서, 버스 제어기(32)는 상태 S5로 즉시 진행한다. 상태 S5에서, 버스 제어기(32)는 라인(88) 상의 트랜잭션 홀드(TRNSHLD-)의 상태를 검사한다. TRNSHLD 신호는 활동 로우 신호이다. TRNSHLD 신호는 시스템 버스(18)에 접속된 각 디바이스에 의해 활동 레벨로 구동되는 동안 각 디바이스는 요구된 데이타를 가지고 있는지(즉, 어드레스가 디바이스가 응답하는 어드레스에 대응하는지)를 판정한다. 각 디바이스가 요구된 어드레스에 응답하지 않았다고 판정하게 되면, TRNSHLD 신호를 해제한다. 라인(88) 상의 TRNSHLD 신호가 활동인 동안, 버스 제어기 논리(32)은 상태 S3에 유지된다. TRNSHLD 신호가 비활동이면, 버스 제어기 논리(32)은 S0상태로 되돌아가 다음 어드레스 요구를 대기한다.

상술된 것과 같은 마이크로프로세서 시스템(10)에서, 각 CPU 모듈(12) 상의 각 버스 제어기(32)는 각 마이크로프로세서(24)에 의해 요구되는 각 어드레스를 가지는 상기 상태표의 상태를 통해 일정하게 이동하고 있다. CPU 모듈(12)과 시스템 버스(18) 및 I/O 버스(20)와의 상호작용은 다음과 같이 제5(a)도-제5(b)도를 참조하여 설명된다.

제5(a)도-제5(b)도는 본 발명의 I/O 버스 프로토콜을 포함하는 마이크로프로세서 시스템의 I/O 사이클의 타이밍 다이어그램을 나타내고, 여기에서 제2 프로세서는 I/O 제어기(16)가 I/O 버스(20)의 제어를 요구한 후에 I/O 버스에의 액세스가 방지된다. 제1 마이크로프로세서(CPU 1), 제2 마이크로프로세서(CPU 2), 및 제2 마이크로프로세서(CPU 3)는 각각 제4도의 상태표의 상태 S1에 대응하는, 각 버스 제어기(32)에의 CADS 신호(도시 생략)을 개시한다. 동시에, 각 마이크로 프로세서 (24)는 요구된 어드레스를 버스 수신기(30)에 송신한다. 요구된 어드레스는 또한 어드레스 및 사이클 타입 디코더(26)로 보내지고, 이 디코더는 요구된 어드레스가 I/O 액세스를 요구하는지의 여부를 판정하고, 만약 요구했으면 IOBUS_ACCESS 신호(도시 생략)를 개시한다. CPU 모듈 #1의 경우,IOBUS_ACCESS 신호는 판명되지 않는다. 각 버스 제어기(32)는 라인(72) 상의 버스 요구(SBREQx-) 신호를 송출한다. 각 버스 제어기(32)는 중앙 조정자(60)로부터 활동 레벨에서 라인(82) 상의 ABUSAVL 신호뿐만 아니라 라인(74) 상의 시스템 버스 확인(SBACKx-) 신호의 수신을 대기하는데, 이는 상태표의 상태 S1에 대응한다.

제5(a)도는 개시된 각 CPU 모듈(12)의 버스 요구; 즉 라인(90) 상의 SBREQ1 신호, 라인(92) 상의 SBREQ2 신호, 라인(94) 상의 SBREQ3 신호로, 클럭 사이클 1에서 시작한다. 클럭 사이클 1에서, CPU 모듈 #1은 활동 상태에서 SBACK1 신호를 수신하고, CPU 모듈 #2 및 CPU 모듈#3상의 버스 제어기(32)는 각각 이들의 시스템 버스 확인(SBACKx-) 신호, SBACK2- 및 SBACK3-를 대기하고 있다. CPU 모듈 #1의 상태표의 상태 S2에 대응하는 클럭 사이클 1에서, CPU 모듈 #1의 버스 제어기(32)는 비활동 레벨에서 라인(86) 상의 SBUSBSY 신호의 수신을 대기한다.

제5(a)도의 클럭 사이클 2에서 설명하고 있는 바와 같이, CPU 모듈 #1의 버스 제어기(32)가 비활동 레벨에서 라인(86) 상의 SBUSBSY 신호를 수신하고, 버스 제어기(32)가 활동 레벨에서 라인(96) 상의 SADDS 신호를 발한다. 이것은 상태표의 상태 S2에서 상태 S4로의 전이시에 발생하게 된다. 또한, 클럭 사이클 2동안, CPU 모듈#1로부터의 시스템 어드레스가 SADDRxx 라인(98)을 거쳐 시스템 버스(18)에 나타나게 된다. 이 어드레스는 클럭 사이클 2-5로부터 유효하다. 요구된 어드레스를 래치하는 시스템 버스(18) 상의 어드레스는 라인(96) 상의 SADDS 신호의 수신에 응답하여 행한다.

클럭 사이클 3에서, CPU 모듈 #1은, CPU 모듈 #1이 어드레스를 시스템 버스(18)상에 이미 배치하고 있기 때문에 라인(90) 상의 시스템 버스 요구 신호 SBREQ1-을 해제한다. 동시에, 라인(88) 상의 TRNSHLD 신호는 시스템 버스에 접속된 각 디바이스에 의해 활동 레벨로 구동되는 동안 각 디바이스는 요구된 데이타를 가지고 있는지의 여부(즉, 어드레스가 디바이스가 응답하는 어드레스에 대응하는지의 여부)를 결정한다. 각 디바이스가 요구된 어드레스에 응답하지 않은 것으로 판정하면, 라인(98) 상의 TRNSHLD 신호를 해제한다. 이것은 상태표의 상태 S5에 해당한다. 라인(96) 상의 SADDS 신호는 라인(96) 상의 어드레스 SADDRxx가 시스템 버스(10)에 나타나고 있기 때문에 표명 해제된다. 또한, 클럭 사이클 3에서,I/O 제어기(16)중 하나는 라인(76)상에 I/O버스 요구 신호,IOBUS REQ-를 표명함으로써 I/O 버스(20)에의 액세스를 요구한다.

클럭 사이클 4에서, 라인(100)상의 SBACK1 신호가 표명 해제되어, 라인(90) 상의 SBREQ1 신호의 표명 해체를 확인한다. 시스템 버스(18)가 라인(100) 상의 SBACK1 신호의 해제 이후 CPU 모듈#1로 더 이상 허용되지 않기 때문에, 중앙 조정자(60)는 다음 CPU 모듈(12)의 요구를 확인한다. 이 경우에, 중앙 조정자(60)는 라인(102) 상의 SBACK2 신호를 개시하여 시스템 버스(18)를 CPU 모듈 #2로 허용한다. 라인(76) 상의 IOBUS_REQ 신호의 개시에 응답하여, 중앙 조정자(60)는 다른 CPU 모듈(12)이 I/O 버스(18)을 액세스하려 하지 않도록 활동 레벨에서 IOBUS_BSY 신호(52)를 개시한다.

클럭 사이클 5에서, 시스템 버스상의 마지막 디바이스는 라인(88) 상의 TRNSHLD 신호를 해제한다. 이것은 CPU 모듈 #1로부터의 라인(98) 상의 어드레스 SADDRxx가 시스템 버스(18)상에서 유효하며 상태표의 상태 S5에서 상태 S0으로의 전이에 해당하는 마지막 사이클이다.

클럭 사이클 6에서, 라인(82) 상의 ABUSAVL 신호는, CPU 모듈#1로부터의 어드레스 요구가 더이상 유효하지 않기 때문에, 활동 레벨로 복귀된다. 버스 브릿지(22)상의 중앙 조정자(60)는 라인(78) 상의 IOBUS_ACK 신호에 응답하고, 이 신호는 요구중인 I/O 제어기(16)에게 I/O 버스(20)를 허용한 것을 나타낸다. 더욱이, I/O 제어기(16)는 I/O 버스(20)의 데이타 라인 세트(IO_DATA)(104)상에 유효 데이타를 배치한다. 라인(104) 상의 데이타 신호는 클럭 사이클 6에서부터 클럭 사이클 14동안 유효하다.

활동 레벨에서 라인(82) 상의 ABUSAVL 신호의 수신과, 활동 레벨에서 라인(102)상의 SBACK2 신호의 이전 수신으로, CPU 모듈 #2는 클럭 사이클 7에서 버스 제어기 타이밍 다이어그램의 상태 S2로 이동한다. CPU 모듈 #2는 이미 요구된 어드레스를 버스 수신기(30)와 어드레스 및 사이클 타입 디코더(36)에 보냈다. 어드레스 및 사이클 타입 디코더(36)은 요구된 어드레스가 I/O액세스를 필요로 하는지는 판정하고, 만약 필요로 하면 IOBUS_ACCESS 신호(도시 생략)을 개시한다. CPU모듈 #2의 경우, 어드레스 요구는 I/O 버스(20)에의 액세스를 필요로 한다. 따라서,IOBUS_ACCESS 신호는 활동 레벨에서 표명된다.

클럭 사이클 7에서, 라인(106) 상의 사이클 종료 (CTERM-) 신호는 데이타가 유효 가능한 것을 나타내는, 유효 데이타를 가지는 디바이스에 의해 표명된다. 유효 데이타는 시스템 버스(18)의 데이타 라인 세트 SMD[63:00](108)상에 나타난다. 유효 데이타는 각 클럭 사이클 8-11의 선행 구간에서 시스템 버스(18)로부터 CPU 모듈 #1에 의해 수신된다. 또한, 클럭 사이클 7에서, CPU 모듈 #2은 시스템 버스(18)상에 요구된 어드레스를 배치한다. 그러나, 라인(52) 상의 IOBUS_BSY 신호가 활동이기 때문에, 라인(96) 상의 SADDS 신호는 개시되지 않는다. 라인(96) 상의 SADDS 신호의 개시 없이, CPU 모듈 #2의 어드레스는 시스템 버스(18)상에서 어떤 디바이스에 의해서도 래치되지 않는다.

클럭 사이클 8에서, CPU 모듈 #2에 의해 활동 레벨에서 IOBUS_BSY 신호의 수신으로 인해, CPU 모듈 #2상의 버스 제어기(32)는 상태 S3에 들어가 현재 I/O 트랜잭션이 완성된 것을 나타내는, 비활동 레벨에서의 IOBUS_BSY 신호의 수신을 대기한다. 부가하여, CPU모듈 #2는 라인(92) 상의 버스 요구 SBREQ2-를 표명 해제하여 I/O 버스(20)가 유효 가능하게 되기를 대기하면서 다른 CPU 모듈(12)이 시스템 버스(18)을 액세스하게 한다.

클럭 사이클 9에서, 중앙 조정자(60)는 라인(102) 상의 SBACK2 신호를 표명 해제하여, 라인(92) 상의 SBREQ2 신호의 표명 해제를 확인한다. 시스템 버스(18)가 SBACK2 신호의 해제 이후에 CPU 모듈 #2로 더 이상 허용되지 않기 때문에, 중앙 조정자(60)는 다음 CPU 모듈(12)의 요구를 확인한다. 이 경우 중앙 조정자(60)는 라인(110) 상의 SBACK3 신호를 개시하여 시스템 버스(18)를 CPU 모듈#3로 허용시킨다.

클럭 사이클 10에서, 시스템 버스(18)에 데이타를 전송하는 디바이스는 라인(112) 상의 트랜잭션 (SEOT-) 신호의 시스템 단부를 저 논리 레벨로 스트로브한다. 클럭사이클 11에서, CPU 모듈 #1은 데이타 전송을 허용하여 라인(106) 상의 CTERM 신호는 고 논리 레벨로 복귀된다. 라인(106) 상의 CTERM 신호가 일단 고 논리 레벨로 복귀되고 라인(112) 상의 SEOT 신호가 저 논리 레벨로 스트로브되면, 라인(86)상의 SBUSBSY 신호는 시스템 버스(18) 상의 사이클이 완료되었기 때문에 비활동 레벨로 설정된다. 또한, 클럭 사이클 11에서, CPU 모듈 #3은 유효 어드레스 SADDRxx를 시스템 어드레스 버스 어드레스 라인(98)에 배치한다. 라인(98) 상의 어드레스는 클럭 사이클(11-15)동안 유효하다.

미리, CPU 모듈 #3은 CPU 모듈 #3상의 어드레스 및 사이클 타입 디코더(36)에서 마이크로프로세서 요구 어드레스를 수신한다. 어드레스 및 사이클 타입 디코더(36)은 요구된 어드레스가 I/O액세스를 필요로 하는지의 여부를 판정하고, 만약 필요로 한다면 IOBUS_ACCESS 신호(도시 생략)을 개시한다. CPU 모듈 #3의 경우, IOBUS_ACCESS 신호는 I/O 액세스를 필요로 하지 않기 때문에 비활동 레벨로 설정된다. CPU 모듈 #3상의 버스 제어기(32)는 이미 활동 레벨에서 라인(82) 상의 ABUSAVL 신호뿐만 아니라 라인(110) 상의 시스템 버스 확인(SBACK3-) 신호를 수신하였고, 이에 따라 상태표의 상태 S2에 있게 된다. 비활동 레벨에서 라인(86)상의 SBUSBSY 신호의 수신으로, CPU #3은 제5(b)도에서 도시되고 있는 바와 같이, 클럭 사이클 12에서 라인(96) 상의 SADDS 신호를 표명한다. 이것은 상태표의 상태 S2에서 상태 S4로의 전이시에 발생한다. 어드레스를 래치하는 시스템 버스(18)상의 디바이스는 라인(96) 상의 SADDS 신호의 수신에 응답하여 행한다. 라인(96)상의 SADDS 신호의 표명으로, 시스템 어드레스 버스는 더 이상 유효 가능하지 않게 되고, 이에 따라 라인(82) 상의 ABUSAVL 어드레스는 비활동 레벨로 구동된다.

마지막으로, 라인(86) 상의 SBUSBSY 신호가 표명되어, 시스템 버스(18)가 CPU 모듈 #3의 요구된 동작으로 비지 상태인 것을 나타낸다. 또한, 클럭 사이클 12에서, 라인(96) 상의 SADDS 신호의 발생 이후에, CPU 모듈 #3은, CPU 모듈 #3이 요구된 어드레스를 이미 시스템 버스(18)상에 배치했기 때문에 라인(94) 상의 시스템 버스 요구 라인 SBREQ3-를 해제하고, 이에 따라 시스템 버스(18)의 사용을 허용한다.

클럭 사이클 13에서, 라인(88) 상의 TRNSHLD 신호는 시스템 버스(10)에 접속된 각 디바이스에 의해 활동 레벨로 구동되는 동안 각 디바이스는 요구된 데이타를 가지고 있는지의 여부를 판정한다. 각 디바이스가 요구된 어드레스에 응답하지 않았다고 판정하면, TRNSHLD 신호를 해제한다. 이것은 상태표의 상태 S5에 해당한다. 라인(96) 상의 SADDS 신호는 어드레스가 시스템 버스(18)에 나타나 있기 때문에 표명 해제된다. 클럭 사이클 14에서, 마지막 유효 데이타가 I/O 제어기(16)으로부터 I/O 버스(20)으로 전달된다.

클럭 사이클(15)에서,I/O제어기(16)는, 그 사이클이 완료되었기 때문에 그 버스 요구, IOBUS_REQ-, 라인(76) 상의 신호를 표명 해제하여 다른 디바이스가 I/O 버스(20)을 액세스 가능하게 한다. 부가하여, 시스템 버스(18) 상의 마지막 디바이스는 CPU 모듈 #3으로부터의 요구에 응답하여, 라인(88) 상의 TRNSHLD 신호를 해제한다. TRNSHLD 신호의 해제는 상태표의 상태 S5로부터 상태 S0으로의 이전에 헤딩한다. 상태 S0에서, CPU 모듈 #3의 버스 제어기(22)는 그 마이크로프로세서(24)로부터의 다음 어드레스 요구를 대기한다.

클럭 사이클 16에서, 라인(81) 상의 IOBUS_ACK 신호는 라인(76) 상의 IOBUS_REQ 신호의 표명 해제를 확인한다. I/O 버스(20)가 더 이상 사용중이 아니기 때문에, 라인(52) 상의 IOBUS_BSY 신호는 비활동 상태로 복귀된다. 라인(52)상의 IOBUS_BSY 신호의 표명 해제로, CPU 모듈 #2의 버스 제어기(32)는 상태표의 상태 S1으로 복귀되며, 현재 유효 가능한 I/O버스(20)을 다시 한번 액세스하려고 시도한다. CPU 모듈 #3으로부터의 시스템 버스(18) 상의 어드레스 요구가 더 이상 유효하지 않기 때문에, 어드레스 버스는 부가의 트랜잭션에 대해 유효 가능하게 된다. 따라서, 클럭 사이클 16에서, 라인(82) 상의 ABUSAVL 신호가 표명 해제된다.

클럭 사이클 17에서, CPU #2는 라인(92) 상의 SBREQ2 신호를 개시하여 시스템 버스(16)에의 액세스를 다시 요구한다. 부가하여, 라인(106) 상의 사이클 종료 (CTERM-) 신호는 데이타가 유효 가능한지를 나타내는, 유효 데이타를 가지는 시스템 버스(18) 상의 디바이스에 의해 표명된다. 유효 데이타는 시스템 버스 데이타 라인 SMD[63:00](108)에 나타난다. 유효 데이타는 각 클럭 사이클(18-21)의 선행 구간에서 시스템 버스(18)로부터 CPU 모듈 #3에 의해 수신된다.

클럭 사이클 18에서, 라인(110) 상의 SBACK3 신호가 표명 해제되어, 라인(94) 상의 SBREQ3 신호의 표명 해제를 확인한다. 시스템 버스(18)가 라인(110) 상의 SBACK3 신호의 해제 이후에 CPU 모듈 #3에 더 이상 고정되어 있지 않기 때문에, 중앙 조정자(60)는 다음 CPU 모듈(12)의 요구를 확인한다. 이 경우, 중앙 조정자(60)는 라인(102) 상의 SBACK2 신호를 개시하여, CPU 모듈 #2를 확인한다.

활동 레벨에서 라인(82) 상의 ABUSAVL 신호의 수신과 활동 레벨에서 라인(102)상의 SBACK2 신호의 이전 수신으로, CPU 모듈 #2는 클럭 사이클 19에서 버스 제어기 상태표의 상태 S2로 이동한다. 상술한 바와 같이, CPU 모듈 #2에 의해 요구된 어드레스가 I/O 버스(20)에의 액세스를 필요로 하기 때문에, CPU 모듈 #2상의 IOBUS_ACCESS 신호는 활동 레벨로 설정된다(도시 생략).

클럭 사이클 20에서, CPU AHEBF #2은 그 어드레스 SADDRXX를 라인(98) 상의 시스템 어드레스 버스상으로 배치한다. 그러나, 라인(96) 상의 SBUSBSY 신호가 여전히 활동이기 때문에, 라인(96) 상의 SADDS 신호는 개시되지 않는다. 라인(96) 상의 SADDS 신호의 개시 없이, CPU 모듈 #2의 어드레스는 시스템 버스(18) 상의 어떤 디바이스에 의해서도 래치되지 않는다. 부가하여, 클럭 사이클 20에서, CPU 모듈 #2 요구에 응답하여 시스템 버스(18)에 데이타를 전송하는 디바이스는 라인(112) 상의 트랜잭션 (SEOT-)의 시스템 단부를 저 논리 레벨로 스트로브한다.

클럭 사이클 21에서, CPU 모듈 #3이 데이타 전송을 수용하여 라인(106) 상의 CTERM 신호는 고 논리 레벨로 복귀된다. 라인(106) 상의 CTERM 신호가 일단 고 레벨로 복귀되고 라인(112) 상의 SEOT 신호가 저 논리 레벨로 스트로브되면, 라인 (86) 상의 SBUSBSY 신호는 시스템 버스(18) 상의 사이클이 완료되었기 때문에 비활동 레벨로 복귀된다.

비활동 레벨에서 라인(86) 상의 SBUSBSY 신호의 수신으로, CPU 모듈 #3은 클럭 사이클 22에서 라인(96) 상의 SADDS 신호를 표명한다. 이것은 상태표의 상태 S2로부터 상태 S4로의 전이시에 발생한다. 어드레스를 래치하는 시스템 버스(18) 상의 디바이스는 라인(96) 상의 SADDS 신호의 수신에 응답하여 행한다. SADDS 신호의 표명으로, 시스템 어드레스는 다른 CPU 모듈(12)에 의한 액세스에 더 이상 유효 가능하지 않다. 따라서 라인(82) 상의 ABUSAVL 신호가 비활동 레벨로 구동된다. 마지막으로, 라인(86) 상의 SBUSBSY 신호가 표명되어, 시스템 버스가 CPU 모듈 #2의 요구 동작으로 비지 상태인 것을 나타낸다. I/O 사이클중 잔여부는 상술한 방법으로 완료된다.

제5(a)도-제5(b)도를 참조하여 상술한 바와 같이, 라인(52) 상의 IOBUS_BSY 신호는 라인(76) 상의 IOBUS_REQ 신호의 개시에 이은 클럭 사이클 동안 개시된다. 그러나, 라인(78) 상의 IOBUS_ACK 신호는 라인(52) 상의 IOBUS_BSY 신호와 동시에 개시되지 않아 CPU 모듈(12)중 하나와 I/O 제어기(16)중 하나에 의해 I/O 버스(20)의 동시 액세스와 관련되는 문제를 방지할 수 있다. CPU 모듈(12)은 라인(52) 상의 IOBUS_BSY 신호를 수신하지 않는 한 I/O 어드레스를 요구할 수 있다. 따라서 CPU 모듈(12)이 I/O 버스(20)를 요구하고 있는 것과 동시에 I/O 제어기(16)가 I/O 버스(20)를 요구하게 하는 것이 가능하다. CPU 모듈(12)이 라인(52) 상의 IOBUS_BSY 신호를 수신하기 전에 버스 프로토콜 회로(64)에 의해 라인(52) 상의 IOBUS_BSY 신호가 발생한 후 일 클럭 사이클이 걸리기 때문에, 중앙 조정자(60)는 동시의 CPU 모듈 액세스가 발생하는지를 체크하기 위해서 I/O버스(18)를 I/O 제어기(16)에 허용하기 전에 적어도 일 사이클을 대기할 필요가 있다.

제5(a)도-제5(b)도에서 나타낸 바람직한 실시예에서, IOBUS_REQ 신호가 수신된 이후, IOBUS_ACK 신호가 IOBUS_BSY 신호의 표명 후 두 클럭 사이클 이후에 개시된다. 두 클럭 주기는,IOBUS_BSY 신호가 I/O 제어기(16) 요구에 응답하여 개시된 것과 동시에 CPU 모듈(12)중 하나가 I/O 버스(20) 상의 어드레스를 요구했는지의 여부를 결정하는 데에 충분한다. 두 클럭 주기 이후에, CPU 모듈(12)은 라인(52) 상의 IOBUS_BSY 신호를 확실하게 수신하며 라인(52) 상의 IOBUS_BSY 신호가 표명 해제될 때 까지 I/O 버스 액세스를 더 이상 요구하지 않는다. 동시 액세스가 검출된 경우에, CPU 모듈의 요구 종료로 에러 상태가 마이크로프로세서(24)에 의해 검출되기 때문에, CPU 모듈(12)은 I/O 버스(20)의 사용이 허용된다. CPU 모듈(12)에 I/O버스(20)가 허용되기 때문에, 요구중인 I/O 제어기(16)는 CPU 모듈의 사이클이 완료될 때 까지 IOBUS_ACK 신호를 수신하지 않는다.

제6(a)도-제6(b)도는 라인(52) 상의 IOBUS_BSY 신호가 I/O 제어기(16)로부터의 IOBUS_REQ-에 응답하여 개시된 것과 동시에 CPU 모듈 #2이 I/O 버스(20)의 액세스를 요구하는 경우를 나타내고 있다.

클럭 사이클 1에서, 각 CPU 모듈(12)의 버스 요구는 개시되고 (즉, 라인 (90, 92, 94)상의 SBREQ1, SBREQ2-, 및 SBTEQ3 신호가 각각 개시됨), CPU 모듈 #1은 활동 상태에서 라인(100) 상의 SBACK1 신호를 수신한다. CPU 모듈 #2과 CPU 모듈 #3상의 버스 제어기(32)는 각각 이들의 시스템 버스 확인 신호, 즉 라인(102) 상의 SBACK2-, 라인(110) 상의 SBACK3-의 수신을 대기한다. CPU 모듈 #1에서 상태 표의 상태 S2에 대응하는 클럭 사이클 1에서, 라인(86) 상의 SBUSBSY 신호는 비활동 레벨에 있고 라인(82) 상의 ABUSAVL 신호는 활동 레벨에 있다.

클럭 사이클 2에서, CPU 모듈 #1로부터의 시스템 어드레스는 SADDRxx 라인(98)를 거쳐 시스템 버스(18)에 나타나게 된다. 어드레스는 클럭 사이클 2-5동안 유효하다. 또한, 클럭 사이클 2동안, SBUSBSY 신호가 비활동이고 ABUSAVL 신호가 활동이기 때문에, CPU 모듈 #1상의 버스 제어기(32)는 활동 레벨에서 라인(96') 상의 SADDS 신호를 발한다. 이것은 상태표의 상태 S2로부터 상태 S4로의 전이시에 발생한다. 어드레스를 래치하는 시스템 버스(18) 상의 디바이스는 라인(96) 상의 SADDS 신호의 수신에 응답하여 행한다.

클럭 사이클(3)에서, CPU 모듈 #1은, 이미 그 어드레스를 시스템 버스(18)상에 배치했기 때문에 시스템 버스 요구 라인, 라인(90) 상의 SBREQ1을 해제하고, 이에 따라 시스템 버스(18)의 사용을 허용한다. 동시에, 라인(88) 상의 TRNSHLD 신호는 시스템 버스(18)에 접속된 각 디바이스에 의해 활동 레벨로 구동되는 동안 각 디바이스는 요구된 데이타를 가지고 있는지의 여부를 결정한다. 각 디바이스가 요구된 어드레스에 응답하지 않았다고 결정하게 되면, TRNSHLD 신호를 해제한다. 라인(88)상의 TRNSHLD 신호의 표명은 상태표의 상태 S5에 해당한다. 부가하여, 라인(96)상의 SADDS 신호는, 어드레스가 시스템 버스(18)에 나타나기 때문에 표명 해제된다.

클럭 사이클 4에서, 라인(100) 상의 SBACK1신호는 표명 해제되어, 라인(90) 상의 SBREQ1 신호의 표명 해제를 확인한다. 시스템 버스(10)가 SBACK1 신호의 해제 이후에 CPU 모듈 #1로 더 이상 허용되지 않기 때문에, 중앙 조정자(60)는 다음 CPU 모듈(12)의 요구를 확인한다. 이 경우, 중앙 조정자(60)는 시스템 버스(18)를 CPU 모듈 #2로 허용하기 위해 라인(102) 상의 SBACK2 신호를 개시한다.

클럭 사이클 5에서, 시스템 버스(18) 상의 마지막 디바이스는 라인(88) 상의 TRNSHLD 신호를 해제한다. 이것은 CPU 모듈 #1로부터의 요구된 어드레스가 시스템 버스(18)상에서 유효하며 상태표의 상태 S5로부터 상태 S0으로의 전이에 해당하는 마지막 사이클이다. 이 지점에서, CPU 모듈 #1은 마이크로프로세서(24)로부터의 다음 어드레스 요구를 대기하는 상태 S0로 유지된다.

클럭 사이클 6에서, 라인(82) 상의 ABUSAVL 신호는, CPU 모듈 #1로부터의 어드레스 요구가 더 이상 유효하지 않기 때문에 활동 레벨로 복귀된다. 활동 레벨에서 라인(82) 상의 ABUSAVL 신호의 수신과 활동 레벨에서 라인(102) 상의 SBACK2 신호의 이전 수신으로, CPU 모듈 #2는 클럭 사이클 7에서 버스 제어기 타이밍 다이어그램의 상태 S2로 이동한다. CPU 모듈 #2은 이미 버스 수신기(30) 및 어드레스 및 사이클 타입 디코더(36)에서 마이크로프로세서의 요구 어드레스를 수신했다. 어드레스 및 사이클 타입 디코더(36)은 CPU 요구 어드레스가 I/O 액세스를 필요로 하는지의 여부를 결정하고, 만약 필요하면 IOBUS_ACCESS 신호를 개시한다(도시 생략). CPU 모듈 #2의 경우, 어드레스 요구는 I/O 버스의 액세스를 필요로 하고, 이에 의해 IOBUS_ACCESS 신호는 활동 레벨에서 표명된다(도시 생략).

클럭 사이클 7에서, 사이클이 종료하고, 라인(106) 상의 CTERM 신호는 데이타가 유효 가능한 것을 나타내는 CPU 모듈 #1에 의해 요구된 데이타를 가지는 장치에 의해 표명된다. 유효 데이타는 데이타 라인 SMD[63:00](108)상에서 시스템 버스(18)에 나타난다. 유효 데이타는 각 클럭 사이클(8-11)의 선행 구간에서 시스템 버스(18)로부터 CPU 모듈 #1에 의해 수신된다.

클럭 사이클(9)에서 CPU 모듈 #2는 시스템 버스(18)의 어드레스 라인(98) 상에 그 어드레스 SADDRxx를 위치시킨다. 그러나, 라인(86) 상의 SBUSBSY-신호가 활동 레벨에 있으므로 라인(96) 상의 SADDS-신호는 시작되지 않는다. 라인(96) 상의 SADDS-신호의 개시없이 CPU 모듈 #2의 어드레스는 시스템 버스(18) 상의 디바이스의 어떤 것에 의해서도 래치되지 않는다. 클럭 사이클(10)에서 데이타를 CPU 모듈 #1으로 전송하는 디바이스는 라인(112) 상의 트랜잭션(SEOT-) 신호의 시스템 엔드를 활동 레벨로 스트로브한다.

클럭 사이클(11)에서 CPU 모듈 #1은 디바이스로부터의 데이타 전송을 받아들이고 라인(106) 상의 CTERM-신호는 비활동 레벨로 복귀한다. 일단 라인(106) 상의 CTERM-신호가 비활동으로 복귀하고 라인(112) 상의 SEOT-신호가 활동 레벨로 스트로브되면, 시스템 버스(18) 상의 사이클이 완료되므로 라인(86) 상의 SBUSBSY-신호는 비활동 레벨로 복귀한다. 또, 클럭 사이클(11)에서 I/O 제어기(16) 중의 하나가 I/O 버스 요구 신호 IOBUS_REQ-를 라인(76) 상에 어서트함으로써 I/O 버스(20)에 대해 액세스를 요구한다.

클럭 사이클(12)에서 라인(76) 상의 IOBUS_REQ- 신호의 개시에 응답하여 I/O 버스 프로토콜 회로(64)는 다른 CPU 모듈(12)이 I/O 버스(20)에 대한 액세스를 시도하는 것을 방지하기 위하여 활동 레벨에서 라인(52)을 통해 IOBUS_BSY-신호를 개시한다. 그러나, 비활동 레벨에서 라인(86)을 통해 SBUSBSY-신호를 수신함으로써 CPU 모듈 #2은 또 클럭 사이클(12)에서 라인(96) 상에 SADDS-신호를 어서트한다. 이것은 상태표의 상태 S2에서 상태 S4로의 전이에서 일어난다.

상술한 바와 같이, 라인(52) 상의 IOBUS_BSY-신호가 I/O 제어기(16)로부터의 요구에 따라 개시되는 것과 동시에 I/O 요구에 의해 라인(96) 상의 SADDS-신호를 CPU 모듈(12) 중의 하나가 개시하는 경우에, 요구하는 CPU 모듈(12)은 I/O 버스(20)를 허여받는다. I/O 제어기(16)는 라인(78) 상의 IOBUS_ACK-신호를 수신하기 전에 CPU 모듈의 사이클을 완료시키기 위해 기다려야 한다. CPU 모듈 #2가 I/O 버스(20)를 허여받으므로 라인(52) 상의 IOBUS_BSY-신호는 CPU 모듈 #2의 I/O 사이클의 나머지 기간 동안 어서트된 채로 남는다. 라인(96) 상의 SADDS-신호의 어서션으로 인해 시스템 어드레스 버스는 더 이상 이용 가능하지 않다. 따라서, 라인(82) 상의 ABUSAVL 신호는 비활동 레벨로 구동된다. 마지막으로, 라인(86) 상의 SBUSBSY-신호는 시스템 버스(18)가 CPU 모듈 #2의 요구로 비지를 나타내도록 어서트된다.

클럭 사이클(13)에서 라인(96) 상에 SADDS-신호를 내보낸 후, CPU 모듈 #2는 CPU 모듈 #2가 이미 시스템 버스(18) 상에 요구된 어드레스를 위치시키기 때문에 라인(92) 상의 시스템 버스 요구 신호 SBREQ2-를 해제한 후 시스템 버스(18)의 사용을 허여받는다. 또, 클럭 사이클(13)에서 라인(88) 상의 TRNSHLD-신호는 시스템 버스에 접속된 각 디바이스에 의해 활동 레벨로 구동된다. 이 때 각 디바이스는 자신이 요구된 데이타를 갖고 있는지를 결정한다. 각 디바이스는 자신이 요구된 어드레스에 응답하지 않는지를 결정할 때 TRNSHLD-신호를 해제한다. 이것은 상태표의 상태(S5)에 상응한다. 마지막으로, 라인(96) 상의 SADDS-신호는 어드레스가 시스템 버스(18)에 존재하므로 디어서트된다.

클럭 사이클(14)에서 센트럴 아비터(60)는 라인(92) 상에 SBREQ2-신호의 디어서션을 인식하여 라인(102) 상에 SBACK2-신호를 디어서트한다. 시스템 버스(18)가 라인(102) 상의 SBACK2- 신호의 해제 후 더 이상 CPU 모듈 #2에 허여되지 않으므로 센트럴 아비터(60)는 다음 CPU 모듈(12)의 요구를 인식한다. 이 경우에 센트럴 아비터(60)는 CPU 모듈 #3의 요구를 인식하여 라인(110)을 통해 SBACK3- 신호를 개시한다.

클럭 사이클(15)에서 시스템 버스(18) 상의 마지막 디바이스는 라인(88) 상의 TRNSHLD-신호를 해제한다. 이것은 상태표의 상태(S5)에서 상태(S0)로의 전이에 상응한다. 이 시점에서 CPU 모듈 #2 상의 버스 제어기(32)는 마이크로프로세서(24)가 새로운 어드레스를 요구할 때까지 상태(S0)에 남아 있다. 클럭 사이클(16)에서 시스템 버스(18)를 통해 CPU 모듈 #2로부터의 어드레스 요구가 더 이상 유효하지 않으므로 어드레스 버스는 부가의 트랜잭션의 이용 가능하고, 따라서 라인(82)상의 ABUSAVL 신호가 어서트된다. 이것은 CPU 모듈 #3에 대해 상태표의 상태(S2)에 상응한다.

클럭 사이클(18)에서 CPU 모듈 #3은 그 어드레스를 시스템 버스(18) 상에 내놓는다. 그러나, 라인(86) 상의 SBUSBSY- 신호가 여전히 활동적이므로 라인(96) 상의 SADDS-신호는 개시되지 않는다. 라인(96) 상의 SADDS- 신호의 개시 없이 CPU 모듈 #3의 어드레스는 시스템 버스 상의 디바이스의 어떤 것에 의해서도 래치되지 않는다.

클럭 사이클(19)에서 라인(106) 상의 사이클 종료(CTERM-) 신호는 버스 브릿지를 통해 제어논리(63)에 의해 어서트된다. 게다가, 버스 브릿지(22) 상의 제어 논리(63)는 라인(112) 상의 트랜잭션(SEOT-) 신호의 시스템 엔드를 로우로 스트로브한다. I/O 버스(20)로부터의 유효 데이타는 버스 브릿지(22)를 통해 버스 버퍼(62)에 의해 시스템 버스 데이타 라인 SMD[63:00]에 존재한다.

I/O 버스 브릿지(22) 상의 버퍼(62)는 I/O 버스(20)의 저속 데이타 비율로 I/O 버스(20)로부터 데이타를 이미 수신하여 이 데이타를 임시로 저장했다. 클럭 사이클(19)에서 모든 데이타가 버퍼(62)에 저장되면, 버스 브릿지(22)는 시스템 버스(18)의 고속 데이타 속도로 한 클럭 사이클에 버퍼(62)로부터의 데이타를 시스템 버스(18)상으로 버스트한다. 유효 데이타는 클럭 사이클(20)의 선단 엣지에서 시스템 버스(18)로부터 CPU 모듈 #2에 의해 수신된다.

클럭 사이클(20)에서 CPU 모듈 #2는 데이타 전송을 수신하고 라인(106) 상의 CTERM- 신호는 하이 레벨로 복귀한다. 일단 라인(106) 상의 CTERM- 신호가 하이로 복귀되고 라인(112) 상의 SEOT- 신호가 로우로 스트로브되면, 시스템 버스(18) 상의 사이클이 완료되므로 라인(86) 상의 SBUSBSY- 신호는 하이로 복귀한다. 유효 데이타가 I/O 버스(20)로부터 버스 버퍼(62)로 전송되고 시스템 버스(18)로 전송된 후 CPU 모듈 #2의 I/O 버스 트랜잭션은 완료되었다. 센트럴 아비트레이터(60)는 라인(78) 상의 IOBUS_ACK- 신호로 하여금 I/O 제어기(16)가 I/O 버스(20)의 제어를 수신하는 것을 가능하게 함을 나타낸다. 라인(52) 상의 IOBUS_BSY- 신호는 I/O 제어기(16)가 그 트랜잭션을 완료하는 동안 활동상태이다.

클럭 사이클(21)에서 CPU 모듈 #3은 비지 I/O 버스(201)가 아니라 시스템 메모리에 대한 액세스를 시도하기 때문에 그 어드레스 요구와 더불어 진행된다. 비활동 레벨에서 라인(86) 상의 SBUSBSY- 신호의 수신으로 인해 CPU 모듈 #3은 라인(96)상에 SADDS- 신호를 어서트한다. 이것은 상태표의 상태(S2)에서 상태(S4)로의 전이에서 일어난다. 라인(96) 상의 SADDS- 신호의 어서션으로 시스템 어드레스 버스는 더 이상 이용 가능하지 않다. 따라서, 라인(82) 상의 ABUSAVL 신호는 비활동 레벨로 구동된다. 마지막으로, 라인(86) 상의 SBUSBSY- 신호는 시스템 버스(18)가 CPU 모듈 #3의 요구된 연산에 의해 비지가 됨을 표시하도록 어서트된다. CPU 모듈 #3의 시스템 버스 요구는 제6(a)도-제6(b)도의 CPU 모듈 #1과 관련하여 상술한 바와 같이 완료된다.

또, 클럭 사이클(21)에서 유효 데이타는 I/O 제어기(16)에 의한 사이클 요구에 응답하여 I/O 버스(18) 상에서 이용 가능하다. I/O 사이클의 나머지는 제5(a)도-제5(b)도와 관련하여 상술한 바와 같이 완료된다.

I/O 사이클이 완료된 후 라인(52) 상의 IOBUS_BSY- 신호는 디어서트(도시되지 않음)된다.

제7도는 센트럴 아비터(60)의 기능의 일부와 제어 논리(63)의 기능의 일부가 고집적 I/O 버스 인터페이스 제어기 회로(122)로 대체되는 버스 브릿지(120)의 다른 실시예를 도시한다. 고집적 I/O 버스 인터페이스 회로(122)는 인텔로부터 입수 가능한 부품 번호 82433LX, 82434LX, 82374EB, 및 82375EB의 4칩 세트와 같이 통상의 디자인에 속하는데, 이것은 시스템 버스(18)와 2개의 I/O 버스(즉, I/O 버스 #1(124) 및 I/O 버스 #2(126)) 사이를 인터페이스하기 위해 필요한 버스 제어 논리를 제공한다.

양호하게는, 버스 인터페이스 회로(122)는 EISA 타입 및 PCI 타입 I/O 버스 모두와 인터페이스할 수 있다. 버스 인터페이스 회로(122)가 멀티프로세서 시스템 (10)에 사용될 때, 각 CPU 모듈(12) 상의 I/O 버스 금지 회로(34)는 변경될 필요가 없다. 그러나, 버스 제어기 논리(32)는 후술하는 바와 같이 버스 제어기 논리의 다른 실시예(150)로 대체된다. 또, 시스템 버스(18)와 I/O 버스(124, 126) 사이를 인터페이스하는 신호는 약간 변경될 것이다.

버스 브릿지(120)의 다른 실시예는 양호하게는 고집적 I/O 버스 인터페이스 회로, 아비트레이션 논리 회로(128), 제어 논리(130) 및 타이머 회로(132)를 포함한다. 제어 논리 회로(130)는 양호하게는 더 상세히 후술되는 바와 같이 I/O 사이클의 타이밍을 제어하는 상태 기계를 포함한다. 양호하게는, 아비트레이션 논리 회로(128)는 시스템 버스(18)에 대한 액세스를 허여받을 경우에 CPU 모듈(12)의 각각에 대해 나타내도록 시스템 버스(18)로부터 라인(72) 상의 SBREQx- 신호들(즉, 라인(90) 상의 SBREQ1- 신호, 라인(92) 상의 SBREQ2- 신호 및 라인(94) 상의 SBREQ3- 신호)을 수신하고 라인(74) 상의 시스템 버스 인식 신호 SBACKx- (즉, 라인(100) 상의 SBACK1- 신호, 라인(102) 상의 SBACK2- 신호 및 라인(110) 상의 SBACK3- 신호)를 복원시킨다. I/O 버스(124,126)의 각각은 I/O 버스 요구를 처리하는 고집적 I/O 버스 인터페이스 회로(122)로 라인(133) 상의 I/O 요구 신호 IOREQx를 전송한다. 일단 요구되는 I/O 버스(124,126)가 액세스를 허용받으면, 고집적 I/O 버스 회로(122)는 비활동 상태에서 라인(134) 상의 I/O 버스 인식 신호 IOACKx를 복원시킨다. 또, 고집적 I/O 버스 회로(122)는 I/O 버스(124,126)의 동작을 제어하는 라인(135) 상의 다수의 제어 신호 IO_CONTROLx를 제어한다.

I/O 버스(124, 126) 중의 하나가 데이타를 시스템 버스(18)로 전송하기를 바란다면 고집적 I/O 버스 인터페이스 회로는 라인(137) 상의 IO_MP_REQ- 신호를 아비트레이션 논리(128)로 전송한다. 아비트레이션 논리(128)는 고집적 I/O 버스 회로(122)에 의해 수신된 라인(136) 상의 시스템 버스 인식 신호 SBUS_ACK-로 I/O 버스 요구에 응답한다. CPU 모듈(12) 중의 하나가 데이타를 I/O 버스(124, 126) 중의 하나로 전송하기를 바란다면, 고집적 I/O 버스 인터페이스 회로(122)는 라인(138)을 통해 제어 논리 회로(130)로부터의 MP_IQ_REQ- 신호를 수신한다. I/O 버스(124, 126)가 데이타를 시스템 버스(18)로부터 수신하는데 이용될 때, 고집적 I/O 버스 회로(122)는 활동 상태에서 라인(139) 상의 RDY- 신호를 제어 논리 회로(130)로 보낸다. I/O 버스(124, 126)가 하나의 트랜잭션으로 비지일 때, 고집적 I/O 버스 회로(122)는 활동 상태에서 라인(140) 상의 BACK_OFF- 신호를 제어 논리 회로(130)로보낸다.

제8도를 참조하면, 버스 인터페이스 회로(122) 상의 제어 논리 회로(130)에서의 상태 기계는 도시된 상태표와 관련하여 설명된다. 상태(S0)에서 시작하여 제어 논리 회로는 아이들 상태에 있고 활동 상태에서 라인(96) 상의 SADDS- 신호의 수신을 대기한다. 상술한 바와 같이 SADDS- 신호는 유효 어드레스 SADDRXX 신호를 시스템 버스(18)의 라인(98) 상에 놓은 후 CPU 모듈(12)에 의해 생성된다. 일단 유효 어드레스가 시스템 버스(18)에 존재하면, 버스 브릿지(120)는 어드레스를 수신하고 이를 어드레스 디코더(66)로 보낸다. 어드레스 디코더(66)는 요구된 어드레스가 I/O 버스(124, 126)의 각각에 대해 액세스를 필요로 하는지를 결정한다. 요구된 어드레스가 I/O 버스(124, 126) 중의 하나에 대한 액세스를 필요로 하면, 어드레스 디코더(66)는 라인(70) 상의 MP-2-IO-ACCESS 신호를 개시한다.

제어 논리 회로(130)의 상태 기계는 라인(96) 상의 SADDS- 신호가 활동 상태에서 수신되고 라인(70) 상의 MP-2-IO-ACCESS 신호가 활동 상태에서 수신된 후 상태(S1)로 나아갈 때까지 상태(S0)에 남아 있다. 상태(S1)에서 상태 기계는 라인(139)상의 버스-레디 신호(RDY-)를 모니터링함으로써 I/O 버스의 가용성을 검사한다. 또, 제어 논리(130)는 라인(140)을 통해 I/O 버스(124, 126)로부터의 백오프(BACK_OFF-) 신호의 상태를 검사한다. 활동시 라인(140) 상의 BACK_OFF-신호는 제어 논리(130)에 I/O 버스(124, 126)가 한 트랜잭션으로 현재 비지이므로 현 트랜잭션이 종료되어야 함을 알려준다. 라인(139) 상의 RDY- 신호도 라인(140)상의 BACK_OFF- 신호도 활성 상태가 아니면, 제어 논리(130)는 상태(S1)에 남아있다. 라인(139) 상의 RDY- 신호가 활성 상태에 있으면, 제어 논리(130)는 상태 기계의 상태(S2)로 나아간다. 라인(140) 상의 BACK_OFF- 신호가 활성 상태에 있으면, 제어 논리(130)는 상태 기계의 상태(S3)로 나아간다.

상태(S2)에서 제어 논리(130)는 유효 데이타의 마지막 부분이 전송되는 것을 표시하도록 시스템 버스(18)에 대한 I/O 버스(20)의 전송의 완료를 대기하고 그 전송의 완료에서 라인(112)을 통해 SEOT- 신호를 개시한다. 전송의 완료시 제어 논리(130)는 상태(S0)로 복귀해서 다음 I/O 버스 요구를 대기한다.

상태(S3)에서 제어 논리(130)는 요구된 I/O 버스(124,126)가 한 사이클로서 현재 비지임을 결정하였다. 제어 논리(130)는 라인(52) 상의 IOBUS_BSY- 신호를 활동레벨로 설정하여 요구되는 CPU 모듈(12) 뿐만 아니라 다른 CPU 모듈(12)에 I/O 버스(20)가 현재 한 트랜잭션으로서 비지임을 알려준다. 더우기, 제어 논리(130)는사이클이 종료되는 것을 표시하도록 활동 레벨에서 라인(112) 상의 SEOT- 신호를 복원시킨다. 요구 CPU 모듈(12)이 활동 레벨에서 라인(52) 상의 IOBUS_BSY- 신호를 수신하는 것과 동시에 활동 레벨에서 라인(112) 상의 SEOT- 신호를 수신할때, CPU 모듈(12) 상의 버스 제어기(150)의 다른 실시예는 I/O 버스(20)가 비지여서 그 요구된 I/O 액세스가 종료되었음을 결정한다. 요구 CPU 모듈(12)은 그 어드레스를 제거하고 IOBUS_BSY- 신호가 비활동이 되기를 대기해서 다시 요구를 시도한다. 그 동안, 나머지, CPU 모듈(12)은 상술한 바와 같이 라인(52) 상의 IOBUS_BSY- 신호를 모니터링한다. 나머지 CPU 모듈(12)은 일단 활동 레벨에서 라인(52) 상의 IOBUS_BSY- 신호를 수신하면 I/O 버스 액세스를 시도하지 않는다. 더우기, 상태(S3)에서 제어 논리(130)은 라인(142)을 통해 START- 신호를 개시한다. 라인(142) 상의 START- 신호는 타이머(132)로 전달되어 요구된 I/O 트랜잭션 타입을 결정하도록 타임-아웃 주기를 시작한다. 그후, 제어 논리(130)는 상태(S4)로 나아간다.

상태(S4)에서 제어 논리(130)는 활동 레벨에서 라인(144)을 통한 TIMEOUT- 신호의 수신 또는 라인(136)을 통한 SBUS_ACK- 신호의 수신을 대기한다. 라인(144)상의 TIMEOUT- 신호는 일단 소정 주기의 시간이 라인(142) 상의 START- 신호의 수신으로부터 지나가면 타이머(132)에 의해 생성된다. 라인(144) 상의 TIMEOUT- 신호는 현재의 트랜잭션이 I/O 버스 #1(124)에서 I/O 버스 #2(126) 타입의 트랜잭션일 때를 결정하거나 또는 그 반대일 때를 결정하는데 사용된다. I/O 트랜잭션이 I/O 버스 #1(124)에서 I/O 버스 #2(126)이거나 그 반대 타입의 트랜잭션이면, 제어 논리(130)는 라인(52) 상의 IOBUS_BSY- 신호를 비활동 레벨로 설정해서 CPU 모듈(121)이 I/O 버스(124, 126) 각각에 대한 다른 액세스 시도를 가능하게한다. 그렇지 않으면, 제어 논리(130)는 아비트레이션 논리 회로(128)로부터 수신 될 라인(136) 상의 SBUS_ACK- 신호의 수신을 대기해서 시스템 버스(18)가 데이타를 요구 디바이스로 전송하도록 각각의 I/O 버스(124, 126)로부터의 요구를 받아들이는 것을 나타낸다. 그 후, 제어 논리(130)는 다른 CPU 모듈(12)이 I/O 버스(124, 126)를 액세스하는 것을 가능하게 하도록 라인(52) 상의 IOBUS_BSY- 신호를 디어서트할 것이다. 활동 레벨에서의 라인(144) 상의 TIME_OUT- 신호나 활동레벨에서의 라인 (136) 상의 SBUS_ACK- 신호의 수신으로 제어 논리 회로(130)는 상태(S0)로 복귀하고 시스템 버스(18)에 의해 다른 요구를 대기한다.

라인(144) 상의 TIME_OUT- 신호와 라인(136) 상의 SBUS_ACK- 신호가 비활동상태이면, 제어 논리 회로(130)는 상태(S4)에 남아 있고 활동 레벨에서 라인(52) 상의 IOBUS_BSY- 신호와 라인(142) 상의 START- 신호를 재개시한다. 제어 논리 (130)가 상태(S4)에서 상태(S0)로 전이할 때 제어 논리 회로는 라인(146) 상의 RESET- 신호를 활동 레벨로 보낸다 라인(146) 상의 RESET- 신호는 라인(142)상의 다음 REART- 신호가 제어 논리 회로(130)로부터 수신될 때까지 타이머 회로(132)에 의해 수신되어 타임-아웃 클럭을 리셋한다.

버스 브릿지 회로(120)의 다른 실시예는 버스 브릿지 회로(22)의 제1 실시예와 다른데, 이는 버스 인터페이스 회로(122)가 I/O 버스(122,144) 상의 I/O 제어기(16)에 의한 동시 액세스 요구와 CPU 모듈(12) 요구와 연관된 문제점을 해소하기 때문이다. 두 실시예에서 라인(52) 상의 IOBUS_BSY- 신호는 다른 CPU 모듈(12) 또는 I/O 버스(124, 126) 중의 하나가 상술한 바와 같이 이미 액세스를 요구하였을 때 CPU 모듈(12)이 I/O 버스의 요구를 개시하는 것을 방지한다. 게다가, 버스 브릿지 회로(120)의 다른 실시예는 요구 CPU 모듈(12)이 라인(52) 상의 IOBUS_BSY- 신호를 수신하기 전에 다른 CPU 모듈(12) 또는 I/O 버스(124, 126) 중의 하나가 I/O 버스를 요구하였을 때 I/O 버스에 대한 액세스를 요구하는 CPU 모듈(12)을 "백오프"하기 위해 라인(52) 상의 IOBUS_BSY- 신호를 이용한다. 라인(52) 상의 IOBUS_BSY-신호가 개시되기 전에 제2 CPU 모듈(12)이 I/O 버스(124, 126)에 대한 액세스를 요구할 때, 라인(112) 상의 SEOT- 신호와 라인(52) 상의 IOBUS_BSY- 신호는 활동 레벨로 복귀한다. 제2 요구 CPU 모듈(12)이 활동 레벨에서 이들 2개의 신호를 수신할 때 CPU 모듈(12) 상의 버스 제어 논리의 다른 실시예는 이미 요구된 사이클이 완료되지 않았음을 인식한다. CPU 모듈(12) 상의 버스 제어 논리(32)는 라인(52)상의 IOBUS_BSY- 신호를 대기해서 비활동 레벨로 복귀하고 이 시점에 앞서의 어드레스 요구를 재개시한다. CPU 모듈(12) 상의 버스 제어 논리(150)의 다른 실시예와 버스 브릿지(120)의 다른 실시예 사이의 통신은 제10(a)도 및 제10(b)도를 참고로 상세히 후술된다.

제9도는 CPU 모듈(12) 상의 버스 제어기 논리(150)의 다른 실시예에 대한 상태표를 도시한다. 버스 제어기(150)의 다른 실시예는 버스 브릿지(120)의 다른 실시예로부터의 신호와 통신하도록 수정되었다. 상태(S0)에서 시작하여 버스 제어기(150)는 활동 레벨에서 수신된 라인(80) 상의 CPU 어드레스 스트로브(CADS-) 신호를 대기한다. CADS- 신호가 비활동 상태인 동안 버스 제어기는 상태(S0)에 남아 있다. 일단 라인(80) 상의 CADS- 신호가 활동 레벨에서 수신되면, 버스 제어기는 상태(S1)로 나아간다.

상태(S1)에저 버스 제어기는 라인(96) 상의 SADDS- 신호, 라인(74) 상의 SBACKx- 신호 및 라인(86) 상의 SBUSBSY- 신호의 상태를 모니터한다. SADDS- 신호 및 SBACKx- 신호가 비활성 상태이면, 버스 제어기(150)는 상태(S1)에 남아 있다. 일단 라인(74) 상의 SBACKx- 신호가 활동 상태이고 라인(86) 상의 SBUSBSY- 신호가 비활동 상태이면, 버스 제어기(150)는 상태(S10)로 나아간다. 그리고, 라인(96) 상의 SADDS- 신호가 활동상태이고 라인(74) 상의 SBACKx- 신호가 비활동 상태이면, 버스 제어기(150)는 상태(S2)로 나아간다.

상태(S2)에서 시스템 버스(18)에 대한 유효 어드레스 요구가 존재하도록 CPU 모듈(12)을 준비하지만, 시스템 버스(18)는 요구 CPU 모듈(12)에 허여되지 않는다. 버스 제어기(150)는 상태(S2)로부터 상태(S3)로 전이한 후 다음 두 클럭 사이클에 상태(S4)로 넘어간다. 상태(S4)에서 버스 제어기(150)는 라인(42) 상의 IOBUS_ACCESS- 신호, 라인(52) 상의 IOBUS_BSY- 신호, 라인(74) 상의 SBACKx- 신호 및 라인(86) 상의 SBUSBSY- 신호의 상태를 모니터한다. 라인(42) 상의 IOBUS_ACCESS- 신호가 활동 상태이고 라인(52) 상의 IOBUS_BSY- 신호가 비활동 상태이며 라인(74) 상의 SBACKx- 신호가 비활동 상태이고 라인(86)상의 SBUSBSY- 신호가 활동 상태이면, 버스 제어기는 상태(S6)로 나아간다. 상태(S4)에서 상태(S6)로의 버스 제어기(150)의 전이는 CPU 요구 어드레스가 I/O 버스(20)에 대한 액세스를 필요로 하고 I/O 버스(20)가 다른 트랜잭션으로 현재 비지가 아님을 의미한다. 또, 상태(S4)에서 상태(S6)로의 전이는 시스템 버스(18)가 현재 버스 트랜잭션으로 비지이고 따라서 요구 CPU 모듈(12)의 버스 요구를 허여하지 않았음을 의미한다.

상태(S4)에서 라인(42) 상의 IOBUS_ACCESS- 신호가 비활동 상태에 있고 라인(74)상의 SBACKx- 신호가 비활동 상태에 있으며 라인(86) 상의 SBUSBSY- 신호가 활동 상태에 있으면, 버스 제어기(150)는 상태(S7)로 나아간다. 상태(S4)에서 상태(S7)로의 전이는 CPU 요구 어드레스가 I/O 버스(20)에 대한 액세스를 필요로 하지 않음을 의미한다. 또, 상태(S4)에서 상태(S7)로의 전이는 시스템 버스(18)가 현재 트랜잭션으로 비지이고 버스 제어기(150)가 시스템 버스(18)에 대한 액세스를 허여받지 않았음을 의미한다.

마지막으로, 상태(S4)에서 버스 제어기가 비활동 레벨에서 라인(42) 상의 IOBUS_ACCESS- 신호를 수신하거나 버스 제어기(150)가 비활동 레벨에서 라인(52) 상의 IOBUS_BSY- 신호와 더불어 활동 레벨에서 라인(42) 상의 IOBUS_ACCESS- 신호를 수신하고, 버스 제어기(150)가 또 활동 레벨에서 라인(74)중의 한 라인상의 SBACKx- 신호와 비활동 레벨에서 라인(86) 상의 SBUSBSY-신호를 수신했다면, 버스 제어기(150)는 상태(S10)로 나아간다. 상태(S4)에서 상태(S10)로의 전이는 CPU 요구 어드레스가 I/O 버스에 대한 액세스를 필요로 하지 않거나 또는 어드레스가 I/O 버스(20)에 대한 액세스를 필요로 하는 경우에 I/O 버스(20)가 트랜잭션으로 현재 비지가 아님을 나타낸다. 또, 상태(S4)에서 상태(S10)로의 전이는 시스템 버스(18)가 현재 이용 가능하며 버스 제어기(150)가 시스템 버스(18)에 대한 액세스를 허여받았음을 나타낸다.

상태(S4)에서 버스 제어기(150)가 활동 레벨에서 라인(52) 상의 IOBUS_BSY- 신호를 수신하고 활동 레벨에서 라인(42) 상의 IOBUS_ACCESS 신호를 수신하면, 버스 제어기(150)는 상태(S5)로 나아간다. 버스 제어기(150)에 의한 상태(S4)에서 상태(S5)로의 전이는 CPU 요구 어드레스가 I/O 버스(20)에 대한 액세스를 요구하며 I/O 버스(20)가 I/O 요구로 현재 비지임을 나타낸다.

상태(S5)에서 버스 제어기(150)는 라인(52) 상의 IOBUS_BSY- 신호의 상태를 모니터한다. 라인(52) 상의 IOBUS_BSY- 신호가 활동 상태이면, 버스 제어기(150)는 상태(S5)에 있다. 라인(52) 상의 IOBUS_BSY- 신호가 비활동 레벨로 전이하면, 버스 제어기(150)는 상태(S6)로 나아간다. 상태(S5)에서 상태(S6)로의 전이는 I/O 버스(20)가 트랜잭션으로 더 이상 비지가 아니어서 액세스에 대해 이용 가능함을 나타낸다.

상태(S6)에서 버스 제어기(150)는 라인(52) 상의 IOBUS_BSY- 신호, 라인(74) 상의 SBACKx- 신호 및 라인(86) 상의 SBUSBSY- 신호의 상태를 모니터한다. 라인(52) 상의 IOBUS_BSY- 신호가 비활동 상태이고 라인(74) 상의 SBACKx- 신호가 비활동 상태이며 라인(86) 상의 SBUSBSY- 신호가 활동 상태이면, 버스 제어기 (150)는 상태(S6)에 남아있을 것이다. 라인(52) 상의 IOBUS_BSY- 신호가 활동 상태이면, 버스 제어기(150)는 라인(52) 상의 IOBUS_BSY- 신호가 비활동 레벨로 복귀할 때까지 상태(S5)로 돌아갈 것이다. 라인(74) 중의 한 라인 상의 SBACKx-신호가 활동 상태이고 라인(86) 상의 SBUSBSY- 신호가 비활동 상태이며 라인(52)상의 IOBUS_BSY- 신호가 비활동 상태이면, 버스 제어기(150)는 상태(S10)로 나아간다. 상태(S6)에서 상태(S10)로의 전이는 시스템 버스(18)가 액세스에 이용 가능하여 시스템 버스(18)가 요구 CPU 모듈(12)에 허여되었음을 나타낸다. 또, 상태(S6)에서 상태(S10)로의 전이는 I/O 버스(20)가 요구 CPU 모듈(12)에 의해 액세스에 이용 가능함을 나타낸다.

상태(S7)에서 요구 CPU 모듈(12)의 버스 제어기(150)는 라인(74) 상의 SBACKx-신호와 라인(86) 상의 SBUSBSY- 신호 각각의 상태를 모니터한다. SBACKx- 신호가 비활동 상태이고 SBUSBSY- 신호가 활동 상태이면, 버스 제어기 논리는 상태 (S7)에 남아 있다. 라인(86) 상의 SBUSBSY- 신호가 비활동 상태인 동안 라인(74) 상의 CPU 모듈의 각 SBACKx- 신호가 활동 상태이면, 버스 제어기(150)는 상태(S10)로 나아간다. 상태(S7)에서 상태(S10)로의 전이는 시스템 버스(18)가 현재 액세스에 이용 가능하며 요구 CPU 모듈(12)이 시스템 버스(18)에 대한 액세스를 허여받았음을 나타낸다.

버스 제어기(150)는 상태(S10)로부터 상태(S11)로 나아간 후 다음 두 클럭 사이클에 상태(S12)로 나아간다. 상태(S12)에서 버스 제어기(150)는 라인(42) 상의 IOBUS_ACCESS- 신호의 상태를 모니터한다. 라인(42) 상의 IOBUS_ACCESS-신호가 비활동 상태이고 요구된 어드레스가 I/O 버스에 대한 엑세스를 필요로 하지 않음을 나타내면, 버스 제어기(150)는 상태(S0)로 복귀하고 다음 마이크로프로세서 어드레스 요구를 대기한다. 라인(42) 상의 IOBUS_ACCESS- 신호가 활동 상태이면, 버스 제어기는 상태(S15)로 나아간다. 상태(S12)에서 상태(S15)로의 전이는 CPU 요구 어드레스가 I/O 버스에 대한 액세스를 필요로 함을 나타낸다.

상태(S15)에서 버스 제어기(150)는 라인(112) 상의 SEOT- 신호와 라인(52) 상의 IOBUS_BSY- 신호의 상태를 모니터한다. 라인(112) 상의 SEOT- 신호가 비활동상태인 동안 버스 제어기(150)는 상태(S15)를 유지한다. SEOT- 신호가 활동 상태이고 라인(52) 상의 IOBUS_BSY- 신호가 활동 상태이면, 버스 제어기는 상태(S5)로 복귀한다. 상태(S15)에서 상태(S5)로의 전이는 I/O 버스에 대한 CPU 요구 액세스가 다른 요구자에 대한 I/O 버스의 허여 후 수신되고 버스 제어기(150)가 완료될 현 I/O 사이클을 대기해야 함을 나타낸다. 상태(S5)로 복귀함으로써 현 I/O 사이클이 완료되면, 버스 제어기(150)는 다시 한번 I/O 버스에 대한 액세스를 시도할 수 있다. 상태(S15)에서 라인(112) 상의 SEOT- 신호가 활동 상태이고 라인(52) 상의 IOBUS_BSY- 신호가 비활동 상태이면, 버스 제어기(150)는 상태(S0)로 복귀한다. 상태(S15)에서 상태(S0)로의 전이는 I/O 버스에 대한 CPU 모듈의 요구 액세스가 완료되었음을 나타낸다. 상태(S0)에서 또 버스 제어기(150)는 다음의 마이크로프로세서 (24) 요구 어드레스를 대기한다.

버스 제어기(150)와 버스 브릿지(120)의 다른 실시예 사이의 통신은 제10(a)도 및 제10(b)도를 참고로 상세히 설명된다. 제10(a)도 및 제10(b)도는 시스템 버스(18) 및 I/O 버스(20) 둘다에 대한 시도된 CPU 모듈 액세스의 여러가지 타이밍 도표를 도시한다.

제8도 및 제9도의 도표의 상태에 상응하는 버스 브릿지(120) 상의 버스 제어기 CPU 모듈과 제어 논리(130)의 상태는 도표의 상부에 도시되어 있다.

타이밍 도표의 클럭 사이클(1)의 시작 단계에서, 버스 브릿지(120) 상의 제어 논리(130)는 CPU 모듈(12) 중의 한 모듈로부터의 어드레스 요구를 대기한다. CPU 모듈 #1, CPU 모듈 #2, 및 CPU 모듈 #3 상의 각 마이크로프로세서는 어드레스 요구를 그 각각의 버스 송수신기(30)로 보냈다. 또, 클럭 사이클(1)에서 라인(90) 상의 SBREQ1-신호 및 라인(92) 상의 SBREQ2-신호 및 라인(94) 상의 SBREQ3-신호는 모두 활동 상태이다. 이것은 각 CPU 모듈(12)이 시스템 버스(18)에 대한 액세스를요구했음을 나타낸다.

클럭 사이클(2)에서 라인(100) 상의 SBACK1-신호는 활동 상태이다. 이것은 시스템 버스(18)가 CPU 모듈#1에 액세스를 허여했음을 나타낸다. 또, 라인(86) 상의 SBUSBSY-신호가 비활성이 됨으로써 시스템 버스(18)는 이용 가능함을 나타낸다.

클럭 사이클(3)에서 CPU 모듈 #1은 시스템 버스(18)의 라인(98) 상에 그 어드레스 SADDRxx를 놓고 라인(96) 상의 SADDS-신호를 개시한다. 시스템 버스(18) 상의 요구된 어드레스와 더불어 라인(86) 상의 SBUSBSY-신호는 활동 상태가 되어 시스템 버스(18)가 현재 트랜잭션을 처리하고 있음을 나타낸다. 마지막으로, CPU모듈 #1은 라인(90) 상의 SBREQ1-신호를 비활동 레벨로 설정하여 CPU 모듈 #1이 더 이상 시스템 버스(18)에 대한 액세스를 요구하고 있지 않음을 나타낸다. 또, CPU 모듈 #1은 그 요구된 어드레스가 라인(152) 상의 CPU1 IOBUS_ACCESS 신호를 개시함으로써 I/O 버스(124, 126) 중의 한 버스에 대한 액세스를 필요로 하는 것을 나타낸다.

클럭 사이클(4)에서 라인(88) 상의 TRNSHLD- 신호는 시스템 버스(18) 상의 디바이스들이 그 요구된 어드레스에 응답하는지를 결정하도록 개시된다. 라인(90) 상의 SBREQ1- 신호의 디어서션에 응답하여 버스 아비트레이션 논리(128)는 라인(100)상의 SBACK1- 신호를 디어서트한다. 시스템 버스(18)가 SBACK1- 신호의 해제 후 CPU 모듈 #1에 더 이상 허여되지 않으므로 버스 아비트레이션 논리(128)는 다음 CPU 모듈(12)의 요구를 인식한다. 이 경우에, 버스 아비트레이션 논리(128)는 라인(102) 상의 SBACK2- 신호를 개시하여 CPU 모듈 #2에 대한 액세스를 허여한다

마지막으로, 라인(70) 상의 MP-2-IOBUS_ACCESS-신호가 개시되어 CPU 모듈 #1의 어드레스 요구가 I/O 버스(124,126) 중의 한 버스에 대한 액세스를 필요로 함을 나타낸다.

클럭 사이클(5)에서 라인(146) 상의 RESET-신호는 해제되어 비활동 레벨로 복귀한다. 클럭 사이클(6)에서 라인(86) 상의 SBUSBSY-신호는 비활동 레벨로 복귀하여 시스템 버스(18)가 액세스에 이용 가능함을 나타낸다. 또, 클럭 사이클(6)에서 라인(154) 상의 CPU3 IOBUS_ACCESS 신호는 CPU 모듈 #3에 의해 요구된 어드레스가 I/O 버스(124, 126) 중의 한 버스에 대한 액세스를 필요로 하지만 CPU 모듈 #3가 시스템 버스(18)에 대한 액세스를 허여받지 않았음을 나타낸다.

클럭 사이클(7)에서 I/O 버스(124, 126)는 라인(140) 상에 BACK-OFF-신호를 생성해서 I/O 버스(124,126)가 현재 앞서의 I/O 요구를 처리하고 있음을 나타낸다.

클럭 사이클(8)에서 활동 레벨에서 라인(140) 상의 BACK-OFF-신호의 수신으로 제어 논리(130)는 타이머 회로(132)에 대해 활동 레벨에서 라인(142) 상의 START-신호를 개시한다. 더우기, 제어 논리(130)는 라인(52) 상의 IOBUS_BSY-신호를 활동레벨로 설정하는 동안에 동시에 라인(106) 상의 CTERM-신호와 라인(112) 상의 SEOT-신호를 개시하여 CPU 모듈 #1으로부터의 앞서의 I/O 요구가 완료되지 않았음을 버스 제어기(150)에 표시한다. 라인(52) 상의 IOBUS_BSY-신호는 I/O 요구가 완료될 때까지 활동 상태이다. 또, 클럭 사이클(8)에서 라인(92) 상의 SBREQ2-신호는 다른 CPU 모듈(12)이 시스템 버스(18)를 액세스하도록 디어서트된다. 또, 클럭 사이클(8)에서 CPU 모듈 #2는 어드레스 라인(98)을 통해 그 어드레스 SADDRxx를 시스템 버스(18)에 나타낸다. 어드레스는 클럭 사이클(8)로부터 클럭 사이클(10)까지 유효하게 유지된다. 또, 클럭 사이클(8) 동안 버스 제어기(150)는 디바이스가 라인(98) 상의 어드레스 SADDRxx에서 클럭을 내보내도록 활동레벨에서 라인(96) 상에 SADDS-신호를 낸다. 이 경우에, CPU 모듈 #2 요구 어드레스는 I/O 버스(124, 126)의 어느 버스에 대한 액세스도 필요로 하지 않는다. 따라서, 라인(156) 상의 CPU2 IOBUS_ACCESS 신호는 비활동 상태이다.

클럭 사이클(9)에서 CPU 모듈 #3는 라인(94) 상의 SBREQ3-신호를 디어서트하는데, 이는 CPU 요구 어드레스가 I/O 버스(124, 126)에 대한 액세스를 필요로 하고 라인(52) 상의 IOBUS_BSY-신호가 활동 상태가 되어 I/O 버스(20)는 비지임을 나타내기 때문이다. 처음에, 클럭 사이클(9)에서 라인(88) 상의 TRNSHLD-신호는 시스템버스(18)상의 디바이스들이 그들 중의 하나가 요구된 어드레스에 응답하는지를 결정 하도록 개시된다. 클럭 사이클(10)은 클럭 사이클(9)과 클럭 사이클(11) 사이에서 한 클럭 사이클과 같거나 보다 큰 무한 주기의 시간을 나타내도록 파선으로 인터럽트된다.

클럭 사이클(11)에서 라인(144) 상의 TIMEOUT-신호는 어서트되어 타이머 (132)가 라인(142) 상의 START-신호에 의해 개시되는 시간 주기를 완료했음을 나타낸다.

또, 라인(86) 상의 SBUSBSY-신호는 디어서트되어 시스템 버스(18)가 액세스에 이용 가능함을 나타낸다.

클럭 사이클(12)에서 라인(142) 상의 START-신호는 타이머(132)가 그 시간 주기를 완료한 후 디어서트된다. 게다가, 라인(146) 상의 RESET-신호는 타이머 (132)를 리세트하도록 활동 레벨에서 개시된다. 라인(136) 상의 SBUS_ACK-신호의 수신 전에 비활동 레벨에서 라인(144) 상의 TIMEOUT-신호의 수신으로 제어 논리 회로(130)는 다른 시도의 I/O 액세스가 가능하도록 라인(52) 상의 IOBUS_BSY-신호를 디어서트한다. 비활동 레벨에서 라인(144) 상의 TIMEOUT-신호의 수신은 I/O 요구가 I/O 버스 #1(124)에서 I/O 버스 #2(126)로 전송되었고 따라서 버스 브릿지(120)가 다른 프로세서의 액세스 시도를 가능하게 하는 것을 나타낸다.

클럭 사이클(13)에서 라인(144) 상의 TIMEOUT-신호는 타임 아웃 주기가 완료되었으므로 디어서트된다. 비활동 레벨에서 라인(52) 상의 IOBUS_BSY-신호의 수신으로 인해 CPU 모듈 #1은 라인(90) 상에 SBREQ1-신호를 어서트함으로써 다른 I/O 요구의 개시를 시도한다. 또, CPU 모듈 #3은 라인(94) 상에 SBREQ3-신호를 어서트함으로써 I/O 사이클의 개시를 시도한다. 게다가, 클럭 사이클(13)에서 CPU 모듈 #2에 의해 요구된 데이타는 유효하며 시스템 버스(18) 상의 데이타 라인 SMD[63:00](108)에 존재하였다. 클럭 사이클(13)에서 CPU #2는 데이타 전송을 받아들였고 라인(106) 상의 CTERM-신호는 고활동 상태로 복귀한다. 또, 요구된 데이타는 단지 전송에 대해 한 클럭 사이클을 필요로 하기 때문에 라인(112) 상의 SEOT-신호는 로우로 스트로브하여 이것이 전송될 마지막 데이타임을 나타낸다.

클럭 사이클(14)에서 라인(102) 상의 SBACK2-신호는 디어서트되어 라인(92) 상의 SBREQ2-신호의 디어서션을 인식한다. 시스템 버스(18)가 SBACK2-신호의 해제 후 CPU 모듈 #2에 더 이상 허여되지 않으므로 아비트레이션 논리(128)는 다음 CPU모듈(12)의 요구를 인식한다.

이 경우에, 아비트레이션 논리는 CPU 모듈 #1이 시스템 버스(18)에 대한 액세스를 허여받는 것을 나타내기 위해 라인(100) 상에 SBACK1 신호를 개시한다.

클럭 사이클(15)에서 CPU 모듈 #1은 시스템 버스(18)의 SADDRxx 라인(98) 상에 어드레스를 놓기 시작한다. 클럭 사이클(16)에서 CPU 모듈 #1은 라인(90) 상의 SADDS- 신호를 CPU #1에 의해 요구된 어드레스가 시스템 버스(18) 상에 있으며 유효함을 나타내는 활동 레벨로 스트로브한다. 라인(98) 상의 SADDRxx 신호는 클럭 사이클(16, 17) 동안 유효하다. 시스템 버스(18) 상에 CPU 요구 어드레스의 존재로 인해 라인(86) 상의 SBUSBSY- 신호는 어서트되어 시스템 버스(18)가 트랜잭션으로 비지임을 나타낸다. 마지막으로, 라인(90) 상의 SBREQ1- 신호는 시스템 버스(18)가 CPU 모듈 #1에 허여되므로 디어서트된다.

클럭 사이클(17)에서 유효 CPU #1 요구 어드레스는 버스 브릿지(120)에 의해 래치된다. 버스 브릿지(130) 상의 버스 제어기 논리(130)는 타이머를 그 초기 위치로 설정하도록 라인(146) 상의 RESET- 신호를 개시한다. 또, 라인(180) 상의 SBACK- 신호는 디어서트되어 앞서의 클럭 사이클 동안 라인(90) 상의 SBREQ1-신호의 디어서션을 인식한다. 시스템 버스(18)는 SBACK1- 신호의 해제로 CPU 모듈 #1에 더 이상 허여되지 않기 때문에, 아비트레이션 논리(128)는 다음 CPU 모듈(12)의 요구를 인식한다. 이 경우에, 바이트레이션 논리(128)는 시스템 버스(18)를 CPU 모듈 #3에 허여하도록 라인(110) 상의 SBACK3- 신호를 개시한다. 마지막으로, 라인(88) 상의 TRNSHLD- 신호는 시스템 버스(18) 상의 디바이스들이 그중의 하나가 요구된 어드레스에 응답하는지를 결정하도록 개시된다.

클럭 사이클(19)에서 라인(86) 상의 SBUSBSY- 신호는 CPU #1에 의해 해제되는데, 이는 요구된 어드레스가 이미 버스 브릿지(120)에 의해 래치되었고 시스템 버스(18)가 더 이상 CPU 모듈 #1에 의해 요구되지 않기 때문이다.

클럭 사이클(20)에서 CPU #3는 그 어드레스를 시스템 버스(18) 상에 놓도록 준비한다. 또,I/O 버스(124,126) 중의 하나로부터 CPU #1에 의해 요구된 데이타는 이용가능하다. 유효 데이타는 시스템 버스(18)의 데이타 라인 SMD[63 : 00](108)에존재한다. 더우기, 제어 논리(130)는 요구된 데이타가 이용가능해지는 것을 나타내도록 라인(106) 상에 사이클 종료(CTERM-) 신호를 개시한다. 유효 데이타는 클럭 사이클(21)의 선단 엣지에서 시스템 버스(18) 상의 CPU #1에 의해 수신된다. 더우기, 요구된 데이타가 전송을 위해 단지 하나의 클럭 사이클을 필요로 하므로 라인(112) 상의 SEOT- 신호는 이것이 이 시간에 버스 브릿지(120)에 의해 전송되는 마지막 데이타임을 나타내도록 한 클럭 사이클 동안 스트로브된다.

클럭 사이클(21)에서 라인(146) 상의 RESET- 신호는 다음 I/O 전달을 모니터하기위해 타이머(132)를 새로운 시간 주기로 설정하도록 활동 레벨로 어서트된다. 게다가, CPU #1용의 라인(42) 상의 IOBUS_ACCESS-신호는 CPU #1이 완료되도록 I/O 요구로서 디어서트된다. 또, CPU #3는 그 유효 어드레스 SADDRxx 신호를 시스템 버스(18)의 라인(98) 상에 놓는다. 요구되는 어드레스는 클럭 사이클(21, 22) 동안 유효하다. 라인(96) 상의 SADDS-신호는 시스템 버스(18) 상의 디바이스가 어드레스 요구를 래치하도록 한 클럭 사이클 동안 로우로 스트로브된다. CPU 모듈 #3의 어드레스 요구를 시스템 버스 상에 놓음으로써 라인(86) 상의 SBUSBSY-신호는 시스템 버스(18)가 다음 트랙잭션으로 비지임을 나타내도록 활동 레벨에서 개시된다.

클럭 사이클(22)에서 라인(88) 상의 TRNSHLD-신호는 시스템 버스(18) 상의 디바이스들 중의 한 디바이스가 요구된 어드레스에 응답하는지를 디바이스들이 결정하도록 개시된다. I/O 사이클의 나머지는 CPU 모듈 #1과 관련하여 상술한 바와 같이 완료된다.

상술한 바와 같이, 버스 브릿지(22)에 의한 IOBUS_BSY-신호(52)의 생성은 모든 CPU 모듈(12)에게 I/O 버스(20)가 요구되었음을 나타내고, CPU 모듈(12)은 현재의 트랜잭션이 완료될 때까지 그 I/O 요구를 유지한다. 다른 CPU 모듈(12)이 I/O 요구를 수행하는 것을 방지함으로써 시스템 버스(18)는 아이들을 유지할 필요가 없게된다. 이 앞서의 유지 시간 동안 시스템 버스(18)는 메모리 CPU 모듈간 트랜잭션 및 CPU 모듈 CPU 모듈간 트랜잭션용으로 사용될 수 있는데, 그 동안 I/O 버스(20)는 캐시 히트 응답 등에 사용 중이다. 시스템 버스가 아이들로 유지되어야 하는 시간을 줄임으로써 시스템 버스의 전체 성능은 아주 증가한다.

본 발명은 그 정신 또는 필수 특성으로부터 벗어남이 없이 다른 특정 형태로 구현 될 수 있다. 상술된 실시예들은 예시적인 것으로 제한적인 것은 아닌 것으로 고려된다. 따라서, 본 발명의 범위는 앞서의 설명보다는 첨부되는 특허 청구의 범위에 의해서 나타내진다. 특허 청구 범위와 동등한 범위 내의 모든 변경은 그 범위 내에 포함된다.

Claims

공통 시스템 버스에 접속되며 I/O 버스 브릿지를 통해 I/O 버스에 접속되어 있는 다수의 CPU 모듈을 포함하는 멀티 프로세서 시스템용의 향상된 신호화 프로토콜 방법에 있어서, 상기 I/O 버스가 I/O 버스 트랜잭션을 처리하여 현재 비지임을 나타내는 제1 논리상태 및 상기 I/O 버스가 I/O 트랜잭션을 처리하도록 이용 가능함을 나타내는 제2 논리 상태를 갖는 I/O 버스 비지 신호를 상기 I/O 버스 브릿지 상에 생성하는 단계; 상기 I/O 버스 비지 신호를 상기 CPU 모듈의 각각에서 수신하는 단계; CPU 어드레스 요구가 상기 I/O 버스에 대한 액세스를 필요로 하는지를 결정하는 단계; 상기 CPU 요구 어드레스가 상기 I/O 버스 비지 신호의 상태에 관계 없이 상기 I/O 버스에 대한 액세스를 필요로 하지 않으면 상기 공통 시스템 버스가 이용 가능할 때 상기 공통 시스템 버스 상의 상기 CPU 어드레스 요구를 처리하는 단계; 상기 어드레스 요구가 상기 I/O 버스에 대한 액세스를 필요로 하고 상기 I/O 버스 비지 신호가 상기 제1 논리 상태에 있으면 상기 CPU 어드레스 요구를 유지하는 단계; 및 상기 어드레스 요구가 상기 I/O 버스에 대한 액세스를 필요로 하고 상기 I/O 버스 비지 신호가 상기 제2 논리 상태에 있으면 상기 시스템 버스가 이용 가능할 때 상기 CPU 어드레스 요구를 처리하는 단계를 포함하는 것을 특징으로 하는 신호화 프로토콜 방법.
공통 시스템 버스에 접속되며 I/O 버스 브릿지를 통해 I/O 버스에 접속되어 있는 다수의 CPU 모듈을 포함하는 멀티프로세서 시스템용의 향상된 신호화 프로토콜 회로에 있어서, 상기 I/O 버스가 I/O 버스 트랜잭션을 처리하여 현재 비지임을 나타내는 제1 논리상태 및 상기 I/O 버스가 I/O 버스 트랜잭션을 처리하도록 이용 가능함을 나타내는 제2 논리 상태를 갖는 I/O 버스 비지 신호를 생성하는, 상기 I/O 버스 브릿지 상의 I/O 버스 프로토콜 회로; 각 CPU로부터의 어드레스 요구를 수신하여 상기 시스템 버스로의 상기 CPU 어드레스 요구의 전달을 제어하는, 상기 각 CPU 모듈 상의 버스 제어기 논리 회로; 및 상기 각 CPU 모듈 상의 I/O 버스 금지 회로를 포함하며, 상기 I/O 버스 금지 회로는, 상기 CPU 어드레스 요구가 상기 I/O 버스에 대한 액세스를 필요로 함을 나타내는 제1 논리 상태 및 상기 CPU 어드레스 요구가 상기 I/O 버스에 대한 액세스를 필요로 하지 않음을 나타내는 제2 논리 상태를 갖는 I/O 버스 액세스 신호를 생성하는 어드레스 및 사이클 타입 디코더; 상기 I/O 버스 액세스 신호에 접속된 제1 입력, 상기 I/O 버스 비지 신호에 접속된 제2 입력 및 금지 신호를 생성하는 출력을 구비한 논리 회로를 포함하며, 상기 금지 신호는 상기 I/O 버스가 현재의 I/O 트랜잭션을 완료할 때까지 상기 시스템 버스로의 상기 CPU 어드레스 요구의 전달을 금지하도록 상기 버스 제어기 논리회로에 접속되어 있는 것을 특징으로 하는 신호화 프로토콜 회로.
제2항에 있어서, 상기 시스템 버스와 상기 I/O 버스 사이에 위치된 버퍼 회로를 더 포함하며, 상기 시스템 버스로부터 상기 I/O 버스로 전달된 데이타는 시스템 버스의 속도로 상기 버퍼 회로로 전달되고 I/O 버스 속도로 상기 버퍼 회로로부터 전달되며, 상기 I/O 버스로부터 상기 시스템 버스로 전달된 데이타는 I/O 버스 속도로 상기 버퍼 회로로 전달되고 시스템 버스 속도로 상기 버퍼 회로로부터 전달되는 것을 특징으로 하는 신호화 프로토콜 회로.