KR100589744B1

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

Info

Publication number: KR100589744B1
Application number: KR1020027010522A
Authority: KR
Inventors: 왕알버트알.; 루델리차드; 굳윈데이비드더블유; 킬리안얼에이.; 바타차리야누푸르; 메디나마린스피.; 리히텐스타인월터디.; 코나스파블로스; 스리니바산랭가라잔; 송어크리스토퍼엠.; 파라메스워아킬레쉬; 메이단드로르이.; 곤잘레스리카도이.
Original assignee: 텐실리카 인코포레이티드
Priority date: 2000-02-17
Filing date: 2001-02-15
Publication date: 2006-06-15
Also published as: US20090177876A1; US7036106B1; US8161432B2; GB0217221D0; US20060101369A1; JP4619606B2; TW571206B; KR20030016226A; AU2001238403A1; WO2001061576A3; JP2004502990A; GB2376546B; US9582278B2; CN1288585C; CN1436335A; US20090172630A1; WO2001061576A2; US7437700B2; GB2376546A

Abstract

본 발명에 따른 프로세서 하드웨어를 생성하기 위한 시스템은 프로세서 명령어 세트에 대한 현저한 확장을 위한 언어를 지원하는데, 여기서 설계자는 신규 명령어의 시맨틱만을 특정화하고, 상기 시스템은 다른 로직을 생성한다. 확장 언어는 레지스터 파일을 포함하는 프로세서 상태 및 그 상태에서 연산하는 명령어들의 추가를 제공한다. 상기 언어는 또한 추가된 상태를 표현하기 위하여 컴파일러에 추가될 신규 데이터 형식을 제공한다. 이는 참조 시맨틱 및 명령어 구현의 별도의 명세를 허용하고, 이것을 설계 검증을 자동화하기 위하여 사용한다. 또한, 상기 시스템은 언어 명세로부터 포맷된 명령어 세트 문서화를 생성한다.

Description

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

본 발명은 컴퓨터 프로세서 뿐만 아니라 시스템 및 상기 시스템 개발을 위한 기술에 관한 것으로서, 특히 사용자의 선택에 따라 구성가능한 특징들을 갖는 프로세서와 이와 관련된 개발 시스템 및 기술에 관한 것이다.

종래의 프로세서는 일반적으로 수정 또는 확장이 상당히 어려운 리지드 객체(rigid object)였다. 종래의 시스템에서는 레지스터-대-레지스터 계산 명령어 및 단순한 상태(레지스터 파일은 아님)를 추가할 수 있는 능력을 포함하는 프로세서와 그 지원 소프트웨어 툴에 대한 제약된 확장성이 제공되었다. 이러한 제약된 확장성은 본 기술분야에서 상당한 발전이었으며, 이러한 개선점들을 이용한 많은 어플리케이션은 4배 이상의 효율 개선 또는 속도 향상을 보여준다.

하지만, 이들 종래 시스템의 확장성에 대한 제약들은 여타의 어플리케이션들이 적절하게 어드레싱될 수 없다는 것을 의미하였다. 특히, 고정된 32비트 폭 레지스터를 구비한 현존 코어 레지스터 파일(core register file)을 이용해야 하는 것은, 일반적으로 데이터 피연산자의 조합된 폭이 32비트를 초과하는 복제된 기능 유 닛 또는 추가 정밀도를 요구하는 어플리케이션에 있어서 상기 개선점들을 이용하는 것을 막는다. 또한, 코어 레지스터 파일은 종종 소정의 명령어를 구현하기 위한 읽기 또는 쓰기 포트가 충분하지 않다. 이러한 이유들로 인하여, 본 기술분야에서는 읽기 및 쓰기 포트의 폭과 수에 있어서 구성가능한 신규 레지스터 파일의 추가를 지원하는 것이 요구된다.

레지스터 파일을 추가하면, 상기 파일 및 메모리간에 데이터를 전송할 필요가 발생한다. 코어 명령어 세트는 상기 코어 레지스터 파일용 로드(load) 및 저장(store) 명령어를 포함하지만, 추가 레지스터 파일들은 추가 로드 및 저장 명령어를 필요로 한다. 이는 확장가능한 레지스터 파일을 대한 이론적 해석들 가운데 하나가 그들로 하여금 소요 데이터 타입 및 대역폭에 대한 크기가 정해지도록 하기 때문이다. 특히, 레지스터 파일의 폭은 나머지 명령어 세트에 의하여 지원되는 것보다 더 넓을 수 있다. 따라서, 상기 코어에 의하여 제공된 레지스터에 데이터를 전송하여 상기 데이터를 로드 및 저장하는 것은 합리적이지 않다; 즉, 값들을 신규 레지스터 파일로부터 직접 로드 및 저장하는 것이 가능해야 한다.

또한, 종래의 시스템들은 프로세서 상태의 추가를 지원하더라도, 상기 상태의 양은 통상적으로 적다. 그 결과, 본 기술 분야에서는 프로세서 아키텍처에 용이하게 추가될 많은 수의 상태 비트가 요구된다. 이러한 상태는 종종 운영체제에 의하여 문맥 스위칭(context switch)될 필요가 있다. 일단 상태의 양이 많아지면, 문맥 스위치 시간을 최소화하는 신규 방법들이 바람직하다. 상기 방법들은 종래의 프로세서(예를 들면, MIPS R2000 코프로세서 인에이블 비트)에 구현되어 왔다. 하지 만, 당업계에서 신규 상태에 대하여 알고 그것을 적절한 방식으로 사용해야 하는 여타의 소프트웨어 및 실시간 운영체제(RTOSes)를 지원하기 위해서는, 입력 명세(specification)로부터 자동으로 코드 시퀀스 및 로직을 추가로 생성하여 이것을 확장시키는 것이 요구된다.

또한, 종래의 프로세서는 코어 프로세서 구현과 명령어 확장(extension)간의 로직의 공유를 허용하지 않는다. 로드 및 저장 명령어 확장에 의하면, 데이터 캐시가 상기 코어와 확장간에 공유되어야 하는 것이 중요하다. 이는 새롭게 구성된 명령어에 의한 저장된 값들이 상기 코어에 의한 로드에 의해 그리고 그 역에 의하여 인식되어, 캐시 코히어런시(cache coherency)(별도의 캐시들은 그들을 일정하게 유지하도록 특별한 메커니즘을 요구할 것임, 가능하지만 바람직하지는 않은 솔루션임)를 보장하도록 하는 것이다. 또한, 데이터 캐시는 코어 프로세서내의 큰 회로 중의 하나이므로, 그것을 공유함으로써 코어 프로세서의 크기의 감소가 촉진된다.

또한, 레지스터 파일을 추가하는 것은 상기 레지스터들에 대한 고레벨 언어 변수의 할당을 지원하는 것을 바람직하게 만든다. 종래의 프로세서들은 기존의 컴파일러들이 이미 사용자 변수의 할당을 지원하는 코어 레지스터 파일을 사용한다. 따라서, 컴파일러 할당이 예상되고, 사용자-정의 레지스터 파일을 지원해야 한다. 레지스터에 변수를 할당하기 위하여, 사용자-정의 레지스터 파일을 지원하는 컴파일러는 기존의 컴파일러 상관관계(functionality)를 구현하도록 상기 레지스터들을 스필(spill), 재저장 및 이동시키는 법을 알아야 한다.

종래의 해당 프로세서 시스템의 더욱 일반적인 제약은 상기 시스템을 지원하 는 컴파일러의 레벨이다. 종종 명령어들이 프로세서에 추가되어, 어플리케이션에 적절한 신규 데이터 타입을 지원할 수 있다(예를 들어, 많은 DSP 어플리케이션은, 보통 프로세서에 의해 지원되는 매우 전통적인 2의 보수 산술 대신에 포화(saturating) 산술을 구현하는 프로세서를 요구한다). 종래의 시스템들은 신규 데이터 타입을 지원하는 명령어들이 추가되도록 하지만, 확장부를 사용하는 고레벨 언어 코드를 기록하는 경우에 상기 신규 명령어들을 현존하는 언어 데이터 타입으로 맵핑시키는 것이 필요하다. 어떤 경우에는, 적절한 내장(built-in) 데이터 타입이 존재하지 않을 수도 있다.

예를 들어, 포화 산술 예시를 살펴보자. 상술된 바와 같이, 많은 DSP 알고리즘들은, 전통적인 2의 보수 시스템에서와 같이, 랩핑(wrapping) 대신에 사용되는 비트 수의 언더플로우에 대한 최소값 또는 오버플로우에 대한 최대값에서 포화하는 산술을 이용한다. 하지만, 이들 시맨틱(semantics)(C 언어는

int a;

int b;

int c = a + b; 이 랩핑 시맨틱을 가지는 것을 요구함)을 갖는 C 데이터 타입은 없다.

또한, 신규 내재 함수(intrinsic function)를 갖는 내장 타입을 사용하는 대신에,

int a;

int b;

int c = SATADD(a, b);

위와 같이 기록할 수 있지만, 이는 어색하고 알고리즘을 불명료하게 한다(기록자는 SATADD 함수를 간단하게 + 로 생각함).

한편, 신규 데이터 타입을 추가하는 것은 + 연산자가 상기 타입과 다르게 기능하도록 하게 한다 - C는 이미 그것을 정수 덧셈 및 부동소수점 덧셈연산을 위한 상이한 연산에 적용하여, 확장이 자연스럽다. 따라서, 신규 데이터 타입을 이용하면, 포화 덧셈(saturating addition)은 다음과 같이 코딩될 수 있다.

dsp16 a;

dsp16 b;

dsp16 c = a + b;

여기서, dsp16은 포화 데이터 타입을 정의한다. 따라서, 마지막 행은 그 피연산자 모두가 포화 데이터 타입이기 때문에 포화 덧셈임을 암시한다.

대부분의 컴파일러는 파이프라인 스톨(pipeline stall)이 최소화되도록 명령어들을 스케줄링한다. 하지만, 종래의 시스템에 의하면, 명령어 명세가 데이터 구조의 컴파일러 스케줄링을 확장하는데 사용될 수 있는 방법은 없다. 예를 들면, 로드 명령어들은 2사이클 대기시간(latency)으로 파이프라인된다. 따라서, 만일 로드 후의 차기 명령어에 대한 참조(reference)인 로드의 결과를 참조한다면, 상기 로드가 종료되지 않았기 때문에 1사이클 스톨이 있을 것이다. 따라서, 다음과 같은 시퀀스는 2 스톨 사이클을 가질 것이다.

load r1, addr1

store r1, addr2

load r2, addr3

store r2, addr4

만일 컴파일러가 이것을 다음과 같이 재배치한다면,

load r1, addr1

load r2, addr3

store r1, addr2

store r2, addr4

상기 시퀀스는 스톨 사이클이 없이 실행된다. 이것은 명령어 스케줄링이라 불리는 보통의 최적화 기술이다. 종래의 명령어 스케줄링은, 명령어들이 그 입력 및 출력값들을 사용하지만 새롭게 추가된 명령어에 대한 상기 정보는 사용하지 않는 파이프(pipe) 스테이지를 제공하는 테이블을 요구한다.

종래 기술의 또 다른 제약은 추가된 명령어의 계산 부분이 1 사이클의 파이프라인으로 구현되어야 한다는 점이다. 큰 피연산자의 곱셈과 같은 소정의 계산들은 통상적인 RISC 파이프라인 스테이지보다 더 긴 로직 딜레이(logic delay)를 가진다. 종래의 기술을 이용하는 이러한 연산이 포함된다면, 계산을 완료하기 위한 더 많은 시간을 제공하도록 프로세서 클럭 속도가 감소되어야 하는 것을 요구할 것이다. 따라서, 상기 계산이 수 개의 파이프라인 스테이지에 걸쳐 분포되는 명령어들을 지원하는 것이 바람직할 것이다. 상기 계산이 다수의 사이클에 걸쳐 수행되도록 하는 것 이외에도, 피연산자들로 하여금 상이한 파이프라인 스테이지에서 사용(consume)되고 생성되도록 하는 것이 유용할 수 있다.

예를 들면, 곱셈/누적 연산은 통상적으로 2 사이클을 필요로 한다. 제1사이클에서, 곱셈기는 캐리-세이브(carry-save) 형태로 곱을 산출하고; 제2사이클에서, 캐리-세이브 곱 및 누산기는 단일 레벨의 캐리-세이브-덧셈을 이용하여 3개의 값에서 2개의 값으로 감소된 후, 캐리-전파-가산기(carry-propagate-adder)에서 더해진다. 그리하여, 가장 단순한 선언(declaration)은 곱셈/누적 명령어들이 어떤 소스 피연산자로부터 목적(destination) 피연산자까지 2 사이클이 걸린다고 할 것이다. 하지만, 동일한 누산기 레지스터에서 백-투-백(back-to-back) 곱셈/누산을 행하는 것은 가능하지 않은데, 이는 2 사이클 대기시간 때문에 1 사이클 스톨이 있을 것이기 때문이다. 하지만, 실제로 상기 로직은 누산기로 들어오는 것부터 누산기 밖으로 나가는 것까지 단지 1 사이클만을 필요로 하기 때문에, 더 나은 접근법이란 바로 다음과 같은 더욱 파워풀한 기술(description)을 제공하는 것이다.

D ← A + B * C

이는 B 및 C는 스테이지 1에서, A는 스테이지 2에서 가져와, 스테이지 3에서 D를 산출하는 것을 서술하고 있다. 따라서, B 또는 C로부터 D까지의 대기시간은 3 - 1 = 2이고, A로부터 D까지의 대기시간은 3 - 2 = 1 이다.

다수 사이클 명령어의 추가에 의하면, 추가된 명령어용 타겟 파이프라인에 적합한 인터록(interlock) 로직을 생성하는 것도 필요하게 된다. 이는 사이클 이슈(issue)마다 하나의 명령어를 가지므로, 하나의 명령어가 차기 사이클에서 인터록을 발생시킬 결과값을 산출할 수 있는 대기시간이 없는데, 이는 차기 명령어가 항상 1 사이클만큼 지연되기 때문이다. 일반적으로, 매 K 사이클에서만 명령어가 이슈될 수만 있다면, 상기 명령어들의 대기시간은 L 사이클(L≥K)이고, 상기 명령어는 그 목적 피연산자에 대하여 인터록을 발생시킬 수 없다(명령어들은 그 소스 피연산자가 로드와 같은 2 사이클 명령어에 의하여 생성되었다면, 그 소스 피연산자에 대해서는 여전히 인터록시킬 수 있음). 새롭게 구성된 2 사이클의 명령어를 가지는 것이 가능하다면, 상기 새롭게 구성된 명령어의 결과에 대하여 인터록시키는 다음 명령어를 가지는 것이 필요하다.

대부분의 명령어 세트 아키텍처들은 상이한 프로세서 아키텍처에 대한 다수의 구현을 가진다. 종래의 시스템들은 명령어에 대한 구현 로직 및 명령어 시맨틱의 명세를 조합하여 이들을 분리시키지 않았는데, 이는 다수의 구현들로 사용될 한 세트의 참조 시맨틱(reference semantics)을 허용할 수 있다. 참조 시맨틱은 명령어 세트 문서화(documentation)의 한 구성요소이다. 영어와 더욱 정확한 표기법 모두에 있어 명령어 시맨틱을 기술하는 것이 전통적이다. 영어는 종종 모호하거나 오류-경향(error-prone)이 있지만, 읽기가 쉽다. 따라서, 도입(introduction), 목적 및 명령어의 루즈 정의(loose definition)를 제공한다. 더욱 공식적인 정의는 명령어가 무엇을 하는지 분명하게 이해하는데 유용하다. 참조 시맨틱의 목적 가운데 하나는 이러한 분명한 정의(precise definition)로서 역할을 하는 것이다. 다른 구성요소들은 명령어 워드, 어셈블러 구문 및 텍스트 기술을 포함한다. 종래의 시스템들은 명령어 워드 및 어셈블러 구문을 생성하기 위하여 확장 언어에 충분한 정보를 가진다. 참조 시맨틱을 추가하면, 텍스트 기술이 빠졌을 때만, 전통적인 ISA 기술 북(book)을 생성하도록 포맷된 문서화(formatted documentation)로 변환될 수 있는 명령어 기술의 명세를 포함하는 것이 필요하다.

상기 특징들을 포함하는 프로세서 개발 기술들은 그 유연성 및 파워의 증가로 인하여 종래 기술의 설계 검증 방법들을 더이상 유효하지 않게 할 것이다. 따라서, 상기 특징들과 연계하여, 생성된 프로세서의 다음과 같은 여러 형태(aspects)의 정확성(correctness)을 검증하는 것이 필요하다:

-- 입력 참조 명령어 시맨틱의 정확성;

-- 입력 구현 명령어 시맨틱의 정확성;

-- 명령어 시맨틱의 컴파일러에 의한 응용 프로그래밍 언어로의 번역;

-- 명령어 시맨틱 컴파일러에 의한 하드웨어 기술 언어(HDL)로의 번역;

-- 명령어 시맨틱 컴파일러에 의한 명령어 세트 시뮬레이터 프로그래밍 언어로의 번역;

-- 레지스터 파일, 인터록, 바이패스, 코어 인터페이스 및 예외(exceptions)를 위하여 명령어 시맨틱 컴파일러에 의하여 생성된 HDL;

-- 명령어 시맨틱 컴파일러에 의하여 생성된 하드웨어 추상화 레이어(HAL) 코드와 같은, 프로세스시에 생성된 임의의 시스템 함수 추상화 레이어(HAL에 대한 더욱 상세한 것은 상술된 Songer 등의 특허출원 참조); 및

-- 프로그래밍 언어 컴파일러에서의 내재함수(intrinsic) 및 데이터 타입 지원.

상기 참조 시맨틱은 상기 몇 가지 경우에도 사용된다.

결국, 모든 신규 하드웨어 상관관계는 명령어 세트에 의하여 지원되어야 한다.

종래 기술의 상기 문제점들의 관점에서 보면, 본 발명의 목적은 읽기 및 쓰기 포트의 폭과 수에 있어서 구성가능한 신규 레지스터 파일의 추가를 포함하는 매우 다양한 프로세서 특징들의 확장성을 허용하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은 상기 신규 레지스터 파일 및 메모리간에 데이터를 전송하기 위한 명령어의 추가를 지원하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은 코어 프로세서 구현 및 명령어 확장간의 로직의 공유, 특히 코어 및 확장 명령어간의 데이터 캐시의 공유를 지원하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 레지스터를 스필, 재저장 및 이동시키는 능력을 포함하는 확장된 레지스터 파일에 대한 고레벨 언어 변수의 컴파일러 할당을 지원하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 계산이 수 개의 파이프라인 스테이지에 걸쳐 분포되는 명령어들을 지원하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 상이한 파이프라인 스테이지에서 피연산자가 사용되고 생성되도록 하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 추가된 다중 사이클 명령어를 위하여 타겟 파이프라인에 적합한 인터록 로직의 생성을 지원하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 파이프라인 스톨을 최소화하기 위하여, 데이터 구조의 컴파일러 스케줄링을 확장하도록 명령어 명세를 사용하는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 한 세트의 참조 시맨틱이 다수의 명령어 구현으로 사용되도록 하기 위하여 명령어에 대한 구현 로직 및 명령어 시맨틱의 명세를 지원하는 것이다.

본 발명의 또 다른 목적은, 포맷된 문서화로의 변환을 위한 명령어 기술의 명세를 사용할 수 있는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 프로세서 설계의 확장가능한 광범위한 특징들을 검증할 수 있는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 입력 명세로부터 자동으로 문맥 스위칭 시간을 최소로 하기 위한 로직 및 코드 시퀀스를 생성할 수 있는 프로세서 개발 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은, 상술된 바와 같이 확장가능한 광범위한 함수들을 지원할 수 있는 명령어 세트 시뮬레이터를 포함하는 프로세서 개발 시스템을 제공하는 것이다.

도 1 및 도 2는 본 발명의 바람직한 실시예에 따른 4-스테이지 파이프라인된 확장가능한 레지스터에 관련된 제어 로직을 도시한 도면;

도 3은 도 1 및 도 2의 2-스테이지 파이프라인 버전의 레지스터를 도시한 도면;

도 4는 제1실시예에 따른 코어 가산기에 대한 인터페이스 신호를 도시한 도면;

도 5는 종래의 로드 정렬기(load aligner)이고, 도 6은 바람직한 실시예에 따른 로드 정렬기를 도시한 도면;

도 7은 바람직한 실시예에 따른 인터페이스 신호를 출력하는 시맨틱 블록을 도시한 도면;

도 8a 내지 도 8c는 바람직한 실시예에 따른 파이프라인 레지스터 최적화를 도시한 도면;

도 9는 바람직한 실시예에서의 예외 프로세싱을 도시한 도면;

도 10은 바람직한 실시예에서의 추가 예외 프로세싱을 도시한 도면;

도 11은 바람직한 실시예에서의 참조 시맨틱 정보의 프로세싱을 도시한 도면;

도 12는 바람직한 실시예에 따른 자동-생성 명령어 문서화를 도시한 도면;

도 13은 바람직한 실시예에 따른 TIE 검증 프로세스를 도시한 도면; 및

도 14는 바람직한 실시예에서의 코시뮬레이션 프로세스를 도시한 도면이다.

본 발명은 TIE(Tensilica Instruction Set Extension) 언어와 그 컴파일러 및 여타의 툴들이 기술되어 있는 Killian 등 및 Wilson 등의 출원에 개시된 기술에 관련된 것이다. 본 발명의 바람직한 실시예는 새로운 구성(construct)을 지원하는 컴파일러 등과 같은 확대(augmented) 소프트웨어 툴 및 새로운 구성을 갖는 TIE 언어를 확장시킨다.

확장된 레지스터 파일

바람직한 실시예에 의하여 제공된 신규 상관관계의 한 형식이 레지스터 파일을 위하여 지원된다. 현존하는 프로세서 기술분야에 있어서, 레지스터 파일은 각각 한 세트의 B 비트의 N 기억장소 위치(storage location)들이다. 명령어의 필드는 상기 명령어의 결과값을 위한 소스 피연산자 값 또는 목적 피연산자 값에 따라 상기 세트의 멤버들을 선택한다. 통상적으로, 레지스터 파일은 병렬로 N 멤버의 R의 읽기, 병렬로 N 멤버의 W의 쓰기를 지원하도록 설계되므로, 명령어들은 1이상의 소스 피연산자와 1이상의 목적 피연산자를 가질 수 있고, 여전히 레지스터 파일 액세스를 위하여 단지 하나의 사이클만 요구한다.

신규 레지스터 파일을 선언하기 위한 TIE 언어 구성은

regfile <rfname> <eltwidth> <entries> <shortname>

이고, 여기서 <rfname>은 후속하는 TIE 구성에서 레지스터 파일에 대하여 참조하도록 사용되는 핸들(handle)이고, <eltwidth>는 레지스터 파일 요소("레지스터")의 비트 폭이며, <entries>는 레지스터 파일에서의 요소들의 개수이고, <shortname>은 어셈블리 언어용 레지스터 네임을 작성하는데 사용되는 짧은 전위(short prefix)(종종 하나의 문자)이다. 레지스터 네임들은 첨부된 레지스터 수를 갖는 <shortname>이다.

regfile 구성은 읽기 또는 쓰기 포트의 수를 선언하지 않으며, 이러한 물리적인 구현 상세는 아래에 자세히 후술되는 바와 같이 TIE 컴파일러에 남겨짐으로써, 가능한 한 구현-의존형으로 TIE를 지속시키고, 고레벨 명세 기술로서 TIE를 유지시킨다.

regfile 선언의 결과로, 생성된 프로세서는 상기 상태의 다수 <eltwidth> 값들을 읽고 쓰기 위하여 로직을 따라 프로그래머-가시 상태(programmer-visible state)의 추가 <eltwidth>*<entries> 비트를 포함할 것이다. 상기 로직 생성 알고리즘은 기타 관련 TIE 언어 구성을 설명한 후에 상세히 후술할 것이다.

TIE 구성

operand <oname> <fieldname> { <rfname>[<fieldname>] }

은 명령어 워드의 필드 <fieldname>로 나타낸 레지스터 파일 <rfname> 요소들을 읽거나 쓰기 위한 핸들로서 <oname>을 선언한다. 이러한 구성은, <rfname>이 코어 레지스터 파일("AR"로 명명됨)에 덧붙여 regfile로 선언된 레지스터 파일을 나타낼 수 있다는 것을 제외하고는, Killian 등의 출원에 개시된 것과 동일하다. Killian 등의 출원에 개시된 바와 같이, <oname> 핸들은 명령어에 있어서 레지스터 파일 in, out 및 inout 피연산자를 기술하도록 iclass 선언들에 사용될 수 있다.

예로서, TIE 명세

opcode GFADD8 op2=4'bOOOO CUSTO

opcode GFMULX8 op2=4'b0001 CUSTO

opcode GFRWMOD8 op2=4'b0010 CUSTO

state gfmod 8

user_register 0 { gfmod }

regfile gf 8 16 g

operand gr r { gf [r] }

operand gs s { gf [s] }

operand gt t { gf [t] }

iclass gfrrr { GFADD8 } {out gr, in gs, in gt} {} {}

iclass gfrr { GFMULX8 } {out gr, in gs} {in gfmod} {}

iclass gfr { GFRWMOD8 } {inout gt} {inout gfmod} {}

semantic gfl { GFADD8 } {

assign gr = gs ＾ gt ;}

