KR100775547B1 - 구성가능한 프로세서를 설계하기 위한 프로세서 자동 생성시스템 및 방법 - Google Patents

Abstract

구성가능한 RISC 프로세서는 고성능 고정 및 가변 길이 인코딩으로 사용자-정의가능한 명령어를 구현한다. 정의하는 신규 명령어 세트의 프로세스는 사용자로 하여금 신규 명령어들을 더하고 그것들을 신속하게 평가하도록 하며, 다중 명령어 세트를 유지하고, 그들 사이에서 용이하게 스위칭되도록 하는 툴에 의하여 지지된다. 표준화된 언어는 목표 명령어 세트의 구성가능한 정의, 상기 명령어 세트를 구현하는데 필요한 하드웨어의 HDL 기술 및 검증과 응용프로그램 개발을 위한 개발 툴을 개발하는데 사용됨으로써, 설계 프로세스에 있어 고도의 자동화를 가능하게 한다.

Description

구성가능한 프로세서를 설계하기 위한 프로세서 자동 생성 시스템 및 방법{AUTOMATED PROCESSOR GENERATION SYSTEM FOR DESIGNING A CONFIGURABLE PROCESSOR AND METHOD FOR THE SAME}

본 발명은 마이크로프로세서 시스템에 관한 것이다. 보다 특별히, 본 발명은 상기 시스템 내의 프로세서가 그들의 설계시에 특별한 응용프로그램에 대한 그들의 적합성을 개선하도록 배열 및 강화된 한개 이상의 프로세서를 포함하는 응용프로그램 솔루션의 설계에 관한 것이다. 또한 본 발명은 응용프로그램 개발자가 사용자-정의된 프로세서 상태를 처리하는 신규 명령어를 포함하는 현존하는 명령어 세트 구조에 신규 명령어와 같은 명령어 확장을 빠르게 개발할 수 있고 응용프로그램 실행 시간 및 프로세서 사이클 시간까지 확장의 영향을 즉시 측정할 수 있는 시스템에 관한 것이다.

프로세서는 전통적으로 설계하거나 수정하기가 어렵다. 이러한 이유로, 대부분의 프로세서를 포함하는 시스템은 일단 일반용도로 설계 및 입증된 다음 오랜 시간에 걸쳐 다양한 응용프로그램에 의해 사용된 것을 사용한다. 이처럼, 특별한 응용프로그램에 대한 그들의 적합성은 항상 이상적인 것은 아니다. 종종 프로세서가 특별한 응용프로그램의 코드를 더 잘 실행하도록(예를 들어, 더 빨리 실행하고, 더 적은 전력을 소비하고, 비용이 덜 들게) 수정하는 것이 적절할 것이다. 하지만, 그것은 어렵고 따라서, 시간, 비용 및 심지어 현존하는 프로세서 설계의 수정의 위험성이 높아서 이것은 통상적으로 행해지지 않는다.

종래 기술이 구성 가능하도록 하는 어려움을 더 잘 이해하기 위해서, 그것의 개발단계를 고려하라. 우선, 명령어 세트 구조(ISA)가 개발된다. 이것은 본래 이전에 행해지고 많은 시스템에 의해 수십년동안 사용된 단계이다. 예를 들어, 인텔 펜티엄

프로세서는 1970년대 중반에 소개된 8008 및 8080에 까지 거슬러 올라가 그것의 명령어 세트의 자취를 조사한다. 기정된 ISA 설계 규약에 기초한 본 과정에서, ISA 명령어, 구문(syntax)등이 개발되고 어셈블러, 디버거, 컴파일러등과 같은 ISA를 위한 소프트웨어 개발 툴이 개발된다. 그다음, 특별한 ISA를 위한 시뮬레이터가 개발되고 다양한 벤치마크가 ISA의 성능을 평가하기 위해 실행되며, 상기 ISA는 평가의 결과에 따라 교정된다. 어떤점에서, ISA는 만족스럽다 볼 수 있으며, ISA 과정은 충분히 개선된 ISA 규격, ISA 시뮬레이터, ISA 검증 슈트 및 예를 들어 어셈블러, 디버거, 컴파일러등을 포함하는 개발 슈트와 함께 완료될 것이다.

다음으로, 프로세스 설계에 대해 설명하겠다. 프로세서는 여러해의 유효 수명을 가질 수 있고, 이 프로세서는 또한 아주 드물게 행해진다--통상적으로, 하나의 프로세서는 일단 설계되면 몇몇 시스템에 의해 수년동안 사용될 것이다. ISA, 그것의 검증 슈트와 시뮬레이터 및 다양한 프로세서 개발 목적을 부여받은 프로세서의 마이크로구조가 설계, 시뮬레이션 및 교정된다. 일단 마이크로구조가 완성되면, 그것은 하드웨어 기술 언어(HDL)내에 제공되고, 마이크로구조 검증 슈트는 HDL 구현의 타당성을 입증하기 위해 개발 및 사용된다(이후에 더 상세히 설명됨). 그다음, 여기서 설명된 명세서의 과정과는 대조적으로, 자동 설계 툴은 HDL 기술에 기초한 회로를 만들고 그것의 성분요소를 배치 및 정해진 경로로 보낼 것이다. 레이아웃은 다음으로 칩 영역의 이용 및 타이밍을 최적화하도록 교정될 수 있다. 대안적으로, 부가적인 명세서의 과정은 HDL 기술에 기초한 평면도(floorplan)를 만들고 회로설계에서 HDL을 개조한 다음 수동 및 자동으로 타당성을 입증하고 상기 회로들을 설계한다. 마지막으로, 상기 레이아웃은 확실히 그것을 자동툴을 이용하는 회로와 매치시킴으로써 타당성이 입증되고 회로는 레이아웃 파라미터에 따라 타당성이 입증된다.

프로세서 개발이 완료된 후에, 전체 시스템이 설계된다. ISA 및 프로세서의 설계와는 달리, (이제부터 프로세서를 포함하는 칩의 설계를 포함할 수 있는)시스템 설계는 상당히 평범하고 시스템은 통상적으로 연속적으로 설계된다. 각 시스템은 특별한 응용프로그램에 의해 비교적 짧은 기간(일년 또는 이년)동안 사용된다. 비용, 수행, 전력 및 기능성과 같은 기정된 시스템의 목표; 기존 프로세서의 명세; (보통 프로세서 공급자와 밀접하게 연관된) 칩 파운드리의 명세에 기초한 전체 시스템이 설계되고, 프로세서는 설계목표에 맞게 선택되며, 칩 파운드리가 선택된다(이것은 프로세서 선택과 연관된다).

그다음, 선택된 프로세서, ISA 및 파운드리 및 (선택된 파운드리를 위한 표준 셀 라이브러리뿐만 아니라)기존에 개발된 시뮬레이션, 검증 및 개발 툴을 부여받은 시스템의 HDL 구현이 설계되고, 검증 슈트가 시스템 HDL 구현을 위해 개발되 며 상기 구현이 검증된다. 다음으로, 시스템 회로가 정해진 경로상에 통합, 배치 및 정해진 경로에 보내지고, 레이아웃 및 타이밍이 다시 최적화된다. 마지막으로, 보드가 설계 및 레이아웃되고, 칩이 제작되며 상기 보드가 조립된다.

종래 기술 프로세서 설계의 다른 어려움은 임의의 소정 응용프로그램은 단지 한가지 특징의 특별한 세트를 필요로하고, 상기 응용프로그램에 필요치 않은 여러 특징을 갖는 프로세서는 지나치게 비싸고, 더 많은 전력을 소비하며 제조하기도 훨씬 어렵기 때문에 단순히 모든 응용프로그램을 감당하는 더 많은 특징을 갖는 전통적인 프로세서를 설계하는 것은 적절치 못하다는 사실에서 비롯된다. 게다가 프로세서가 초기에 설계될 때, 응용프로그램의 모든 목표를 안다는 것은 불가능하다. 프로세서 수정 과정이 자동화될 수 있고 신뢰할만 하다면, 응용프로그램 솔루션을 고안하는 시스템 설계자의 능력이 충분히 향상될 것이다.

예를 들어, 복잡한 프로토콜을 이용하는 채널의 도처로 데이터를 전송하고 수용하도록 설계된 디바이스를 고려해 보자. 프로토콜은 복잡하기 때문에, 그 처리가 고정배선, 예를 들어 조합, 논리회로내에 완전히 이상적으로 수행될 수 없고, 대신에 프로그래밍 가능한 프로세서가 프로토콜 프로세싱을 위한 시스템에 채용된다. 또한 프로그래밍가능성은 버그 수정을 허용하고 추후에 프로토콜이 신규 소프트웨어를 이용하여 명령어 메모리를 로딩함으로써 수행되도록 업그레이딩한다. 하지만, 전통적인 프로세서는 아마도 (상기 프로세서가 설계된 때에도 응용프로그램이 존재하지 않을 수 있는) 이 특별한 응용프로그램을 위하여 설계되지 않았고, 부가적인 프로세서 논리를 가진 한개 또는 수개의 명령어을 이용해 행해질 수 있는 많은 명령어에 대한 요구를 수행하는 것이 필요하다.

프로세서는 쉽게 개선될 수 없기 때문에 많은 시스템 설계자는 개선하려 들기보다 이용 가능한 일반용 프로세서의 비효율적인 순수한-소프트웨어 해를 만드는 방법을 택한다. 비효율성은 솔루션이 더 느려지거나 더 많은 전력을 필요로하고 또는 더 많은 비용이 들 수 있는 결과를 초래한다(예를 들어, 그것은 충분한 속도로 프로그램을 실행하기 위해 더욱 크고 강력한 프로세서를 필요로 할 수 있다). 다른 설계자들은 보조처리장치와 같은 응용프로그램을 위해 설계한 특수-목적 하드웨어의 프로세싱 요건의 얼마간을 제공하기위해 선택하고, 그다음 프로그래머 코드 업(programmer code up)이 상기 프로그램내의 다양한 점에서의 특수-목적의 하드웨어에 접근하도록 한다. 하지만, 프로세서와 이러한 특수-목적 하드웨어 사이의 데이터를 전송하는 시간은 단지 상당히 큰 작업 유닛이 특수-목적 하드웨어를 이용함으로써 덜 수 있는 시간이 전문화된 하드웨어에서 및 으로부터 데이터를 전송하기위해 필요한 부가 시간보다 크도록 충분히 속도를 높일 수 있기 때문에 시스템 최적화를 위한 본 접근방법의 유용성을 제한한다.

통신 채널 응용프로그램에서, 프로토콜은 암호화, 오차-수정 또는 컴프레션/디컴프레션(compression/decompression) 프로세싱을 필요로 할 것이다. 이러한 프로세싱은 종종 프로세서의 더 큰 워드보다 개별적 바이트로 연산할 것이다. 계산용 회로가 다소 적절할 수 있지만, 프로세서가 각 바이트를 추출하기 위한 필요성은 그것을 연속적으로 처리한 다음 상당한 부담을 더한 바이트를 재압축 한다.

매우 특별한 예로서, 표1에 도시된 규칙을 이용하는 허프만 해독을 고려해 보자(유 사한 부호화가 MPEG 압축 표준에 이용된다).

값 및 길이 모두는 계산되어야 하며, 그래서 길이 바이트는 스트림내에 해독될 다음 소자의 시작을 찾아내기 위해 연장될 수 있다.

종래 명령어 세트를 위해 이것을 코드화하기 위한 다수의 방법이 있지만, 그들 모두는 많은 테스트가 행해져야 하기 때문에 많은 명령어를 필요로 하고, 조합 논리를 위한 단일 게이트 지연과는 대조적으로, 각 소프트웨어 구현은 다수의 프로세서 사이클을 필요로 한다. 예를 들어, MIPS 명령어 세트를 이용하는 효율적인 종래 기술의 구현은 여섯번의 논리적인 연산, 여섯개의 조건부 분기 명령, 하나의 산술 연산 및 관련 레지스터 로드를 필요로 한다. 하나의 논리 연산, 여섯개의 조건부 분기 명령, 산술 연산 및 관련 레지스터 로드를 필요로 하는 편리하게 설계된 명령어 세트를 이용하는 코딩이 더 낫지만, 여전히 시간의 관점에서 볼때는 사치스럽다.

프로세서 자원의 관점에서, 이것은 너무 비싸서 256-엔트리 검색 테이블이 일련의 바이트-바이-바이트(bite-by-bite) 비교처럼 프로세스를 코딩하는 대신 통상적으로 이용된다. 하지만, 256-엔트리 검색 테이블은 충분한 공간을 확보하고 또한 액세스할 많은 사이클일 수 있다. 더 긴 Huffman 부호화을 위해, 테이블 크기는 터무니 없이 커질 수 있고, 더 복잡하고 느린 코드를 야기한다.

프로세서에서 다루기 쉬운 특정 응용프로그램 요건의 문제에 대한 가능한 솔루션은 프로세서의 기능을 개선하고 그 기능을 맞추기 위해서 쉽게 수정 및 확장될 수 있는 명령어 세트 및 구조를 갖는 구성가능한 프로세서를 이용하는 것이다. 구성가능성은 설계자가 그녀의 제품을 위해 부가적인 기능이 필요한지 또는 얼마나 많은 부가적인 기능이 필요한지를 명확히 하는 것을 허용한다. 구성가능성의 가장 간단한 종류는 특징이 존재하거나 부재하는 두가지 선택이 있다. 예를 들어, 프로세서는 부동-소수점 하드웨어를 구비하거나 없이 제공될 것이다.

유연성은 더 좋은 등급의 구성 선택에 의해 개선될 수 있다. 예를 들어, 프로세서는 시스템 설계자가 레지스터 파일내의 레지스터의 수, 메모리 폭, 캐시 크기, 캐시 결합(cache associative)등을 명확히 하는 것을 허용한다. 하지만, 이 선택은 여전히 시스템 설계자들이 바라는 맞춤성(customizabiliy)의 수준에 도달하지 못한다. 예컨대, 상술한 Huffman 해독의 예처럼, 종래 기술에서 시스템 설계자들이 해독을 수행하기 위해 특정 명령어를 포함하는 것을 좋아했는지에 대해 알려진 바는 없지만, 예를 들어

huff8 t1, t0

여기서 결과적으로 가장 중요한 8바이트는 해독된 값이고 적어도 중요한 8바이트는 길이이다. 이전에 상술한 소프트웨어 구현과는 대조적으로, Huffman 해독의 직접적인 하드웨어 구현은 꽤 단순하다--명령어를 해독하기 위한 논리는 명령어 해독의 배타적인 적정한 조합 논리 기능을 위해 대략 30개 또는 통상적인 프로세서의 게이트 수의 0.1%보다 적은 게이트를 표현하고, 단일 사이클내의 특수-목적 프로세서 명령어에 의해 계산되어 단지 사용하는 범용 명령어에 더하여 4 내지 20의 개량 인자를 재현한다.

구성가능한 프로세서 생성에서 종래 기술 성과는 일반적으로 기정된 하드웨어 기술과 함께 이용되는 논리 통합 및 추상적 기계 기술(abstract machine description)로부터의 컴파일러 및 어셈블러의 자동 재목표화의 두가지 범주로 나뉜다. 제1범주에서 Synopsys DW8051 프로세서, ARM/Synopsys ARM7-S, Lexra LX-4080, ARC 구성가능한 RISC 코어; 및 다소간 Synopsys 통합가능한/구성가능한 PCI 버스 인터페이스와 같은 통합가능한 프로세서 하드웨어 설계는 쇠락했다.

상술한 바중에서, Synopsys DW8051은 현존하는 프로세서 구조의 이원으로 양립 가능한(binary-compatible) 구현 및 적은 수의 통합 파라미터, 예를 들어, 파라미터 rom_addr_size, 내부 타이머, 일련 포트의 변화가능한 수(0-2) 및 6 또는 13 소스를 지지하는 개입중단 유닛에 의해 결정된 내부 램, 롬 어드레스 영역 128 또는 256바이트를 포함한다. Synopsys DW8051 구조는 약간 변화할 수 있고, 그것의 명령어 세트 구조의 변경은 불가능하다.

ARM/Synopsys ARM7-S 프로세서는 현존하는 구조 및 마이크로구조의 이원으로 양립가능한 구현을 포함한다. 그것은 높은-성능 또는 낮은-성능 승수의 선택 및 디 버그와 내부회로 모방 논리의 포함으로 이루어진 두개의 구성가능한 파라미터를 갖는다. ARM7-S의 명령어 세트 구조의 변화는 가능하지만, 그들은 현존하는 구성가능성 없는 프로세서 구현의 부분집합이어서 신규 소프트웨어는 필요로하지 않는다.

Lexra LX-4080 프로세서는 표준 MIPS 구조의 구성가능한 변화를 가지고 명령어 세트 확장을 위한 소프트웨어 지원은 갖지 않는다. 그것의 선택은 응용프로그램-특정 연산을 이용하는 MIPS ALU 연산코드의 확장을 허용하는 주문형 엔진 인터페이스(custom engine interface); 레지스터 소스 및 레지스터 또는 16 비트-와이드 즉석 소스를 포함하는 내부 하드웨어 인터페이스; 간단한 메모리 처리 유닛 선택; 세개의 MIPS 보조처리장치 인터페이스; 캐시, 스크래치-패드 램 또는 롬에 유연한 로컬 메모리 인터페이스; 프로세서 자신의 로컬 버스에 주변 함수 및 메모리를 연결하는 버스 제어기; 및 구성가능한 깊이의 쓰기 버퍼를 포함한다.

ARC 구성가능한 RISC 코어는 목표 기술 및 클럭 속도에 기초한 온-더-플라이(on-the-fly) 게이트 계수 설정, 명령어 캐시 구성, 명령어 세트 확장, 타이머 선택, 스크래치패드 메모리 선택 및 메모리 제어기 선택을 구비한 사용자 인터페이스; 메모리에 블록 이동을 이용한 로컬 스크래치패드 램, 특수 레지스터, 최고 16개의 여분 상태 선택, 32 ×32 비트 스코어보딩된 멀티플라이 블록, 단일 사이클의 32 비트 버렐-쉬프터/로테이트 블럭, 정상화(첫번째 비트를 찾음) 명령어, 명령 버퍼(레지스터 파일에서는 아님)에 직접 쓰는 결과, 16비트 MUL/MAC 블록과 36비트 누산기, 및 선형 산술을 이용하는 로컬 SRAM에 슬라이딩 포인터 접근과 같은 선발 가능한 선택을 이용하는 명령어 세트; VHDL의 메뉴얼 편집에 의해 정 의된 사용자 명령어를 갖는다. ARC 설계는 명령어 세트 기술 언어를 실행하기 위한 설비를 가지고 있지 않고 그것은 구성된 프로세서에 특정한 소프트웨어 툴을 생성하지도 않는다.

Synopsys 구성가능한 PCI 인터페이스는 시설, 구성 및 통합 활동에 대한 GUI 또는 명령 회선 인터페이스; 구성에 기초한 선발된 설계 파일(예를 들어, Verilog 대 VHDL); 조합 정당성을 검사를 이용한 구성값을 위한 파라미터 세팅 및 사용자의 프롬프팅, 및 HDL의 사용자 갱신 및 HDL 소스 파일의 무편집을 이용한 HDL 생성; 및 I/O 패드, 기술-독립 제약조건과 통합 스크립트, 패드 삽입 및 기술-특수 패드용 프롬프트, 및 기술-독립 공식에서 기술-종속 스크립트로의 번역을 선발하기 위해서 기술 라이브러리를 분석하는 사용자 인터페이스와 같은 통합 기능을 포함한다. 구성가능한 PCI 버스 인터페이스는 그것이 변수, 구성에 기초한 설비(configuration-based installation) 및 HDL 파일의 자동 수정을 구현하기 때문에 주목할만 하다.

또한, 종래의 통합 기술은 사용자의 목표 명세에 기초한 다른 맵핑을 선택하고, 속도, 전력, 영역 또는 목표 성분요소를 최적화 하기 위한 맵핑을 허용한다. 이점에서, 종래 기술에서 전체 맵핑 프로세스를 통해 설계를 하지않고 이들 방식에서 재구성한 프로세서의 효과로 피드백을 얻는것은 불가능하다. 이러한 피드백은 시스템 설계 목표가 달성될 때까지 직접적인 프로세서의 추가 재구성에 이용될 수 있다.

구성가능한 프로세서 생성 영역내의 종래 기술 작업의 제2범주(즉, 컴파일러 및 어셈블러의 자동 목표재설성)는 풍부한 학회의 연구의 영역을 포함한다; 예를 들어 Hanono등이 저술한 "AVIV 목표재설정 코드 생성내에서 명령어 선택, 자원 할당 및 스케쥴링"(코드 생성기의 자동 형성을 위해 이용되는 기계 명령어의 재현); Fauh 등이 저술한 "nML을 이용하는 명령어 세트 프로세서 서술하기(Describing Instruction Set Processors Using nML)"; Ramsay등이 저술한 "트리 매칭 및 동적 프로그래밍을 이용하는 코드 생성(Code Generation Using Tree MAtching and Dynamic Programming)"각 기계 명령어, 예를 들어 패턴 매칭과 같은 방법을 이용하는 소정 기계-독립적인 중간 양식에 의해 재현된 프로그램 연산의 순서를 이요한 첨가, 로드, 저장, 분기등과 관련된 변형을 조화시키는 알고리즘); 및 Cattell이 저술한 "코드 생성기의 공식화 및 자동 유도"(컴파일러 연구에 이용된 기계 구조의 추출 기술)을 참고하라.

일단 프로세서가 설계되면, 그것의 연산은 입증된다. 즉, 프로세서는 일반적으로 명령어 실행의 한 위상에 적합한 각 스테이지를 구비한 파이프라인을 이용하는 저장된 프로그램으로부터의 명령어를 실행한다. 따라서, 명령어의 변형이나 추가 또는 구성의 변형은 프로세서의 논리에서 널리 받아들여진 변형을 필요로해서 다양한 파이프라인 스테이지의 각각은 각각 이러한 명령어에 의해 적당한 동작을 수행할 수 있다. 프로세서의 구성은 그것이 재검증 될것과 이 검증이 변형 및 추가에 적합할 것을 요구한다. 이것은 간단한 작업이 아니다. 프로세서는 광범위한 내부 데이터 및 제어 상태를 갖는 복잡한 논리 디바이스이고, 제어 및 데이터의 조합이론 (combinatorics) 및 프로그램은 프로세서 검증에 엄격한 기술을 제공한다. 프 로세서 검증의 또 다른 어려움은 적절한 검증 툴을 개발하기 어렵다는 점이다. 검증은 종래 기술에서 자동적이지 않기 때문에, 그것의 유연성, 속도 및 신뢰성이 최적에 미치지 못한다.

게다가, 일단 프로세서가 설계 및 검증되면 그것은 그것이 쉽게 프로그래밍 될 수 없다면 특별한 쓸모가 없다. 프로세서는 일반적으로 컴파일러, 어셈블러, 링커, 디버거, 시뮬레이터 및 프로파일러를 포함하는 소프트웨어 툴의 조력으로 프로그래밍 된다. 프로세서가 변형되었을 때, 소프트웨어 툴 또한 변형되어야 한다. 명령어를 추가하는 것은 명령어가 컴파일링, 어셈블링, 시뮬레이팅 또는 디버깅될 수 없다면 좋지 않다. 소프트웨어 변형의 비용은 프로세서 수정과 관련이 있고, 개선은 종래 기술에서 유연한 프로세서 설계에서 주요한 구현이다.

따라서, 종래 기술 프로세서 설계는 일반적으로 프로세서가 특정 응용프로그램을 위하여 통상적으로 설계 또는 수정되지 않은 어려운 수준인 것으로 보여진다. 또한, 시스템 효율의 상당한 개량은 프로세서가 특정 응용프로그램을 위하여 구성 또는 확장될 수 있다면 가능하다고 보여질 수 있다. 또한, 설계의 효율성 및 효과는 프로세서 설계를 보다 우수하게 하는 전력 소비, 속도등과 같은 구현 특징에 의한 피드백을 이용할 수 있다면 개선될 수 있다. 더구나, 종래 기술에서 일단 프로세서가 수정되면, 수정후에 프로세서의 정확한 연산을 검증하기 위해서 엄청난 노력이 요구된다. 마지막으로, 종래 기술이 제한된 프로세서 구성능력을 위해 제공되지만, 그들은 구성된 프로세서와 함께 이용하기 위하여 맞춰진 소프트웨어 개발 툴의 생성을 위하여는 제공하지 못한다.

상기의 현상을 만족하는 시스템이 분명히 기술상의 진보가 이루어지는 동안, 진보가 만들어질 수 있다. 예를 들어, 특수 레지스터내에 저장된 정보에 접근 또는 수정하는 명령어를 갖는 프로세서 시스템을 위한 필요성이 있다. 즉, 습득 가능한 명령어의 범위를 제한해서 많은 성능의 진보가 달성될 수 있는 프로세서 상태이다.

또한, 신규 응용프로그램-특정 명령어를 발명하는 것은 사이클 계수 감소, 부가적인 하드웨어 자원 및 CPU 사이클-타임 충돌 사이의 복잡한 타협을 포함한다. 다른 시도는 고도의 성능 마이크로프로세서 구현의 종종 모호한 세부파일 내에 응용프로그램 개발자를 포함하지 않는 신규 명령어를 위한 효율적인 하드웨어 구현을 얻는 것이다.

상기 시스템은 사용자의 응용프로그램을 위해 잘 맞는 프로세서를 설계하도록 사용자에게 융통성을 주지만, 하드웨어 및 소프트웨어의 상호 개발을 위해서는 성가시다. 더 완전히 이 프로그램을 이해하기 위해서, 많은 소프트웨어 설계자들이 그들의 소프트웨어 응용프로그램의 성능을 튜닝함으로서 이용되는 전형적인 접근법을 고려해 보자. 그들은 포텐셜 성능향상에 대해서 통상적으로 생각하고 그들의 소프트웨어가 그 포텐셜 성능향상을 이용하도록 수정하고, 그들의 소프트웨어 자원이 포텐셜 성능향상을 포함하는 실행가능한 응용프로그램을 생성하도록 재편집한 다음 그 포텐셜 성능향상을 평가한다. 통상적으로, 전체 프로세스는 단지 몇 분많에 완료된다. 이것은 사용자가 자유롭고, 빠르게 아이디에 대한 실험적인 시도와 그 아이디어를 유지하거나 버릴수 있는 실험을 할 수 있게 한다. 소정의 경우에, 포텐셜 아이디어를 바로 평가하는 것은 복잡하다. 사용자는 많이 변화하는 상황에서 그 아 이디어를 테스트하기를 원할 것이다. 이러한 경우에, 사용자는 복잡한 응용프로그램에 대해 종종 포텐셜 성능향상을 포함하는 하나의 원래의 버전과 다른 버전등 다양한 버전을 유지할 수 있다. 소정의 경우에, 포텐셜 성능향상은 상호작용할 것이고, 사용자는 포텐셜 성능향상의 다른 부분집합을 이용하는 각 응용프로그램의 두개 이상의 복사본을 가지고 있을 것이다. 다양한 버전을 지님으로써, 사용자는 서로 다른 상황하에서 쉽게 다른 버전을 반복적으로 테스트 할 수 있다.

구성가능한 프로세서의 사용자는 소프트웨어 개발자들이 전통적인 프로세서의 소프트웨어를 개발하는 방식과 유사한 방법으로 상호작용하도록 하드웨어와 소프트웨어를 연계하여 개발하는 것을 좋아한다. 통상의 명령어에 구성가능한 프로세서를 더하는 사용자의 경우를 고려해 보자. 사용자는 상호작용하도록 포텐셜 명령어에 그들의 프로세서를 더하고는 것을 좋아하고 그들의 특별한 응용프로그램의 명령어들을 테스트 및 평가한다. 종래 기술의 시스템의 경우 이것은 다음의 세가지 이유 때문에 어렵다.

우선, 포텐셜 명령어를 제안한 후에, 사용자는 명령어을 이용할 수 있는 컴파일러와 시뮬레이터를 얻기 전에 한시간 이상을 기다려야 한다.

둘째, 사용자가 많은 포텐셜 명령어를 이용해 실험하기를 바랄때, 상기 사용자는 각각에 대해 소프트웨어 개발 시스템을 형성 및 유지해야 한다. 소프트웨어 개발 시스템은 매우 클 수 있다. 많은 버전을 유지하는 것은 관리가 불가능해질 수 있다.

끝으로, 소프트웨어 개발 시스템은 전체 프로세서를 위해 구성된다. 그것은 서로 다른 공학자들 사이의 개발 프로세스를 분리하는 것을 어렵게 만든다. 두 개발자가 특별한 응용프로그램을 위해 작업하는 예를 생각해 보라. 한 개발자는 프로세서의 캐시 특징을 결정하는 책임이 있고, 다른 개발자는 관습화된 명령어를 추가하는 책임이 있을수 있다. 두 개발자의 작업이 관련되는 동안, 각 부분은 충분히 분리가능해서 각 개발자는 독립적으로 자신의 작업을 수행할 수 있다. 캐시 개발자는 초기에 특별한 구성을 제안할 것이다. 다른 개발자는 그 구성을 가지고 시작하여 각각의 포텐셜 명령어를 위한 소프트웨어 개발 시스템을 만드는 몇가지 명령어를 실험한다. 이제부터, 사익 캐시 개발자는 제안된 캐시 구성을 수정한다. 다른 개발자는 자신의 각각의 구성이 본래의 캐시 구성을 가지고 있게 때문에 이제부터 자신의 구성중 모든 것을 다시 만든다. 한 가지 프로젝트를 위해 작업하는 많은 개발자들에게, 서로 다른 구성을 조직하는 것은 금방 처리불가능해질 수 있다.

본 발명은 종래 기술의 세가지 문제점을 극복하고 프로세서의 하드웨어 구현 및 동일한 구성의 명세로부터 프로세서를 프로그래밍 하기 위한 소프트웨어 개발 툴 세트 둘 다를 생성함으로써 자동적으로 프로세서를 구성할 수 있는 시스템을 제공하려는 목적을 갖는다.

본 발명의 다른 목적은 다양한 수행 현상을 위해 하드웨어 구현 및 소프트웨어 툴을 최적화할 수 있는 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은 확장성, 이진법 선택 및 파라미트릭 수정을 포함하는 프로세서를 위한 다양한 형태의 구성을 허용하는 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은 하드웨어내에 쉽게 구현될 수 있는 언어로 프로세서의 명령어 세트 구조를 기술할 수 있는 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은 프로세서 상태를 수정하는 명령어 세트 확장을 개발 및 구현하기 위한 시스템 및 방법을 제공하는 것이다.

본 발명의 또 다른 목적은 구성가능한 프로세서 레지스터를 수정하는 명령어 세트 확장을 개발 및 구현하기 위한 시스템 및 방법을 제공하는 것이다.

본 발명의 또 다른 목적은 사용자가 신규 명령어를 추가함으로써 프로세서 구성을 변경하고 수분내에 그 특징을 평가할 수 있도록 하는 것이다.

