집적 회로 개발 시스템{INTEGRATED CIRCUIT DEVELOPMENT SYSTEM}

관련 출원에 대한 상호 참조

본 출원은 발명의 명칭이 집적 회로 개발 시스템인 2003년 6월 18일에 출원된 미국 가특허 출원 제60/479,759호에 대해 우선권을 주장하며, 그 내용이 본 발명에 참조로 포함된다.

본 발명은 집적 회로 개발 시스템에 관한 것으로서, 보다 구체적으로는, 하드웨어 객체들, 하드웨어 객체들 간의 메시지들을 용이하게 전달하는 통신 패브릭(fabric), 및 소프트웨어 표현 및 하드웨어 객체들 상에서의 시스템들의 실행을 허용하는 시스템을 포함하는 집적 회로 개발 시스템에 관한 것이다.

집적 회로(IC) 설계 및 개발은 현재 매우 어렵고 비용이 비싼 프로세스이다. 오늘날의 ASIC(Application Specific Integrated Circuit) 방법론 및 EDA(Electronic Design Automation) 툴들에 대한 엄격한 제한들로 인해 설계자들이, 새로운 제조 기술 각각이 제공하는 모든 여분의 게이트들을 효과적으로 사용할 수 없게 됨에 따라 설계 격차(design gap)가 점차 확대되어 나타나고 있다.

특별 주문 설계는, 새로운 제조 기술 각각의 낮은 레벨 상세들에서의 복잡성이 급격하게 증가함에 따라 상당히 새로운 설계를 가용한 시간 내에 할 수 없기 때 문에, 캐시 메모리와 같은 대량의 정규 구조를 갖는 설계인 경우에도, 매우 비용이 비싸게 된다. 긴 배선 및 칩 구성요소들 간의 점점 더 많은 상호접속들에 대한 필요성이 지속적으로 증가하는 오늘날의 아키텍쳐에 의해 IC 속도가 제한된다. 이와 같이 증가된 양의 상호접속은 배선 상의 결함이 좌우하는 새로운 제조 상황을 유발시키고 있다.

제조기술이 단일 다이에 10억개의 트랜지스터들에 가까운 트랜지스터 밀도로 지속적으로 개선됨에 따라, 급격하게 상승하는 설계 비용, 기하급수적으로 증가하는 검증 노력, 오늘날 설계 툴들의 고유 한계, 및 예전에 진행되었던 것을 효과적으로 재사용하지 못하는 무능력으로 인해 미래의 개발 비용이 매우 비싸지게 되고 소수의 경우에만 이용가능하게 될 것이라는 것이 자명하다.

ASIC 및 FPGA(Field Programmable Gate Array)를 사용하여 IC를 생성하는 예시적인 프로세스가 도 1a 및 도 1b에 예시된다. 상호접속된 기능들 (A, B, C)로서 본 명세서에 예시된 시스템 모델을 생성함으로써 설계가 시작된다. 시스템 모델은 임의의 방식으로 모델링될 수 있으며, 시스템의 이러한 모델링은, 예를 들어 블록도, UML(Unified Modeling Language) 모델 또는 데이터 흐름도를 포함한다. 시스템 모델이 완료되면, 시간 소비적이고 확인이 어려운 수기(by hand)에 의해 소프트웨어 기술(software description)이 생성된다. 소프트웨어 기술은, 예를 들어 C, C++, 자바, 스몰토크(Smalltalk) 또는 시스템 C로 생성될 수 있다. 그 다음, 소프트웨어 기술은, 시스템의 논리 게이트 모델을 생성하는데 사용될 수 있는 RTL(Register Transfer Level) 기술(description)로 수기 변환된다. RTL은, 합성 을 통해 논리 게이트 모델을 생성하는데 사용될 수 있는 베릴로그(Verilog) 또는 VHDL과 같은 HDL(Hardware Description Languages)에 대한 일반적인 용어이다. RTL은 ASIC(도 1A) 또는 FPGA(도 1B) 솔루션들 모두를 생성하는데 사용될 수 있다. 역시, 소프트웨어 기술을 RTL로 수기에 의해 변환하는 것은 시간 소비적이고 확인이 어렵다. ASIC의 경우, 합성을 통해 논리 게이트 모델이 생성되면, 반자동화된 하드웨어 레이아웃 툴들을 사용하여 기능성 게이트들을 배치 및 라우팅하는데 보다 많은 소프트웨어가 사용된다. 일단 레이아웃이 되면, 생성된 패턴들은 제조 프로세스에서의 광학 효과들을 고려하도록 최적화된다. 주의할 점은, 프로세스를 최적화하는 데에 많은 반복이 필요하고 최적화중 일부는 수동으로 수행된다는 것이다. 최종적으로, 마스크 세트가 생성되고 특정 설계의 ASIC을 제조하는데 사용된다.

도 1B를 참조하면, FPGA를 생성하기 위한 유사한 프로세스가 발생한다. 다시 RTL 기술 및 합성이 사용되어 논리 게이트 모델을 개발한다. 설계가 목표 부분에 물리적으로 맞는지를 보장하기 위해 몇몇 반복이 요구될 수 있다. 매핑(mapping)이 알려지면, 설계는 타이밍 요구조건들이 만족되는지를 보장하기 위해 검사된다. 타이밍 설계 요구조건이 초기에 만족되지 않으면, 매핑 및 타이밍 요구조건 모두가 만족될 때까지 RTL의 구조는 변경되어야 한다. 예를 들어, 타이밍 제약이 만족될 수 있는지를 보장하기 위해 병렬로 작동하는 동일한 논리의 복수의 반복을 종종 가질 필요가 있으며, 이는 RTL 기술을 변경함으로써만 달성될 수 있다. 최종적으로, FPGA 상의 모든 요소들에 대한 논리 매핑이 판독 전용 메모리(ROM)에 로딩된다. FPGA 디바이스에 전력이 공급되는 경우, 모든 FPGA 요소들은 원하는 기 능을 생성하기 위해 ROM으로부터 자동적으로 로딩된다.

트랜지스터들 및 다른 IC 구성요소들의 크기가 줄어들고 있기 때문에, 특별 주문 설계는 현재 사용되는 것보다 훨씬 많은 설계자들을 필요로 할 것이고, 이는 본 기술분야의 현재 상태와 비교하면, 엄청난 복잡성을 추가하고 개발하는데 기하급수적으로 많은 시간 및 자원들을 요구한다. 하드웨어 복잡성을 줄이고 하드웨어에서의 실수에 대한 검증 위험을 줄이기 위해, 많은 시스템들은 현재 하드웨어와 소프트웨어의 혼합을 사용하고 있다. 이러한 새로운 상황에서, 성능은 디바이스가 제조된 이후 기능 및 버그가 고정될 수 있도록 많은 구성요소들에 대해 프로그램가능한 하드웨어 상에서 작동하는 소프트웨어를 사용하는 것으로 대체된다. 소프트웨어 및 하드웨어가 함께 존재하여 솔루션을 생성하는 이러한 공동 설계는, 지난 20여년 동안 광범위하게 조사되었으나 별 성공을 거두지 못한 문제이다.

크고, 복잡한 설계가 합리적인 시간 내에 실행되고 검증될 수 있는 것을 보장하는데 필수적인, 하드웨어 및 소프트웨어 구성요소들의 광범위한 재사용은, 도달할 수 없는 것으로 증명되었고 소규모의 긴밀하게 연관된 설계 센터들 내에서 제한적인 의미로서만 관리되어 왔다.

본 발명의 실시예들은 종래 기술의 이러한 한계 및 다른 한계들을 다룰 것이다.

도 1a는 ASIC들을 설계하는데 사용되는 통상적인 프로세스들을 예시하는 블록도이다.

도 1b는 FPGA들을 설계하는데 사용되는 통상적인 프로세스들을 예시하는 블록도이다.

도 2는 데이터 전송 프로토콜을 예시하는 타이밍도이다.

도 3은 데이터 레지스터의 개념도를 예시하는 블록도이다.

도 4는 본 발명의 실시예들에 따른 프로토콜 레지스터의 다른 개념도를 예시하는 블록도이다.

도 5는 조합 논리를 포함하는 프로토콜 레지스터의 블록도이다.

도 6A 내지 도 6E는 일련의 프로토콜 레지스터들로 구성된 데이터 파이프라인의 거동을 예시하는 블록도이다.

도 7은 본 발명의 실시예들에 따른 다른 프로토콜 레지스터의 블록도이다.

도 8은 본 발명의 실시예들에 따른 프로토콜 레지스터의 개략도이다.

도 9는 도 8의 프로토콜 레지스터에 대한 상태 천이도이다.

도 10은 무효 데이터 멤버(invalid data member)들을 나타내는 데이터 패킷의 2개의 블록도이다.

도 11은 2개의 데이터 패킷들이 조합될 수 있는 방법을 예시한다.

도 12는 전통적인 FIFO 요소가 본 발명에 통합될 수 있는 방법을 나타내는 블록도이다.

도 13은 하드웨어 객체가 프로토콜 레지스터들을 사용하여 구성될 수 있는 방법을 나타내는 블록도이다.

도 14는 포크(fork), 결합(join) 및 프로토콜 레지스터들의 등가 조합들을 나타내는 개략도이다.

도 15는 프로토콜 레지스터의 비동기 구현을 나타내는 개략도이다.

도 16은 의사 비동기 클럭 생성을 나타내는 타이밍도이다.

도 17은 프로토콜 레지스터의 의사 비동기 구현을 나타내는 블록도이다.

도 18은 예시적인 하드웨어 객체의 블록도이다.

도 19는 하드웨어 객체들이 기존 하드웨어 객체들로부터 정의될 수 있는 방법을 나타내는 블록도이다.

도 20A 내지 20C는 서로 다른 유형들의 하드웨어 객체들을 예시하는 블록도들이다.

도 21은 다른 유형의 하드웨어 객체를 예시하는 블록도이다.

도 22는 하드웨어 객체들이 메시지들을 사용하여 서로 통신할 수 있는 방법을 예시하는 블록도이다.

도 23은 메시징 포크 객체(messaging fork object)를 예시하는 블록도이다.

도 24는 메시징 결합 객체를 예시하는 블록도이다.

도 25는 복수의 물리적으로 형성된 하드웨어 객체를 갖는 예시적인 재구성가능한 칩을 나타낸다.

도 26은 시스템들을 개발하기 위해 재구성가능한 칩과 결합하여 사용되는 객체 라이브러리를 예시하는 블록도이다.

도 27은 소프트웨어 객체 계층구조를 예시하는 블록도이다.

도 28은 하드웨어 시스템의 소프트웨어 모델을 예시하는 블록도이다.

도 29는 소프트웨어 객체들이 재구성가능한 칩으로 매핑되는 방법을 예시하는 블록도이다.

도 30은 각 소프트웨어 객체 시스템에 부착될 수 있는 추가 정보를 예시하는 블록도이다.

도 31은 재구성가능한 칩 상의 구현을 위한 소프트웨어 시스템들을 개발하는데 사용되는 프로세스들을 예시하는 흐름도이다.

도 32 내지 도 35는 본 발명의 실시예들을 사용하여 생성될 수 있는 예시적인 시스템을 나타내는 도면들이다.

본 발명의 실시예들은 집적 회로 개발을 위한 시스템을 포함한다. 개발 시스템의 실시예들은 하드웨어 및 소프트웨어 객체들을 포함한다. 이러한 객체들은 인스턴스되고, 순서화되며, 파라미터화되고 소프트웨어 환경에서 접속되어 서로 다른 기능들을 구현할 수 있다. 소프트웨어인 경우, 기술(description)은 객체 세트의 토폴로지 및 속성들을 정의한다. 이러한 객체들은 다른 객체들과 계층적으로 구성된다. 계층구조 내의 가장 하위 레벨은 프리미티브 객체(primitive object)로 표시된다. 기능을 구현하고 소프트웨어 객체의 주요 속성들을 유지할 수 있는 하드웨어를 이용함으로써, 소프트웨어 기술의 토폴로지 및 속성들이, 원하는 기능들을 수행할 수 있는 하드웨어를 정의하는데 요구되는 전부이다. 본 발명의 실시예들을 사용하면, 회로 설계자들은 하드웨어 또는 하드웨어 설계에 대한 지식을 거의 또는 전혀 갖지 않고, 단지 소프트웨어 기술만을 가지고 하드웨어 시스템들을 설계할 수 있다.

통신 원리(Communication Fundamentals)