semantic gf2 { GFMULX8 } {

assign gr = gs [7] ? ({gs [6 : 0], l'bO} ＾ gfmod) :

{gs [6 : 0], 1'bO} ;

}

semantic gf3 { GFRWMOD8 } {

wire [7 : 0] tl = gt ;

wire [7 : 0] t2 = gfmod ;

assign gfmod = tl ;

assign gt = t2 ;

}

는 8비트 데이터 값에 대한 단순화된 Galois-필드 산술 유닛을 구현한다(본 예시를 구현하기 위한 TIE 파일들의 전체 세트는 Appendix A에서 찾아볼 수 있음). 16-엔트리, 8비트 레지스터 파일이 작성되고(각 레지스터는 GF(2)에 걸친 다항식과 gfmod에 저장된 다항식을 나눈 나머지를 보유함), 2개의 명령어는 상기 레지스터에서 연산하는 것이 정의된다. GFADD8은 명령어 워드의 s 필드에 의하여 특정화된 레지스터("gs 레지스터")의 다항식을 명령어 워드의 t 필드에 의하여 특정화된 레지스터("gt 레지스터")의 다항식에 더하고, 그 결과를 명령어 워드의 r 필드에 의하여 특정화된 레지스터("gr 레지스터")에 기록한다. GFMULX8은 gs 레지스터의 다항식과 x와 gfmod를 나눈 나머지를 곱하여, 그 결과를 상기 gr 레지스터에 기록한다. GFRWMOD8은 상기 gfmod 다항식 레지스터를 읽고 쓰기 위한 것이다.

이러한 간단한 TIE 코드로부터 생성된 로직은, 상이한 파이프라인 스테이지에 대한 다양한 연산의 지정(assignment)을 취급(handle)하기 위하여 제어 로직을 요구하기 때문에 더욱 복잡하다. TIE는 명령어 세트의 사용자에게 친근한 레벨로 명령어 세트를 기술하는 고레벨 명세이고, 명령어 세트의 구현기(즉, 프로세서 디자이너)에 의하여 쓰여진 것과 같은 저레벨이 아니다.

도 1에는 TIE 코드에 의하여 생성된 레지스터 파이프라인 제어 로직의 예시가 도시되어 있다. 이는 4개의 파이프라인 레지스터 및 그 대응하는 입력 멀티플렉 서에 의하여 형성된 읽기 데이터 파이프(도면의 좌측에 있음)를 포함하는 4 스테이지 파이프라인 레지스터를 보여준다. 상부로부터 시작하여, 읽기 포트의 각 쌍의 파이프라인 레지스터들은 C0(R), C1(E), C2(M), C3(W), C4 파이프라인 스테이지의 바운더리들을 나타낸다. 각 파이프라인 레지스터의 출력, 즉 rd0_dataC1 ~ rd0_dataC4는 읽기 및 쓰기 포트들(간단하게 하기 위하여 도시되지 않음) 사이에 개재된 레지스터의 데이터패스(datapath)에 제공된다. 이들 출력들은, 읽기 포트의 더 나중의 모든 파이프라인 레지스터의 출력과 마찬가지로, 차기 스테이지 멀티플렉서에 입력으로 제공된다. 읽기 포트 멀티플렉서를 위한 제어 신호 생성은 아래에 후술된다.

본 도면은 또한 4개의 파이프라인 레지스터 및 그 안에 3개의 최근의 파이프라인 스테이지를 위한 대응 입력 멀티플렉서들에 의하여 형성된 쓰기 포트(도면의 우측에 있음)를 보여준다. 레지스터 데이터패스로부터의 4개의 신호(w0_dataC1 ~ w0_dataC4)는 직접 또는 이전의 쓰기 포트 파이프라인 레지스터의 출력(wr0_resultC2 ~ wr0_resultC4)과의 멀티플렉싱을 거쳐, 쓰기 포트 레지스터 입력중의 대응하는 것들의 입력으로 제공된다. 이들 출력 신호는 레지스터 파일 xregfle RF의 출력과 함께 멀티플렉싱되고, 읽기 포트 파이프라인의 C0 스테이지 멀티플렉서로 공급된다.

읽기 및 쓰기 포트의 멀티플렉서를 위한 제어 신호들은, 아래의 레지스터 파일의 컴파일러 생성에 대한 논의와 연계하여 해석될 경우에 당업자라면 용이하게 이해할 수 있듯이, 도 2의 회로도를 이용하여 스톨 신호 stall_R 및 xregfile RF에 대한 쓰기 인에이블(write enable)에 따라 생성된다.

이해를 돕기 위하여, 도 3에는 도 1 및 도 2의 회로의 2-스테이지 버전을 조합한 2-스테이지 레지스터 파일이 도시되어 있다.

레지스터 파일 생성하기

regfile 문장에 의하여 선언된 각각의 레지스터 파일에 있어서, 컴파일러는 다음을 생성하여야 한다.

-- 레지스터 파일 기억소자;

-- 읽기 포트;

-- 쓰기 포트;

-- 소스 피연산자 인터록 로직;

-- 소스 피연산자 바이패스 로직; 및

-- 목적 피연산자 쓰기 로직.

읽기 및 쓰기 포트

레지스터 파일을 생성하는 것의 제1단계는 읽기 및 쓰기 포트의 수를 결정하고, 상기 포트에 파이프라인 스테이지를 지정하며, 상기 포트에 피연산자를 지정하는 것이다. 많은 알고리즘들이 이들 연산을 행하는데 사용될 수 있고, 각각 상이한 속도 및 면적 트레이드오프를 야기한다. 다음의 알고리즘은 바람직한 실시예에 사용된다.

레지스터 파일로부터 소스 피연산자를 선택하는데 사용되는 각각의 필드에 있어서, 읽기 포트가 생성된다. 어떤 경우에는, 이것이 필요한 것보다 더 많은 읽 기 포트를 생성하지만, 일반적으로 레지스터 읽기를 명령어 디코드와 병렬로 시작하도록 하기 때문에 더 빠른 레지스터 읽기를 만들어낸다.

iclass gfr { GFRWMOD8 } {inout gt} {inout gfmod} {} 이

iclass gfr { GFRWMOD8 } {inout gr} {inout gfmod} {}

로 변경된 이전의 Galois-필드 산술 예시를 살펴보자.

비록 어떤 명령어도 동시에 2개를 초과하는 GF 레지스터 파일 읽기를 사용하지 않음에도 불구하고, 상기 알고리즘은 3개의 레지스터 읽기 포트(명령어 워드의 r, s, t 필드 각각을 위한 것)를 생성할 것이다. 하지만, 단지 2개의 읽기 포트만이 생성된다면, r 및 s 필드 또는 r 및 t 필드 사이에서 선택하도록 읽기 포트들 중의 하나의 앞에 2:1 mux를 구비하는 것이 필요하다. 상기 mux는 GFRWMOD 및 GFADD 명령어들을 구별하는 디코드 로직에 의하여 제어되어야 한다. 복잡한 예시에서는, 상기 로직이 상당한 양일 수 있으므로, 레지스터 파일 읽기가 오랜 시간이 걸릴 수 있다. 바람직한 실시예에 사용되는 알고리즘에서 요구되는 여분의 면적(area)은 일반적으로 명령어의 레지스터 파일 액세스 필드를 배치하는 명령어 세트 디자이너에 의하여 피할 수 있으므로, 각 레지스터 파일을 읽는데 사용되는 상이한 필드의 수는 임의의 명령어에 의하여 사용되는 읽기의 최대 수와 동일하다. 이것이 상기 예시에서 iclass gfr의 gr 대신에 피연산자 gt가 사용되는 이유이다.

상기 알고리즘의 가능한 강화(enhancement)는 각 필드에 대한 schedule 문장(이하 "TIE의 멀티-사이클 명령어" 섹션에 더욱 상세히 설명됨)에 특정화된 최소 스테이지 수를 트랙킹하는 것이다. 만일 최소 스테이지 수가 명령어 디코드가 수행되는 스테이지 수보다 더 많으면, 필드의 먹싱(muxing)은 읽기 포트의 수를 감소시키는데 사용될 수 있다. 최소 스테이지 수가 명령어 디코드 스테이지 수 이내에 있는 모든 필드에 있어서, 레지스터 파일을 읽는데 사용되는 각 필드를 위한 별도의 포트가 사용된다.

다음의 예시를 살펴보자.

regfile SR 32 4 r

operand sx x {SR [x]}

operand sy y {SR [y]}

operand sz z {SR [z]}

operand su u {SR [u]}

operand sv v {SR [v]}

iclass stu {instl} (out sz, in sx, in sy, in su}

iclass stv {inst2} {out sz, in sx, in sy, in sv}

schedule stu {inst1} {

in sx 1 ;

in sy 1 ;

in su 2 ;

out sz 2 ;

}

schedule stv {inst2} {

in sx 1 ;

in sy 1 ;

in sv 2 ;

out sz 2 ;

}

여기서, 레지스터 파일 SR의 4개의 입력 피연산자는 sx, sy, su, sv 이다. 스케줄 정보에 따르면, su 및 sv 모두는 제2의 파이프라인 스테이지에서 사용되므로, 사이클 시간에 영향을 주지 않고도 단일 읽기 포트로 맵핑시킬 수 있다. 그 결과, SR 레지스터 파일의 4개의 읽기 포트를 만들 필요가 없다. 이 경우, 3개의 읽기 포트의 주소 신호를 read_addr_0, read_addr_1, read_addr_2 라고 하면, 3개의 주소에 대한 로직은,

read_addr_0 = x;

read_addr_1 = y;

read_addr_2 = inst1 ? u : v;

이다.

쓰기 포트들은 타임-크리티컬(time-critical)이 적다. 사이클 0에서 레지스터 파일을 읽는 매우 짧은 파이프라인 조차도 사이클 1에서 계산을 수행하고, 사이클 2에서 레지스터 파일을 기록한다. 따라서, 레지스터 파일을 기록하는데 사용되는 모든 필드 사이에서 디코딩 및 먹싱하기 위한 충분한 시간이 있다. 더 많은 임계 타이밍 경로(critical timing path)가 인터록되고; 사이클 0에서 레지스터 파일 을 읽은 후, 사이클 1의 시작시에 쓰여지는 레지스터 파일이 무엇인지를 알아야 하므로, 필요하다면 레지스터 파일을 읽는 다음의 명령어가 스톨될 수 있다. 하지만, 일반적으로 목적 레지스터 파일을 디코딩 및 먹싱하기 위한 충분한 시간은 1 사이클이고, 따라서 본 알고리즘은 속도에 영향을 주지 않고 면적을 절약할 수 있다.

프로세서 파이프라인에 대한 레지스터 파일 읽기 및 쓰기 포트의 인터페이스는 코어 프로세서의 파이프라인 아키텍처에 따라 변할 것이다. 바람직한 실시예에서, 코어 프로세서의 파이프라인은, 본 명세서에서 참조자료로 모두 채택되는 Dixit 등의 미국특허출원 일련번호 09/192,395호 및 Killian 등의 09/322,735호에 도시된 고정 파이프라인 스테이지의 읽기 및 쓰기 포트를 항상 사용하는데, 상기 읽기 포트들은 언제나 제1스테이지에 앞서, 쓰기 포트들은 4-스테이지 파이프라인 레지스터 파일의 마지막(4번째) 스테이지 다음에 사용된다.

각각의 읽기 포트는 소스 피연산자로서 그것을 사용하는 어떤 명령어의 가장 앞선 스테이지에서 읽혀질 것이고; 추후 스테이지에서 상기 피연산자를 사용하는 명령어들은 일찍이 레지스터 파일을 읽고, 상기 특정화된 스테이지에 따라 데이터를 단계화(stage)시킨다. 이러한 단계화는 또한 바이패스 먹스를 포함하여, 레지스터 파일이 읽힌 후에 소정의 요소를 생성하는 명령어들은 여전히 이용가능하다. 쓰기 포트에 있어서, 명령어 커밋 스테이지(commit stage)(예를 들면, W 스테이지)에서의 목적 피연산자로서 그것을 사용하는 어떤 명령어의 최후 스테이지에서 쓰기가 발생한다(상기 스테이지가 더 나중에 오는 경우). 도 1은 바람직한 실시예에서의 레지스터 파일 읽기 및 쓰기 포트를 위한 로직 스키마(schema)를 보여준다.

바이패스 로직

바이패스 로직은 도 1에 예시되어 있고, 읽기-포트 로직에서 먹스들에 의하여 달성된다. 예를 들면, 명령어는 스테이지 3에서의 결과값(wr0_data_C3)을 생성하고, 후속하는 명령어는 스테이지 1에서의 데이터를 사용하는 것이 필요하며, 읽기-포트 로직상의 제1먹스에 대한 제어 신호가 설정되어, 좌측으로부터 4번째 입력이 선택될 것이다. 그 결과, 차기 클럭 사이클에서는, 데이터(rd0_data_C1)가 명령어를 위하여 이용가능하다.

인터록 로직

인터록 로직은 도 2에 예시되어 있다. 스케줄 정보를 토대로, 명령어 디코딩 로직은 이슈될 명령어를 위하여 각각의 쓰기 포트용 useN 신호 및 각각의 읽기 포트용 defN를 발생시킨다. useN은 명령어가 스테이지 N에서 그 입력 레지스터 피연산자를 필요로 할 것이라는 것을 나타낸다. defN은 명령어가 스테이지 N에서 그 결과를 산출할 것이라는 것을 나타낸다. 더 나아가, 명령어에 대한 defN 신호는 파이프라인의 명령어를 따라 파이핑(pipe)된다. 스톨 신호는 모든 defN 및 useN 신호의 조합을 검사하여 발생된다. 다음의 예시는 2개의 읽기 포트(rd0 및 rd1) 및 1개의 쓰기 포트(wd0)를 구비한 4-스테이지 파이프라인 레지스터 파일에 대한 스톨 로직을 예시하였다. 신호 네임의 후위(suffix)(_Cn)는 신호가 파이프라인의 스테이지 n에 존재한다는 것을 나타낸다.

따라서,

assign Stall_R =

((wrO_addr_Cl == rdO_addr_CO) & (

(rdO_usel_CO & (wr0_def2_C1 | wr0_ns_def3_C1 | wr0_ns_def4_C1))

|

(rdO_use2_CO & (wrO_def3_Cl | wrO_ns_def4_Cl)) |

(rdO_use3_CO & (wr0_def4_C1)))) |

((wr0_addr_C2 == rd0_addr_C0) & (

(rdO_usel_CO & (wr0_def3_C2 | wr0_ns_def4_C2)) |

(rdO_use2_CO & (wr0_def4_C2)))) |

((wr0_addr_C3 == rd0_addr_C0) & (

(rdO_usel_CO & (wrO_def4_C3)))) |

((wrO_addr_Cl == rdl_addr_CO) & (

(rdl_usel_CO & (wr0_def2_C1 | wr0_ns_def3_c1 | wr0_ns_def4_C1))

|

(rdl_use2_CO & (wrO_def3_Cl | wrO_ns_def4_Cl)) |

(rdl_use3_CO & (wr0_def4_C1)))) |

((wr0_addr_C2 == rd1_addr_C0) & (

(rdl_usel_CO & (wrO_def3_C2 | wrO_ns_def4_C2)) |

(rdl_use2_CO & (wr0_def4_C2)))) |

((wr0_addr_C3 == rd1_addr_C0) & (

(rdl_usel_CO & (wrO_def4_C3)))) ;

다음의 perl 코드는 스톨 코드를 개발하기 위한 바람직한 실시예에 사용된다. wfield( ) 및 rfield( )는 간단한 신호 네임, 포트 네임 및 스테이지 수로부터 신호 네임을 구성하는 함수이다. 식(expression)은 효율적인 인자 형태(factored form)로 쓰여진다.

print " assign Stall_R =＼n" ;

foreach $write_port (@{$rf->{WRITE_PORT}}) {

foreach $read_port (@{$rf->{READ_PORT}}) {

for($s = 1; $s <= $write_port->{MAX_DEF}-1; $s++) {

my($waddr) = wfield("addr", $write_port, $s) ;

my($raddr) = rfield ("addr", $read_port, 0) ;

print " (($waddr == $raddr) & (＼n" ;

for($i = 1; $i <= $write_port-> {MAX_DEF} - $s ; $i++) {

my($use) = rfield("use$i", $read_port, 0);

print " ($use & (";

for($j = $i+$s; $j <= $write_port->{MAX_DEF}; $j++) {

my($ns_def) = wfield("ns_def$j", $write_port, $s);

print "$ns_def";

if ($j ! = $write_port->{MAX_DEF}) {

print " | ";

}

print "))";

if ($i == $write_port->{MAX_DEF} - $s) {

print ")) |＼n";

} else {

print " |＼n";

}

print " l'bO;＼n";

print "＼n";

쓰기 로직

쓰기 포트 주소들은 각각의 쓰기 포트에 관련된 하드웨어 비용을 낮추기 위하여 바람직한 실시예에서 먹싱되기 때문에, 어떤 피연산자가 어떤 포트를 사용하는지를 결정하기 위한 알고리즘을 구비할 필요가 있다. 이러한 먹싱을 위한 하나의 기준(criteria)은 필요한 로직을 최소화하는 것이다. 타겟 파이프라인에서, 일차적인 로직 비용은 데이터를 쓰기 포트 스테이지에 단계화시키는 비용이다. 만일 동일한 파이프라인 스테이지에서 모든 쓰기가 발생한다면, 상기 로직 비용은 차이가 없 지만, 다수의 스테이지에서 쓰기가 발생한다면, 유사한 쓰기 스테이지를 목적 피연산자와 함께 그룹화시켜 로직을 절약할 수 있다.

다음의 예시를 살펴보자.

regfile SR 32 8 s

operand sx x {SR [x]}

operand sy y {SR [y]}

operand sz z {SR [z]}

operand su u {SR [u]}

operand sv v {SR [v]}

iclass i1 {instl} (out sx, out sy, in su, in sv}

iclass i2 {inst2} {out sz, in su, in sv}

schedule s1 {inst1} {

out sx 8;

out sy 3;

}

schedule s2 {inst2} {

out sz 9;

}

여기서, inst1은 SR에 대하여 2개의 결과값(3 사이클에 하나 그리고 8 사이클에 다른 하나)을 산출한다. inst2는 9사이클로 SR에 대하여 1개의 결과값을 산출 한다. inst1은 2개의 쓰기 포트를 필요로 하고, inst2는 하나의 쓰기 포트를 필요로 하며, 레지스터 파일 SR은 단지 2개의 쓰기 포트만을 가져야 한다. 상기 포트들을 wr0 및 wr1이라 하자. inst1에 대하여, 쓰기 포트에 대한 피연산자의 맵핑은 다음과 같이 간단하다.

sx -> wr0

sy -> wr1

이는 wr0은 8 스테이지를 가져야하고, wr1은 3 스테이지를 가져야한다는 것을 암시한다. inst2에 대하여는, 아래 둘 중에서 어느 하나가 선택된다.

sz -> wr0

sz -> wr1

하지만, 상기 두가지 선택은 상이한 로직 비용을 가진다. sz를 wr0에 맵핑하는 것은 하나의 또 다른 스테이지를 wr0에 추가(8에서 9로 증가)시키는 것을 의미하고, wr1에 매핑하는 것은 6개의 또 다른 스테이지를 wr1에 추가(3에서 9로 증가)시키는 것을 의미한다.

바람직한 실시예는 다음의 알고리즘을 사용한다. 각각의 명령어에 있어서, 피연산자를 내려가는 순서로 스테이지 수만큼 소트(sort)시키고, 그들을 순차적으로 쓰기 포트 0 내지 쓰기 포트 n-1로 지정하자. 따라서, 쓰기 포트 0은 가장 긴 데이터 체인(chain)을 가지고, 쓰기 포트 n-1은 가장 짧은 데이터 체인을 가질 것이다. m 이 n 보다 적은 m 피연산자를 갖는 명령어에 있어서, 상기 피연산자는 스테이지 수만큼 유사한 내려가는 순서로 제1의 m 쓰기 포트에 맵핑될 것이다. 다음 의 예시는 쓰기-포트 지정 프로세스를 예시하는데 사용된다.

regfile SR 32 8 s

operand sx x {SR [x]}

operand sy y {SR [y]

operand sz z {SR [z]}

operand su u {SR [u]}

operand sv v {SR [v]}

operand sw w {SR [w]}

iclass il {instl} {out sx, out sy, in su, in sv}

iclass i2 {inst2} {out sz, in su, in sv}

iclass i3 {inst3} {out sw, in su, in sv}

schedule sl {instl} {

out sx 8 ;
out sy 3 ;

}

schedule s2 {inst2} {

out sz 9 ;

}

schedule s3 {inst3} {

out sw 2 ;

}

이 프로세스는 다음의 지정을 만들어낸다.

inst1에 대하여,

sx -> wr0

sy -> wr1

inst2에 대하여,

sz -> wr0

inst3에 대하여,

sw -> wr0

상기 쓰기-포트 지정 프로시저는 데이터 단계화 비용을 최소화하더라도, 전력 소비와 같은 기타 비용 기준을 최적화하기 위하여 더욱 세분화될 수 있다. 상기 예시에서, inst3의 sw는 단계화 비용을 결코 증가시키지 않고도 wr1에 맵핑될 수 있다. 하지만, 그렇게 함으로써, 데이터가 스테이지 2의 말단에서 레지스터 SR내에 쓰여진 후에 파이프라인의 전력을 다운시키는(power-down) 기회가 제공될 수도 있다.

sw를 wr0에 지정하는 것은 9 사이클동안 활성화(active)될 파이프라인을 요구할 것이다. 다음의 프로시저는 전력 소비와 같은 부가적인 비용을 고려하기 위하여 쓰기-포트 지정을 더욱 개선시키는 제2의 패스(pass)로서 사용될 수 있다.

m 피연산자(여기서, m < n)를 갖는 각각의 명령어에 대하여, 그리고 역 순서(reverse order)의 각각의 피연산자에 대하여, 신규 쓰기 포트 i(여기서, i는 단계화 비용을 증가시키지 않는 가능한 한 큰 값임)에 대한 피연산자의 지정을 이 동시키자. 앞선 예시를 이용하여 상기 프로시저를 설명하기 위하여, inst1의 피연산자는 이미 모든 쓰기 포트를 사용하기 때문에 이동될 수 있는 inst1의 피연산자가 없다. inst2에 있어서는, 단계화 비용을 증가시키지 않고 sz가 wr1에 재지정(re-assign)될 수 없다. inst3에 있어서는, 단계화 비용을 증가시키지 않고 sw가 wr0에서 wr1로 재지정될 수 있다.

레지스터 파일 읽기 및 쓰기 포트의 지정에 있어서의 알고리즘에 대한 다양한 변화가 가능하다. 예를 들어, 어떤 경우에는 전력 소비를 낮추도록 데이터 단계화를 최소화하기 위하여 엄밀하게 요구되는 것보다 많은 포트들을 제공하는 것이 적합할 수 있다. 또한, 읽기 및 쓰기 포트에 관련된 하드웨어 비용을 더욱 낮추기 위하여 소정의 명령어에 의하여 요구되는 것보다 더 적은 포트를 제공하는 것도 가능하며; 읽기 포트에 대해서는, 이것이 레지스터 피연산자를 읽는데 다수의 사이클이 걸리는 것을 의미하고, 쓰기 포트에 대해서는 쓰기 포트가 사용되지 않는 사이클동안 기다리도록 소정의 레지스터 쓰기값들을 버퍼링시키는 것을 의미한다. 또 다른 가능성은 TIE 코드가 레지스터 파일 읽기 및 쓰기 포트 지정을 특정화시키도록 하여, 자동 알고리즘이 바람직하지 않은 결과값을 제공하는 경우를 취급할 수 있다.

확장된 레지스터 구현의 상기 개념들은 Appendix B의 코드, 즉 N-읽기, M-쓰기 B-비트 S-엔트리 레지스터 파일을 생성하는 perl 프로그램에 사용된다.

로드/저장 명령어

해당 기술분야의 배경지식에서 알 수 있듯이, TIE 로드 및 저장 명령어는 데 이터를 TIE 레지스터 파일로 그리고 TIE 레지스터 파일로부터 메모리로 직접 전송하기 위한 수단을 제공하는 것이 필요하다. 이러한 요구사항으로 인하여, 그들은 코어 파이프라인의 메모리(M) 스테이지의 로컬 메모리들, 즉 데이터 캐시, Data RAM, Data ROM 등을 공유해야 한다. 상기 로컬 메모리를 공유하는 것 이외에, 코어 로드/저장에 사용되는 여타의 하드웨어 자원(resource)들은 가능한 한 공유하는 것이 바람직하다. 자원들을 공유하는 것은 면적 및 타이밍의 관점에서 더욱 최적의 솔루션을 얻을 수 있다. 후술하는 바와 같이, 주소 계산 로직 및 데이터 정렬 로직은 코어 및 TIE 로드/저장간에 공유되는 2 세트의 자원들이다.

다음의 인터페이스 신호들은 바람직한 실시예의 TIE 로드/저장을 구현하는데 필요하다.

interface VaddrOffset 32 core out

interface VaddrBase 32 core out

interface VaddrIndex 32 core out

interface LSIndexed 1 core out

interface LSSize 5 core out

interface MemDataOut<n><n> core out

interface VaddrIn 32 core in

interface MemDataIn<n> <n> core in

이들 신호의 대부분은 도 4에 예시되어 있고, 도 6은 LSSize 927, MemDataOut<n> 901, MemDataIn<n> 938을 보여준다. LSSize는 데이터 참조의 크기를 바이트로 제공한다(바람직한 실시예에서는 1, 2, 4, 8 또는 16). MemDataOut<n>은 TIE 시맨틱으로부터 코어로의 저장 데이터를 제공하고, MemDataIn<n>은 코어로부터 TIE 시맨틱으로의 로드 데이터를 제공한다. 바람직한 실시예에서, <n>은 8, 16, 32, 64 또는 128이다.

TIE 로드/저장의 메모리 주소를 계산하는 것에 있어서, TIE 로드 및 저장 명령어의 포맷과 코어의 포맷이 일치하는 경우에는 주소 가산기를 공유하는 것이 가능하다. 주소 가산기를 복사(duplicate)하는 것은 낭비일 수 있고, 주소 계산 경로에 있어 추가적인 딜레이를 도입할 수도 있다. 인터페이스 신호들은 도 4에 도시된 코어 주소 가산기로의 입력들을 나타낸다. 이러한 주소 로직은 다음과 같은 어드레싱 모드를 지원하도록 되어 있다.

I AR [s] + immediate

X AR [s] + AR [t]

두가지 모드간의 선택은 LSIndexed 인터페이스 신호에 의하여 이루어진다. I-형태로 사용되는 직접모드(immediate)는 VAddrOffset 입력상에 제공되고, X-형태로 사용되는 AR[t] 값은 VAddrIndex 입력상에 제공된다. VaddrBase는 AR[s]를 제공하는데 사용된다. AR[s] 및 AR[t] 이외의 기타 값들은 TIE 시맨틱 블록에 의하여 VAddrBase 및 VAddrIndex상에 제공될 수 있는 한편, 만일 이들 값들이 로직 최적화로 하여금 그 결과적인 로직을 상당히 단순화하도록 한다면, 이에 따라 주소 생성이 타이밍-크리티컬되지 않게 한다. 이는 로직 최적화는 TIE 로직으로부터의 VaddrBase(AR[s])가 코어의 베이스 주소와 동일하고 상기 동일한 신호에 대하여 그 것을 감소시킨다는 것을 인식할 것이기 때문이다.

TIE는 코어에서 로드 및 저장 정렬 로직에 의하여 이익을 얻을 수 있다(상기 로직에 대해 소정의 수정이 제공되는 경우). 정렬(alignment)은 구현하는데 매우 많은 로직을 요구하기 때문에, TIE에 대한 복사(replication)를 피하는 것은 상당한 면적을 절약할 수 있다. 더욱이, 복사는 헤비 로딩(heavy loading)으로 인하여 타이밍 임계 경로를 도입시킬 수 있고, 이는 로컬 메모리 출력과 정렬 및 데이터 선택 제어 신호를 구동(drive)시키게 한다. 그러나, 정렬 자원의 공유를 구현하기 위해서는 도 5 및 도 6에 예시화된 수정들이 요구된다.

이들 수정들은 우선 TIE 로드/저장이 32비트의 코어 로드/저장에 대조(oppose)되는 다수의 로드/저장 폭을 요구/제공한다는 사실과 관련된다. 이는 정렬 로직내의 모든 데이터 경로들이 TIE 또는 코어 데이터 폭의 최대값과 일치하도록 그 폭을 증가시켜야 한다는 것을 의미한다. 둘째로, TIE 로드는 코어에 의하여 요구되는 간단한 오른쪽 시프트에 대조되는 더욱 일반적인 정렬 함수를 요구할 수 있다. 이는 정렬 로직이 TIE 정렬 함수 및 코어 오른쪽 시프트의 수퍼셋(superset)을 수행하여야 한다는 것을 의미한다.

도 5는 128비트 액세스 폭의 3방향 세트 결합형 데이터 캐시(803~805) 및 병렬 데이터 RAM(806)을 위한 종래의 코어 로드 정렬 로직을 보여준다. 본 예시에서, 언캐시 데이터 입력(808)은 또한 캐시 보충(refill) 편의를 위하여 128비트 폭으로 선택되고, 데이터 RAM 액세스는 32비트 폭인데, 그 이유는 그 최대 폭이 32비트인 코어 로드/저장들을 통해서만 액세스되기 때문이다. 또한, 저장된 데이터가 후속하 는 로드에 바이패스되어야 할 때 사용되는 32비트 폭 저장 데이터 입력(807)이 있다.

사용되는 일차적인 정렬 메커니즘은, 4:1 멀티플렉서(809~812)에 이어 부호 확장(sign extension)(814~819)도 행하는 바이트-레벨 오른쪽 시프트가 뒤따른다. 상기 시프트의 양은 로드 주소(813, 821) 및 원-핫(one-hot) 디코딩된 coreSize 신호(820)에 의하여 주어진다. 저장 및 데이터 RAM 데이터는 그들이 이미 32비트 폭이기 때문에 4:1 멀티플렉서를 필요로 하지 않는다. 그 후, 상기 32비트 폭 정렬 데이터는 일련의 후속 멀티플렉서(822~833)에 의하여 선택되어, 최종 코어 로드 데이터(834)를 산출한다.

도 6은 본 실시예에서의 로드 정렬 구현의 일 예시를 보여준다. 일차적인 차이점은, 모든 로드 데이터 소스(906~911)가 128비트 폭 TIE 로드 명령어를 지원하도록 현재 128비트 폭이고, 로드 정렬 결과 또한 128비트 폭이라는 점이다. 본 예시에서, 정렬 자체는 바이트-레벨 로테이터(rotator)(914~918)에 이어 부호 확장기(sign extender)(921~925)를 사용하여 행해진다. 본 예시에서는 TIE 시맨틱에서 데이터 로테이션을 위한 호출(call)이 일어나기 때문에, (또한, 코어 로드 정렬에 의하여 요구되는 간단한 오른쪽 시프트 이외에) 바이트-레벨 로테이터가 요구된다. 시프트 또는 회전의 양은 로드 주소(919) 및 원-핫 디코딩된 LSSize(927) 또는 coreSize(926) 신호에 의하여 주어진다. 로드 정렬의 최종 출력은 TIE 코프로세서(전체 128비트 폭(938)은 LSSize에 의하여 특정화된 다수의 로드 폭을 제공함) 또는 코어(최소 유효 32비트 부분(939)만이 coreSize에 의하여 특정화된 3개의 코 어 로드 폭 32/16/8비트를 제공함) 중 어느 하나에 의하여 사용될 수 있다.

코어는 메모리 데이터 이외에 시맨틱 블록으로 되돌아 가는 가상 주소를 제공한다. 가상 주소는 때때로 로드 데이터상에서 부가적으로 프로세싱하기 위하여 필요하다. 또한, 이는 가상 주소를 형성하는데 사용되는 레지스터들을 수정하는 것을 로드 및 저장 명령어들이 정의하도록 한다. 예를 들어, 코어 ISA의 "업데이트" 모드는 다음을 행한다.

IU vAddr <- AR[s] + offset

AR[s] <- vAddr

XU vAddr <- AR[s] + AR[t]

AR[s] <- vAddr

베이스 주소 레지스터 AR[s]로의 번들 쓰기(bundled write)는 많은 내부 루프(inner loop)에서 별도의 인크리멘트(increment) 명령어를 피한다. 이는 "in"을 "inout"으로 변경하고, 지정값을 더하는 것과 같이 간단하게 TIE에서 달성된다.

베이스 주소 레지스터로의 번들 쓰기의 이점을 이해하기 위하여, 첫째로 상기 특징을 사용하지 않는 소프트웨어 루프를 살펴보자.

for (i = 0; i < n; i++) {

x = tie_loadi(px, 0);

y = tie_loadi (py, 0);

z = instl(x, y);

tie_storei(z, pz, 0);

px = px + 8;

Py = py + 8;

pz = pz + 8;

}

상기 예시는 요소들이 8바이트 폭인 2개의 입력 어레이(px, py)에 걸쳐 루프하고, 계산(inst1)을 수행하며, 그 결과를 또 다른 어레이(pz)에 저장한다. 상기 루프의 7개의 명령어 가운데 3개는 로드 및 저장 명령어에 대한 베이스 포인터(base pointer)를 진행시키는데 사용되었다. 번들 쓰기 로드 및 저장 명령어를 사용하면, 상기 예시는 다음의 코드에 예시된 바와 같이 훨씬 더 효과적일 것이다.

px = px - 8;

py = py - 8;

pz = pz - 8;

for (i = 0; i < n; i++) {

x = tie_loadiu(px, 8);

y = tie_loadiu(py, 8);

z = inst1(x, y);

tie_storeiu(z, pz, 8);

}

이하, tie_loadiu(tie_storeiu)는 p+8로서 가상 주소를 계산하고, 메모리 데 이터를 로드(저장)하며, 하나의 명령어에서 p를 p+8로 변경시킬 것이다. 초기 감산들은, 첫번째 것이 px+8, py+8에서 시작하고, px+8에 우선 저장하기 때문에, px, py, pz를 정정하는 것이 필요하다.

본 명세서에 기술된 로드/저장 인터페이스와 같은 코어 신호의 스테이지 수는 코어 파이프라인에 의하여 고정되고, schedule 선언으로 특정화되지 않는다. 하지만, 상술된 파이프라인 삽입 알고리즘에 적절한 값들이 사용된다. 예를 들어, 다음과 같이 로드 및 저장 명령어를 상기 Galois-필드 산술 GF 유닛 예시에 더한다.

opcode LGF8. I r=4'bOOOO LSCI

opcode SGF8. I r=4'b0001 LSCI

opcode LGF8. IU r=4'bOO10 LSCI

opcode SGF8. IU r=4'bOO11 LSCI

opcode LGF8. X op2=4'bOOOO LSCX

opcode SGF8. X op2=4'b0001 LSCX

opcode LGF8. XU op2=4'bOO10 LSCX

opcode SGF8. XU op2=4'bOO11 LSCX

interface VaddrOffset 32 core out

interface VaddrBase 32 core out

interface VaddrIndex 32 core out

interface LSIndexed 1 core out

interface LSSize 5 core out

interface MemDataIn8 8 core in

interface VaddrIn 32 core in

interface MemDataOut8 8 core out

iclass gfloadi {LGF8. I} {out gt, in ars, in imm8} {} {

out LSSize, out LSIndexed, out VAddrOffset, out VAddrBase, in

MemDataIn8}

iclass gfstorei {SGF8. I} {in gt, in ars, in imm8} {} {

out LSSize, out LSIndexed, out VAddrOffset, out VAddrBase,

out MemDataOut8}

iclass gfloadiu {LGF8. IU} {out gt, inout ars, in imm8} {} {

out LSSize, out LSIndexed, out VAddrOffset, out VAddrBase, in

MemDataIn8, in VAddrIn}

iclass gfstoreiu {SGF8. IU} {in gt, inout ars, in imm8} {} {

out'LSSize, out LSIndexed, out VAddrOffset, out VAddrBase,

out MemDataOut8, in VAddrIn}

iclass gfloadx {LGF8.X} {out gr, in ars, in art} {} {

out LSSize, out LSIndexed, out VAddrIndex, out VAddrBase, in

MemDataIn8}

iclass gfstorex {SGF8. X} {in gr, in ars, in art} {} {

out LSSize, out LSIndexed, out VAddrIndex, out VAddrBase,

out MemDataOut8}

iclass gfloadxu {LGF8. XU} {out gr, inout ars, in art} {} {

out LSSize, out LSIndexed, out VAddrIndex, out VAddrBase, in

MemDataIn8, in VAddrIn}

iclass gfstorexu {SGF8. XU} {in gr, inout ars, in art} {} {

out LSSize, out LSIndexed, out VAddrIndex, out VAddrBase,

out MemDataOut8, in VAddrIn}

semantic lgf {LGF8. I, LGF8. IU, LGF8. X, LGF8. XU} {

assign LSIndexed = LGF8. LGF8. XU ;

assign LSSize = 1 ;

assign VAddrBase = ars ;

assign VAddrIndex = art ;

assign VAddrOffset = imm8 ;

assign gt = MemDataIn8 ;

assign gr = MemDataIn8 ;

assign ars = VAddrIn ;

}

semantic sgf {SGF8. I, SGF8. IU, SGF8. X, SGF8. XU} {

assign LSIndexed = SGF8. X|SGF8. XU ;

assign LSSize = 1 ;

assign VAddrBase = ars ;

assign VAddrIndex = art ;

assign VAddrOffset = imm8 ;

assign MemDataOut8 = SGF8. X|SGF8. XU ? gr : gt ;

assign ars = VAddrIn ;

}

schedule gfload {LGF8. I}

{

use imm8 0 ;

use ars 1 ;

def gt 2 ;

}

schedule gfloadu {LGF8. IU}

{

use imm8 0 ;

use ars 1 ;

def ars 1 ;

def gt 2 ;

}

schedule gfloadx {LGF8. X}

{

use ars 1 ;

use art 1 ;

def gr 2 ;

}

schedule gfloadxu {LGF8. XU}

{

use ars 1 ;

use art 1 ;

def art 1 ;

def gr 2 ;

}

본 발명에 있어서 로드 정렬기를 생성하기 위한 tpp 입력은 다음과 같다.

module loadalign (out, in, va, vamask, TIEload, L16SI, L16UI, L8UI) ;

; use Utilities ;

; my $bits = $pr-> dcache-> accessBits ;

; my $bytes $bits >> 3 ;

; my $mux = log2 ($bytes) ;

output out ['$bits-l' : 0] ;

input in ['$bits-1' : 0] ;

input va ['$mux-1' : 0] ;

input vamask ['$mux-1' : 0] ;

input TIEload ;

input L16SI ;

input L16UI ;

input L8UI ;

wire L8orl6 = L8UI|L16UI|L16SI ;

wire vam ['$mux-1' : 0] = TIE1oad

? va & vamask

: {va ['$mux-1' : 2], va [1] & L8orl6, va [0] & L8UI} ;

; sub rot (

; my ($bits, $n, $step, $in, $out, $sel) = @_;

; my @muxin = map ($_ == 0

; ? $in

; : '{'.$in. ' ['.($_*$step-1). ':0],'.$in.'[' # ($bits-

1).' : '. ($_*$step).']}',

; 0.. ($n-1)) ;

xtmux'$n'e #'$bits' ('$out',

'join (", ＼n＼t＼t", @muxin) ',

'$sel');

; }

; my $in ='input' ;

; if ($mux & 1) {

; # rotate is done with 4 : 1 muxes and one 2 : 1 mux

; # combine the last 2 : 1 mux with the sign extend

; for (my $i = $mux-2 ; $i > = 1 ; $i -= 2) {

; my $out = 't'.($temp++);

wire ['$bits-1':0] '$out';

; rot($bits, 4, 8 * (1 << $i), $in, $out,

'vam ['.($i+1).':'.$i.']');

; $in = $out;

; }
if ($bits > 32) {

xtmux2e #'$bits - 32' (output['$bits-1': 32],

'$in' ['$bits-1':32],

{'$in'[7:0],'$in'['$bits-l':40]},

vam [0]) ;

; }

xtmux4e #16 ( output[31 : 16],

'$in'[31:16],

; if ($bits > 32) {

'$in'[39:24]},

; } else {

{'$in'[7:0],'$in'[31:24]},

; }

{16('$in'[15] & L16SI}},

16'b0, //should never happen because vam [O]

//is forced 0 if L8orl6 is set

{L8orl6, vam [0]});

xtmux4e #8 ( output[15:8],

'$in'[15:8],

'$in'[23:16],

8'bO,

{L8UI,vam[O]});

xtmux2e #8 ( output[7:0],

'$in'[7:0],

'$in'[15:8],

vam [O]);

; } else {

; # rotate is all done in 4 : 1 muxes,

; # so sign extend must be done in separate 2 : 1

; for (my $i = $mux-2 ; $i > = 0 ; $i -= 2) {

; my $out ='t'. ($temp++) ;

wire ['$bits-1' : 0] '$out' ;

; rot ($bits, 4, 8 * (1 << $i), $in, $out,

'vam['.($i+1).':'.$i.']') ;

; $in = $out ;

; }

assign out = {

; if ($bits > 32) {

'$in'['$bits-1':32],

; }

L8orl6 ? [16{'$in'[15] & L16SI}} : "$in'[16:32],

'$in'[15:8] &~ {8{L8UI}},

'$in' [7:0] } ;

; }

endmodule loadalign

폭 128의 출력은 다음과 같다.

module loadalign (out, in, va, vamask, TIEload, L16SI, L16UI,

L8UI) ;

output out [127 : 0] ;

input in [127 : 0] ;

input va [3 : 0] ;

input vamask [3 : 0] ;

input TIEload ;

input L16SI ;

input L16UI ;

input L8UI ;

wire L8orl6 = L8UI|L16UI|L16SI ;

wire vam [3 : 0] = TIEload

? va & vamask

: (va [3 : 2], va [1] & L8orl6, va [0] & L8UI} ;

wire [127 : 0] tO ;

xtmux4e #128 (t0,

input,

{input [31 : 0], input [127 : 32]},

{input [63 : 0], input [127 : 64]},

{input [95 : 0], input [127 : 96]},

vam [3 : 2]) ;

wire [127 : 0] tl ;

xtmux4e #128 (t1,

tO,

{t0 [7 : 0], to [127 : 8] },

{tO [15 : 0], tO [127 : 161] },

{tO [23 : 0], to [127 : 24]},

vam [1 : 0] ) ;