상기의 목적들은 목표 명령어 세트, 명령어 세트를 구현하기 위해 필요한 회로의 Hardware Description Language 기술 및 프로세서를 위한 소프트웨어를 생성하고 상기 프로세서를 검증하기 위해 이용되는 컴파일러, 디버거 및 시뮬레이터과 같은 개발 툴의 구성된 정의를 개발하기 위해 표준화된 언어내에서 관습화된 프로세서 명령어 세트 선택 및 확장의 기술을 이용하는 자동 프로세서 생성 시스템을 제공함으로써 달성된다. 프로세서 회로의 구현은 면적, 전력 소비 및 속도와 같은 다양한 현상을 위해 최적화 될 수 있다. 일단 프로세서 구성이 개발되면, 그것은 테스트되고 반복적으로 프로세서 구현을 최적화 하기 위해 수정되는 시스템에 입력된다.

본 발명에 따른 자동 프로세서 생성 시스템을 개발하기 위해서, 명령어 세트 구조 기술 언어가 정의 되고 어셈블러, 링커, 컴파일러 및 디버거와 같은 구성가능한 프로세서/시스템 구성 툴 및 개발 툴이 개발된다. 이것은 툴의 대부분이 관례이 지만, 그들이 ISA 기술로부터 자동적으로 구성될 수 있도록 만들어 져야 하기 때문에 개발 프로세스의 일부이다. 설계 프로세스의 이 부분은 통상적으로 자동 프로세서 설계 툴 그 자체의 설계자 또는 제조자에 의해 행해진다.

본 발명에 따른 자동 프로세서 생성 시스템은 아래와 같이 작동한다.자, 예를 들어 시스템 설계자는 구성된 명령어 세트 구조를 개발한다. 즉, 이전에 개발된 정의 및 툴을 이용하는 특정 ISA 설계 목표를 따르는 구성가능한 명령어 세트 구조가 개발된다. 그다음, 개발 툴 및 시뮬레이터가 이 명령어 세트 구조를 위해 구성된다. 구성된 시뮬레이터를 이용하는 벤치마크는 구성가능한 세트 구조 및 평가 결과에 기초한 교정된 코어의 효과를 평가하기 위해서 실행된다. 일단 구성가능한 명령어 세트 구조가 만족할 만한 상태에 있다면, 검증 슈트는 그것을 위해 개발된다.

본 프로세스의 소프트웨어 형태에 따라, 시스템은 구성가능한 프로세서를 개발함으로써 하드웨어 형태를 돕는다. 그다음, 비용, 성능, 전력 및 기능과 이용가능한 프로세서 패브(fabs)의 정보와 같은 시스템 목표를 이용하는 시스템은 구성가능한 ISA 옵션, 확장 및 계수를 고려한 프로세서 특징 선택을 설계한다. 전체 시스템 구조, 개발 소프트웨어, 시뮬레이터, 구성가능한 명령어 세트 구조 및 프로세서 HDL 구현을 이용하는 프로세서 ISA, HDL 구현, 소프트웨어 및 시뮬레이터는 시스템에 의해 구성되고 시스템 HDL은 시스템-온-어-칩(system-on-a-chip) 설계를 위해 설계된다. 또한, 시스템 구조 및 칩 파운드리의 명세에 기초한 칩 파운드리는 시스템 HDL에 관한 파운드리 능력의 평가에 기초해 선택된다(종래 기술에서 처럼 프로세서 선택에 관한 것은 아님). 마지막으로, 파운드리의 표준 셀 라이브러리를 이용 하는 구성 시스템 통합 회로는 그것을 배치 및 정해진 경로로 보내고 레이아웃 및 타이밍을 다시 최적화하는 능력을 제공한다. 그다음, 회로 보드 레이아웃이 설계가 싱글-칩 형태가 아니라면 설계되고, 칩이 제조되며 보드가 조립된다.

위에서 볼 수 있는 것처럼, 몇몇 기술이 프로세서 설계 프로세스의 광범위한 자동화를 용이하도록 하기 위해 이용된다. 이 이슈들을 어드레싱하기 위해 이용되는 제1기술은 임의의 수정 또는 확장 만큼 유연하지 못하지만 그럼에도 불구하고 충분한 기능 향상을 허용하는 특정한 메카니즘을 설계하고 구현하기 위한 것이다. 변환의 임의성을 제약함으로써 그것과 관련된 프로그램이 제약을 받는다.

제2기술은 변환의 단일 기술을 제공하고 모든 영향을 받는 성분요소에 자동적으로 수정 또는 확장을 일으키는 것이다. 종래 기술을 이용하여 설계된 프로세서는 일단 수동으로 얼마간을 행하는 것이 자동적으로 얼마간을 행하면서 툴을 한번씩 이용하기 위해서 툴을 쓰는 것보다 종종 더 저렴하기 때문에 이것을 행하지 않는다. 자동화의 이점은 상기 작업이 여러번 반복될 때 적용한다.

이용되는 제3기술은 일련의 사용자 평가를 위해 측정 및 자동 구성을 돕는 데이터베이스를 구축하는 것이다.

끝으로, 제4기술은 구성에 도움이 되는 양식에 하드웨어 및 소프트웨어를 제공하는 것이다. 본 발명의 실시예에서 구성 데이타베이스의 조회 및 치환, 조건문, 복사 및 다른 수정을 이용하는 표준 하드웨어 및 소프트웨어 코드의 생성을 허용하는 프로세서를 부가함으로써 개선된 언어를 제외하고 하드웨어 및 소프트웨어중 일부는 표준 하드웨어 및 소프트웨어 언어에서 직접적으로 쓰이지 않는다. 그다음 연 결된 개선을 허용하는 훅을 이용하여 코어 프로세서 설계가 행해진다.

이들 기술을 설명하기 위해서, 응용프로그램-특정 명령어의 첨가를 고려해 보자. 레지스터 및 일정한 피연산자를 가지며 레지스터 결과를 산출하는 명령어에 대한 방법에 제약을 가함으로써, 명령어 연산은 단지 (상태 없고, 피드백 없는)조합 논리를 이용해 명확해 질 수 있다. 이 입력은

-- 신규 연산코드를 인식하는 프로세서를 위한 명령어 해독 논리;

-- 레지스터 피연산자의 조합 논리 기능을 수행하는 기능성 유닛의 첨가;

-- 그것의 피연산자가 타당할 때만 명령어 이슈가 확실한 프로세서의 명령어 스케쥴 논리에 대한 입력;

-- 신규 연산코드 및 그것의 피연산자를 수용하고 정확한 기계 코드를 생성하는 어셈블러 수정;

-- 신규 명령어를 입력하기 위해 신규 본래의 기능을 첨가하는 컴파일러 수정;

-- 신규 명령어처럼 기계 코드를 방해하는 디스어셈블러/디버거 수정;

-- 신규 연산코드을 수용하고 명확한 논리 기능을 수행하기 위한 시뮬레이터 수정;

-- 첨가된 명령어의 결과를 포함 및 검사하는 직접적 및 불규칙 코드 순서 둘 다를 생성하는 진단 생성기를 생성하는 툴로부터 명령어를 위한 연산코드 지정, 명령어 이름, 어셈블러 구문 및 조합 논리를 명확히 한다.

상기 기술 모두는 응용프로그램-특정 명령어를 첨가하기 위해 이용된다. 입 력은 피연산자 및 논리를 그들을 평가하기 위해서 입력 및 출력하기 위해 제약을 받는다. 변화은 한 장소에 기술되고 모든 하드웨어 및 소프트웨어 수정은 상기 기술로 부터 도출된다. 이 기능은 어떻게 단일 입력이 다양한 성분요소를 개선하기 위해 이용될 수 있는지를 보여준다.

이 프로세스의 결과는 프로세서와 시스템 논리 잔류부 사이의 타협이 설계 프로세스중의 훨씬 나중에 만들어질 수 있기 때문에 현존하는 기술보다 그것의 응용프로그램 필요성이 요구되는 곳에서 훨씬 가치가 있다. 종래 기술의 구성은 더 많은 재현의 양식에 적용될 수 있다는 점에서 위에서 논의한 종래 기술 접근법의 다수가 더 우월하다. 단일 소스는 모든 ISA 인코딩, 소프트웨어 툴이 이용될 수 있고 높은 수준의 시뮬레이션이 구성 패키지내에 포함될 수 있으며, 흐름은 구성 값이 최선의 조합을 찾기위해 반복이 이루어 지도록 설계될 수 있다. 또한, 제어를 위한 단일의 사용자 인터페이스 또는 사용자 직접 재정의를 위한 측정 시스템없이 하드웨어 구성 또는 소프트웨어 구성 단독에만 초점이 맞춰지는 동안, 본 발명은 최상의 구성의 선택을 돕도록 하드웨어 설계 결과 및 소프트웨어 수행으로 부터의 피드백을 포함하는 프로세서 하드웨어 및 소프트웨어의 구성을 위한 흐름을 완성하는데 기여한다.

이 목적들은 목표 명령어 세트, 목표 명령어 세트의 구성가능한 정의, 명령어 세트를 구현하기 위해 필요한 회로의 Hardware Description Language 기술 및 프로세서를 위한 응용프로그램을 개발하고 그것을 검증하는데 이용될 수 있는 컴파일러, 어셈블러, 디버거 및 시뮬레이터와 같은 개발 툴을 개발하기위한 표준화된 언어내에 관습화된 프로세서 명령어 세트 확장의 기술을 이용하는 자동 프로세서 디자인 툴을 제공함으로써 본 발명의 한 형태에 따라 달성된다. 표준화된 언어는 프로세서 상태를 수정하거나 구성가능한 프로세서를 이용하는 명령어 세트 확장을 조작할 수 있다. 확장 및 최적화의 제약이 가해진 도메인을 제공함으로써, 프로세스는 고도로 자동화 될 수 있고, 이것에 의해 빠르고 신뢰할 수 있는 개발이 수월해 진다.

또한 상기의 목적들은 사용자가 포텐셜 명령어나 상태의 다양한 설정을 유지하고(이후에 포텐셜 구성가능한 명령어나 상태의 조합은 집합적으로 "프로세서 개선"이라고 칭할 것이다) 그들의 응용프로그램을 평가할 때 쉽게 그들 사이에서 스윗칭(switch)할 수 있는 본 발명의 다른 형태에 따라 달성된다.

사용자는 본 명세서에서 기술된 방법을 이용하는 기본 프로세서 구성을 선택하고 구축한다. 사용자는 사용자-정의된 프로세서 개선의 신규 세트를 만들고 그들을 파일 디렉토리내에 배치한다. 그다음, 사용자는 사용자 개선을 진행하고 기본 소프트웨어 개발 툴에 의해 이용가능한 형태로 그들을 변형하는 툴을 호출한다. 이 변형은 그것이 단지 사용자 정의된 개선을 포함하고 전체 소프트웨어 시스템을 구축하지 않기 때문에 매우 빠르다. 그다음, 사용자는 신규 디렉토리내에 생성된 프로세서 개선을 동적으로 이용하기 위한 효력있는 툴인 기본 소프트웨어 개발 툴을 호출한다. 바람직하게는, 디렉토리의 위치는 명령 회선 옵션을 통해서나 변화가능한 환경을 통하는 툴에 주어진다. 프로세스를 더 간단히 하기 위해서, 사용자는 표준 소프트웨어 메이크파일을 이용할 수 있다. 신규 프로세서 개선의 문맥 내에 자 신들의 응용프로그램을 구축 및 평가하기 위해서 메이크파일은 유저가 그들의 프로세서 명령어를 수정할 수 있게 한 다음 단일 메이크 명령을 통해 개선을 진행하고 기본 소프트웨어 개발 시스템을 이용할 수 있게 한다.

상기 발명은 종래 기술 접근법의 세가지 한계를 극복한다. 잠재적 개선의 신규 세트가 주어진 사용자는 약 수분내에 신규 개선을 평가할 수 있다. 사용자는 각각의 세트를 위해 신규 디렉토리를 생성함으로써 포텐셜 개선의 많은 버전을 지닐 수 있다. 상기 디렉토리는 단지 신규 개선의 기술을 포함하고 전체 소프트웨어 시스템은 보유하지 않기 때문에, 요구되는 저장 공간은 아주 적다. 끝으로, 신규 개선은 구성의 잔류부로부터 완화된다. 일단 사용자가 신규 개선의 포텐셜 세트를 구비한 디렉토리를 생성하면, 사용자는 임의의 기본 구성을 구비한 디렉토리를 사용할 수 있다.

도 1은 본 발명의 바람직한 실시예에 따른 명령어 세트를 구현하는 프로세서의 블록도;

도 2는 실시예에 따른 프로세서에서 이용되는 파이프라인의 블록도;

도 3은 실시예에 따른 GUI내의 구성 편집자를 도시한 도면;

도 4는 실시예에 따른 GUI내의 구성 편집자를 도시한 도면;

도 5는 실시예에 따른 구성가능성의 다른 형태;

도 6은 실시예에서 프로세서 구성의 흐름을 보여주는 블록도;

도 7은 실시예에 따른 명령어 세트 시뮬레이터의 블록도;

도 8은 본 발명에 따라 구성된 프로세서를 이용하기 위한 에뮬레이션 보드의 블록도;

도 9는 실시예에 따른 구성가능한 프로세서의 논리적 구조를 보여주는 블록도;

도 10은 도 9의 구조에 멀티플라이어를 첨가한 블록도;

도 11은 도 9의 구조에 멀티플라이-누산 유닛을 첨가한 블록도;

도 12 및 도 13은 실시예에서 메모리의 구성을 도시한 도면; 및

도 14 및 도 15는 도 8의 구조에 사용자-정의된 기능적 유닛을 첨가한 도면;

도 16은 다른 바람직한 실시예에서 시스템 성분요소 사이의 정보의 흐름을 도시한 도면;

도 17은 실시예에서 어떻게 관습적인 코드가 소프트웨어 개발 툴을 위해 생성되는지를 보여주는 블록도;

도 18은 본 발명의 다른 바람직한 실시예에서 이용되는 다양한 소프트웨어 모듈의 생성을 보여주는 블록도;

도 19는 실시예에 따른 구성가능한 프로세서내의 파이프라인 구조체의 블록도;

도 20은 실시예에 따른 상태 레지스터 구현을 도시한 도면;

도 21은 실시예에서 상태 레지스터 구현을 구현하기 위해 필요한 부가적인 논리의 도면;

도 22는 실시예에 따른 몇가지 의미론의 블록으로부터 임의의 상태의 다음 상태 출력의 조합 및 상태 레지스터에 입력하기 위한 선택된 하나를 도시한 도면;

도 23은 실시예에 따른 의미론의 논리에 상응하는 논리를 도시한 도면; 및

도 24는 실시예에 따라 상태가 사용자 레지스터의 한 비트에 맵핑될 때의 상태의 한 비트를 위한 논리를 도시한 도면이다.

일반적으로, 자동 프로세서 생성 프로세스는 상기 프로세서가 구성될 사용자-명세된 응용프로그램 뿐만 아니라 구성가능한 프로세서 정의 및 사용자-명세된 수정을 개시한다. 이 정보는 구성된 계수에 사용자 수정를 하는 프로세서를 생성하기 위해 이용되고 소프트웨어 개발 툴, 예를 들어 컴파일러, 시뮬레이터, 어셈블러 및 디스어셈블러 등을 그것을 위해 생성한다. 또한, 응용프로그램은 신규 소프트웨어 개발 툴을 이용하여 다시 컴파일링된다. 재컴파일링된 응용프로그램은 응용프로그램을 실행하는 구성된 프로세서의 성능을 기술하는 소프트웨어 프로파일을 생성하기 위해서 시뮬레이팅 되고 프로세서 회로 구현을 특징으로 하는 하드웨어 프로파일을 생성하기 위해서 구성된 프로세서는 실리콘 칩 처리, 전력 소비, 스피드등에 관해 평가된다. 소프트웨어 및 하드웨어 프로파일은 사용자가 프로세서가 그 특별한 응용프로그램을 위해 최적화 될 수 있도록 추가로 반복적인 구성을 가능케 할 수 있도록 피드 백 및 제공된다.

본 발명의 바람직한 실시예에 따른 자동 프로세서 생성 시스템(10)은 도 1에 도시된 바와 같이 다음의 네개의 주요 성분요소를 구비한다: 프로세서를 설계하기 를 원하는 사용자가 자신의 구성능력 및 확장성 옵션 및 다른 설계 제약사항을 엔터링할 수 있는 사용자 구성 인터페이스(20); 사용자에 의해 선택된 기준에서 설계된 프로세서를 위해 관습화될 수 있는 소프트웨어 개발 툴(30)의 슈트; 프로세서(40)의 하드웨어 구현의 파라미터화된 확장기능 기술; 및 사용자 인터페이스, 요구된 프로세서의 관습화되고 통합가능한 하드웨어 기술을 생성하고 선택된 설계를 조절하기 위한 소프트웨어 개발 툴을 수정하는 사용자 인터페이스로부터 입력 데이터를 수용하는 구축 시스템(50). 바람직하게는, 구축시스템(50)은 하드웨어 및 소프트웨어 설계과 하드웨어 및 소프트웨어 특징을 평가하기 위한 에스티메이터를 검증하기 위해 진단 툴을 추가로 생성한다.

본 명세서 및 첨가항에서 이용된 "하드웨어 구현 기술"은 프로세서 설계의 물리적인 구현의 형태를 기술하는 한개이상의 기술, 그리고, 단독 또는 한개 이상의 다른 기술과 공동으로 설계에 따른 칩의 설비 생산을 의미한다. 따라서, 하드웨어 구현 기술의 성분요소는 넷리스트 및 마이크로코딩을 통한 하드웨어 기술 언어와 같은 비교적 높은 수준에서 마스크 기술까지, 변화하는 추상화의 수준에서 생길수 있다. 하지만 본 실시예에서, 하드웨어 구현 기술의 주요 성분요소는 HDL, 넷리스트 및 스크립트로 쓰여진다.

또한, 본 명세서 및 첨가항에서 이용된 바와 같이 HDL은 마이크로구조등을 기술하기 위해 사용되는 하드웨어 기술 언어의 일반적인 종류를 언급하기 위해 의도되고 그것은 이러한 언어의 특별한 예를 언급하기 위해 의도된 것은 아니다.

본 실시예에서, 프로세서 구성의 기초는 도 2에 도시된 구조이다. 구조의 많 은 소자는 사용자에 의해 직접적으로 수정되지 않는 기본적 특징들이다. 이들은 프로세서 제어 섹터(62), 정렬 및 디코드 섹터(64)(이 섹터의 일부가 사용자-명세된 구성에 기초되었지만), ALU 및 어드레스 생성 섹터(66), 분기 논리 및 명령어 인출(68) 및 프로세서 인터페이스(70)을 포함한다. 다른 유닛은 기본 프로세서의 일부이지만 사용가-구성가능하다. 이들은 인터럽트 제어 섹터(72), 데이터 및 명령어 어드레스 워치 섹션(74 및 76), 윈도우 레지스터 파일(78), 데이터 및 명령어 캐시 그리고 태그 섹션(80), 쓰기 버퍼(82) 및 타이머(84)를 포함한다. 도 2에 도시된 나머지 섹터들은 선택적으로 사용자에 의해 포함된다.

프로세서 구성 시스템(10)의 중앙 성분요소는 사용자 구성 인터페이스(20)이다. 이것은 모듈이고, 이 모듈은 바람직하게는 컴파일러의 재구성과 어셈블러, 디스어셈블러 및 명령어 세트 시뮬레이터(ISS)의 재생성 및 완전한 통합, 배치 및 라우팅의 라운칭을 위한 입력의 준비를 포함하는 프로세서 기능성을 선택하는 것이 가능한 그래피컬 사용자 인터페이스(GUI)를 이용하는 사용자에게 제공한다. 또한 그것은 사용자가 추가 반복 및 프로세서 구성의 개선을 위해 프로세서 영역, 전력 소비, 사이클 타임, 응요프로그램 성능 및 코드 크기의 이점을 활용하는 것을 허용한다. 바람직하게는, 상기 GUI는 또한 디폴트 값을 얻거나 사용자 입력의 에러 검사를 하기 위한 구성 데이터베이스를 입력한다.

프로세서(60)를 설계하기 위한 본 실시예에 따른 자동 프로세서 생성 시스템(10)을 이용하기 위해서, 사용자는 설계 파라미터를 사용자 구성 인터페이스(20)에 입력한다. 자동 프로세서 생성 시스템(10)은 사용자의 제어하에 컴퓨터 시스템을 실행하는 독립하여 조작이 가능한 시스템일 수 있다; 하지만, 그것은 바람직하게는 자동 프로세서 생성 시스템의 제조자의 제어를 받는 시스템을 주로 실행한다. 그다음 사용자 접근은 통신 네트워크 전반에 걸쳐 제공된다. 예를 들어, HTML 및 Java에서 쓰여진 데이터 입력 스크린을 이용하는 웹 브라우저를 이용하는 GUI가 제공될 수 있다. 이것은 임의의 전매특허 후위의 소프트웨어(back-end software)의 신뢰성을 유지, 후위 소프트웨어의 긴급보수 및 갱신을 간소화등과 같은 몇가지 이점을 가진다. 이러한 경우에, GUI에 접근하기 위해서 사용자는 우선 그의 신분을 증명하기 위해서 시스템(10)에 로그온해야 한다.

일단 유저가 접근하면, 상기 시스템은 도 3에 도시된 것처럼 구성 매니저 스크린(86)을 나열한다. 구성 매니저(86)는 사용자에 의해 접근가능한 구성 모두를 기재한 디렉토리이다. 도 3에서의 구성 매니저(86)는 이미 구축된, 즉 생산을 위하여 완결한 첫번째것 및 아직 구축되지 않는 두번째것인 두개의 구성 "just intr" 및 "high prio"를 사용자가 갖는다는 것을 도시하고 있다. 이 스크린(86)으로부터, 사용자는 선택된 구성을 구축할 수 있고, 그것을 삭제할 수 있고, 그것을 편집할 수 있으며, 구성 및 확장 옵션이 그 구성을 위해 선택되어 왔다고 명세한 보고서를 생성할 수 있거나 신규 구성을 창작할 수 있다. "just intr"와 같은 구축 되어온 그들 구성을 위해, 그것을 위해 관습화된 소프트웨어 개발 툴(30)의 슈트는 다운로드될 수 있다.

새로운 구성을 창작하거나 현존하는 구성을 편집하는 것이 도 4에 도시된 구성 에디터를 요구 수준에 도달시킨다. 상기 구성 에디터(88)는 왼쪽에 구성 및 확 장된 프로세서(60)의 다양한 일반 형태를 보여주는 "옵션" 섹션 메뉴를 갖는다. 옵션 섹션이 선택되었을 때, 오른쪽에 그 섹션을 위한 구성 옵션을 갖는 스크린이 나타나고, 이들 옵션은 상기 기술에서 알려진 바와 같이 풀-다운 메뉴, 메모 박스, 체크 박스, 라디오 버튼등을 구비한 세트가 될 수 있다. 사용자가 옵션을 선택하고 임의의 데이터를 기입하지만, 상기 섹션 사이에 논리적 종속이 존재하기 때문에 바람직하게는 데이터가 연속하여 각각으로 기입된다; 예를 들어, "인터럽트" 섹션내에 옵션을 적절히 나열하기 위해서 다수의 인터럽트가 "ISA Option" 섹션에서 선택되어 왔다.

본 실시예에서, 다음의 구성 옵션이 각각의 섹션을 위해 이용가능하다.

부가적으로, 시스템(10)은 32-비트 정수 곱셈/나눗셈 유닛 또는 부동 소수점 산술 유닛; 메모리 관리 유닛; 온-칩 램 및 롬; 캐시 연합(cache associativity); 개선된 DSP 및 보조처리기 명령어 세트; 라이트-백 캐시(write-back cache); 다중처리기 동기화; 컴파일러-디렉티드 스펙큘레이션; 및 부가 CAD 패키지를 위한 지지와 같은 다른 기능 유닛을 부가하기 위한 옵션이 제공될 수 있다. 어떤 구성 옵션이 주어진 구성 프로세서를 위해 이용될 수 있더라도, 그들은 일단 사용자가 적절한 옵션을 선택하면 시스템(10)이 구문 검사등을 위해 이용하는 정의 파일(부록 A에 도시된 것과 같은)내에 바람직하게 기재된다.

상술한 바로부터, 누구나 자동 프로세서 구성 시스템(10)은 도 5에 도시된 바와 같이 사용자에게 구성가능성(300)의 다음의 두가지 보드 형태를 제공한다는 것을 알 수 있다: 사용자가 스크래치(scratch)로부터 임의의 함수 및 구조를 정의하는 것을 허용하는 확장성(302) 및 사용자가 기정된 옵션의 제약된 세트로부터 선택하는 것을 허용하는 수정가능성(304). 수정가능성 내에서, 상기 시스템은 예를 들어 MAC16 또는 DSP가 프로세서(60) 및 다른 프로세서 특징, 예를 들어 인터럽트의 수와 캐시 크기의 파라미트릭 명세(308)에 부가되어야 하는지에 대한 확실한 특징의 두가지 선택(306)을 허용한다.

상기의 구성 옵션의 다수는 상기 기술과 친숙하다; 하지만, 다른 것들은 특별한 주의가 필요하다. 예를 들어, 램 및 롬 옵션은 설계자가 프로세서(10) 그 자체의 스크래치 패드 또는 펌웨어를 포함하는 것을 허용한다. 프로세서(10)은 이들 메모리로부터 명령어를 인출할 수 있거나 데이터를 읽고 쓸수있다. 메모리의 크기 및 배치는 구성가능하다. 본 실시예에서, 이들 메모리의 각각은 세트-결합 캐시내의 부가 세트처럼 접근도리 수 있다. 메모리내의 적중(hit)는 단일 태그 엔트리와 비교함으로써 감지될 수 있다.

각각의 고순위 인터럽트 레벨이 세개의 특수 레지스터를 필요로 하고, 따라서 이들은 더 비싸기 때문에 상기 시스템(10)은 인터럽트(레벨 1의 인터럽트를 구현함) 및 고순위 인터럽트 옵션(레벨 2-15의 인터럽트를 구현함)을 위한 개별적인 구성 옵션을 제공한다.

40비트 누산기 옵션(도 2의 90에 도시됨)을 구비한 MAC16은 하나의 40비트 누산기, 여덟개의 16비트 피연산자 레지스터 및 곱셈, 누적, 피연산자 로드를 조합하고 최신 명령어를 어드레싱하는 복합 명령어 세트를 이용하는 곱셈/덧셈 기능을 부가한다. 피연산자 레지스터는 곱셈/누산 연산과 병행하여 메모리로부터의 16비트 값의 쌍이 로딩될 수 있다. 이 유닛은 사이클당 두번의 로드와 곱셈/누산을 이용해 알고리즘을 입증할 수 있다.

온-칩 디버그 모듈(도 2의 92에 도시됨)은 JTAG 포트(94)를 통해서 프로세서(60)의 내부의 일람식-소프트웨어(software-visible) 상태에 접근하기 위해 이용된다. 묘듈(92)은 디버그 모드; 모든 프로그램-가시 레지스터 또는 메모리 위치; 프로세서(60)이 실행을 위해 구성되는 명령어의 실행; 코드내 소정 위치에 점핑하기 위한 PC의 수정; 및 JTAG 포트(94)를 통해 프로세서(60) 외부로 부터 트리거링된 평범한 연산 모드로의 복귀를 허용하기 위한 유틸리티에 프로세서(60)을 두기 위해서 예외 상황 생성을 위한 지지를 제공한다.

일단 프로세서(10)이 디버그 모드를 기입하면, 그것은 타당한 명령어가 JTAG 포트(94)를 통해 스캐닝 되어온 외부 세상으로부터의 인디케이션을 기다린다. 그다음 상기 프로세서는 이 명령어를 실행하고 다음 타당한 명령어를 기다린다. 일단 프로세서(10)의 하드웨어 구현이 제조되면, 이 모듈(92)은 시스템을 디버깅하는데 이용될 수 있다. 프로세서(10)의 실행은 원격 호스트로 실행되는 디버거를 통해 제어될 수 있다. 명령어 실행을 제어할 뿐만 아니라 프로세서(10)의 상태를 결정 및 제어하기 위해서 디버거는 JTAG 포트(94)를 통해 프로세서와 인터페이싱하고 온-칩 디버그 모듈(92)의 능력을 이용한다.

최고 세 개의 32비트 카운터/타이머(84)가 구성될 수 있다. 인터럽트 및 유사한 특징들을 이용하기 위하여, 이것은 비교 레지스터 및 컴페어 레지스터 컨텐츠와 (각각의 구성된 타이머를 위하여)현재의 클럭킹된 레지스터 계수를 비교하는 비교기 뿐만 아니라 각각의 클럭 사이클을 증가시키는 32비트 레지스터의 이용을 수반한다. 카운터/타이머는 트리거링된 에지(edge-triggered)처럼 구성될 수 있고 정규 또는 높은 우선순위의 내부 인터럽트를 생성할 수 있다.

스페큘레이션 옵션(speculation option)은 로드가 항상 실행되지 않는 흐름을 제어하도록 로드가 순리적으로 이동되도록 허용함으로써 유연성을 스케쥴링하는 더 뛰어난 컴파일러를 제공한다. 로드는 예외 상황을 야기할 수 있기 때문에, 이러한 로드 움직임은 예외 상황이 근본적으로 발생할 수 없는 타당한 프로그램에 채용할 수 있다. 로드가 실행될 때 순리적인 로드는 예외 상황이 발생하는 것을 막지만, 데이터가 요구될 때는 예외 상황을 제공한다. 로드 오차를 위하여 예외 상황을 야기하는 대신에, 순리적인 로드는 수신지 레지스터의 타당한 비트를 재설정한다(이러한 옵션과 관련된 신규 프로세서 상태).

바람직하게는, 코어 프로세서(60)은 몇개의 파이프라인 동기화 능력을 갖고 있지만, 다양한 프로세서가 시스템내에 이용될 때는 프로세서 사이의 통신 및 동기화의 일부가 요구된다. 몇몇 경우에, 입력 및 출력 대기열과 같은 자기-동기 통신 기술(self-synchronizing communication techniques)이 이용된다. 다른 경우에, 공유된 메모리가 요구되는 의미론을 제공하지 않기 때문에, 공유된 메모리 모델이 통신을 위해 이용되고, 동기화를 위한 명령어 세트 지지를 제공할 필요가 있다. 예를 들어, 습득 및 해제 의미론을 이용하는 부가적인 로드 및 저장 명령어가 부가될 수 있다. 이들은 동기화 참조들 사이의 정확한 순서를 유지하기 위해서 동기화 및 데이터를 위해 다른 메모리 위치가 이용되는 멀티프로세서 시스템내의 메모리 참조의 순서를 제어하기에 유용하다. 다른 명령어는 상기 기술에서 알려진 세마포어 시스템을 창작하기 위해서 이용된다.

몇몇 경우에, 공유된 메모리는 요구되는 의미론을 제공하지 못하기 때문에 공유된 메모리 모델은 통신을 위해 이용되고, 동기화를 위하여 명령어 세트 지지를 제공할 필요가 있다. 이것은 멀티프로세서 동기화 옵션에 의해 행해진다.