기본적으로, IC 상에 형성된 하드웨어 객체들은 전기 신호들을 사용하여 서로 통신한다. 전기 신호들의 상태는 데이터를 표현하도록 정의된다. 예를 들어, 동작 전압과 접지 기준 전압 간의 중간점보다 큰 전압 값을 갖는 전기 신호는 "1" 또는 HIGH 값을 표현하는 것으로 생각될 수 있으며, 중간 전압보다 낮은 전압들은 "0" 또는 LOW 값으로 생각될 수 있다. 신호 무결성을 보장하기 위해, 접지 기준 근처의 제한된 전압 범위만이 LOW 값으로 생각될 수 있다. 유사하게, 동작 전압 근처의 제한된 전압 범위만이 HIGH 값으로 생각될 수 있다. 한계들 간의 임의의 전압은 정의되지 않은 논리 상태이다.

모든 설명 및 도면들에서, HIGH 값은 신호가 어써트된(asserted) 것을 나타내며; LOW 값은 디-어써트된(de-asserted) 값이다. 임의의 신호의 능동적인 감지는 HIGH 또는 LOW 용어로 결정되지 않는다.

복수의 신호는, 제1 포인트에서 제2 포인트로 데이터를 동시에 전송시킬 수 있는 병렬 데이터 버스를 따라 객체들 간에 전송될 수 있다. 특정 시간 내에 전송될 수 있는 데이터의 양은 버스의 데이터 폭 및 데이터 상태가 갱신되는 빈도에 의해 결정된다.

종종, 데이터가 객체들 간에 전송되는 때와 방법을 제어하기 위해 데이터 전송 프로토콜이 사용된다. 프로토콜은 통상적으로 실제 "데이터" 전송의 일부 자체가 아니라, 데이터에 대한 품질을 표시하거나 또는 데이터의 전송을 동기화시킨다. 예를 들어, 수신 객체는 자신이 사용중이기 때문에 데이터를 수신할 수 없는 때를 나타낼 수 있다.

도 2는 수신 객체가 "접수(accept)" 신호를 어써트함으로써 자신이 데이터를 수신할 수 있다는 것을 나타내는 상대적으로 간단한 데이터 전송 프로토콜을 예시하는 타이밍도이다. 유사하게, 송신 객체는 자신이 송신하고 있는 데이터가 유효인지 무효인지를 나타낸다. 무효 데이터는 임의의 값을 가질 수 있고 사용되지 않는다.

도 2를 참조하면, HIGH 접수 신호는, 수신 객체가 데이터를 수신할 수 있다는 것을 나타낸다. HIGH 유효 신호는, 데이터가 유용한 값을 가지고 있다는 것을 나타낸다. 접수 및 유효 신호들이 모두 HIGH인 경우, 송신 객체와 수신 객체 간에 데이터 전송이 발생한다. 클럭 신호가 도 2에 도시된다. 클럭은 자신의 포지티브 에지(positive edge)에서 유효, 접수 및 데이터 신호들을 트리거한다. 데이터 신호들은 단일 비트이거나 또는 동시에 송신된 몇몇 데이터 비트들을 포함할 수 있다. 일반 데이터 버스 폭들은 8, 16, 32 또는 64와 같이 2의 거듭제곱이다.

제1 클럭 펄스, 즉 도 2에 예시된 클럭 신호의 포지티브 에지에서, 유효 비트는, 데이터 신호들이 의미있는 값을 가진다는 것을 나타내는 HIGH로 구동된다. 그러나, 접수 신호는, 수신 객체가 데이터를 수신할 준비가 되어 있지 않다는 것을 나타내는 LOW이다. 데이터 신호들은 접수 신호가 HIGH인 경우 클럭 에지 4까지 값 DATA1을 유지한다. 접수 신호는 클럭 에지 3에서, 수신 객체가 수신할 준비가 되어 있다는 것을 나타내는 HIGH로 구동되었다. 클럭 에지 4에서, 데이터 DATA1은 송신 객체에서 수신 객체로 전송된다. 화살표는 데이터의 전송을 나타낸다. 클럭 에지 6, 7, 및 9에서, 유효 및 접수 신호들 모두가 HIGH이기 때문에 전송이 발생한다. 다른 모든 클럭 에지들에서는, 유효 및 접수 신호들중 하나 또는 양쪽이 LOW이기 때문에 전송이 발생하지 않는다. 클럭 에지들 상에서의 천이들을 나타냄으로써 설명을 용이하게 하기 위해 클럭이 도 2에 예시된다. 도 2에 도시된 전송 프로토콜은, 송신 객체의 상태에 대한 선험적 지식없이 수신 객체가 수신할 준비 상태를 나타내는 프로토콜들의 선점 클래스(pre-emptive class)중 하나이다.

도 3은 프로토콜 레지스터(50)를 예시하는 블록도이다. 레지스터는 입력 인터페이스 및 출력 인터페이스 간의 저장 요소들의 세트이다. 도 3의 인터페이스들은 도 2에 상세하게 예시된 것과 동일한 프로토콜을 사용한다. 입력 인터페이스는, 저장 요소들(52, 54)이 갱신될 수 있다는 것을 나타내기 위해 in_accept 신호를 사용한다. in_accept 신호가 HIGH이면, 저장 요소(54)는 in_data 상의 값을 저장하고, 저장 요소(52)는 in_valid 상의 값을 저장한다. 주의할 점은, 저장 요소들(52, 54)은 하나 이상의 (유효, 데이터) 값 쌍을 보유할 수 있다는 것이다. 출력 인터페이스는 저장 요소(52)의 가장 오래된 값을 out_valid에 제공하며, 저장 요소(54)의 가장 오래된 값을 out_data에 제공한다. out_valid 및 out_data 상의 값들은, out_accept 신호가 HIGH인 경우 다음의 가장 오래된 (유효, 데이터) 값 쌍으로 변경되며, 그렇지 않은 경우, 변경되지 않는다. 저장 요소(56)는 out_accept 신호의 이력을 포함하고 신호 in_accept의 다음 값을 계산하는데 사용된다.

도 4는 저장 요소(72, 74, 76, 78)들을 포함하는 다른 프로토콜 데이터 레지스터(70)의 블록도이다. 저장 요소(72, 74, 76)들은 유사하게 동작하는 도 3의 프로토콜 레지스터(50)의 저장 요소(52, 54, 56)들에 대응한다. 이러한 요소들에 대한 설명은 간결하게 하기 위해 생략된다. 저장 요소(78)는 패킷 식별자 값들의 이력도 저장하도록 레지스터(70)를 확장시킨다. 도 3의 레지스터(50)는 (유효, 데이터) 쌍들의 이력을 저장하고; 도 4의 레지스터(70)는 (유효, (데이터, packet_id)) 트리플(triple)들의 이력을 저장한다. 각 트리플에서, HIGH 유효 값은 (데이터, packet_id) 쌍 값이 의미있는지 여부를 나타낸다. 유효 값이 LOW이면, (데이터, packet_id) 쌍 값은 사용될 수 없거나 또는 정의되지 않는 결과가 발생할 수 있다. (데이터, packet_id)는 packet_id 값이 보다 큰 데이터 그룹 또는 데이터 패킷 내의 데이터 값의 위치를 나타내는 쌍이다. 종종 패킷 메시지들은 병렬로 동시에 전송될 수 있는 것보다 많은 데이터를 포함할 것이며, 메시지는 몇몇 데이터의 "워드들(words)"로 분해될 것이다. 본 명세서에 사용된 "메시지 패킷(message packet)" 및 "워드(word)"라는 용어는 가장 넓은 의미로 해석될 것이고 임의의 특정 구조, 포맷 또는 제한들을 암시하지 않는다. 따라서, 단일 메시지 패킷을 전송하기 위해 데이터 또는 워드들의 복수의 세트가 송신될 필요가 있다.

일 실시예에서, packet_id 값은 단일 비트이나, 물론 보다 큰 그룹 또는 메시지 패킷 내의 데이터의 멤버쉽의 임의의 표시일 수 있다. 특정 실시예에서, packet_id의 LOW 값은, 메시지 패킷 내의 최종 워드라는 것을 나타낸다. 모든 다른 워드들은 packet_id에 대해 HIGH 값을 가진다. 이러한 표시를 사용하면, 현재 워드를 선행하는 워드에 대한 LOW 값 바로 뒤를 따르는 HIGH packet_id 값을 검출함으로써 메시지 패킷 내의 제1 워드가 결정될 수 있다. 다르게 설명하면, 선행 packet_id에 대한 LOW 값에 후속하는 packet_id에 대한 제1 HIGH 값은 메시지 패킷 내의 제1 워드를 나타낸다. 단일 비트 packet_id를 사용하면 단지 제1 워드 및 최종 워드만 결정될 수 있다.

도 5는 조합 논리를 포함하는 프로토콜 레지스터(80)를 예시한다. 도 5의 프로토콜 레지스터(80)는 도 3의 프로토콜 레지스터(50)와 유사하나, 출력 인터페이스에 논리(87)를 포함한다. 도 5에 예시된 실시예에서, 논리(87)는 2개의 입력을 갖는 OR 게이트이다. 논리(87)는 레지스터(82)로부터의 부정 out_valid 신호와 out_accept 신호를 조합하여 out_valid가 LOW이더라도, 프로토콜 레지스터(80)는 항상 다음의 가장 오래된 (유효, 데이터) 쌍을 갱신한다는 것을 보장한다. 이러한 거동에 대한 실질적인 사용이 아래에 상세하게 예시된다.

도 6A 내지 도 6E는 파이프라인(90)에 조립되는, 일련의 프로토콜 레지스터(80)의 거동을 예시하는 블록도이다. 파이프라인(90)은 R1 내지 R9로 표시된 9개의 레지스터들을 포함한다. 도 6A 내지 도 6E 각각은 서로 다른 시간 주기, t1 내지 t5를 예시한다. 파이프라인(90)은 다음 수신 객체(도시 안됨)로부터의 out_accept 신호를 사용한다. 상술한 바와 같이, 다음 수신 객체는 데이터를 수신할 수 없을 때 out_accept 신호를 LOW로 구동시킨다. 시퀀스 t1 - t5 내의 out_accept 신호는 항상, 수신 객체가 t1 - t5 동안 수신할 수 없다는 것을 나타내는 LOW이다. 도 5를 다시 참조하면, 저장 위치(86)는 in_accept 신호를 연산하고 이를 다시 다음 레지스터에 송신한다. 예를 들어, 레지스터 R1의 in_accept 신호는 레지스터 R2의 out_accept 신호인 것 등이다. 이러한 방식으로, 수신 객체로부터의 out_accept 신호는 순차적으로 파이프라인(90)으로 송신된다.

도 6A를 참조하면, 시간 t1에서 파이프라인(90)은 데이터의 3개의 유효 워드들 D1, D2, D3를 보유한다. 파이프라인(90)은 무효로 생각되는 다른 데이터를 보유한다. 유효 데이터는 개별 레지스터들에 음영 박스들로 예시되며, 무효 데이터는 비음영 박스들로 예시된다. 상술한 바와 같이, 각 사이클에서, 파이프라인(90)은 다음 수신 객체로부터의 out_accept 신호를 사용한다. 파이프라인(90)은 또한 송신 객체(도시 안됨)로부터의 다른 (유효, 데이터) 쌍을 접수한다. 도 6A(시간 t1)에서, 데이터의 제4 유효 워드 D4가 파이프라인(90)으로 송신된다.

따라서, 시간 t1에서, 유효 데이터의 3개 워드들 D1, D2, D3이 존재하고 모두 파이프라인(90)의 개별 프로토콜 레지스터 R2, R5, R8에 저장된다. 중간 out_accept 신호가 HIGH인 각 사이클에서, (유효, 데이터) 쌍들은 다음 레지스터로 진행한다. 사이클 t1에서, 도 5의 논리(87)는 R1에 제공된 out_accept가 LOW이더라도 레지스터 R1이 갱신될 수 있게 한다. t2 및 t3 사이클에서, R2에 대한 중간 out_accept는, R2가 무효 데이터를 포함하기 때문에 HIGH로 유지된다. 도 5의 논리(87)의 효과는 파이프라인(90)에서 임의의 무효 데이터 워드들을 제거하고 파이프라인(90)의 각 레지스터 R1 - R9이 의미있는 데이터를 저장하는 경우에만 프로세싱을 중단한다는 것을 보장하는 것이다.

논리(87)의 동작은 모든 레지스터들 R1 - R9 사이에서 반복되고 D1, D2 및 D3 간의 무효 데이터 모두가 사이클 t5에 의해 제거될 수 있게 한다. 주의할 점은, 이러한 무효 데이터는 R1에 제공된 out_accept 신호가, 수신 객체가 데이터를 접수하지 않았다는 것을 나타내는 LOW로 보유된 경우에도 제거되었다는 것이다. 다른 경우 낭비된 사이클에서, 본 발명의 실시예들은 파이프라인이 데이터를 유용하게 계속하여 처리할 수 있게 한다.