assign out = {

tl [127 : 32],

L8orl6 ? {16 {tl [15] & L16SI}} : t1 [16 : 32],

tl [l5 : 8] &~ {8{L8UI}},

tl [7 : 0]} ;

endmodule loadalign

폭 64의 출력은 다음과 같다.

module loadalign (out, in, va, vamask, TIEload, L16SI, L16UI,

L8UI) ;

output out [63 : 0] ;

input in [63 : 0] ;

input va [2 : 0] ;

input vamask [2 : 0] ;

input TIEload ;

input L16SI ;

input L16UI ;

input L8UI ;

wire L8orl6 = L8UI|L16UI|L16SI ;

wire vam [2 : 0] = TIEload

? va & vamask

: {va [2 : 2], va [1] & L8or16, va [0] & L8UI} ;

wire [63 : 0] to ;

xtmux4e #64 (t0,

input,

{input [15 : 0], input [63 : 16] },

{input [31 : 0], input [63 : 32] },

{input [47 : 0], input [63 : 48] },

vam [2 : 1]) ;

xtmux2e #32 (output [63 : 32],

tO [63 : 32],

{t0 [7 : 0], to [63 : 40] },

vam [O]) ;

xtmux4e #16 ( output [31 : 16],

tO [31 : 16],

tO [39 : 24]},

{16 {tO [15] & L16SI}},

16,b0, // should never happen because vam [0]

//is forced 0 if L8orl6 is set

{L8or16, vam [0] }) ;

xtmux4e #8 ( output [15 : 8],

tO [15 : 8],

tO [23 : 16],

8'bO,

{L8UI, vam [0]}) ;

xtmux2e #8 ( output [7 : 0],

tO [7 : 0],

tO [15 : 8],

vam [0]) ;

endmodule loadalign

폭 32의 출력은 다음과 같다.

module loadalign (out, in, va, vamask, TIEload, L16SI, L16UI,

L8UI) ;

output out [31 : 0] ;

input in [31 : 0] ;

input va[l : 0] ;

input vamask [1 : 0] ;

input TIEload ;

input L16SI ;

input L16UI ;

input L8UI ;

wire L8orl6 = L8UI|L16UI|L16SI ;

wire vam [1 : 0] = TIEload

? va & vamask

: {va [1 : 2], va [1] & L8orl6, va [0] & L8UI} ;

wire [31 : 0] tO ;

xtmux4e #32 (tO,

input,

{input [7 : 0], input [31 : 8]},

{input [15 : 0], input [31 : 16]},

{input [23 : 0], input [31 : 24]},

vam [l : 0]) ;

assign out = {

L8orl6 ? {16 {tO [15] & L16SI}} : tO [16 : 32],

tO [15 : 8] &~ {8{L8UI}},

tO [7 : 0]} ;

endmodule loadalign

코어로의 인터페이스

로드 및 저장은 통상적으로 데이터 캐시 또는 작은 데이터 RAM을 사용하여 프로세서 파이프라인내에서 프로세싱된다. 비용 및 정확성(correctness) 모두에 있어서, 신규 로드 및 저장 명령어는 또한 상기 데이터 캐시/RAM을 사용하여, TIE 및 코어 명령어 모두에 의하여 프로세싱되는 캐시/RAM 데이터의 무결성(integrity)을 유지시켜야 한다. 종래의 시스템에서, 코어에 추가된 명령어들은 상기 코어와 로직을 공유하지 않았다. 바람직한 실시예는 이러한 공유를 위한 메커니즘을 제공한다.

TIE 구성

interface <sname> <width> <mname> [in|out]

은 TIE 모듈 <mname>로 인터페이스하는 신호 <sname>를 선언한다. 상기 신호는 <width> 비트 폭이고, 최후 파라미터에 따라 상기 TIE 코드로 입력 또는 출력된다. 코어로의 인터페이스를 위하여, <mname>은 core이다.

TIE iclass 구성은 명령어에 의하여 사용되는 인터페이스 신호들을 리스트화하도록 확장된다. 그 구문은,

iclass <classname>

{ <iname>, ... }

{ <operandspec>, ... }

{ <statespec>, ... }

{ <interfacespec>, ... }

이고, 여기서 <interfacespec>은 in <sname> 또는 out <sname> 중의 하나이고, <sname>은 인터페이스 신호 네임 또는 예외 문장에서 선언된 예외 신호 네임 중의 하나이다. 예외 신호 네임은 입력으로서가 아니라 출력으로만 사용될 수 있다. 마찬가지로, schedule 구성은 확장되어, 인터페이스 신호 네임으로 하여금 (입력을 위한) "in" 또는 (출력을 위한) "out"을 사용하여 파이프라인 스테이지 수가 제공되도록 한다.

시맨틱 블록으로부터의 각 출력 인터페이스 신호는, iclass의 인터페이스 섹션에 리스트화된 출력을 구비한 명령어의 원-핫 명령어 디코드 신호의 OR과 함께 AND된다. 그 후, 모든 시맨틱 블록으로부터의 AND된 인터페이스 신호들은 코어에 대한 출력 신호를 형성하도록 함께 OR된다. 도 7은 TIE 컴파일러에 의하여 출력 인터페이스 신호 sname의 구현을 예시한다. sname_semI는 i'번째 시맨틱 블록에 의하여 생성된 sname의 값을 나타낸다. iN1 및 iN2는 1비트의 명령어 디코드 신호이고, sname_semI_sel은 i'번째 시맨틱이 sname을 생성하는 상태하의 조건(condition)을 나타내는 신호이다. 각각의 입력 인터페이스 신호는 상기 신호를 사용하는 모듈들에 직접 공급된다.

TIE의 컴파일러/OS 지원

지금까지 TIE 구성들은 상태 및 명령어들이 정의되도록 되어 있었지만, 이들 명령어들이 어떻게 소프트웨어에 의하여 자동으로 사용되어야 하는지에 대해서는 어떠한 단서도 제공되지 않았다. 종래 시스템에서는, 명령어의 모든 사용이 어플리케이션내에 쓰여진 내재함수(intrinsic)들을 거쳐 참조되었다. 이에 따라, 컴파일러는 상기 내재함수를 명령어상에 맵핑시키는데만 필요하였고, 상기 내장함수 자체의 사용법은 알 필요는 없었다. 사용자-정의 레지스터 파일의 추가에 의하면, 컴파일러가 프로그램 변수들을 레지스터 파일의 요소들에 할당시키는 것이 바람직해진다. 레지스터 할당시, 컴파일러는 프로그램 값들을 레지스터 파일(들)에 포함된 레지스터에 지정하는 것을 시도한다. 프로그램의 소정의 위치에서는, 모든 값들을 레지스터에 지정하는 것이 가능하지 않을 수도 있다. 이들 위치에서, 1이상의 값들은 메모리로 이동되어야 한다. 레지스터로부터 메모리로 값을 이동시키는 것은 저장을 필요로 하고, 메모리로부터 레지스터로 값을 이동시키는 것은 로드를 필요로 한다. 따라서, 최소한 컴파일러는 메모리로부터 레지스터로 값을 로드시키는 법과 레지스터로부터 메모리로 값을 저장하는 법을 알아야 한다.

레지스터 할당시, 컴파일러가 값을 한 레지스터로부터 다른 레지스터로 이동시키기 것이 필요할 지도 모른다. 예를 들어, 함수에 의하여 생성된 값은 레지스터 A에서 리턴될 수 있고, 차기 명령어는 상기 값이 레지스터 B로부터 사용되는 것을 요구할 수도 있다. 컴파일러는 임시 메모리 위치에 레지스터 A를 먼저 저장시킨 후, 상기 메모리 위치로부터 레지스터 B를 로드시켜, 레지스터 A에서 레지스터 B로 상기 값을 이동시킬 수 있다. 하지만, 상기 값을 레지스터 A로부터 레지스터 B로 직접 이동시키는 것이 더욱 효율적이기 쉽다. 따라서, 필수적인 것은 아니지만, 상기 컴파일러는 한 레지스터로부터 다른 레지스터로 값을 이동시키는 법을 아는 것 이 바람직하다.

세이브 및 재저장 시퀀스는 개별적인 레지스터의 세이브 및 재저장 시퀀스의 간단한 연결(concatenation)보다 더욱 복잡할 수 있다. 전체 레지스터 파일을 만듦에 있어서, 성능 및/또는 공간절약(space saving) 대 스필 명령어의 명백한 연결에 대한 기회일 수 있다. 이는 또한 레지스터 파일에 있지 않는 코프로세서 상태를 포함할 수 있다.

각 코프로세서의 상태는, 상이하고 잠재적으로 상호의존형(interdependent)인 다양한 구성요소들로 이루어진다. 이들 구성요소들을 세이브 및 재저장하는데 사용되는 명령어 시퀀스는 상호의존성에 따라 좌우될 수 있다.

이러한 종속성(dependency) 정보는 그래프로 표현될 수 있다. 그래프가 주기적이라면, 상기 상태는 제 때에 임의의 점에서 성공적으로 세이브될 수 없다. 그러나, 종속성 그래프가 비주기적이라면(DAG), 모든 코프로세서의 상태가 제 때에 임의의 점에서 세이브 및 재저장될 수 있도록 상기 구성요소들의 세이브 및 재저장을 명령(order)하는 방식이 있다.

TIE 컴파일러는 상기 종속성 정보를 생성 및 분석하기 위하여 표준 그래프 구성 및 분석 알고리즘을 사용하고, 주어진 코프로세서를 위한 세이브 및 재저장 시퀀스 생성시에 상기 정보를 고려한다.

예를 들어, 2개의 레지스터 파일(regfile_a 및 regfile_b)을 갖는 코프로세서를 살펴보자. regfile_a는 4개의 32비트 레지스터를 갖고, regfile_b는 16개의 128비트 값을 가진다. 부가적인 상태는 레지스터들이 터치된(reg_touched라 불림) 비트필드(bitfield)이고, regfile_a의 레지스터 0을 되돌리는(reg_back이라 불림) 푸시 레지스터이다. 코프로세서는 상기 코프로세서 상태를 세이브 및 재저장하기 위하여 다음의 로드 및 저장 명령어를 제공한다.

rur/wur -- for access to reg_touched and reg_back

push_a -- copies regfile_a register 0 into reg_back

pop_a -- copies regfile_a register 0 from reg_back

s128b reg_a_register, reg_b_register -- stores the register file regfile_b into the address specified by regfile_a's register

l128b reg_a_register, reg_b_register -- loads the register file regfile_b from the address specified by regfile_a's register

s32a reg_a_register, reg_a_register -- stores the register file regfile_a into the address specified by regfile_a's register

l32a reg_a_register, reg_a_register -- loads the register file regfile_a into the address specified by regfile_a's register

이 경우, 상기 세이브 상태 종속성에 대한 DAG는 다음과 같이 생각된다.

reg_touched <-- regfile_a, regfile_b, reg_back

상기 코프로세서용 TIE는 이것을 이루기 때문에, reg_touched는 regfile_a, regfile_b 또는 reg_back이 터치되는 어느 때나 변할 것이다.

regfile_a <---- reg_back

regfile_a에서의 레지스터의 세이브는 regfile_a에서의 프리(free) 레지스터 를 요구하기 때문이다. regfile_a에서의 프리 레지스터를 얻기 위해서는, 레지스터의 값이 reg_back을 통하여 이동되어야 하는 것을 필요로 한다. 이는 reg_back의 현재 값을 소거(destroy)시킨다.

regfile_a <---- regfile_b

regfile_b를 위한 저장 명령어는, 그것에 저장하기 위한 주소로서 regfile_a에서의 레지스터를 사용하기 때문이다. 이는 regfile_b가 단지 한번만 저장될 수 있고, regfile_a는 이미 저장되어 있다는 것을 의미한다(실제적으로는, regfile_a에서 단지 하나의 레지스터만). 이는 상기 예시를 간단하게 하기 위하여 요약되어 있다.

또한, 세이브 시퀀스는 상기 상태가 적절한 순서로 세이브되도록 되어 있다. 이 경우, 순서는 다음과 같다.

reg_touched, reg_back, regfile_a, regfile_b

또한, 바람직한 실시예는 그 요소들이 내장 타입의 표준 프로그래밍 언어(예를 들면, C의 64+비트 또는 상술된 포화 산술)로 표현될 수 없는 레지스터 파일의 정의를 허용하기 때문에, 정의된 하드웨어를 일치시키도록 신규 타입을 추가하기 위한 메커니즘을 가질 필요가 있다. 프로그래밍 언어 타입들은 또한 어떤 레지스터 파일에 변수가 할당될 수 있는지를 결정하는데 유용하다.

예를 들어, 많은 ISA에 있어서 정수값은 하나의 레지스터 파일에 맵핑시키고, 부동소수점값은 또 다른 레지스터 파일에 맵핑시키는 것이 일반적인데, 그 이유는 정수 계산 명령어만이 정수 레지스터 파일에서 그 피연산자를 취하고, 부동소 수점 명령어만이 부동소수점 레지스터 파일에서 그 피연산자를 취하기 때문이다. 신규 데이터 타입을 생성할 수 있는 능력이 주어진다면, 내장 타입 및 신규 타입간, 그리고 상이한 신규 타입들간에 허용되는 변환을 특정화하는 메커니즘을 가지는 것이 바람직하다. 예를 들어, C 프로그래밍 언어에 있어서, char 타입 변수들과 short 타입 변수들간에 (char 타입을 부호 또는 제로-확장시킴으로써) 변환이 허용된다.

TIE 구성

ctype <tname> <size> <alignment> <rfname>

은 프로그래밍 언어 타입 <tname>을 생성하고, 그것을 메모리내의 <alignment> 비트 바운더리상에 정렬된 <size> 비트로 선언한다(상기 <alignment>는 <rfname>에 할당됨).

예를 들어, Galois-필드 산술 GF 유닛과 연결시키면, 문장

ctype gf8 8 8 gf

은 8비트 메모리 바운더리상에 정렬된 8비트 값을 갖는 "gf8"로 명명된 신규 타입(바람직한 실시예에서는 C 프로그래밍 언어용)을 선언하고, 이들 값들은 필요에 따라 "gf" 레지스터 파일에 레지스터 할당된다.

TIE 구성

proto <pname> {<ospec>, ...} {<tspec>, ...} {<inst> ...}

은 컴파일러가 내재 피연산자에 대한 타입 정보에 대하여 알아야 하거나 또는 타입 정보를 주어야 하는 다양한 함수들을 수행하는 명령어 시퀀스를 특정화시 키는데 사용된다. <ospec>은 피연산자 타입 명세이고, <tspec>은 명령어 시퀀스에 의하여 필요한 임시 레지스터 명세이며, <inst>는 시퀀스의 명령어이다.

<ospec>의 구문은

[in|out|inout] <typename> [*] <oname> 이고,

여기서 <oname>은 시퀀스의 명령어(<inst>)로 대체될 수 있는 피연산자 네임이고, <typename>은 피연산자의 타입 네임이다(선택적 애스터리스크가 주어진다면, 상기 타입에 대한 포인터).

임시 레지스터 명세 <tspec>의 구문은

<rfname> <oname> 이고,

여기서, <oname>은 시퀀스의 명령어(<inst>)로 대체될 수 있는 피연산자 네임이다. <typename>은 레지스터 파일로부터 <oname>이 상기 시퀀스를 위하여 임시적으로 할당되어야 하는 상기 레지스터 파일을 식별하는 타입 네임이다.

시퀀스의 명령어 <inst>의 구문은

<iname> [<oname>|<literal>], ... ; 이고,

여기서, <iname>은 명령어 네임이고, <oname>은 <ospec> 또는 <tspec> 중 어느 하나에 선언된 피연산자 네임이며, <literal>은 proto에 의하여 특정화된 명령어 시퀀스를 생성할 때 컴파일러에 의하여 변화되지 않으면서 사용되는 상수 또는 문자열(string)이다.

proto의 일 사용은 단순히 내재함수를 정의할 목적으로 명령어 피연산자와 타입을 결합(associate)시키는 것이다. 이 경우, <pname>은 명령어 네임이고, <ospec>은 iclass 피연산자 명세와 일치하며(typename들이 추가된 것은 제외함), <tspec> 리스트는 비어 있어야 하고, <inst> 시퀀스는 단일 명령어로 구성되어야 한다. 예를 들면 다음과 같다.

proto GFADD8 {out gf8 r, in gf8 s, in gf8 t} {} {

GFADD8 r, s, t;

}

proto의 또 다른 사용은 다수의 명령어 내재함수를 정의하는 것이다. 여기서, <tspec>은 비어있지 않을 수 있다. 예를 들면,

proto GFADDXSQ8 {out gf8 r, in gf8 s} {gf8 tmp} {

GFMULX8 tmp, s;

GFMULX8 r, tmp;

}

proto의 부가적인 사용은 ctype TIE 구성을 사용하여 선언된 프로그래밍 언어 타입의 값들을 로드 및 저장하는 법을 컴파일러에 지시하는 것이다. 앞서 논의된 바와 같이, 메모리로 또한 메모리로부터 로드 및 저장할 수 있는 것은, 컴파일러가 레지스터 할당을 수행하는 것과 레지스터 파일의 컨텐츠가 태스크 스위치에 세이브되고 재저장되도록 하는 것을 필요로 한다.

각각의 ctype <tname> 선언에 있어서, 다음과 같은 형태의 proto 선언이 되어야 한다.

proto <tname>_loadi

{ out <tname> <x>,

in <tname>* <y>,

in immediate <z> }

{ <tspec>, ...}

{

<inst>... // sequence of instructions that loads

// register <x> from the address <y>+<z>

}

proto <tname>_storei

{ in <tname> <x>,

in <tname>* <y>,

in immediate <z> }

{ <tspec>, ...}

{

<inst>... // sequence of instructions that stores

// register <x> from the address <y>+<z>

}

<tname>_loadi proto는 메모리로부터 레지스터로 타입 <tname>의 값을 로드하는데 사용되어야 하는 명령어 시퀀스를 컴파일러에게 알려준다. <tname>_storei proto는 레지스터로부터 메모리로 타입 <tname>의 값을 저장하는데 사용되어야 하 는 명령어 시퀀스를 컴파일러에게 알려준다.

앞서 기술된 바와 같이, 컴파일러는 한 레지스터로부터 다른 레지스터로 값을 이동시키는 법을 아는 것이 바람직하다. 로드 및 저장에 의하면, proto는 레지스터들간에 값을 이동시키는 법을 컴파일러에 지시하는데 사용된다. 각각의 ctype <tname> 선언에 있어서, 다음과 같은 형태의 proto 선언이 있을 수 있다.

proto <tname>_move

{ out <tname> <x>,

in <tname> <y> }

{ <tspec>, ...}

{

<inst>... // sequence of instructions that moves

// register <y> to register <x>

}