아마 구성 옵션들 사이에서 가장 두드러진 것은 설계자-정의된 명령어 실행 유닛(96)이 구축되는 TIE 명령어 정의일 것이다. California, Santa Clara의 Tensilica Corporation에 의해 개발된 상기 TIM^TM(Tensilica Insruction Set Extension) 언어는 기본 ISA를 늘리기 위해서 사용자가 확장 및 신규 명령어의 형태로 자신의 응용프로그램을 위한 관습 기능을 기술하는 것을 허용한다. 부가적으로, TIE의 유연성 때문에 그것은 사용자에 의해 변형될 수 없는 ISA의 일부를 기술하는데 이용될 수 있을 것이다; 이러한 방식에서, 전체 ISA가 소프트웨어 개발 툴(30) 및 하드웨어 구현 기술(40)을 균등하게 생성하기 위해 이용될 수 있다. 아래처럼 신규 명령어의 특성을 정확하게 서술하기 위해서 TIE 기술은 다수의 구축 블록을 이용한다.

명령어 필드 문장, field는 TIE 코드를 읽기 쉽도록 개량하는데 이용된다. 필드는 임의의 이름에 의해 함께 그룹을 이루고 참조된 다른 필드의 부분집합 또는 연결이다. 명령어내 비트의 완성 세트는 최고 레벨의 수퍼세트 필드 inst 이고, 이러한 필드는 더 작은 필드로 나뉘어 질 수 있다. 예를 들어,

최고 레벨의 필드 inst의 하부 필드(각각, 비트 8-11 및 12-15)로서 두 개의 4비트 필드, x 및 y 및 x 및 y 필드의 연쇄로서 하나의 8비트 필드를 정의한다.

문장 opcode는 특정 필드를 인코딩하기 위한 연산코드를 정의한다. 다음에 정의하는 연산코드에 의해 이용될 피연산자, 예를 들어 레지스터 또는 중간 상수를 명확히 하기 위해 의도된 명령어 필드는 필드 문장이 처음으로 정의되어야 하고 다름으로 피연산자 문장이 정의되어야 한다.

예를 들어,