도 7은 프로토콜 레지스터(70)(도 4)의 양상들과 도 5의 논리(87)를 결합시킨 프로토콜 레지스터(100)의 블록도이다. 프로토콜 레지스터(100)는 도 4를 참조하여 설명된 바와 같이 각각의 신호들을 저장하기 위한 저장 위치(102, 104, 106, 108)들을 포함한다. 논리 요소(107)는 도 5의 논리(87)에 대응하는 OR 함수를 포함한다. 물론 논리 요소(107)는 동일한 기능을 제공하는 임의의 게이트 조합들로 형성될 수 있다.

도 8은 본 발명의 실시예들에 따른, 단일 이력을 갖는 프로토콜 레지스터(100)의 구현을 예시하는 개략도이다. 도 8의 프로토콜 레지스터(100)는 에지 트리거형 클럭드 "D"형 플립 플롭들로 예시된 저장 레지스터들을 포함한다. 또한, 플립 플롭들중 일부는 인에이블 입력을 포함하며, 인에이블 입력은 그 인에이블이 HIGH인 경우 포지티브 클럭 에지에서 입력 값들이 출력으로 전송되는 것만 허용한다. 본 명세서의 기술(description)은 마스터 동기 클럭(도시 안됨)을 사용하여 동작을 설명하나, 회로는 아래의 예에서 예시된 바와 같은 비동기 클럭들을 사용하여 작동하도록 구성될 수 있다.

D형 플립 플롭(132, 134, 138)들은 하나의 (유효, 데이터, packet_id) 값 트리플을 저장할 수 있는 제1 레지스터 세트를 형성한다. 이러한 레지스터 세트는 "사이드 레지스터(side register)"(130)로 표시된다. D형 플립 플롭들(122, 124, 128)은 다른 (유효, 데이터, packet_id) 값 트리플을 저장할 수 있는 제2 레지스터 세트를 형성한다. 이러한 레지스터 세트는 "메인 레지스터(main register)"(120)로 표시된다. 멀티플렉서들(142, 144, 148)은, (신호 in_accept가 HIGH인 경우) 입력으로부터 또는 신호 in_accept가 LOW인 경우 사이드 레지스터(130)로부터의 (유효, 데이터, packet_id) 트리플이 메인 레지스터(120)에 로딩될 수 있게 하는 논리 세트이다.

이전에 설명한 바와 같이, 데이터 값의 폭은 임의의 수의 비트들일 수 있다.

논리 함수(127, 137)는 도 5의 논리(87)에 대응하고, 상세한 함수는 본 명세서에 설명되지 않는다. 레지스터(126)는 (논리 함수(127, 137)들의 작용을 무시하는) in_accept가 되는 한 사이클에 의해 지연된 out_accept의 복사본을 생성한다.

in_accept가 HIGH인 경우 입력 트리플이 사이드 레지스터(130)에 로딩되며, 다른 경우 사이드 레지스터는 이전 값 트리플을 유지한다. 멀티플렉서(142, 144, 148) 및 in_accept와 out_accept의 조합은 메인 레지스터(120)의 동작을 제어한다. 표 1은 메인 레지스터의 동작을 나타낸다.

표 1은 프로토콜 레지스터(110)에 대한 4개의 상태: NORMAL, STOPPING, STOPPED 및 STARTING이 존재한다는 것을 나타낸다. NORMAL 상태는 레지스터가 정상적으로 동작하는 경우 - 입력 인터페이스로부터의 다음 값 트리플을 출력 인터페이스로 직접 전달하는 경우이다. 출력 인터페이스 out_accept 신호가, 수신 객체가 데이터를 수신할 수 없고 입력 인터페이스 in_accept 신호가 아직 LOW가 되지 않았다는 것을 나타내는 LOW가 되는 경우 STOPPING 상태가 발생한다. STOPPING 상태 동안, 새로운 입력 값 트리플은 접수될 수 있고, 이는 사이드 레지스터(130)에 저장된다. STOPPED 상태는, 입력 및 출력 인터페이스들 모두가 임의의 데이터를 전송하지 않고 레지스터(120, 130) 모두가 유효 데이터로 채워져 있는 경우이다. STARTING 상태는, 출력 인터페이스가 가장 오래된 값 트리플을 전송하나, 입력 인터페이스가 정지된 경우이다. STARTING 상태에서, 사이드 레지스터(130)에 보유된 다음의 가장 오래된 값 트리플이 메인 레지스터(120)로 전송된다. 프로토콜 레지스터(110)에 대한 상태 천이도가 도 9에 제공되며, 상태 천이도는 각 상태를 변화하게 하는 out_accept 신호의 천이들 및 상태들을 나타낸다.

도 10은 길이 5의 패킷을 구성하는 (유효, 데이터, packet_id) 값 트리플의 조합의 2개의 가능한 뷰를 도시한다. 각 값 트리플은 워드 W1 - W5로 표현된다. 레지스터 뷰는 패킷이 유효 및 무효 값 트리플들 모두로 구성된다는 것을 나타내며, 음영 박스들은 유효 경우들을 나타낸다. 유효가 LOW인 경우, packet_id 신호는 데이터 신호들인 경우와 같이 정의되지 않는다. packet_id 신호는, LOW가 패킷 내의 최종 워드를 나타내는 단일 비트 신호이다. 상술한 바와 같이, LOW로부터 HIGH로의 packet_id의 천이는 패킷 내의 제1 워드를 결정한다.

도 10의 패킷 뷰는 단지 유효 워드들만을 뽑음으로써 유효 신호 상태를 추상화시켰다. 이는 다중 워드 패킷의 가장 편리한 뷰이다.

도 11은, 2개의 동일한 길이의 패킷들(이 경우 각각은 길이 5 워드임)이 워드 단위로 조합될 수 있는 방법을 나타낸다. 도 10의 패킷 뷰에서, 작용은 매우 간단하다; 각 워드는 개별적으로 조합되어 길이 5의 새로운 패킷을 만든다. 사이클별 거동은 보다 복잡하고 도 10의 레지스터 뷰는 각 패킷 내의 유효 신호가 실제 동작에 어떻게 영향을 미치는지를 예시한다.

도 11은 각각 5개 워드들을 갖고 A1-A5 및 B1-B5로 각각 연속적으로 표시된 2개의 패킷 A 및 B를 각각 사용한다. 도 11의 예에서, 조합은 길이 5의 새로운 패킷이 되고 각각의 출력 워드는 A1 + B1, A2 + B2, ..., A5 + B5이다.

도 11은 T1으로부터 T10까지의 각 사이클 동안의 동작을 나타낸다. 사이클 T1에서, 입력 워드들(A1, B1) 양자는 접수되고 그 합 A1 + B1이 출력된다. 사이클 T1에서의 출력 (유효, 데이터, packet_id) 값 트리플은 (1, A1 + B1, 1)이다. 사이클 T2에서는, B2가 유효가 아니기 때문에 가산될 수 없고, 따라서 A2 및 B2 양자가 제공되고 가산되어 출력 값 트리플(1, A2 + B2, 1)을 생성할 수 있는 경우인 사이클 T5까지 A2는 B2를 기다린다. 사이클 T2, T3, T4에서, 유효 출력이 없기 때문에 출력 값 트리플은 (0, X, X)이며, 여기서 X는 임의의 정의되지 않는 값이다. 사이클 T6에서, A3 및 B3는 이용가능하고 출력 값 트리플은 (1, A3 + B3, 1)이다. 사이클 T7에서, B4는 입력 상에 있으나, 무효 출력 값 트리플 (0, X, X)를 생성하는, A4를 기다려야 한다. 사이클 T8에서, A4 및 B4가 조합되어 출력 값 트리플(1, A4 + B4, 1)을 생성한다. 사이클 T9에서, B5는 입력 상에 있으나, 무효 출력 값 트리플 (0, X, X)를 생성하는 A4를 기다려야 한다. 사이클 T10에서, A5 및 B5 양자가 접수되어 최종 워드 (1, A5 + B5, 0)을 생성한다.

도 11에서, packet_id 필드는 패킷 A 워드 packet_id 필드의 복사본이거나 또는 패킷 B 워드로부터 복사될 수 있다. 본 예에서 패킷들은 동일한 길이를 가지기 때문에 그 상황은 대칭적이다. 도 11은 무효 워드들이 파괴되지 않으나, 인입 패킷들의 무효 워드들의 상대적 위치에 따라 출력 패킷에서 재배열되는 방법을 나타낸다. 패킷들이 결합하는데 필요한 시간 주기는 항상 적어도 가장 긴 패킷 길이이다.

도 12는 전통적으로 설계된 FIFO(First-In First-Out) 요소(144)가 도 3의 프로토콜 레지스터(50)로 변환될 수 있는 방법을 나타낸다. 전통적인 FIFO 요소(144)는 마스터 클럭을 사용하여 동기될 수 있거나, 또는 입력 인터페이스 및 출력 인터페이스가 독립적인, 연관되지 않은 클럭들을 사용하여 개별적으로 클럭되는 비동기적일 수 있다. 전통적인 FIFO 요소(144)는 입력 데이터를 FIFO로 밀어 넣기 위해 푸시 신호(push signal)를 사용한다. FIFO는 FIFO가 채워진 경우 풀 신호(full signal)를 생성한다. 풀 신호가 HIGH인 경우 푸시 신호를 어써팅하는 거동은, 일부 구현들이 입력 데이터를 버리고 일부는 이러한 조건들 하에서 푸시 신호를 단순히 무시하기 때문에, 정의되지 않는다. 유사하게, 전통적인 FIFO 요소(144)는 팝 신호(pop signal)를 사용하여 FIFO로부터 데이터를 출력한다. FIFO가 비워진 경우 엠프티 신호(empty signal)가 제공된다. 푸시/풀 문제와 유사하게, 엠프티 신호가 HIGH인 경우 팝 신호를 어써팅하는 것은, 일부 구현들이 정의되지 않은 값들을 출력하는 동안 다른 구현들은 이러한 조건 하에서 팝 신호를 무시하기 때문에, 정의되지 않는다.

도 12는 논리 함수(140, 141, 142, 143)를 추가함으로써 FIFO 요소(144)가 도 3의 프로토콜 레지스터(50)로 변환되는 방법을 나타낸다. in_data 및 out_data 신호들은 FIFO 요소(144)의 입력 및 출력 데이터 포트들과 정확하게 대응한다. 인버터(140)는, FIFO가 비어있지 않으면, 즉 FIFO 요소(144) 내에 데이터가 존재하는 경우 out_valid가 HIGH인 것을 보장한다. 인버터(142)는 FIFO가 채워져 있지 않으면, 즉 FIFO 요소(144) 내에 가용한 공간이 여전히 존재하는 경우 in_accept가 HIGH인 것을 보장한다. 2개의 입력을 가진 AND 논리 함수들(141, 143)은, FIFO 요소(144)가 채워져 있는 동안의 push=HIGH 및 FIFO 요소(144)가 비어있는 동안의 pop=HIGH와 같은 위법한 상태를 제거함으로써 FIFO 요소(144)의 임의의 가능한 정의되지 않은 거동들이 제외된다는 것을 보장한다.

도 13은 도 3의 프로토콜 레지스터(50) 또는 상술한 예시적인 프로토콜 레지스터들중 다른 것, 또는 그들의 조합들이 하드웨어 객체들을 생성하는데 사용되는 방법을 예시한다. 도 13의 상부 예는, 하드웨어 객체(150)에 대한 하나의 포트 및 하나의 입력 포트가 존재하는 간단한 파이프라인 스테이지를 나타낸다. 하드웨어 객체(150)는 도 10에 설명된 패킷 바인딩(packet binding)을 사용하여 구성될 수 있는 메시지들을 사용하여 시스템의 나머지와 통신한다. 메시지의 내용 및 구조는 도 10의 패킷 바인딩에 의해 결정되지 않고, 데이터, 피연산자, 결과들, 커맨드들, 명령들, 라우팅 방향들, 메시지 상태 플래그들 및 내부 구조 식별자들을 포함하나 이에 한정되지 않는 임의의 형태의 메시지 및 내용이 용이하게 구성될 수 있다.

모든 메시지들은 비동기적으로 다루어진다. 입력 포트에 대해, 비동기 수단은 임의의 시간에 메시지를 수신할 수 있으며, 입력 메시지가 하드웨어 객체(150)에 의해 처리될 수 없는 경우의 유일한 동작은, 입력을 차단하는 것이다. 이러한 것은, 메시지의 임의의 부분이 소비되거나 또는 처리될 수 없는 경우 프로토콜 레지스터(155)가 자신의 in_accept 신호를 LOW로 구동시킴으로써 달성된다. 출력 포트에 대해, 비동기 수단은 메시지를 출력할 준비가 된 경우에만 메시지를 출력할 수 있으며, 출력 메시지가 준비되지 않은 경우의 유일한 동작은, 하드웨어 객체(150)가 아무것도 출력하지 않는 것이다. 이러한 것은, 프로토콜 레지스터(156)가 자신의 out_valid 신호를 LOW로 구동시킴으로써 달성된다.