예를 들어, Galois-필드 산술 GF 유닛과 연결시키면, proto 선언

proto gf8_loadi {out gf8 t, in gf8* s, in immediate o} {} {

LGF8.I t, s, o ;

}

proto gf8_storei {in gf8 t, in gf8* s, in immediate o} {} {

SGF8. I t, s, o ;

}

proto gf8_move {out gf8 r, in gf8 s} {} {

GFADD8I r, s, 0 ;

}

은 바람직한 실시예에서 gf8 변수들의 레지스터 할당을 행하는 컴파일러를 구비하기 위한 소요 입력이고, 그들은 또한 gf 레지스터 파일을 위한 태스크 상태 스위치 시퀀스를 생성하기 위한 소요 입력일 수도 있다.

proto의 최종 사용은 내장 및 신규 타입간, 그리고 상이한 신규 타입간에 허용되는 변환을 정의하는 것이다. 변환 프로토타입들은 요구되지 않고, 예를 들어 신규 타입 A와 신규 타입 B간의 변환이 특정화되지 않는다면, 컴파일러는 타입 A의 변수가 타입 B의 변수로 변환되도록 하지 않는다. 각 쌍의 신규 또는 내장 타입 <t1name> 및 <t2name>에 있어서(많아야 그것 중의 하나가 내장 타입일 수 있고, 이러한 메커니즘은 2개의 내장 타입간의 변환 명세를 허용하지 않는데, 그 이유는 상기 변환은 이미 프로그래밍 언어에 의하여 정의되기 때문임), 다음과 같은 형태의 3개의 proto 선언이 될 수 있다.

proto <t1name>_rtor_<t2name>

{ out <t2name> <x>,

in <t1name> <y> }

{ <tspec>, ... }

{

<inst>... //sequence of instructions that converts

//type <t1name> in register <y> to type

// <t2name> in register <x>

}

proto <tlname >_rtom_<t2name>

{ in <t1name> <x>,

in <t2name>* <y>,

in immediate <z> }

{ <tspec>, ... }

{

<inst>... // sequence of instructions that stores

// type <t1name> in register <x> as

// type <t2name> at the address <y>+<z>

}

proto <t1name>_mtor_<t2name>

{ out <t2name> <x>,

in <t1name>* <y>,

in immediate <z> }

{ <tspec>, ... }

{

<inst>... // sequence of instructions that loads

// type <t1name> from the address <y>+<z>

// as type <t2name> into register <x>

}

예를 들어, Galois-필드 산술 GF 유닛과 연결시키면, proto 선언

proto gf8_rtom_char {in gf8 t, in char* s, in immediate o} {} {

SGF8.I t, s, o;

}

proto char_mtor_gf8 {out gf8 t, in char* s, in immediate o} {} {

LGF8.I t, s, o;
}

은 메모리내의 타입 char의 변수와 레지스터내의 타입 gf8의 변수간의 변환을 허용할 것이다. 이들 proto에 의하면, 다음의 예시는 char의 두 벡터들이 GFADD 내재함수를 사용하여 더해질 수 있는 법을 보여준다.

void

gfadd_vector (char *char_vector0, char *char_vector1, int size)

{

for (int i = 0 ; i < size ; i++) {

gf8 pO = char_vector0[i];

gf8 pl = char_vector1[i];

gf8 res = GFADD(pO, p1);

char_vector0[i] = res;

}

종래의 시스템(예를 들어, GNU C 컴파일러)에 있어서, 컴파일러들은 각 프로그램 변수 및 컴파일러-생성 임시 변수를 위한 타입 정보를 유지한다. 이들 내장 변수 타입들은 고레벨-언어 타입(예를 들면, C에서, char, short, int, float, double 등)에 대응한다. 각각의 내장 타입에 있어서, 컴파일러는 상기 타입의 네임, 상기 타입을 위한 사이즈와 정렬 요구사항 및 상기 타입의 값이 할당되어야 하는 레지스터 파일을 알아야 한다. 신규 타입에 있어서, 이러한 정보는 ctype 언어 구성에 의하여 제공된다. ctype 정보를 사용하여, 컴파일러는 상기 타입을 표현하기 위하여 내부 타입 구조를 생성하고, 내장 타입을 위하여 행해진 것과 동일한 방식으로 컴파일러-생성 임시 변수 및 프로그램 변수를 위하여 상기 타입을 사용한다.

종래의 GNU C 컴파일러는 열거된 타입 machine_mode를 사용하여 내부적으로 타입을 표현한다. 관련된 타입들은 열거된 타입 mode_class로 기술된 분류대로 함께 그룹화된다. 신규 타입을 지원하기 위하여, 당업자는 열거기(enumerator)를 mode_class에 추가시켜 사용자-정의 타입을 표현하는 타입의 분류(class)를 표현할 수 있고, ctype TIE 언어 구성을 사용하여 선언된 각각의 신규 타입을 위하여 하나의 열거기를 machine_mode에 추가시킬 수 있다. 예를 들어, 신규 타입을 표현하는 분류가 MODE_USER라 불린다고 가정하면, 파일 machmode.h에서 mode_class의 정의는 다음과 같이 된다.

enum mode_class {MODE_RANDOM, MODE_INT, MODE_FLOAT,

MODE_PARTIAL_INT, MODE_CC, MODE_COMPLEX_INT, MODE_COMPLEX_FLOAT,

MODE_USER, MAX_MODE_CLASS};

열거기들은 파일 machmode.def에 행들을 삽입시켜 machine_mode에 추가된다. 각각의 행은 신규 타입, 그 네임, 그 분류 및 그 사이즈(8비트 바이트로 주어짐)를 정의한다. 사용자-정의 타입을 위한 열거기들은 U<n>mode로 명명되며, 여기서 0<n>은 제로 및 사용자-정의 타입의 전체 수 사이의 숫자이다. 예를 들어, 앞선 예시로부터 사용자-정의 타입 gf8을 표현하도록 내부 타입을 추가하기 위하여, 다음의 행이 추가된다.

DEF_MACHMODE (UOmode, "UO", MODE_USER, 1, 1, VOIDmode)

그 후, 당업자는 MODE_USER 분류의 타입에 대하여 정확하게 수행하도록 GNU C 컴파일러에 의하여 적용된 분석 및 최적화를 수정할 수 있다.

종래의 컴파일러에 있어서, 코드 선택기(또는 코드 생성기)는 각각의 내부적으로 표현된 명령어를 위한 저레벨 명령어(어셈블리 명령어에 다소 대응됨)의 시퀀스를 대체시킬 책임이 있다. 코드 선택기는 내부 명령어에 의하여, 그리고 명령어에 대한 피연산자의 타입에 의하여 수행되는 연산을 검사하여 어떤 명령어 시퀀스가 대체될 수 있는지를 결정한다. 예를 들어, add를 나타내는 내부 명령어는 입력으로 타입 int의 2개의 값을 갖고, 출력으로 타입 int의 1개의 값을 가질 수 있거나 또는 입력으로 타입 float의 2개의 값을 갖고, 출력으로 타입 float의 1개의 값을 가질 수 있다. 입력 및 출력 값들의 타입을 토대로, 코드 선택기는 정수 덧셈을 수행하기 위한 명령어의 시퀀스 또는 부동소수점 덧셈을 수행하기 위한 명령어의 시퀀스 가운데 어느 하나를 선택한다. 사용자-정의 타입에 있어서, 로드, 저장, 이동 및 변환 proto 정의들은 사용자-정의 타입으로 1이상의 피연산자를 갖는 내부 명령어를 대체하기 위한 명령어 시퀀스를 기술한다. Galois-필드 산술 GF 유닛 예시와 연결시키면, 만일 내부 명령어가 gf8 값의 로드를 나타낸다면, 코드 선택기는 gf8_loadi proto를 참고하여 상기 명령어를 대체해야 하는 명령어 시퀀스를 결정한다.

종래의 GNU C 컴파일러에 있어서, 타겟 프로세서에서 이용가능한 명령어들은 명령어 패턴을 사용하여 기술된다(예를 들면, 더 많은 정보를 위하여 Stallman의 "Using and Porting GNU CC"(1995) 참조). 이들 명령어 패턴들은 피연산자의 개수 및 타입을 포함하는 명령어를 기술한다. 컴파일러에서 사용자-정의 타입을 지원하기 위하여, 로드, 저장, 이동 및 변환 proto는 컴파일러에 의하여 예상되는 명령어 패턴으로 변환된다. 예를 들어, gf8_load proto는 다음의 패턴으로 표현된다(gf8 ctype은 machine_mode 열거기 U0mode로 맵핑되었다고 가정).

(define_insn ""

[(set (match_operand:UO 0 "register_operand" "v")

(match_operand:UO 1 "memory_operand" "U"))]

""

"LGF8.I＼t%O, %1")

임시 레지스터를 특정화시키는 proto들은 적절한 타입의 피연산자를 겹쳐쓰 거나(overwrite) "클라버(clobber)"하는 명령어 패턴으로 변환된다. 컴파일러는 클라버된 피연산자가 명령어의 위치에서 사용되지 않도록 보장하여, 상기 명령어는 임시로 그것을 사용할 수 있다. 예를 들어, 사용자-정의 타입 tt를 위한 다음의 로드 proto는 클라버를 포함하는 명령어 패턴을 생성한다.

proto tt_loadi { out tt x, in tt* y, in immediate z } { char t }

{

L8UIt, y, z;

MVTTx, t;

}

(define_insn ""

[(parallel [(set (match_operand:UO 0 "register_operand" "v")

(match_operand:UO 1 "memory_operand" "U"))

(clobber (match_operand:UO 2 "register_operand" "a"))])]

""

"L8UI＼t%2, %1＼nMVTT＼t%0, %2")

내재 함수 선언

Killian 등의 출원에 있어서, GNU asm 문장을 사용하는 함수로서 모든 TIE 명령어의 정의를 포함하는 내재 함수 선언 파일이 생성된다. 특히, 각각의 명령어 함수는 달리 발생할 수 있는 최적화를 억제하도록 C volatile 특성으로 알맞게 된다. 이러한 방법은, 비록 안전하지만, TIE 명령어들이 안전하게 리오더(re-order) 를 받을 수 있는 소정의 컴파일러 최적화를 막는다. 본 발명은 종래의 시스템을 두가지 방식으로 개선시킨다. 첫째로, 단지 로드 및 저장 명령어들만이 휘발성으로 선언되므로, 코드 최적화시에 명령어들을 리오더링하도록 컴파일러에 최대 자유도(freedom)를 제공한다. 두번째 개선으로는, 특별한 상태 및 사용자-선언 상태를 사용하는 명령어들이 명시적 상태 인자(explicit state argument)로 선언되므로, 상기 명령어의 부작용(side effect)에 대한 더욱 정확한 정보를 컴파일러에 제공한다는 것이다. 다음의 헤더 파일은 내재 함수로서 GF 예시에서의 모든 명령어들을 선언하도록 TIE 컴파일러로부터 생성된다.

/* Do not modify. This is automatically generated. */

typedef int gf8_attribute_((user("gf8")));

#define GFADD8_ASM(gr, gs, gt) {＼

_asm_("gfadd8 %0, %1, %2" :"=v"(gr):"v"(gs),"v"(gt));＼

}

#define GFADD8I_ASM(gr, gs, imm4) {＼

_asm_("gfadd8i %0, %1, %2" : "=v"(gr):"v"(gs),"i"(imm4));＼

}

#define GFMULX8_ASM(gr, gs) {＼

register int _xt_state asm ("state"); ＼

_asm_("gfmulx8

%1, %2":"+t"(_xt_state),"=v"(gr):"v"(gs));＼

}

#define GFRWMOD8_ASM(gt) {＼

register int_xt_state asm ("state");＼

_asm_("gfrwmod8 %l":"+t"(_xt_state),"=v"(gt):"l"(gt));＼

}

#define LGF8_I_ASM(gt, ars, imm8) {＼

_asm_ ＼

volatile("lgf8_i %0, %1, %2":"=v"(gt):"a"(ars),"i"(imm8));＼

}

#define SGF8_I_ASM(gt, ars, imm8) {＼

_asm_ ＼

volatile("sgf8i %0, %1, %2"::"v"(gt),"a"(ars),"i"(imm8));＼

}

#define LGF8_IU_ASM(gt, ars, imm8) {＼

_asm_volatile("lgf8_iu %0,%1,%3" : ＼

삭제

"=v"(gt), "=a"(ars):"1"(ars), "i" (imm8)); ＼

}

#define SGF8_IU_ASM(gt, ars, imm8) {＼

_asm_volatile("sgf8_iu %1, %0, %3" : ＼

"=a" (ars) : "v" (gt), "0" (ars), "i" (imm8)); ＼

}

#define LGF8_X_ASM(gr, ars, art) {＼

_asm_volatile("lgf8_x %0, %1, %2" : ＼

"=v" (gr) : "a" (ars), "a" (art)); ＼

}

#define SGF8_X_ASM(gr, ars, art) {＼

_asm_volatile("sgf8_x %0, %1, %2" : : ＼

"v" (gr), "a" (ars), "a" (art)); ＼

}

#define LGF8_XU_ASM(gr, ars, art) {＼

_asm_volatile("lgf8_xu %0, %1, %3" : ＼

"=v" (gr), "=a" (ars) : "1" (ars), "a" (art)); ＼

}

#define SGF8_XU_ASM(gr, ars, art) {＼

_asm_volatile("sgf8_xu %1, %0, %3" : ＼

"=a" (ars) : "v" (gr), "0" (ars), "a" (art)); ＼

}

상기 샘플 출력에 있어서, GFADD8I와 같은 산술 명령어들은 휘발성으로 선언되지 않는다. LGF8_I와 같은 로드 및 저장 명령어들은 휘발성으로 선언된다. GFRWMOD8과 같은 프로세서 상태를 읽거나 쓰는 명령어들은, 상기 명령어들이 부작용을 갖는다는 것을 컴파일러에 시그널하기 위한 1이상의 인자_xt_state를 가진다.

레지스터 할당

종래의 시스템(예를 들어, GNU C 컴파일러)은 이식성(portability)을 위하여 설계된 레지스터 할당 알고리즘을 포함한다. 이식성은 컴파일러가 폭넓은 ISA를 지원하는 것을 요구한다. 이들 ISA들은 그들 자체가 구성가능하거나 확장가능하지 않더라도, 그들 중의 어느 것을 목적으로 삼아야 하는 컴파일러는 레지스터 할당에 대한 일반적인 접근법(generic approach)을 취해야 한다. 따라서, 종래의 시스템들은 다수의 레지스터 할당을 허용할 수 있고, 어떤 것은 소정의 레지스터 파일에 대한 프로그래밍 언어 타입을 제한할 수 있다.

종래의 GNU C 컴파일러는 타겟의 머신 기술(machine description)을 수정하여 임의의 개수의 레지스터 파일들이 특정화되도록 한다. 당업자는 "Using and Porting GNU CC"에 기술된 바와 같이 타겟을 위한 머신 기술을 수정하여 1이상의 신규 레지스터 파일을 위하여 GCC에 지원을 추가할 수 있다.

각각의 TIE regfile 구성에 있어서, 컴파일러는 레지스터 파일내의 레지스터에 값을 지정하기 위하여 자동으로 구성된다. regfile 구성은 레지스터 파일내의 레지스터의 수를 나타낸다. 상술된 바와 같이, TIE ctype 구성은 타입의 값들이 지정되어야 하는 레지스터 파일을 특정화시킨다. 컴파일러는, 사용자-정의 타입을 갖는 각각의 프로그램 값을 지정하도록 시도할 때, 상기 정보 뿐만 아니라 레지스터 파일내의 레지스터의 수를 사용한다.

Galois-필드 산술 GF 유닛 예시와 연결시키면, gf 레지스터를 위한 regfile 구성은

regfile gf 8 16 g

이다.

이는 각각 사이즈가 8비트인 16 gf 레지스터들이 있다는 것을 나타낸다. gf8 타입을 위한 ctype 구성은

ctype gf8 8 8 gf

이고, 이는 gf 레지스터 파일에 지정되어야 하는 타입 gf8의 값을 나타낸다. 따라서, 컴파일러는 타입 gf8의 모든 값들을 gf 레지스터 파일(16개의 레지스터를 가짐)에 할당할 것이다.

명령어 스케줄링

종래의 시스템(예를 들어, GNU C 컴파일러)들은 파이프라인 스톨을 감소시켜 성능을 향상시키기 위하여 명령어들을 리오더링하는 명령어 스케줄링 알고리즘을 포함한다. 이들 알고리즘은 최소 수의 스톨 사이클을 발생시키는 명령어 오더링을 결정하도록 타겟 프로세서의 파이프라인을 시뮬레이션하여 동작시키는 한편, 이슈 폭과 같은 기타의 파이프라인 제약조건 및 기능 유닛 이용성을 만족시킨다.

종래의 GNU C 컴파일러는, 임의의 쌍의 명령어를 위하여, 만일 하나의 명령어가 다른 것 다음에 즉시 스케줄링된다면 나타날 스톨 사이클의 수를 결정하여 프로세서의 파이프라인을 시뮬레이션한다. 각 명령어 쌍을 위한 스톨 정보를 토대로, 컴파일러는 전체 스톨 사이클을 최소화하는 명령어의 오더링을 찾도록 시도한다. 신규 TIE 명령어에 있어서, 컴파일러는 TIE 언어 스케줄 구성에 의하여 제공되는 정보를 사용하여 스톨 사이클을 결정한다. 명령어 B가 명령어 A 다음에 즉시 스케줄링된다면 발생할 스톨의 수를 결정하기 위하여, 컴파일러는 A의 각 출력 피연산자의 쓰기용 파이프라인 스테이지를 B의 각각의 대응하는 입력 피연산자의 읽기용 파이프라인 스테이지와 비교한다. 각 피연산자에 있어서, 이들 값들의 차이+1(정의된 피연산자 파이프라인 스테이지 값에 대한 스케줄 구성의 시맨틱 때문임)은 스톨을 피하기 위하여 A를 B와 분리시켜야 하는 최소 수의 사이클을 나타낸다. 1의 값은 B가 스톨없이 A 다음에 즉시 스케줄링될 수 있다는 것을 나타내고, 2의 값은 A 다음에 즉시 B를 스케줄링하는 것이 1 스톨 사이클을 야기할 것이라는 것 등을 나타낸다. A로 쓰여진 모든 피연산자에 걸친 최대 스톨 값은, B가 A 다음에 즉시 스케줄링된다면 나타날 스톨 사이클의 수이다.

다음의 예시를 살펴보면, 스케줄링 구성은 다음과 같다.

schedule aload { ALD }

{

use imm8 0;

use ars 1;

def xt 2;

}

schedule aadd { AADD }

{

use xa 1;

use xb 2;

def xc 2;

}

다음의 코드 시퀀스에 있어서, ALD 명령어의 xt 피연산자, x3은 AADD 명령어의 xa 피연산자와 동일하다. 따라서, AADD 명령어는 스톨을 피하기 위하여 ALD 다음에 (def xt)-(use xa)+1=2-1+1=2 사이클로 스케줄링되어야 한다. 만일 AADD가 ALD 다음에 즉시 스케줄링된다면, 1 사이클 스톨이 있게 된다.

ALD x3, a0, 0

AADD x0, x3, x1

다음의 코드 시퀀스에 있어서, ALD 명령어의 xt 피연산자, x3은 AADD 명령어의 xb 피연산자와 동일하다. 따라서, AADD 명령어는 스톨을 피하기 위하여 ALD 다음에 (def xt)-(use xb)+1=2-2+1=1 사이클로 스케줄링되어야 한다. 이 경우, AADD가 ALD 다음에 즉시 스케줄링된다면, 스톨이 없게 된다.

ALD x3, a0, 0

AADD x0, x1, x3

레이지 상태 스위치(Lazy State Switch)

레지스터 파일을 프로세서에 추가하는 것은, 대부분의 실시간 운영체제에 의하여 구현된 멀티-태스킹 환경의 태스크 스위칭의 부분으로서 세이브 및 재저장되어야 하는 상태의 양을 상당히 증가시킨다. 부가적인 상태는 종종 태스크의 서브셋 으로 수행되는 소정의 계산에 대하여 특정화되기 때문에, 이렇게 불필요하게 행해지는 것은 태스크 스위치 사이클 카운트를 증가시키므로, 매 태스크 스위치마다 상기 부가적인 상태를 세이브 및 재저장하는 것은 바람직하지 않다. 이는 또한 솔루션이 종래 기술분야에 존재하는 확장불가능한 프로세서에서 이슈일 수도 있다. 예를 들어, MIPS R2000 CPENABLE 비트는 하나의 태스크로부터 다른 태스크로 코프로세서 레지스터의 "레이지(lazy)" 스위칭을 고려한다. 바람직한 실시예는 레이지 스위칭을 프로세서 확장(TIE state 및 regfile 선언)을 통하여 생성되는 상태에 적용되도록 한다.

이는 세이브 및 재저장 연산의 가장 복잡한 것 중의 하나이다. 이는 몇가지 이유로 인하여 복잡하다. 문맥 스위치로부터 딜레이된 시간에 포인트에서 일어나고, 실행시간이 각각의 코프로세서 파일의 정당성(validity)을 관리해야 하며, 코어 자체는 예외 발생에 따라 코프로세서의 정당성이 변경된다.

이것이 취급될 수 있는 방법을 보여주기 위하여, 2개의 태스크, A 및 B를 가진 시스템이 있다고 가정하자. 또한 2개의 코프로세서 레지스터, cp_0 및 cp_1도 있다고 가정한다. 시스템의 상태는 코어에 의하여 유지되는 유효(valid) 비트 및 실행시간에 유지되는 레지스터 파일 오너 레코드(owner record)로 이루어진다. 그 다음, 아래의 표 1에 도시된 이벤트(event)의 시퀀스를 고려하자. 본 예시에서, 코프로세서 상태는 각 태스크의 스택(stack)의 베이스에 저장된다고 가정된다.

0 유효	1 유효	0 오너	1 오너	Event	Comment
x 1 0	x 1 0	x none none	x none none	초기화	코어는 미지의 상태로 상정된다. 우선, 시스템은 모든 레지스터 파일을 유효로 설정한다. 그 후, 각 파일에 대한 상태를 설정하도록 init 루틴을 호출한다. 초기화 끝에, 시스템은 사용을 위하여 모든 레지스터 파일을 무효로, 상기 레지스터에 대한 오너는 없다고 선언한다.

0 0 1 0 0 1

0 0 0 0 1 0

none none A A A A

none none none none B B

태스크 A 생성됨 태스크 B 생성됨 태스크 A가 cp_0을 사용함 태스크 B가 교체진입(swap in)함 태스크 B가 cp_1을 사용함 태스크 A가 교체진입함

태스크 A의 생성시, OS는 초기 재저장을 위한 "세이프"값으로 태스크 A의 스택의 베이스를 초기화하도록 init_mem 호출을 사용하는 것을 확보한다. 태스크 A의 스택 포인터는 세이브 영역 후에 시작하도록 설정된다. 코프로세서의 상태는 영향이 없다. 태스크 B의 생성은 태스크 A의 생성과 비슷하다. 레지스터 파일의 사용은 예외를 발생시킨다. 예외는 유효 비트를 설정한다. cp_0의 이전의 오너가 없었기 때문에, 데이터의 세이브가 수행되지 않는다. 태스크 A는 코프로세서를 액세스하기 때문에, 상기 코프로세서를 위한 태스크 A의 데이터는 cp_0으로 로드된다. cp_0의 오너십은 A에 지정된다. 교체진입 후, 실행시간은 cp_0 레지스터 파일에 A의 상태를 남겼다. 레지스터 파일은 무효로 마킹되었지만, A는 오너로서 남겨졌다. 위와 같이, A가 우선 cp_0을 사용하면, 예외는 유효 비트를 설정한다. 실행시간은 cp_1이 사전에 사용되지 않았으므로, 재저장을 행하지 않았다는 것을 보았다. 실행시간은 B의 상태를 cp_1로 로드하였고, cp_1의 오너를 B로 설정하였다. 상기 교체진입시에는 해야할 더많은 작업이 있다. 실행시간은, B가 교체방출되고, cp_1의 오너이기 때문에, cp_1에 대한 유효 비트를 클리어한다. A가 교체진입되는 것을 참조하면, cp_0에 대한 유효 비트를 설정한다. 태스크 A는 예외를 발생시키지 않고 cp_0를 사용할 수 있다.

1 1 0 0	0 1 1 1	A A A A	B A A B	태스크 A가 cp_0을 사용함 태스크 A가 cp_1을 사용함 태스크 B가 교체진입함 태스크 B가 cp_1을 사용함	이는 단지 본 프로세스의 일 구현이라는 것을 유의해야 한다. 모든 유효 비트가 턴 오프될 수 있고, A가 코프로세서를 터치하면, 실행시간은, 예외에서, A의 상태가 이미 cp_0으로 로드되고, 그 포인트에서 재저장을 피한다는 것을 인식할 수 있다. 예외는 유효 비트를 설정할 것이다. A의 상태는 이미 cp_0에 있기 때문에, 실행시간은 이미 문맥 스위치상에 유효 비트를 설정하고 있다. 유효 비트가 설정되어 있기 때문에, 예외가 발생하지 않고, 실행시간에 의하여 취해져야하는 액션이 없다. 태스크 A의 cp_1의 사용은 예외를 발생시킨다. 이 예외는 cp_1에 대한 유효 비트를 설정한다. 실행시간(태스크 B가 cp_1을 소유한 것을 참조)은 태스크 B의 스택에 cp_1의 컨텐츠를 세이브한다. 그 후, 태스크 A의 상태를 cp_1에 재저장한다. 태스크 A에 의하여 소유된 모든 유효 비트는 턴오프된다. 태스크 B에 의하여 소유된 코프로세서는 없고, 따라서 턴온되는 유효 비트가 없다. 태스크 B의 cp_1의 사용은 예외를 발생시킨다. 이 예외는 cp_1에 대한 유효 비트를 턴온시킨다. 실행시간은 태스크 A가 현재 cp_1을 소유하는 것과 태스크 A의 세이브 영역에 현 상태를 세이브하는 것을 참조한다. 그 후, 실행시간은 태스크 B의 상태를 cp_1에 재저장한다.
프로세싱 계속...

레이지 스위치 메커니즘은, 액세스가 가능하거나 불가능하게 될 수 있는 설정으로 상태가 그룹화되는 것을 요구하는데, 불가능한 상태로의 액세스는 예외를 발생시키고, 예외 핸들러(handler)는 어떤 상태가 스위칭되어야 하는지를 결정하고, 상기 예외 핸들러는 상기 상태 및 재인에이블(re-enable) 액세스를 메모리에 세이브하고, 상기 메모리로부터 재저장할 수 있다.

바람직한 실시예에서, TIE 구성

coprocessor <came> <cumber> { <sname>, ... }

은 <sname>,...으로 명명된 상태가 레이지 스위칭의 목적을 위한 그룹인 것을 선언한다. 이 그룹화는 네임 <came> 및 0 ~ 7 범위의 수 <cumber>가 제공된다. 만일 어떤 <sname>,...이 하나의 코프로세서 문장보다 많이 명명된다는 것은 에러이다.

상기 구조가 주어지면, iclass의 in/out/inout 리스트에 <sname>을 갖는 명령어의 리스트가 생성된다. 그 후, 이들 명령어를 위한 명령어 원-핫 디코드의 OR인 신호가 생성된다. 상기 신호는 CPENABLE 비트의 보수와 함께 AND된다. 그런 다음, 각 프로세서를 위하여 생성된 상기 신호들은 아래의 예외 섹션에서 더욱 상세하게 설명되는 TIE 소스 코드 생성 예외와 결합된다. 모든 코프로세서 디스에이블 예외(disabled exception)는 TIE 소스 코드로부터 어떤 예외보다도 높은 우선순위를 가진다. 코프로세서 디스에이블 예외간에는, 가장 적은 수의 예외가 우선순위를 가진다.

바람직한 실시예의 코어 프로세서에 있어서, 상이한 예외는 모두 동일한 벡터를 사용하고, 상기 예외에 의하여 EXCCAUSE 레지스터로 로드된 코드에 의하여 식별된다. 코어 프로세서에는 이들 예외를 위한 8개의 원인 코드(cause code)(32부터 39까지)가 저장되어 있다. 코프로세서 문장에 응답하여, TIE 컴파일러는 비트 <cumber>를 CPENABLE 레지스터에 더하고, 만일 <cumber>가 클리어되고 <sname>,...을 액세스하는 임의의 명령어가 실행된다면, 예외를 발생시키도록 로직을 프로세서 에 더하며, 상기 예외가 코어에 의하여 인식되는 경우에 EXCCAUSE 레지스터로 32+<cnumber>를 로드하도록 로직을 프로세서에 더한다.

TIE의 다중-사이클 명령어