이전에 정의된 연산코드 custo(4'b0000는 네 개의 비트-롱 이진법 상수 0000 나타냄)에 기초한 두 개의 신규 연산코드 acs 및 adsel을 정의한다. 바람직한 코어 ISA의 TIE 명세는

그것의 기본 정의의 일부로서 문장을 가진다. 따라서, acs 및 adsel의 정의는 다음에 의해 각각 표현된 명령어 해독 논리를 생성하기 위한 TIE 컴파일러의 근원이 된다.

명령어 피연산자 문장 operand는 레지스터 및 중간 상수를 식별한다. 하지만, 피연산자처럼 필드를 정의하기 전에, 상술한 것처럼 그것이 이전에 필드로 정의되어야 한다. 피연산자가 중간 상수라면, 상수의 값은 피연산자로부터 생성될 수 있거나 그것은 아래에 기술된 것처럼 이전에 정의된 상수 테이블로부터 인용될 수 있다. 예를 들어, 중간 피연산자를 해독하기 위해서 TIE 코드는

부호화된 숫자를 보유하는 18비트 필드 네이밍된 오프셋 및 오프셋 필드내에 저장된 네배의 숫자인 피연산자 offset4를 정의한다. operand 문장의 마지막 부분은 당업자들에게는 명백히 이해되는 것처럼, 조합 회로를 기술하기 위한 Verilog^TMHDL의 서브세트내의 계산을 수행하는데 사용되는 회로를 실제로 기술한다.

여기서, 문장 wire는 t라 명명된 광폭 32비트 논리 와이어의 하나의 세트를 정의한다. 와이어 문장에 이어서 첫번째 문장 assign이 논리 와이어를 구동하는 논리 신호는 오른쪽으로 쉬프팅된 offsets4 상수라 명세하고 두번째 문장 assign은 t의 보다 낮은 18비트를 offset 필드에 할당한다고 명세한다. 바로 첫번째 문장 assign은 offset의 연결 및 이 비트의 쉬프트-레프트에 의해 그것의 사인 비트(비트 17)의 14 복사처럼 offsets4의 값을 직접적으로 명세한다.

상수 테이블 피연산자를 위해, TIE 코드는

상수의 배열 prime(테이블 이름에 이어지는 숫자는 테이블 내의 소자의 숫자임)을 정의하고 피연산자 prime_s을 위한 값을 해독하기 위한 테이블 prime에서 색인으로서 피연산자를 이용한다(색인 지정을 정의하는 Verilog^TM 문장의 이용을 주목할 것).

본 명령어 클래스 문장 iclass는 연산코드와 평범한 포맷내의 피연산자를 연관시킨다. iclass에 정의된 모든 명령어는 동일한 포맷과 피연산자 사용법을 갖는다. 명령어 클래스를 정의하기 전에, 그것의 성분요소가 정의 되어야 하고, 필드가 처음으로 그다음 연산코드 및 피연산자가 정의되어야 한다. 예를 들어, 연산코드 acs 및 adsel을 정의하는 상기의 예에서 이용된 코드를 구축하는 부가적인 문장은

세개의 레지스터 피연산자 art, ars 및 arr을 정의하기 위해서 operand 문장을 이용한다(상기 정의에서의 Verilog^TM의 이용에 다시 주목할 것). 그다음, 클래스 문장은

입력으로 두개의 피연산자 art 및 ars를 가지는 명령어 viterbi의 일반적인 클래스에 속한 피연산자 adsel 및 acs를 명세하고 레지스터 피연산자 arr으로 출력을 기록한다.

명령어 의미론 문장 semantic은 코딩 피연산자를 위해 이용되는 Verilog^TM의 동일한 서브세트를 이용하는 한개 이상의 동작을 기술한다. 단일 의미론 문장에서 다양한 명령어를 정의함으로써, 몇개의 평범한 표현이 공유되고 하드웨어 구현이 더 효율적으로 만들어 질 수 있다. 의미론 문장에서 허용된 변수는 문장의 연산코드 목록내에 정의된 연산코드를 위한 피연산자 및 연산코드 목록내에 명세된 각각의 연산코드를 위한 단일비트의 변수이다. 이러한 변수는 연산코드처럼 동일한 이름을 가지며 연산코드가 감지될 때 1로 평가한다. 그것은 상응하는 명령어의 존재를 나타내기 위해 계산 섹션(Verilog^TM 서브세트 섹션)에서 이용된다.

예를 들어, 다른 32비트 단어내의 개개의 8비트 피연산자를 이용하는 임의의 32비트 단어내에 네개의 8비트 피연산자를 부가하는 신규 명령어 ADD8_4 및 32비트 단어내의 16비트 피연산자 및 다른 32비트 단어내의 개개의 16비트 피연산자 사이의 최소 선택을 수행하는 신규 명령어 MINI6_2 정의하는 TIE 코드는 읽을 수 있을 것이다.

여기서, op2, CUSTO, arr, art 및 ars는 상기된 바와 같이 앞에서 저의했던 피연산자이고 opcode 및 iclass 문장 상술한 바처럼 기능한다.

semantic 문장은 신규 명령어에 의해 수행된 계산을 명세한다. 당업자라면 쉽게 이해하겠지만, semantic 문장내의 두번째 줄은 신규 명령어 ADD8_4에 의해 수행된 계산, 세번째 및 네번째 줄은 MINI6_2 에 의해 수행된 계산 및 섹션의 마지막 줄은 arr 레지스터에 쓰여진 결과를 명세한다.

사용자 입력 인터페이스(20)의 논의로 돌아와서, 일단 사용자는 모든 구성 및 확장 옵션을 기입하면 구축 시스템(50)이 우세해지기를 원한다. 도 5에 도시된 바와 같이, 상기 구축 시스템(50)은 유저에 의해 설정된 파라미터들 및 유저에 의해 설계된 확장가능한 특징들에 의해 구성된 구성 명세를 수용하고, 그들을 예컨대 유저에 의해 수정될 수 없는 특징들과 같은 코어 프로세서 아키텍처를 정의하는 추가 파라미터들과 조합시켜, 전체 프로세서를 기술하는 단일 구성 명세(100)를 생성하게 된다. 예를 들어, 유저에 의해 선택된 구성 세팅(102) 이외에, 상기 구축 시스템(50)은 프로세서의 물리적 어드레스 공간을 위해 다수의 물리적 어드레스 비트, 리세트 후에 프로세서(60)에 의해 실행될 제1명령어의 위치등을 명세하는 파라미터를 더할 수 있다.

Tensilica, Inc.에 의한 Xtensa^TM Instruction Set Architecture(ISA) Reference Manual, Reversion 1.0이 코어 명령어처럼 구성가능한 프로세서내에 구현될 수 있는 명령어 및 구성 옵션의 선택을 통해 이용가능한 명령어의 예를 설명할 목적으로 본명세서에서 채용된다.

또한 구성 명세(100)는 기본 ISA를 명세한 TIE 언어 문장을 포함하는 ISA, 보조처리기 패키지(98)(도 2 참조) 또는 DSP와 같은, 사용자에 의해 선택될 수 있는 부가 패키지 및 사용자에 의해 공급되는 TIE 확장을 포함한다. 부가적으로, 구성 명세(100)는 어떤 구조적 특징이 프로세서(60)내에 포함될 것인지 아닌지에 대해 암시적인 플래그를 세팅하는 다수의 문장을 가질 수 있다. 예를 들어,

프로세서는 우선순위가 높지 않은 인터럽트 설비를 제외하고 온-칩 디버깅 모듈(92), 인터럽트 설비(72) 및 예외 상황 취급을 포함할 수 있음을 나타내고 있다.

구성 명세(100)을 이용하여 다음의 사항들은 아래에 보여지는 바와 같이 자동적으로 생성될 수 있다.

-- 프로세서(60)의 명령어 해독 논리

-- 프로세서(60)을 위한 불법 명령어 감지 논리

-- 어셈블러(100)의 ISA-특정부

-- 컴파일러(108)을 위한 ISA-특정 지지 루틴

-- (디버거에 의해 이용되는)디스어셈블러(100)의 ISA-특정부; 및

-- 시뮬레이터(112)의 ISA-특정부.

중요한 구성 능력은 명령어 패키지의 포함을 명세하는 것이기 때문에 이러한 것들을 자동적으로 생성하는 것은 가치가 있다. 몇가지 것들을 위해, 그것이 구성된다면 명령어를 취급하는 각각의 툴에서의 조건화된 코드를 이용하여 이것을 구현하는 것이 가능할 것이지만 이것은 불편하다; 더 중요하게, 그것은 시스템 설계자가 쉽게 자신의 시스템을 위한 명령어를 부가하는 것을 허용하지 않는다.

설계자로 부터의 입력으로 구성 명세(100)을 취하는 것에 덧붙여, 또한 목표를 받아들이고 자동적으로 구성을 결정하는 구축 시스템(50)을 갖는 것이 가능하다. 설계자는 프로세서(60)를 위한 목표를 명세할 수 있다. 목표중 일부가 충돌하기 때문에(예를 들어 면적이나 전력 소비 또는 이 둘 모두가 증가함으로써 결국에는 성능이 증가될 수 있음), 구축 시스템(50)은 또한 목표를 위한 우선 순서를 만든다. 그다음 구축 시스템(50)은 이용가능한 구성 옵션의 세트를 결정하기 위해서 검색 엔진을 조사하고 입력 목표를 동시에 달성하도록 시도하는 알고리즘으로 부터 각각의 옵션을 세팅하는 방법을 결정한다.

검색 엔진(106)은 다양한 메트릭(metrics)의 효과를 기술하는 엔트리를 갖는 데이터베이스를 포함한다. 엔트리는 특별한 구성 세팅이 더하거나 곱해지고 또는 메트릭의 효과의 제한한다는 점을 명세한다. 엔트리는 또한 전제조건 또는 다른 옵션과 병행할 수 없을만큼 다른 구성 옵션을 요구하도록 표시될 수 있다. 예를 들어, 간단한 분기 예측 옵션(simple branch prediction option)은 Cycle Per Instruction(CPI-성능의 결정)의 효과, 클럭 속도의 제한, 구역의 곱셈 또는 덧셈 효과 및 전력의 부가 효과를 명세할 수 있다. 그것은 간단한 팬시어 분기 프레딕터(fancier branch predictor)와 병립할수 없으며 적어도 두개의 엔트리에 명령어 페치 큐(fetch queue) 크기가 세팅에 존속하도록 표시될 수 있다. 이들 효과의 값은 분기 프레딕션 테이블의 크기와 같은 파라미터의 기능일 수 있다. 일반적으로, 데이터베이스 엔트리는 평가될 수 있는 기능에 의해 재현된다.

다양한 알고리즘은 입력 목표를 달성하기 위해 가장 밀접하게 완성되는 구성 세팅을 찾기 위하여 가능하다. 예를 들어, 간단한 냅색(knapsack) 패키징 알고리즘은 이용에 의해 분배된 값의 저장된 순서에서 각각의 옵션을 고려하고 지정된 제한 아래로 비용을 유지하는 한편 가치를 증가시키는 특정 옵션 명세를 받아들인다. 예를 들면, 그래서, 지정된 값 아래로 전력을 유지하는 한편 성능을 최대화 하기 위해서, 옵션은 전력 및 전력 제한을 초과함 없이 구성될 수 있는 성능을 증가시키는 각각의 옵션에 의해 분배된 성능에 의해 저장될 것이다. 더 복잡한 냅색 알로리즘은 백트래킹의 몇몇 계수를 제공한다.

목표 및 설계 데이터베이스로부터의 구성을 결정하기 위한 알고리즘의 아주 다른 종류는 시뮬레이팅된 어닐링에 기초한다. 파라미터의 임의의 초기 세트는 출 발점처럼 이용되고, 그다음 개별적 파라미터의 변환이 전체적인 유틸리티 기능을 평가함으로써 받아들여지거나 거절된다. 최적화 프로세스처럼 저하되는 문턱(threshold)에 기초된 네가티브 변환이 받아 들여지는 한편 유틸리티 기능의 개량은 개연적으로 항상 받아들여 진다. 이러한 시스템에서 유틸리티 기능은 입력 목표로부터 구조된다. 예를 들어, 전력, 구역 및 성능의 실행 우선순위를 갖는 목표 성능〉200, 전력〈100, 구역〈4이 주어진 다음의 유틸리티 기능이 이용될 수 있다:

여기서, 리워드(rewards)는 전력 소비를 100보다 작거나 같을 때까지 감소시키고, 리워드는 구역을 4보다 작거나 같을 때까지 감소시키며 리워드는 성능이 200보다 크거나 같을때 까지 감소시킨다. 또한, 전력이 규격을 벗어날때 구역 처리를 경감시키고 전력이 규격을 벗어날 때 성능 처리를 경감시키는 성분요소가 있다.

알고리즘 및 나머지 모두는 지정된 목표를 만족시키는 구성을 찾는데 이용될 수 있다. 중요한 것은 구성가능한 프로세서 설계가 설계 데이터베이스내에 기술된다는 점이며, 여기서 설계 데이터베이스는 전제조건 및 양립할 수 없는 옵션 명세 및 다양한 메트릭의 구성 옵션의 임팩트를 가진다.

제시된 예들은 하드웨어 목표를 가지며, 여기서 하드웨어 목표는 일반적이며 프로세서(60)이 실행되는 특별한 알고리즘에 종속적이지 않다. 또한 기술된 알고리 즘은 특정한 사용자 프로그램을 위해 잘 맞는 구성을 선택하기 위해 이용된다. 예를 들어, 다른 크기, 다른 회선 크기 및 다른 세트 연관성(associativity)와 같은 다른 특징을 가진 다른 형태의 캐시를 위해 많은 캐시 오류를 측정하기 위해서 사용자 프로그램은 캐시 어큐레이트 시뮬레이터를 이용하여 실행될 수 있다. 이들 시뮬레이션의 결과는 하드웨어 구현 기술(40)의 선택을 돕는 검색 알고리즘(106)에 의해 이용되는 데이터베이스에 부가될 수 있다.

유사하게, 사용자 알고리즘은 특정 명령어의 존재를 위해 프로파일링될 수 있고, 여기서 특정 명령어는 하드웨어에서 선택적으로 구현될 수 있다. 예를 들어, 사용자 알고리즘이 멀티플리캐이션을 행하는데 충분한 시간을 쓴다면, 검색 엔진(106)은 자동적으로 하드웨어 멀티플라이어를 포함하는 것을 제안할 것이다. 이러한 알고리즘 필요성은 한 사용자의 알고리즘을 고려하기 위해서 제한되지 않는다. 사용자는 알고리즘의 한 세트를 시스템에 공급할 수 있고 검색 엔진(106)은 구성을 선택할 수 있으며, 여기서 상기 구성은 사용자 프로그램의 세트에서 평균하여 유용하다.

프로세서(60)의 이전에구성된 특징을 선택하는 것에 덧붙여, 검색 알고리즘은 또한 사용자 가능한 TIE 확장을 자동적으로 선택하거나 제안하는데 이용될 수 있다. 아마 C 프로그래밍 언어에서 기록된 사용자 프로그램의 입력 목표 및 예가 주어진 이들 알고리즘은 포텐셜 TIE 확장을 제안할 것이다. 상태 없는 TIE 확장을 위해, 컴파일러와 유사한 툴은 패턴 매쳐(pattern matcher)와 함께 구현된다. 이들 패턴 매쳐는 식 노드(expression nodes)를 다양한 명령어 패턴을 찾기위한 상향식 방식으로 검토하고, 여기서 상기 명령어 패턴은 단일 명령어로 대체될 수 있다. 예를 들어, 사용자 C 프로그램은 다음 문장을 포함한다고 말한다.

x = ( y + z ) 〈〈 2 ;

x2 = (y2 + z2 ) 〈〈 2 ;

상기 패턴 매쳐는 두개의 다른 위치에서 사용자가 두개의 수를 부가하고 왼쪽으로 결과 2 비트를 쉬프팅하는 것을 발견할 것이다. 상기 시스템은 데이터베이스에 TIE 명령어 생성의 가능성을 부가할 것이고, 여기서 TIE 명령어는 두개의 수를 부가하고 왼쪽으로 결과 2 비트를 쉬프팅한다.

구축 시스템(50)은 얼마나 여러번 가능 TIE 명령어가 나타나는지에 대한 총계와 함께 많은 가능 TIE 명령어를 추적한다. 프로파일링 툴을 이용하는 시스템(50)은 또한 얼마나 자주 각각의 명령어가 총 알고리즘의 실행동안 실행되는지를 추적한다. 하드웨어 추정기(estimator)를 이용하는 시스템(50)은 하드에어에서 각각의 포텐셜 TIE 명령어를 구현하는 것이 얼마나 고가인지를 추적한다. 포텐셜 TIE 명령어의 한 세트를 선택하귀 위해서 이들 수는 검색 경험적 알고리즘(search heuristic algorithm)에 공급되고, 여기서 상기 포텐셜 TIE 명령어는 성능, 코드 크기, 하드웨어 복잡성등과 같은 입력 목표를 최대화 한다.

상태를 가진 포텐셜 TIE 명령어를 발견하기 위해서 강력한 알고리즘을 제외한 유사물이 이용된다. 몇몇 다른 알고리즘은 기회(opportunities)의 다른 형태를 감지하는데 이용된다. 어떤 알고리즘은 사용자 프로그램이 하드웨어에서 이용가능한 것보다 더 많은 레지스터를 필요로 한다면 사용자 프로그램을 스캐닝 및 감지하 기 위해서 컴파일러와 유사한 툴을 이용한다. 당 업자라면 알다시피, 이것은 사용자 코드의 컴파일링된 버전에서의 레지스터 스필(spills) 및 재저장(restores)의 수를 셈함으로써 감지될 수 있다. 컴파일러와 유사한 툴은 많은 스필 및 재저장을 구비한 사용자의 코드의 일부에서 단지 이용되는 연산를 지지하는것을 제외하고 부가적인 하드웨어 레지스터(98)와 함께 검색 엔진에 보조연산자를 제안한다. 상기 툴은 사용자의 알고리즘 성능이 얼마나 개량되었는지 측정할 뿐만 아니라 보조연산자의 하드웨어 비용의 측정의 검색 엔진(106)에 의해 이용되는 데이터베이스를 알릴 책임이 있다. 상술한 바 처럼, 검색 엔진(106)은 제안된 프로세서(98)가 더 나은 구성을 끌어내는지 또는 그렇지 못한지에 대한 전체적인 결정을 한다.

대안적으로 또는 그것과 연계하여, 컴파일러와 같은 툴은 임의의 변수들이 임의의 제한보다 더 크지 않음을 보장하기 위하여 사용자 프로그램이 비트-마스크 연산을 사용하는지 여부를 체크한다. 이 경우, 상기 툴은 상기 사용자 제한(예를 들면, 12 비트 또는 20 비트 또는 그 밖의 크기 정수)에 따르는 데이터 형태를 사용하여 코-프로세서(98)를 검색 엔진(106)에 제안한다. 다른 실시예에 사용된 제3알고리즘에 있어서, C++에서의 사용자 프로그램에 사용된, 컴파일러와 같은 툴은 사용자 정의된 추상 데이터 형태상에서 동작하는데 많은 시간이 걸리는 것을 알게 된다. 만일 상기 데이터 형태상에서의 모든 연산이 TIE에 적당하다면, 상기 알고리즘은 상기 데이터 형태상의 모든 연산을 TIE 코프로세서로 구현하는 검색 엔진(106)에 제안한다.

상기 프로세서(60)의 명령어 디코드 로직을 생성하기 위하여, 하나의 신호가 상기 구성 명세내에 정의된 각각의 연산코드에 대하여 생성된다. 상기 코드는,

opcode NAME FIELD = VALUE 선언은 다음의 HDL 문장

assign NAME = FIELD == VALUE 으로;

opcode NAME FIELD = VALUE PARENTNAME [FIELD2 = VALUE2] 은

assign NAME = PARENTNAME & (FIELD == VALUE) 으로 간단히 재기록되어 생성된다.

레지스터 인터록의 생성 및 파이프라인 스톨 신호는 또한 자동화되어 있다. 이 로직은 또한 구성 명세의 정보를 기초로 하여 생성된다. 상기 iclass 문장에 포함된 레지스터 사용 정보 및 상기 명령어의 대기 시간을 기초로 하여, 상기 생성된 로직은 현재 명령어의 소스 피연산자가 완성되지 않은 이전의 명령어의 수신지 피연산자에 의존할 때 스톨(또는 버블)을 삽입한다. 이러한 스톨 기능성을 구현하기 위한 기구는 상기 코어 하드웨어의 부분으로서 구현된다.

오류 명령어 검출 로직은 다음과 같이 그 필드 제약을 갖는 AND된 개별 생성된 명령어 신호들을 함께 NOR 시킴으로써 생성된다:

assign illegalinst = ! (INST1 ｜ INST2... ｜ INSTn);

상기 명령어 디코드 신호 및 오류 명령어 신호는 상기 디코드 모듈의 출력으로서 그리고 손으로 쓰여진 프로세서 로직에 대한 입력으로서 이용가능하다.

다른 프로세서 특징을 생성하기 위하여, 본 실시예는 Perl계 프리프로세서 언어로 강화된 구성가능한 프로세서(60)의 Verilog^TM 기술을 사용한다. Perl은 컴플렉스 제어 구조, 서브루틴 및 I/O 설비를 포함하는 전체-특징 언어(full-featured language)이다. 본 발명의 실시예에서 TPP(부록 B에서 소스 리스팅으로 도시된 바와 같이, TPP는 Perl 프로그램 자체이다)라 불리는 프리프로세서는, 그 입력을 스캔하고, 상기 프리프로세서 언어(TPP용 Perl)로 쓰여진 프리프로세서 코드(TPP용 세미콜론에 의해 프리픽스됨)로서 임의의 라인들을 식별하며, 다른 라인들의 문자를 생성하기 위하여 추출된 라인 및 문장으로 구성된 프로그램을 작성한다. 비-프리프로세서 라인들은 상기 TPP 프로세싱의 결과로서 생성된 그 위치 표시들이 대체되는 내장된 표시들을 가졌을 수 있다. 그 결과로 나온 프로그램은 소스 코드, 즉 상세한 프로세서 로직(40)을 기술하기 위한 Verilog^TM 코드를 생성하도록 실행된다(후술하는 바와 같이, TPP는 소프트웨어 개발 툴(30)을 구성하는데 사용되기도 한다).

이러한 문맥에 사용되면, TPP는 구성 명세 조회, 조건부 표시 및 Verilog^TM 코드내의 반복적 구조 등의 구성의 포함을 허용할 뿐만 아니라, 상술된 바와 같이 Verilog^TM 코드내의 구성 명세(100)에 의존하는 내장된 표시를 구현하기 때문에 강력한 프리프로세싱 언어이다. 예를 들면, 데이터베이스 조회에 기초한 TPP 할당은 다음과 같다.

여기서, config_get_value는 상기 구성 명세(100)에 사용된 TPP 함수이고, IsaMemoryOrder는 상기 구성 명세(100)에서의 플래그 세트이며, $endiandms 상기 Verilog^TM 코드를 생성함에 있어 추후에 사용될 TPP 변수이다.

TPP 조건부 표시는 다음과 같다.

반복적 루프는 다음과 같은 TPP 구조에 의해 구현될 수 있다.

여기서 $i는 TPP 루프 인덱스 변수이고, $ninterrupts는 상기 프로세서(60)에 대해 특정화된 인터럽트의 번호이다(config_get_value를 사용하는 상기 구성 명세(100)로부터 얻어짐).

최종적으로, TPP 코드는 다음과 같은 Verilog^TM 표시내로 내장될 수 있다.

여기서,

$ninterrupts는 인터럽트의 넘버를 정의하고, 상기 xtscenflop 모듈(플립-플롭 원시 모듈)의 폭(비트로 환산)을 결정하며;

srInterruptEn은 적절한 수의 비트의 와이어로 정의될, 플립-플롭의 출력이고;

srDataIn_W은 플립-플롭에 대한 입력이지만, 단지 관계있는 비트들만이 인터 럽트의 넘버에 기초한 입력이며;

srIntrEnWEn은 플립-플롭의 쓰기 인에이블이고;

cReset은 플립-플롭에 대한 클리어 입력이며;

CLK는 플립-플롭에 대한 입력 클럭이다.

예를 들면, TPP에 대한 입력은 다음과 같이 주어지고,

상기 선언은,

이다.

TPP는 다음을 생성한다.

따라서, 상기 HDL 기술(114)은 예를 들면 블럭(122)의 Synopsys사에서 제조된 DesignCompiler^TM을 사용하여 프로세서 구현을 하기 위하여 하드웨어를 합성하는데 사용된다. 그 후, 상기 결과는 예를 들면 Cadence사의 Silicon Ensemble^TM 또는 Avant!사의 Apollo^TM을 사용하여 배치되고 라우팅된다. 일단 상기 구성요소가 라우팅되었으면, 상기 결과는 예를 들어 Synopsys사의 PrimeTime^TM을 사용하여, 블럭(132)의 백-주석(back-annotation) 및 타이밍 검증에 사용될 수 있다. 이러한 프로세스의 생성물은 추가 구성 반복문에 대한 구성 캡쳐 루틴(20)으로 추가 입력을 제공하기 위하여 사용자에 의해 사용될 수 있는 하드웨어 프로파일(134)이다.

로직 합성 섹션(122)과 연계하여 언급된 바와 같이, 구성중인 프로세서(60)의 성과 중의 하나는 소정의 여러 상업적인 합성 툴을 사용함으로써 얻어질 수 있는 특정 게이트-레벨 구현으로부터 한 세트의 맞춤으로 만들어진 HDL 파일이다. 이러한 툴 중의 하나는 Synopsys의 Design Compiler^TM이다. 정확하고 고성능의 게이트-레벨 구현을 보장하기 위하여, 본 실시예는 고객 환경에 있어서 합성 프로세스를 자동화하는데 필요한 스크립트를 제공한다. 이러한 스크립트를 제공하는데 있어서의 목적은 광범위한 각종 합성 방법론 및 사용자의 상이한 구현 목적들을 지지하는 것이다. 첫번째 목적을 말하기 위하여, 본 실시예는 상기 스크립트를 더 작고 기능적으로 완성된 스크립트로 분해한다. 이러한 예시 중의 하나는 독특한 프로세서 구성(60)에 대한 전체 HDL 파일을 읽을 수 있는 읽기 스크립트, 상기 프로세서(60)에 있어 고유한 타이밍 요구를 설정하기 위한 타이밍 제약조건 스크립트 및 게이트-레벨 네트리스트의 배치 및 라우팅에 사용될 수 있는 방식을 초래하는 쓰기 아웃 합성(write out synthesis)에 대한 스크립트를 제공하는 것이다. 두번째 목적을 말하기 위하여, 본 실시예는 각각의 구현 목적을 위하여 스크립트를 제공한다. 이러한 예시 중의 하나는 가장 빠른 사이클 타임을 달성하기 위한 스크립트, 최소 실리콘 면적을 달성하기 위한 스크립트 및 최소 전력 소비를 달성하기 위한 스크립트를 제공하는 것이다.

스크립트는 또한 프로세서 구성의 다른 단계에서도 사용된다. 예를 들면, 일단 프로세서(60)의 HDL 모델이 쓰여졌다면, 시뮬레이터는 블럭(122)과 연계하여 상술한 바와 같이, 프로세서(60)의 교정 연산을 검증하는데 사용될 수 있다. 이것은 종종 시뮬레이팅된 프로세서(60)상에서 많은 테스트 프로그램 또는 진단을 실행함으로써 달성된다. 상기 시뮬레이팅된 프로세서(60)상에서 테스트 프로그램을 실행하는 것은 상기 테스트 프로그램의 실행가능한 이미지를 생성하는 것과 상기 시뮬레이터(112)에 의해 읽혀질 수 있는 이러한 실행가능한 이미지의 표시를 생성하는 것, 시뮬레이션의 결과들이 미결정 분석을 위하여 모여질 수 있는 임시 장소를 만드는 것, 상기 시뮬레이션의 결과들을 분석하는 것 등과 같은 많은 단계들을 요구할 수 있다. 종래 기술에 있어서, 이것은 많은 스로우-어웨이 스크립트(throw-away scripts)로 행해졌다. 이들 스크립트는 어떤 HDL 파일이 포함될 것인가, 그 파일들은 디렉토리 구조내 어디서 찾을 수 있는가, 어떤 파일들이 테스트 벤치를 요구하는가 등의 상기 시뮬레이션 환경의 내장된 일부 지식을 구비하였다. 현재 설계에 있어서, 바람직한 기구는 파라미터 대체에 의해 구성되는 스크립트 템플리트를 쓰는 것이다. 상기 구성 기구는 또한 시뮬레이션에 요구되는 상기 파일들의 리스트를 생성하기 위하여 TPP를 사용한다.

더 나아가, 블럭(132)의 검증 프로세서에 있어서, 설계자로 하여금 일련의 테스트 프로그램을 실행하도록 하는 다른 스크립트를 쓰는 것이 종종 필요하다. 이것은 HDL 모델에서 주어진 변화는 새로운 버그를 도입하지 않는 설계자 신뢰(designer confidence)를 주는 회귀 수트(regression suites)를 실행하는데 종종 사용된다. 이들 회귀 스크립트들은 또한 파일 이름, 위치 등에 대한 많은 내장 가정(many built-in assumptions)을 가지는 것에 따라 종종 스로우-어웨이(throw-away) 하였다. 단일 테스트 프로그램에 대한 실행 스크립트의 작성을 위하여 상술한 바와 같이, 회귀 스크립트는 템플리트로서 쓰여진다. 이 템플리트는 구성 시간에 실제 값들에 대한 파라미터들을 대체함으로써 구성된다.

RTL 기술을 하드웨어 구현으로 변환하는 프로세서에 있어 최종 단계는 상기 추상적 네트리스트를 기하학적 표시로 변환하기 위하여 배치 및 라우트(P&R) 소프트웨어를 사용하는 것이다. 상기 P&R 소프트웨어는 상기 네트리스트의 연결성을 분석하고, 상기 셀의 배치를 결정한다. 그 후, 전체 셀들 간의 연결들을 묘사하기 위해 시도한다. 상기 클럭 네트는 보통 특별한 주의(special attention)를 받을 만하고, 마지막 단계로서 라우팅된다. 이 프로세스는 상기 툴에 예를 들면 어떤 셀이 서로 근접하게 될 것이 예상되는지(소프트 그룹핑으로 알려짐), 셀의 상대 배치, 어떤 네트가 작은 전파 지연을 가지는 것이 예상되는지 등의 소정의 정보를 제공함으로써 둘 모두에 도움을 줄 수 있다.

이 프로세스를 더 쉽게 하기 위하여 그리고 소정의 성능 목표를 보장하기 위해서는, --사이클 시간, 면적, 전력 소산(消散)-- 을 만족해야 한다. 상기 구성 기구는 상기 P&R 소프트웨어에 대한 한 세트의 스크립트 또는 입력 파일을 생성한다. 이들 스크립트는 셀에 대한 상대 배치 등의 상술한 바와 같은 정보를 포함한다. 이 스크립트는 또한 얼마나 많은 서플라이 및 그라운드 연결이 요구되는지, 이들이 어떻게 바운더리를 따라 분포되어야 하는지 등의 정보도 포함한다. 상기 스크립트는 얼마나 많은 소프트 그룹을 만들어야 하는지 및 어떤 셀이 그 안에 포함되어야 하는지, 어떤 네트가 타이밍 임계인지 등의 정보를 포함하는 데이터베이스를 조회함으로써 생성된다. 이들 파라미터는 어떤 옵션이 선택되어지는 가에 기초하여 변화된다. 이들 스크립트는 배치 및 라우트를 하기 위해 사용될 툴들에 의존하여 구성가능해야 한다.

선택적으로 상기 구성 기구는 사용자로부터 더 많은 정보를 요청하여, 그것을 상기 P&R 스크립트로 패스할 수 있다. 예를 들어, 상기 인터페이스는 최종 레이아웃의 소정의 가로세로비, 얼마나 많은 버퍼링의 레벨들이 클럭 트리에 삽입되어야 하는지, 입력 및 출력핀이 어느쪽에 배치되어야 하는지, 이들 핀의 상대 또는 절대 배치, 전력 및 그라운드 스트랩의 폭과 위치 등을 사용자에게 물을 수 있다. 그 후, 이들 파라미터는 소정의 레이아웃을 생성하도록 상기 P&R 스크립트로 패스된다.

더욱 복잡한 스크립트가 사용될 수도 있는데, 예를 들면 더욱 복잡한 클럭 트리를 허용하는 것이다. 전력 소산을 줄이기 위해 행해진 공통 최적화 중 하나는 클럭 신호를 게이팅하는 것이다. 그러나, 이것은 모든 분기들의 지연을 균형 맞추기가 매우 어렵기 때문에 매우 어려운 문제인 클럭 트리 합성을 만든다. 상기 구성 인터페이스는 사용자에게 클럭 트리 및 상기 클럭 트리 합성의 성능부 또는 전체를 사용하기 위한 교정 셀을 요청할 수 있다. 상기 게이팅된 클럭들이 설계에 있어서 어디에 배치되는지에 관한 소정의 지식을 구비하고, 한정 게이트(qualifying gate)로부터 플립-플롭의 클럽 입력으로의 지연을 예측함으로써 이것을 행할 것이다. 제약 조건을 클럭 트리 합성 툴에 주는 것보다 클럭 버퍼의 지연을 게이팅 셀의 지연과 매칭시킬 것이다. 현재 구현에 있어서, 이것은 범용 Perl 스크립트에 의해 행해진다. 이 스크립트는 어떤 옵션들이 선택되는지에 따라 구성 에이전트에 의해 생성된 게이팅된 클럭 정보를 읽는다. 상기 Perl 스크립트는 일단 상기 설계가 배치되고 라우팅되었으면 실행되지만, 최종 클럭 트리 합성 전에 행해진다.

상술된 프로파일 프로세스는 또 다른 개선을 이룰 수 있다. 특별히, 사용자가 CAD 툴을 몇시간 동안 실행시키지 않고도 거의 즉각적으로 유사한 하드웨어 프로파일 정보를 얻을 수 있는 프로세스를 설명한다. 이 프로세스는 몇가지 단계를 가진다.

이 프로세스의 제1단계는 상기 하드웨어 프로파일상의 그룹에서의 옵션의 효과가 기타 그룹에서의 옵션에 독립적이도록, 전체 구성 옵션의 세트를 직교 옵션(orthogonal options)의 그룹으로 분할하는 것이다. 예를 들면, 하드웨어 프로파일에 대한 MAC16 유닛의 임팩트는 기타 옵션에 독립적이다. 그래서, 상기 MAC16 옵션만을 갖는 옵션 그룹이 형성된다. 더욱 복잡한 예시는 인터럽트 옵션, 하이-레벨 인터럽트 옵션 및 타이머 옵션을 포함하는 옵션 그룹인데, 이는 상기 하드웨어 프로파일상의 임팩트가 이들 옵션의 특별한 조합에 의해 결정되기 때문이다.

제2단계는 각 옵션 그룹의 하드웨어 프로파일 임팩트를 캐릭터라이즈 (characterize)하는 것이다. 상기 캐릭터화는 상기 그룹내 옵션의 다양한 조합에 대한 하드웨어 프로파일 임팩트를 얻음으로써 행해진다. 각각의 조합을 위하여, 상기 프로파일은 실제 구현이 도출되어 그 하드웨어 프로파일이 측정되는 전술된 프로세스를 이용하여 얻어진다. 이러한 정보는 추정 데이터베이스내에 저장된다.

마지막 단계는 커브 핏팅 및 인터폴레이션 기술을 사용하는 옵션 그룹내 옵션의 특별한 조합에 의해 하드웨어 프로파일 임팩트를 계산하기 위한 특수 공식을 도출하는 것이다. 상기 옵션의 성질에 따라, 상이한 공식이 사용된다. 예를 들면, 각각의 추가 인터럽트 벡터는 거의 동일한 로직을 상기 하드웨어에 더하기 때문에, 그 하드웨어 임팩트를 모델링하기 위한 선형 함수를 사용한다. 다른 예시에서는, 높은 우선순위 인터럽트 옵션을 요구하는 타이머 유닛을 가지므로, 상기 타이머 옵션의 하드웨어 임팩트에 대한 공식은 수 개의 옵션을 포함하고 있는 조건부 공식이다.

그것은 구조적인 선택이 런타임 성능 및 응용프로그램의 코드 크기에 얼마나 영향을 줄 수 있는지에 퀵 피드백을 제공하는데 유용하다. 다중 응용프로그램 도메인으로부터의 벤치마크 프로그램의 수 개의 세트들이 선택된다. 각각의 도메인을 위해서, 상이한 구조 설계 결정이 도메인내의 응용프로그램의 코드크기와 실행시간 성능에 얼마나 영향을 미치는지를 추정하는 데이터베이스가 미리 구축된다. 사용자가 구조 설계를 변화시키기 때문에, 데이터베이스는 사용자의 흥미를 갖게하는 응용프로그램 도메인용으로 또는 다중 도메인용으로 조회된다. 평가의 결과가 사용자에게 제시될 수 있어서, 사용자는 소프트웨어 이점과 하드웨어 비용 사이의 타협을 추정할 수 있다.

빠른 평가 시스템은 프로세서를 더욱 최적화하기 위한 구성을 수정하는 방법을 사용자에게 제안하기 위해 쉽게 확장될 수 있다. 일련의 수가 영역, 지연, 및 승(power)등의 다양한 비용 측정기준상의 옵션의 점증적인 효과를 나타낼 때 하나의 이러한 예시는 각각의 구성 옵션을 결합하는 것이다. 주어진 옵션을 위한 점증적 비용 효과를 계산하는 것은 빠른 평가 시스템으로 쉽게 이루어진다. 옵션이 있건 없건 평가 시스템에서는 간단히 두 개의 호출을 포함한다. 두 가지 평가에서의 비용 차이는 옵션의 점증적 효과를 나타낸다. 예를 들어, MAC16 옵션의 점증적 영역 효과는 MAC16 오션이 있건 없건 두 가지 구성의 영역 비용을 평가함으로써 계산된다. 그 후, 차이는 대화식 구성 시스템에서의 MAC16 옵션으로 표시된다. 이러한 시스템은 일련의 단일-단계 개선을 통해 사용자를 최적 해결책으로 안내할 수 있다.

소프트웨어쪽의 자동화된 프로세서 구성 프로세스에 대한 조치로, 본 발명의 실시예는 그것들은 프로세서에 특정화되도록 소프트웨어 개발 툴(30)을 구성한다. 구성 프로세서는 상이한 시스템과 명령어 집합 구조의 다양성에 포트될 수 있는 소프트웨어 툴(30)로 시작한다. 이러한 재목표가능한 툴은 본 기술에서 널리 연구되고 잘 알려져 있다. 이러한 실시예는 소프트웨어 없이 예를 들어, GNU C 컴파일러, GNU 어셈블러, GNU 디버거, GNU 링커, GNU 프로파일러, 및 다양한 유틸리티 프로그램을 포함하는 툴의 GNU 패밀리를 사용한다. 그 후 이들 툴(30)은 ISA 기술로부터 직접 소프트웨어 부분을 생성하고 직접 기록된 소프트웨어 부분을 수정하도록 TPP를 사용하여 자동 구성된다.

GNU C 컴파일러는 여러가지 상이한 방식으로 구성된다. 코어 ISA 기술이 주어질 때, 컴파일러에서 많은 기계-독립 논리가 직접 기록될 수 있다. 컴파일러의 이러한 부분은 구성가능한 프로세서 명령어 집합의 모든 구성에 일반적이고, 직접 재목표화하는 것은 가장 좋은 결과를 위한 양질의 변화(fine-turning)를 허용한다. 그러나, 컴파일러의 이러한 핸드-코드된 부분에서 조차, 어떤 코드는 ISA 기술로부터 자동적으로 생성된다. 상세히 말하자면, ISA 기술은 다양한 명령어의 즉시 필드에서 사용될 수 있는 상수 값의 세트를 정의한다. 각각의 즉시 필드를 위해서, 술어 함수는 특정 상수값이 상기 필드에서 인코딩될 수 있을 때 테스트하기 위해 생성될 수 있다. 컴파일러는 프로세서(60)용 코드를 생성할 때 이들 술어 함수를 사용한다. 컴파일러 구성의 이러한 특성을 자동화하는 것은 ISA 기술과 컴파일러 사이의 불일치에 대한 조건을 제거하고, 가능한한 적은 노력으로 ISA에서의 상수를 변화시킬 수 있다.

컴파일러의 여러가지 특성들은 TPP를 갖는 전 프로세싱(preprocessing)을 통해 구성된다. 파라미터 섹션에 의해 제어된 구성 옵션을 위해서, TPP를 통해 컴파일러내의 대응 파라미터가 설정된다. 예를 들어, 목표 프로세서(60)가 큰 엔디안 또는 작은 엔디안 바이트 순서를 사용하는지를 나타내기 위해 플래그 변수를 갖고, 이러한 변수는 구성 명세(100)로부터 엔디안니스 파라미터를 판독하는 TPP 명령어를 사용하여 자동적으로 설정된다. TPP는 또한 구성 명세(100)에서 대응 패키지가 가능한지 안 한지를 기초로 선택 ISA 패키지용 코드를 생성하는 컴파일러의 핸드- 코드된 부분을 조건적으로 허가 또는 금지하기 위해 사용된다. 예를 들어, 다중/누적 명령어를 생성하기 위한 코드는 단지 구성 명세가 MAC16옵션(90)을 포함할 때 컴파일러내에 포함된다.

컴파일러는 또한 TIE 언어를 통해 특징지워진 설계자-정의된 명령어를 지지하기 위해 구성된다. 이러한 서포트에 대한 두 가지 레벨이 있다. 최저레벨에서, 설계자-정의된 명세는 컴파일된 코드에서 매크로, 내장 함수, 또는 인라인(외장)함수로서 이용가능하다. 본 발명의 이러한 실시예는 "인라인 어셈블리" 코드(CPU 컴파일러의 표준 특징)로서 인라인 함수를 정의하는 C 헤더 파일을 생성한다. 설계자-정의된 연산코드의 TIE 명세와 그것들의 대응 피연산자가 주어질 때, 이러한 헤더 파일을 생성하는 것은 GNU C 컴파일러의 인라인 어셈블리 구문으로 번역하는 직선전방 프로세스이다. 대안적인 구현은 인라인 어셈블리 명령어를 특정화하는 C 전 처리기를 포함하는 헤더 파일을 작성한다. 그러나, 또다른 대안은 내장 함수를 컴파일러 내에 직접 부가하도록 TPP를 사용한다.

설계자-정의된 명령어용 서포트의 제2레벨은 명령어를 사용하는 기호를 자동 인식하는 컴파일러를 갖음으로써 제공된다. 이들 TIE 명령어들은 사용자에 의해 직접 정의되거나 구성 프로세서시 자동적으로 작성될 수 있다. 사용자 응용프로그램을 컴파일링하기에 앞서, TIE 코드는 자동적으로 검사되고 C 등가 함수에서 변환된다. 이것은 TIE 명령어의 빠른 시뮬레이이션을 허용하기 위해 사용되는 동일한 단계이다. C 등가 함수는 컴파일러에 의해 사용된 트리-베이스된 중간 표시내로 부분 컴파일된다. 각각의 TIE 명령어용 표시는 데이터베이스내에 저장된다. 사용자 응용 프로그램이 컴파일될 때, 번역 프로세서의 부분은 패턴 매처(matcher)가 된다. 사용자 응용프로그램은 트리- 베이스된 중간 표시로 컴파일된다. 패턴 매처는 사용자 프로그램에서 상향식 모든 모든 트리를 검토한다. 검토의 각각의 단계에서, 현재 포인트에서 루트된 중간 표시가 데이터베이스내의 TIE 명령어의 일부에 매치하는지를 패턴 매처가 검사한다. 거기에 매치가 있다면, 매치가 표시된다. 각각의 트리를 검토하는 것이 완료된 후, 최대 크기의 매치 세트가 선택된다. 트리에서 각각의 최대 매치는 등가 TIE 명령어로 대체된다.

상술된 알고리즘은 상태없는 TIE 명령어를 사용하기 위해 자동적으로 조건을 인식할 것이다. 부가적인 접근은 또한 상태를 갖는 TIE 명령어를 사용하기 위해 자동적으로 조건을 인식하기 위해 사요될 수 있다. 이전의 섹션은 상태를 갖는 잠재적인 TIE 명령어를 자동적으로 선택하는 알고리즘을 기술했다. 동일한 알고리즘은 C 또는 C++ 응용프로그램에서 TIE 명령어를 자동적으로 사용하기 위해 사용된다. TIE 코프로세서가 연산의 한정된 세트를 제외하고 더 많은 레지스터를 갖도록 정의될 때, 그것들이 레지스터 스필링(spilling)을 겪는지 그리고 이들 영역들이 이용가능한 연산 세트를 단지 사용하는지를 알아보기 위해 코드의 영역이 스캔된다. 이러한 영역들이 발견되면, 이들 영역에서의 코드는 자동적으로 코프로세서 명령어들과 레지스터(98)을 사용하도록 변경된다. 변환 연산은 코프로세서(98)의 내부와 외부의 데이터를 이동시키기 위해 그 영역의 경계에서 생성되었다. 유사하게, TIE 코프로세서가 상이한 크기 정수들상에서 작업하도록 정의된다면, 코드의 영역은 마치 그것이 상이한 크기일 때처럼 영역내의 모든 데이터가 액세스되는지를 알아보기 위 해 검사된다. 매칭 영역을 위해서, 코드는 변경되고 글루 코드(glue code)가 상기 경계에서 부가된다. 유사하게, TIE 코프로세서(98)가 C++ 추상적 데이터 형을 구현하기 위해 정의된다면, 이러한 데이터 형에서 모든 연산들은 TIE 코프로세서 명령어와 대체된다.

TIE 명령어를 자동적으로 제안하고 TIE 명령어를 자동적으로 사용하는 것은 모두 독립적으로 유용하다. 제안된 TIE 명령어는 또한 내장 기구를 통해 사용자에 의해 수동식으로 사용될 수 있고 알고리즘을 사용하는 것은 수동적으로 설계된 TIE 명령어 또는 코프로세서(98)에 이용될 수 있다.

설계자-설계된 명령어가 어떻게 생성되는지에 관계없이, 인라인 함수를 통해 또는 자동 인식에 의해, 컴파일러는 그것이 이러한 명령어들을 최적화하고 스케줄화 할 수 있도록 설계자-정의된 명령어의 잠재적인 부작용을 알 필요가 있다. 성능을 개선시키기 위해서, 구식 컴파일러는 실행-시간 성능, 코드 크기 또는 전력 소비등의 소망하는 특성들을 최적화시키기 위해 사용자 코드를 최적화할 수 있다. 당업자들에게 알려진 바와 같이 이러한 최적화는 명령어를 재배열 또는 어떤 명령어들을 다른, 의미론으로 등가 명령어로 대체하는 것 등을 포함한다. 또한 최적화를 실행시키기 위해서, 컴파일러는 모든 명령어가 기계의 상이한 부분에 얼마나 영향을 미치는지를 알아야 한다. 기계의 상이한 부분을 판독 및 기록하는 두 명령어들은 자유롭게 재정렬될 수 있다. 기계 상태의 동일한 부분을 엑세스하는 두 명령어들은 항상 재정렬될 수 없다. 구식 프로세서용으로, 상이한 명령어들에 의해 판독 및/또는 기록된 상태는 때때로 테이블에 의해, 컴파일러 내에서 하드웨어된다. 본 발명의 일실시예에서, TIE 명령어들은 프로세서(60)의 모든 상태를 판독 및 기록하기 위해 보수적으로 가정된다. 이것은 컴파일러로 하여금 정확한 코드를 발생시키게 하지만 TIE 명령어에 직면하여 코드를 최적화시키기 위해서 컴파일러의 성능을 제한한다. 본 발명의 또다른 실시예에서, 자동적으로 툴은 TIE 정의를 판독하고 각각의 TIE 명령어에서는 상태가 상기 명령어에 의해 판독 또는 기록되는지를 발견한다. 그 후, 이러한 툴은 각각의 TIE 명령어의 효과를 정확하게 모델하기 위해 컴파일러의 최적화기에 의해 사용된 테이블을 수정한다.

컴파일러와 같이, 어셈블러(110)의 기계-종속부는 TPP 로 구성된 핸드-코드된 부분과 자동적으로 생성된 부분 모두를 포함한다. 모든 구성에서 공통적인 특성들 중 일부는 직접 쓰여진 코드로 지지된다. 그런, 어셈블러(110)의 주 작업은 기계 명령어를 인코드하는 것이고, 명령어 인코딩과 디코딩 소프트웨어는 ISA 기술로부터 자동적으로 생성될 수 있다.

명령어 인코딩과 디코딩이 여러가지 상이한 소프트웨어 툴에서 유용하기 때문에, 본 발명의 이러한 실시예는 이들 작업을 분리된 소프트웨어 라이브러리로 실행시키기 위해서 소프트웨어를 그룹화한다. 이러한 라이브러리는 ISA 기술의 정보를 사용하여 자동적으로 생성된다. 라이브러리는 연산 코드의 열거, 열거의 맴버들상에 연산코드 의사기호용 문자열(strindToOpcode)을 효과적으로 맵하기 위한 함수, 및 각각의 연산코드에서는 명령어길이(instructionLength), 피연산자의 수 (numberOfOperands), 피연산자 필드, 피연산자 형(즉, 레지스터 또는 즉시) (operandType), 2진법 인코딩(encodeOpcode), 및 의사기호 문자열(opcodeName)을 특정화하는 테이블을 정의한다. 각각의 피연산자에서, 라이브러리는 명령 단어에서 대응하는 비트를 인코드(fieldSetFunction) 및 디코드(fieldGetFunction)하기 위한엑세서 함수를 제공한다. 이러한 정보의 모두는 ISA 기술에서 쉽게 이용가능한다.라이브러리 소프트웨어를 발생시키는 것은 단지 정보를 실행가능한 C코드로 번역하는 하는 문제이다. 예를 들어, 명령어 인코딩은 각각의 연산코드 필드를 각 엔트리가 ISA 기술에서 명령어용으로 특정화된 값으로 설정함으로써 발생하는 특정 명령어를 인코딩하는 C 배열 변수에서 기록된다. encodeOpcode 함수는 주어진 연산코드용 배열값을 간단히 리턴한다.

또한, 라이브러리는 2진법 명령어내의 연산코드를 디코드(decodeIn-struction)하기 위한 함수를 제공한다. 이러한 함수는 중첩된 switch 문장에 대한 순서로 생성되고, 여기서, 가장 바깥쪽의 스위치는 연산코드 계층의 맨 위에서 서브연산코드 필드를 테스트하고, 상기 중첩된 switch 문장은 연산코드 계층에서 차츰 더 아래로 서브연산코드를 테스트한다. 따라서, 이러함 함수용으로 생성된 코드는 연산코드 계층 그 자체와 동일한 구조를 갖는다.

명령어를 인코딩 및 디코딩하는 이러한 라이브러리가 주어질 때, 어셈블러 (110)는 쉽게 구현된다. 예를 들어, 어셈블러에서 명령어 인코딩 논리는 아주 간단 하다.

이진법 명령어를 어셈블리 코드와 거의 비슷한 판독하기 쉬운 형태로 번역하 는 역어셈블러(110)가 동시에 직접 구현된다.

이 디스어셈블러 알고리즘은 자립적 디스어셈블러 툴에서 사용되며 기계어 코드의 디버깅을 지원하기 위해서 디버거(130)에서도 사용된다.

링커는 컴파일러 및 어셈블러(110)에 비하여 구성에 덜 민감하다. 링커의 대부분은 표준이며 기계-의존부(machine-dependent portion)는 주로 코어 ISA 기술에 의존하고 특정 코어 ISA에 대하여는 핸드-코딩될 수 있다. 엔디안니스(endianness)와 같은 파라미터는 TPP를 사용하는 구성 명세(100)로부터 설정된다. 목표 프로세서(60)의 메모리 맵은 링커가 필요로 하는 구성의 다른 형태중 하나이다. 전술한 바와 같이, 메모리 맵을 지정하는 파라미터는 TPP를 사용하는 링커에 삽입된다. 본 발명의 본 실시예에서, GNU 링커는 한 세트의 링커 스크립트에 의하여 구동되며, 메모리 맵 정보를 포함하고 있는 것은 이들 링커 스크립트이다. 이러한 접근의 장점은 목표 시스템의 메모리 맵이 프로세서(60)가 구성되었을 때 정해진 메모리 멥과 다른 경우, 프로세서(60)를 재구성하지 않고 또 링커를 재건축하지 않고도 나중에 추가적인 링커 스크립트가 생길 수 있다는 것이다. 따라서, 본 실시예는 상이한 메모리 맵 파라미터를 가지고 신규 링커 스크립트를 구성하기 위한 툴을 구비한다.

디버거(130)는 그것이 실행하는 프로그램의 상태를 관찰하기 위해서, 한번에 하나의 실행 명령어를 싱글-스텝으로 하기 위해서, 정지점(breakpoint)을 도입하기 위해서, 그리고 다른 표준 디버깅 태스크를 수행하기 위해서 제공된다. 디버깅된 프로그램은 구성된 프로세서의 하드웨어 구현에 따라, 또는 ISS(126)에 따라 실행될 수 있다. 디버거는 어느 경우에도 사용자에게 동일한 인터페이스를 표현한다. 프로그램이 하드웨어 구현에 따라 실행될 때에는 사용자 프로그램의 실행을 제어하고 시리얼 포트를 통해 디버거와 의사소통하기 위해서 작은 모니터 프로그램이 포함된다. 프로그램이 시뮬레이션(126)상에서 실행될 때에는 시뮬레이션(126) 그 자체가 그러한 기능을 수행한다. 디버거(130)는 몇 가지 방식으로 구성에 의존한다. 그것은 디버거(130) 내부로부터의 디스어셈블링 기계어 코드를 지원하기 위해서 상술한 바와 같은 명령어 인코딩/디코딩 라이브러리와 함께 링크된다. 프로세서의 레지스터 상태를 디스플레이하는 디버거(130)의 부분과, 디버거(130)에 그 정보를 제공하는 ISS(126) 및 디버그 모니터 프로그램의 부분은 프로세서(60)내에 레지스터 가 존재하는 지를 알아내기 위하여 ISA 기술을 스캐닝함으로써 생성된다.

다른 소프트웨어 개발 툴(30)은 표준이며 각각의 프로세서 구성을 위하여 변화될 필요는 없다. 프로파일 뷰어 및 각종 유틸리티 프로그램은 이 카테고리 안에 떨어진다. 이들 툴은 프로세서(60)의 모든 구성이 공유하는 바이너리 포맷으로 파일에 동작하기 위해서 일단 리타켓팅될 필요가 있지만, 그들이 ISA 기술이나 구성 명세(100)내의 그 밖의 파라미터에 의존하지는 않는다.

구성 명세는 도 7에 도시된 ISS(126)라고 불리우는 시뮬레이터를 구성하는 데에도 사용된다. ISS(126)는 구성가능한 프로세서 명령어 세트의 함수적 동작을 모델링하는 소프트웨어 응용프로그램이다. Synopsys VCS 및 Cadence Verilog XL와 NC 시뮬레이터와 같은 그것의 카운터파트 프로세서 하드웨어 모델 시뮬레이터와는 다르게, ISS HDL 모델은 그것의 명령어 실행 중에 CPU의 추상화(abstraction)이다. ISS(126)은 그것이 완벽한 프로세서 설계에서의 레지스터 및 모든 게이트에 대한 모든 신호 변환을 모델링할 필요는 없기 때문에 하드웨어 시뮬레이션보다 더 빠르게 실행할 수 있다.

ISS(126)는 구성된 프로세서(60)를 위하여 생성된 프로그램이 호스트 컴퓨터에서 실행되게 한다. 그것은 장치 드라이버 및 초기화 코드와 같은 낮은 레벨 프로그램이 개발되게 하는 인터럽트 동작 및 프로세서의 리셋을 정확히 재생산한다. 이것은 원시 코드를 내장된 응용프로그램에 포팅(porting)할 때에 특히 유용하다.

ISS(126)는 구조적 가정, 메모리 순서 고려(memory ordering consideration) 등과 같은 잠재적인 문제들을 실제 내장된 목표에 대한 코드를 다운로드하지 않고 도 식별하는 데에 사용될 수 있다.

본 실시예에서, ISS 의미론은 명령어를 함수로 바꾸는 C 연산자 빌딩 블럭을 구축하기 위해서 C와 같은 언어를 사용하여 문자로 표현된다. 예를 들어, 인터럽트 레지스터, 비트 세팅, 인터럽트 레벨, 벡터 등과 같은 인터럽트의 기초적인 기능성(rudimentary fuctionality)은 이 언어를 사용하여 모델링된다.

구성가능한 ISS(126)는 다음의 4가지 목적이나 시스템 설계 및 검증 프로세스의 부분으로서 목적을 위해 사용된다.

-- 하드웨어가 사용 가능해지기 전 소프트웨어 응용프로그램 디버깅;

-- 시스템 소프트웨어(예를 들어, 컴파일러 및 운영체제 구성요소) 디버깅;

-- 하드웨어 설계 검증을 위한 HDL 시뮬레이션과의 비교. ISS는 ISA의 기준 구현으로서 역할한다. -- 상기 ISS 및 프로세서 HDL은 모두 프로세서 설계 검증 중에 진단 및 응용프로그램을 위해 실행되고, 두 개로부터의 추적이 비교된다; 및

-- 소프트웨어 응용프로그램 성능 분석(이것은 구성 프로세스의 일부일 수도 있고, 프로세서 구성의 선택이 완료된 후 또 다른 응용프로그램 튜닝을 위해 그것이 사용될 수도 있다).

전체 목표는 ISS(126)가 구성가능한 어셈블러(110)와 링커로 만들어진 프로그램을 로딩하고 디코딩할 수 있을 것을 요구한다. 그들은 또한 명령어의 ISS 실행이 의미론적으로 대응하는 하드웨어 실행과 컴파일러의 기대치에 등가가 될 것을 요구한다. 이러한 이유로 하여, ISS(126)는 하드웨어 및 시스템 소프트웨어를 정의하는데 사용된 동일한 ISA 파일로부터 그것의 디코드와 실행 동작을 도출한다.

상기 열거된 첫 번째 목표와 마지막 목적을 위해서는, ISS(126)가 필요한 정확성을 위하여 가능한 빨라야 하는 것이 중요하다. 따라서 ISS(126)는 시뮬레이션의 세부사항의 수준에서 동적 제어를 가능하게 한다. 예를 들어, 캐시 디테일은 요청하지 않은 이상 모델링되지 않으며, 캐시 모델링은 동적으로 꺼지고 켜질 수 있다. 덧붙여, ISS(126)의 부분(예를 들어, 캐시 및 파이프라인 모델)은 ISS(126)가 컴파일링되기 전에 구성되어 ISS(126)가 런타임시 동작의 구성-의존 선택(configuration-dependent choice)을 거의 드물게 한다. 이 방식에서, 모든 ISS 구성가능한 동작은 시스템의 다른 부분에 관련된 잘 정의된 소스로부터 도출된다.

열거된 첫 번째 및 세 번째 목표를 위해서는, 운영 체계 서비스가 시스템 언더 설계(system under design)(목표)를 위해 OS로부터 아직 이용 가능하지 않은 때에 응용프로그램에 그 운영 체계 서비스를 제공하는 것이 중요하다. 또한 이들 서비스는 그 때에 디버깅 프로세스의 관련 부분인 목표 OS에 의하여 제공되는 것이 중요하다. 이 방식에서, 시스템은 이들 서비스가 ISS 호스트와 시뮬레이션 목표의 사이에서 유연하게 움직이게 하는 설계를 제공한다. 현재의 설계는 ISS 동적 제어(트래핑 SYSCALL 명령어가 턴 온 및 오프될 수 있음)와, 호스트 OS 서비스를 요청하기 위해서 특수 SIMCALL 명령어의 사용에 달려있다.

마지막 목표는 ISS(126)가 ISA에 의하여 지정된 레벨의 아래에 있는 시스템 동작 및 프로세서의 특정 형태를 모델링할 것을 요구한다. 특히, ISS 캐시 모델은 구성 데이터베이스(100)로부터 파라미터를 추출하는 Perl 스크립트로부터의 모델에 대하여 C 코드를 생성함으로써 구축된다. 또한, 명령어의 파이프라인 동작의 디테일(예를 들어, 레이스터 사용과 기능적 유닛 가용성 요구에 기초한 인터록(interlock))도 구성 데이터베이스(100)로부터 도출된다. 현재 구현에 있어서, 특수 파이프라인 기술 파일은 리스프형 구문(lisp-like syntax)내에 이 정보를 지정한다.

세 번째 목표는 인터럽트 동작의 정밀한 제어를 요구한다. 이 목적을 위하여, ISS(126)내의 특수 비-구조적 레지스터(special non-architectural register)가 인터럽트 기능을 억제하는 데에 사용된다.

ISS(126)는 그 용도에 따라 상이한 목표를 지원하기 위해서 수 개의 인터페이스를 제공한다:

-- 일괄 또는 명령 라인 모드(일반적으로 첫 번째 및 마지막 목표와 함께 연결하여 사용됨);

-- 예를 들어, 정지점, 감시점(watchpoint), 스텝 등과 같은, 네 개의 모든 목표를 위하여 자주 사용되는 비-기호 디버그 능력을 제공하는 명령 루프 모드; 및

-- ISS(126)가 실행 백엔드(execution backend)로서 소프트웨어 디버거에 의하여 사용되게 하는 소켓 인터페이스(이것은 선택된 특별 구성을 위하여 레지스터 상태를 읽고 쓰도록 구성되어야 한다).

-- 매우 상세한 디버깅 및 성능 분석을 가능케 하는 스크립트 가능한 인터페이스. 특히, 이 인터페이스는 서로 다른 구성상의 응용프로그램 동작을 비교하는 데에 사용될 수 있다. 예를 들어, 임의의 정지점에서 하나의 구성상에 있는 실행으 로부터의 상태는 다른 구성상에 있는 실행으로부터의 상태와 비교될 수도 있고 그 상태로 전송될 수도 있다.

시뮬레이터(126)도 핸드-코딩된 부분과 자동으로 생성된 부분을 모두 갖는다. 핸드-코딩된 부분은 명령어 디코드 및 실행을 제외하고는 통상적인 것으로서, ISA 기술 언어로부터 생성된 테이블로부터 창조된다. 테이블은 실행될 명령 단어에서 발견된 기본 연산코드로부터 시작함에 따라 명령어를 디코딩하며, 그 필드의 값을 가지고 테이블을 인덱싱하여 리프 연산코드(leaf opcode) 즉, 다른 연산코드의 항에서 정의되지 않은 연산코드가 발견될 때까지 계속한다. 그러면 테이블은 명령어에 대한 의미론 선언(semantics declaration)에서 지정된 TIE 코드로부터 번역된 코드에 포인터를 부여한다. 이 코드는 명령어를 시뮬레이션하도록 실행된다.

ISS(126)는 시뮬레이션되고 있는 프로그램의 실행을 선택적으로 프로파일링할 수 있다. 이 프로파일링은 당업계에서 알려진 프로그램 카운터 샘플링 기술을 이용한다. 규칙적인 간격으로 시뮬레이터(126)는 시뮬레이션되고 있는 프로세서의 PC(프로그램 카운터)를 샘플링한다. 그것은 코드의 각 영역에서 샘플의 수를 가지고 히스토그램을 구축한다. 또한 시뮬레이터(126)는 호출 그래프에서 각각의 에지가, 호출 명령어가 시뮬레이션될 때마다 카운터를 증가시킴에 따라 실행되는 회수를 센다. 시뮬레이션이 완료되면, 시뮬레이터(126)는 히스토그램과 호출 그래프 에지 카운트를 모두 담고 있는 출력 파일을 표준 프로파일 뷰어에 의하여 읽힐 수 있는 형식으로 기재한다. 시뮬레이션 중의 프로그램(118)은 명령어 코드로(표준 프로파일링 기술로) 수정될 필요가 없기 때문에, 프로파일링 오버헤드는 시뮬레이션 결 과에 영향을 미치지 않으며 프로파일링은 전체적으로 비침략적(non-invasive)이다.

시스템은 소프트웨어 프로세서 에뮬레이션 뿐만 아니라 가용한 하드웨어 프로세서 에뮬레이션을 만드는 것이 바람직하다. 이 목적을 위하여, 본 실시예는 에뮬레이션 보드를 제공한다. 도 6에 도시된 바와 같이, 에뮬레이션 보드(200)는 Altera Flex 10K200E와 같은 복잡한 프로그래밍이 가능한 논리 디바이스(202)를 사용하여 하드웨어에서 프로세서 구성(60)을 에뮬레이팅한다. 일단 시스템에 의하여 생성된 프로세서 네트리스트(netlist)로 프로그래밍되면, CPLD 디바이스(202)는 기능적으로 최종 ASIC 생성물과 동등하다. 그것은 프로세서(60)의 물리적 구현이 이용 가능해져 다른 시뮬레이션 방법(ISS(126) 또는 HDL과 같은)보다 더 빠르게 실행할 수 있고 사이클이 정확해진다는 장점을 제공한다. 하지만, 그것은 최종 ASIC 디바이스가 도달할 수 있는 고주파수 목표은 도달할 수 없다.

이 보드는 설계자가 다양한 프로세서 구성 옵션과 시작 소프트웨어 개발을 평가할 수 있게 하고 설계 사이클에서 초기에 디버깅하게 한다. 그것은 프로세서 구성의 기능적 검증을 위해서도 사용될 수 있다.

에뮬레이션 보드(200)는 그 위에서 이용 가능한 수 개의 리소스를 갖고 있어서 소프트웨어 개발, 디버깅 및 검증을 용이하게 한다. 이들은 CPLD 디바이스(202) 그 자체와, EPROM(204), SRAM(206), 동기적 SRAM(208), 플래쉬 메모리(210) 및 두 개의 RS232 시리얼 채널(212)을 구비한다. 시리얼 채널(212)은 UNIX 또는 PC 호스트에 사용자 프로그램을 다운로딩하고 디버깅하는 커뮤니케이션 링크를 제공한다. CPLD 네트리스트의 관점에서는, 프로세서(60)의 구성이 전용 시리얼 링크를 통해 CPLD(202) 안으로 다운로딩되어 디바이스의 구성 포트(214)로 향하거나 전용 구성 ROM(216)을 거치게 된다.

보드(200)상에서 이용 가능한 리소스는 비슷한 정도로 구성가능하다. 보드상의 각종 메모리 소자의 메모리 맵은 쉽게 변화될 수 있는데, 그것은 맵핑이 쉽게 변화될 수 있는 프로그래밍 가능한 논리 디바이스(PLD)(217)를 통해 행해지기 때문이다. 또한, 프로세서 코어가 사용하는 캐시(218, 228)는, 더 큰 메모리 디바이스를 사용하고 캐시(218, 228)에 연결하는 태그 버스(222, 224)의 크기를 적절히 함으로써 확장이 가능하다.

특별한 프로세서 구성을 에뮬레이팅하기 위하여 보드를 사용하는 것에는 수 개의 단계를 수반한다. 첫 단계는 프로세서의 특별한 구성을 기술하는 일 세트의 RTL 파일을 얻는 것이다. 다음 단계는 많은 상업적 합성 툴 중 어느 것을 이용하여 RTL 기술로부터 게이트-레벨 네트리스트를 합성하는 것이다. 이러한 예의 하나는 Synopsys로부터의 FPGA Express이다. 그러면 게이트-레벨 네트리스트는 공급자에 의하여 전형적으로 제공된 툴을 사용하여 CPLD 구현을 얻는 데에 사용될 수 있다. 이러한 툴 중 하나는 Altera Coporation의 Maxplus2 이다. 마지막 단계는 마찬가지로 CPLD 공급자에 의하여 제공된 프로그래머를 이용하여 에뮬레이션 보드상의 CPLD 칩으로 상기 구현을 다운로딩하는 것이다.

에뮬레이션 보드의 용도 중 하나는 디버깅 목적으로 빠른 원형 구현(prototype implementaion)을 지원하는 것이므로, 전 단락에서 개관된 CPLD 구현 프로세스는 자동적이라는 것이 중요하다. 이 목적을 이루기 위하여, 사용자에게 전달된 파일은 모든 관련 파일을 하나의 디렉토리 안에 그룹을 지어 줌으로써 맞춤화된다. 그러면, 완전히 맞춤화된 합성 스크립트는 고객이 선택한 특별한 FPGA 디비이스에 특별한 프로세서 구성을 합성하는 것이 가능해지게 된다. 공급자 툴에 의하여 사용될 완전히 맞춤화된 구현 스크립트도 생성된다. 이러한 합성 및 구현 스크립트 게런티는 최적의 성능으로 구현 수단을 기능적으로 수정한다. 기능적 교정(functional correctness)은 스크립트 안에 특정한 프로세서 구성에 관련된 모든 RTL 파일을 읽기 위해서 적절한 명령을 구비하고, 프로세서 구성에 있는 I/O 신호에 기초한 칩-핀 위치(chip-pin location)를 정하기 위해서 적절한 명령을 구비하며, 게이팅된 클럭(gated clock)에서와 같이 프로세서 로직의 어떤 임계적 부분에 대한 특정한 논리 구현을 얻기 위해서 명령을 구비함으로써 달성된다. 스크립트는 또한 모든 프로세서 I/O 신호에 상세한 타이밍 제약조건(detailed timing constraint)을 부여하고 어떤 임계적 신호의 특수 프로세싱에 의하여 구현 수단의 성능을 향상시킨다. 이러한 타이밍 제약조건을 위한 일례는 보드상의 그 신호의 지연을 산입함으로써 신호에 특수 입력 지연을 할당하는 것이다. 임계적 신호 처리의 예는 CPLD 칩상의 낮은 클럭 스큐(low clock skew)를 달성하기 위하여 전용 글로벌 와이어에 클럭 신호를 부여하는 것이다.

바람직하게는, 상기 시스템이 또한 구성된 프로세서(60)를 위한 검증 수트(verification suite)를 구성한다. 마이크로프로세서와 같은 복잡한 설계의 대부분의 검증은 다음과 같은 흐름으로 이루어진다:

-- 설계를 자극하기 위해서 테스트벤치를 구축하고 테스트벤치 내부에서 또 는 ISS(126)와 같은 외부 모델을 이용하여 출력을 비교;

-- 자극을 생성하기 위해서 진단을 쓰기;

-- 유한 상태 기계 커버리지 HDL(finite state machine coverage HDL)의 라인 커버리지와 같은 계획을 이용하여, 설계상의 벡터 실행의 수와 버그율(bug rate)을 감퇴시켜, 검증의 커버리지를 측정; 및

-- 만일 커버리지가 충분하지 않으면 - 진단(diagnostics)을 더 작성하고 아마도 설계를 더 실습하기 위해서 진단을 생성하는 데에 툴을 사용한다.

본 발명은 다소 유사한 흐름을 이용하지만, 흐름의 모든 구성요소는 설계의 구성가능성(configurability)을 설명하기 위하여 수정된다. 이 방법론은 다음의 단계로 이루어진다.

-- 특별한 구성을 위한 테스트벤치를 구축. 테스트벤치의 구성은 HDL에 대하여 서술된 바와 유사한 접근을 이용하며 모든 옵션과 그 내부에 지원되는 확장, 즉 캐시 크기, 버스 인터페이스, 클럭킹, 인터럽트 생성 등을 지원;

-- HDL의 특별한 구성상의 자기-검사 진단(self-checking diagnostics)을 실행. 진단 그 자체는 특별한 한 조각의 하드웨어에 대하여 그들을 주문하도록 구성가능하다. 어떠한 진단을 실행할 것인 지를 선택하는 것도 구성에 달려있다;

-- 의사 무작위로 생성된 진단을 실행하고 ISS(126)에 대항하는 각 명령어의 실행 후 프로세서 상태를 비교; 및

-- 검증의 커버리지의 측정 - 라인 커버리지 뿐만 아니라 기능을 측정하는 커버리지 툴을 사용. 또한, 오류 상태 및 조건을 검사하기 위하여 진단을 따라 모니터와 체커가 실행된다. 이들 모두는 특별한 구성 명세를 위하여 구성가능하다.

모든 검증 성분은 구성가능하다. 구성가능성은 TPP를 사용하여 구현된다.

테스트벤치는 구성된 프로세서(60)가 위치한 시스템의 Verilog^TM 모델이다. 본 발명의 경우에 이들 테스트벤치는 다음을 포함한다:

-- 캐시, 버스 인터페이스, 외부 메모리;

-- 외부 인터럽트 및 버스 에러 발생; 및

-- 클럭 발생.

상기 특성의 거의 모두는 구성가능하기 때문에, 테스트벤치 그 자체는 구성가능성을 지원할 필요가 있다. 따라서, 예를 들어, 캐시 크기와 폭 및 외부 인터럽트의 수는 구성에 기초하여 자동으로 조정된다.

테스트벤치는 테스트를 받는 디바이스-프로세서(60)에 자극을 준다. 이것은 메모리 안으로 사전로딩(preloading)되는 (진단으로부터의) 어셉블리 레벨 명령어를 제공함에 따라 행해진다. 그것은 또한 프로세서(60)의 동작-즉, 인터럽트를 제어하는 신호를 생성한다. 또한, 이들 외부 신호의 주파수 및 타이밍은 제어 가능해서 테스트벤치에 의하여 자동으로 생성된다.

진단에 대한 구성가능성의 종류는 두 가지이다. 첫 번째는 진단이 무엇을 테스트할 지를 결정하기 위해 TPP를 사용하는 것이다. 예를 들어, 진단은 소프트웨어 인터럽트를 테스트하도록 기재되었다. 이 진단는 올바른 어셈블리 코드를 생성하기 위하여 얼마나 많은 소프트웨어 인터럽트가 존재하는 지를 알아야 한다.

두 번째는, 프로세서 구성 시스템(10)이 이 구성을 위하여 진단이 적합한 지를 결정해야 하는 것이다. 예를 들어, MAC 유닛을 테스트하도록 기재된 진단은 이 유닛을 구비하지 않는 프로세서(60)에는 적용할 수 없다. 본 실시예에서는 각각의 진단에 대한 정보를 담고 있는 데이터베이스의 사용을 통해 이것을 성취한다. 데이터베이스는 각각의 진단에 대하여 다음의 정보를 담고 있다:

-- 어떠한 옵션이 선택된 경우에 진단을 사용할 것인 지;

-- 진단이 인터럽트와 함께 실행될 수는 없는 지;

-- 진단이 실행하기 위해서 특수 라이브러리나 핸들러를 요구하는 지; 및

-- 진단이 ISS(126)을 가지고 코시뮬레이션으로 실행될 수는 없는 지.

프로세서 하드웨어 기술은 세 가지 형태의 테스트 툴 즉, 테스트 생성 툴, 모니터와 커버리지 툴(또는 체커) 및 코시뮬레이션 메카니즘을 구비하는 것이 바람직하다. 테스트 생성 툴은 지능적 성향(intelligent fashion)을 가진 일련의 프로세서 명령어를 창조하는 툴들이다. 그들은 의사 무작위 테스트 생성기의 시퀀스이다. 본 실시예는 내부적으로 두 가지 형태를 사용하는데, 하나는 소위 RTPG 로서 특수하게 개발된 것이며 다른 하나는 VERA(VSG)라고 하는 외부 툴에 기반을 둔 것이다. 그 둘 모두는 그들의 주변에 구축된 구성가능성을 갖는다. 또한 이들 툴은 TIE로부터 새롭게 정의된 명령어를 다루어 이들 새롭게 정의된 명령어가 테스트 동안에 무작위로 생성되게 할 수도 있다. 본 실시예는 설계 검증의 커버리지를 측정하는 모니터와 체커를 구비한다.

모니터와 커버리지 툴은 회귀 실행(regression run)과 나란히 실행되는 툴이다. 커버리지 툴은 진단이 무엇을 행하고 있는 지와 그것이 실습 중인 HDL의 함수와 논리를 모니터링한다. 이 정보는 모두 회귀 실행을 통해서 수집되며 나중에 논리의 어떤 부분이 더욱 테스팅을 필요로 하는가에 대한 실마리를 잡기 위해서 분석된다. 본 실시예는 구성가능한 수 개의 기능적 커버리지 툴을 사용한다. 예를 들어, 특별한 유한 상태 기계에 대하여는 모든 상태가 구성의 의존하여 포함되는 것은 아니다. 따라서, 그 구성에 대하여는 기능적 커버리지 툴이 그들 상태나 변환을 체킹하려고 해서는 아니된다. 이것은 TPP를 통해 구성가능한 툴을 제작함으로써 성취된다.

이와 유사하게, 모니터는 HDL 시뮬레이션 내부에서 발생하는 오류 상태(illegal condition)를 체크한다. 이들 오류 상태를 버그로 볼 수도 있다. 예를 들어, 3-상태 버스(3-state bus)상에는 동시에 두 개의 드라이버가 존재해서는 아니된다. 이들 모니터는 구성가능하여 특별한 논리가 그 구성을 위하여 포함되는 지 아닌 지에 의거하여 가산 체크(adding check)나 제거 체크를 행한다.

코시뮬레이션 메카니즘은 HDL을 ISS(126)에 연결한다. 그것은 명령어의 끝에서 프로세서의 상태가 HDL 및 ISS(126)에서 동일한 것인 지를 체크하는 데 사용된다. 그것 역시 각각의 구성에 대하여 어떤 특징이 포함되고 어떤 상태가 비교될 필요가 있는 지를 알고 있는 범위로 구성가능하다. 따라서, 예를 들어, 테이터 정지점 형상은 특수 레지스터를 더한다. 이 메카니즘은 이 신규 특수 레지스터를 비교하는 것을 알 필요가 있다.

TIE를 통해 지정된 명령어 의미론은, ISS(126)를 사용하고 시스템 설계자가 테스팅 및 검증을 위해 사용할 수 있도록 함수적으로 등가인 C 함수로 번역될 수 있다. 구성 테이터베이스(106)에서 명령어의 의미론은, 표준 파서 툴(standard parser tool)을 사용하여 파스 트리(parse tree)를 구축하는 툴과, 상기 트리를 걸으며 C 언어로 대응하는 표현을 출력하는 코드에 의하여 C 함수로 변역된다. 번역은 모든 표현에 대한 비트 폭을 할당하고 어떤 번역은 단순화하도록 파스 트리를 다시 쓰기 위해서 프리패스(prepass)를 요구한다. 이들 번역기는 HDL을 C로 또는 C를 어셈블리 언어 컴파일러로 번역하는 다른 번역기에 비하여 상대적으로 간단하며, TIE 및 C 언어 명세로부터 시작한 당업자에 의하여 씌여질 수 있다.

구성 파일(100)과 어셈블러/디셈블러(100)를 사용하여 구성된 컴파일러를 사용하면, 벤치마크 응용프로그램 소스 코드(118)는 컴파일링되고 어셈블링되며, 데이터 세트(124)를 사용하면 사용자에 대한 피드백을 위하여 사용자 구성 캡쳐 루틴에도 제공되는 소프트웨어 프로파일(130)을 얻도록 시뮬레이션된다.

임의의 구성 파라미터 선택을 위하여 하드웨어 및 소프트웨어 경비/이득 특성화를 모두 얻기 위한 능력을 갖고 있음은 설계자가 시스템을 더욱 최적화하기 위한 신규 기회를 열어 준다. 상세하게는, 이것은 설계자가 어떠한 모습의 장점에 따라 전반적인 시스템을 최적화하는 최적의 구성 파라미터를 선택할 수 있게 한다. 한 가지 가능한 프로세스는 반복하여 선택하거나 구성 파라미터를 선택하지 않음으로써 탐욕스런 전략(greedy strategy)에 기초한다. 각 단계에서, 전반적인 시스템 성능 및 비용에 미치는 최상의 영향을 갖는 파라미터가 선택된다. 이 단계는 하나의 파라미터가 시스템 성능 및 비용을 향상시키기 위하여 변화될 수 없을 때까지 반복된다. 그 밖의 범위는 동시에 구성 파라미터의 그룹을 바라보거나 더 세련된 탐색 알고리즘을 채용하는 것을 포함한다.

최적의 구성 파라미터 선택을 획득함과 더불어, 이 프로세스는 최적의 프로세서 범위를 구축하는 데에도 사용될 수 있다. 프로세서 범위에는 많은 가능성이 있기 때문에, 확장 대상(extension candidate)의 수를 엄격히 하는 것이 중요하다. 한 가지 기술은 응용프로그램 소프트웨어를 분석하고 시스템 성능이나 비용을 향상시킬 수 있는 명령어 범위에서 바라보기만 하는 것이다.

본 발명의 자동화된 프로세서 구성 시스템의 동작을 숙지하였다면, 프로세서 마이크로구조 구성에 대한 시스템의 응용프로그램의 예를 든다. 첫 번째 예는 이미지 압축(image compression)으로 적용된 본 발명의 장점을 보여준다.

모션 추정(motion estimation)은 MPEG 비디오 및 H263 컨퍼런스 응용프로그램을 포함하는 많은 이미지 압축 알고리즘의 중요한 구성요소이다. 비디오 이미지 압축은 하나의 프레임으로부터 다음 프레임으로의 유사성을 이용하여 각 프레임에 대하여 요구되는 스토리지의 양을 줄이려고 한다. 가장 간단한 경우에, 압축될 이미지의 각 블럭은 기준 이미지(압축되고 있는 이미지의 바로 앞의 것 또는 바로 뒤의 것)의 대응하는 블럭(동일한 X, Y 위치)에 비교될 수 있다. 프레임간의 이미지 차이의 압축은 일반적으로 개별 이미지의 압축보다 더 비트-효율적이다. 비디오 시퀀스에서는, 구별되는 이미지 피쳐가 프레임에서 프레임으로 움직이기도 하여 상이한 프레임내에서 블럭간의 가장 밀접한 유사점(closest correspondence)도 정확히 동일한 X, Y 위치에 있지 않고 약간 오프셋되기도 한다. 이미지의 현저한 부분이 프레임간에 움직이고 있다면, 그 차이를 계산하기 전에 움직임에 대한 동일화 및 보상을 필요로 할 수도 있다. 이 점은 구별되는 이미지에 대하여 계산된 차이에서 이용된 서브 이미지에서 X, Y 오프셋을 포함하는 연속적인 이미지들 간의 차이를 인코딩함으로써 가장 짙은 표현(densest representation)을 달성할 수 있다는 것을 의미한다. 이미지 차이를 계산하는 데 이용된 위치에서의 오프셋은 모션 벡터라고 불리운다.

이 종류의 이미지 압축에서 가장 중점적으로 계산해야 할 일은 각 블럭에 대하여 가장 적합한 모션 벡터를 결정하는 것이다. 모션 벡터를 선택하는 공통적인 미터법(common metric)은 압축되고 있는 이미지의 각 블럭과 이전 이미지의 후보 블럭의 세트간의 한 픽셀 한 픽셀마다(pixel-by-pixel)의 가장 낮은 평균차로 벡터를 발견하는 것이다. 후보 블럭은 압축되고 있는 블럭의 위치 주변에서 이웃하는 모든 블럭의 세트이다. 이미지의 크기, 블럭의 크기 및 이웃의 크기는 모두 모션 추정 알고리즘의 러닝 타임에 영향을 준다.

간단한 블럭계 모션 추정(block-based motion estimation)은 기준 이미지에 대하여 압축될 이미지의 각각의 서브 이미지를 비교한다. 기준 이미지는 비디오 시퀀스에서의 앞선 종속 이미지이거나 뒤따르는 종속 이미지일 수 있다. 모든 경우에 있어서, 기준 이미지는 종속 이미지가 디컴프레션되기 전에 디컴프레션 시스템(decompression system)에서 이용할 수 있는 것으로 알려져 있다. 디컴프레션하의 이미지의 한 블럭을 기준 이미지의 후보 블럭과 비교하는 것은 아래에 서술된다.

종속 이미지에서 각 블럭에 대하여, 기준 이미지에서의 대응하는 위치의 주변에서 검색이 수행된다. 이미지의 각각의 색 성분(예를 들어, YUV)은 개별적으로 분석되는 것이 정상이다. 때때로 모션 추정은 단지 하나의 성분, 특히 발광(luminance)에 대하여만 수행되기도 한다. 평균적인 한 픽셀마다의 차이는 그 종속 블럭과 기준 이미지의 검색 영역에 있는 모든 가능한 블럭과의 사이에서 계산된다. 그 차이는 픽셀값의 크기에 따른 차이의 절대값이다. 평균은 블럭들의 쌍에서 총합을 N² 픽셀로 나눈 값이며, 여기서 N은 블럭의 치수이다. 가장 작은 평균 픽셀 차이를 만드는 기준 이미지의 블럭은 종속 이미지의 블럭에 대한 모션 벡터를 정의한다.

다음의 예시는 모션 추정 알고리즘의 간단한 형태를 보여주며, 이에 따라 작은 응용프로그램-지정 기능 유닛(application-specific functional unit)에 대하여 TIE를 사용하는 알고리즘을 최적화한다. 이 최적화는 팩터의 10이상 속도를 증가시켜 많은 비디오 응용프로그램에 대하여 프로세서계 압축(processor-based compression)을 실현 가능하게 한다. 그것은 고차원 언어로 프로그래밍하는 용이함과 특수 목적 하드웨어의 효율성을 결합시킨 구성가능한 프로세서의 힘을 설명한다.

본 예시는 두 개의 메트릭스, OldB 및 NewB를 사용하여 그 각각이 예전 이미지와 신규 이미지를 표현한다. 이미지의 크기는 NX 및 NY로 결정된다. 블럭 크기는 BLOCKX 및 BLOCKY로 결정된다. 따라서, 상기 이미지는 NX/ BLOCKX by NY/BLOCKY 블럭으로 구성된다. 블럭 주변의 검색 영역은 SEARCHX 및 SEARCHY로 결정된다. 최적의 모션 벡터와 값은 VectX, Vecty 및 VectB 에 저장된다. 베이스(기준) 구현 툴로 계산된 최적의 모션 벡터와 값은 BaseZ, BaseY 및 BaseB 에 저정된다. 이들 값은 명령어 범위(instruction extension)를 사용하는 상기 구현에 의하여 계산된 벡터에 대항하여 체크하는 데 사용된다. 이들 기본 정의는 다음의 C-코드 세크먼트에 캡쳐된다:

상기 모션 추정 알고리즘은 세 개의 중첩된 루프(nested loop)로 구성된다:

1. 예전 이미지에서 각각의 소스 블럭에 대하여.

2. 소스 블럭의 주변환경 영역에서 신규 이미지의 각각의 수신지 블럭(destination block)에 대하여.

3. 각 쌍의 픽셀간의 절대 차를 계산.

알고리즘에 대한 완벽한 코드는 아래에 열거된다.

기초 구현은 간단한 반면에, 블럭 비교에 대한 이 블럭의 고유 병렬성(intrinsic parallelism)의 대부분을 활용할 수는 없다. 구성가능한 프로세서 구조는 이 응용프로그램의 현저한 속도 증가를 가능케 하는 두 개의 키 툴을 제공한다.

첫째, 명령어 세트 구조는 강력한 퍼널 쉬프팅 프리미티브(funnel shifting primitive)를 구비하여 메모리에 정렬되지 않은 필드의 빠른 추출을 허용한다. 이것은 픽셀 비교의 내부 루프가 메모리로부터 인접한 픽셀의 그룹을 효율적으로 인출하게 한다. 그러면 상기 루프는 다시 기재될 수 있어 네 개의 픽셀(바이트)을 동시에 작동시킨다. 특히, 본 예시의 목적을 위하여, 동시에 네 개의 픽셀 쌍의 절대 차를 계산하도록 신규 명령어를 정의하는 것이 바람직하다. 하지만, 이 신규 명령어를 정의하기 전에, 그러한 명령어를 사용하기 위하여 알고리즘을 재구현(re-implement)해야 할 필요가 있다.

이 명령어의 존재는 내부 루브 픽셀 차 계산에서 루프 언롤링(loop unrolling)도 마찬가지로 관심거리가 되도록 개선한다. 내부 루프에 대한 C 코드는 다시 기재되어 신규 절대 차의 총합 및 효율적 쉬프팅이라는 장점을 갖는다. 그러면 기준 이미지의 네 개의 중첩 블럭의 부분은 동일한 루프에서 비교될 수 있다. SAD(x,y)는 첨가된 명령어에 대응하는 신규 명령어 함수이다. SRC(x,y)는 SAR 레지스터에 저장된 쉬프트 양에 따라 x와 y의 연계(concatenation)의 오른쪽 쉬프트를 수행한다.

이 구현은 다음의 SAD 함수를 사용하여 그 결과 생성된 신규 명령어를 에뮬레이팅한다:

이 신규 구현 툴을 디버깅하기 위해서, 이 신규 구현 툴 및 베이스 구현 툴에 의하여 계산된 모션 벡터와 값은 비교하는 데 다음의 테스트 프로그램이 사용된다.

이 간단한 테스트 프로그램은 전반적인 개발 프로세스에 사용될 것이다. 이 다음으로 하여야 할 한 가지 중요한 결정은 에러가 검출되면 메인 프로그램이 0으로 복귀하고 그렇지 않으면 1로 복귀하여야 한다는 것이다.

TIE의 사용은 신규 명령의 신속한 명세(rapid specification)를 허용한다. 구성가능한 프로세서 생성기는 이들 명령어를 하드웨어 구현 및 소프트웨어 개발 툴로 완전히 구현할 수 있다. 하드웨어 합성은 신규 함수를 하드웨어 데이터패스로 최적화 통합(optimal integration)한다. 구성가능한 프로세서 소프트웨어 환경은 신규 명령어를 C와 C++ 컴파일러, 어셈블러, 기호 디버거, 프로파일러 및 사이클-어큐레이트 명령어 세트 시뮬레이터로 완벽히 지원한다. 하드웨어와 소프트웨어의 빠른 재생은 응용프로그램-특정 명령어들을 응용프로그램 가속을 위한 빠르고 신뢰성 있는 툴로 만든다.

이러한 예시는 픽셀 차이, 고유값 및 4개의 픽셀들을 병렬로 누산하도록 간단한 명령어를 구현시키기 위해 TIE를 사용한다. 이러한 단일 명령어는 원자 연산(atomic operation)으로서 (종래의 프로세스가 분리 명령어를 요구하는) 11 개의 기초 연산을 한다. 완성된 기술은 다음과 같다.

이러한 기술은 신규 명령어를 정의하도록 최소의 단계들을 나타낸다. 먼저, 명령어를 위한 신규 연산코드를 정의하는 것이 필요하다. 이러한 경우에, 신규 연 산코드 SAD는 CUSTO의 서브 연산코드로서 정의된다. 앞에서 나타난 바와 같이, CUSTO는 미리 정의된다.

QRST가 톱-레벨 연산 코드라는 것을 이해하는 것은 쉽다. CUST0는 QRST의 서브 연산코드이고, 차례로 SAD는 CUST0의 서브 연산코드이다. 연산코드의 이러한 계층적 구성은 연산 코드 스페이스의 관리 및 논리 그룹을 허용한다. 기억해야할 중요한 하나는 사용자가 신규 명령어들을 부가하도록 비축된 연산 코드 스페이스로서 CUSTO(및 CUST1)가 정의된다는 점이다. TIE기술에 대한 미결정 재가용성을 보장하도록 이러한 할당된 연산 코드의 스페이스내에 사용자가 머무는 것이 바람직하다.

TIE 기술에서의 두번째 단계는 신규 명령어 SAD를 포함하는 신규 명령어 클래스를 정의하는 것이다. 여기서 SAD 명령어의 피연산자가 정의된다. 이러한 경우에, SAD는 세 개의 레지스터 피연산자, 목적 레지스터 arr 및 소스 레지스터 ars 및 art로 구성된다. 상술된 바와 같이, arr은 명령어의 r 필드에 의해 인덱싱된 레지스터로 정의되고, ars 및 art는 명령어의 s 및 t 필드에 의해 인덱싱된 레지스터들로 정의된다.

이러한 기술에서의 마지막 블록(last block)은 SAD 명령어용 형식적 의미론 정의를 제공한다. 이러한 기술은 조합 논리를 설명하는 Verilog HDL 언어의 부분집합을 이용하고 있다. 이러한 블록은 ISS가 SAD 명령어를 어떻게 시뮬레이팅하는지와 신규 명령어를 지지하기 위해 부가 회로도가 어떻게 구성 프로세서 하드웨어에 부가되고 합성되는지를 정확히 정의한다.

다음, 이미 상술된 툴을 사용하여, TIE 설명이 디버싱되고 검증된다. TIE 설명의 정확성을 검증한 후, 다음 단계는 하드웨이 크기와 성능에 신규 명령어의 영향을 추정하는 것이다. 상술된 바와 같이, 이것은 예를 들어, Desigh Compier^TM 을 이용하여 행해질 수 있다. Design Compiler가 완료될 때, 사용자는 속도 리포트와 세부 영역에 대한 출력을 볼 수 있다.

TIE 설명이 정확하고 효과적이라는 것을 검증한 후에는 또한 신규 SAD 명령어를 지지하는 구성 프로세서를 구축하고 구성할 시간이 된다. 이것은 상술된 바와 같이 GUI를 사용하여 이루어진다.

다음, 이동 추정 코드는 프로그램의 정확성을 검증하고 더욱 중요하게는 성능을 측정하기 위해 명령어 집합 시뮬레이터를 사용하는 구성 프로세서용 코드로 컴파일링된다. 이것은 3단계, 즉, 시뮬레이터를 사용하는 테스트 프로그램 실행; 명령어 카운트를 얻기위해 베이스 구현만 실행; 명령어 카운트를 얻기 위해 신규 구현만 실행에서 행해진다.

다음은 제2단계의 시뮬레이션 출력이다.

다음은 제3단계의 시뮬레이션 출력이다.

두 개의 리포트로부터, 하나는 대략 4x 고속화가 발생한다고 이해할 수 있다. 구성 프로세서 명령어 집합 시뮬레이터는 기타 유용한 정보를 제공할 수 있다는 것에 유의하라.

프로그램의 성능과 정확성을 검증한 후, 다음 단계는 상술된 바와 같이 Verilog 시뮬레이터를 사용하는 테스트 프로그램을 실행하는 것이다. 당업자는 부록 C(결합 파일도 부록 C에서 나타남)의 메이크파일(makefile)로부터 프로세스의 세부사항들을 얻을 수 있다. 시뮬레이션의 목적은 신규 명령어의 정확성을 더욱 검증하는 것이고 이러한 테스트 프로그램을 구성된 프로세서용 회귀 테스트의 일부로 만드는 것은 더욱 중요해진다.

마지막으로, 프로세서 논리는 예를 들어, Design Compiler^TM 을 사용하여 합성될 수 있고, 예를 들어, Apollo^TM 을 사용하여 라우팅되고 배치될 수 있다.

이러한 예시는 설명의 간략화와 명백화를 위해 영상 압축과 이동 추정에 대한 간소화된 뷰(view)를 얻는다. 현실적으로, 표준 압축 알고리즘에서는 미묘한 차이들(nuances)이 다수 부가된다. 예를 들어, 일반적으로 MPEG2는 서브 픽셀 해상도를 갖는 보상과 이동 추정을 한다. 픽셀의 두 개의 인접 행과 열은 두 개의 행 또는 열 사이 중간의 가상 위치에 삽입된 일렬의 픽셀을 생성하도록 평균화될 수 있다. 명령어를 평균화하는 병렬 픽셀은 TIE 코드의 단지 세 개 또는 네 개의 라인에서 쉽게 구현되기 때문에, 구성 프로세서의 사용자-정의 명령어들은 본 명세서에서 다시 유용해진다. 다시, 열에서 픽셀들 사이를 평균화하는 것은 프로세서의 표준 명령어 집합의 효과적인 얼라이먼트 동작을 사용한다.

따라서, 간단한 합의 절대 차(sum-of-absolute-differences) 명령어의 인코퍼레이션(incorporation)은 단지 몇 백개의 게이트를 부가하지만, 10의 팩터 이상으로 이동 추정 성능을 개선시킨다. 이러한 가속은 최종 시스템의 파워 효율과 비용에서 상당한 개선을 나타낸다. 더구나, 신규 이동 추정 명령어를 포함하기 위한 소프트웨어 개발 툴의 심리스 확장(seamless extension)은 신속한 프로토 타이핑(prototyping), 완성된 소프트웨어 응용의 해제 및 성능 분석을 허용한다. 본 발명의 해결책은 응용-특정 프로세서 구성을 간단, 확실, 완전하게 만들고 비용, 성능, 최종 시스템 생성물의 전력- 효율과 기능성에 대한 매우 효과적인 증대를 제공한다.

기능성 하드웨어 유닛의 덧셈에 초점을 맞추는 예시로서, 프로세서 제어 기능, 프로그램 카운터(PC), 분기 선택, 명령어 메모리 또는 캐시와 명령어 디코더, 및 주 레지스터 파일, 바이패싱 멀티플렉서, 파이프라인 레지스터, ALU, 캐시용 데이터 메모리와 어드레스 발생기를 포함하는 베이식 정수 자료 통로를 포함하는 도 6에 도시된 베이스 구성을 고려해보자.

HDL은 "승수" 파라미터가 설정될 때, 승수 논리가 존재한다는 것을 조건으로 하여 기록되고, 도 7에 도시된 바와 같이 신규 파이프라인 단계로서 승수 유닛이 부가된다(정확한 예외상황이 지지되는 것이라면 예외상황 처리로의 변경이 요구될 것이다.) 물론, 승수를 이용하는 명령어들은 바람직하게는 신규 유닛과 동시에 일어나도록 부가되고 있다.

제2예시로서, 도 8에 도시된 바와 같이 전체 코프로세서는 다중 / 누산 유닛 (multiply/accumulate unit)등의 디지털 신호 프로세서용 베이스 구성에 부가될 것이다. 이것은 확장된 명령어로부터 수신지와 레지스터 소스의 디코딩; 제어 신호용 고유의 파이프라인 지연을 부가; 레지스터 목적 논리를 확장; 누산 레지스터로부터 이동하는 레지스터 바이패스 멀티플렉서용 제어를 부가 및 명령어 결과용 가능한 소스로서 곱셈-누산 유닛의 포함을 갖는 곱셈-누산 연산용 부가 디코딩 제어 신호등의 프로세서 제어에서 변화를 가능하게 한다. 부가적으로, 부가 누산기 레지스터, 곱셈-누산 어레이 및 주 레지스터 소스용 소스 선택 멀티플렉서를 수반하는 곱셈-누산 유닛의 부가를 필요로한다. 또한, 코프로세서의 부가는 누산 레지스터로부터 소스를 갖도록 누산 레지스터로부터 레지스터 바이패스 멀리플렉서의 확장과 승수의 결과로부터 소스를 갖도록 로드/얼라이먼트 승수의 확장을 수반한다. 다시, 바람직하게는, 이러한 시스템은 실제 하드웨어와 함께 신규 기능 유닛을 사용하는 명령어를 부가한다.

디지털 신호 프로세서와 관련하여 특별히 유용한 또다른 옵션은 부동 소수점 유닛이다. 예를 들어, IEEE 754 단일-정밀도 부동 소수점을 구현시키는 기능 유닛은 그것을 액세스하는 명령어들과 함께 부가될 수 있다. 부동 소수점 유닛은 예를 들어, 오디오 컴프레션 및 디컴프레션 등의 디지털 단일 프로세싱 응용에 사용될 수 있다.

이러한 시스템의 유연성의 또다른 예시로서, 도 9에 나타난 4 kB 메모리 인터페이스를 고려해보자. 본 발명의 구성가능성(configurability)을 이용하여, 코프로세서 레지스터와 데이터패스는 주 정수 레지스터 파일과 데이터패스보다 더 폭이 넓거나 또는 더 폭이 좁아질 수 있고, 지역 메모리 폭은 상기 메모리 폭이 가장 폭이 넓은 프로세서 또는 코프로세서와 동일하도록 변경될 수 있다(따라서 판독과 기록상의 메모리 어드레싱은 변경될 수 있다). 예를 들어, 도 10은 동일한 배열을 어 드레싱하는 프로세서/코프로세서 조합에 32비트의 로드와 저장을 지지하는 프로세서용 지역 메모리 시스템을 나타내지만, 여기서, 코프로세서는 128비트의 로드와 저장을 지지한다. 이것은 TPP code를 사용하여 구현될 수 있다.

여기서, $Bytes는 기록 신호(W1)의 제어하에서 데이터 버스(D1)를 갖는 바이트 어드레스(A1)에서의 너비(B1) 바이트 또는 대응하는 파라미터(B2, A2, D2 및 W2)를 사용하여 엑세스되는 전체 메모리 크기이다. Select로 정의되는 단지 한 쌍의 신호들은 주어진 사이클내에서 작동한다. TPP 코드는 메모리 뱅크의 수집으로서 메모리를 구현한다. 각 뱅크의 폭은 최소 액세스 폭으로 주어지고 뱅크의 수는 최대 및 최소 엑세스 폭의 비로 주어진다. 각 메모리 뱅크와 그것의 결합된 기록 신호, 즉, 기록 동작과 기록 데이터를 나타내도록 제1루프가 사용된다. 제2루프는 모든 뱅크로부터 단일 버스안으로 데이터를 모으는데 사용된다.

도 11은 베이스 구성에서 사용자-정의 명령어를 포함하는 예시이다. 도면에서 도시된 바와 같이, 간단한 명령어들은 타이밍과 인터페이스가 ALU의 것과 유사할 때 프로세서 파이프라인에 부가될 수 있다. 이러한 방식으로 부가된 명령어들은 어떠한 스톨이나 예외상황을 발생시키지 않고, 어떠한 상태를 포함하지 않도록 하며, 단지 두 개의 표준 소스 레지스터 값과 명령어 단어를 입력으로 사용하여 단일 출력값을 초래한다. 그러나, TIE 언어는 불필요한 제약조건등의 프로세서 상태를 특정화시키는 준비과정을 갖는다.

도 12는 이러한 시스템하에서, 사용자-정의된 유닛에 대한 구현의 또다른 예시를 나타낸다. ALU의 8/16 병렬 데이터 유닛 확장인 상기 도면에 나타난 기능 유 닛은 다음 ISA 코드로부터 발생된다.

이들 수정 프로세서 상태를 포함하는 TIE-정의된 명령어들이 디코딩되고 실행되는 곳은 설계자-정의된 명령어 실행 유닛(96)이기 때문에, 그것은 본 발명의 또다른 특성에서 특정 관심분야중 하나가 된다. 본 발명의 이러한 특성에서, 다수의 구성요소들이 신규 명령어에 의해 판독 및 기록될 수 있는 부가적인 프로세서 상태를 나타낼 수 있도록 상기 언어에 부가되고 있다. 이들 "state" 문장들은 추가 프로세서 상태를 나타내도록 사용된다. 이러한 선언은 키워드 상태로 시작한다. 상태 문장의 다음 부분은 크기, 비트 수, 상태 수를 나타내고, 이러한 상태의 비트가 어떻게 인덱스되는지를 나타낸다. 상태의 이름이 되는 다음 부분은 기타 설명 부분 에서 상태를 확인하기 위해 사용되었다. "state" 문장의 마지막 부분은 상기 상태와 결합된 속성의 리스트이다. 예를 들어,

는 세 개의 신규 프로세서 상태, DATA, KEYC, 및 KEYD를 정의한다. 상태 DATA의 폭은 64비트이고 상기 비트는 63부터 0까지 인덱싱된다. KEYC 및 KEYD는 모두 28-비트 상태이다. DATA는 코프로세서 데이터 DATA가 속하는 것을 지시하는 코프로세서 - 수 속성 cpn을 갖는다.

속성 "autopack"은 DATA의 값이 소프트웨어 툴로 판독 및 기록될 수 있도록 사용자-레지스터 파일내의 어떤 레지스터에서 상태 DATA가 자동적으로 매핑된 것을 나타낸다.

user_register 섹션은 사용자 레지스터 파일내의 레지스터에서 상태의 매핑을 나타내도록 정의된다. user_register 섹션은 키워드 사용자-레지스터로 시작한 다음 레지스터 수를 나타내는 수가 뒤따르고, 레지스터상에 매핑될 상태 비트를 나타내는 표현으로 종결된다. 예를 들어,

DATA의 저차수 단어는 제1레지스터 파일로 매핑되고 고차수 단어가 제2레지스터 파일로 매핑되는 것이 구체화된다. 다음 두 개의 사용자 레지스터 파일 엔트리들은 KEYC 및 KEYD 값을 유지하도록 사용된다. 명백히, 이러한 섹션에서 상태 정보는 state 섹션의 것과 일치해야 한다. 여기서, 일치는 컴퓨터 프로그램에 의해 자동적으로 검사될 수 있다.

본 발명의 또다른 실시예에서, 사용자 레지스터 파일 엔트리에 대한 상태 비트의 할당은 빈-패킹(bin-packing) 알고리즘을 사용하여 자동적으로 유도된다. 또다른 실시예에서, 수동 및 자동 할당의 조합은 예를 들어, 상향 호환성을 보장하도록 사용될 수 있다.

명령어 필드 문장 field는 TIE 코드의 기독성을 개선시키기 위해 사용된다. 필드들은 이름에 의해 참조되고 함께 그룹화되는 다른 필드들의 연결 또는 서프셋이다. 명령어에서 비트의 완성된 세트는 최고 레벨 수퍼셋 필드 inst 이고, 이 필드는 더 작은 필도로 나누어질 수 있다. 예를 들어,

최고-레벨 필드 inst의 서브-필드(각각, 비트 8-11 및 12-15)로서 두 개의 4-비트 필드, x 및 y 그리고 상기 x 및 y 플디의 연결로서 8-비트 필드, xy 를 정의한다.

문장 opcode는 인코딩 특정 필드용 연산코드를 정의한다. 따라서 정의된 연산코드에 사용되도록 피연산자, 예를 들어, 레지스터 또는 즉시 상수를 구체화하도록 의도된 명령어 필드가 먼저 제 1 문장과 정의되어야 하고 그 다음 피연산자 상태가 정의되어야 한다.

예를 들어,

앞에서 정의된 연산코드 CUST0를 기초로 하는 두 개의 신규 연산코드, acs 및 adsel를 정의한다(4'b0000는 비트-긴 바이너리 상수 0000를 정의한다.). 바람직한 코어 ISA의 TIE 명세는 그것의 기본 정의에 대한 부분으로서 문장들

을 갖는다. 따라서, acs 및 adsel의 정의는 다음에 의해 각각 나타낸 명령어 디코딩 논리를 발생하도록 TIE 컴파일러를 초래한다.

명령어 피연산자 문장 operand는 레지스터 및 즉시 상수를 확인한다. 그러나, 피연자로서 필드를 정의하기 전에, 상술된 바와 같이 이전에 필드로서 정의되어야 한다. 피연산자가 즉시상수라면, 상수 값은 피연산자로서 발생될 수 있거나, 다음에서 설명된 바와 같이 정의된 앞에서 정의된 상수 테이블로부터 얻어질 수 있 다. 예를 들어, 즉시, 피연산자를 인코딩하기 위해서, TIE 코드는

오프셋에서 저장된 수의 4배가 되는 피연산자 offsets4와 사인된 수를 유지하는 18-비트 명시된 오프셋을 정의한다. operand 문장의 마지막 부분은 실제로 당업자에게 명백한 바와 같이 조합 회로를 설명하는 Verilog^TM HDL 의 서브셋에서의 계산을 실시하기 위해 사용되는 회로망을 설명한다.

여기서, wire 문장은 32-비트 폭을 갖는 t로 명시된 한 쌍의 논리 와이어를 정의한다. 와이어 문장 다음의 제1 assign 문장은 논리 와이어를 구동하는 논리 신호가 오른쪽으로 시프트된 offsets4 상수이고, 제 2 assign 문장은 더 낮은 18비트의 t가 offset 필드에 넣어지는 것을 상술한다. 제 1 assign 문장은 offset에 대한 연결로서 offsets4 피연산자 값을 직접 상술하고, 그것의 사인 비트(비트 17)의 14의 복사가 일어난 후 2비트가 좌측으로 시프트된다.

상수 테이블 피연산자를 위해, TIE코드는

상수(테이블에서 구성요소의 수가 되는 테이블 이름을 따르는 수)의 배열 prime을 정의하기 위해 table 문장을 이용하고 피연산자 prime_s용 값을 인코딩하기 위해 테이블 index로서 연산자 s를 사용한다.(인덱싱을 정의하는데 있어 Verilog^TM 문장의 이용을 주의).

명령어 클래스 문장 iclass 는 공통 포맷내에 피연산자를 갖는 연산 코드를 결합한다. iclass 문장내에서 정의된 모든 명령어들은 동일한 포맷과 피연산자 사용을 갖는다. 명령어 클래스를 정의하기 전에, 그것의 구성요소들이 먼저 필드로서 다음 연산코드로서 및 피연산자로서 정의되어야 한다. 예를 들어, 연산코드, acs 및 adsel을 정의하는 앞의 예시에 사용된 코드를 구성할 때, 부가적인 문장은,

세개의 레지스터 피연산자들 art, ars 및 arr을 정의하도록 operand 문장을 사용한다(정의에서 Verilog^TM 문장의 이용을 다시 주의). 그 후, iclass 문장은,

입력으로서 두 개의 레지스터 피연산자들 art 및 ars를 갖고 레지스터 피연산자 arr로 출력을 기록하는 공통 클래스의 명령어들 viterbi에 속한다는 것을 구체화한다.

본 발명에서, 명령어 클래스 문장 "iclass"는 명령어의 상태-엑세스 정보의 명세를 허용한다. 키워드 "iclass"로 시작하여 명령어 클래스의 이름, 명령어 클래스에 속하는 연산 코드 리스트 및 피연산자 엑세스 정보 리스트가 뒤따르고 상태 엑세스 정보를 위해 새룝게 정의된 리스트로 종결된다. 예를 들어,

여러가지 명령어 클래스와 다양하고 신규 명령어가 상태를 엑세스 하는 방법을 정의한다. 키워드 "in" , "out" 및 "inout"은 iclass 에서 명령어에 의해 판독, 기록 또는 수정(판독과 기록)된다. 이러한 예시에서, 상태 "DATA"는 명령어 "LDDTA"로 판독되고, 상태 "KEYC" 및 "KEYD"는 명령어 "STKEY"로 기록되고, "KEYC", "KEYD" 및 "DATA"는 명령어 "DES"로 수정된다.

명령어 의미론 문장 semantic는 피연산자를 코딩하기 위해 사용된 Verilog^TM 의 동일한 서브셋을 사용하는 하나 또는 그 이상의 명령어들의 동작을 설명한다. 단일 의미론 문장에서 곱셈 명령어들을 정의함으로써, 어떤 공통 표현들이 공유될 수 있고, 하드웨어 구현은 더욱 효과적일 수 있다. 의미론 문장에서 허용되는 변수들은 문장의 연산코드 리스트에서 정의된 연산코드용 피연산자이고, 연산코드 리스트에서 상술된 각각의 연산코드용 단일-변수이다. 이러한 변수는 연산코드가 디코딩될 때 1에 대한 계산을 하고 연산코드와 동일한 이름을 가진다. 대응 명령어의 존재를 지시하는 것은 계산 섹션(Verilog^TM 서브셋 섹션)에서 사용된다.

상술된 코드의 제1섹션은 BYTESWAP로 명시되는 신규 명령어용 연산코드를 정의한다.

여기서, 신규 연산코드 BYTESWAP는 CUST0의 서브-연산코드로서 정의된다. 아 래에서 더욱 상세히 설명되는 the Xtensa^TM Instruction Set Architecture Reference Manual 로부터, CUST0가

로서 정의된다.

여기서, op0 및 op1은 명령어에서의 필드이다. 일반적으로 연산코드는 계층적 방식으로 구성된다. 본 명세서에서, QRST는 톱-레벨 연산코드이고 CUST0는 QRST의 서브 -연산코드이고 BYTESWAP는 차례로 CUST0의 서브-연산코드이다. 연산코드의 계층적 구성은 연산코드 스페이스의 처리와 논리 그룹을 허용한다.

제2선언은 BYTESWAP 명령어로 인해 필요한 부가 프로세서 상태를 나타낸다.

여기서, COUNT는 32-비트 상태로 나타나고 SWAP는 1-비트 상태로 나타난다. TIE 언어는 비트 0이 최소 유효가될 때, COUNT에서의 비트가 31부터 0까지 인덱싱되는 것을 나타낸다.

The Xtensa^TM ISA는 특별한 시스템 레지스터들을 저장 및 재저장하는 두 개의 명령어, RSR 및 WSR을 제공한다. 유사하게, TIE에 나타난 상태를 저장 및 재저장하는 두 개의 명령어, RUR 및 WUR을 제공한다. TIE에 나타난 상태를 저장 및 재저장하기 위해서, RUR 및 WUR 명령어가 엑세스할 수 있는 사용자 레지스터 파일에서 엔트리하기 위한 상태의 매핑을 나타내야만 한다. 상술된 코드의 다음 섹션은 이러한 매핑을 나타낸다.

그 결과 다음 명령어들은 COUNT의 값을 2로 SWAP의 값을 5로 저장할 것이다.

이러한 구조는 실제로 상태의 내용을 검증하기 위해 테스트 프로그램에 사용된다. C에서, 상술된 두 개의 명령어들은,

와 같이 나타날 수 있다.

TIE 설명에서 중첩 섹션은 신규 명령어 BYTESWAP를 포함하는 신규 명령어 클래스를 정의한다.

여기서 iclass는 키워드이고 bs는 iclass의 이름이다. 다음 절(clase)은 명령어 클래스(BYTESWAP)를 리스트한다. 그 이후의 절은 이러한 클래스에서 명령어에 의해 사용되는 피연산자(이러한 경우에, 입력 피연자는 ars 이고 출력 피연산자는 arr)를 특정한다. iclass 정의에서 마지막 절은 이러한 클래스에서 명령어에 의해 엑세스되는 상태를 나타낸다(이러한 경우에 명령어는 상태 SWAP를 판독하고 상태 COUNT 를 판독 및 기록할 것이다).

상술한 코드에서 마지막 블록은 BYTESWAP 명령어용 형식적 의미론 정의를 제공한다.

상기 기술은 조합 논리를 설명하는 Verilog HDL용 서브셋을 이용한다. 이 블록은 신규 명령어를 지지하기 위해 Xtensa^TM 프로세서 하드웨어에서 부가 회로망이 합성 및 부가되는 방법과 명령어 집합 시뮬레이터가 BYTESWAP 명령어를 시뮬레이팅할 방법을 정확히 정의한다.

사용자-정의된 상태를 구현하는 본 발명에서, 선언된 상태들은 상기 상태에서 저장된 정보를 엑세싱하는 어떤 기타 변수와 같이 사용될 수 있다. 식의 우측에 나타난 상태 식별자는 상기 상태로부터 판독을 나타낸다. 상태에서 기록하는 것은 값 또는 식을 갖는 상태 식별자를 할당함으로써 행해진다. 예를 들어, 다음 의미론 코드 세그먼트는 상태가 명령어에 의해 판독 및 기록되는 방법을 나타낸다.

Tensilica Inc. 에 의한 개정판 1.0 인 The Xtensa^TM Instruction Set Archi tecture(ISA) Reference Manual은 구성 옵션을 선택하여 이용가능한 명령어 및 코어 명령어와 같이 구성 프로세서내에서 구현될 수 있는 명령어의 예시를 설명하기 위해 본 명세서에서 참조로 포함된다. 또한, Tensilica Inc. 에 의한 개정판 1.3인 Instruction Extension Language(TIE)는 사용자-정의된 명령어를 구현하기 위해 사용될 수 있는 TIE 언어 명령어의 예시를 나타내기 위해 참조로 포함된다.

TIE 설명으로부터, 명령어를 구현시키는 신규 하드웨어는 예를 들어, 부록 D 에 나타난 프로그램과 유사한 것을 사용하여 발생될 수 있다. 부록 E는 고유 함수로서 신규 명령어를 지지하기 위해 필요한 헤더 파일용 코드를 나타낸다.

구성 명세를 이용하여, 다음이 자동적으로 발생될 수 있다.

--프로세서(60)의 명령어 디코딩 논리;

--프로세서(60)의 불법 명령어 검출 논리;

--어셈블러의 ISA-특정부;

--컴파일러용 ISA-특정 지지 루틴;

--(디버거에 의해 사용된)디셈블러의 ISA-특정부; 및

-시뮬레이터의 ISA-특정부.

도 16은 이들 소프트웨어 툴의 ISA-특정부가 발생되는 방법에 대한 다이어그램이다. 사용자-작성된 TIE 기술 파일(400)로부터, TIE 파서 프로그램(410)이 여러가지 프로그램용 C코드를 생성하고, 각각의 C코드는 사용자-정의된 명령어 및 상태에 대한 정보용 하나 또는 그 이상의 소프트웨어 개발에 의해 엑세스된다. 예를 들어, 프로그램 tie2gcc(420)은 신규 명령어용 고유 함수 정의를 포함하는 xtensa-tie.h 라 불려지는 C헤더 파일(470)을 생성한다. 프로그램 tie2isa(430)은 사용자-정의된 명령어 포맷의 정보를 포함하는 동적으로 링크된 라이브러리(DLL) (480)를 생성한다(이하에서 토의된 Wilson et al. 응용프로그램에서, 이것은 여기서 토의된 인코드 및 디코드 DLLs의 효과적인 조합이다). 프로그램 tie2iss(440)은 성능 모델링 루틴을 생성시키고, Wilson et. al 응용프로그램에서 토의된 바와 같이, 시뮬레이터에 의해 사용된 시뮬레이터 DLL를 만들도록 호스트 컴파일러에 의해 사용된 명령어 의미론을 포함하는 DLL(490)을 초래한다. 프로그램 tie2ver(450)은 고유의 하드웨어 기술 언어에서 사용자-정의된 명령어용 필수기술(500)을 초래한다. 마지막으로, 프로그램 tie2xtos(460)는 RUR 및 WUR 명령어로 사용하는 저장 및 재저장 코드(510)를 일으킨다.

명령어의 정확한 기술과 그것들이 상태를 엑세스하는 방법은 현재의 고-성능 마이크로프로세서 설계내에서 이용할 수 있는 효과적인 논리를 발생시킬 수 있다. 본 발명의 이러한 실시예와 관련하여 기술된 방법들은 하나 또는 그 이상의 상태 레지스터로부터 판독 또는 그것으로 작성되는 이들 신규 명령어를 명확하게 취급한다. 특히, 이러한 실시예는 고성능을 달성하기 위한 기술로서 모두 파이프라이닝을 사용하는 마이크로프로세서 구현 스타일의 클래스에 관련하여 상태 레지스터용 하드웨어를 유도하는 방법을 나타낸다.

도 17에 나타난 것과 같은 파이프라인된 구현에서, 상태 레지스터는 일반적으로 여러번 복사되고, 각각의 실례(instantiation)는 특정 파이프라인 단계에서의 상태값을 나타낸다. 이러한 실시예에서, 상태는 기본적인 코어 프로세서 구현과 일치하는 레지스터의 다중 카피로 번역된다. 부가적인 바이패스와 전방 논리는 또한 기본적인 코어 프로세서 구현과 일치하는 방식으로 다시 발생된다. 예를 들어, 3개의 실행 단계를 구성하는 코어 프로세서 구현을 목표화시키기 위해서, 이러한 실시예는 상태를 도 18에 나타난 바와 같이 연결된 3개의 레지스터로 번역할 수 있다. 이러한 구현에서, 각각의 레지스터(610 - 630)는 3개의 파이프라인 단계중 하나에서 상태값을 나타낸다. ctrl-1, ctrl-2 및 ctrl-3는 대응하는 플립-플롭(610-630)에서 데이터 래칭할 수 있도록 사용된 제어 신호이다.

기본적인 프로세서 구현과 일치하도록 작동하는 상태 레지스터의 다중 카피를 만드는 것은 부가적인 논리 및 제어 신호를 요구한다. "Consistently"는 인터럽트, 예외상황 및 파이프라인 스톨의 조건하에서 프로세서 상태의 나머지와 같은 방식으로 정확히 작동해야만 한다는 것을 의미한다. 일반적으로, 소정의 프로세서 구현은 다양한 파이프라인 조건을 나타내는 어떤 신호를 정의한다. 이러한 신호들은 파이프라인 상태 레지스터가 적절히 작용하기 위해 필요하다.

전형적인 파이프라인된 구현에서, 실행 유닛은 다중 파이프라인 단계를 구성한다. 명령어의 계산은 이러한 파이프라인의 다중 단계에서 수행된다. 명령어 스트림(stream)은 제어논리로 안내된 바와 같은 순서로 파이프라인을 통하여 흐른다. 어떤 주어진 시간에서도, 파이프라인에서 실행된 n 명령어까지 이를 수 있고, 여기서, n은 단계의 개수이다. 본 발명을 사용하여 구현가능한 수퍼 스칼라 프로세서에서, 파이프라인내의 명령어 개수는 n·w 가 될 수 있고, 여기서, w는 프로세서의 이슈(issue)폭이다.

제어 논리의 역할은 명령어들 사이의 종속이 지켜지고, 명령어들 사이의 어떤 인터퍼렌스(interference)가 결정되는 것을 확실히 하는 것이다. 명령어가 초기 명령어에 의해 계산된 데이터를 사용한다면, 특수 소프트웨어는 파이프라인을 스톨하지 않고 더 나중 명령어로 데이터를 진행시킬 필요가 있다. 인터럽트가 발생하면, 파이프라인내의 모든 명령어가 제거되고 나중에 다시 실행될 필요가 있다. 명령어의 입력 데이터 또는 그것이 필요한 계산 하드웨어가 이용될 수 없기 때문에 명령어가 실행될 수 없다면, 명령어는 스톨되어야 한다. 명령어를 스톨하는 한가지 비용효과를 기대할 수 있는 방법은 제1명령어에서 그것을 제거하는 것이고 다음 사이클에서 명령어를 재실행하는 것이다. 이러한 기술의 결과는 파이프라인에서 무효 단계(버블)를 발생시킨다. 이러한 버블은 다른 명령어들과 함께 파이프라인을 통과하여 흐른다. 명령어가 남겨져있는 파이프라인의 끝에서, 버블이 제거된다.

상기 3-단계 파이프라인 예시를 사용하여, 이러한 프로세서 상태의 일반적인 구현은 도 19에 나타난 연결과 부가적인 논리를 필요로한다.

표준 상태하에서, 단계에서 계산된 값은 데이터 종속에 의해 도입된 파이프라인 스톨의 개수를 감소시키기 위해서 파이프라인의 끝에 이르기 위한 값에 대한 대기 없이 즉시 다음 명령어로 진행될 것이다. 이것은 다음 명령어에 의해 즉시 사용될 수 있는 의미론 블록에 직접 제1플립-플롭(610)의 출력을 보냄으로써 수행된다. 인터럽트 및 예외상황등의 비정상 조건을 처리하기 위해, 구현은 다음 제어 신호들: kill_1, kill_all 및 Valid_3을 필요로한다.

신호 "kill_1"는 그것이 결과(proceeds)를 필요로하는 데이터를 갖지 않는등의 이유로 인해서 제1파이프라인 단계(110)에서 일반적인 명령어들이 제거되어야 한다는 것을 나타낸다. 일단 명령어가 제거되면, 그것은 다음 사이클에서 재시도될 것이다. 신호 "kill_all"는 파이프라인에서 일반적인 모든 명령어들은 그것들 앞의 명령어가 예외상황을 발생시키거나 인터럽트가 발생되는 등의 이유로 제거되어야 한다. 신호 " Valid_3"은 마지막 단계(630)에서 일반적인 명령어들이 유효 또는 무효인지를나타낸다. 이러한 조건은 제1파이프라인 단계(610)에서 명령어를 제거하고 파이프라인에서 버블(무효 명령어)을 일으키는 결과이다. "Valid_3"은 제3파이프라인 단계에서의 명령어가 유효 또는 버블인지를 나타낸다. 명백히, 유효 명령어만이 래치되어야 한다.

도 20은 상태 레지스터를 구현시키는데 필요한 연결과 부가 논리를 나타낸다. 그것은 이러한 상태-레지스터 구현이 상기 필요조건을 충족하도록 신호 "ctrl-1", "ctrl-2" 및 "ctrl-3" 를 구동하기 위해 제어논리를 구성하는 방법을 나타낸다. 다음은 도19에 나타난 바와 같이 상태 레지스터를 구현하기 위해 자동적으로 발생된 샘플 HDL 코드이다.

endmodule

상기 파이프라인된 상태 레지스터 모듈을 사용하여, 의미론 블록이 그것의 입력으로서 상태를 특징지울 때, 입력 변수로서 상태의 현재 상태값이 의미론 블록에 통과된다. 상태용 신규 값을 발생시키기위해 의미론 블록이 논리를 가질 때, 출력 신호가 생성된다. 이러한 출력 신호는 파이프라인된 상태 레지스터에서 다음-상태 입력으로서 사용된다.

이러한 실시예는 다중 의미론 기술 블록을 허용하고, 그것의 각각은 다중 명령어용 동작을 기술한다. 이러한 자유로운 기술 스타일하에서, 의미론 블록의 서브셋만이 주어진 상태용 다음-상태 출력을 발생시킬 수 있다. 또한, 주어진 의미론 블록이 주어진 시간에서 그것이 실행하는 명령어에 따라 일반적으로 다음-상태 출력을 또한 발생시킬 수 있다. 결과적으로, 부가 하드웨어 논리는 입력을 형성하도록 모든 의미론 블럭으로부터 파이프라인된 상태 레지스터까지 다음 상태 출력을 조합하는 것을 필요로한다. 본 발명의 이러한 실시예에서, 이러한 블록이 상태용으로 신규 값을 발생하는지 안하는지를 나타내도록 각각의 의미론 블록에서 자동적으로 신호가 얻어진다.

도 20은 여러가지 의미론 블록 s1_sn으로부터 상태의 다음-상태 출력을 조합하고 상태 레지스터에서 입력하기 위해 적절히 하나를 선택하는 방법을 나타낸다. 이러한 도면에서, op1_1 및 op1_2는 제1의미론 블록용 연산코드 신호이고, op2_1 및 op2_2는 제2의미론 블록등의 연산코드 신호이다. 의미론 블록 i의 다음-상태 출력은 si이다( 다중 상태 레지스터가 존재한다면 블록용 다중 다음-상태 출력이 존재한다.). 의미론 블록 i 가 상태용 신규 값을 초래한다는 것을 나타내는 신호는 si_we 이다. 신호 s_we는 의미론 블록의 일부가 상태용 신규 블록을 초래하는지 기록-가능한 신호로서 파이프라인된 상태 레지스토에서 입력으로 사용되는 지를 나타낸다.

다중 의미론 블록의 표현 능력이 단일 의미론 블록의 표현 능력보다 크지 않지만, 그것은 일반적으로 관련 명령어를 단일 블록내로 그룹화함으로써 더욱 구조화된 기술을 구현시키는 방식을 제공한다. 또한 명령어가 구현되는 더욱 제한된 유효범위로 인해 다중 의미론 블록은 명령어 효과의 더 간단한 분석을 이끌 수 있다. 한편, 다중 명령어의 동작을 기술하기 위해서 단일 의미론 블럭에 대한 근거들이 자주 존재한다. 대개 자주, 그것은 이러한 명령어의 하드웨어 구현이 공통 논리를 공유하기 때문이다. 단일 의미론 블록에서 다중 명령어를 기술하는 것은 일반적으로 더욱 효과적인 하드웨어 설계를 초래한다.

인터럽트와 예외상황으로인해, 데이터 메모리로부터 데이터 메모리까지 상태값들을 재저장하고 로드하기 위해 소프트웨어가 필요하다. 신규 상태와 신규 명령어의 형식적 기술을 기초로, 재저장 및 로드 명령어등을 자동적으로 발생시킬 수 있다. 본 발명의 실시예에서, 재저장 및 로드 명령어용 논리는 두 개의 의미론 블록처럼 자동적으로 발생되고 그 후 두 개의 의미론 블록은 어떤 다른 블록과 같이 실제 하드웨어내에서 순환가능하게 번역될 수 있다. 예를 들어, 상태의 다음 선언 으로부터:

다음 의미론 블록은 범용 레지스터내에서 "DATA", "KEYC", 및 "KEYD"의 값을 판독하기 위해 생성될 수 있다.

도 21은 이런 종류의 의미론 논리에 대응하는 논리의 블록도를 나타낸다. 입력 신호 "st"는 user_register 명세와 일치하는 방식으로 상태 레지스터로부터 어떤 비트를 선택하기 위해 사용되는 다양한 선택 신호를 형성하기 위해 다양한 상수와 비교된다. 이전의 상태 선언을 사용하여, 비트32의 DATA는 비트0의 제2사용자 레지스터에 나타난다. 따라서, 이러한 다이어그램에서 MUX의 제2입력은 32 비트의 DATA 상태로 연결되어야 한다.

다음 의미론 블록은 범용 레지스터로부터 값을 갖는 상태 "DATA", "KEYC" 및 "KEYD" 를 기록하기 위해 생성될 수 있다.

도 22는 jth비트의 상태 S가 kth 비트의 ith 사용자 레지스터에 맵될 때 jth 비트의 상태 S용 논리를 나타낸다. WUR 에서 user_register 수가 "i" 일 때, kth 비트의 "ars"가 S[j] 레지스터내로 로드된다; 이와 달리, S[j]의 초기값이 재순환된다. 또한, 어떤 비트의 상태 S가 재로드될 때, 신호 S_we가 허가된다.

TIE user_register 선언은 상태 선언에 의해 정의된 부가 프로세서 상태로부터 TIE 명령어에 독립적인 이러한 상태를 판독 및 작성하기 위해 이들 RUR 및 WUR 명령어에 의해 사용된 식별자로 매핑을 구체화한다.

부록F는 RUR 및 WUR 명령어를 생성시키는 코드를 나타낸다.

RUR 및 WUR의 주목적은 작업 스위칭용이다. 다중-작업 환경에서, 다중 소프트웨어 작업은 어떤 스케줄링 알고리즘에 따라 실행하는 프로세서를 공유한다. 액티브할 때, 작업 상태가 프로세서 레지스터에 남는다. 스케줄링 알고리즘이 또다른 작업으로 스위치하도록 결정할 때, 프로세서 레지스터에 유지된 상태는 메모리에 저장되고 또다른 작업 상태는 메모리로부터 프로세서 레지스터로 로드된다. The Xtensa^TM Instruction Set Architecture(ISA)는 ISA 에 의해 정의된 상태를 판독 및 기록하기 위해서 RSR 및 WSR 명령어를 포함한다. 예를 들어, 다음 코드는 작업 "메모리에 저장" 부분이다.

그리고 다음 명령어는 작업 "메모리로부터 재저장" 부분이다.

여기서 SAR, LCOUNT, LBEG, LEND는 코어 Xtensa^TM ISA의 프로세서 상태 레지스터이고, ACCLO, ACCHI, MR_0, MR_1, MR_2 및 MR_3는 MAC Xtensa^TM ISA 옵션의 일부분이다(레지스터는 파이프라인 인터록을 회피하기 위해 쌍으로 저장 및 재저장된다).

설계자가 TIE를 갖는 신규 상태를 정의할 때, 그것은 상기 상태와 같이 스위치된 작업이되어야 한다. 한가지 가능성은 설계자가 작업 스위치 코드를 간단히 편집하고 상기 코드에 유사한 RUR/S32I 및 L32I/WUR 명령어를 부가시킬 수 있다는 것 이다. 그러나, 소프트웨어가 자동적으로 생성되고 구성에 의해 교정될 때, 구성가능한 프로세서가 가장 효과적이다. 따라서, 본 발명은 작업 스위치 코드를 자동적으로 증가시키는 기능을 포함한다.

다음 tpp 라인은 상기 저장 작업에 부가된다.

그리고 다음 라인들은 상기 저장 작업에 부가된다.

마지막으로, 메모리에서 작업 상태 영역은 사용자 레지스터 기억장치를 위해 할당된 부가 스페이스를 구비해야 하고, 작업 저장 포인터의 베이스로부터 이러한 공간의 오프셋은 어셈블러 상수 UEXCUREG로서 정의된다. 이러한 저장 영역은 이전에 다음 코드에 의해 정의되었다.

는

로 변경되었다.

이러한 코드는 사용자 레지스터 번호에 대한 리스트를 갖는 tpp 가변 @user _register인 것에 의존한다. 이것은 간단히 모든 user _register 문장의 제1인자로부터 작성된 리스트이다.

다소 더욱 복잡한 마이크로프로세서를 구현하는데 있어서, 상태는 상이한 파이프라인 상태에서 계산될 수 있다. 프로세스에서 여러가지 확장(간단한 것이긴 하지만)을 필요로하는 이것을 처리하는 것이 본 명세서에서 기술되었다. 먼저, 명세 언어는 파이프라인 단계를 갖는 의미론 블록을 결합시키기 위해 필요하다. 이것은 여러가지 방법중 하나에서 수행될 수 있다. 일 실시예에서, 결합된 파이프라인 단계는 각각의 의미론 블록을 가지고 명백히 특징지어질 수 있다. 또다른 실시예에서, 파이프라인 단계의 범위는 각각의 의미론 블록을 위해 특징지어질 수 있다. 더욱 또다른 실시예에서, 주어진 의미론 블록을 위한 파이프라인 단계는 요구된 계산 지연에 따라 자동적으로 유도될 수 있다.

상이한 파이프라인 단계에서 상태 생성을 지지하는 제2작업은 인터럽트, 예외상황, 및 스톨을 처리하는 것이다. 일반적으로 이것은 파이프라인 제어 신호의 조절하에 고유의 바이패스 및 전방 논리를 부가하는 것을 포함한다. 일실시예에서, 생성-이용(generate-usage)다이어그램은 상태가 생성될 때 및 그것이 사용될 때 사이의 관계를 나타내기 위해 생성될 수 있다. 응용프로그램 분석을 기초로, 고유의 전방 논리는 공통 위치를 처리하기 위해 구현될 수 있고, 인터록 논리는 전방 논리에 의해 처리될 수 없는 경우를 위해 파이프라인을 스톨하기 위해 생성될 수 있다.

베이스 프로세서의 명령어 이슈 논리를 수정하는 방법은 베이스 프로세서에 의해 이용되는 알고리즘에 종속된다. 그러나, 일반적으로 말해서, 싱글-이슈인지 또는 수퍼 스칼라인지, 단일-사이클인지 명령어인지 또는 멀티-사이클 명령어인지에 따라 대부분의 프로세서용 명령어 이슈 논리는 이슈를 위해 테스트된 명령어에 단지 의존한다:

1. 소스로서 명령어가 상태를 이용하는지에 대하여 각각의 프로세서 상태 요소를 가리키는 신호;

2. 목적으로서 명령어가 상태를 이용하는지에 대하여 각각의 프로세서 상태 요소가 가리키는 신호;

3. 명령어가 기능 유닛을 사용하는지에 대하여 각각의 기능 유닛을 가리키는 신호;

이들 신호는 파이프라인 및 크로스-이슈 검사에서 이슈를 실행하고 파이프라인-종속 이슈 논리에서 파이프라인 상태를 업데이트하기 위해 사용된다. TIE는 신규 명령어에 신호와 그것들의 방정식을 증가시키기 위해서 모든 필요한 정보를 포함한다.

첫째, 각각의 TIE 상태 선언은 신규 신호가 명령 이슈 논리를 위해 작성되도록 한다. iclass선언에서 제3 또는 제4인자에 리스트된 각각의 in 또는 inout 피연자 또는 상태는 특정 프로세서 상태 요소용 제1세트의 방정식에서 제2인자에 리스트된 명령어를 위해서 명령어 디코드 신호를 부가한다.

둘째, iclass선언에서 제3 또는 제4인자에 리스트된 각각의 out 또는 inout 피연산자 또는 상태는 특정 프로세서 상태 요소용 제2세트의 방정식에서 제2인자에 리스트된 명령어를 위해 명령어 디코드 신호를 부가한다.

셋째, 각각의 TIE 의미론 블록으로부터 작성된 논리는 신규 기능 유닛을 나타내어서, 신규 유닛 신호가 작성되고, 의미론 블록을 위해서 명시된 TIE 명령어용 디코드 신호는 제3세트의 방정식을 형성하기 위해 함께 OR'd 된다.

명령어가 이슈될 때, 파이프라인 상태는 다음 이슈 결정을 위해 업데이드되어야 한다. 다시 알고리즘에 종속된 베이스 프로세서의 명령어 이슈 논리를 수정하는 방법은 베이스 프로세서에 의해 사용된다. 그러나, 다시 어떤 일반적인 관찰 정보가 일어날 수 있다. 파이프라인 상태는 이슈 논리 뒤에 다음 상태를 제공해야 한다:

4. 그 결과가 바이패스용으로 이용될 대 각각의 이슈된 명령어를 가리키는 신호;

5. 기능 유닛이 또다른 명령어를 준비하는 것을 나타내는 각각의 기능 유닛용 신호.

본 명세서에서 기술된 실시예는 설계자-정의된 명령어들이 논리 계산의 단일 사이클에서 제한되는 단일-이슈 프로세서이다. 이러한 경우에, 단일-이슈 프로세서는 상당히 단순화된다. 기능 유닛 검사 또는 크로스-이슈 검사가 필요하지 않고, 단일-사이클 명령어가 프로세서 상태 요소를 만들 수 없어서 다음 명령어를 위해 파이프준비되지 않는다. 따라서, 이슈 방정식은

이 되고 여기서 src[i] 파이프준비 신호는 부가 명령어에 의해 영향을 받지않고, src[i]이용은 상술된 바와 같이 기술되고 수정된 제1세트의 방정식이다. 이러한 실시예에서, 제4 및 제5 세트의 신호들은 요구되지 않는다. 다중-사이클을 갖는 다중-이슈가 되는 대안적인 실시예에서, TIE 명세는 계산을 파이프라인하기 위한 사이클의 수를 제공하는 각각의 명령어를 위해 대기시간 명세를 가지고 증가될 것이다.

제4세트의 신호들은 명세에 따른 이러한 단계에서 완성된 각각의 명령어용 명령어 디코드 신호와 함께 OR'ing 함으로써 각각의 의미론 블록 파이프 단계에서 생성될 수 있다.

디폴트에 의해 생성된 논리는 완전히 파이프라인될 것이고, TIE 생성 기능 유닛은 명령어를 인식한 후 항상 하나의 사이클을 준비할 것이다. 이러한 경우에 TIE 의미론 블록용 제5세트의 신호가 항상 가정된다. 다중 사이클에서 의미론 블록내의 논리를 재사용하는 것이 필요할 때, 추가된 명세는 이러한 명세서에서 기능유닛이 사용될 때 얼마나 많은 사이클이 준비되는지를 명확히 할 것이다.

대안적으로, 상이한 실시예에서, 결과 준비와 기능 유닛 준비 신호를 특징지우기 위해 설계자가 TIE하는 것은 확장으로써 남겨질 수 있다.

이러한 실시예에 따라 처리된 코드의 예시는 첨부된 부록에서 나타난다. 간 략화를 위해, 이들은 상세히 설명되지 않을 것이다. 그러나, 그것들은 상술된 참조 매뉴얼를 검토한 후 당업자에 의해 쉽게 이해될 것이다. 부록G는 TIE 언어를 사용하는 명령어의 구현 예시이다. 부록 H는 이러한 코드를 사용하는 컴파일러용으로 TIE 컴파일러가 생성하는 것을 나타낸다. 유사하게, 부록I는 시뮬레이터용으로 TIE 컴파일러가 생성하는 것을 나타낸다. 부록 J는 TIE 컴파일러가 사용자 응용에서 TIE 명령어를 확장하는 매크로용으로 생성하는 것을 나타낸다. 부록 K는 원시 모드에서 TIE 명령어를 시뮬레이트 하기 위해 특약 컴파일러가 생성하는 것을 나타낸다. 부록 L은 특약 컴파일러가 부가 하드웨어용으로서 Verilog HDL 기술을 생성하는 것을 나타낸다. 부록 M은 전체 CPU 크기와 성능상의 TIE 명령어의 속도 임팩트와 영역을 추정하기 위해 상기 Verilog HDL 기술을 최적화시키기 위해 Design Compiler 스크립트로서 TIE 컴파일러가 생성하는 것을 나타낸다.

상술된 바와 같이, 프로세서 구성 절차를 시작하기 위해서, 사용자는 상술된 GUI를 통해 베이스 프로세서 구성을 선택함으로써 시작한다. 프로세서의 부분으로서, 소프트웨어 개발 시스템(30)은 도 1에 나타난 바와 같이 사용자에게 구축 및 전달된다. 소프트웨어 개발 시스템(30)은 도 6에서 더욱 상세히 설명된 본 발명의 또다른 특성에 관한 4개의 중요 구성요소: 컴파일러(108), 어셈블러(110), 명령어 집합 시뮬레이터(112) 및 디버거(130)를 포함한다.

당업자에게 잘 알려진 컴파일러는 C 또는 C++ 등의 고레벨 프로그래밍 언어로 기록된 사용자 응용프로그램을 프로세서-특정 어셈블리 언어로 변환시킨다. C 또는 C++ 등의 고레벨 프로그래밍 언어는 응용프로그램 작성자가 정확히 기술하기 쉬운 형태로 그들의 응용프로그램을 기술하도록 설계된다. 이들은 프로세서에 의해 이해되는 언어가 아니다. 응용프로그램 작성자는 사용될 프로세서의 모든 특정한 특성들에 대하여 반드시 걱정할 필요가 없다. 동일한 C 또는 C++ 프로그램은 일반적으로 많은 상이한 형태의 프로세서들과 거의 사용될 수 없거나 그것에 어떠한 수정을 이용할 수 없다.

컴파일러는 C 또는 C++ 프로그램을 어셈블리 언어로 번역한다. 어셈블리 언어는 기계어에 더욱 가깝고, 상기 언어는 프로세서에 의해 직접 지지되었다. 상이한 형태의 프로세서들은 그것 자신의 어셈블리 언어를 가질 것이다. 종종 각각의 어셈블리 언어는 직접 하나의 기계 명령어를 나타내지만, 이 둘은 반드시 동일하지 않다. 어셈블리 명령어는 사람이 판독하기 쉬운 문자열이 되도록 설계된다. 각각의 명령어와 피연산자는 의미있는 이름 또는 기억을 돕는 이름을 받아, 인간이 어셈블리 명령어를 판독하고 기계에 의해 피연산자가 실행될 것을 쉽게 이해하도록 한다. 어셈블러는 어셈블리 언어를 기계어로 변환시킨다. 각각의 어셈블리 명령어 문자열은 프로세서에 의해 직접 및 효과적으로 실행될 수 있는 하나 또는 그 이상의 기계 명령어 내로 어셈블러에 의해 효과적으로 인코딩된다.

기계 코드는 프로세서상에서 직접 실행될 수 있지만, 물리적 프로세서들은 항상 즉시 이용되지 않는다. 물리적 프로세서를 구축하는 것은 시간 소모이고 값비싼 처리이다. 포텐셜 프로세서 구성을 선택할 때, 사용자는 각각의 포텐셜 선택용 물리적 프로세서를 구축할 수 있다. 그 대신, 사용자는 시뮬레이터라 불리워지는 소프트 프로그램으로 제공된다. 일반 컴퓨터상에 실행하는 프로그램인 시뮬레이터 는 사용자 구성된 프로세서상에 사용자 응용 프로스램을 실행하는 효과를 시뮬레이트할 수 있다. 시뮬레이터는 시뮬레이트된 프로세서의 의미론을 모방할 수 있고 실제 프로세서가 사용자의 응용프로그램을 얼마나 빨리 실행시킬 수 있는 가를 사용자에게 말해줄 수 있다.

디버거는 사용자가 그들의 소프트웨어가 갖는 문제점을 상호작용하여 발견하도록 하는 툴이다. 상기 디버거는 사용자가 그들의 프로그램을 상호작용하여 실행하게 한다. 사용자는 임의의 시간에서 프로그램의 실행을 정지시키고, C소스 코드, 결과 어셈블리 또는 기계 코드를 바라볼 수 있다. 사용자는 또한 정지점에서 변수들 또는 하드웨어 레지스터들의 일부 또는 모든 값을 검사 또는 수정할 수 있다. 그 후, 사용자는 신규 사용자-선택 정지점에서 한꺼번에 한 문장, 한꺼번에 하나의 기계 명령어의 실행을 계속할 수 있다.

4개의 구성요소들(108, 110, 112 및 130)은 사용자-정의된 명령어(750)(도 3참조)의 인식을 필요로 하고 시뮬레이터(112)와 디버거(130)은 사용자-정의된 상태 (752)를 부가적으로 인식해야만 한다. 상기 시스템은 사용자 C 및 C++ 응용프로그램에 부가된 내장(intrinsics)을 통해 사용자가 사용자-정의된 명령어(750)를 액세스하도록 한다. 컴파일러(108)는 사용자-정의된 명령어(750)을 위해 내장 호출을 신규 어셈블리 명령어(738)로 번역해야 한다. 어셈블러(110)는 사용자에 의해 직접 기록되는지 또는 컴파일러(108)에 의해 번역되는지간에 신규 어셈블리 언어 명령어 (738)를 가져야만하고 사용자-정의된 명령어(750)에 대응하는 기계 명령어(740)내로 그것들을 인코딩해야 한다. 시뮬레이터(112)는 사용자-정의된 기계 명령어(740) 를 디코드해야 한다. 명령어의 의미론을 모델하고 구성된 프로세서상의 명령어의 성능을 모델해야 한다. 또한, 시뮬레이터(112)는 사용자-정의된 상태의 성능과 값을 모델해야 한다. 디버거(130)는 사용자가 사용자-정의된 명령어(750)를 포함하는 어셈블리 언어 명령어(738)를 프린트하게 해야 한다. 그것은 사용자가 사용자-정의된 상태의 값을 검사 및 수정하게 해야 한다.

본 발명의 이러한 특성에서, 현재 일어날 가능성 있는 사용자 정의된 인핸스먼트(736)를 처리하기 위해서, 사용자는 툴, TIE 컴파일러(702)를 일으킨다. TIE 컴파일러(702)는 사용자 응용프로그램을 어셈블리 언어(738)로 번역하는 컴파일러 (708)과 다르다. TIE 컴파일러(702)는 이미-구축된 베이스 소프트웨어 시스템(30)(컴파일러(708), 어셈블러(710)와 시뮬레이터(712) 및 디버거(730))가 신규, 사용 자-정의된 인핸스먼트(736)를 사용할 수 있는 구성요소를 구축한다. 소프트웨어 시스템(30)의 각각의 요소는 다소 상이한 세트의 구성요소를 포함한다.

도 24는 이들 소프트웨어 툴의 TIE-특정 부분이 생성되는 방법에 대한 다이어그램이다. 사용자-정의된 확장 파일(736)으로부터, TIE 컴파일러(702)는 여러가지 프로그램용 C 코드를 생성하고, 그것의 각각은 사용자-정의된 명령어와 상태에 관한 정보를 위해서 하나 또는 그 이상의 소프트웨어 개발 툴에 의해 엑세스되는 파일을 만든다. 예를 들어, 프로그램 tie2gcc(800)은 신규 명령어용 내장 함수 정의를 포함하는 (이하에서 더욱 상세히 설명된) xtensa-tie.h라 불려지는 C 헤더 파일(842)를 생성한다. 프로그램 tie2isa(810)은 사용자-정의된 명령어 포맷(이하에서 더욱 상세히 기술된 디코드 DLL(848)과 인코드 DLL(844)의 조합)상에 정보를 포함하는 동적 링크된 라이브러리(DLL)(844/848)을 생성한다. 프로그램 tie2iss(840)은 이하에서 더욱 상세히 설명될 바와 같이 시뮬레이터(712)에 의해 사용된 시뮬레이터 DLL(849)를 발생시키기 위해 호스트 컴파일러(846)에 의해 사용된 이하에서 설명될 명령어 의미론과 성능 모델링용 C코드(870)을 생성한다. 프로그램 tie2ver (850)은 고유의 하드웨어 기술 언어에서 사용자-정의된 명령어용 필수 기술(850)을 만든다. 마지막으로, 프로그램 tie2xtos(860)은 문맥 스위칭용 사용자-정의된 상태를 저장 및 재저장 하기 위해 코드(810)을 저장 및 재저장한다. 사용자-정의된 상태의 구현상의 부가 정보는 앞에서-언급된 Wang el al. 응용프로그램에서 발견될 수 있다.

컴파일러(708)

이러한 실시예에서, 컴파일러(708)는 사용자의 응용프로그램에서의 내장 호출을 사용자-정의된 인핸스먼트(736)용 어셈블리 언어 명령어(738)로 번역한다. 컴파일러(708)는 CNU 컴파일러등의 표준 컴파일러에서 발견된 인라인 어셈블리 장치와 매크로의 맨위에서 이러한 장치를 구현한다. 이들 장치에서의 더 많은 정보를 위해서, 예를 들어, GNU C 및 C++ Compiler User's, EGCS Version 1.0.3.를 참조.

2개의 레지스터들상에서 연산하고 제3레지스터에서 결과를 리턴하는 신규 명령어 foo를 작성하기를 바라는 사용자를 고려해보자. 사용자는 특수 디렉토리의 사용자-정의된 명령어 파일(750)에서 명령어 기술을 하고, TIE 컴파일러(702)를 일으킨다. 이러한 파일은 foo의 다음 정의를 포함한다.

사용자가 응용프로그램상에 컴파일러(708)를 일으킬 때, 명령 라인 옵션 또는 환경 변수중 어느 하나를 통해 사용자-정의된 인핸스먼트(736)를 갖는 디렉토리의 이름을 컴파일러(708)에 나타낸다. 또한, 디렉토리는 xtensa-tie. h file(742)를 포함한다. 컴파일러(708)는 사용자가 스스로 foo의 정의를 기록했을 때처럼 컴파일된 사용자 C 또는 C++ 응용프로그램내로 파일 xtensa-tie.h를 자동적으로 포함한다. 포함된 정의때문에, 컴파일러(708)는 상기 포함된 정의에서 호출처럼 이들 내장 호출을 취급한다. 컴파일러(708)에 의해 제공된 표준 메크로 장치를 기초로하여, 사용자는 매크로 호출보다 어셈블리 언어 문장(738)을 직접 기록했을 때 처럼 호출을 매크로 foo로 취급한다. 즉, 표준 인라인 어셈블리 장치를 기초로, 컴파일러(708)는 호출을 단일 어셈블리 명령어 foo로 번역한다. 예를 들어, 사용자는 내장 foo에서 호출을 포함하는 함수를 가질 것이다.

컴파일러는 함수를 사용자 정의된 명령어 foo를 사용하는 다음 어셈블리 언어 서브루틴으로 번역한다.

사용자가 신규 세트의 사용자-정의된 인핸스먼트(736)을 작성할 때, 어떠한 신규 컴파일러도 재구축될 필요가 없다. TIE 컴파일러(702)는 단지 사용자 응용프로그램내로 미리 구축된 컴파일러(708)에 의해 자동적으로 포함된 파일 xtensa-tie.h(742)을 작성한다.

어셈블러(710)

이러한 실시예에서, 어셈블러(710)는 어셈블리 명령어(750)을 인코드하기 위해 인코드 라이브러리(744)를 사용한다. 이러한 라이브러리(744)에서의 인터페이스는 함수를 포함한다:

--연산코드 의사기호 문자열을 내부 연산코드 표시로 번역;

--각각의 연산코드용으로 생성될 비트 패턴을 기계 명령어(740)내의 연산코드 파일에 제공; 및

--각각의 명령어 피연산자용 피연산자 값을 인코드하고 상기 인코드된 피연산자 비트 패턴을 기계 명령어(740)의 피연산자 필드내로 삽입.

예시로서, 내장 함수 foo를 호출하는 사용자 함수의 앞선 예시를 고려해 보자. 어셈블러는 "foo a2, a2, a3" 명령어를 취하여 그것을 16진수 0x62230로 표현된 기계 명령어로 변환하고, 여기서 높은 자리수 6과 낮은 자리수 0은 함께 foo 에 대한 연산코드를 나타내고, 상기 2, 2, 3은 3개의 레지스터 a2, a2, a3을 각각 나타낸다.

이들 함수의 내부 구현은 테이블 및 내부 함수들의 조합을 기초로 한다. 테이블은 TIE 컴파일러(702)에 의하여 쉽게 생성되지만, 그것의 표현성은 제한된다. 피연산자 인코딩 함수를 표현하는 것과 같이, 유연성이 더욱 필요하게 되면, TIE 컴파일러(702)는 라이브러리(744)에 포함될 임의의 C 코드를 생성할 수 있다.

"foo a2, a2, a3"의 예시를 다시 고려해 보자. 모든 레지스터 필드는 상기 레지스터의 넘버로 간단히 인코딩된다. 상기 TIE 컴파일러(702)는 리걸 레지스터값을 체크하는 다음의 함수를 만들고, 만일 상기 값이 리걸이면, 상기 레지스터 넘버로 복귀한다.

전체 인코딩이 매우 간단하다면, 인코딩 함수는 필요하지 않을 것이고, 테이블은 충분할 것이다. 그러나, 사용자는 더욱 복잡한 인코딩을 선택하도록 된다. TIE 언어로 기술된 다음의 인코딩은 피연산자를 1024로 나눈 값인 넘버로 모든 피연산자를 인코딩한다. 이러한 인코딩은 1024의 배수일 것이 요구되는 값을 조밀하게 인코딩하는데 유용하다.

operand tx10 t {t << 10} { tx10 >> 10 }

상기 TIE 컴파일러는 상기 피연산자 인코딩 기술을 다음의 C 함수로 변환한 다.

상기 피연산자에 대하여 가능한 값의 도메인이 매우 크기 때문에, 테이블은 상기의 인코딩을 사용할 수 없다. 테이블은 매우 커져야 할 것이다.

인코드 라이브러리(744)의 구현에 있어서, 하나의 테이블은 연산코드 의사기호 문자열을 상기 내부 연산코드 표시로 매핑시킨다. 효율을 위하여, 이 테이블은 정렬될 수 있거나 또는 해시(hash) 테이블이나 유효 검색(efficient searching)을 허용하는 일부 다른 자료 구조일 수 있다. 또 다른 테이블은 상기 연산코드를 위한 적절한 비트 패턴에 대해 초기화된 연산코드 필드를 갖는 기계 명령어의 템플리트로 각각의 연산코드를 매핑시킨다. 동일한 피연산자 필드 및 피연산자 인코딩을 갖는 연산코드들은 함께 그룹화된다. 이들 그룹들 중의 하나에서의 각 피연산자에 대해서는, 라이브러리가 피연산자값을 비트 패턴으로 인코딩하기 위한 함수와 상기 비트들을 기계 명령어에 있어서의 적절한 필드로 삽입하기 위한 또 다른 함수를 포함한다. 별도의 내부 테이블은 각각의 명령어 피연산자를 이들 함수들로 매핑시킨 다. 결과 레지스터 수가 상기 명령어의 비트 12..15로 인코딩되는 경우의 예시를 고려해 보자. 상기 TIE 컴파일러(702)는 상기 결과 레지스터의 값(수)을 갖는 명령어의 비트 12..15를 설정하는 다음의 함수를 생성할 것이다.

상기 어셈블러(710)를 수정하지 않고도 사용자-정의 명령어의 변경을 허용하기 위하여, 상기 인코드 라이브러리(744)는 동적 연결 라이브러리(DLL)로서 구현된다. DLL은 프로그램으로 하여금 그 기능성을 동적으로 확장하게 하는 표준 방식이다. 핸들링 DLL의 세부 파일은 상이한 호스트 운영체제를 가로질러 변화하지만, 기본적인 개념은 동일하다. 상기 DLL은 프로그램의 코드의 확장으로서 실행중인 프로그램내로 동적으로 로딩된다. 런-타임 링커는 상기 DLL과 주 프로그램 사이 및 상기 DLL과 이미 로딩된 다른 DLL 사이에서 기호 참조를 결정한다. 인코드 라이브러리 또는 DLL(744)의 경우, 상기 코드의 스몰 부분은 상기 어셈블러(710)내로 정적으로 링크된다. 이 코드는 상기 DLL을 로딩하는 역할을 감당하는데, 사전-구축 명령어 세트(746)(이는 별도의 DLL로부터 로딩되어져 있을 수 있음)를 위하여 현존하는 인코드 정보를 갖는 상기 DLL에서 상기 정보를 조합하고, 상술된 인터페이스 함수를 통해 접근가능한 정보를 작성한다.

사용자가 신규 인핸스먼트(enhancements; 736)를 만들면, 상기 TIE 컴파일러(702)를 상기 인핸스먼트(736)의 기술상에 호출한다. 상기 TIE 컴파일러(702)는 내부 테이블을 정의하는 C 코드 및 상기 인코드 DLL(744)을 구현하는 함수를 생성한다. 그 후, TIE 컴파일러(702)는 사용자-정의 명령어(750)를 위한 인코드 DLL(144)을 만들기 위하여, 호스트 시스템의 원시 컴파일러(746)(이것은 구성되고 있는 프로세서 보다는 호스트상에서 실행하도록 코드를 컴파일링한다)를 호출한다. 사용자는 상기 사용자-정의 인핸스먼트(736)를 포함하고 있는 디렉토리를 지정하고 있는 플래그 또는 환경 변수를 갖는 사용자의 응용 프로그램상에 사전-구축 어셈블러(710)를 호출한다. 상기 사전-구축 어셈블러(710)는 상기 디렉토리내의 DLL(744)을 동적으로 개방한다. 각각의 어셈블리 명령어에 있어서, 상기 사전-구축 어셈블러(710)는 연산코드 의사기호를 조사하기 위하여 상기 인코드 DLL(744)을 사용하여, 기계 명령어에서의 연산코드 필드에 대한 비트 패턴을 찾아서, 상기 각각의 명령어 피연산자를 인코딩한다.

예를 들면, 상기 어셈블러(710)가 TIE 명령어 "foo a2, a2, a3"를 보면, 상기 어셈블러(710)는 "foo" 연산코드를 비트 위치 16 내지 23에서 넘버 6으로 번역하는 테이블로부터 본다. 테이블로부터, 각각의 레지스터에 대한 인코딩 함수를 찾는다. 상기 함수는 a2를 넘버 2로, 다른 a2를 넘버 2로, 그리고 a3를 넘버 3으로 인코딩한다. 테이블로부터, 적절한 세트 함수를 찾는다. Set_r_field는 상기 결과값 2를 상기 명령어의 비트 위치 12..15내로 풋(put)한다. 유사한 세트 함수들은 상기 다른 2 및 상기 3을 적절하게 위치시킨다.

시뮬레이터(712)

상기 시뮬레이터(712)는 몇가지 방식으로 사용자-정의 인핸스먼트(736)와 상 호 작용한다. 기계 명령어(740)가 주어지면, 상기 시뮬레이터(712)는 상기 명령어를 디코딩해야 한다. 즉, 콤포넌트 연산코드 및 피연산자내로 상기 명령어를 분해한다. 사용자-정의 인핸스먼트(736)의 디코딩은 디코드 DLL(748)의 함수를 통해 행해진다(상기 인코드 DLL(744) 및 상기 디코드 DLL(748)은 실제적으로 단일 DLL인 것이 가능하다). 예를 들면, 사용자가 3개의 연산코드(상기 명령어의 비트 16 내지 23에서는 각각 인코딩 0x6, 0x16, 0x26을 갖고, 비트 0 내지 3에서는 0을 갖는 foo1, foo2, foo3)를 정의하는 경우를 고려해 보자. 상기 TIE 컴파일러(702)는 상기 연산코드를 사용자-정의 명령어(750) 전체의 연산코드와 비교하는 다음의 디코드 함수를 생성한다.

수많은 사용자-정의 명령어로, 가능한 전체 사용자-정의 명령어(750)에 대해 연산코드를 비교하는 것은 비용이 많이 들 수 있으므로, 상기 TIE 컴파일러는 계층 적 세트의 스위치 문장들을 대신 사용할 수 있다.

명령어 연산코드를 디코딩하는 것에 덧붙여, 상기 디코드 DLL(748)은 명령어 피연산자를 디코딩하는 함수를 포함한다. 이것은 상기 인코드 DLL(744)의 피연산자를 인코딩하는 것과 동일한 방식으로 행해진다. 우선, 상기 디코드 DLL(748)은 기계 명령어로부터 상기 피연산자 필드를 추출하도록 함수들을 제공한다. 앞선 예시들을 계속해서 보면, 상기 TIE 컴파일러(702)는 명령어의 비트 12 내지 15로부터 값을 추출하도록 다음의 함수를 생성한다.

피연산자의 상기 TIE 기술은 인코딩 및 디코딩 모두의 명세를 포함하는데, 상기 인코드 DLL(744)은 피연산자 인코드 명세를 사용하는 반면, 상기 디코드 DLL(748)은 피연산자 디코드 명세를 사용한다. 예를 들면, 상기 TIE 피연산자 명세 는 다음과 같다.

operand tx10 t {t << 10} {tx10 >> 10}

이것은 다음의 피연산자 디코드 함수를 생성한다.

상기 사용자가 상기 시뮬레이터(712)를 호출하면, 사용자-정의 인핸스먼트(736)에 대한 상기 디코드 DLL(748)을 포함하고 있는 디렉토리를 상기 시뮬레이터(712)에게 알려준다. 상기 시뮬레이터(712)는 적절한 DLL을 개방한다. 상기 시뮬레이터(712)가 명령어를 디코딩할 때마다, 사전-구축 명령어 세트에 대한 디코드 함수에 의해 상기 명령어가 성공적으로 디코딩되지 않는다면, 상기 시뮬레이터(712)는 상기 DLL(748)의 디코드 함수를 호출한다.

디코딩된 명령어(750)가 주어지면, 상기 시뮬레이터(712)는 상기 명령어(750)의 의미를 해석하고 모델링해야 한다. 이것은 함수적으로 행해진다. 모든 명령어(750)는 상기 시뮬레이터(712)로 하여금 상기 명령어(750)의 의미를 모델링하게 하는 대응하는 함수를 가진다. 상기 시뮬레이터(712)는 상기 시뮬레이팅된 프로세서의 전체 상태의 트랙을 내부적으로 유지한다. 상기 시뮬레이터(712)는 상기 프로세서의 상태를 갱신하거나 조회하기 위한 고정 인터페이스를 가진다. 상술한 바와 같이, 사용자-정의 인핸스먼트(736)는 Verilog의 서브세트인 상기 TIE 하 드웨어 기술 언어로 쓰여진다. 상기 TIE 컴파일러(702)는 상기 하드웨어 기술을 상기 신규 인핸스먼트(736)를 모델링하기 위하여 상기 시뮬레이터(712)에 의해 사용된 C 함수로 변환한다. 하드웨어 기술 언어의 연산자는 대응하는 C 연산자로 직접 번역된다. 상태를 읽거나 쓰는 연산들은 상기 프로세서의 상태를 갱신하거나 조회하기 위하여 상기 시뮬레이터의 인터페이스로 번역된다.

본 실시예의 예로서, 2개의 레지스터를 더하기 위하여 명령어(750)를 만들고 있는 사용자를 고려해 보자. 이 예시는 단순함을 위해 선택된다. 하드웨어 기술 언어에 있어서, 사용자는 다음과 같이 덧셈의 의미를 기술할 수 있다.

semantic add { add } { assign arr = ars + art; }

내장 이름 arr로 명명된 출력 레지스터는 내장 이름 ars 및 art로 명명된 2개의 입력 레지스터의 합이 할당된다. 상기 TIE 컴파일러(702)는 이러한 기술을 취하여 상기 시뮬레이터(712)에 의해 사용된 의미 함수를 생성한다.

상기 하드웨어 연산자 "+"는 C 연산자 "+"로 직접 번역된다. 상기 하드웨어 레지스터 ars 및 art의 읽기는 "ar"을 호출하는 상기 시뮬레이터(712) 함수의 호출로 번역된다. 하드웨어 레지스터 arr의 쓰기는 상기 시뮬레이터(712) 함수 "set_ar"로의 호출로 번역된다. 모든 명령어는 상기 명령어의 크기 만큼 프로그램 카운터(pc)를 무조건 증가시키기 때문에, 상기 TIE 컴파일러(702)는 또한 덧셈 명 령어의 크기인 3 만큼 시뮬레이팅된 pc를 증가시키는 시뮬레이터(712) 함수로의 호출을 생성한다.

상기 TIE 컴파일러(702)가 호출되면, 모든 사용자-정의 명령어에 대하여 상술된 바와 같은 의미 함수를 만든다. 그것은 또한 전체 연산코드 이름을 연관된 의미 함수로 매핑시키는 테이블을 작성한다. 상기 테이블 및 함수들은 표준 컴파일러(746)를 사용하여 상기 시뮬레이터 DLL(749)으로 컴파일링된다. 사용자가 상기 시뮬레이터(712)를 호출하면, 사용자-정의 인핸스먼트(736)를 포함하고 있는 디렉토리를 상기 시뮬레이터(712)에 알려준다. 상기 시뮬레이터(712)는 적절한 DLL을 개방한다. 상기 시뮬레이터(712)가 호출될 때마다, 그것은 프로그램내 전체 명령어를 디코딩하고, 명령어를 상기 연관된 의미 함수로 매핑시키는 테이블을 작성한다. 상기 매핑이 이루어지는 경우, 상기 시뮬레이터(712)는 상기 DLL을 개방하고 적절한 의미 함수를 검색한다. 사용자-정의 명령어(736)의 의미들을 시뮬레이팅할 때, 상기 시뮬레이터(712)는 상기 DLL의 함수를 직접 호출한다.

응용 프로그램이 상기 시뮬레이팅된 하드웨어상에서 얼마나 오랫동안 실행될 것인지를 사용자에게 알려주기 위하여, 상기 시뮬레이터(712)는 명령어(750)의 성능 효과를 시뮬레이팅할 필요가 있다. 상기 시뮬레이터(712)는 이러한 목적을 위해 파이프라인 모델을 이용한다. 모든 명령어는 여러 사이클에 걸쳐 실행된다. 각 사이클에 있어서, 명령어는 기계의 상이한 자원들을 사용한다. 상기 시뮬레이터(712)는 전체 명령어를 병렬로 실행하기 위한 노력을 시작한다. 만일 다중 명령어들이 동일한 사이클에서 동일한 자원을 사용하려고 시도한다면, 후자의 명령어는 상기 자원을 이용할 수 있게 될 때까지 기다리면서 정지된다. 만일 후자 명령어가 나중 사이클에서 전자 명령어로 쓰여지는 어떤 상태를 읽는다면, 상기 후자 명령어는 값이 쓰여지기를 기다리면서 정지된다. 상기 시뮬레이터(712)는 각각의 명령어의 성능을 모델링하기 위하여 함수적 인터페이스를 사용한다. 함수는 모든 형태의 명령어를 위해 작성된다. 상기 함수는 상기 프로세서의 성능을 모델링하는 상기 시뮬레이터의 인터페이스로의 호출을 포함한다.

예를 들면, 간단한 3개의 레지스터 명령어 foo를 고려해 보자. 상기 TIE 컴파일러는 다음의 시뮬레이터 함수를 작성할 것이다.

pipe_use_ifetch로의 호출은 상기 시뮬레이터(712)에게 상기 명령어는 인출될 3 바이트를 요구할 것이라는 것을 알려준다. pipe_use로의 2개의 호출은 상기 시뮬레이터(712)에게 2개의 입력 레지스터가 사이클 1에서 읽혀질 것이라는 것을 알려준다. pipe_def로의 호출은 상기 시뮬레이터(712)에게 출력 레지스터가 사이클 2에서 쓰여질 것이라는 것을 알려준다. pipe_def_ifetch로의 호출은 상기 시뮬레이터(712)에게 이 명령어는 분기가 없으므로 다음 명령어가 다음 사이클에서 인출될 수 있다는 것을 알려준다.

이들 함수들로의 포인터들은 상기 의미 함수와 동일한 테이블에 위치된다. 상기 함수들 자체는 상기 의미 함수들과 동일한 DLL(749)으로 컴파일링된다. 상기 시뮬레이터(712)가 호출되면, 그것은 명령어와 성능 함수들간의 매핑을 만든다. 상기 매핑이 이루어지는 경우, 상기 시뮬레이터(712)는 상기 DLL(749)을 개방하고, 적절한 성능 함수를 검색한다. 사용자-정의 명령어(736)의 성능을 시뮬레이팅할 때, 상기 시뮬레이터(712)는 상기 DLL(749)의 함수를 직접 호출한다.

디버거(730)

상기 디버거는 2가지 방식으로 사용자-정의 인핸스먼트(750)와 상호 작용한다. 우선, 사용자는 사용자-정의 명령어(736)에 대한 어셈블리 명령어(738)를 인쇄하는 능력을 가진다. 이것을 하기 위하여, 상기 디버거(730)는 기계 명령어(740)를 어셈블리 명령어(738)로 디코딩해야 한다. 이것은 명령어를 디코딩하기 위하여 상기 시뮬레이터(712)에 의해 사용된 것과 같은 기구이며, 상기 디버거(730)는 상기 디코딩을 하기 위하여 상기 시뮬레이터(712)에 의해 사용된 동일한 DLL을 사용하는 것이 바람직하다. 상기 명령어를 디코딩하는 것에 덧붙여, 상기 디버거는 상기 디코딩된 명령어를 문자열로 변환해야 한다. 이러한 목적을 위하여, 상기 디코드 DLL(748)은 각각의 내부 연산코드 표시를 대응하는 의사기호 문자열로 매핑시키는 함수를 포함한다. 이것은 간단한 테이블로 구현될 수 있다.

상기 사용자는 사용자-정의 인핸스먼트(750)를 포함하고 있는 디렉토리를 지정하고 있는 플래그 또는 환경 변수를 갖는 사전-구축 디버거를 호출할 수 있다. 상기 사전-구축 디버거는 적절한 DLL(748)을 동적으로 개방한다.

상기 디버거(730)는 또한 사용자-정의 상태(752)와 상호 작용한다. 상기 디 버거(730)는 상기 상태(752)를 읽고 수정할 수 있어야 한다. 그렇게 하기 위하여, 상기 디버거(730)는 상기 시뮬레이터(712)와 통신한다. 그것은 상기 시뮬레이터(712)에게 상기 상태가 얼마나 크며, 그 상태 변수의 이름은 무엇인지를 묻는다. 상기 디버거(730)는 일부 사용자 상태의 값을 인쇄하도록 요청될 때마다, 상기 시뮬레이터(712)에게 동일한 방식으로 상기 값을 묻고, 미리결정된 상태에 대하여 묻는다. 유사하게, 사용자 상태를 수정하기 위하여, 상기 디버거(730)는 상기 시뮬레이터(712)에게 상기 상태를 주어진 값으로 설정하도록 알려준다.

따라서, 사용자-정의 명령어 세트에 대한 지지의 구현 및 본 발명에 따른 상태는 코어 소프트웨어 개발 툴에 대해 플러그-인 되는 사용자 기능성을 정의하는 모듈을 사용하여 달성될 수 있다. 따라서, 시스템은 특유한 세트의 사용자-정의 인핸스먼트에 대한 플러그-인 모듈들이 각각의 구성 및 조작을 위한 시스템내의 그룹으로서 유지되는 곳에서 개발될 수 있다.

또한, 상기 코어 소프트웨어 개발 툴은 특유한 코어 명령어 세트 및 프로세서 상태로 특정될 수 있고, 사용자-정의 인핸스먼트에 대한 단일 세트의 플러그-인 모듈은 시스템상에 상주하는 다중 세트의 코어 소프트웨어 개발 툴과 연계하여 평가될 수 있다.

(부록 A)

(부록 B)

(부록 C)

(부록 D)

(부록 E)

(부록 F)

(부록 G)

(부록 H)

(부록 I)

(부록 J)

(부록 K)

(부록 L)

(부록 M)

Claims (173)

1. 삭제
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 삭제
8. 삭제
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 구성가능한 프로세서를 설계하기 위한 시스템에 있어서, 상기 시스템은,

    구성 명세를 기초로 하여, 상기 프로세서의 하드웨어 구현의 기술 (description)을 생성하는 수단; 및

    상기 구성 명세를 기초로 하여, 상기 하드웨어 구현에 대한 특유의 소프트웨어 개발 툴들을 생성하는 수단을 포함하며,

    상기 구성 명세는 상기 프로세서의 확장가능한 특성의 적어도 하나의 확장 명세를 포함하고,

    상기 확장 명세는 사용자-정의 명령어의 포함 및 상기 명령어를 위한 구현을 특정화하며,

    상기 소프트웨어 개발 툴들을 생성하기 위한 상기 수단은 적어도 하나의 응용 프로그램에 특히 밀접하게 관련된 잠재적인 사용자-정의 명령어를 상기 사용자에게 제안하기 위한 수단을 포함하는 것을 특징으로 하는 시스템.
48. 구성가능한 프로세서를 설계하기 위한 시스템에 있어서, 상기 시스템은,

    구성 명세를 기초로 하여, 상기 프로세서의 하드웨어 구현의 기술 (description)을 생성하는 수단; 및

    상기 구성 명세를 기초로 하여, 상기 하드웨어 구현에 대한 특유의 소프트웨어 개발 툴들을 생성하는 수단을 포함하며,

    상기 구성 명세는 상기 프로세서의 확장가능한 특성의 적어도 하나의 확장 명세를 포함하고,

    상기 확장 명세는 사용자-정의 명령어의 포함 및 상기 명령어를 위한 구현을 특정화하며,

    상기 소프트웨어 개발 툴들은 상기 사용자-정의 명령어를 생성할 수 있는 컴파일러를 포함하는 것을 특징으로 하는 시스템.
49. 제 48항에 있어서,

    상기 컴파일러는 사용자-정의 명령어를 포함하고 있는 코드를 최적화할 수 있는 것을 특징으로 하는 시스템.
50. 구성가능한 프로세서를 설계하기 위한 시스템에 있어서, 상기 시스템은,

    구성 명세를 기초로 하여, 상기 프로세서의 하드웨어 구현의 기술 (description)을 생성하는 수단; 및

    상기 구성 명세를 기초로 하여, 상기 하드웨어 구현에 대한 특유의 소프트웨어 개발 툴들을 생성하는 수단을 포함하며,

    상기 구성 명세는 상기 프로세서의 확장가능한 특성의 적어도 하나의 확장 명세를 포함하고,

    상기 확장 명세는 사용자-정의 명령어의 포함 및 상기 명령어를 위한 구현을 특정화하며,

    상기 소프트웨어 개발 툴들은 상기 사용자-정의 명령어를 생성하는 어셈블러; 상기 사용자-정의 명령어를 사용하는 사용자 코드의 실행을 시뮬레이팅하는 시뮬레이터; 및 상기 사용자-정의 명령어의 상기 사용자 구현을 검증하는 툴들 중 적어도 하나를 포함하는 것을 특징으로 하는 시스템.
51. 제 48항에 있어서,

    상기 컴파일러는 추가 명령어를 자동으로 생성할 수 있는 것을 특징으로 하는 시스템.
52. 구성가능한 프로세서를 설계하기 위한 시스템에 있어서, 상기 시스템은,

    구성 명세를 기초로 하여, 상기 프로세서의 하드웨어 구현의 기술 (description)을 생성하는 수단; 및

    상기 구성 명세를 기초로 하여, 상기 하드웨어 구현에 대한 특유의 소프트웨어 개발 툴들을 생성하는 수단을 포함하며,

    상기 구성 명세는 상기 프로세서의 확장가능한 특성의 적어도 하나의 확장 명세를 포함하고,

    상기 확장 명세는 실질적으로 사용자에 의해 추상적 형태로 설계된 기능성을 가지는 신규 특징을 특정하고,

    상기 하드웨어 구현 기술을 생성하기 위한 상기 수단은 또한 상기 신규 특징을 상기 상세한 하드웨어 구현 기술로 재정의 및 통합하는 것을 특징으로 하는 시스템.
53. 삭제
54. 삭제
55. 삭제
56. 삭제
57. 삭제
58. 삭제
59. 삭제
60. 삭제
61. 삭제
62. 삭제
63. 삭제
64. 삭제
65. 삭제
66. 삭제
67. 삭제
68. 삭제
69. 삭제
70. 삭제
71. 삭제
72. 삭제
73. 삭제
74. 구성가능한 프로세서를 설계하기 위한 시스템에 있어서, 상기 시스템은,

    사용자-정의 프로세서 상태의 명세, 및

    적어도 하나의 사용자-정의 명령어 및 그 사이에 연관된 사용자-정의 함수(상기 사용자-정의 프로세서 상태로부터 읽기 및 상기 사용자-정의 프로세서 상태로 쓰기 중 적어도 하나를 포함함)를 포함하는 구성 명세의 사용자-정의가능한 부분을 갖는 구성 명세를 생성하기 위한 수단; 및

    구성 명세를 기초로 하여, 상기 프로세서의 하드웨어 구현의 기술을 생성하기 위한 수단을 포함하여 이루어지는 것을 특징으로 하는 시스템.
75. 제 74항에 있어서,

    상기 프로세서의 상기 하드웨어 구현의 상기 기술은, 적어도 하나의 사용자-정의 명령어의 실행 및 상기 사용자-정의 프로세서 상태의 구현에 필요한 제어 로직의 기술을 포함하는 것을 특징으로 하는 시스템.
76. 제 75항에 있어서,

    상기 프로세서의 상기 하드웨어 구현은 명령어 실행 파이프라인을 기술하고;

    상기 제어 로직은 상기 명령어 실행 파이프라인의 각 스테이지와 연관된 부분들을 포함하는 것을 특징으로 하는 시스템.
77. 제 76항에 있어서,

    상기 하드웨어 구현 기술은 명령어 실행을 중지하기 위한 회로도의 기술을 포함하고,

    상기 제어 로직은 중지된 명령어들에 의하여 상기 사용자-정의 상태의 수정을 방지하기 위한 회로도를 포함하는 것을 특징으로 하는 시스템.
78. 제 77항에 있어서,

    상기 제어 로직은 적어도 하나의 사용자-정의 명령어에 대해 기능하는 피연산자 쓰기, 명령어 이슈 및 피연산자 바이패스 중 적어도 하나를 수행하기 위한 회로도를 포함하는 것을 특징으로 하는 시스템.
79. 제 76항에 있어서,

    상기 하드웨어 구현 기술은 상기 사용자-정의 상태를 상기 명령어 실행 파이프라인의 복수의 스테이지로 구현하기 위한 레지스터를 포함하는 것을 특징으로 하는 시스템.
80. 제 76항에 있어서,

    상기 하드웨어 구현 기술은 출력 피연산자가 생성되는 곳이 아닌 상이한 파이프라인 스테이지에 쓰여진 상태 레지스터를 포함하고;

    상기 하드웨어 구현 기술은, 상기 상태로의 쓰기가 행해지기 전에 상기 사용자-정의 프로세서 상태를 참조하는 후속 명령어로 상기 쓰기가 바이패스되는 것을 특정화하는 것을 특징으로 하는 시스템.
81. 제 74항에 있어서,

    상기 구성 명세는 상기 사용자-정의 부분에 덧붙여 사전설정된 부분을 포함하고;

    상기 명세의 사전설정된 부분은 상기 사용자-정의 상태를 메모리로 저장하는 것을 용이하게 하는 명령어 및 상기 사용자-정의 상태를 메모리로부터 복원하는 것을 용이하게 하는 명령어를 포함하는 것을 특징으로 하는 시스템.
82. 제 81항에 있어서,

    상기 명령어를 이용하여 상기 사용자-정의 상태를 컨텍스트 스위치(context switch)하는 소프트웨어를 생성하기 위한 수단을 더 포함하는 것을 특징으로 하는 시스템.
83. 제 74항에 있어서,

    상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 어셈블링하기 위한 어셈블러; 상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 컴파일링하기 위한 컴파일러; 상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 시뮬레이팅하기 위한 시뮬레이터; 및 상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 디버깅하기 위한 디버거 중 적어도 하나를 생성하기 위한 수단을 더 포함하는 것을 특징으로 하는 시스템.
84. 제 74항에 있어서,

    상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 어셈블링하기 위한 어셈블러; 상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 컴파일링하기 위한 컴파일러; 상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 시뮬레이팅하기 위한 시뮬레이터; 및 상기 사용자-정의 프로세서 상태 및 상기 적어도 하나의 사용자-정의 명령어를 디버깅하기 위한 디버거를 생성하기 위한 수단을 더 포함하는 것을 특징 으로 하는 시스템.
85. 삭제
86. 삭제
87. 삭제
88. 삭제
89. 삭제
90. 삭제
91. 구성가능한 프로세서를 설계하기 위한 시스템에 있어서, 상기 시스템은,

    명령어 세트 구조 명세를 기초로 하여, 상기 명세에 대한 특유의 소프트웨어 개발 툴들을 생성하는 코어 소프트웨어 툴들; 및

    사용자-정의 명령어 명세를 기초로 하여, 상기 사용자-정의 명령어를 구현하는데 있어 상기 코어 소프트웨어 툴을 사용하여 적어도 하나의 모듈을 생성하는 사용자-정의 명령어 모듈을 포함하여 이루어지는 것을 특징으로 하는 시스템.
92. 삭제
93. 삭제
94. 삭제
95. 삭제
96. 삭제
97. 삭제
98. 삭제
99. 삭제
100. 삭제
101. 삭제
102. 삭제
103. 삭제
104. 삭제
105. 삭제
106. 삭제
107. 삭제
108. 제 91항에 있어서,

     단일 사용자-정의 명령어는 상이한 코어 명령어 세트 명세를 기초로 한 다중 코어 소프트웨어 툴들에 의하여 수정되지 않게 사용될 수 있는 것을 특징으로 하는 시스템.
109. 삭제
110. 삭제
111. 삭제
112. 삭제
113. 삭제
114. 삭제
115. 삭제
116. 삭제
117. 삭제
118. 삭제
119. 삭제
120. 삭제
121. 삭제
122. 삭제
123. 삭제
124. 삭제
125. 삭제
126. 삭제
127. 삭제
128. 삭제
129. 삭제
130. 삭제
131. 삭제
132. 삭제
133. 삭제
134. 삭제
135. 삭제
136. 삭제
137. 삭제
138. 삭제
139. 삭제
140. 삭제
141. 삭제
142. 삭제
143. 삭제
144. 삭제
145. 삭제
146. 삭제
147. 삭제
148. 삭제
149. 삭제
150. 삭제
151. 삭제
152. 삭제
153. 삭제
154. 삭제
155. 삭제
156. 삭제
157. 삭제
158. 삭제
159. 삭제
160. 삭제
161. 삭제
162. 삭제
163. 삭제
164. 삭제
165. 삭제
166. 삭제
167. 삭제
168. 삭제
169. 삭제
170. 삭제
171. 삭제
172. 삭제
173. 삭제

Images