비동기 메시지들이 하드웨어 객체(150)의 동작들을 제어하는 것은, 소프트웨어 객체의 속성들 및 거동들에 직접적으로 대응하는 하드웨어 객체들을 생성하는데 유용하다. 하드웨어 객체(150) 내의 회로(151)는, 프로토콜 레지스터(155, 156)가 회로(151)를 임의의 주변 회로로부터 분리시키고 그 결과 예상치 못한 부작용을 가질 수 있기 때문에 임의의 회로 조합일 수 있다. 또한, 비동기 메시지를 사용하면, 메시지들이 임의의 시간에 수신 및 출력될 수 있기 때문에, 외부적으로 생성되는 임의의 타이밍 문제들을 제거할 수 있다.

하드웨어 객체(150)의 대안적인 구현이 도 13에 포함된다. 하드웨어 객체(152)와 하드웨어 객체(150) 간의 관계는 아래에서 상세하게 설명될 것이나, 프로토콜 레지스터(157, 158)가 각각 프로토콜 레지스터(155, 156)에 직접적으로 대응한다는 것에 주의하는 것이 중요하다. 또한, 회로(153)는 회로(151)와 동일할 수 있다. 하드웨어 객체(152)는 간단한 FIFO(154) 및 여분의 프로토콜 레지스터(159)를 포함한다. FIFO(154) 및 프로토콜 레지스터(159)의 동작은 임의의 입력 메시지들을 버퍼 및 지연시키는 것이다. 동기 시스템에서는, 이러한 지연으로 인해, 하드웨어 객체(150)와 비교할 경우 하드웨어 객체(152)의 동작에서의 대기 시간의 변경이 발생하나, 처리율 또는 기능에는 영향을 주지 않는다. 비동기 시스템에서는 시간 및 대기 시간에 대한 엄격한 개념은 존재하지 않고 따라서 하드웨어 객체(152) 및 하드웨어 객체(150)는 동일한 거동들을 가진다.

도 13의 내부 프로토콜 레지스터(159)는, 프로토콜 레지스터들이 단지 경계부분이 아니라 하드웨어 객체 내에 유용한 기능들을 가질 수 있다는 것을 나타낸다. 본 발명의 바람직한 실시예들은 그러한 레지스터를 사용하는 것이 이로울 때마다 프로토콜 레지스터들을 배타적으로 사용한다.

도 14는 프로토콜 레지스터들의 서로 다른 조합들을 각각 갖는 간단한 결합 및 간단한 포크 기능(fork function)을 나타낸다.

결합 기능(160)은 도 10의 패킷 바인딩에 대응하는 전체 메시지들에 대해 동작한다. 메시지는 도 13의 설명에서 상세하게 설명된다. 가장 간단한 형태의 결합 기능(160)은 2개의 입력 포트(161, 162), 하나의 출력 포트(168)를 가지며, 2개의 입력 포트들(161, 162)에서 수신된 메시지들을 동기화시킨다. 동기화는, 입력 포트(161, 162) 양쪽이 메시지의 제1 워드를 가지는 경우 출력 메시지를 단지 시작하고, 입력 인터페이스(161, 162) 양쪽이 동기화 프로세스를 시작한 메시지들의 최종 워드를 수신한 경우 단지 종료함으로써 수행된다.

포크 기능(163)은 도 10의 패킷 바인딩에 대응하는 전체 메시지들에 대해 동작한다. 메시지는 도 13의 설명에서 상세하게 설명된다. 가장 간단한 형태의 포크 기능(163)은 2개의 출력 포트(165, 166), 하나의 입력 포트(164)를 가지며, 입력 포트(164)에서 수신된 입력 메시지를 출력 포트(165, 166) 양쪽에 복제한다. 복제 프로세스는, 입력 포트(164)가 메시지의 제1 워드를 가지는 경우 출력 메시지를 단지 시작하고, 프로세스를 시작한 메시지의 최종 워드를 출력 인터페이스(165, 166) 양쪽이 송신한 경우 단지 종료함으로써 수행된다.

도 3의 프로토콜 레지스터(50)는 채워진 사각형으로 도 14에 도시된다. 예로서, 사각형(167)은 프로토콜 레지스터를 나타낸다. 도 14는 동일한 포크 및 결합 기능들을 생성하는 모든 동등한 토폴로지들을 나타내며, 실제로는 프로토콜 레지스터들을 배치하는 것은 기능을 변경시키지 않는다. 도 13의 설명에서 상세하게 설명된 바와 같이, 비동기 시스템에 프로토콜 레지스터들을 삽입하는 것은 타이밍 또는 기능에 영향을 주지 않는다.

도 14의 서로 다른 토폴로지들은, 프로토콜 레지스터를 삽입하는 판단이 임의적으로 이루어질 수 있다는 것을 나타낸다. 본 발명의 바람직한 실시예들에서, 레지스터들은, 모든 프로토콜 레지스터들이 대략 동일한 전기적 부하를 가져서 유사한 타이밍 특성을 갖도록 IC 상에 배치된다. 이러한 규칙을 강제로 시행함으로써, 모든 프로토콜 레지스터는 반드시 동일하게 동작한다. 하드웨어 객체들이 도 13에 도시된 것과 같이 프로토콜 레지스터들을 사용하여 포트들로 구성되면, 하드웨어 객체의 입력 및 출력 포트들은, 하드웨어 객체를 구현하기 위해 IC 상의 어떤 프로토폴 레지스터들이 선택되었는지에 무관하게, 동일한 기능 및 전기적 성능을 가질 것이다. 이로 인해, 하드웨어 객체들은 부작용없이 재배치가능하거나 또는 다시 인스턴스될 수 있으며, 이는, 그 인스턴스들이 임의의 위치에 임의의 시간에 동일하게 거동하도록 취해지는 소프트웨어 객체를 하드웨어 모델링하기 위한 중요한 특징이다.

도 15는, 도 8의 프로토콜 레지스터 구현(110)이 어떻게 확장되어 (유효, 데이터, packet_id) 값 트리플을 손실하거나 반복하지 않고 입력 및 출력 인터페이스들에 대해, 비동기 클럭들 clk1, clk2를 각각 사용하는 프로토콜 레지스터를 생성하는지를 나타낸다. D형 플립 플롭(171, 172, 173, 174)들은 동기화 기능을 수행함으로써 동기화 장치로의 천이가 불안정 상태 입력 전압을 생성하고 동기화 장치의 동작이 해당 불안정 상태 입력 전압을 유효 HIGH 또는 LOW 전압으로 (무작위로) 결정한다. 본래의 천이가 적어도 2개의 사이클에 걸쳐 안정하게 남아 있을 것이고 그래서 불안정한 이벤트 이후의 다음 사이클에서 참 논리 값이 항상 올바르게 샘플링되기 때문에 동기화 장치들의 결정은 무작위적일 수 있다. 많은 시스템들에서, 2개 초과의 D형 플립 플롭(171, 172 또는 173, 174)이 캐스케이드(cascade)되어 불안정한 출력 전압의 가능성을 줄일 수 있거나 또는 특정 동기화 장치 요소들이 D형 플립 플롭(171, 172, 173, 174)의 위치에 사용될 수 있다.

도 15는 유효 및 접수 신호들이 명시적으로 동기화된다는 것을 보여준다. in_data 및 in_packet_id 신호들은 동기적으로 샘플링되고 도 15의 논리의 동작은, out_valid 및 out_accept가 HIGH이고 전송이 수신 프로토콜 레지스터(도시 안됨)에 대해 이루어지는 경우 out_data 및 out_packet_id 신호들이 변화하지 않는다는 것을 보장한다.

도 15의 유효 및 접수 논리는 래치를 생성하여, 논리 HIGH 값이 동기화 장치들중 하나를 통과하고 다른 동기화 장치의 대응하는 HIGH 값이 수신될 때까지 LOW로 재설정될 수 없다

재설정 상태에서, 중요 노드(175, 176)들은 LOW이고 노드(177, 178)는 HIGH이다. 이는 회로의 정지 상태이다. 정지 상태에서, 1차 출력 out_valid는 LOW이고 in_accept는 HIGH, 즉 레지스터가 비어있고 시작할 준비가 되어 있다는 것이다. out_valid=LOW라는 것은, out_accept의 상태가 정지 상태에서 관련없다는 것을 의미한다. in_valid가 HIGH가 되는 경우만 다음 상태가 발생할 수 있어, (유효, 데이터, packet_id) 값 트리플을 입력한다. 상태 레지스터(179)는, 노드(177)가 다음 사이클에서 in_accept와 함께 LOW가 될 것이라는 것을 보장한다. 이는, 더이상 입력 데이터가 접수될 수 없다는 것을 보장한다. 노드(177)의 LOW 값은 플립 플롭들(171, 172)을 사용하여 동기화되어 결국 노드(178)는 LOW가 된다. 노드(176, 178) 양쪽이 LOW인 경우, out_valid는 HIGH로 구동된다. 상태 레지스터(180)는 전송이 일어난 때, 즉 out_valid 및 out_accept 양쪽이 HIGH인 시간을 기록한다. 상태 레지스터(180)는, 노드(176)가 전송 이후 다음 사이클에서 HIGH로 진행할 것이라는 것을 보장한다. 노드(176)가 HIGH가 되면, out_valid는 LOW가 되어 데이터의 전송이 반복되지 않는다. 노드(176) 상의 HIGH 값은 플립 플롭(173, 174)을 사용하여 동기화되고, 결국 노드(175)가 HIGH 값이 된다.

중요 노드(175, 176)가 HIGH이고 노드(177, 178)가 LOW인 상태는, 전송이 완료된 휴식 상태이다. 휴식 상태에서, 노드(175)가 HIGH이면, 이벤트들의 체인이 시작하여, 노드(177, 178, 176, 175)는 결국 모두 LOW, LOW, HIGH, HIGH의 자신들 각각의 정지 상태로 되돌아간다. 이때, in_valid가 HIGH로 진행하는 경우 새로운 전송이 시작될 수 있다.

도 16은 서로 다른 클럭 주파수들이 마스터 클럭으로부터 어떻게 구성될 수 있는지를 보여주는 타이밍도이다. 도 16에서, 2개의 "비동기" 주파수들, in_clk 및 out_clk이 생성된다. 주파수들은 항상 master_clk보다 낮고, 반드시 동일한 마크 간격을 가지거나 심지어 일치하는 클럭 에지들을 가질 필요는 없다. 도 16에서, (시퀀스가 반복된다고 가정하면) master_clk의 매 15개 포지티브 클럭 에지들에 대해 in_clk 및 out_clk 각각 상에 4개의 포지티브 클럭 에지들이 존재한다. 이는, in_clk 및 out_clk 양쪽의 주파수가 master_clk의 주파수의 4/15인 것을 의미하나, in_clk와 out_clk 간의 에지들의 서로 다른 배치는 양쪽 클럭들이 서로 효과적으로 비동기적이라는 것을 나타낸다.

도 16은 본질적으로 비동기적인 클럭들이 마스터 동기 클럭으로부터, 또한 각 출력 클럭에 대한 임의의 주파수 분할비들로 비교적 용이하게 생성될 수 있다는 것을 나타낸다. 도 16에서, in_clken은, master_clk의 네거티브 에지에서 샘플링된 후 master_clk과 함께 AND 함수에 대한 마스크로 사용되어 in_clk를 생성하는 인에이블 신호(master_clk에 동기임)이다. 유사하게 out_clken은, master_clk의 네거티브 에지에서 샘플링된 후 master_clk과 함께 AND 함수에 대한 마스크로 사용되어 out_clk를 생성하는 인에이블 신호(master_clk에 동기임)이다. 도 16에 설명된 클럭킹 스키마는 의사 비동기 클럭킹으로 알려져 있다.

도 17은, (유효, 데이터, packet_id) 값 트리플을 반복하거나 또는 손실함이 없이 입력 및 출력 인터페이스들에 대한 의사 비동기 IN_CLK 및 OUT_CLK을 각각 사용하는 프로토콜 레지스터를 생성하기 위해 도 8의 프로토콜 레지스터 구현이 확장될 수 있는 방법을 나타낸다. 의사 비동기 IN_CLK 및 OUT_CLK는 도 16에 설명된 바와 같이 MASTER_CLK, in_clken 및 out_clken으로부터 생성된다. 도 8의 논리는 IN_CLK로 표시된 음영 영역에 복제되고 프로토콜 레지스터(196)를 생성한다. 음영 영역의 모든 D형 플립 플롭은 IN_CLK를 사용하여 클럭된다. MASTER_CLK으로 표시된 비음영 영역의 추가 논리는, OUT_CLK로 표시된 음영 영역에 도시된 출력 인터페이스가 올바르게 형성되고 OUT_CLK 신호에 정렬되도록 프로토콜이 재포맷된다는 것을 보장하는 역할을 한다. D형 플립 플롭(190)은 MASTER_CLK 신호를 사용하여 클럭된다.