종래의 프로세서 기술분야에 있어서, 다수 사이클의 계산을 요구하는 명령어들은, 상기 계산의 조합 논리(combinatorial logic)를 파이프라이닝하고, 이슈잉(issuing)으로부터의 아직 계산되지 않은(not-yet-computed) 결과에 따라 좌우되는 명령어를 방지하기 위한 부가적인 로직을 필요로 한다. 또한, 상기 프로세서용 컴파일러는 파이프라인 스톨을 최소화하기 위하여 명령어를 리오더링하도록 알고리즘을 포함해야 한다.

첫번째 아이템은 통상적으로, 조심스럽게 선택된 위치에 삽입되는 파이프라인 레지스터를 갖는 쓰기 로직에 의하여 프로세서 디자이너에 의해 구현된다. 두번째 아이템은 통상적으로, 이슈될 명령어의 소스 피연산자를 파이프라인의 아직 계산되지 않은 목적 피연산자 모두와 비교하고, 만일 일치한다면 명령어를 유지시킴으로써 구현된다.

이들 3개의 아이템은 대등(coordinate)하여야 한다. 계산 로직의 파이프라이닝이 이슈 로직에 대한 변경과 일치하지 않는다면, 프로세서는 틀린 결과를 만들어낼 수 있다. 파이프라인 스톨을 최소화하기 위한 리오더링(reordering)이 조합 로직을 파이프라이닝 하는 것과 일치하지 않는다면, 서브-최적 성능이 나올 것이다(예를 들어, 준비되기 전의 결과의 사용을 스케줄링하는 것은 파이프라인 스톨을 발생시킬 것이다).

다음과 같은 예시를 살펴보자.

MUL a3, a4, a5 /* a3 = a4 * a5, a 2-cycle instruction */

ADD a6, a3, a7 /* a6 = a3 + a7, a single cycle instruction */

SUB a2, aO, al /* a2 = aO - al, a single cycle instruction */

MUL 로직이 2 사이클에 걸쳐 수행되지만, 제어 로직이 매 사이클마다 하나의 명령어를 이슈한다면, a3은 ADD 명령어가 그것을 필요로 하는 바로 그 때에 정확한 값을 가지지 않기 때문에, a6은 정확하지 않은 결과를 가질 것이다. 보정을 위하여, 이슈 로직은 MUL이 2 스테이지에 걸쳐 파이프라이닝되고, ADD 명령어를 이슈하기 전에 1 사이클을 스톨시켜야 한다는 것을 알아야 한다. 1 사이클만큼 ADD 명령어를 스톨링하는 것이 보정 로직을 발생시킨다고 할지라도, 최적의 성능을 제공하는 것은 아니다. ADD 및 SUB 명령어의 순서를 바꿈으로써, 본 예시에서 어떠한 명령어를 스톨시키는 것이 더이상 필요하지 않고, 따라서 최적의 성능을 실현할 수 있다. 이는 단지 MUL 로직의 구현, 명령어 이슈 로직의 구현 및 명령어 리오더링(스케줄링) 사이의 적절한 코디네이션(coordination)에 의해서만 달성될 수 있다.

종래의 시스템에 있어서, 이들 3개의 아이템(파이프라인 로직, 파이프라인 스톨링 및 명령어 리스케줄링)은 종종 별도로 구현되어 코디네이션을 더욱 어렵게 하고 설계 검증 요구사항들을 증가시킨다. 본 발명의 바람직한 실시예는 이들 특징들이 요구되는 정보를 일단 명세화시키고, 이러한 명세로부터 프로세서 제너레이터에서 3개의 아이템을 구현하는 방법을 제공한다.

또한, 바람직한 실시예의 명령어 세트 시뮬레이터는 그 타이밍 모델에서 스 케줄링 정보의 동일한 명세를 사용한다. 이는 바람직한 실시예의 모든 특징을 사용하는 어플리케이션 개발자로 하여금 저속의 HDL 시뮬레이터상에서 그 어플리케이션을 실행하지 않고도 하드웨어가 구성되기 전의 성능에 대한 좋은 예측을 얻도록 한다.

본 명세서에서 참고자료로 채택되는 Killian 및 Warthman에 의한 Xtensa^TM Instruction Set Architecture(ISA) Reference Manual의 제10장에는, 파이프라인 스톨을 최소화하기 위하여 종래의 기술에 사용된, 프로세서 파이프라인의 성능을 모델링하는데 사용된 파이프라인 하드웨어를 기술하는 방법을 개시되어 있다. 하지만, 바람직한 실시예에 있어서, 상기 기술은 상기 첫번째 2개의 아이템에 부가적으로 사용된다.

특히, TIE 언어는 현재 다음과 같은 선언을 포함한다.

schedule <schedulename> { <iname>, ... }

in <oname> <stage>;

.

out <oname> <stage>;

.

}

여기서, <iname>은 명령어의 네임이고, <oname>은 피연산자 또는 상태 네임이며, <stage>는 파이프라인 스테이지를 나타내는 서열(ordinal)이다.

TIE에 의하여 사용된 def 스테이지 수는 Killian 및 Warthman에 의한 Xtensa^TM Instruction Set Architecture(ISA) Reference Manual의 제10장에 기술된 값보다 하나 적으므로, 명령어간의 구분(separation)은 max(SA-SB,0) 대신에 max(SA-SB+1,0)이다.

이러한 명세를 토대로, Killian 등 및 Wilson 등의 출원에 기술된 TIE 컴파일러는 다음과 같이 시맨틱 로직 명세로 파이프라인 레지스터를 삽입하기 위하여 확장된다. 스테이지 수가 시맨틱 블록에 대한 모든 입력에 지정된다. 명령어 디코드 신호 및 직접 피연산자에는 구현-특정 수(implementation-specific number)(바람직한 실시예에서는 0)가 지정된다. 레지스터 소스 피연산자, 상태 레지스터 및 인터페이스 신호(후술함)에는 TIE 스케줄 선언으로부터 스테이지 수(구현-특정 디폴트 -- 바람직한 실시예에서는 1 개임)가 지정된다. 다음으로, 시맨틱 블록의 각 노드는 포스트오더(postorder)로(즉, 선행 노드 각각이 방문된 후) 방문된다. 노드 NS의 스테이지 수는 그 입력의 임의의 최대 스테이지 수이다. 스테이지 수 IS<NS를 갖는 각 입력에 있어서, 컴파일러는 입력과 노드 사이에 NS-IS 파이프라인 레지스터를 삽입한다. 최종적으로, 출력 레지스터 피연산자, 상태 레지스터 및 인터페이스 신호들이 방문된다. 만일 시맨틱 블록으로부터의 스테이지 수 IS가 스케줄 문장에 선언된 스테이지 수 OS보다 크면, 입력 TIE 명세는 에러가 난다. 반대로, OS > IS 이면, 그 출력 전에 OS-IS 파이프라인 레지스터를 삽입시킨다.

이 프로세스는 다음과 같은 예시로 도시된다.

state sl 1

state s2 32

state s3 32

iclass complex {example} {out arr, in ars, in art} {in sl, in

s2, in s3}

semantic complex {example} {

wire [31 : 0] temp1 = s1 ? ars : art ;

wire [31 : 0] temp2 = s2 - temp1 ;

assign arr = s3 + temp2 ;

}

schedule complex {example} {

in ars 1 ; /* using operand ars in stage 1 */

in art 1 ; /* using operand art in stage 1 */

in s1 2 ; /* using state sl in stage 2 */

in s2 2 ; /* using state s2 in stage 2 */

in s3 1 ; /* using state s3 in stage 1 */

out arr 3 ; /* defining operand arr in stage 3 */

}

본 예시는 명령어 "example"이 스테이지 1에서 피연산자 ars, art 및 상태 s3 그리고 스테이지 2에서 상태 s1 및 s2를 사용하는 것을 특정화한다. 스테이지 3에서는 결과 피연산자 arr을 만들어낸다. 이러한 기술에 있어서, 상기 레지스터-삽입 프로시저는 도 8a의 회로를 만들어낼 것이다. 노드 "?"의 NS는 최대 입력 스테이지가 2이기 때문에 2이다. ars 및 art의 IS는 1이기 때문에, 하나의 레지스터가 노드 "?"의 각 입력에 삽입된다. 노드 "+"에도 유사하게, s3 입력이 1 스테이지만큼 딜레이되어 다른 입력과 일치하게 된다. 최종적으로, 노드 "+"의 출력은 arr에 지정되기 전에 1 스테이지만큼 딜레이된다. 상기 예시의 스케줄 기술에서 arr이 "out arr 1"로 선언된다면, 파이프라인 삽입 프로시저는 도 8b의 회로를 만들어낼 것이다. 노드 "+"의 NS가 2이고, arr의 OS가 1이기 때문에, 프로시저는 입력 스케줄 요구사항이 충족되지 않으므로 에러 메시지를 이슈할 것이다.

상기 알고리즘은 필요에 따라 파이프라인 레지스터를 정확하게 삽입하지만, 이들 레지스터의 배치(placement)는 최적과는 거리가 멀다. 합성(synthesis)을 위한 수용가능한 로직을 생성하도록 초기 삽입 후, Synopsys의 DesignCompiler에 갖추어진 것과 같은 파이프라인 레지스터 최적화 알고리즘을 사용하는 것이 필요하다. 이는 통상적으로, 레지스터의 양 쪽의 로직 딜레이를 밸런싱하도록 레지스터를 조합 로직을 가로질러 이동시킴으로써 행해진다. 상기 예시를 사용하여, 레지스터 최적화는, 딜레이를 밸런싱하고 사이클 타임을 단축시키기 위하여 노드 "+"의 출력 에서의 레지스터가 입력으로 이동되는 도 8c의 것과 같은 회로를 만들어낼 것이다.

어떤 경우에는, 2개의 명령어가 소정의 공통 로직을 공유할 수 있기 때문에, 하나의 명령어에 대하여 하나의 파이프라인 스테이지에서, 또한 상이한 명령어에 대하여는 또 다른 스테이지에서, 레지스터 피연산자를 사용하거나 정의하는 시맨틱 블록을 가지는 것이 바람직할 수 있다. 2개의 별도 시맨틱 블록에서 명령어를 특정화하는 것은 로직의 불필요한 중복(duplication)을 필요로 할 것이다.

이는 바람직한 실시예에서 변경함으로써 가능한 확장이다. 이러한 능력은, 예를 들어 단지 <operand> 대신에 <operand>@<stage>의 2개의 피연산자를 위한 시맨틱 블록에서 별도의 신호 네임들을 사용하여 지원될 것이다. 일단 이러한 수정이 이루어지면, 상기 알고리즘은 멀티-시스템 환경에서도 정확하게 동작한다.

예를 들어, 만일 다음과 같은 2개의 명령어를 가지도록 원한다면,

inst1: arr = ars + art

inst2: arr = ars +art + s1

여러 이유로 인하여, s1은 스테이지 1 입력이어야 하고, 사이클 타임 요구사항은 한 사이클에 하나의 덧셈만을 수행하도록 하는 오직 그 시간이 되도록 한다. 상술된 확장을 이용하여, 시맨틱 기술은 다음과 같을 수 있다.

semantic two {instl, inst2} {

wire [31 : 0] temp = ars + (inst1 ? art : s1) ;

assign arr = temp ;

assign arr@2 = temp + art@2 ;

}

확장된 신호 네임 ars@2 및 art@2를 갖는 단일 시맨틱 블록에 2개의 명령어를 기술함으로써, 상기 2개의 명령어는 2개의 별도 시맨틱 블록에 기술될 2개의 명령어를 가진 2개(3개 대신)의 가산기만으로 구현될 수 있다.

예외

대부분의 프로세서들은 완료(completing) 대신에 예외를 조건적으로 발생시키기 위하여 명령어에 대한 소정의 메커니즘을 가진다. 예를 들어, divide 명령어는 젯수가 제로인 경우에 예외를 발생시킬 수 있다. 본 발명의 바람직한 실시예는 먼저 다음과 같은 신규 예외를 선언하여 TIE로부터 상기 능력을 지원한다.

exception <ename> <exceptioncode> { <exc1>, ... } <string>

여기서, <ename>은 명령어의 네임이고 그것을 올리기 위하여 시맨틱 블록에 사용된 신호이며; <exceptoncode>는 다른 것으로부터 상기 예외를 식별하도록 소프트웨어 예외 핸들러로 패스된 값이고; <exc1> 등은 낮은 우선순위의 예외이며; <string>은 문서화에 사용될 기술 문자열(descriptive string)이다.

일단 선언되면, 예외 신호는 상술된 바와 같이 iclass 선언에 리스트될 수 있다. 이러한 선언에 의하면, 예외의 네임을 갖는 단일-비트 신호는 정의된 명령어를 포함하는 시맨틱 TIE 블록내에 생성되고, 상기 신호는 지정되어야 한다. 도 9는 하나 보다 많은 것이 단일 명령어에 의하여 시그널링되는 경우, 예외들간에 우선순위화시키고, 다수의 TIE 블록으로부터 예외 신호를 결합시키기 위하여, TIE 컴파일러에 의하여 생성된 로직을 보여준다.

예외 신호는 또한 스케줄 선언에서 스테이지 수가 주어질 수도 있다. 하지만, 바람직한 실시예에서, 코어 프로세서는 그 M 파이프라인 스테이지에서 모든 예외를 프로세싱한다. 이러한 구현에 있어서, 스케줄 선언에 의하여 특정화된 스테이지 수는, 만일 에러가 컴파일 시간에 시그널링되지 않는다면, M-스테이지의 스테이지 수와 같거나 적은 것이 확보되도록 체크된다. 만일 특정화된 스테이지 수가 M-스테이지의 스테이지 수와 같거나 적다면, M-스테이지의 스테이지 수가 대신 사용된다. 따라서, 도 9의 로직은 M-스테이지에서 평가(evaluate)된다.

도 9에 도시된 바와 같이, 각 시맨틱 블록에 의하여 생성된 예외 신호는 그 인터페이스 섹션에서 예외 신호를 선언하는 원-핫 명령어 디코드 신호의 OR과 함께 AND된다(이는 TIE 코드로 하여금, 상기 예외를 올리는 명령어들이 실행될 때, 유효 예외 신호만을 생성하도록 한다). 다음으로, 모든 예외 신호들은 소정의 예외가 발생하는 것을 나타내는 단일 신호를 생성하도록 OR된다. 이 신호는 종래의 기술분야에서와 같이 코어에 의하여 프로세싱된다.

최종적으로, 우선순위 인코더는 어떤 예외 코드가 코어 프로세서의 EXCCAUSE 레지스터내에 쓰여질 것인지를 결정하는데 사용된다. 더 낮은 우선순위 예외의 리스트는 방향성 그래프를 형성하는데 사용된다(만일 사이클이 검출되면, 컴파일-타임 에러가 고려된다). 본 그래프의 위상 정렬(topological sort)이 이루어지고(예를 들면, Unix tsort 프로그램에서와 같이), 그 결과인 오더는 다양한 예외 신호의 우선순위 인코드를 행하는데 사용된다. 그 후, 우선순위 인코드의 결과는 먹스에서 대응하는 예외 코드를 선택하는데 사용된다. 그런 다음, 상기 신호는 종래의 기술 에서와 같이 코어에 의하여 프로세싱된다.

예시로서, 도 9는 사이클 N에서 모두 일어나는 3개의 우선순위화된 예외 신호의 다음과 같은 TIE 기술을 위한 로직을 보여준다.

iclass i1 {inst1} {...} {...} {out exc1}

iclass i2 {inst2} {...} {...} {out exc2}

iclass i3 {inst3} {...} {...} {out exc3}

iclass i4 {inst4} {...} {...} {out exc1}

exception <exc1> <exccode1> {} "Low level exception

condition"

exception <exc2> <exccode2> {exc1} "Medium level exception

condition"

exception <exc3> <exccode3> {exc2} "High level exception

condition"

schedule sl {instl} { def exc1 1; }

schedule s2 {inst2} { def exc2 3; }

schedule s3 {inst3} { def exc3 2; }

schedule s4 {inst4} { def exc1 3; }

이 경우, 예외 exc1은 C1에서 inst1에 의하여 또한 C3에서 inst4에 의하여 올려질 수 있고, 예외 exc2는 C3에서 inst2에 의하여, 예외 exc3는 C2에서 inst3에 의하여 올려질 수 있다. 본 실시예에서, 모든 예외 신호들은 그 선언된 스테이지에 서 생성되고, 예외 원인값(cause value)이 상기 TIE 기술에서 특정화된 예외 신호의 우선순위에 의하여 예외 코드를 선택하여 계산되는 어떤 포인트에서 커밋 스테이지에 대하여 파이프라이닝된다. 예외 신호 Exception 및 원인 신호 ExcCause는 코어에 전달된다. 일단 예외가 핸들링되면, 코어는 TIE 로직으로 되돌아가는 신호를 이슈하여, 파이프라인에서 모든 명령어를 제거(kill)하고, 남아있는 핸들링되지 않은 예외들을 효과적으로 클리어할 것이다.

또 다른 예시로서, 도 10은 2개의 예외 및 하나의 예외를 생성하는 소정의 명령어와 양자 모두를 생성하는 명령어를 갖는 코드에 의하여 기술된 회로를 보여준다. 본 예시에 있어서, Overflow는 Zero에 의한 Divide보다 더 낮은 우선순위이다(실제로, 양자 모두는 divide에 있어서 동일한 시간에 일어날 수 없으므로, 해당 우선순위는 관련이 없다).

도면에서, 각각의 도시된 시맨틱 블록은 TIE 예외의 전체 세트의 소정의 서브셋을 생성한다는 것을 유의해야 하고, 따라서 정확한 배선(wiring)은 입력-의존형이다. 또한, 시맨틱 블록에서, 예외 출력들은 TIE 스케줄 메커니즘에 의하여 레졸루션(resolution) 스테이지로 파이프라이닝된다.

exception Overflow 40 {} "Integer Overflow"

exception DivZero 41 {Overflow} "Integer Divide by Zero"

iclass ov {ADDO, SUBO, MULO, DIVO} {out arr, ars, art}

{out Overflow}

reference ADDO {

wire [32 : 0] t = {ars[31], ars} + {art[31], art};

assign Overflow = t[32] != t[31];

assign arr = t[31 : 0];

}

reference SUBO {

wire [32 : 0] t = {ars[31], ars} - {art[31], art};

assign Overflow = t[32] != t[31];

assign arr = t[31 : 0];

}