도 17의 비음영 영역의 논리는, 심지어 in_clken 및 out_clken들이 영구적으로 HIGH인 가장 빠른 레이트에서도 IN_CLK 및 OUT_CLK가 동일하면 동작이 도 8의 구현과 동일하다는 것을 보장하는 방식으로 구성된다. 이러한 경우 논리의 동작은 명확하다. 논리 게이트(191)는 항상 D형 플립 플롭(190)이 하는 것과 같이 LOW 값을 출력한다. 따라서, 논리 게이트(192, 193, 194)는 통과 모드(pass mode)에 있고 out_accept 및 out_valid의 상태는 프로토콜 레지스터(196)에 의해 직접 제어된다.

in_clken 및 out_clken이 도 17에서 영구적으로 HIGH가 아닌 다른 경우, (IN_CLK에 의해 클럭되는 프로토콜 레지스터(196)에 대한 out_accept인) 논리 게이트(193)의 출력과 out_valid가 올바른 상태에 있도록 비음영 영역의 게이트들이 제어되고: 논리 게이트(192)는, out_valid를 LOW로 구동시킴으로써 다음 in_clken이 아직 어써트되지 않은 경우 out_valid 복제의 가능성을 제거하고, 논리 게이트(193)는 게이트(193)의 출력을 HIGH로 구동함으로써 in_clken의 다음 어써트때까지 "out_accept"가 확장된다 (누락되지도 않음)는 것을 보장한다.

하드웨어 객체(Hardware objects)

도 18은 하드웨어 객체의 기능도를 예시한다. 상술한 바와 같이, 하드웨어 객체들은 복수의 프로토콜 레지스터에 의해 둘러싸여진 회로를 포함한다. 프로토콜 레지스터들은 상술한 것과 동일한 레지스터들일 수 있다. 레지스터들의 존재가 회로의 논리 흐름에 전혀 영향을 주지 않고, 오히려 긴 신호 배선들을 분할함으로써 전기적 부하의 균형을 맞추는데 사용된다. 각 하드웨어 객체는 완전히 캡슐화되고 임의의 다른 객체의 상태에 의해 영향을 받지 않는다. 하드웨어 객체들은 메시지들 또는 메시지 객체들을 송신함으로써 서로 통신한다. 패킷들은 명령들 또는 데이터 또는 양쪽을 포함할 수 있다. 소정의 실시예들에서, 하드웨어 객체의 내부 상태는 메시지들을 사용함으로써 단지 문의되거나 또는 변경될 수 있다. 하드웨어 객체가 명령들 및 적절한 데이터를 수신하면, 수신 하드웨어 객체는 데이터에 대해 동작하여 출력을 생성한다. 출력은 그 후 다른 객체로 송신될 수 있다.

설명된 개발 시스템에서, 하드웨어 객체들은 일반적으로 중간 크기(medium-grained), 즉 AND와 같이 가장 간단한 함수도 아니며, 하드웨어 객체들의 컬렉션(collection)의 일반적인 성질을 파괴하는 경향이 있는 과도하게 복잡한 함수도 아니다. 중간 크기의 객체들중 일부 예들은 IO 구조들, 마이크로프로세서들, RAM 및 FSM(Finite State Machines)을 포함한다. 소정의 객체들은 극단적으로 범용이며; 다른 것들은 고정된 기능을 가진다. 객체들은 물려받을 수 있는 서브-기능을 가질 수 있는데, 예를 들어, MAC(Multiply Accumulate) 객체는 소정의 응용에서 가산기 또는 승산기의 역할을 할 수 있다.

하드웨어 객체(300)는, 통상적으로 적어도 하나의 입력 프로토콜 레지스터(310) 및 출력 프로토콜 레지스터(310)에 의해 "둘러싸여진(bounded)", 특수 중앙 회로 세트(304)를 포함한다. 도 18에서, 복수의 프로토콜 레지스터(310)가 존재한다. 실제, 프로토콜 레지스터들(310)의 존재 및/또는 배치는 회로의 동작에 영향을 주지 않기 때문에, 객체의 기능 또는 동작 능력을 파괴하지 않고 프로토콜 레지스터들을 가지지 않는 하드웨어 객체를 가질 수 있다. 반대로, 하드웨어 객체(300)는 중앙 회로(304) 안쪽 및 경계에 수십 개의 레지스터들을 포함할 수 있다. 프로토콜 레지스터(310)를 임의의 위치에 배치하는 능력은, 저항성 및 용량성 부하의 균형을 맞추는 물리적 위치들을 선택함으로써 칩 내에 긴 신호 배선들이 형성되지 않게 하는데 사용될 수 있다. 프로토콜 레지스터(310)들은, 일부 레지스터들이 최소인 반면 다른 레지스터들은 추가 특징 또는 성능을 가질 수 있다는 점에서 서로 다소간 상이할 수 있다. 통상적으로, 프로토콜 레지스터들은 동시에 전송할 수 있는 데이터 신호들의 수에 의해 구별될 수 있다. 예시적인 시스템들은 다양한 유형들의 프로토콜 레지스터들중 몇몇 유형을 포함할 수 있다.

하드웨어 객체(300)들은 독립적일 수 있으나, 몇몇 하드웨어 객체들과 함께 연관시키는 것이 훨씬 더 유용할 수 있다. 도 19는 U1 - U9으로 표시된, 9개의 하드웨어 객체들(300)을 예시한다. 하드웨어 객체들(300)중 2개, U4 및 U7는 독립적이고 본 예에서 하드웨어 객체와 연관되지 않는다. 복수의 하드웨어 객체(300)는 연관되어, 개별 하드웨어 객체만에 의해 가능하거나 바람직한 것보다 많은 기능을 가진 다른 하드웨어 객체들을 생성할 수 있다. 도 19에 예시된 바와 같이, 하드웨어 객체들 U1, U2, U3, U5가 서로 연관되어 하드웨어 객체(320)를 생성한다. 하드웨어 객체(320)는 자신의 구성요소들 간의 내부 통신을 갖는, 특정 독립형 회로로서 간단히 형성될 수 있었다. 그러나, 본 발명의 실시예들을 사용하면, 개별적인 하드웨어 객체들은, 단순히 다른 구성요소들과 연관되기 때문에 자신들의 보편성을 잃어버리지 않는다. 반대로, 보다 작은 하드웨어 객체들의 컬렉션들로부터 보다 강력한 하드웨어 객체들을 구축하는 것이 본 발명에 포함된 진보성있는 개념들을 사용하는 것의 두드러진 이점이다.

도 19는 또한 하드웨어 객체들 U5, U6, U8, U9을 연관시킴으로써 형성되는 다른 하드웨어 객체(330)를 예시한다. 기능 관점에서, U5가 하드웨어 객체들(320, 330) 양쪽의 구성원인 것은 중요하지 않다. 소정의 경우, 독립형 하드웨어에서 동작하는 하드웨어 객체(320) 및 하드웨어 객체(330)의 구성요소 기능들 각각 및 분리가능한 하드웨어로 구성되는 하드웨어 객체 U5를 갖는 것으로부터 공유된 기능이 발휘된다. 다른 경우, 하드웨어 객체(320) 및 하드웨어 객체(330)의 구성요소 기능들은 하드웨어 객체 U5 내의 공유된 하드웨어 상에서 작동한다. 하드웨어가 임의의 적절한 우선순위 또는 성능 기준들로 공유될 수 있다는 것을 보장하기 위해 시간 공유 기능이 하드웨어 객체(320) 및 하드웨어 객체(330)에 존재하여야 한다.

도 20A 내지 도 20C는 예시적인 하드웨어 객체들(300)을 나타내며, 하드웨어 객체들 각각은 서로 다른 중앙 회로(304)를 가진다. 도 20A는 그 중앙 회로(304)에 승산 기능을 포함하는 하드웨어 객체(300)를 예시한다. 승산 기능은 하드웨어 승산기 또는 본 기술 분야에 잘 알려진 다른 방법들에 의해 구현될 수 있다. 프로토콜 레지스터(310)는 하드웨어 객체(300)와 다른 객체들 간에 균일한 데이터 인터페이스를 제공한다. 도 20B는 그 중앙 회로(304)에 메모리 및 시프터(shifter)를 포함하는 하드웨어 객체(300)를 예시한다. 이 예에서, 메모리 및 시프터는 프로토콜 레지스터(310)를 거치지 않고 서로 직접 통신한다. 중앙 회로(304) 내의 통신은 하드웨어 객체들의 경계들에서 사용되는 프로토콜 레지스터들 이외에 내부 프로토콜 레지스터(310)를 사용할 수 있다. 또는 다른 형태의 통신이 중앙 회로(304) 내에 사용될 수 있다. 예를 들어, 도 20B에 예시된 바와 같이 메모리 및 시프터는 다이렉트 버스 프로토콜(direct bus protocol)을 사용하여 서로 직접 통신할 수 있다. 또한, 메모리 및 시프터는 원하는 경우 직렬 회선(serial line)을 통해 통신할 수 있다. 하드웨어 객체들을 조립하고 구현될 수 있는 시스템들을 개발하는데 있어, 임의의 하드웨어 객체(300)의 중앙 회로(304) 내의 구성요소들이 서로 통신하는 방법은 상대적으로 중요하지 않다. 도 20B의 하드웨어 객체(300)는 또한 객체들 간의 통신을 용이하게 하기 위해 프로토콜 레지스터들(310)을 포함한다.

도 20C는 중앙 회로(304)에 또 다른 구성요소들을 갖는 하드웨어 객체(300)의 추가 예를 예시한다. 이 예에서, 메모리 및 상태 머신은 추가적으로 레지스터 파일 및 ALU(Arithmetic Logic Unit)에 연결된다. 이러한 예는, 중앙 회로(304)의 모든 구성요소가 서로 직접적으로 통신할 필요가 없고, 임의의 방법 또는 프로토콜을 사용하는 통신이 특정 하드웨어 객체(300) 자체 내에 통합될 수 있다는 것을 나타낸다. 그러나, 대부분의 경우, 중앙 회로(304)의 "에지들(edges)"에 프로토콜 레지스터(310)를 포함하는 것은, 하드웨어 객체들의 쉬운 컬렉션을 용이하게 하여 매우 강력하고 복잡한 객체들을 생성한다.

도 21은 하드웨어 객체들이 다른 하드웨어 객체들과 동일한 경계들에 의해 둘러싸여질 필요가 없다는 것을 나타낸다. 도 21에서, 5개의 하드웨어 객체들이 예시된다. IC 기판 상에 고정된 4개의 하드웨어 객체들은 342, 344, 346, 348이다. 객체(350)는 객체들(342, 344, 346)의 요소들로 이루어진다. 객체(350)는 완전한 객체(342, 346)를 포함하나, 객체(344)의 일부분만을 포함한다. 구체적으로, 객체(350)는, 하드웨어 객체(344)의 중앙 회로(304)의 ALU들중 단지 하나 및 메모리를 사용한다. 주의할 점은, 하드웨어 객체(344)의 중앙 회로(304)는 이미 내부적으로 그들을 활용하고 있기 때문에, 객체(350)는 프로토콜 레지스터(310)에 의해 여전히 둘러싸여진다는 것이다. 이 경우, 객체(350)는 하드웨어 객체(344)의 중앙 회로(304) 내부에 있었던 프로토콜 레지스터(310)를 사용할 수 있다. 객체(344)로부터의 나머지 ALU 및 객체(348) 전체는 여기서 할당되지 않으나, 다른 하드웨어 객체를 형성하는데 사용될 수 있다.

객체들은, 본 발명의 바람직한 실시예들에서 메시지 패킷들을 사용하여 구현될 수 있는, 비동기 메시지들을 서로 송신함으로써 서로 통신한다. 메시지 패킷들은, 데이터, 명령들, 어드레스들 및/또는 메시지 패킷들 자체에 대한 정보를 포함할 수 있는, 메시지의 구조 또는 내용을 제한하지 않는다. 도 22는 각각의 프로토콜 레지스터(310)들 간의 메시지들을 사용하여 서로 통신하는 2개의 하드웨어 객체(360, 370)를 예시한다. 본 발명의 실시예들은 임의의 특정 메시지 포맷을 지시하거나, 또는 메시지들이 임의의 소정 프로토콜에 따르는 것을 요구하지 않는다. 물론, 시스템이 설계됨에 따라 송신기 및 수신기가 올바르게 메시지들을 해석하도록 메시지 구조의 송신기 및 수신기 간의 이해가 형성되어야 한다.

10개 워드들을 포함하는 예시적인 메시지(380)가 또한 도 22에 예시된다. 이러한 예시적인 메시지(380)는, "ROUTE LEFT"와 같이 고정형 커맨드 또는 목적지 어드레스일 수 있는 라우팅 커맨드로 시작한다. 하드웨어 객체들의 시스템이 재구성가능한 칩 상에서 연결되고 고정되는 경우, 아래에서 설명되는 바와 같이, IC 기판 상의 각 하드웨어 객체에 고유 어드레스가 할당될 수 있다. 메시지들은 예를 들어, 고유 어드레스 또는 조종 커맨드(steering command)에 기초하여 지향될 수 있다. 라우팅 정보 이후, 메시지(380)는 메시지 내에 포함된 정보의 유형 또는 심지어 메시지의 보다 상위 레벨 구조를 식별하는데 사용될 수 있는 플래그들을 포함한다. 프로토콜 레지스터들(310)을 통해 송신된 프로토콜에 따른 메시지들이 몇몇 서로 다른 유형들을 나타낼 수 있기 때문에, 플래그들은 어느 유형들이 사용되는지를 나타내는데 사용될 수 있다. 플래그들은 메시지의 포맷, 예를 들어 데이터만을 포함하거나, 명령들을 포함한다는 것 등을 나타낼 수 있다. 도 22의 예시적인 메시지(380)는 일련의 명령들 및 피연산자들, 및 수신 객체(370)에 의해 사용될 다양한 플래그들을 더 포함한다. 소정의 경우, 수신 객체는 송신 객체로부터 수신된 명령들 및 피연산자들중 일부 또는 그들 전부를 단순히 다른 객체에게 전달할 수 있다. 제1 객체가 제1 객체에게 직접적으로 접속되지 않은 다른 객체에게 메시지를 송신하는 관통 메시지(pass-through message)들이 사용된다.

도 23은 복수의 기본 객체(402, 404, 406, 408, 410)를 포함하는 "메시징 포크(messaging fork)" 객체(400)를 예시한다. 단일 데이터 스트림 A는 객체(400)에 대한 입력이고 2개의 출력들 A1 및 A2가 생성된다. 포크는 데이터 스트림 A에 포함된 임의의 데이터 또는 피연산자에 대해 동작할 수 있다. 포크 프리미티브 객체(402) 내에서, 메시지 스트림 A는 2개의 구성요소 스트림들 A1 및 A2로 분리된다. 가장 기본적인 형태에서, 포크 객체(402)는 데이터 스트림 A로부터의 데이터를 간단히 복제하여 2개의 스트림들 A1 및 A2를 만든다. 다른 실시예들에서, 포크 객체(402)는 인입 스트림을 구성요소 스트림들로 파싱(parsing)하기 전에 인입 스트림에 대해 동작들을 수행할 수 있다. 예를 들어, 포크 객체(402)는 데이터 스트림 A 내의 대분수(mixed number) 스트림을 접수하고 단지 정수들만 스트림 A1으로 분리하고 부동소수점들은 스트림 A2로 분리할 수 있다. 포크 객체(402)들의 다른 실시예들은 스트림들에 대한 동작없이 간단히 스트림들을 분리할 수 있는데, 예를 들어, 특정 범위 내의 모든 어드레스된 메시지들은 출력 스트림 A2로 가고 다른 모든 메시지들은 출력 스트림 A1으로 갈 수 있다. 이러한 방식으로, 많은 양의 인입 데이터가 복수의 분리된 병렬 프로세스를 거쳐 분리될 수 있다. 다른 유형들의 포크들은, 메시지 패킷 내의 라우팅 커맨드를 만나지 못하는 경우 고정된 방향으로 패킷들을 조정하는 조정 포크들을 포함하며, 이 순간 조정 포크들은 라우팅 커맨드를 따른다. 2개의 결과적인 데이터 스트림 A1 및 A2만을 생성하는 것으로 예시되었더라도, 복수의 포크 객체가 연결되어 임의의 개수의 결과 스트림들을 생성할 수 있다.

도 23은 또한 객체들(404, 406)이 메시지 스트림(A2)에 대해 동작하여 매우 복잡한 포크 기능들을 생성하는 것을 보여준다. 유사하게, 객체들(408, 410)은 메시지 스트림 A1에 대해 동작하여 추가 기능들을 생성할 수 있다. 5개 객체들(402, 404, 406, 408, 410)로 구성된 객체(400)의 구조의 중요성은, 메시지 스트림들 A1 및 A2가 병렬로 동작한다는 것이다. 예를 들어, 스트림들중 하나가 일시적으로 막히면, 다른 스트림이 계속하여 처리된다.

도 23은 임의의 스트림들의 길이를 제한하지 않으며; 특히 본 예에서 출력 스트림들이 동일한 길이의 입력 메시지에 의해 모두 호출되더라도, 출력 스트림 B1 및 B2를 서로 다른 길이들로 만드는 것이 중요할 수 있다.

도 24는 2개의 입력 스트림들을 접수하고 이들을 하나의 스트림으로 결합시키는 "결합(joining)" 객체(420)를 예시한다. 도 23에 예시된 포크 객체와 유사하게, 결합 객체(420)는 원하는 기능을 구현하는데 필요한 거의 임의의 형태를 취할 수 있다. 일반 결합 기능은 2개의 입력 메시지들에 대해 동기화된다. 이러한 경우, 입력 메시지들 양쪽은 임의의 출력 스트림들의 생성이 시작하기 전에 존재하여야 하고, 일단 시작하면, 동기화 프로세스는 각 입력 메시지들의 전체가 수신될 때까지 완료될 수 없다. 다른 일반 기능은, 제1 입력 메시지를 복사하여 출력에 도달시키는 "대체 결합(alternate join)" 기능이다. 입력 메시지가 접수되면, 다른 입력 상의 다른 메시지들은 복사가 완료되기를 기다린다. 일반적으로, "대체 결합" 기능은 최저 최근 사용 규칙(least-recently-used policy)에 따라 공정하게 중재하나, 고정형 입력 우선순위를 가지거나 또는 입력 메시지들 내에 인코딩된 우선순위 역할을 하는 다른 변수들이 일반적으로 사용된다. 결합 기능 및 그의 상사형 포크 기능은, 병렬 프로세스들의 출력들 간의 연산 순서를 생성하는데 사용될 수 있기 때문에, 비동기 연산 시스템에 매우 유용하다.

도 24는 하드웨어 객체들을 함께 결합함으로써 복잡한 결합 기능이 생성될 수 있다는 것을 보여준다. 객체들(422, 424) 간의 피드백 선(429, 430)들은 입력 메시지 스트림들(431, 432)의 매우 복잡한 조합들이 구현될 수 있게 한다. 유사하게, 객체(428)는 기본 결합 객체(426)의 출력을 추후 처리하는데 사용될 수 있으며, 최종 결합 객체(420)를 내부의 기본 결합 객체(426)보다 훨씬 더 복잡하게 만든다. 도 23과 유사하게, 결합 객체(420)의 주요 품질은 그의 구성요소 부분들이 독립적으로 동작한다는 것이다.

하드웨어 객체들이 쉽게 결합되면, 독립적으로 동작하고 도 21, 23, 24에 설명된 비동기 메시지들을 사용하여 통신하는 것이 반드시 최대 시스템 성능을 보장하기에 충분하지 않다. 또한, 상술한 바와 같이 다양한 프로토콜 레지스터들중 하나를 사용하면 시스템 내의 모든 구성요소 객체는, 완전히 정지할 때까지(출력할 수 없고, 유효 데이터로 채워지는 때) 데이터를 계속해서 처리할 것이다.

상술한 하드웨어 객체들은 실리콘 또는 다른 기판 상에 간단한 방식으로 형성될 수 있다. 도 25는 하드웨어 객체들(454, 455)의 복수의 물리적으로 형성된 인스턴스를 갖는 예시적인 칩(50)을 나타낸다. 객체들은 프로토콜 레지스터들 사이에 연결된 데이터 라인들에 의해 상호접속되며, 이는 상술한 다른 프로토콜 레지스터들의 속성들을 가질 수 있다. 입력 및 출력 핀들(458)은 칩(450)에 인터페이스를 제공한다. 특정 접속 프로토콜들을 수행하도록 프로그램된 특정 하드웨어 객체(454)를 포함함으로써, USB 또는 파이어와이어(Firewire)와 같은 표준 통신 프로토콜들이 칩(450)에 접속될 수 있다.

칩(450) 상에 형성된 객체들(454, 455)의 특정 혼합은 칩(450)에 의해 실행되는 애플리케이션의 유형에 따라 변화할 수 있다. 그러나, 현대 기술들은 매우 큰 수의 물리적 객체들을 지원할 수 있기 때문에, 응용가능성을 보다 광범위하게 만든다. 하드웨어 칩(450) 상의 하드웨어 객체들은 상대적으로 용이하게 구성 및 재구성될 수 있기 때문에, 칩(450)은 재구성가능한 표준 부분(Re-configurable Standard Part) 또는 RSP로 표현될 수 있다. RSP 상에 구현된 물리적 하드웨어 객체 인스턴스들의 총수는 100 - 100,000의 단위 또는 그 이상일 수 있다. 서로 다른 물리적 하드웨어 객체들의 총수(본 예에서는 단지 2개)는 예를 들어 10 단위로 훨씬 적을 것이다. 물론, 하드웨어 객체들의 임의의 수의 유형들 또는 총수가, 본 발명에 설명된 진보적인 개념들에서 벗어나지 않고 RSP 상에 구현될 수 있다.

기본 RSP 상에 만들어지는 하드웨어 객체들을 선택함으로써, 특정 RSP들이 특정 시장에 대해 최적화될 수 있다. 일반적인 예는 연산 하드웨어 대신에 온칩(on-chip) 메모리 용량을 선택하는 것이다. 예를 들어, 가산기들, 시프터들 및 승산기들과 같은 복수의 물리적 연산 하드웨어 객체를 갖는 RSP는 DSP(Digital Signal Processing) 시장에 유용할 수 있다. 다른 경우, 보다 많은 온칩 메모리를 갖는 것은, 큰 데이터 세트들을 저장하고 네트워크 패킷들을 버퍼링하는 것이 순수한 수학적 연산보다 중요한 네트워크 라우팅 시장에 유용할 것이다.

소프트웨어 객체들(Software objects)

하드웨어 객체들이 정의되면, 본 발명의 실시예들은 상호접속된 하드웨어 객체들의 기술(description)을 개발함으로써 시스템이 구축될 수 있게 한다. 궁극적으로, 이러한 기술은 상술한 RSP 상에 로딩되고 완전히 프로그램되어 매우 일반적인 아키텍쳐를 사용한 매우 고유한 시스템이 생성된다. 프로그램되면, RSP 시스템은 완성되고 동작할 준비가 된다.

상호접속된 하드웨어 객체들의 시스템을 생성하기 위해, 하드웨어 객체 정의들의 소프트웨어 기술들은 객체 라이브러리에 저장된다. 예시적인 라이브러리가 도 26에 예시된다. 라이브러리 객체들 A, B, C, D의 컬렉션이 이 도면에 예시된다. 라이브러리 객체들은 프리미티브 객체 기술들의 사전 정의된 컬렉션들이다. 고유 메시징 프로토콜들의 존재 및 상술한 각 하드웨어 객체들의 캡슐화는 하드웨어 객체들의 소프트웨어 객체 기술들이 하드웨어 객체 내에 이미 내장될 수 있게 한다.

본 발명에 포함되는 소프트웨어 객체의 주요 속성들은 독립적 실행, 객체들 간의 비동기 메시징, 캡슐화 및 컨텍스트에 대한 둔감성을 포함한다.

독립적 실행은 소프트웨어가 작동하는 하부 하드웨어의 동작에서 소프트웨어를 제거하는 중요한 품질이며, 많은 서로 다른 소프트웨어 아키텍쳐들이 하드웨어 제한없이 효과적으로 구현될 수 있게 한다.

비동기 메시징은, 소프트웨어 기술이 하드웨어 설계에서의 모든 전통적인 타이밍 문제들에 독립적이도록 하기 때문에, 중요하다. 또한, 이는, "실시간(real time)"이 복수의 프로세서 사이클에 의해 정의되기보다는 임의의 실시간 소프트웨어 기능이 소프트웨어 내에 명시적으로 정의되도록 한다.