reference MULO {

wire [63 : 0] t = {{32{ars[31]}, ars} * {{32{art[31]}, art};

assign Overflow = t[63 : 32] != {32{t[31]}};

assign arr = t[31 : 0];

}

semantic {ADDO, SUBO} {

wire [32 : 0] t = {ars[31], ars} + ({ars[31], art} ^

{{33}SUBO}) + SUBO;

assign Overflow = t[32] != t[31];

assign arr = t[31 : 0];

}

semantic {DIVO} {

assign DivZero = art == 32'bO;

assign Overflow = (ars == 32'h80000000) & (art==

32'hffffffff);

assign arr = ...;

}

도 10은 모든 TIE 예외들이 모든 코어 예외에 대하여 단일 고정 우선순위를 갖는 형태를 보여준다. 스트레이트포워드(straightforward) 확장은 TIE 예외 문장이 다양한 코어 예외에 대하여 명시적으로 참조하도록 할 것이다. 그 후, TIE 컴파일러는 TIE 및 코어 예외를 결합하는 우선순위 인코더를 생성할 수 있을 것이다.

참조 시맨틱(Reference Semantics)

Killian 등 및 Wilson 등의 출원에 기술된 바와 같은 시스템은 각 명령어의 단일 시맨틱 정의를 가진다. 이러한 시맨틱 정의는 명령어를 표현하는 하드웨어와 소프트웨어 양자 모두를 생성하는데 사용되었다. 이러한 시스템들은 원-핫 명령어 디코드 입력 신호에 의하여 구별되고, 다수의 명령어가 함께 정의되도록 되어 있었다(예를 들면, ADD 및 Subtract 명령어들이 가산기를 공유할 수 있다). 이러한 특징을 사용하는 것은 효율적인 하드웨어를 생성하는 것이 요구된다. 바람직한 실시예로 정의될 수 있는 명령어의 복잡성을 증가시킴으로써, 구현 시맨틱의 효율적인 세트는 읽기, 쓰기, 검증 및 이해가 더욱 어려워진다. 그들은 또한 파이프라이닝을 위하여 더욱 조정(tune)되어지고, 덜 추상적이게 된다. 이는 상기 기술이 파이프라인 효과를 고려하여, 파이프라인 레지스터들이 이동될 수 있는 신호를 생성해야 하기 때문이다.

예를 들어, TIE에서 부동소수점 구현이 주어지면, 아마도 3 또는 4-사이클 부동소수점 덧셈 연산에 대조되는 2-사이클 부동소수점 덧셈 연산을 목적으로 삼는 상이한 코드를 기록할 것이다. 프로그래머는 종종 명료성(clarity)을 희생하여 더 적은 게이트를 생성하도록 코드를 최적화하기 때문에 덜 추상적이다. 예를 들어, 참조 시맨틱에서 assign x = y * 3; 로 쓸 수 있지만(매우 명료함), 소프트웨어 개발 툴들은 수동으로 행해질 수 있는 케이스 등 뿐만 아니라 상수의 곱셈을 취급하지 않기 때문에 구현 시맨틱에서 assign x = y + {y[30:0], 1'b0}; 라고 쓸 수 있다.

또 다른 예시로서, 참조에서 곱셈-누적 명령어를 기술하는 것은, 다음과 같이 간단하다.

acc = a * b + acc;

그러나, 시맨틱 기술에 있어서, 상기 명령어는 2개의 파이프라인 스테이지에 걸쳐 구현되어야 한다는 것을 고려하여야 한다. 숙련된 하드웨어 디자이너는 a * b의 부분 결과가 제1스테이지에서 캐리-세이브-가산기 트리를 사용하여 계산되어야 하고, 상기 2개의 부분 결과를 acc와 더하는 것의 최종 결과는 제2스테이지에서 계산된다는 것을 알 것이다.

최종적으로, 구현 시맨틱은 원시(native) 머신 명령어에 대한 대응(correspondence)이 헛되이 되기 때문에, 소프트웨어를 시뮬레이션하도록 번역될 때 더 느려진다. 이전의 명령어를 사용하면, 참조 기술은 2개의 명령어를 사용하여 시뮬레이션될 수 있다. 이 경우에 있어 시맨틱 기술을 시뮬레이션하는 것은 수 백개의 명령어를 취할 것이다.

이와 같은 이유로 인하여, 바람직한 실시예는 2 세트의 시맨틱의 명세를 허용한다. 한 세트는 참조 시맨틱이라 불린다. 명령어 당 하나의 참조 시맨틱이 있고, 명령어들 사이에는 시맨틱의 공유가 없다. 이러한 시맨틱 정의는 일반적으로 명령어의 예상된 연산을 정의하도록 명료하게 쓰여진다. 시맨틱의 두번째 세트, 구현 시맨틱은 하드웨어 구현을 위한 것이다. 이들 시맨틱은 종래 시스템의 특징들을 보유하여, 하드웨어가 다수의 명령어에 의하여 공유되도록 하고, 일반적으로 게이트-레벨 합성으로 더 낮은 레벨로 쓰여질 것이다.

이는 다음과 같이 2개의 명령어 ADD 및 SUB를 정의하는 간단한 TIE 예시로 도시될 수 있다.

iclass rrr {ADD, SUB} {out arr, in ars, in art}

iclass rr {NEG} {out arr, in ars}

reference ADD {

assign arr = ars + art;

}

reference SUB {

assign arr = ars - art;

}

reference NEG {

assign arr = -ars;

}

semantic alu {ADD, SUB, NEG} {

wire [31 : 0] 1, r;

assign 1 = SUB ? ~art : NEG ? ~ars : art;

assign c = (SUB | NEG) ? 1 : 0;

assign r = NEG ? 0 : ars;

assign arr = 1 + r + c;

}

참조 기술들은 간단하고 직접적이다. 하지만, 시맨틱 기술은 그 자체가 구현 효율성을 고려하여야 하는데, 상세하게는 이 경우에 3개의 명령어에 의하여 요구되는 가산기를 공유하여야 한다. 이렇게 함으로써, 수를 뺄셈하는 것은 비트별로 보수된 수와 상수 1을 더하는 것과 같다는 수학적 동치(identity)에 의존한다.

참조 시맨틱은 또한 명령어 세트가 참조 시맨틱을 통하여 한번 정의되도록 한 다음, 구현 시맨틱의 상이한 세트로 여러번 구현된다. 다수의 구현으로 단일 ISA 정의를 가진다는 것은 산업상 흔한 일이지만, 일반적으로 참조 시맨틱들은 공식적인 방법 대신에 ISA 문서화에서만 정의된다. 바람직한 실시예는 이러한 전형적인 프로시저를 반전시켜, 공식적으로 참조 시맨틱을 정의하고, 그 반대 보다는 오 히려 TIE 명세로부터 문서화를 도출한다.

별도의 참조 및 구현 시맨틱을 가진다는 것은 그 등가(equivalence)를 검증할 필요가 있게 한다. 종래의 시스템에 있어서, 문서화의 참조 시맨틱에 의하면, 사람이 문서를 읽고 등가를 검증하기 위하여 테스트를 기록함으로써 등가가 체크된다. 이러한 프로시저는 시간 소모형이고, 정교한 언어로 특정화된 참조 시맨틱에 의하면, 상기 참조 시맨틱을 구현 시맨틱과 비교하도록 로직 등가 툴을 사용하는 것이 가능하다. 바람직한 실시예는 두가지 상이한 방식(특정 명령어를 위한 구현 시맨틱 및 참조의 등가를 체크하는 방식과 참조 시맨틱을 사용하여 구현된 전체 회로가 구현 시맨틱을 사용하여 구현된 것과 등가인지를 체크하는 방식)으로 등가 체크 툴에 필요한 입력들을 생성시켜 상기 프로세스를 자동화한다. 첫번째 방법은 구현 시맨틱 기술을 디버깅하는데 도움을 준다. 두번째 방법은 시맨틱에 의하여 특정화된 로직 뿐만 아니라 모든 시맨틱을 조합하기 위한 글루(glue) 로직도 포함하는 전체로서 설계를 검증한다.

참조 및 구현 시맨틱으로부터 생성된 회로들은 일반적으로 등가적이지 않다. 주어진 명령어에 있어서, 출력 신호의 서브셋만이 설정될 것이다. 출력 신호의 나머지에 있어서, 참조 및 구현 시맨틱들은, 그들이 논리적으로 "don't cares", 즉 사용되지 않기 때문에, 비용 기준 또는 기술의 용이성을 토대로 상이한 값들을 지정하도록 선택할 것이다. 바람직한 실시예는, 도 11에 도시된 바와 같이, 특정 명령어에 의하여 생성된 출력 신호들이 변경되지 않고, 출력 신호의 나머지가 0과 같은 특정 논리값으로 강제되도록 부가적인 논리를 만듦으로써 이러한 문제를 해결한 다. 본 도면은 참조 기술(x_ref)에 의하여 생성된 각 출력 신호 x 및 시맨틱 기술(x_imp1)에 의하여 생성된 각 출력 신호는 또 다른 신호 ignore_x와 함께 AND되어, x가 명령어 출력의 부분이 아닌 경우에 그것이 0으로 강제되므로, 등가 체크 툴로부터 나온 거짓 네거티브(false negative)를 피할 수 있다는 것을 보여준다. ICLASS 문장으로부터, x를 설정하는 명령어 세트를 알고, 따라서 ignore_x는 x를 설정하지 않는 명령어의 간단한 논리적 OR이다.

내장 모듈(Built-In Modules)

상용으로 사용되는 소정의 계산들은 언어-정의 연산자가 없다. 하지만, 다른 언어 구성들을 사용하는 것은 기술하는데 있어 매우 장황하거나 또는 효율적으로 구현하는 것이 매우 어렵다. Tie는 이들 소정의 계산을 위하여 아래의 표 2에 도시된 내장 연산자를 제공한다.

포맷	기술	결과 정의
TIEmul(a, b, sign)	사인 및 언사인 곱셈	{{m{a[n-1]&s}}* {{n{a[m-1]&s}},b}, 여기서 n은 a의 사이즈이고, m은 b 의 사이즈이다.
TIEmac(a, b, c, sign, negate)	곱셈-누적	n ? c - a * b : c + a * b
TIEadd(a, b, cin)	캐리-인을 갖는 덧셈	a + b + cin
TIEcsa(a, b, c)	캐리-세이브 가산기	{a&b\|a&c\|b&c,a＾b＾c}

예시로서, 다음과 같은 기술은 ADD 및 SUB 명령어 사이에서 가산기를 공유한다.

assign arr = TIEadd(ars, SUB ? ~art : art, SUB);

다음과 같은 시맨틱 기술은 전가산기(full adder)가 뒤따르는 캐리-세이브 가산기(CSA) 어레이를 사용하여 4개의 수를 더한다.

wire [31 : 0] sl, cl, s2, c2;

assign {sl, cl} = TIEcsa(dl, d2, d3);

assign {s2, c2} = TIEcsa (cl << 1, sl, d4);

assign sum = (c2 << 1) + s2;

이러한 내장 모듈을 사용하는 장점은, TIE 컴파일러가 내장 모듈들을 인식하고, 모듈 제너레이터를 사용할 수 있어서, 그들을 위한 더욱 효율적인 구현을 이끌어낼 수 있다는 것이다.

문서화(Documentation)

참조 시맨틱은 또한 명령어 세트 문서화의 하나의 중요한 요소이다. 전형적인 명령어 세트 참조 메뉴얼(도 12에 도시된 것의 예시적인 페이지)은 각각의 명령어를 위한 그 머신 코드 포맷; 그 패키지; 그 어셈블러 구문; 시놉시스(명령어의 1행 텍스트 기술); 명령어의 전체 텍스트 기술; 및 명령어의 더욱 정교한 연산 정의 뿐만 아니라, 명령어와 관련된 예외 및 어셈블러 노트(note)와 같은 부가적인 정보를 포함할 수 있다. 머신 코드 포맷을 생성할 필요가 있는 모든 정보는 이미 TIE 명세에서 발견되는데, 그 이유는 그것이 연산코드 비트 및 피연산자 필드를 포함하기 때문이다. 이와 유사하게, 어셈블러 구문은 의사기호 및 피연산자 네임으로부터 도출된다. TIE 참조 시맨틱은 정교한 정의가 된다. 단지 시놉시스 및 텍스트 기술만이 미스(missing)된다. 따라서, 바람직한 실시예는 구성들을 TIE에 더하여, 명령어 세트 디자이너가 시놉시스 및 텍스트 기술을 특정화하도록 한다.

TIE package 명세는 다음과 같은 포맷을 가진다.

package <pname> <string>

.

endpackage <pname>

상기 패키지 네임 <pname>은 package와 endpackage 사이에 정의된 모든 명령어와 관련된다. 패키지는 후술하는 바와 같이 문서화를 위한 것 이외에 여타의 사용들을 가진다. <string> 파라미터는 문서화 목적을 위하여 package의 네임을 제공한다(그것은 스페이스를 가질 수 있다).

TIE synopsis 명세는 다음과 같은 포맷을 가진다.

synopsis <iname> <string>

여기서, <string>은 명령어의 쇼트(대략 한 행의 1/2) 기술이다. 포맷 제어는 상기 텍스트에서 요구되지 않는다. 본 텍스트는 통상적으로 북(book)의 표제(heading) 및 명령어 리스트의 부가적인 소재(material)에 사용된다.

TIE description 명세는 다음과 같은 포맷을 가진다.

description <iname> <string>

여기서, <string>은 영어나 또 다른 자연 언어로 명령어의 연산을 기술하는 텍스트를 포함하는 긴(보통 수 개의 문단) 문자열이다. 본 텍스트에서는 텍스트 포맷 명령(command)을 위하여 필요하다. 바람직한 실시예는 HTML형 언어(HTML용 명세 는, 예를 들면 http://www.w3.org/TR/REC-html40에서 찾을 수 있다)를 구현한다. 또한, 2개의 선택적 문서화 문자열이 지원된다.

assembly_note <iname> <string>

implementation_note <iname> <string>

이들 선택적 명세들은 부가적인 per-명령어 텍스트를 제공한다.

HTML과 같이, 포맷 제어의 두가지 소트들이 지원된다 : 요소 및 문자 엔티티(character entity). 의도는 데이터의 속성(그 정확한 외관(appearance)이 아닌)을 특정화하는 것이다. 상기 데이터는 그 속성을 토대로 출력 매체에 적합하게 렌더링될 것이다. 문자 엔티티 &<name>; 은 ASCII에서 이용할 수 없는 문자들을 특정화하거나 또는 특별한 렌더링을 사용해야 한다. Elements는 문단, 리스트, 코드 예시 등과 같은 HTML-정의 엔티티를 표현한다. HTML 4.0 명세로부터의 인용(quoting)은 "[e]ach element type declaration describes three parts : a start tag, content, and an end tag. The element's name appears in the start tag(written <ELEMENT-NAME>) and the end tag(written </ELEMENT-NAME>); note the slash before the element name in the end tag." 이다.

다시 말해, <ELEMENT-NAME>DOCUMENTATION</ELEMENT-NAME>은 DOCUMENTATION에 적용될 포맷을 특정화한다. HTML과 달리, 엔드 태그 </ELEMENT-NAME>는 절대 선택적이 아니다. 두 종류의 태그가 있다 : 블록 및 인라인(inline). 블록 태그는 문단식 구조를 특정화하고, 인라인 태그는 상기 문단내에 텍스트의 포맷을 특정화하는데 사용된다. 인라인 TAGs는 중첩(nest)될 수 있다. 블록 태그는, UL내의 LI를 제 외하고는, 중첩될 수 없다.

이들 구성은 HTML로 용이하게 번역되어, 각 명령어를 위한 HTML 페이지 및 명령어의 인덱스를 어셈블하는 Appendix C의 것과 같은 프로그램의 부분으로서 HTML 문서화를 생성할 수 있다. 이러한 HTML 문서화는 프로세서 사용자를 위한 온-라인 참조 매뉴얼을 제작하는데 사용될 수 있다. 바람직한 실시예에서 위와 같이 하기 위한 프로그램은 Perl 프로그래밍 언어로 쓰여지고, 2개의 열(하나는 의사기호를 위한 것, 또 하나는 시놉시스 텍스트 문자열을 위한 것)의 HTML 테이블을 갖는 index.html 파일을 작성하여 작업한다. 테이블의 행들은 소트된 순서로 명령어를 프로세싱하여 채워진다. 명령어 의사기호는 각 명령어를 위하여 생성된 페이지에 HTML 링크된다.

per-명령어 페이지는 의사기호 및 시놉시스를 제공하는 HTML 레벨-1 표제("H1")로 시작한다. 다음, 다양한 섹션들이 HTML 레벨-2 표제("H2")에서 고정된 네임으로 도입된다. "Instruction Word"로 라벨이 붙은 첫번째 섹션은 비트당 하나의 열을 갖는 HTML-테이블로 표현된 머신 코드 포맷을 제공한다. 연산코드 비트('0' 또는 '1')는 대응하는 테이블 셀에 삽입된다. 피연산자 필드들은 필드 네임으로 그 안에 채워진다. 다수의 인접 비트를 스팬(span)하는 필드는 반복을 피하도록 HTML 테이블의 COLSPAN 특징을 사용한다. 머신 코드 박스의 비트들은 테이블 행 위쪽을 사용하여 번호가 매겨지고, 필드 폭은 행 아래쪽에 주어진다.

"Package"로 라벨이 붙은 두번째 섹션은 명령어를 정의하는 TIE 패키지 네임을 제공한다. 간단한 해시(hash)는 식별기(identifier)로부터의 패키지 네임을 문 서화 문자열로 번역하는데 사용된다. 패키지 네임 자체는 HTML 문단 블록-요소("p")의 내부에서 출력된다.

"Assembler Syntax"로 라벨이 붙은 세번째 섹션은 명령어를 코드화하는데 사용되는 어셈블리 언어 포맷을 제공한다. 이것은 명령어 의사기호, 스페이스 및 콤마에 의하여 구분되는 피연산자 네임으로 구성되어 있다. 레지스터 피연산자 네임은 레지스터 파일의 쇼트 네임을 필드 네임과 연결시켜 형성된다. 직접 피연산자 네임들은 단지 TIE로부터의 직접 네임이다. 어셈블러 구문은 HTML 코드 인라인-요소("CODE")를 사용하여 HTML 문단 블록-레벨 요소("P")의 내부에서 출력된다. 코드 인라인-요소는, 프로그래밍 언어 코드가 보통 렌더링되는 방식과 유사한 고정 폭 폰트로 텍스트를 렌더링한다.

"Description"으로 라벨이 붙은 네번째 섹션은, TIE에서 HTML로 번역된 텍스트 기술을 포함한다. TIE의 포맷 코드는 HTML의 것과 유사하기 때문에, 이 번역은 매우 간단하다. 일차적으로 필요한 것은 INSTREF 요소를 네임 명령어에 대한 HTML 링크로 번역하는 것이다.

"Assembler Note"로 라벨이 붙은 선택적인 다섯번째 섹션은, TIE에서 HTML로 번역된 텍스트를 포함한다.

"Exceptions"로 라벨이 붙은 여섯번째 섹션은, 상기 명령어가 올릴 수 있는 예외의 리스트를 포함한다. Load 및 Store 명령어는 TIE 컴파일러에 의하여 리스트에 추가된 LoadStoreError 예외를 자동적으로 가진다. 대응하는 예외 신호가 명령어의 iclass의 신호 리스트 섹션에서 리스트화된다면, 기타 예외들이 리스트화된 다. 예외들은 우선순위 순서(상술된 위상 정렬의 결과)로 리스트화된다.

"Implementation Notes"로 라벨이 붙은 선택적인 일곱번째 섹션은, TIE에서 HTML로 번역된 텍스트를 포함한다.

후술되는 TIE 명세로부터의 테스트 케이스 리스트를 문서화내로 카피하는 것도 가능한데, 그 이유는 이것이 때때로 판독자(reader)에게 유용하기 때문이다.

프로세서 명령어를 위한 문서화의 예시가 아래에 주어진다.

<html>

<head>

<title>

GFADD8 - Galois Field 8-bit Add

</title>

</head>

<body>

<h1>

GFADD8 — Galois Field 8-bit Add

</h1>

<h2>

Instruction Word

</h2>

<table frame="void" rules="groups" cellspacing=O

cellpadding=O>

<colgroup colspan=8><col width=28><col width=28><col

width=28><col width=28><col width=28><col width=28><col

width=28><col width=28><colgroup colspan=4><col width=28><col

width=28><col width=28><col width=28><colgroup colspan=4><col

width=28><col width=28><col width=28><col width=28><colgroup

colspan=4><col width=28><col width=28><col width=28><col

width=28><colgroup colspan=4><col width=28><col width=28><col

width=28><col width=28>

<thead>

<tr>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</td>

</tr>

</thead>

<tbody>

<tr>

0

</td>

0

</td>

0

</td>

0

</td>

0

</td>

1

</td>

1

</td>

0

</td>

r

</td>

s

</td>

t

</td>

0

</td>

0

</td>

0

</td>

0

</td>

</tr>

</tbody>

<tfoot>

<tr>

</td>

</td>

</td>

</td>

</td>

</tr>

</tfoot>

</table>

<h2>

Package

</h2>

<p>

</p>

<h2>

Assembler Syntax

</h2>

<p>

<code>GFADD8 gr, gs, gt</code>

</p>

<h2>

Description

</h2>

<p><CODE>GFADD8</CODE> performs a 8-bit Galois Field

addition of the

contents of GF registers <CODE>gs</CODE> and <CODE>gt</CODE> and

writes the result to GF register <CODE>gr</CODE>.</P>

<h2>

Operation

</h2>

<pre>

gr = gs ＾ gt;

</pre>

<h2>

Exceptions

</h2>

<p>

None

</p>

</body>

</html>

비록 HTML은 바람직한 실시예에서 문서화 포맷 언어로서 사용되었지만, 당업자라면 Adobe Frame Maker MIF 포맷과 같은 기타 동등한 명세 언어가 사용될 수도 있다는 것을 인식할 것이다.

서브-필드

본 발명의 실시예들을, 프로그램 실행 특성들을 변하게 하는 프로세서 구성 옵션에 덜 민감하게 만드는 개발은 또 다른 필드의 서브-필드로서 필드를 정의하는 능력이다. 이는 필드의 정의를 명령어 워드의 특정화된 파트로 제한하였고, 그것들을 다른 필드의 파트로 정의되도록 허용하지 않았던 종래의 구성가능한 프로세서 시스템과 대조적이다. 다른 필드의 파트로서 필드를 정의하는 능력은 소프트웨어가 구성된 프로세서의 엔디안화(endianness)에 부분적으로 독립적이도록 한다.

예를 들어, 종래의 시스템에 있어서, t 필드의 첫번째 2 비트에 대응하는 신규 필드 t10은 단지 다음과 같은 TIE 문장 중의 어느 하나로만 정의될 수 있다.

field t10 inst[5:4] /* for field memory order */

또는

field t10 inst[15:14] /* for big endian memory order */

이러한 형태하에서는, 메모리 오더에 독립적인 t10을 정의하는 것이 가능하지 않다. 서브-필드의 사용을 허용함으로써, 본 발명은 t10이 다음과 같이 정의되도록 한다.

field t10 t[1:0]

t는 프로세서 코어에 의하여 리틀 엔디안(little endian)을 위해서는 inst[7:4] 그리고 빅 엔디안(big endian)을 위해서는 inst[17:14]로 정의되기 때문에, 이제 t10은 메모리 오더에 독립적이다.

테스트 케이스

사용자-정의 TIE의 검증에 대한 두가지 형태가 있다. 첫째는 코어와 TIE 블록 및 사용자-정의 상태와 레지스터 파일간의 인터페이스의 정확성을 확보하는 것이다. 둘째는 사용자 시맨틱의 하드웨어로의 번역, 다시말해 TIE 컴파일러의 정확성을 검증하는 것이다. 첫째는 TIE 명령어 시맨틱에 좌우되지 않고, TIE 명세의 특성으로부터 도출될 수 있다.

사용자-정의 TIE를 위한 소정의 임의의 방향성(directed) 테스트 또는 진단(diagnostics)을 기록하는 것이 가능하지 않다. 이러한 문제는 TIE를 위한 하드웨어 및 소프트웨어가 생성되는 동시에 사용자 TIE 명세로부터 테스트를 도출하여 접근된다. TIE 컴파일러는 사용자 명령어를 위한 ISA 기술을 생성한다. TIE용 진단 제너레이터는 TIE 명령어의 ISA 기술을 판독한다. 이것은 또한 사용자-정의 상태 및 레지스터 파일에 대한 지식을 포함한다. 이 정보는 상기 제너레이터에 의하여 사용되어, 사용자 TIE를 위한 소정의 의미있는 진단 세트를 만들어낸다.

참조 시맨틱은 구현 시맨틱을 위한 검증 방법을 제공한다. 참조 시맨틱들은 타겟 어플리케이션에 그들을 사용하여 검증된다. Killian 등 및 Wilson 등의 출원에 기재되어 있는 바와 같이, 상기 출원은 내재함수를 통해 신규 명령어를 사용하도록 디자이너에 의해 수정된다. 수정된 어플리케이션 및 명령어 정의들은 시뮬레이터로 또는 원시적으로(natively) 함께 테스트된다. 원시(native) 실행은 (종래의 것과 같은) TIE 컴파일러의 능력에 의해 촉진(facilitate)되어, 함수로서 내재함수의 종래의 프로그래밍 언어(예를 들어, C) 정의를 만들어낸다. 타겟 어플리케이션의 사용은 일반적으로 명령어 정의의 가장 좋은 테스트이다.

C 코드를 생성하는 TIE 컴파일러의 정확성은 상기 프로세스에 의하여 체크되지만, 상기 어플리케이션이 HDL 시뮬레이터에서 실행되지 않으면, TIE 코드의 HDL로의 번역은 체크되지 않는다. 하지만, HDL 시뮬레이터는 일반적으로 많은 어플리케이션에서 이를 수행하는데 있어 너무 느리다. 따라서, 입력 시맨틱을 HDL로 번역하는 TIE 컴파일러 번역의 정확성을 테스트하기 위해서는 소정의 다른 방식을 구비 하는 것이 바람직하다.

또한, 디자이너는 어플리케이션이 명령어에 의하여 핸들링되어야 하는 모든 케이스를 커버하는지를 확신하지 못할 수도 있다. 어플리케이션이 프로세서가 생성된 후에 변경될 수 있다면, 또는 신규 어플리케이션이 상기 프로세서를 사용할 것이라면, 이는 중요하다. 이 경우, 명령어를 테스트하기 위하여 다른 방식을 구비하는 것이 바람직하다. 종래의 시스템에 있어서, 프로세서의 명령어들은 일반적으로 선택된 세트의 소스 피연산자값으로 명령어를 실행하고, 예상값에 대하여 결과 피연산자를 체크하는 육필(hand-written) 진단을 실행하여 테스트된다. 바람직한 실시예는 TIE 명세로부터 이용가능한 부가적인 정보를 이용하여 상기 프로세스를 자동화한다.

TIE iclass 명세는 각 명령어의 모든 입력 및 출력에 대하여, 레지스터 파일 피연산자, 직접모드(immediates) 또는 프로세서 상태 레지스터인지를 리스트화한다. TIE 구성

test <iname> {

in { <oname> => <value>, ... }

out { <oname> => <value>, ... }

in { <oname> => <value>, ... }

out { <oname> => <value>, ... }

...

}

은 명령어 <iname>에 대한 예상 결과 및 소스 피연산자값의 리스트를 제공한다. 여기서, <oname>은 피연산자 또는 상태 레지스터의 네임이고, <value>는 (in 또는 inout 피연산자에 대한 또는 테스트 in 리스트의 레지스터에 대한) 대응하는 입력값 또는 (out 또는 inout 피연산자, 레지스터에 대한 또는 테스트 out 리스트의 예외 신호에 대한) 예상값이다.

TIE 컴파일러는 테스트 in 리스트의 상기 값에 대한 in 및 inout 프로세서 레지스터들이 Wilson 등의 출원에 기술된 TIE user_register 구성으로 선언된 수 및 WUR 내재함수를 사용하는 종래의 프로그램 언어(예를 들어, C)에서 테스트 프로그램을 생성한다. 그 후, 레지스터를 로드시키기 위한 proto 선언에 의하여 특정화된 내재함수를 사용하여 in 및 inout 레지스터 파일 피연산자를 셋업한다. 코어 레지스터 파일(예를 들어, 바람직한 실시예에서는 AR's)의 피연산자들은 내장 언어 타입을 사용한다. 다음, TIE 컴파일러는 iclass에 의하여 특정화된 순서로 리스트화된 피연산자로 내재함수를 불러낼 것이다. 다음으로, 테스트 out 리스트에서 특정화된 out 및 inout 피연산자들이 판독되어, 주어진 예상값과 비교된다. 최종적으로, 테스트 out 리스트의 프로세서 레지스터들은 user_register 구성을 위한 레지스터 수 및 RUR 내재함수를 사용하여 판독되고, 이들 값들은 주어진 값과 비교된다.

이렇게 자동으로 생성된 프로그래밍 언어 진단은 명령어 세트 시뮬레이터에서 또는 타겟 프로그래밍 언어로의 번역에 의하여 TIE 컴파일러가 생성한 내재-모방(intrinsic-emulating) 함수를 원시적으로 사용하거나 하드웨어 RTL 모델상에서 실행될 수 있다.

예시로서, 명세

test GFADD8 {

in { gs => 8'xFF, gt => 8'xA5 }

out { gr => 8'x5A }

}

test GFMULX8 {

in { gs => 8'xFF, gfmod => 8'xA5 }

out {gr => 8'x5B }

}

는 다음과 같은 C 진단을 생성한다.

unsigned char GFADD80_0[1] = { 255 };

unsigned char GFADD8_1[1] = {165};

unsigned char GFADD8_2[l] = { 90 };

unsigned char GFMULX8_0[l] = { 255 };

unsigned char GFMULX8_l[l] = { 91 };

unsigned char GFMULX8_2[l] = { 165 };

int

main (int argc, char *argv[])

{

for (i = 0 ; i < 1 ; i += 1) {

gf gr;

gf gs;

gf gt;

unsigned char tO;

LGF8_I (gs, &GFADD8_0[i], 0);

LGF8_I (gt, &GFADD8_1[i], 0);

GFADD8 (gr, gs, gt);

SGF8_I (gr, &t0, 0);

if (tO != GFADD8_2[i])

fail();

}

for (i = 0 ; i < 1 ; i += 1) {

gf gr;

gf gs;

unsigned char tO;

LGF8_I (gs, &GFMULX8_0[i], 0);

WUR (GFMULX8_1[i], 0);

GFMULX8 (gr, gs);

SGF8_I (gr, &t0, 0);

if (tO != GFMULX8_2[i])

fail();

}

return 0;

}

테스트 케이스를 생성하기 위한 테스트 벡터의 자동 샘플링

어플리케이션을 실행하는 것이 입력 명령어 시맨틱의 정확성을 테스트하기에 충분한 경우, 상기 입력 시맨틱의 TIE 번역을 테스트하기 위하여 HDL 시뮬레이터에서 실행하는 테스트 케이스를 가지는 것도 바람직하다. HDL 시뮬레이터는 많은 경우에 있어 어플리케이션을 실행하는데 너무 느리다. 따라서, 원시적으로 또는 명령어 세트 시뮬레이터에서 실행하는 어플리케이션으로부터 테스트를 추출하기 위한 방법을 가지는 것이 바람직하다.

따라서, TIE 컴파일러는 명령어의 입력 및 출력 피연산자를 파일에 기록하는 코드를 갖는 어플리케이션 프로그래밍 언어로의 입력 시맨틱의 번역을 증가(augment)시키기 위하여 옵션을 가져야 한다. 상기 파일은 중복(duplicate)을 제거하고, 통계적 샘플링을 사용하여 포스트-프로세싱되어, HDL 시뮬레이터에서 시뮬레이션하기 합리적인 테스트 케이스의 수를 추출할 수 있다. 이들 기록은 그 구현이 나머지 프로세스에 대하여 영향을 줄 수 있도록 상술된 TIE 테스트 구성으로 변환될 수 있다.

아키텍처럴 테스트 및 마이크로아키텍처럴 테스트를 생성하는 이러한 방법론 을 이용하는 배후의 목적은 사용자 TIE의 구현을 위한 시스템적 검증 프로세스를 제공하는 것이다. 이는 사용자의 어플리케이션이 TIE 구현의 마이크로아키텍처를 테스트하는데 충분하지 않을 수도 있기 때문에 매우 중요하다. TIE 기술로부터 상기 진단을 생성하기 위하여, TIE 컴파일러에 의하여 생성된 ISA 기술 및 파이프라인 정보로부터 필요한 정보를 도출시키는 방법을 채택한다. 이러한 방식이 후술된다.

TIE 명령어의 ISA 기술

사용자의 요구사항에 따라 프로세서 코어를 구성할 수 있기 위해서는, 구성(configuration)이 사용된다. 구성은 본질적으로 웹을 기반으로 하는 인터페이스를 통하여 사용자에 의하여 맞춤화(customize)될 수 있는 프로세서 코어의 속성 및 파트들의 리스트이다. 이들 프로세서 속성들은 구성 파라미터로서 언급된다. 구성 파라미터의 완전한 리스트는 그 디폴트 값과 범위에 따르고, 상기 값들은 프로세서 코어의 구성 스페이스를 정의한다고 가정할 수 있다. 프로세서 코어의 구체적인 경우는, 즉 모든 구성 파라미터에 구체적인 값들이 지정된 코어의 경우는 코어 구성이다.

현재, 구성 스페이스 및 구체적인 코어 구성 양자 모두는 상기 구성 파라미터 및 그 값들을 리스트화하는 텍스트 파일로서 표현된다. 텍스트 파일로 열거된 모든 구성 파라미터 및 그 값들의 플랫(flat) 리스트는 사람이 용이하게 읽을 수 있는 장점이 있지만, 하드웨어 및 소프트웨어의 개별적인 피스(piece)를 구성하는 프로세스가 복잡하다. 이러한 이유로, 구성 정보를 읽고, 구성 파라미터의 값 및 프로세서의 다양한 파트들의 객체-지향형 표현을 생성하는 한 세트의 툴이 개발되어 왔다. 구성의 표현 및 툴들은 집합적으로 구성 환경 또는 구성 데이터베이스로 알려져 있다.

소프트웨어 및 하드웨어의 구성시, tpp는 개발자로 하여금 구성 정보를 프로그램적으로 액세스할 수 있게 하는 구성 환경 뿐만 아니라 소스 코드의 용이한 계산 파트에 대한 취급을 제공한다. 또한, 계산은 구성 환경에서 수행되기 때문에, 따라서 모든 구성된 소스에 걸쳐 공유되고, 구성가능한 소스 코드를 개발하는 것이 간단해진다.

ISA를 기술하기 위한 PERL 라이브러리가 개발되어 왔다. TIE에 있어서, TIE 컴파일러는 사용자-정의 명령어용 PERL 객체를 생성하도록 실행되고, 이는 코어 ISA에 추가된다. 그로부터, 모든 검증 툴은 이들 PERL 객체를 질의(query)하여, 사용자-정의 TIE의 ISA 및 파이프라인 정보를 얻을 수 있다.

다음의 예시는 이것이 수행되는 법을 예시한다. 다음과 같은 간단한 TIE 기술로 시작한다.

opcode acc op2=0 CUSTO

state accum 32

user_register 100 accum

iclass acc {acc} {in ars, in art} {inout accum}

reference acc {

assign accum = accum + ars + art;

}

TIE 컴파일러는 그것을 사용하여 명령어의 시맨틱 및 TIE 사용자 상태에 대한 다음의 정보를 생성한다.

State accum mapped to user register: 100, bits 31:0

opcode : acc, package : UserDefined, size : 20,

Register Operands:

Name : as : input,

regfile : AR, shortname:a, size:32 bits, entries:64

Name : at: input,

regfile : AR, shortname:a, size:32 bits, entries:64

상기 정보로부터, TIE 명령어 acc를 위한 어셈블리 코드를 생성하는 것이 가능하다. 명령어는 소정의 랜덤 레지스터 할당 또는 훨씬 더 좋은 지능적인 레지스터 할당을 행하는 것이 가능하다는 것을 토대로, 타입이 모두 AR인 2개의 레지스터 피연산자를 가진다고 알려져 있는데, 그 이유는 출력 및 입력 필드가 알려져 있기 때문이다. 따라서, acc $a7, $a13과 같은 상기 명령어를 위한 어셈블리 코드를 자동으로 생성하는 것이 가능하며, 여기서 a7 및 a13은 AR에 대한 regfile 정의로 보는 레지스터 할당 알고리즘에 의하여 생성된 명령어 acc의 s 및 t 필드이다. TIE 명령어의 ISA 기술에 대한 몇가지 예시는 다음과 같다.

opcode : il281, package : UserDefined, size : 24, load

Register Operands:

Name : il28t:output,

regfile:il28, shortname:il28, size:128 bits, entries:16

Name : as: input,

regfile:AR, shortname:a, size:32 bits, entries:64

Immediate Operands:

Name:offset28: bits 8, Table : [0 16 32 48 .... ]

opcode : wurO, package : UserDefined, size : 24,

Register Operands:

Name : at: input,

regfile : AR, shortname:a, size:32 bits, entries:64

opcode : il28s, package : UserDefined, size : 24, store

Register Operands:

Name: il28t : input

regfile:il28, shortname:il28, size:128 bits, entries:16

Name : as: input

regfile : AR, shortname:a, size:32 bits, entries:64

Immediate Operands:

Name:offset28:bits 8, shift 0, Table : [0 16 32 ....]

명령어의 예상값에 대한 충분한 정보를 도출하는 것이 가능하지 않기 때문에, TIE 시맨틱의 정확성을 체크하는 것이 가능하지 않다. 예를 들어, acc 명령어의 결과가 테스트에서 정확한지를 체크하는 것이 가능하지 않다. 하지만, 하드웨어가 상태 누산기에서 틀린 결과를 산출하였다면, 또 다른 섹션에서 더욱 상세히 설명되는 바와 같이, 이는 모든 명령어 바운더리에서 RTL 및 ISS 사이의 모든 사용자 상태와 레지스터 파일을 비교하는 코시뮬레이션 메커니즘에 의하여 검출될 것이다. 다음의 섹션들은 알고리즘을 표현하도록 의사코드 같은 소정의 PERL을 사용한다. 진단 제너레이터들은 대부분 PERL 기반 프로그램이다.

정확한 TIE 명령어를 생성하기 위한 진단 제너레이터에 의하여 사용되는 알고리즘은 다음과 같다.

subroutine gen_tie_instr

( tie_opcode, address_reg, index_reg)

{

// address_reg is a core register

// containing a valid address in case

// the TIE instruction does a load/store,

// same for the index register, if the

// load/store is a indexed load

foreach operand (tie_inst->regoperands() ) {

fld = operand->field();

reg = &register_allocate(tie_inst, operand);

if ( (isLoad(tie_inst) || isStore(tie_inst) )

&& operand->name() eq 'as' ) {

override with valid address

reg = address_reg;

}

if ( ( isLoad(tie_inst) || isStore(tie_inst) )

&& operand-> name() eq 'at' ) {

reg = index_reg;

}

push ( operand_list, reg);

}

foreach operand (tie_inst->immoperands() ) {

// specification of immediate operand

// as a table of values or a range

range = operand->range();

table = operand->table();

legal = tie_inst->legals(operand->field()->name);

if ( legal ) {

imm = legal[ random index ];

} elsif ( range ) {

imm = random value between range.lo and range.hi;

} elsif ( table) {

imm = table [ random index ];

}

push ( operand_list, imm);

}

subroutine register_allocate (tie_inst, register_operand) {

name = register_operand->shortname();

numentries= register_operand->entries();

legalrange =

tie_inst->legals(register_operand->field()->name());

if ( legalrange ) {

register_num = legalrange [ random index ];

} else {

register_num = random (0, numentries-1 );

}

return concatenate( name, register_num };

}

또한, TIE 명령어를 실행하는 것을 시작하는 것이 가능하기 전에, TIE 상태 및 레지스터 파일을 초기화하는 것이 필요하다. 이는 다음과 같은 방식으로 행해진다.

subroutine initTieState ( address_reg, data_reg ) {

// Iterate over all state and get the vaue

// for each user register that

// the states are mapped to

states = (tie->states(),

map($->states(), tie->coprocessors()) );

foreach state ( states ) {

UserRegMask{state->userReg} = getMask;

}

foreach ureg( keys of the hashtable UserRegMask ) {

mask the data register with the mask value

do a WUR to the ureg

}

// Initialize register files by loading from a

// valid memory location

regfiles = (tie->regfiles(),

map($_->regfiles(), tie->coprocessors()) >

foreach regf ( regfiles ) {

for( i=0; i< regf->entries(); i++ ) {

generate the load instruction or instruction sequence

using the adds reg that has the valid address to load

index i of register file regf.

}

TIE를 위한 파이프라인 정보

TIE에서의 바이패스 및 인터록 로직을 테스트하는 마이크로아키텍처럴 진단을 발생시키기 위해서는, TIE 명령어의 파이프라인 정보가 필요하다. 이는 레지스터 및 상태와 같은 자원들이 TIE 명령어에 의하여 읽고 쓰여지는 스테이지들의 지식을 제공한다. 다시 한번, TIE 컴파일러는 상기 정보를 제공하고, PERL 객체에 표현되며, 검증 툴에 의하여 사용된다. 파이프라인의 상이한 스테이지에서 데이터를 간단하게 이동시키는 명령어의 세트 및 사용자-정의 레지스터 파일을 갖는 다음의 예시를 살펴보자. 관습(convention) 1:E 스테이지, 2:M 스테이지, 3:W 스테이지를 유의하라.

regfile il28 128 16 il28

operand il28s s {il28[s]}

operand il28t t {il28[t]}

operand il28r r {il28[r]}

opcode I128L r=O LSCI

opcode I128S r=1 LSCI

opcode I128AND op2=0 CUSTO

schedule load {I128L} {

def il28t 2;

}

이것은 PERL 데이터베이스에 다음과 같이 번역한다.

Regfile il28 width 128 entries 16 instructions :

Writes:

stage 2 : Inst il28and: Field r

stage 3 : Inst il281: Field t

Reads:

stage 1 : Inst il28s: Field t

Inst il28and: Field s

Inst il28and: Field t

이러한 정보가 어떻게 차기 섹션에서 진단을 생성하는데 사용되는지 알 수 있다.

TIE를 위한 마이크로아키텍처럴 테스트

본 섹션의 목적은 TIE와 코어간의 인터페이스의 구현의 지식 뿐만 아니라, 만일 있다면, TIE 상태 및 레지스터 파일의 그것을 토대로 TIE 로직을 위한 마이크로아키텍처럴 진단을 생성하는 것이다. TIE 자체의 파이프라인 기술 및 ISA가 사용되지만, 앞서 언급한 바와 같이, TIE 명령어의 구현의 "정확성"은 테스트에서 직접 검증되지 않는다.

한 세트의 MVP 진단은 구현의 다음과 같은 형태를 테스트하기 위하여 생성된다.

-- 코어/tie 인터페이스에 있어서의 제어 로직; 및

-- 로드/저장과 바이패스 및 인터록 로직을 포함하는, 사용자 상태 및 레지스터 파일의 구현.

코어와 TIE간의 제어 신호

예외, 인터럽트 및 재생(replay) 신호들은 모든 사용자 명령어가 코어(예를 들면, 브랜치), 예외 및 재생 신호에서 제어 순서 변경(control flow change)에 의하여 제거(kill)되는 테스트를 발생시킴으로써 테스트된다. 명령어는 바로 종료 스테이지까지 그 실행의 모든 스테이지에서 제거되어야 한다.

이들 테스트를 발생시키는 알고리즘은 TIE 컴파일러에 의하여 생성된 ISA 기술에서 모든 TIE 연산코드에 걸쳐 간단히 반복하고, 다음의 각각의 경우를 구성한다.

케이스 a) TIE 명령어는 순서의 변경에 의하여 제거됨:

foreach tie_opcode (tie_opcode_list)

branch instr ( branch taken)

tie_opcode

end // foreach

케이스 b) TIE 명령어는 예외에 의하여 제거됨:

foreach tie_opcode ( tie_opcode_list)

for (stage=0;

stage < completion stage of tie_opcode;

stage++ )

syscall or break instr (that generates an exception)

<stage> number of nops

tie_opcode

end // for

end // foreach

알 수 있는 바와 같이, 예외를 발생시키는 명령어와 TIE 명령어간의 no-ops의 수는 그것이 제거되어지는 TIE 명령어 실행의 스테이지를 제어한다.

케이스 c) TIE 명령어는 파이프라인으로 재생됨

foreach tie_opcode ( tie_opcode_list )

isync instr

tie_opcode

end

사용자 상태 및 레지스터 파일을 위한 바이패스 로직

이들 테스트는 그들을 쓰기/읽기하는 "패어링(pairing)" 명령어에 의하여 TIE 상태 및 레지스터 파일을 위한 바이패스 로직을 실행할 것이다. 상기 테스트는 데이터 페치(fetch) 및 명령어의 계정(account)상의 스톨이 없고, (만일 구성이 허용한다면) 에러와 같은 어떤 불필요한 스톨 및 플래그(flag)를 찾기 위하여 명령어 시퀀스 전후에서 사이클 카운트 레지스터를 체크하는 것을 보장할 것이다. 알고리즘은 다음과 같다.

특정 레지스터 파일 또는 상태에 대한 모든 읽기/쓰기 스테이지를 위하여 [instr, field]의 리스트를 생성하자. 이 state/regfile에 대한 최대 완료 스테이지가 무엇인지 체크하자. 이제, 쓰기 및 읽기 명령어를 쌍을 이루면, 최대 완료 스테이지까지의 사이에서 nop의 수가 변한다.

foreach regf ( tie->regfiles() ) {

//list of the stages at which regf is read

// possibly (1, 2)

readstages = getReadStages( regf);,

// list of stages at which regf is written

// possibly (2, 3)

writestages = getDefStages( regf );

foreach wstage ( writestages ) {

writelist = Generate list of [instr, field] pairs

that write regf in stage wstage

max_nops =

maximum_completion_stage for regf - wstage ;

foreach rstage ( readstages ) {

readlist = Generate list of [instr, field]

pairs that read regf in stage rstage

}

foreach write_instr ( writelist ) {

foreach read_instr ( readlist ) {

for ( i=0; i< max_nops; i++ ) {

stalls =

(wstage-rstage-1) if ( wstage > rstage ) else 0;

ccount_before = read cycle count

write_instr

I - nops

read_instr

ccount_after = read cycle count

if (( ccount_after - ccount_before)

!= ( stalls + nops + 3 ) )

ERROR !!

}

명령어 시퀀스를 두번 실행함으로써 I$ 및 D$ 미스가 없는 것을 보증하는 것이 필요하다. 두번째 반복에서, 사이클 카운트 체크가 행해진다. 사이클의 예상 수는 읽기/쓰기 스테이지 및 nop에 따라 좌우된다. 상기 예시를 위한 소정의 예시 케이스들은 다음과 같다.

#(il281 field t stage 3) -> (il28and Field s Stage 1),

#nops=0, stall 1 cycles

Test_11:

rsr $a3, 234 <-- read cycle count before

il281 $i1280,$a10,0

| ->

|

il28and $il285,$il280,$il2811

rsr $a4, 234 <--- cycle count after

addi $a3, $a3, 4

beq a4, a3, PASS_11

j FAIL

PASS_11:

#(il28and field r stage 2) -> (il28and Field s Stage 1),

#nops=0, stall 0 cycles,

Test_12:

rsr $a3, 234

il28and $il280,$il288,$il284

| ->

|

i128and $i1286,$i1280,$i1285

rsr $a4, 234

addi $a3, $a3, 3

beq a4, a3, PASS_12

j FAIL

PASS_12:

#(il28and field r stage 2) -> (il28and Field s Stage 1),

# nops=1, stall 0 cycles,

Test_13:

rsr $a3, 234

i128and $i1280,$i1288,$i1284

nop.n

i128and $i1286, $i1280, $i1285

rsr $a4, 234

addi $a3, $a3, 4

beq a4, a3, PASS_13

j FAIL

PASS_13:

인터록 및 해저드(Interlocks and hazards)

이것은 읽기-후-쓰기, 쓰기-후-쓰기 및 (가능하게는) 쓰기-후-읽기 해저드 케이스의 경우에 스톨을 보정하기 위하여 테스트한다.

해저드 케이스를 위한 알고리즘은 상술된 바이패스 케이스의 것과 유사하게 도출된다. 스테이지 1에서 그것을 읽는 명령어의 뒤를 이어, 스테이지 2 및 스테이지 3에서 동일한 regfile을 쓰는 2개의 명령어가 있다. 세번째 명령어는 두번째 쓰기의 결과를 위하여 스톨한다.

#(Inst il28and r 2) ->

#(Inst i1281 t 3) ->

#(Inst il28and s 1)

Test_1:

rsr $a3, 234

il28and $il280,$il289,$il281

i1281 $i1280,$a5,0

il28and $il2815,$il280,$il2813

rsr $a4, 234

addi $a3, $a3, 5

beq a4, a3, PASS_1

j FAIL

PASS_1:

로드/저장

모든 레지스터 파일에 대한 로드 및 저장은 다음과 같은 알고리즘을 사용하여 모든 정렬된 그리고 오정렬된 주소들에 대해 광범위하게 테스트된다.

foreach regf ( tie->regfiles() ) {

PIFbytes = PIFWidth >> 3; // bytes

PIFwords = PIFbytes >> 2; // words ( eg 4 for 128 bit )

regfw = regf-> size() >> 5;

for ( k=0; k< PIFbytes; k++ ) {

load_address = PIFWidth-aligned address + k;

store_address = PIFWidth-aligned address + k;

* initialize memory

* store known data into load address

* store a default value to the store address

for ( i=0; i<PIFwords; i++ ) {

* store data_word to load_address + i

* store default_word to store_address + i

}

* do the load from load address

* do the store to store address

expected_result =

expected_tie_load_result( load_address, data);

for ( i=0; i<PIFw; i++ ) {

result = load a word from store_address + i

if ( i <regfw) {

check result == expected_result

} else {

check result == default_word

}

로드의 예상 결과는 로드 시맨틱에 따라 좌우되고, 비록 그것이 대부분의 경우에 대하여 결정될 수 있지만, 상태 및 메모리 비교에 대한 체크를 남기는 것이 필요한 경우, 가능한 모든 시맨틱에 대하여 그렇게 하기는 가능하지 않을 수 있다.

TIE 로드/저장 명령어를 위한 데이터 정지점(breakpoint)들은 또한 구성이 데이터 정지점을 지원하는 경우에 TIE 로드/저장 명령어에 대하여 테스트된다. 데이터 정지점이 어떻게 TIE 명령어를 위하여 작업하는지의 상세는 로드/저장 아키텍처 섹션에서 찾아볼 수 있다. 발생된 진단은, 데이터 정지 주소 레지스터, 제어 마스크 레지스터 및 로드/저장을 위한 가상 주소의 가능한 모든 조합에 대해 데이터 정지점을 테스트한다.

foreach regf (tie->regfiles() ) {

regfw = regf->size() >> 5;

write dbreak register with an address aligned to regfw

foreach mask ( set of masks for regfw ) {

* write dbreak control mask

* set address register based

on mask and dbreak address

* do a load/store to regf that

takes a data breakpoint exception

* check if exception was taken

end

부합(match)하는 데이터 정지점은 디버그 예외를 발생시킬 것이다. 상기 테이스를 위한 디버그 예외 핸들러는 예외가 실제로 취해졌던 것을 보장하도록 체크 될 카운터를 갱신할 것이다. 이것에 덧붙여, 데이터 정지점을 갖는 로드/저장은 상기 예외의 정확한 우선순위를 보장하도록 (레지스터 윈도우를 위한) 오버플로우/언더플로우 예외와 부합하는 더욱 복잡한 케이스들도 구성된다.

TIE 명령어를 위한 랜덤 진단 제너레이터

랜덤 진단은 마이크로아키텍처의 구현 뿐만 아니라, 코어 ISA의 검증에 있어서 주요 역할을 한다. 명령어의 랜덤 시퀀스는 방향성 테스트에 의하여 커버되기 쉽지 않은 기타의 시나리오 및 바운더리 케이스를 적중(hit)시키기 쉽다. 그들은 또한 설계 검증을 위하여 커버리지 측정기준(coverage metrics)에 추가한다. 부가적인 지능(intelligence)은 소정의 특징들을 부가함으로써 랜덤 제너레이터에 추가되어 왔다. 예를 들어, 명령어 시퀀스의 템플리트(template)는 특정 해당 시나리오를 목적으로 삼도록 생성될 수 있다. 이것의 예로는 쓰기-버퍼를 채우는(fill up) back-to-back 저장 또는 단일 명령어를 갖는 제로-오버헤드(zero-overhead) 루프를 들 수 있다. 각 타입의 명령어 또는 명령어 시퀀스에 부착되는 상대 확률(relative probability)은 얼마나 자주 특정 종류의 명령어를 생성하기 원하느냐를 결정할 수 있고, 예를 들면 브랜치 명령어가 높은 상대 확률(또는 가중치)를 가진다면, 생성된 테스트는 더 많은 브랜치들을 가질 것이다. 사용자-제어 파라미터들은 생성된 테스트의 특질(nature)을 조정할 수 있다. 예를 들어, 명령 라인 인자들은 소정의 명령어의 상대 가중치, 테스트의 길이, 중첩된 함수 호출의 수 등을 제어할 수 있다. 랜덤 진단 제너레이터들은 사용자-정의 TIE 명령어도 생성할 수 있다.

기본적인 메커니즘은 마이크로아키텍처럴 테스트의 메커니즘과 유사하다. 랜 덤 제너레이터는 코어 ISA 뿐만 아니라 TIE 명령어를 포함하는 ISA 기술을 판독한다. 유효 TIE 명령어들은 특정 TIE 명령어의 ISA 기술을 주목하고, 소정의 레지스터 할당 메커니즘을 채택함으로써 구성된다.

foreach operand (tie_instr->operands() ) {

if ( operand is TIE register file ) {

do a random register allocation

random(O, #entries in register file)

} elsif ( operand is a core register file ) {

if ( this is a load/store instr ) {

this is the address register

for the load/store operation.

Find a core register that can be written,

and write a valid address

} else {

random core register

}

} elsif immediate field {

generate a random immediate value based on the

instruction's immediate table or range

}

랜덤 제너레이터는 구성 시스템의 최종 사용자에 의하여 액세스가능하지 않은 것이 좋지만, 내부 검증 및 상술된 바와 같은 TIE 기술의 전체 범위에 대해 채택되고, 8, 16, 32, 64, 128비트와 같은 폭이 변하는 TIE 레지스터 파일의 과도한 케이스 및 상태들을 더욱 포함한다. 추가로, 최종 사용자에게는 추가 검증에서 사용하기 위하여 랜덤 제너레이터로의 액세스가 주어질 수도 있다.

TIE 검증을 위한 커버리지 측정

상술된 바와 같이, 상기 검증 작업의 목적은 코어 및 TIE 인터페이스의 정확성, 사용자-정의 상태 및 레지스터 파일과 관련된 로직의 구현 및 TIE 명령어의 하드웨어로의 정확한 번역을 보장하는데 있다. 이들 영역의 소정의 커버리지 측정기준이 요구된다.

이는 TIE 컴파일러에 의하여 생성된 RTL의 기초 설계 커버리지를 참조하는 것을 의미하지 않고, 언급된 영역에서의 기능적 커버리지를 더 참조하는 것을 의미한다. 이러한 TIE용 커버리지 사정(assessment)을 만드는 것은 극히 어렵지만, RTL을 따라 실행하고 소정의 커버리지 수단을 보고하는 소정의 기능적 커버리지 모듈을 생성하기 위한 방식들이 개발되어 왔다. 예를 들어, 하나의 중요한 영역은 TIE 레지스터 파일 및 상태간의 모든 바이패스 경로이다. 바이패스를 테스트하기 위하여 생성된 진단은 가능한 모든 바이패스 경로를 커버해야 하지만, 그 목적은 RTL에서 그것의 독립적인 확인(confirmation)을 갖는 것이다. 이렇게 함으로써, 일부 Verilog/VERA 모듈들은 TIE 기술 및 파이프라인 정보로부터 자동으로 생성된다. 이 들 모듈들은 어떤 바이패스 경로가 커버되었는지를 보고하도록 RTL 시뮬레이션 시간 동안에 실행되었다.

128비트 레지스터 파일의 예시를 살펴보면, i128은 이미 앞선 섹션에서 살펴 보았고, 도 13은 이러한 범용 레지스터 파일 및 하드웨어에서의 구현을 보여준다. 본 도면은 하나의 읽기 포트 Rd0 및 하나의 쓰기 포트 Wd를 보여준다. 통상적으로, 레지스터 파일을 위한 2개의 읽기 포트 및 1개의 쓰기 포트가 있다. 신호에 대한 네이밍 관습(naming convention)은 다음과 같다.

<port_name>_<signal_name>_<stage_name>

여기서,

port_name: 레지스터 파일 포트의 네임(Rd0, Rd1, Wd)

signal_name: 신호 네임들은,

읽기 포트: mux: 먹스의 출력,

data: TIE의 데이터패스 유닛으로 진행하는 플립플롭의 출력

쓰기 포트 : mux: 먹스의 출력

data: 데이터패스 유닛의 출력

result: 플립플롭의 출력

stage_name: 이것은 파이프라인의 스테이지를 가리킨다.

앞선 섹션에 기술된 바와 같이, 상기 관습은 다음과 같다.

C0:R 스테이지, C1:E 스테이지, C2:M 스테이지, C3:W 스테이지.

설명을 간단하게 하기 위하여, 다음의 논의는 모든 TIE 명령어들로 하여금 M 스테이지의 말단보다 더 늦지 않은 레지스터 파일을 기록하는 것을 제한한다.

블록 다이어그램은 이들 스테이지에 대한 상이한 바이패스 경로를 보여준다. 읽기 포트 Rd0에 있어서, 이는 스테이지 1 및 스테이지 2에서의 데이터패스에 의하여 읽혀지고(이는 앞선 섹션에서 레지스터 파일의 사용으로서 표현되었음), 다음과 같이 블록 다이어그램을 추적하거나 설명한다.

Stage C0:

RdO_mux_CO = select from (

Wd_data_C2 :

the result produced by the instr last in the pipeline

Wd_data_Cl :

the result produced by the instr before last

in the pipeline

RdO_data_CO: The current data in the register file

)

Stage C1:

Rd0_data_C1 <= Rd0_mux_C0

where <= implies after a clock cycle

RdO_mux_Cl = select from (

Wd_data_C2 :

the result produced by the instr last in the pipeline

RdO_data_Cl: the result of the previous stage

)

Stage C2:

RdO_data_C2 <= RdO_mux_Cl

스테이지 2 및 3에서 쓰여지는 쓰기 포트 Wd는 유사한 바이패스 경로를 가짐.

Stage C2:

Wd_result_C2 <= Wd_mux_C1 = Wd_data_C1

(the only source for the write port in

stage Cl is the output of the instruction in E stage)

Wd_mux_C2 = select from (

Wd_result1_C2

Wd_data_C2 : result of the current instr in M stage

)

Stage C3:

Wd_result_C3 <= Wd_mux_C2

Wd_result_C3 은 레지스터 파일에 쓰여짐.

바이패스 경로의 커버리지

바람직한 실시예의 목적은, 상기 블록 다이어그램의 모든 바이패스 경로들이 활용되는지를 체크하는 모니터를 생성하는 것이다. 예시적인 바이패스 경로는 도 13의 점선 경로로 추적된다. 상기 모니터는 본질적으로 상기 경로들을 통하여 데이터를 추적하므로, 매우 중요한 가정을 세우는 것이 필요한데, 그것은 데이터가 TIE의 데이터패스 유닛에서 변하지 않고 남아있다는 점이다. 이는 다음과 같은 체크가 수행될 수 있다는 것을 의미한다(E 스테이지(C1)에서 데이터를 읽고 E 스테이지에서 출력 데이터를 생성하는 TIE 명령어는 상기 데이터를 변화시키지 않는다고 가정함).

Wd_data_C1 == Rd0_data_C1

물론, 이것은 임의의 실제 TIE 명령어에 있어서는 맞지 않는다. 하지만, 테스트를 위하여, (실제 하드웨어를 생성하기 위하여 제거될) 사용자 TIE의 소정의 "동치(identity)" 명령어들이 도입된다. 이들 명령어들은 본질적으로 데이터를 카피한다. 본 예시에서, 2개의 동치 명령어가 얻어진다.

Identity 1: use C1, def C1 : 이는 E 스테이지에서 레지스터 파일을 읽고, E 스테이지에서 동일한 데이터를 생성하며,

Identity 2: use C1, def C2 : 이는 사이클 지연 후에 데이터를 생성한다.

모니터 생성의 전제가 설명되었으므로, 이제 모든 바이패스 경로들이 활용되었는지를 테스트하는 Vera 모듈을 생성하기 위한 알고리즘이 아래에 설명된다. 다시 한번, TIE 컴파일러에 의하여 생성된 정보가 사용되고, 상술된 신호 네임 관습이 뒤따른다.

foreach regf ( list of register files ) {

foreach writeport ( writeports of regf ) {

foreach writestage (

list of stages writeport is written ) {

foreach readport ( readports of regf ) {

foreach readstage (

list of stages readport is read) {

skip if writestage < readstage

generate_the_signal_list( regf->name,

writeport-> name, writestage,

readport-> name, readstage,

list_of_write_stages_for_writeport

)

} // readstage

} //readport

}// writestage

} //writeport

} // regf

신호 리스트를 생성하는 서브루틴의 작업은 설명을 간단히 하기 위하여 생략되지만, 당업계의 당업자에게는 명백할 것이다. 하나의 중요한 유의점은 어떻게 데이터패스가 신호의 리스트에 표현되는가 하는 것이다. 만일 데이터패스가 쓰기 스테이지 > 읽기 스테이지를 가진다면(예를 들면, 상기 Identity 2 명령어), 데이터패스 유닛에서 사용된 사이클의 수(이러한 논의를 위하여 2 사이클 TIE 명령어의 제한에 따르면, 하나 까지임)는 간단하게 추가된다.

도 13의 점선으로 도시된 경로는 다음과 같이 상기 알고리즘으로부터 추적 또는 신호 리스트로서 생성된다.

il28_wd_data_C2->

il28_rdO_mux_CO->

il28_rdO_data_Cl->

waitcyclesl->

i128_wd_data_C2->

il28_wd_mux_C2->

il28_wd_result_C3

여기서, i128은 레지스터 파일 네임이다. Xtensa의 탑 레벨로부터 TIE 레지스터 파일 i1128로의 경로는 이와 같이 계획된다. 도 13의 데이터패스의 RdO_data_C1->Wd_data_C2 로부터의 점선은 신호 추적에 있어 웨이트(wait) 사이클 1로 표현되었음을 유의하라.

이러한 신호 추적의 리스트는 모든 바이패스 경로에 대하여 생성된다. 신호 추적을 토대로, 작은 모니터 모듈은 상기 경로가 추적되었는지를 체크하는 Verilog/Vera로 생성된다. 그렇다면, 시뮬레이션의 말단에서 상기 경로에 대하여 1을 보고한다. 각각의 모니터는 본질적으로 다음과 같은 알고리즘에 의하여 생성되는 작은 상태 머신이다.

a) 상태 머신에서 상태의 수를 결정

상태의 수 = 신호 추적에 있어 (E 로부터의) 스테이지의 수 + 데이터패스에서의 사이클의 상태 m/c 수

b) 상태에 따른 신호 그룹화

c) 생성 코드:

state = 0;

foreach state ( states in FSM ) {

if ( last state in list ) {

* reset state

* set flag to 1 for covered

} else {

if ( signals in this state ) {

generate if expression to advance to next state

} else {

advance to next state

}

예시적인 바이패스 경로를 위하여 생성된 상태 머신은 다음과 같다.

case (state)

{

0 :

{

if (<hierarchy>.il28_rdO_mux_CO ==

<hierarchy>.il28_wd_data_C2) {

state = 1;

}

1 :

{

if (<hierarchy>.il28_rdO_data_Cl ==

<hierarchy>.il28_rdO_mux_CO) {

state = 2;

}

2 :

{

int_state = 3; // waitcycles 1

}

3 :

{

if (<hierarchy>.i128_wd_result_C3 ==

<hierarchy>.il28_wd_mux_C2) {

state = 0 ;

result_flag = l'bl;

}

검증 요약(Verification Summary)

입력 참조 명령어 시맨틱의 정확성을 테스트하기 위하여, TIE 코더는 내재함수를 사용하여 신규 명령어를 사용하도록 어플리케이션을 수정한 후, (1) 이것을 머신 코드로 컴파일하고, 어플리케이션을 명령어 세트 시뮬레이터로 실행하거나 또는 (2) 원시 코드로 컴파일하고, 내재적 호환성을 제공하도록 TIE 컴파일러에 의하여 출력된 매크로 및 함수를 사용한다. 어플리케이션의 정확성은 이들 두 가지 옵션 가운데 하나를 이용하여 명령어 참조 시맨틱의 정확성을 검증한다. 참조 시맨틱의 번역은 옵션 2에 의하여 검증되고, 확장된 컴파일러 및 시뮬레이터의 정확성은 옵션 1로 검증된다. 어플리케이션에 의하여 제공된 것 이상의 부가적인 커버리지는 특정 케이스(예를 들어, 독특한(unusual) 또는 "코너" 케이스)의 테스트를 생성하도록 테스트 케이스 TIE 구성의 사용에 의한 것이다.

구현 시맨틱은 상술한 바와 같은 동일한 방법을 사용하는 참조 시맨틱 대신 에 이들을 번역하기 위하여 TIE 컴파일러 옵션을 사용하여 검증될 수 있다. 구현 시맨틱 및 그것의 HDL로의 번역은 또한 HDL로 각각 번역 작업을 하는 상용 등가 체크 툴에 의하여 상기 참조 시맨틱과 유사하게 공식적으로 검증될 수도 있다. 구현 시맨틱 및 그 번역은 또한 HDL 시뮬레이터에서 실행하는 TIE-정의 테스트 케이스의 사용에 의하여 체크될 수도 있다.

레지스터 파일, 인터록, 바이패스, 코어 인터페이스 및 예외를 위하여 TIE 컴파일러에 의하여 생성된 HDL은, TIE 입력을 토대로 자동으로 생성된 테스트를 실행시키고, 결과들을 검증하기 위하여 코시뮬레이션을 사용하여 검증된다. 이들 테스트는 인터록, 바이패스 및 예외의 모든 조합을 철저하게 테스트하기 위하여 파이프라인 명세를 사용한다.

TIE 컴파일러에 의하여 생성된 HAL 코드는 명령어 세트 시뮬레이터에서 그것을 실행하여 검증된다. 신규 명령어를 지원하는 어셈블러 및 컴파일러는 상기 대부분에 의하여 검증된다.

프로세서의 코시뮬레이션

코시뮬레이션은 RTL 및 참조 모델을 병렬로 실행시키고, 특정화된 바운더리에서 ISA로 정의된 아키텍처럴하게 볼 수 있는(architecturally visible) 상태를 비교하는 프로세스이다.

코시뮬레이터(이하 "코심(cosim)")는 RTL 시뮬레이터, ISS 및 병렬로 실행되는 다수의 기타 모니터/체커 태스크 사이의 게이트웨이 및 동기화 장치로서 작용한다. 진단은 RTL 및 ISS간에 오정합(mismatch)이 일어나자 마자 또는 가정 체커(assertion checker)가 돌발 이벤트(catastrophic event)를 시그널링할 때 실 패(fail)한다.

코시뮬레이션을 사용하는 장점은 여러가지가 있다. 첫째로, 실패 진단의 디버깅을 더욱 손쉽게 한다. 문제가 발생한 사이클에서(또는 근처에서) 시뮬레이션이 중단하도록 하는데, 이는 디버깅 시간과 노력을 현저하게 감소시킨다.

둘째로, 더 많은 상태 체크를 제공한다. 프로그램 실행을 통해 프로세서 상태의 관찰성(observability)을 허용함으로써, 에러있는 중간 결과를 생성하는 상기 케이스를 시그널링하는 한편, 올바른 최종 결과를 산출한다.

마지막으로, 코시뮬레이션에 의하면, 자가-체크가 필요없다. 랜덤 진단이 실행 및 체크될 수 있다.

바람직한 실시예에 있어서, ISS는 참조 모델이고, 바운더리들은 외부 이벤트가 발생할 때마다 명령어 퇴거(retirement)에 대하여 정의된다. 아키텍처럴하게 볼 수 있는 비교될 상태의 세트가 구성가능하다. 구성가능한 프로세서를 갖는 코심을 이용하는 한가지 이유는 RTL 및 ISS를 비교하는 프로세스에 관한 완전한 지식 부재 때문이다. RTL과 ISS를 비교하는 것에 대하여 알고 있는 것은, 명령어 퇴거 바운더리 및 외부 이벤트의 발생시 상기 비교가 발생하는 것이 필요하다는 것이다. 하지만, RTL과 ISS간에 비교되어야 하는 프로세서 상태는 사용자가 그 구성에 포함하도록 선택하는 프로세서 옵션에 좌우한다. 프로세서 옵션이 프로세서 코어의 특정 구성에 포함되지 않는 경우, 코심 환경은 상기 옵션에 의하여 도입된 상태를 비교하도록 시도조차 하지 않아야 하는데, 그 이유는 상기 상태가 RTL 또는 ISS 가운데 어느 하나에도 존재하지 않기 때문이다. 따라서, 바람직한 실시예는 구성가능한 코심 환경을 사용하여, 프로세서 구성시 소프트웨어 및 하드웨어에 따라 맞춤화된다.

코심이 TIE를 이용하여 작업하는 법

TIE를 이용하는 명령어 세트 뿐만 아니라 프로세서 상태를 확장하기 위한 사용자의 능력은 코심 프로세스를 복잡하게 하는데, 그 이유는 프로세서 상태 및 명령어 세트의 종래의 완전한 지식이 없이 코심 환경이 개발되도록 요구되기 때문이다. TIE의 존재에 있어서, 코심 환경은 신규 상태가 RTL과 ISS간에 비교될 바운더리를 결정하는 것 뿐만 아니라 비교/정당화되어야 하는 신규 프로세서 상태를 결정할 수 있도록 요구한다. 이들 두 가지 요구사항/목적을 달성할 수 있는 코심을 위하여, TIE로 정의된 신규 프로세서 상태에 관한 정보가 필요하다. 코심에 의하여 요구되는 정보는 신규 상태의 네임, 상태 요소의 폭, 상태를 정의하는 완전한 RTL 계층(경로), 상태가 리셋에 대하여 정의되는지의 여부, 개별적인 상태 또는 레지스터 파일인지의 여부 및 상태가 레지스터 파일인 경우의 엔트리의 수를 포함한다.

코심에 의하여 요구되는 정보는 3 단계의 사용자 TIE 기술로부터 생성된다. 첫째, 도 14에 도시된 바와 같이, TIE 컴파일러는 TIE 기술을 분석(parse)하고, 입력 파일에 정의된 상태의 중간 표현을 생성한다. 이 중간 표현은 신규 TIE 상태의 검증에 필요한 코심 소스 코드를 생성하도록 코심 프리프로세서에 의하여 순차적으로 사용된다. 최종적으로, 생성된 코심 코드는 주어진 구성에 대하여 독특한 코심 환경을 만들도록 코심 프레임워크(framework)의 나머지와 함께 통합된다. 이는 예를 들어 CA, 마운틴 뷰의 시놉시스사의 Vera^TM System Verifier로 구현된 Vera^TM 코시뮬레이션 언어로 코드를 생성하도록 tpp를 사용하여 행해지는 것이 좋다.

아래의 섹션은 앞서 제시된 Galois 필드 TIE 예시와 연계하여 얻어지는 생성된 코심 소스 코드 및 코심 프리프로세서의 예시를 포함한다.

CosimInfo.pm

# ---------------------------------------------------------- #

# CosimInfo.pm creates arrays which contains state and #

# register files information for TIE and the core. #

# ---------------------------------------------------------- #

@CosimInfo::EXPORT = qw(

@RegisterFiles

@SpecialRegister

@IntrType

@TieState

@TieRegister

@AllRegFiles

@AllSpecialRegs);

# ---------------------------------------------------------- #

# For a given configuration: #

# SpecialRegister contains all the core #

# special registers' names #

# RegisterFiles contains all the core #

# register files names #

# ---------------------------------------------------------- #

@SpecialRegister = map (CoreState ($_, 1),

grep($_->name ne 'MEM', $isa->state));

@RegisterFiles = map (CoreState ($_, 0),

grep($_-> name ne 'MEM', $isa->state));

# ---------------------------------------------------------- #

# For a given tie description: #

# TieState contains all the TIE states names #

# TieRegister contains all the TIE register files names #

# ----------------------------------------------------------- #

@TieState = map (TieState ($_, 1),

$pr->tie()->allStates());

@TieRegister = map (TieState($_, 0),

$pr->tie()->allStates());

@AllRegFiles = (@RegisterFiles, @TieRegister);

@AllSpecialRegs = (@SpecialRegister, @TieState);

# ---------------------------------------------------------- #

# TieState subroutine reads the TIE state and register #

# information from the configuration data base. #

# ---------------------------------------------------------- #

sub TieState {

my ($state, $tieState) = @_;

my $name = $state->name();

my $entries = $state->entries();

my $width = $state->width();

my $undefonreset = !($state->initialized());

my $regfile = $state->isRegFile();

if ($tieState) {

return if ($regfile);

[$name, $width == 1 ? 1 : $width, $undefonreset];

} else {

return if (!$regfile);

[$name, $width == 1 ? 1 : $width, $entries];

}

코심 소스 코드(Tie 레지스터 파일 비교):

; foreach (@TieRegister) {

; my ($regName, $regWidth, $regEntries) = @$_;

; for ($i = 0 ; $i < $regEntries ; $i++) {

; $tn = $regName . $i;

iss_ '$tn' =

$iss_read_register_bitvec('$i'+'$regName'_start);

if(rt1_'$tn'[index] != iss_'$tn') {

printf("Cosim @ cycle %Od PC %h:＼n＼tRTL != ISS TIE Reg

File '$tn' %h %h＼n＼n", current_cycle, rt1_spreg_pc[index],

rt1_'$tn'[index], iss_'$tn');

}

; }

코심 출력 프로그램(Tie 레지스터 파일 비교):

iss_gf0 = $iss_read_register_bitvec(0+gf_start);

if(rt1_gf0[index] != iss_gfO) {

printf("Cosim @ cycle %Od PC %h:＼n＼tRTL != ISS TIE Reg

File gfO %h %h＼n＼n", current_cycle, rt1_spreg_pc[index],

rtl_gf0[index], iss_gf0);

...

iss_gfl5 = $iss_read_register_bitvec(0+gf_start);

if(rtl_gfl5[index] != iss_gfl5) {

printf("Cosim @ cycle % Od PC %h:＼n＼tRTL != ISS TIE Reg

File gfl5 %h %h＼n＼n", current_cycle, rtl_spreg_pc[index],

rt1_gf0[index], iss_gfl5);

코심 소스 코드(Tie 상태 비교):

; foreach (@TieState) {

; ($sreg) = @$_;

// Checking Special Register '$sreg'

iss_'$sreg' = $iss_read_register_bitvec('$sreg'_map);

if(rt1_spreg_'$sreg'[index] != iss_'$sreg') {

iss_'$sreg' = $iss_read_register_bitvec('$sreg'_map);

printf("Cosim @ cycle %0d PC %h:＼n＼tRTL != ISS at TIE

State '$sreg' %0h %0h＼n＼n", current_cycle, rt1_spreg_pc[index],

rtl_spreg_'$sreg'[index], iss_'$sreg');

}

; }

코심 출력 프로그램(Tie 상태 비교):

// Checking Special Register gfmod

iss_gfmod = $iss_read_register_bitvec(gfmod_map);

if(rtl_spreg_gfmod[index] != iss_gfmod) {

iss_gfmod = $iss_read_register_bitvec(gfmod_map);

printf("Cosim @ cycle %Od PC %h:＼n＼tRTL != ISS at TIE State

gfmod %0h %0h＼n＼n", current_cycle, rt1_spreg_pc[index],

rtl_spreg_gfmod[index], iss_gfmod);

}

따라서, 요약하면, 바람직한 실시예에서 작업하기 위하여 Killian 등의 출원에 기술된 시뮬레이터를 채택하기 위하여, 상태에 대한 일반화와 일차적으로 관련된 많은 변경들이 이루어져야 한다. TIE 상태는 임의적으로 넓어질 수 있기 때문에, 임의적으로 크기가 정해지는 레지스터 값에 인터페이스가 필요하지만, 성능상의 이유로 해서 상기 인터페이스는 항상 사용되지 않는 것이 바람직하다. 이러한 이유로 해서, 레지스터들은 분류로 파티션되고, gdb 및 cosim 인터페이스는 단일의 정수 코드로부터 한 분류내에서 분류 및 인덱스를 발견할 수 있도록 수정된다. 소켓 인터페이스는 임의의 폭 값이 송수신될 수 있도록 변경된다. 신규 메모리 인터페이스는 넓은 로드 및 저장을 지원하는 것이 추가된다. TIE 상태의 초기화는 코프로세서로의 레지스터의 지정 및 레지스터 파일을 지원하도록 일반화된다. TIE 상태의 액세스와 관련된 시뮬레이팅 파이프라인 딜레이를 지원하는 것도 추가된다. TIE 상태로의 인터페이스는 CPENABLE 예외를 시뮬레이션하기 위하여 수정된다.

요약

상술된 주요 신규 TIE 구성을 요약하면, 그들이 영향을 끼치는 생성된 파일 및 그 일반적인 목적들은 아래 표 3에 주어진다.

구 조	생성된 파일	목적/태스크
ㆍ 또 다른 필드의 서브필드	ㆍ Libisa-<tie>.a ㆍ Libiss-<tie>.a ㆍ <tie>.v ㆍ customer.isa	ㆍ메모리-오더-의존형 필드 정의 지원
ㆍ TIE 모듈	ㆍ Libiss-<tie>.a ㆍ Cstub-<tie>.c ㆍ <tie>.v ㆍ Verification files	ㆍ복잡한 시맨틱 기술을 쓰지 않고 명령어의 효율적인 하드웨어 구현을 지원
ㆍ 레지스터 피연산자	ㆍ Libisa-<tie>.a ㆍ Libcc-<tie>.a ㆍ Libiss-<tie>.a ㆍ Cstub-<tie>.c ㆍ Xtensa-<tie>.h ㆍ <tie>.v ㆍ customer.isa	ㆍ 사용자-정의 레지스터 파일을 위하여 레지스터 피연산자를 갖는 명령어를 정의하기 위함 ㆍ 레지스터 파일 읽기/쓰기 포트 할당에 사용된 베이스 엔티티
ㆍ Iclass 인터페이스 절	ㆍ Xtensa-<tie>.h ㆍ Libiss-<tie>.a ㆍ <tie>.v ㆍ Cstub-<tie>.c ㆍ Verification files	ㆍ TIE 명령어 및 Xtensa 코어간의 인터렉션 캡처
ㆍ 인터페이스	ㆍ Libcc-<tie>.a ㆍ Libiss-<tie>.a ㆍ Cstub-<tie>.c ㆍ Xtensa-<tie>.h ㆍ <tie>.v	ㆍ TIE 명령어를 소정의 Xtensa 코어 기능성에 액세스하도록 함
ㆍ 스케줄	ㆍ Libcc-<tie>.a ㆍ Libiss-<tie>.a ㆍ <tie>.v ㆍ customer.isa	ㆍ 명령어의 다수사이클 구현을 생성 ㆍ 최대 효율성을 위한 스케줄 코드 ㆍ 정확한 클럭 사이클 카운트로 명령어를 시뮬레이션함
ㆍ Regfile	ㆍ Libisa-<tie>.a ㆍ Libcc-<tie>.a ㆍ Libiss-<tie>.a ㆍ Cstub-<tie>.c ㆍ Xtensa-<tie>.h ㆍ <tie>.v ㆍ customer.isa	ㆍ 더욱 효율적인 계산을 위하여 코프로세서 레지스터 파일을 사용함
ㆍ Synopsis ㆍ Description ㆍ Impl_note ㆍ Assm_note	ㆍ customer.isa	ㆍ TIE 명령어를 위한 문서화 생성
ㆍ Ctype	ㆍ Libcc-<tie>.a	ㆍ 프로그래밍 및 자동 레지스터 할당의 용이성을 위하여 C로 된 신규 데이터 형식 지원

ㆍ 프로토	ㆍ Libcc-<tie>.a ㆍ Xtensa-<tie>.h	ㆍ 자동 레지스터 할당을 위하여 부가적인 정보 제공 ㆍ C 형식의 자동 관습 지원 ㆍ 명령어 관용구 지원
ㆍ 참조	ㆍ Libisa-<tie>.a ㆍ Libcc-<tie>.a ㆍ Libiss-<tie>.a ㆍ Cstub-<tie>.c ㆍ Xtensa-<tie>.h ㆍ <tie>.v ㆍ customer.isa	ㆍ TIE 명령어를 위하여 참조 정의 제공 ㆍ TIE 명령어의 시맨틱 기술의 정확성을 체크
ㆍ 코프로세서	ㆍ Customer.isa ㆍ Libiss-<tie>.a	ㆍ 레이지 문맥 스위칭을 지원하기 위하여 레지스터 파일 및 상태를 코프로세서로 그룹화함

지금까지 본 발명을 바람직한 실시예와 연계하여 기술하였지만, 이는 단지 예시를 위한 목적으로 이루어졌으며, 본 발명은 이것에 제한되지는 않는다. 실제로, 본 발명의 변형은 당업계의 당업자에게는 명백한 것이고, 또한 본 발명의 범위내에서 가능하다.

Claims

구성가능한 프로세서를 설계하기 위한 시스템에 있어서,

상기 시스템은,

미리 결정된 부분 및 상기 프로세서의 사전-정의 명령문 세트에 부가된 1 이상의 사용자-정의 명령문들을 지원하는 사용자-정의 부분을 포함하는 구성 명세(specification)를 기초로 하여, 상기 프로세서의 하드웨어 구현의 기술(description)을 생성하기 위한 하드웨어 생성 수단을 포함하되, 상기 미리 결정된 부분은 코어 레지스터 파일의 구성을 특정하고, 상기 사용자-정의 부분은 상기 코어 레지스터 파일에 부가해서 사용자-정의 레지스터 파일을 상기 프로세서에 포함할 것이지 여부를 특정하고,

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

상기 하드웨어 생성 수단은, 상기 구성 명세의 사용자-정의 부분을 기초로 하여, 상기 코어 레지스터 파일의 기술에 부가해서 이 코어 레지스터 파일로부터 분리된 사용자-정의 레지스터 파일의 기술을 상기 프로세서의 하드웨어 구현의 기술에 생성하는 레지스터 생성 수단을 포함하고,

상기 소프트웨어 생성 수단은, 상기 사용자-정의 부분을 기초로 하여, 사용자-정의 프로세서 레지스터 파일에 관련된 소프트웨어를 상기 소프트웨어 개발 툴에 포함시키기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 사용자-정의 프로세서 레지스터 파일에 관련된 소프트웨어는, 명령어의 필드를 따라 레지스터 파일내의 요소(element)들을 액세스하기 위한 명령어를 포함하는 것을 특징으로 하는 시스템.
제2항에 있어서,

상기 하드웨어 생성 수단은, 레지스터 전송 레벨 하드웨어 기술 언어로 적어도 상기 하드웨어 구현의 상기 기술의 일부를 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 구성 명세는 상기 사용자-정의 레지스터 파일내의 요소의 폭(width)을 특정화하는 문장(statement)을 사용하여 상기 사용자-정의 레지스터 파일을 정의하는 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 구성 명세는 상기 사용자-정의 레지스터 파일내의 요소의 수를 특정화하는 문장(statement)을 사용하여 상기 사용자-정의 레지스터 파일을 정의하는 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 하드웨어 생성 수단은, 상기 구성 명세에 독립하여 상기 사용자-정의 레지스터 파일의 다수의 읽기 포트 및 쓰기 포트 중의 적어도 하나를 결정하기 위한 수단인 것을 특징으로 하는 시스템.
삭제
제1항에 있어서,

상기 하드웨어 생성 수단은, 상기 프로세서 하드웨어 구현 기술의 일부로서, 데이터 스테이지화 비용을 최소화하기 위하여 사용자-정의 레지스터 파일의 쓰기 포트를 명령어 피연산자에 지정(assign)하는 로직의 기술을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 하드웨어 생성 수단은, 상기 사용자-정의 레지스터 파일을 액세스하도록 파이프라인 로직을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제9항에 있어서,

상기 사용자-정의 레지스터 파일용 읽기 포트는, 소스 피연산자로서 그들을 사용하는 임의의 명령어의 가장 앞선 스테이지에서 판독되는 것을 특징으로 하는 시스템.
제9항에 있어서,

상기 사용자-정의 레지스터 파일용 쓰기 포트는, 목적 피연산자로서 그것을 사용하는 임의의 명령어의 최후 스테이지에서 또는 더 늦다면 명령어 커밋(commit) 스테이지에서 판독되는 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 하드웨어 생성 수단은, 상기 프로세서의 하드웨어 구현의 일부로서, 상기 사용자-정의 레지스터 파일을 액세스하는 명령어내에서, 상기 사용자-정의 레지스터 파일로부터 소스 피연산자를 선택하는데 사용되는, 각 필드를 위한 상기 사용자-정의 레지스터 파일용 읽기 포트를 제공하는 로직을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 하드웨어 생성 수단은, 상기 프로세서의 하드웨어 구현의 일부로서, 상기 사용자-정의 레지스터 파일을 액세스하기 위한 바이패스 로직을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제13항에 있어서,

상기 하드웨어 생성 수단은, 상기 구성 명세에서의 명령어 피연산자 및 상태 용법(usage) 기술을 기초로 하여, 상기 구성 명세에 의하여 기술된 프로세서의 주어진 파이프라인을 위한 인터록(interlock) 로직을 생성하기 위한 수단인 것을 특 징으로 하는 시스템.
제1항에 있어서,

상기 하드웨어 생성 수단은, 상기 프로세서의 하드웨어 구현의 일부로서, 상기 사용자-정의 레지스터 파일을 액세스하기 위한 인터록 로직을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제15항에 있어서,

상기 하드웨어 생성 수단은, 상기 구성 명세에서의 스케줄링 정보를 기초로 하여, 상기 인터록 로직을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제15항에 있어서,

상기 하드웨어 생성 수단은, 상기 구성 명세에서의 명령어 피연산자 및 상태 용법 기술을 기초로 하여, 상기 구성 명세에 의하여 기술된 프로세서의 주어진 파이프라인을 위한 인터록 로직을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 하드웨어 생성 수단은, 상기 사용자-정의 레지스터 파일의 액세스를 지원하기 위하여 상기 구성 명세의 미리 결정된 부분에 의하여 기술된 프로세서 로직의 적어도 일부분을 사용하도록 프로세서 하드웨어 구현 기술을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제18항에 있어서,

상기 프로세서 로직의 적어도 일부분은 어드레스 계산 로직을 포함하는 것을 특징으로 하는 시스템.
제19항에 있어서,

상기 어드레스 계산 로직은 주소 가산기 로직을 포함하는 것을 특징으로 하는 시스템.
제19항에 있어서,

상기 프로세서 로직의 적어도 일부분은 상기 구성 명세의 미리 결정된 부분과 사용자-정의 부분에 해당하는 프로세서의 부분들 사이에 공유된 데이터 정렬 로직을 포함하는 것을 특징으로 하는 시스템.
제19항에 있어서,

상기 프로세서 로직의 적어도 일부분은 데이터 메모리인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 구성 명세의 사용자-정의 부분은, 상기 사용자-정의 레지스터 파일에 조건적으로 기록하는 명령어의 기술을 포함하는 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 소프트웨어 생성 수단은, 상기 사용자-정의 레지스터 파일에 관련되는 소프트웨어의 일부로서, 상기 구성 명세를 기초로 하여 상기 프로세서의 제조 및 설계 검증을 위한 진단(diagnostic) 테스트를 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 구성 명세는 상기 프로세서의 명령어를 위한 참조 시맨틱(semantic) 및 구현 시맨틱 양자 모두를 포함하고,

상기 참조 시맨틱은 상기 구현 시맨틱의 설계 정확성을 검증하는데 사용될 수 있는 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 프로세서 명령어 세트 기술 언어는 명령어 테스트 케이스를 포함하고,

상기 소프트웨어 생성 수단은 상기 테스트 케이스용 진단을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 소프트웨어 생성 수단은, 어플리케이션을 실행하는 동안, 피연산자를 상기 프로세서 명령어 세트 기술 언어의 명령어로 샘플링하여 테스트 벡터를 자동으로 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 소프트웨어 생성 수단은, 레지스터 파일 및 사용자-정의 상태에 관련되는 소프트웨어의 일부로서 운영체제의 적어도 일부분을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제28항에 있어서,

상기 운영체제의 생성된 부분은 프로세서 상태를 위한 세이브(save) 및 재저장 시퀀스를 포함하는 것을 특징으로 하는 시스템.
제29항에 있어서,

상기 세이브 및 재저장 시퀀스는 구성요소 상태의 상호의존성 (interdependency)과 관련하여 생성되고, 상기 상호의존성에 대하여 유효(valid)한 것을 특징으로 하는 시스템.
제28항에 있어서,

상기 운영체제는 문맥(contexts)을 스위칭한 후의 새로운 태스크에 의해 다이나믹 레퍼런스(dynamic reference)에 따라 프로세서 상태의 전체보다 적게 세이브할 수 있는 것을 특징으로 하는 시스템.
제28항에 있어서,

상기 구성 명세의 사용자-정의 부분은, 상기 구성 명세의 미리 결정된 부분에서 발견되지 않은 소프트웨어 데이터 형식을 정의하고,

컴파일러는 상기 소프트웨어 데이터 형식을 지원하는 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 소프트웨어 생성 수단은, 상기 사용자-정의 레지스터 파일에 관련되는 소프트웨어의 일부로서 컴파일러, 링커, 시뮬레이터 및 디버거 가운데 적어도 하나를 생성하기 위한 수단인 것을 특징으로 하는 시스템.
제1항에 있어서,

상기 소프트웨어 생성 수단은, 상기 사용자-정의 레지스터 파일에 관련되는 소프트웨어의 일부로서 컴파일러를 생성하기 위한 수단이고,

상기 컴파일러는 프로그램 변수를 상기 사용자-정의 레지스터 파일의 레지스터에 할당할 수 있는 것을 특징으로 하는 시스템.
제34항에 있어서,

상기 컴파일러는 또한 메모리로부터의 값을 상기 사용자-정의 레지스터 파일의 레지스터로 로드하고, 상기 사용자-정의 레지스터 파일의 레지스터의 값을 메모리에 저장할 수 있는 것을 특징으로 하는 시스템.
제34항에 있어서,

상기 컴파일러는 또한 사용자-정의 레지스터 파일의 한 레지스터로부터의 값을 사용자-정의 레지스터 파일의 또 다른 레지스터로 이동시킬 수 있는 것을 특징으로 하는 시스템.
제34항에 있어서,

상기 컴파일러는 상기 사용자-정의 레지스터 파일을 액세스하는 소프트웨어 생성 수단에 의하여 생성된 소프트웨어에서의 명령어의 스톨(stall) 사이클을 결정하기 위하여 상기 구성 명세의 스케줄링 정보를 사용하기 위한 것임을 특징으로 하는 시스템.
제1항에 있어서,

상기 소프트웨어 생성 수단은 바이패스 경로의 커버리지(coverage)를 체크하기 위한 모니터를 자동으로 생성하기 위한 수단인 것을 특징으로 하는 시스템.
구성가능한 프로세서를 설계하기 위한 시스템에 있어서,

상기 시스템은,

미리 결정된 부분 및 상기 프로세서의 사전-정의 명령문 세트에 부가된 1 이상의 사용자-정의 명령문들을 지원하는 사용자-정의 부분을 포함하는 구성 명세를 기초로, 상기 프로세서의 하드웨어 구현의 기술을 생성하기 위한 하드웨어 생성 수단; 및

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

상기 구성 명세는 상기 소프트웨어 개발 툴에 사용되는 명령어의 스케줄링 정보를 특정화하는 문장을 포함하며,

상기 하드웨어 생성 수단은, 상기 구성 명세의 문장을 기초로 하여, 파이프라인 로직, 파이프라인 스톨링 로직 및 명령어 리스케줄링 로직 가운데 적어도 하나의 기술을 생성할지 여부 및 생성하는 방법을 결정하기 위한 것임을 특징으로 하는 시스템.
제39항에 있어서,

상기 스케줄링 정보는, 명령어의 피연산자가 주어진 스테이지에서 상기 프로세서의 파이프라인으로 들어가는 문장을 포함하는 것을 특징으로 하는 시스템.
제39항에 있어서,

상기 스케줄링 정보는, 명령어의 피연산자가 주어진 스테이지에서 상기 프로세서의 파이프라인을 빠져나가는 문장을 포함하는 것을 특징으로 하는 시스템.
제39항에 있어서,

상기 소프트웨어 생성 수단에 의하여 생성된 소프트웨어는 상기 구성 명세의 사용자-정의 부분에 기술된 명령어를 사용하는 컴파일러를 포함하고,

상기 컴파일러는 상기 구성 명세의 사용자-정의 부분에 기술된 명령어를 스케줄링하기 위하여 명령어 스케줄링하는 동안 스케줄링 정보를 사용하는 것을 특징으로 하는 시스템.
제39항에 있어서,

상기 구성 명세는 프로세싱될 복수의 프로세서 사이클을 요구하는 명령어의 기술을 포함하는 것을 특징으로 하는 시스템.
제43항에 있어서,

상기 구성 명세는 프로세서의 타겟 파이프라인에 독립적인 명령어의 시맨틱의 기술을 포함하고,

상기 하드웨어 생성 수단은, 프로세서 하드웨어 구현의 일부로서, 명령어 시맨틱으로부터 분리되어 있는 파이프라인 기술을 기초로 하여, 파이프라인을 생성하기 위한 수단인 것을 특징으로 하는 시스템.
구성가능한 프로세서를 설계하기 위한 시스템에 있어서,

상기 시스템은,

미리 결정된 부분 및 상기 프로세서의 사전-정의 명령문 세트에 부가된 1 이상의 사용자-정의 명령문들을 지원하는 사용자-정의 부분을 포함하는 구성 명세를 기초로 하여, 상기 프로세서의 하드웨어 구현의 기술을 생성하기 위한 하드웨어 생성 수단;

상기 구성 명세를 기초로 하여, 상기 하드웨어 구현에 대한 특정 소프트웨어 개발 툴을 생성하기 위한 소프트웨어 생성 수단; 및

상기 구성 명세를 기초로 하여, 상기 구성 명세에 의하여 기술된 확장된 프로세서 명령어 세트의 문서화(documentation)를 생성하기 위한 문서 생성 수단을 포함하는 것을 특징으로 하는 시스템.
제45항에 있어서,

상기 문서 생성 수단은, 상기 프로세서 명령어 세트 문서화를 생성하기 위하여 상기 구성 명세에 정의된 명령어의 참조 시맨틱을 사용하기 위한 것임을 특징으로 하는 시스템.
제45항에 있어서,

상기 구성 명세의 사용자-정의 부분은 그 안에 정의된 명령어의 참조 시맨틱 및 사용자-정의 명령어를 위한 시놉시스(synopsis) 및 텍스트 기술 가운데 적어도 하나의 사용자-정의 명세를 포함하고,

상기 문서 생성 수단은, 상기 프로세서 명령어 세트의 문서화를 생성하기 위하여 상기 시놉시스 및 텍스트 기술 가운데 적어도 하나를 사용하기 위한 것임을 특징으로 하는 시스템.
구성가능한 프로세서를 설계하기 위한 시스템에 있어서,

상기 시스템은,

미리 결정된 부분 및 상기 프로세서의 사전-정의 명령문 세트에 부가된 1 이상의 사용자-정의 명령문들을 지원하는 사용자-정의 부분을 포함하는 구성 명세를 기초로, 상기 프로세서의 하드웨어 구현의 기술을 생성하기 위한 하드웨어 생성 수단; 및

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

상기 구성 명세의 상기 사용자-정의 부분은, 프로세서 명령어가 예외(exception)를 올릴 때의 프로세서 예외의 사용자-정의 명세를 포함하며,

상기 하드웨어 생성 수단은 프로세서 하드웨어 구현의 일부로서 상기 사용자-정의 예외를 지원하는 하드웨어를 생성하기 위한 사용자-정의 예외 지원 생성 수단을 포함하는 것을 특징으로 하는 시스템.
삭제