캡슐화 및 컨텍스트에 대한 둔감성은, 소프트웨어 객체들이 IC 상의 하드웨어 구현의 물리적 위치 및 특정 IC 유형에 무관하게 동일한 기능 및 성능을 가질 수 있게 한다. 하드웨어 객체가:

● 내장형 캡슐화를 가지고,

● 컨텍스트에 둔감하며,

● 독립적으로 동작하고,

● 비동기적으로 통신하며,

● 본질적으로 재배치가능하고,

● 임의의 크기가 될 수 있으며,

● 임의의 복잡성을 가질 수 있도록

구축될 수 있으면, OOP(Object Oriented Programming)을 지원하는 소프트웨어 기술을 간단히 사용함으로써 하드웨어 객체 계승(inheritance), 폴리모피즘(polymorphism) 및 모듈성(modularity)을 비교적 용이하게 생성한다. 따라서, 하드웨어 객체들은 OOP 주요부를 엄격히 따르는 소프트웨어 기술을 가진다.

하드웨어 뷰와 소프트웨어 뷰의 객체 간에 기능적인 차이는 존재하지 않는다. 모든 하드웨어 객체들은 순수하게 객체 라이브러리(Object Library) 소프트웨어 프리미티브들의 인스턴스화(instantiations)로서 생각될 수 있다. 모든 소프트웨어 객체들은 완전히 캡슐화된 하드웨어 객체들의 순수한 기술들로 생각될 수 있다. 본 발명의 실시예들에서, 하드웨어 뷰와 소프트웨어 뷰 간에 완전하고, 검증가능한, 일대일 매핑이 존재한다. 설명된 개발 시스템에서, 하드웨어/소프트웨어 2분법은 기본 하드웨어 객체들 및 프로토콜 레지스터들의 관계들 및 규칙들에 기초한 진정한 상향식 구성이다. 모든 소프트웨어 거동들 및 하드웨어 객체들의 모든 하드웨어 특정 정보는 객체 정의 내에 포함되며, 이들은 중앙에 저장되고 계승될 수 있다. 이로 인해, 모든 하드웨어 규칙들 및 관계들이 자식 인스턴스들로부터 물려받을 수 있기 때문에, 새로운 객체들이 생성될 수 있다.

도 26은 객체 A가 4개의 상호접속된 프리미티브 객체들로 이루어지며 이들중 3개는 프리미티브 유형 #1이고 하나는 유형 #2인 것을 예시한다. 객체 A가 라이브러리에 배치되면, 객체 자체는 추가 객체들에 의해 사용될 수 있게 된다. 예를 들어, 객체 A와 유사하게, 객체 B도 다른 프리미티브 객체들의 컬렉션으로 알려져 있는 반면, 객체 D는 단지 객체 A 및 B의 컬렉션이며 임의의 프리미티브 객체들을 직접적으로 인스턴스하지 않는다. 이러한 계층적 관계는 예를 들어 계승과 같이 모든 OOP 속성들을 보존한다. 그러나, 라이브러리에 저장된 소프트웨어 객체들은 프리미티브 객체들에 한정될 필요는 없다. 이러한 것은, 소정의 추가 상호접속된 프리미티브 객체들과 함께 다른 라이브러리 객체 B를 포함하는 객체 C의 정의에 예시된다.

소프트웨어 객체 계층구조는 또한 도 27에 예시되는데, 도 27은 복수의 프리미티브 객체가 소프트웨어 객체(460)에 계층적으로 수집된 것을 보여준다. 소프트웨어 객체(462)는 단순히 단일 프리미티브 객체인 반면, 소프트웨어 객체(464, 466)는 각각 2개 및 3개의 프리미티브 객체들로 이루어진다. 라이브러리에 대한 새로운 소프트웨어 객체들은, 추상화 및 계층구조의 새로운 레벨을 정의함으로써 생성될 수 있다. 모든 하드웨어 특정 규칙들 및 관계들이 자식들로부터 계승되기 때문에, 새로운 소프트웨어 객체에 대한 하드웨어 정보는 자동적으로 생성된다. 실제, 객체 라이브러리는 C++, 자바 또는 임의의 다른 OOP 언어로 개발될 수 있다.

시스템 개발(System development)

완전한 시스템의 예시적인 소프트웨어 모델이 도 28에 예시된다. 이 도면은 하드웨어 프리미티브들의 컬렉션으로부터 조립된 MPEG2 디코더 객체(470) 및 객체 라이브러리의 비디오 디코더부로부터의 사전 정의된 소프트웨어 객체들을 예시한다. 비디오 디코더 라이브러리(480)는, 움직임 객체(motion object)(472) 및 압축해제 객체(decompress object)(476)와 함께, 개별적인 프리미티브 객체들 P1 - P7을 포함한다. 움직임 객체(472)는 2개의 프리미티브 P3 및 P5로부터 생성되는 반면, 압축해제 객체(476)는 3개의 프리미티브들 P2, P4 및 P6로부터 생성된다. P6 프리미티브는 DCT ^-1 (inverse Discrete Cosine Transform) 프리미티브 객체이다. 프리미티브 P1 및 P7은 입력/출력 프리미티브 객체들이다. 디코더(470)를 조립하는 것은 또한, 소정의 실시예들에서 오프 칩 메모리를 사용하여 실행될 수 있는, 외부 프레임 저장소(476)를 사용하는 것을 포함한다. 추가 상세는 디코더의 구현을 참조하여 아래에 제공된다.

도 28의 소프트웨어 모델은 시스템의 진정한 OOP 기술(description)이며; 객체들은 독립적으로 작동하고 코드는 단순히 객체 인스턴스들의 컬렉션이다. 시스템이 이러한 소프트웨어 모델을 사용하여 기술되면, 소프트웨어의 일부로서 실행가능하고 모델을 하드웨어에 효율적으로 매핑하는데 필요한 구조 정보를 가질 수 있다.

소프트웨어의 컬렉션인 소프트웨어 시스템 및, 궁극적으로 하드웨어 객체들이 생성되면, 시스템은 RSP(450)(도 25)로 매핑되어 하드웨어 제품을 만든다. 동작시, 시스템 설계자가 시스템 모델을 설계하는 경우, 설계자는 객체 라이브러리로부터의 속성들을 직접 사용하고, 이는 다시 하부의 물리적 하드웨어 객체들의 속성들로부터 직접 생성된다. 따라서, 시스템 설계자가 원하는 시스템을 기술하는 경우, 원하는 시스템의 속성들은 내장된 하부의 물리적 하드웨어 객체들의 속성들을 이미 가질 것이다. 원하는 시스템으로부터 하부의 물리적 하드웨어 객체들로의 이러한 직접적인 대응관계는 RSP 상으로의 매핑을 상대적으로 간단한 할당 프로세스로 만든다.

예시적인 매핑 시스템이 도 29에 도시되며, 도 29는 도 28의 MPEG2 디코더 객체(470)가 도 25의 RSP(450) 상으로 매핑되어 MPEG2 디코더가 되도록 프로그램된 시스템 칩(480)을 생산하는 것을 나타낸다. 디코더 객체(470)의 프리미티브 객체들 P1 - P7 각각은 RSP(450)의 하드웨어 객체들(454, 455)중 하나에 할당된다. 프리미티브 객체들 P1 - P9가 되도록 구성되는 경우, 하부의 물리적 하드웨어 객체들(454, 455)의 속성들은 객체 라이브러리(480)(도 28)로부터 디코더(470)를 개발하는데 사용된 동일한 속성들이다. RSP(450) 상의 "1"로 표시된 프로그램된 물리적 하드웨어 객체(454) 및 디코더(470)의 객체 P1 모두는 시스템으로의 입력 메시지들을 접수하는 입력 객체들이다. 유사하게, "7"로 표시된 프로그램된 물리적 객체(455) 및 객체 P7은 디코딩된 비디오를 전달하는 출력 객체이다.

압축해제 객체(474)를 포함하는 프리미티브 객체들 P2, P4 및 P6들은 RSP(450) 상에서 "2", "4" 및 "6"으로 각각 표시된 3개의 물리적 하드웨어 객체들로 직접 매핑된다. 압축해제 객체(474)의 계층적 속성들은, 음영 영역(474)으로 도시된 RSP(450) 상에 유지된다. 유사하게, 움직임 객체(472)를 포함하는 프리미티브 객체들 P3 및 P5는 각각 "3" 및 "5"로 표시된 2개의 물리적 하드웨어 객체들로 직접 매핑된다. 움직임 객체(472)의 계층적 속성들은 음영 영역(472)으로 도시된, RSP(450) 상에 유지된다.

본 예에서 도 28의 프레임 저장소(476)는 소프트웨어 모델 내의 오프 칩인 것으로 표시되었고, 따라서 RSP(450) 상에 매핑되지 않고 대신 "프레임 저장소로/로부터(to/from frame store)"로 표시된 인터페이스 신호들을 생성한다.

RSP(450) 상의 모든 물리적 하드웨어 객체들(454, 455)이 모든 시스템 구현을 위해 사용되는 것은 아니다. 실제로, 많은 물리적 하드웨어 객체들이 사용되지 않을 가능성이 있다. 사용되지 않는 물리적 하드웨어 객체들은 턴오프되거나 또는 극히 낮은 클럭 속도로 작동되도록 설정되어 전력을 절약한다.

상술한 바와 같이, 하드웨어 객체들은 본래 소프트웨어 객체 기술, 기능 및 속성들을 포함한다. 또한, 하드웨어 객체는 추가 속성 요구조건, 구체적으로는, 하드웨어가 원하는 기능을 수행하게 하는 구성 바이너리(configuration binary) 프로그램; 필요한 하드웨어 자원의 양; 및 하드웨어가 접속되는 방법을 제어하는 접속 규칙들을 가진다. 본 발명의 일 실시예에서, 하나의 가능한 하부의 물리적 하드웨어 객체 토폴로지를 갖는 객체의 단지 한 버젼만이 존재한다. 다른 실시예들에서는, 객체를 생성하도록 (객체에 부착된 구성 바이너리를 사용하여) 프로그램될 수 있는 하부의 물리적 하드웨어 객체들의 서로 다른 많은 토폴로지들 및 혼합들이 존재한다. 후자의 경우, 객체는 서로 다른 체현(incarnation)을 가진다고 말하여 진다.

객체의 각 체현은 내장된 동일한 소프트웨어 객체를 정확하게 가지나, 각각은 특정 체현들을 선택하는 사용자에 의해 거래될 수 있는 서로 다른 성능 및 자원 활용을 나중에 생성하는 서로 다른 가능한 하드웨어 토폴로지들 및 혼합들을 가진다.

도 30은 하나의 소프트웨어 객체 체현에 부착될 수 있는 추가 정보를 예시한다. 소프트웨어 객체(490)가 예시되며, 이는 임의의 유형의 객체 기술, 예를 들어 도 28의 디코더(470)일 수 있다. 소프트웨어 객체(490)가 개발됨에 따라, 물리적 하드웨어 객체 토폴리지가 선택되고 접속 규칙들의 리스트가 생성된다. 접속 규칙들은 특정 성능 목표를 만족시키기 위해 토폴로지가 용인할 수 있는 최대 및 최소 지연들을 지정하고, 프리미티브 객체들이 RSP(450)의 하드웨어로 직접 매핑되는 경우 만족되어야 한다. 상기 하드웨어 객체를 참조하여 설명된 바와 같이, 각 하드웨어 객체와 연관될 수 있는 프로토콜 레지스터들의 수에는 실제 한계가 존재한다. 따라서, 각 하드웨어 객체에 대한 상호접속 레벨에 대한 대응하는 한계가 존재한다. 즉, RSP(450) 상의 모든 하드웨어 객체가 소프트웨어 객체에 사용된 다른 모든 하드웨어 객체에 직접 접속되는 것은 불가능하다. 따라서, 접속 규칙들의 리스트(492)가 사용되어 (예를 들어, 성능 요구조건들을 만족시키기 위해) 서로 근처에 존재해야 하는 객체들이 그렇게 될 수 있거나, 직접적으로 접속될 필요가 없는 객체들이 그렇게 접속되지 않는다는 것을 보장한다. 도 30의 접속 규칙들의 리스트(492)를 참조하면, Ad와 Ad(2개의 하드웨어 객체의 포트 "d") 간의 연결은 직접 접속, 즉 정확하게 1 홉(hop)의 접속 길이를 가져야 한다는 것을 나타낸다. 다른 객체들은 그렇게 직접 상호접속될 필요가 없고, 각각 3 또는 7개의 접속들에 의해 분리될 수 있다. 실제, 직접 접속되지 않는 하드웨어 객체들이 서로 통신할 필요가 있다면, 이들은 어드레스 또는 라우팅 커맨드들을 갖는 메시지를 원하는 하드웨어 객체에게 송신한다.

자원 리스트(494)는 RSP(450) 상의 얼마나 많은 물리적 객체들 및 어떤 유형들의 물리적 객체들이 소프트웨어 객체 체현의 토폴로지를 형성하는지를 나타낸다. 시스템이 설계되고 있는 경우, RSP(450) 상의 가용한 자원들을 추적하는 설계 규칙 확인장치가 사용될 수 있고, 시스템 설계자가 설계시 물리적으로 가용한 자원들의 수를 초과하지 못하게 한다.

접속 규칙(492) 및 자원 리스트(494) 양쪽은 계승을 사용하여 소프트웨어 객체의 자식 프리미티브들로부터 용이하게 추론될 수 있다. 프리미티브 객체들은 단지 정의된 토폴로지를 가진다.

바이너리 리스트(496)는 물리적 하드웨어 객체의 구성 레지스터들 또는 명령 메모리로 로딩되는 마이크로명령들 또는 마이크로코드의 리스트이고, 특정 물리적 하드웨어 객체가 어떻게 동작하여야 하는지를 제어한다. 예를 들어, 마이크로코드는 명령 순서대로 저장될 수 있어, 하드웨어 객체가 개시되는 경우, 판독된 제1 명령은 하드웨어 객체가 수행하길 원하는 제1 명령이다.

시스템 소프트웨어 객체 모델이 RSP(450) 상의 하드웨어 객체들과 동형(isomorphic)이기 때문에, 구성된 RSP(450)는 시스템 모델에서 시뮬레이션된대로 정확하게 동작할 것이다.

실제로, 바이너리 리스트(496)는 통상적으로 소정 유형의 메모리에 저장될 것이며, 소정 유형의 메모리는 EEPROM, 플래시 또는 다른 유형의 ROM 또는 RSP(450) 상에 위치되거나 또는 그 밖에 위치되는 다른 유형의 메모리이다. RSP에 전력이 공급되는 경우, 초기화 프로세스는 먼저 모든 하드웨어 객체들을 초기 상태로 초기화시킨다. 하나의 물리적 하드웨어 객체는 자동적으로 초기 명령들을 로딩할 기능이 되도록 리셋 시에 구성될 수 있다. 그 후 초기 명령들은, 상위 레벨 바이너리 리스트(496)가 RSP(450)로 로딩될 수 있게 실행된다. 바이너리 리스트는 상술한 메시지 패킷 프로토콜을 사용하여 개별적인 하드웨어 객체들로 배포될 수 있다. 바이너리들의 제1 부분이 그들의 개별적인 객체들로 로딩되면, 객체들은 동작하기 시작하며, 제1 입력 데이터를 대기한다.

완전히 프로그램된 시스템을 생성하는데 사용되는 프로세스들을 설명하는 흐름도가 도 31에 예시된다. 프로세스(510)에서 문제를 그 구성요소 부분들로 분할함으로써 흐름(500)이 시작한다. 다음, 라이브러리 객체들이 프로세스(520)에서 설계 시스템으로 반입된다. 설계가 개발되고 있는 동안, 설계자는 판정(530) 블럭에서 라이브러리 내에 올바른 소프트웨어 객체들이 존재하는지를 결정한다. 필요한 객체들이 존재하지 않으면, 예를 들어 객체가 아직 존재하지 않거나 또는 새로운 성능 체현이 필요하면, 설계자는 프로세스(532)에서 이들을 생성하고 새롭게 생성된 객체들을 라이브러리에 저장할 수 있다. 설계가 완료되고 모든 필요한 객체들이 라이브러리에 포함된 후, 프로세스(540)에서 설계가 테스트된다. 설계는 프로세스(550)에서 검사된다. 설계가 설계 테스트를 통과하지 못하면, 예를 들어 접속 규칙들이 만족될 수 없다면, 흐름(500)은 다시 되돌아가고 새로운 객체 체현들이 생성될 수 있고 설계가 테스트된다. 설계가 완료되면, 프로세스(560)에서 상술한 바와 같이, RSP(450)로부터의 하드웨어 제약 리스트가 프로그램된 RSP로 매핑될 설계 특징과 일치된다.

본 발명의 실시예들은, RSP(450) 상의 하드웨어 객체들의 컬렉션이 대량 병렬구조로 비동기적으로 작동하기 때문에, 특히 높은 데이터 처리량 응용에 매우 적합하다. 이는 복잡한 알고리즘들을 사용하여 많은 양의 데이터를 다루는 매우 큰 시스템에 대해 믿을 수 없는 잠재력을 생성한다. 특히 소정의 적합한 잠재적 응용들은, 예를 들어 비디오 인코딩용 움직임 추정, 고해상도 비디오 인코딩 및 프로세싱, 레이저 기록 장치들을 위한 래스터 알고리즘들, 고속 무선 네트워크들을 위한 가속기들, 상당히 안전한 암호화, 저장 영역 네트워크들, HDTV 비디오 스케일링, 802.13 및 802.11g에 대한 FEC 및 기타 무선 프로토콜, SNORT 칩입 검출, 및 디스플레이 레이트 변경을 위한 일시적 비디오 보간을 포함한다.

본 발명의 실시예들의 주요 태양은, 고성능 집적 회로들을 구축하고 단지 소프트웨어를 사용하여 집적 회로들을 변경시키는 본래의 능력을 구비한 완전성(completeness)이다. 완전성이란, 소프트웨어 하드웨어 공동 설계 문제가 단지 소프트웨어 기술(description)을 사용함으로써 제거된다는 것을 의미한다.

본 발명의 실시예들을 사용하면, 소프트웨어 뷰 및 하드웨어 뷰, 및 그들의 구현은 하나이고 동일하다. 이로 인해 개발 시스템의 사용자는 표준 툴 및 언어들을 사용하여 프로그램들을 기록하고 그 후, 수반하는 성능 이점을 가지고, 그들을 하드웨어로 직접 구현한다.

본 발명의 실시예들의 사용자들은 임의의 하드웨어 지식 또는 경험을 가질 필요가 없다. 그러한 사용자는 단지, 주문형 IC만이 오늘날 제공할 수 있는 매우 고성능 시스템들만큼 복잡할 수 있는, 시스템을 생성하도록 소프트웨어를 기록 또는 처리한다. 시스템이 소프트웨어로 정의되면, 소프트웨어 정의가 사용되어 미리 존재하는 물리적 하드웨어 객체들의 컬렉션을 사용하여 생성되는 범용 IC를 구성한다. 객체들의 소프트웨어 라이브러리에 연결된, RSP, 고유의 범용 칩의 조합으로 인해 사용자는 오늘날 툴들을 사용하여 많은 성능을 구비하거나 또는 거의 쉽게 설계될 수 없는 시스템을 빨리 설계하고 테스트할 수 있다.

예시적인 구현

도 32, 도 33, 도 34 및 도 35는 비교적 복잡한 객체가 간단한 객체들을 사용하여 어떻게 구축될 수 있는지에 대한 예를 나타낸다. 예시적인 객체는, 2개의 스트림들의 필터링된 버젼을 생성하기 위해 2개의 스트림들을 함께 컨벌루션하는(convolve) 것이다. 시간 영역에서의 컨벌루션은 주파수 영역에서의 승산과 동등하고, 무선 통신 시스템들에서와 같이, 복수의 필터가 캐스케이드되는 응용들에 사용된다. 설계의 목적은 동일한 값을 많은 구성요소 객체들에게 동시에 방송하는 전역 접속들을 가질 필요없이 하나 초과의 하드웨어 승산기가 바빠질 수 있도록 컨벌루션 객체를 생성하는 것이다.

도 32는 컨벌루션 프리미티브 객체를 보여준다. 3개의 입력 포트들(u _i , w _i , y _i 로 표시됨) 및 3개의 출력 포트들(w _i+1 , u _i+1 , y _i+1 로 표시됨)를 형성하는 6개의 프로토콜 레지스터들이 존재한다. 하드웨어 객체 내의 회로는 하나의 하드웨어 승산기 및 하나의 가산기이다. 하드웨어 객체 내의 접속들은 다음 동작을 수행하도록 구성된다:

도 32는 또한 입력 및 출력 포트들 및 "CP"로 표시된 프리미티브를 예시하는 객체의 개략적 뷰를 보여준다.

도 33은 도 32의 컨벌루션 프리미티브 객체에 대한 의사 코드를 보여준다. 포트들은 CHANNEL 유형의 INPORT 또는 OUTPORT 접속들인 것으로 선언된다. 로컬 변수들 ui, wi 및 yi는 정수형(type integer)인 것으로 선언된다. 절차 내의 제1 코드 라인은 채널 a와 채널 b의 결합 기능이다. 결합 기능은 양쪽 채널들 a 및 b가 유효 입력값들을 가질 때까지 완료되지 않는다. 채널 a 상에서 수신된 값은 변수 ui에 할당되고 채널 b 상에서 수신된 값은 변수 wi에 할당된다. 다음 2개 라인들은 ui 및 wi를 각각 출력 채널들 d 및 e로 복사한다. 라인 "c→yi"는 승산 하드웨어의 출력을 갖는 다른 결합 기능과 동등하고, "결합(a→ui, b→wi, c→yi)"를 사용함으로써 제1 라인에 포함될 수 있으나, 도 33에 도시된 2개를 분리함으로써, 채널 c 상의 입력이 아직 발생되지 않더라도 승산 하드웨어가 진행할 수 있게 된다. 최종 라인은 값 ui*wi+yi가 채널 f 상의 출력이라는 것을 나타낸다.

도 34는 본 예에서 다른 프리미티브 객체를 보여준다. 2개의 입력 포트(u _i 및 w _i 로 표시됨) 및 3개의 출력 포트(w _i+1 ,u _i+1 및 y _i+1 로 표시됨)을 형성하는 (6개의 가용한) 프로토콜 레지스터들중 5개가 존재한다. 하드웨어 객체 내의 회로는 단지 하나의 하드웨어 승산기이다. 하드웨어 객체 내의 접속들은 다음의 동작들을 수행하도록 구성된다.

도 34는 또한 입력 및 출력 포트들 및 "승산(multiply)"에 대한 약자인 "X"로 표시된 프리미티브를 예시하는 객체의 개략적 뷰를 나타낸다.

도 35는 도 32 및 34의 2개의 프리미티브 객체들이 토폴로지에서 어떻게 결합하여 컨벌루션 객체를 생성하는지를 나타낸다. 주의할 점은 모든 접속들이, 전역 배선의 접속에 의한 것이 아니라, 배선을 간단하게 하고 성능이 프리미티브 객체들에 의해 결정될 수 있게 하는 지점-대-지점이라는 것이다.

컨벌루션 객체의 기능은 아래의 식에 의해 주어진다.

도 35의 예에서, 간단히 하기 위해 w(i) 및 u(i)는 i>3에 대해 0이나, 실제 스트리밍 시스템에서는 첫번째 4개보다 많은 입력 값들이 사용될 수 있다고 가정한다. 시리즈를 확장하면, 출력 항들 각각은 다음의 수식들의 세트로 주어진다.

도 35의 토폴로지가 이러한 항들을 올바르게 생성한다는 것을 보여주기 위해, 먼저 출력 y(0)를 검사한다. 출력 y(0)이, 원하는 경우 단순히 u(0)*w(0)인 프리미티브 객체(600)의 출력 y _{i +1} 에 의해 생성된다. 다음으로 출력 y(1)을 검사한다. 출력 y(1)은, 함수

인 프리미티브 객체(601)의 출력 y _{i +1} 에 의해 생성된다.

상기 수식에서, 위첨자는 특정 객체가 해당 출력을 생성한다는 것을 나타낸다. 객체(600) 및 객체(602)는 다음과 같이 동작한다.

마지막 4개 식을 결합시키면 다음과 같이 보여진다.

이러한 가우시안 소거 프로세스는 출력들 y(2) ... y(6)에 대한 나머지에 대해서도 계속된다.

상술한 시스템의 구현은 상기 개시의 측면에서 간단히 생성된다. 통상의 경우처럼, 구현의 상세는 시스템 설계자에게 달려있다. 특정 하드웨어 객체들, 프로토콜 레지스터들, 메시지 포맷들 등에 대한 개별적인 선택은 구현에 특정적이고 경험적으로 발견될 필요가 있다. 본 발명은 종래의 방법들과 비교할 경우 시스템들이 설계되고 구현되는 방식에 있어 선구자적인 패러다임 이동을 표현한다.

따라서, 하드웨어 및 소프트웨어 객체들을 포함하는 집적 회로 개발 시스템에 대한 특정 실시예들이 설명되었더라도, 그러한 특정 참조들이 본 발명의 범위에 대한 제한들로 생각되는 것을 의도하지 않으며, 오히려 범위는 다음의 청구의 범위 및 그들의 등가물에 의해 결정된다.