KR20050010775A - 집적회로 설계를 관리하기 위한 장치 및 방법 - Google Patents

Abstract

본 발명은 전반적으로 반도체 설계와, 집적회로용의 컴퓨터 자동화된 설계의 분야에 관한 것이다. 보다 구체적으로, 본 발명은 구성, 설계 파라미터 및 시스템에 대한 설계의 기능성을 관리하기 위한 방법과, 주문자 명령어 및 다른 설계 요소가 설계자에 의해 제어될 수 있는 집적회로 설계를 제공한다.

Description

집적회로 설계를 관리하기 위한 장치 및 방법{APPARATUS AND METHOD FOR MANAGING INTEGRATED CIRCUIT DESIGNS}

집적회로(IC)를 설계 및 제조하는데 여러 가지 유형의 CAD 툴이 이용 가능하다. 이러한 CAD 툴 또는 자동화된 IC 설계 툴은 합성 및 최적화 프로세스 모두를 어드레스하는 모듈 또는 프로그램을 포함한다. 합성은 일반적으로 하이 레벨의 업스션에서 로우 레벨의 업스션으로 전환하는 자동화된 방법으로써 정의되며, 다야한 레벨의 업스션에서 발생하는 어떠한 요구된 합성 기술의 조합을 포함할 수도 있다. 소위 "동작적 합성(behavioral synthesis)"은 요구된 IC의 동작(예를들어, 입력, 출력 및 기능성)이 그 요구된 동작을 나타내는 조자를 설계하기 위해 컴퓨터 프로그램내에 입력되는 설계 툴이다. 이러한 툴은 IC 설계자로 하여금 간혹 수천만개의 논리 게이트 카운트를 가지며 핸드 레이아웃과 같은 수동 설계 기술로 가능해질 수 있는 것보다 상당히 더 짧은 시간 주기로 에러가 거의 또는 전혀 없는 복잡성과 처리 능력이 증가하고 있는 소자의 생산을 가능하게 한다.

상이한 레벨의 업스션을 수반하는 합성 프로세스의 예는 구성적 레벨 합성(architectural level synthesis)과 논리 레벨 합성(logic level synthesis)을 포함하며, 이들 모두는 IC 설계 공정에 통합될 것이다.

구성적 레벨 합성은 주로 회로의 거시적 구조에 관련되며, 그 거시적 구조는 기능 블록(블록의 상호접속 및 내부 기능성에 관한 정보를 포함한)을 활용한다. 구성적 레벨 합성은 레지스터 및 오퍼레이터와 같은 다중 비트 성분을 가질 수 있는 레지스터 전달 레벨(RTL : Register Transfer Level) 합성을 포함한다.

한편, 논리 레벨 합성은 게이트 레벨 설계와 관련된다. 논리 레벨 합성은 회로의 미시적 구조를 결정하며, 논리 모델을 라이브러리 셀의 인스턴스(instance)의 상호접속으로 변환한다. 논리 레벨 합성의 결과는 논리 소자 및 그들의 상호접속체의 네트리스트(netlist)가 된다. 논리-레벨 합성기(주로, 합성 "엔진"으로 지칭됨)는 여러 개의 상업적 공급자로부터 이용 가능하다.

합성 프로세스는 일반적으로 설계자가 타겟 소자의 요구된 기능성에 기초하여 IC 사양(specification)의 세트를 컴파일링하는 것으로부터 개시한다. 이러한 사양은 그리고나서 미국 뉴욕주 뉴욕에 소재한 IEEE로부터 이용 가능한 VHDL^?(VHSIC 하드웨어 묘사 엔진) 또는 미국 캘리포이나주 산타클라라에 소재한 Cadence Design System, Inc.로부터 이용 가능한 Verilo^?와 같은 하드웨어 묘사 엔진(HDL : Hardware Description Language)으로 인코딩된다. 사양은 IC에 대해 이용 가능 메모리 또는 클럭 속도와 같은 요구된 기능성뿐만 아니라 요구된 입력 및 출력을 정의한다. HDL로부터, 설계자는 그리고나서 게이트의 리스트 및 그 게이트들의 상호접속을 포함하는 "네트리스트"를 생성하며, 이것은 요구된 IC의 회로의 묘사가 된다. 궁극적으로, 설계는 컴파일되며, 물리적 IC를 생성하기 위해 제조된 매스크가 된다. 도 1은 종래 기술의 합성 기반 IC 설계 및 제조 방식을 예시한다. 이에 대해서는, 예를들어 2001년 11월 27일자로 Dangelo 등에게 허여된 "Method and systems for creating and validating low level description of electronicdesign"이라는 명칭의 미국 특허 제6,324,678호를 참조하기 바라며, 상기 특허에는 고레벨 묘사 및 사양으로부터 복잡한 디지탈 소자의 구조적 묘사를 생성하기 위한 방법학이 개시되어 있다. 방법학은 원래의 고레벨 묘사의 의도에 삽입된 의미론의 일치를 그리고 강화하기 위해 체계적인 기술을 사용한다. 설계 활성도는 필수적으로 다양한 레벨의 설계 표현에 대해 작용하는 일련의 변환이다. 각각의 레벨에서, 의도된 의미(의미론) 및 정규의 소프트웨어 조작은 설계 목표를 충족하는 더욱 상세한 레벨의 묘사 하드웨어를 구하기 위해 캡쳐된다. 방법학의 주요한 특징은 사용자의 컨셉, 의도, 사양, 묘사, 제한 및 트레이드오프를 캡쳐하는 것과, 구성적 분할과, 하이 레벨에서의 왓-이프 분석(what-if analysis)과, 크기 평가와, 타이밍 평가와, 구성적 트레이드-오프와, 실시 평가를 반영한 개념적 설계와, 타이밍 종결이다.

불행히도, 자동화된 IC 설계에 대한 전술한 종래 기술의 방식은 더 단순한 소자 및 단일 부품에 대해서는 잘 적용되지만, 특히 CPU 기반 프로세서와 같은 더욱 복잡한 IC의 설계에 적용할 경우에는 여러가지 한계점을 겪는다. 이러한 문제점은 대체적으로 명령어가 설계 및 합성 프로세스 동안에는 수정할 수 없고 설계 및 합성 프로세스 전에 수정되어야만 하는 조건으로부터 야기되며, 그에 의해 설계 프로세스 동안 및 설계 프로세스 후에 설계자에게 주어지는 유연성 및 능력이 경감된다. 이러한 문제점은 프로세서를 자신의 시스템 집적회로 설계에 집적하고자 희망하는 사용자에게 사전정의된 CPU 설계를 제공하려고 실시할 때에 두드러지게 나타난다. 특히, 합성 동안의 설계에서 특정 명령어, 함수 및 부품을 고려할 수 없게 됨으로써, 설계자는 이들 부품을 설계에 재적합화(backfit)하려고 시도하도록 요구되며, 이것은 종종 호환성 문제 또는 다른 문제점을 야기한다. 이러한 조작의 불가능은 또한 그 결과의 설계가 필수적으로 더 높은 게이트 카운트를 갖고 아울러 요구된 아키텍쳐 및 기능성 고유의 주문형 명령어의 이점을 갖지 못하기 때문에 특정 파라미터(다이 크기 또는 클럭 속도와 같은)에 대한 설계의 최적화를 배제시키는 영향을 갖는다. 더욱이, 이러한 종래 기술의 시스템은 완전한 프로세서의 HDL 모델을 자동적으로 어셈블링하고 그 프로세서의 동작은 설계 공정의 효율 및 유효성을 상당히 증가시킬 수 있는 방식으로 시뮬레이션하는 것이 불가능하다.

사용자 구성가능성 및/또는 확장가능성에 대한 전술한 문제점을 해소하기 위한 여러 방식이 개발되고 있다. 그 중에서도 가장 주목할 만한 것은 최초의 진정한 사용자 구성가능한 대화식 프로세서 설계 환경인 본 출원인에 의해 개발되어 시판되고 있는 "ARChitect" 사용자 구성가능한 설계 환경이다. ARChitect 구성 툴은 기본형(basecase) 프로세서 구성을 주문하는 것을 용이하게 하는 포인트-앤드-클릭(point-and-click) 사용자 인터페이스를 갖는다. 화면을 통해 진행하고 메뉴, 개발자 및 신규 명령어로부터 옵션을 선택함으로써, 명령어/데이타 캐시를 구성하고, DSP 확장범위를 선택하며, 스크래치패드 메모리(scratchpad memory)를 추가하며, 입터럽트를 구성하고, 주변장치를 집적하며, 기본 프로세서 아키텍쳐의 다수의 다른 특징을 주문한다. ARChitect 툴은 주문 설계의 블록도와 프로그래머의 모델을 디스플레이할 수 있으며, 이것은 요구된 게이트의 수를 개발자에게 알려준다. ARChitect 툴은 RTL 파일, 합성 스크립트 및 주문 설계에 대한HTML 포맷의 문서를 자동적으로 생성한다. ARChitect는 또한 예를들어 (ⅰ)ARC 프로세서에 대한 명령어 세트 시뮬레이터외에도 High C/C++ 컴파일러, 링커, 어셈블러, 프로파일러 및 SeeCode™ 태스크-어웨어 디버거를 제공하는 MetaWare High C/C++™ Tool Suite, (ⅱ)신포 처리 알고리듬에 의해 생성된 데이타의 그래픽적 시청화면을 제공하고, DSP 확장으로 구성된 ARC 프로세서에 대한 DSP 소프트웨어의 개발 테스트를 현저하게 가속화할 수 있는 ARC Siganl Visualization Tool(SVT), 및 (ⅲ)CASSEIA(Cycle-Accurate Signal Simulator with Extensible Instruction Architecture) 개발 및 검증 툴을 포함하는 다른 개발 툴과 호환 가능하다.

프로세서 설계에 대한 다른 접근은 2002년 11월 5일자로 Killian 등에게 허여된 "Automated processor generation system for designing a configurable processor and method for the same"이라는 명칭의 미국 특허 제6,477,683호에 설명되어 있으며, 상기 특허는 자동화된 프로세서 설계 툴을 개시하고 있다. 이 툴은 목표 명령어 세트의 구성 가능한 정의를 개발하기 위해 표준화된 언어의 주문형 프로세서 명령어 세트 확장부에 대한 묘사와, 그 명령어 세트를 실행하기 위해 필요한 회로의 HDL(하드웨어 묘사 언어) 묘사와, 프로세서에 대한 어플리케이션을 개발하고 이를 검증하기 위해 사용될 수 있는 컴파일러, 어셈브러, 디버거 및 시뮬레이터와 같은 개발 툴을 포함한다. 프로세서 회로의 실시는 면적, 전력 소비, 속도 등과 같은 다양한 기준에 대해 최적화될 수 있다. 프로세서 구성이 개발된 후, 이 프로세서 구성은 테스트될 수 있으며, 프로세서 실시를 반복적으로 최적화도록 수정된 채로 시스템에 입력된다.

유사하게, 2002년 11월 5일자로 Killian 등에게 허여된 "Adding Complex Instruction Extension Deined In A Standardized Language To A Microprocessor Design To Produce A Configurable Definition Of A Target Instruction Set, And HDL Description And Verification Tools For The Instruction Set"라는 명칭의 미국 특허 제6,477,697호 또한 자동화된 프로세서 설계 툴을 개시하고 있다. 상기 특허에 개시된 표준화된 언어는 프로세서 상태를 수정하거나 또는 구성 가능한 프로세서를 사용하는 명령어 세트 확장부를 처리할 수 있다.

상기의 미국 특허 제6,477,683호에 교시된 "묘사" 언어(TIE 또는 Tensilica Instruction Extension)는 복잡하면서도, 정의할 수 있는 명령어의 타입이 제한된다. 특히, TIE-정의된 명령어는 특수한 레지스터내에 저장된 임의의 정보, 즉 프로세서 상태를 액세스하거나 수정할 수 없으며, 이것은 획득 가능한 명령어의 범위를 현저하게 제약하고, 그에 따라 달성 가능한 성능 향상의 양을 제한한다.

소위 "하드웨어/소프트웨어 공동-설계"로 지칭되는 다수의 방식이 종래 기술로 교시되어 있다. 예를들어, 프로세서의 다수의 특징적 동작(예를들어, 명령어 세트) 및 구조적 묘사가 제안되어 있다. 이에 대해서는, 예를들어 1998년 10월의 "EXPRESSION: An ADL for System Level Design Exploration" 기술 보고서 제98-29호와, 1996년 10월의 Zivojnovic 등의 "LISA-Machine Description Language and Generic Machine Model for HW/SW Co_Design"를 참조하기 바란다. 또한, 1997년 DAC의 Hadjiyiannis 등의 "ISDL: An Instruction Se Description Language for Retargetability"을 참조하기 바란다. Cadence nML 언어 또한 그에 대해 언급하고있으며, 이에 대해서는 1997년 6월의 ACM의 페이지 303~306에의 Hartoog 등의 "Generation of Software Tools From Processor Descriptions for Hardware/Software Codesign"을 참조하기 바란다.

다소 유사한 공동-설계 방식이 1998년 1월의 DEsign Automation for Embedded Systems의 vol.3의 Leupers 등의 "Retargetable Code Generation based on Structural Processor Descriptions"에 개시되어 있으며, 이 문서에는 MIMOLA/TREEMOLA 설계 언어 및 툴 스위트이 개시되어 있다. MIMOLA 방식은 라지 익스텐트 기어드 투워드 사이클-어큐레이트 동작(명령) 모델링 및 시뮬레이션(a large extent geared toward cycle-accrate behavior(instruction) medeling and simulation)이 되는 표현식 nML, LISA 또는 ISD 방식보다 하드웨어 묘사 언어(예를들어, VHDL과 같은)에 더욱 유사하다.

1997년 9월 7일자로 Fritz에게 허여된 "Method for the generation of ISA simulators and assemblers from a machine description"이라는 명칭의 미국 특허 제5,949,993호는 하드웨어 및 소프트웨어 개발에 사용될 소프트웨어 개발 툴을 생성하기 위한 방법을 개시하고 있다. 상기 특허는 마이크로프로세서와 같은 프로그래밍 가능한 전자장치의 신택스 뮤사 및 하드웨어 묘사를 처리하고 하드웨어 및/또는 소프트웨어 개발자에 유용한 개발 툴의 세트를 생성한다. 이러한 툴의 일부는 예를등어, 시뮬레이터, 어셈블러, 디코더, 디스어셈블러, 동작 의미론 및 속성 그래머를 포함한다. 그러나, Fritz는 설계의 ㅎ드웨어 묘사 언어 표현식에 확장부 및 다른 특징을 추가하는 관점으로부터 명백한 사용자 구성 가능성을 교시하지 못했다. Fritz는 필수적으로 하드웨어 묘사 모델(예를들어, VHSL 모델)을 소프트웨어 툴의 생성을 위한 입력으로써 사용한다.

이들의 각각의 특징에도 불구하고, 사용자 주문 프로세서 설계에 대한 전술한 솔루션은 최적의 것이 아니다. 특히, 상당한 복잡성 및/또는 "수동" 주문화이 이들 솔루션 중의 다수의 것의 특징이며, 이에 의해 특히 이러한 설계 태스크가 둘 또는 그 이상의 엔티티 또는 개인에 걸쳐 분포된 곳에서는 상이한 설계 태스크 및 목표에 대한 유연성 및 적합화성을 겸감시킨다.

전술한 종래 기술의 솔류선은 또한 설계 생성 프로세스가 관리 가능하도록 그들의 작동 및 최소로 유지된 설계 변수의 수에 있어서 제약되며, 작동에 있어서 제약된다는 것은 기본으로써 사용된 설계가 그 시작점에서 제약된다는 것을 의미한다. 그러나, 이것은 설계자가 전술된 "제약된" 모델에 적합하지 않는 설계 공간을 탐색하기 원할 때 설계자를 제한한다.

또한, 설계 툴 구성은 사용자의 특정 태스크 또는 프로젝트에 대체로 부합하지만, 사용자에 의해 적합화하거나 확장 가능하지 않다.

전술한 내용을 토대로, 구성이 프로세서 및 유사 소자에 대한 명령어 세트를 포함하도록 사용자에 의해 반복적으로 변경될 수 있는 집적회로 설계의 구성, 설계 파라미터 및 기능성을 관리하기 위해 향상된 방법 및 관련 장치는 요구된다. 특히, 이러한 향상된 방법은 사용자가 요구된 설계 속성(확장 명령어, 캐시 구성 등과 같은)을 신속하게 선택하고 이러한 선택에 기초하여 설계를 생성하도록 할 수 있을 것이다. 이러한 생성된 설계는 그리고나서 반복적으로 평가될 수 있고, 최소의 시간과 노력으로 요구된 바와 같이 수정될 수 있다. 이러한 향상된 설계 장치는 또한 그 구성에 있어서 매우 높은 유연성을 가져, 추가의 기능성을 용이하게 할 환경에 플러그-인 또는 추가의 툴을 추가함에 의해서와 같이 IC 설계 자체뿐만 아니라 설계 환경을 요구된 바대로 사용자가 "확장"시킬 수 있도록 한다. 이러한 소프트웨어 환경은 또한 설계 프로세스가 설계자에게(특히, 비숙련자에게) 더욱 명백해지게 하여, 시스템의 장래의 사용자 기반을 증가시킬 것이다. 또한, 다른 환경과도 호환 가능하게 될 것이며, 그에 따라 개별적인 설계자가 다른 환경, 기기 및 네트워크에 걸쳐 정보를 공유할 수 있게 될 것이다.

본 출원은 2002년 4월 25일자로 출원된 "Apparatus And Method for Managing Integrated Circuit Designs"라는 명칭의 미국 가출원 일련번호 60/375,997를 그 우선권으로 하며, 이 출원은 본 명세서에 그 전체내용이 참조된다(가출원에 포함된 모든 부록 포함). 본 출원은 또한 1998년 10월 14일자로 출원된 미국 가출원 일련번호 60/104,271을 우선권으로 하는 1999년 10월 14일자 출원된 "Method Ans Apparatus for Managing The Configuration And Functionality Of A Semiconductor Design"이라는 명칭의 현재 계류중인 미국특허 출원 번호 09/418,663호에 관련되며, 상기 특허 출원 또한 그 전체 내용이 본 명세서에 참고자료로 통합된다.

본 특허 명세서의 상세한 설명의 일부는 저작권 보호의 대상이 되는 물질을 포함하고 있다. 저작권 소유자는 그 물질이 특허청 특허 파일 또는 기록문서에 등재되어 있기 때문에 특허 명세서 또는 명세서의 상세한 설명 중의 어느 곳에서의 유사한 재생에 반대하지 않지만, 그 밖의 경우는 어떠한 것이든 모든 저작권에 의해 보호된다.

본 발명은 전반적으로 반도체 설계와, 집적회로용의 컴퓨터 자동화된 설계의 분야에 관한 것이다. 보다 구체적으로, 본 발명은 구성, 설계 파라미터 및 시스템에 대한 설계의 기능성을 관리하기 위한 방법과, 주문자 명령어 및 다른 설계 요소가 설계자에 의해 제어될 수 있는 집적회로 설계를 제공한다.

도 1은 일례의 프로세서 코어 및 관련 성분에 대한 블록도이다.

도 2는 본 발명에 따른 IP 프로젝트와 IP 라이브러리간의 관계에 대한 그래픽적 표현도이다.

도 3은 본 발명에 따른 일례의 IP 라이브러리에 대한 그래픽적 표현도이다.

도 4는 본 발명에 따른 설계를 작성함에 있어서 사용된 다양한 구조에 대한 그래픽적 표현도이다.

도 5는 도 4의 구조와 관련된 설계 계층의 그래픽적 표현도이다.

도 6은 일례의 프로젝트 디렉토리 구조의 그래픽적 표현도이다.

도 7은 2개의 설계 성분을 결합하는 일례의 링크에 대한 그래픽적 표현도이다.

도 8은 일례의 성분 계층에 대한 그래픽적 표현도이다.

도 9 내지 도 9c는 성분의 그룹화에 대한 다양한 도면으로, 복잡한 시스템에 대한 그래픽적 표현도이다.

도 10은 자신의 라이브러리 및 확장부를 갖는 성분과 함께 일례의 코어에 대한 그래픽적 표현도이다.

도 11은 본 발명에 따른 다중-코어 IC 설계를 생성하는 방법을 예시하는 논리 흐름도이다.

도 12는 일례의 코어 템플릿에 대한 그래픽적 표현도이다.

도 13은 일례의 행 템플릿에 대한 그래픽적 표현도이다.

도 14는 도 11의 다중-코어 IC에 대한 그래픽적 표현도이다.

도 15는 일례의 논리적 머신 디렉토리 구조에 대한 그래픽적 표현도이다.

도 16은 다수의 프로젝트에 대해 다수의 라이브러리를 갖는 다른 예의 구성을 예시하는 도면이다.

도 17은 2개의 코어를 포함하고 있는 설계 프로젝트의 일례의 칩 성분에 대한 그래픽적 표현도이다.

도 18은 도 17의 설계 프로젝트에 대한 일례의 디렉토리 구조를 그래픽적으로 예시하는 도면이다.

도 19는 신규 확장부의 설계를 유지하기 위해 코어1 내부의 라이브러리의 사용을 그래픽적으로 예시하는 도면이다.

도 20은 도 18 및 도 19의 프로젝트를 위한 디렉토리 구조에 대한 그래픽적 표현도이다.

도 21은 2개의 확장된 코어를 갖는 일례의 프로젝트를 그래픽적으로 예시하는 도면이다.

도 22는 본 발명에 따른 일례의 단일 사용자 개발 시스템을 예시하는 기능 블록도이다.

도 23은 (ⅰ)다수의 사용자, (ⅱ)단일 IP 라이브러리, (ⅲ)다수의 IP 프로젝트를 갖지만 (ⅳ)소스 코드 제어 시스템은 갖지 않는 일례의 다수의 사용자 개발 시스템을 예시하는 기능 블록도이다.

도 24는 SCCS를 갖는 일례의 단일 사용자 개발 시스템을 예시하는 기능 블록도이다.

도 25는 SCCS를 갖는 일례의 다중-사용자 시스템을 예시하는 기능 블록도이다.

도 26은 일례의 다중-사용자 다중-라이브러리 개발 시스템을 예시하는 기능 블록도이다.

도 27은 SCCS를 갖는 일례의 다중-사용자 다중-라이브러리 시스템을 예시하는 기능 블록도이다.

도 28은 일례의 다중-사용자 다중-라이브러리 다중-프로젝트 개발 시스템을 예시하는 기능 블록도이다.

도 29는 본 발명에 따른 일례의 디렉토리 구조내의 클래스 저장을 예시하는 도면이다.

도 30은 본 발명에 따른 공통 프로젝트 및 그 프로젝트의 결과 라이브러리 구조의 예를 예시하는 도면이다.

도 31은 일례의 ARCtangent 코어의 IP의 디렉토리 구조를 예시하는 도면이다.

도 32는 도 30의 코어와 관련된 일례의 디렉토리 구조를 예시하는 도면이다.

도 33은 일례의 프로젝트의 성분 타입 및 성분 인스턴스를 위한 디엑토리 구조를 에시하는 도면이다.

도 34는 2개의 예의 설계 성분, 이 성분의 사이트 및 이 사이트를 결합시키는 링크를 예시하는 블록도이다.

도 35는 인터페이스를 위한, 고정된 속성값을 갖는 툴 데이타의 사용을 예시하는 도면이다.

도 36은 고정된 속성값 대신 스크립팅을 사용하는 일례의 툴 데이타를 예시하는 도면이다.

도 37은 일례의 성분 작업(context) 및 다른 성분에 대한 그 성분 작업의 관계에 대한 그래픽적 표현도이다.

본 발명은 대화식 컴퓨터 프로그램의 사용을 통해 집적회로 설계의 구성, 설계 파라미터 및 기능성을 관리하는 자동화된 수단을 제공함으로써 전술된 요구를 충족시킨다.

본 발명의 일특징으로, 집적회로 설계의 구성, 설계 파라미터 및 기능성을 관리하기 위한 향상된 방법이 개시된다. 상기 방법은 종래 기술에 비해 실질적으로 "반복적인" 설계 프로세스를 채용하며, 이에 의해 설계자가 설계자의 확장 성분(확장 명령어 또는 주변 성분)을 소프트웨어 라이브러리내에 집적하는 것이 가능하게 된다. 이것은 라이브러리로부터 설계 묘사를 구축함으로써 추가 확장 성분이 구조내에 자동적으로 집적된다는 것을 의미한다.

본 발명의 제2 특징으로, 전술된 방법은 집적회로의 구성을 설계 및 관리하기 위해 마이크로컴퓨터 또는 다른 유사 소자와 합동으로 사용될 수도 있는 컴퓨터프로그램에 추가로 삽입된다. 일례의 실시예에서, 이 컴퓨터 프로그램은 다양한 세트 또는 그룹의 관련 기능을 수행하는 성분과의 객체 지향 환경을 포함한다. 일변형예에서, 확장가능한 마크업 랭귀지(XML), 자바 및 자바스크립트의 조합이 정적 및 동적 데이타 모두를 저장하기 위해 사용된다.

제2 실시예에서, 현존의 비객체 지향 프로그램은 이러한 비객체 지향 어플리케이션을 역으로 적합하게 하기 위해 적합화된 향상된 "툴셋" 모듈로 구성된다.

본 발명의 제3 특징에서, 전술된 방법을 사용하여 집적회로 설계를 생성, 시뮬레이션 및/또는 합성하기 위한 장치가 개시된다. 일실시예에서, 마이크로프로세서, 디스플레이 장치 및 입력 소자를 갖는 마이크로컴퓨터는 이전에 언급된 컴퓨터 프로그램을 실행하기 위해 사용되며, 이에 의해 설계자는 설계, 시뮬레이션 및/또는 합성 프로세스 동안 프로그램과 대화할 수 있게 된다. 마이크로컴퓨터는 전술된 컴퓨터 프로그램으로 구성된 2개 또는 그 이상의 마이크로컴퓨터간의 정보의 저장, 검색 및 공유를 허용하기 위해 저장 장치 및 네트워크 인터페이스를 추가로 포함한다.

본 발명의 제4 특징에서, 복수의 성분을 갖는 집적회로 설계내의 계층을 발생하기 위한 방법이 개시된다. 상기 방법은 각각이 제1 유형의 사이트를 갖는 복수의 성분 중의 적어도 일부에 코드를 제공하는 단계와, 코드없이 복수의 성분 중의 상기의 것에 관해 제2 유형의 사이트를 정의하는 단계와, 상기 제1 사이트 및 제2 사이트의 적어도 일부를 결합시켜 계층을 발생하는 단계를 포함한다.

본 발명의 제5 특징에서, 복수의 성분을 갖는 집적회로 구조를 발생하기 위한 방법이 개시된다. 본 방법은 각각이 제1 유형의 사이트를 갖는 복수의 성분 중의 적어도 일부에 코드를 제공하는 단계와, 코드없이 복수의 성분 중의 상기의 것에 관해 제2 유형의 사이트를 정의하는 단계와, 상기 제1 사이트 및 제2 사이트의 적어도 일부를 결합시켜 계층을 발생하는 단계와, 계층에서의 최상단 성분에게 그 성분의 코드에 대해 질의하는 단계와, 최상단 성분으로부터 코드를 판독하는 단계와, 최상단 성분에 링크된 적어도 하나의 성분으로부터 코드를 합병하는 단계와, 구조를 발생하기 위해 계층에 걸쳐 질의 단계와 합병 단계의 동작을 반복하는 단계를 포함한다.

본 발명의 제6 특징에서, 하드웨어 묘사 언어로 묘사되고 전술한 본 발명의 방법을 이용하여 합성된 집적회로 설계가 개시된다. 일례의 실시예에서, 집적회로는 임베디드 어플리케이션(embedded application)에서 사용된 확장된 RISC 프로세서를 포함한다.

본 발명의 제7 특징에서, 전술된 합성된 설계를 사용하여 제조된 집적회로가 개시된다. 일례의 실시예에서, 집적회로는 파이프라인형 감소 명령어 세트 CPU(RISC) 프로세서를 포함한다.

본 발명의 제8 특징에서, 전술된 프로그램은 완전한 자바스크립트 디버거를 포함하며, 상기 디버거는 사용자로 하여금 자신의 데이타에 대한 브레이크포인트를 설정할 수 있도록 하고, 사용자가 실제 설계 프로젝트에서 발생시킬 때의 각종 계산 및 연산을 처리하여 나아갈 수 있도록 한다.

본 발명의 제9 특징에서, 영구 저장장치에 성분 인스턴스를 정장하는 향상된방법이 제공된다. 일례의 실시예에서, 운영체계(OS) 파일 시스템은 간략한 계층적 데이타 구조로 데이타를 저장하기 위해 사용된다. 이와 달리, 파일에 대해 운영체계 동작을 모방하도록 시스템 API 기능의 사용을 통해 동일한 기능을 달성하기 위해 dBase, 오라클 및 유사 데이타베이스 관리 시스템과 같은 데이타베이스 관리자가 채용될 수도 있다. 표준 파일 시스템을 사용한다는 것은 사용자가 자신의 프로젝트르 관리하기 위해 사용하는 다수의 기존 툴을 갖는다는 것을 의미한다.

본 발명의 제10 특징에서, 관리가 용이하고 조직적 명명법(nomenclature)으로부터 자유로운 향상된 설계 라이브러리 구조가 제공된다. 이 구조는 라이브러리내의 성분이 고유하게 명명되어, 상이한 설계 엔티티가 동일 명칭으로 성분을 생성하지 않도록 할뿐만 아니라 객체(즉, 자바)를 집적하는 메쏘드가 라이브러리 구조로 분류되도록 하는 것을 포함한다.

본 발명의 제11 특징에서, 사이트-바이-사이트를 기초로 디폴트 접속 방식을 특정하기 위한 향상된 방법이 제공된다. 이것은 모든 성분에 적합한 하나의 방식이 존재하지않아 소정 세트의 성분과 함께 사용될 수 있는 다수의 상이한 접속 방식이 존재하기 때문에 요구된다. 본 발명은 성분의 작성자가 그 작성자의 성분에 관한 각각의 사이트(인터페이스)에 대해 접속 방식을 특정하할 수 있도록 한다. 이 방식은 스크립트(예를들어, 자바스크립트)의 일부분 또는 클래스(자바 클래스) 중의 하나로써 코딩되며, 이 스크립트/클래스는 성분을 연결시키는 방법에 대한 정보를 시스템에 제공하기 위해 실행된다.

본 발명의 제12 특징에서, 프로젝트 또는 설계 블록의 템플릿(template)을생성하기 위한 향상된 방법이 개시된다. 템플릿은 라이브러리에 저장되며, 다른 설계자 또는 엔진의 최종 사용자에게 전체 또는 일부가 분배될 수 있다. 더욱이, 설계자는 동일 성분 또는 블록의 다수의 인스턴스를 가지고 설계를 작성하기 위해 여러 번 인스턴스된(instantiated) 단일 템플릿을 사용할 수 있다. 템플릿을 변경시키는 것은 성분/블록의 인스턴스의 전부를 동시에 변경시키며, 그에 의해 한 성분씩의 수정이 방지된다.

본 발명의 제13 특징에서, GUI를 관리하는 향상된 방법이 개시된다. 본 발명은 성분 정의 일부인 GUI를 사용하여 개시한다. 이 기능성을 인에이블시키기 위해, GUI 코드의 일부분은 성분과 함께 분배된다. 일례의 실시예에서, 자바 랭귀지는 GUI 객체를 포함하는 크로스플랫폼(cross-platform) 코드를 정의하기 위해 사용된다. 이 코드는 코드를 재컴파일할 필요없이 실행시 GUI 내로 플러그될 수 있다. GUI 루틴(예를들어, "위저드")은 객체 클래스로 분배되어, 이들이 실행 어플리케이션내에 동적으로 포함될 수 있다.

본 발명의 제14 특징에서, 변경된 설계 성분에 관한 정보의 디스플레이를 관리하기 위한 향상된 기술이 제공된다. 일실시예에서, 성분은 하나 또는 그 이상의 카테고리화 기준에 기초하여 카테고리화되며, 이 카테고리 정보를 포함하도록 구성된다. 그러므로, 디스플레이/GUI 기능은 성분을 이들 성분의 카테고리 속성에 기초하여 식별할 수 있고, 이들 성분을 요구된 바대로 디스플레이할 수 있다.

본 발명의 제15 특징에서, 성분 종속성 및 제약을 관리하기 위한 향상된 방식이 개시된다. 설계 종속성/제약에 관련된 데이타는 성분 정의부 자체에 저장된다. 이러한 종속성은 이들 종속성을 요구된 바대로 복잡하게 되거나 단순하게 되도록 하는 스크립트(예를들어, 자바스크립트) 또는 자바 클래스로써 표현된다.

추가로, 본 발명은 "구조 계층"을 작성하기 위해 각각의 성분으로부터 구조 정보를 사용함으로써 정보의 인캡슐레이션(encapsulation)을 이용한다. 다양한 성분에 관해 소위 말하는 "부모" 사이트 및 "자녀" 사이트가 정의되며, 이에 의해 성분이 링크에 의해 결합될 때의 구조 계층을 효율적으로 특정한다.

본 발명의 제16 특징에서, "플러그-인"의 사용자 추가를 도모하고 용이하게 하는 사용자-확장가능한 툴셋이 개시된다. 일실시예에서, 자바 클래스 파일이 저장 장치의 소정 디렉토리에 배치된다. 툴은 자바 반영 메카니즘을 사용하여 그 디렉토리내의 클래스를 검사하며, 이에 의해 툴에 의한 플러그-인의 사용을 용이하게 한다.

본 발명의 제17 특징에서, "도트" 오퍼레이터를 사용하여 데이타를 어드레스하는 향상된 방법이 개시된다. 시스템의 라이브러리에 저장된 스크립트는 "도트" 오퍼레이터를 사용하여 정보(성분 타입 또는 인스턴스로부터의 데이타를 포함)를 검색하는 메쏘드가 제공된다. 시스템내의 경로는 서브성분(서브성분의 첫번째는 타입 또는 인스턴스 데이타를 나타냄)으로 분기되며, 각각의 후속 서브성분은 그 기능과 관련된 하나 또는 그 이상의 객체를 리턴하도록 순차적으로 호출(invocation)된다.

본 발명의 제18 특징에서, 집적회로의 설계를 발생하기에 적합화된 향상된 컴퓨터로 처리되는 시스템이 개시된다. 일례의 실시예에서, 설계는 인캡슐레이션화된 객체에 의해 표현된 복수의 성분을 포함하며, 객체는 각각 다른 객체와의 적어도 하나의 인터페이스를 가지며, 적어도 하나의 인터페이스는 그 인터페이스를 가로질러 전송된 데이타에 관한 정보를 포함하고 있다. 예를들어, 복수의 성분은 프로세서 코어 및 확장 명령어를 포함할 수 있으며, 정보는 확장의 시행을 위해 코어와 관련된 HDL에 적합화되어야만 하는 HDL을 포함한다. 정보는 요구된 데이타를 검색하기 위해 실행기 평가되는 스크립트를 포함할 수 있다.

본 발명의 제19 특징에서, 닙적회로의 설계를 발생하기 위한 향상된 컴퓨터로 처리되는 시스템이 개시된다. 일실시예에서, 적어도 하나의 확장 가능한 GUI 트리가 제공되며, 확장 가능한 GUI 트리는 사용자가 트리와 적어도 하나의 플러그-인 모듈간의 관계를 특정할 수 있도록 해준다.

본 발명의 제20 특징에서, 사용자에 의해 선택된 특정 구성과 관련된 주문 문서를 자동적으로 발생하도록 적합화된 향상된 설계 시스템이 개시된다.

본 발명의 제21 특징에서, 집적회로 설계를 발생하기 위한 컴퓨터로 처리되는 시스템이 개시되며, 여기서 구조 시퀀스는 사용자가 상기 설계의 발생이 제공되는 동안 복수의 별도의 구조 시퀀스 중의 하나 또는 그 이상을 선택적으로 사용할 수 있도록 적합화된다.

본 발명의 제22 특징에서, 설계내의 각각의 성분에 의해 제공된 정보에 기초하여 설계의 기하학적인 표현을 발생하기 위해 적합화된 적어도 하나의 모듈을 포함하는 집적회로의 설계를 발생하기 위한 컴퓨터로 처리되는 시스템이 개시된다.

이하에서는 도면을 참조하여 본 발명을 설명하며, 동일 도면부호는 전체에 걸쳐 동일 구성요소를 나타낸다.

본 명세서에 사용된 바와 같이, "컴퓨터 프로그램", "루틴", "서브루틴" 및 "알고리듬"은 동일한 의미의 것이며, 3개의 후자의 구성요소의 집합 또는 그룹을 설명하기 위해 대표적으로 "컴퓨터 프로그램"이 사용된다(그러나, 독점적으로 사용되지만은 않음). 이러한 프로그램, 루틴/서브루틴 및 알고리듬은 예를들어 객체 지향 언어를 포함한 어떠한 언어로도 제공된다. 일반적으로, 그러나, 본 명세서에 사용된 바와 같은 전술된 용어의 전부는 소정 목적을 당성하기 위해 시퀀스로 수행된 임의의 일련의 논리적 단계를 망라하는 것으로 이해되어야 한다.

본 명세서에 사용된 바와 같이, "IP"라는 용어는 개인 또는 시스템에 의해 사용되거나 생성될 수도 있는 IC 설계, 프로세스, 체계, 코드, 하드웨어 묘사 언어 모델, 구성("빌드"), 스크립트, 논리 레벨 표현 및 소프트웨어 객체와 성분(및 그들의 묘사)을 어떠한 제한없이 포함하는 지적 재산권을 전반적으로 지칭한다.

본 명세서에 포함된 하드웨어 묘사 언어(HDL) 또는 VHSIC HDL(VHDL)에 대한어떠한 언급도 Verilog^?, VHDL, Systems C, Java^?또는 설계에 대한 어떠한 다른 프로그래밍 언어-기반 표현과 같은 다른 하드웨어 묘사 언어를 포함하는 것으로 이해되어야 한다. 더욱이, 본 명세서에 설명된 다양한 실시예를 합성하기 위해 Design Compiler 2000.05(DC00)과 같은 일례의 Synopsys^?합성 엔진이 사용되거나, 이와 달리 다른 합성 엔진, 그 중에서도 Cadence Design Systems, Inc로부터 이용 가능한 Buildgates^?와 같은 합성 엔진이 사용될 수도 있을 것이다. IEEE std. 1076.3-1997에서 규정하고 있는 IEEE Standard VHDL Synthesis Package는 본 기술분야의 일반적 기술 중의 하나에 이용 가능하게 될 것으로 기대되는 하드웨어 정의 언어-기반 설계 및 합성 성능을 특정하기 위한 산업-수용된 언어를 기술한다.

본 명세서에 사용된 바와 같이, "프로세서"라는 용어는 적어도 하나의 명령어 워드에 관해 연산을 수행할 수 있는 어떠한 집적회로 또는 다른 전자 소자(또는 소자의 집합)를 포함하는 것으로 이해되어야 하며, 예를들어 본 출원인에 의해 제조된 ARCompact™ A5 및 ARCtangent™ A4 사용자 구성 가능한 ISA/코어(각각은 아래에 상세히 설명됨)와 같은 감소된 명령어 세트 코어(RISC) 프로세서와, 중앙 처리 장치(CPU)와, 디지탈 신호 처리장치(DSP)를 포함한다. 이러한 소자의 하드웨어는 단일 기판(예를들어, 실리콘 "다이") 상에 집적되거나, 2개 또는 그 이상의 기판 사이에 분포될 것이다. 더욱이, 프로세서의 다양한 기능적 특징은 프로세서와 관련된 소프트웨어 또는 펌웨어로써 독단적으로 시행될 것이다.

또한, 본 명세서에 사용된 바와 같은 "스테이지"라는 용어는 스테이지1이제1 파이프라인 스테이지를 지칭하고 스테이지2가 제2 파이프라인 스테이지를 지칭하는 등과 같이 파이프라인형 프로세서 내의 각종 연속 스테이지를 지칭한다. 이러한 스테이지는 예를들어 명령어 페치(instruction fetch), 디코드, 실행 및 재기입 스테이지를 포함할 것이다.

ARCompact™는 설계자가 32-비트 사용자-구성가능한 프로세서에 관해 16-비트와 32-비트 명령어들을 혼합하도록 하는 혁신적인 명령어 세트 아키텍쳐(ISA)이다. ISA의 핵심적 잇점은 SoC(system-on-chip) 상의 메모리 요구를 상단한 백분율로 잘라내는 능력이며, 그 결과 무선 통신 및 고용량 소비자 전자 제품과 같은 상당히 많이 반영된 어플리케이션에서 저전력 소비 및 저비용 소자가 가능하게 된다.

ARCompact ISA의 주요 특징부는 더 우수한 코드 밀도를 제공하기 위한 목적의 32-비트 명령어와, 가장 공통적으로 사용된 연산을 위한 16-비트 명령어의 세트와, 현저한 모드-전환없이 경쟁 모드-전환 아키텍쳐에 비해 컴파일러 사용의 복잡성을 경감시키는 16-비트 및 32-비트 명령어의 자유 형태 혼합을 포함한다. ARCompact 명령어 세트는 사용자가 ARCtangent™ 프로세서 명령어 세트에 추가할 수 있는 고객 확장 명령어의 수를 확장한다. 현재의 프로세서 아키텍쳐는 이미 사용자가 중요한 루틴 및 알고리듬을 가속하기 위해 69개 정도의 많은 신규 명령어를 추가할 수 있도록 하고 있다. ARCompact ISA로, 사용자는 256개의 많은 신규 명령어를 추가할 수 있다. 사용자는 또한 신규 코어 레지스터, 보조 레지스터 및 조건 코드를 추가할 수 있다. ARCompact ISA는 그러므로 ARC의 확장 가능한 프로세서 기술의 사용자 주문 가능한 특징 및 확장 가능한 특징을 유지 및 확장한다.

32-비트 아키텍쳐가 디플리 임베디드 시스템(deeply embeded system)에서 더욱 폭 넓게 사용되어 가고 있기 때문에, 코드 밀도는 시스템 비용에 대해 직접적인 충격을 가질 수 있다. 대표적을, 시스템-온-칩(SoC)의 높은 백분율의 실리콘 면적이 메모리에 의해 취해진다.

ARCompact ISA는 플래시 메모리 카드와 같은 고용량 소비자 어플리케이션에 대한 필수적인 요소인 임베디드 어플리케이션에 대해 요구된 메모리를 현저하게 경감시키는데 도움을 주는 고밀도 코드를 전달한다. 또한, 소형 메모리에 코드를 끼워넣음으로써, 프로세서는 잠재적으로 메모리 액세스를 거의 하지 않아야 한다. 이것은 MP3 플레이어, 디지탈 카메라 및 무선 핸드셋과 같은 휴대용 장치에 대해 전력 소비를 절감시켜 배터리 수명을 연장시킨다. 추가로, 신규의 더 짧은 명령어는 이전에는 2 이상의 명령어를 요구하던 일부 연산을 단일 클럭 사이클에서 실행함으로써 시스템 전반에 걸쳐 시스템을 향상시킬 수 있다. 이것은 더 높은 클럭 주파수에서 프로세서를 실행해야할 필요없이 어플리케이션 성능을 끌어올릴 수 있다.

16-비트 및 32-비트 명령어의 자유 형태 사용을 위한 지원은 컴파일러 및 프로그래머가 특정 코드 파티셔닝 또는 시스템 모드 관리에 대한 어떠한 요구없이 소정 태스크에 대해 가장 적합한 명령어를 사용할 수 있게 해준다. 16-비트 명령어를 32-비트 명령어로 직접적으로 교체하는 것은 즉각적인 코드 밀도 장점을 제공하며, 이것은 어플리케이션 전반에 걸쳐 개별 명령어 레벨에서 실현될 수 있다. 컴파일러가 코드를 재구성하기 위해 요구되지 않을 때, 더 넓은 범위의 명령어에 걸쳐 더 우수한 양상의 최적화가 제공된다. 어플리케이션 디버깅은 신규 발생된 코드가 원래 소스 코드의 구조를 따르기 때문에 더 직관적이다.

ARCompact ISA는 본 출원인에게 양도된 "CONFIGURABLE DATA PROCESSOR WITH MULTI-LENGTH INSTRUCTION SET ARCHITECTURE"라는 명칭의 공동 계류중인 미국 가출원 번호 60/353,377호에 상세히 개시되어 있으며, 상기 특허 출원은 그 전체 내용이 본 명세서에 참조된다.

ARCtangent™ 프로세서는 ASIC, 시스템-온-칩(SoC) 및 FPGA 집적을 위한 사용자 주문 가능형 32-비트 RISC 코어이다. 이 프로세서는 합성 가능하고, 구성 가능하며, 확장 가능하며, 그에 따라 개발자로 하여금 아키텍쳐를 특정 어플리케이션에 더 우수하게 적합화되도록 수정 및 확장할 수 있도록 해준다. ARCtangent 마이크로프로세서는 4-스테이지 실행 파이프라인을 갖는 32-비트 아키텍쳐를 포함한다. 명령어 세트, 레지스터 파일, 조건 코드, 캐시, 버스 및 다른 구성적 특징부는 사용자 구성 가능하며 확장 가능하다. 이 마이크로프로세서는 32×32 비트 코어 레지스터 파일을 가지며, 이것은 필요시 어플리케이션에 의해 2배로 될 수 있다. 추라고, 다수의 보조 레지스터(최대 2E32)를 사용하는 것이 가능하다. 이 프로세서의 코어의 기능적 구성요소는 산술 논리 유닛(ALU), 레지스터 파일(예를들어, 32×32), 프로그램 카운터(PC), 명령어 페치(i-fetch) 인터페이스 로직뿐만 아니라 각종의 스테이즈 래치를 포함한다. 도 1은 대표적인 ARCtangent 프로세서 코어(100) 및 관련 확장 명령어(102)를 예시하는 블록도이다.

개괄

더욱 상세히 후술되는 바와 같이, 본 발명은 일실시예에서 집적회로를 설계, 구성 및 평가하기 위해 특별하게 적합화된 컴퓨터 프로그램의 형태를 취한다. 이 컴퓨터 프로그램은 요구된 결과, 즉 특정 속성 및 기능성을 갖는 IC의 효율적이고 신속한 설계를 달성하기 위해 더 우수한 정도의 사용자 주문을 제공한다. 특히, 파이프라인형 프로세서 코어의 경우, 이러한 사용자 주문은 설계자가 Viterbi 디코드, FET 등과 같은 특정 연산을 수행하기 위해 적합화된 확장부(예를들어, 명령어)를 코어에 용이하게 추가할 수 있도록 해준다. 이러한 명령어 및 다른 구성요소(특수한 용도의 레지스터, 신규 조건 코드 선택, 로컬 스크래치패드 RAM, 3D 또는 DSP 어플리케이션을 위한 멀티미디어 확장부의 라이브러리 등과 같은)는 설계 프로세스 동안에 설계자에 의해 용이하게 기존 명령어 세트에 임의적으로 추라될 수 있을 것이다. 외부 ASIC 또는 다른 성분을 합성 후 대상 시스템 또는 집적회로 설계에 추가하는 것과는 달리, 이러한 명령어는 집적 문제를 제거하기 위해 그리고 하나 또는 그 이상의 선택된 속성에 기초하여 최대의 최적화를 허용하기 위해 프로세서 명령어내에 포함되게 된다. 이 방법은 설계자에게 전체 IC의 HDL 모델을 생성하는 능력을 추가로 제공하며, 이에 의해 설계 프로세서의 효율을 현격히 향상시킨다. 이 능력은 다른 유형의 성분에도 용이하게 적용될 수 있을 것이지만 복잡한 프로세서 설계에 특히 유용하다.

이러한 사용자 구성가능한 설계를 제공하기 위한 기존의 솔루션은 1999년 10월 14일자로 출원되어 공동 계류 및 공동 소유중인 "Method and Apparatus For Managing The Configuration Ans Functionality Of A Semiconductor Design"이라는명칭의 미국 특허 출원 번호 09/418,663호의 일례의 일반화된 방법을 포함하며, 그 전체 내용은 본 명세서의 앞에서 설명된 "ARChitect" 설계 소프트웨어에 이식된 것으로써 참조된다. 본 발명은 그 중에서도 객체 지향 프로그래밍 및 스크립팅과 그에 관련한 다양한 특징의 채용을 통해 이러한 종래의 방식에 비해 현저한 향상을 제공한다. 특히, 본 발명은 종래의 솔루션에 의해 해결되지 않은 여러가지 요구사항, 즉 (1)다수의 확장부의 설계에의 용이하면서 효율적인 추가, (2)이들 확장부를 구동하는 데이타를 위한 저장부를 제공함으로써 데이타-구동된 툴을 가는하게 하는 것, (3)공유하기 위한 모든 툴에 각각의 프로세서 또는 IC 설계를 위한 단일 저장소(repository)를 제공하는 것, (4)정보 교환을 위해 포맷을 정의하는 것을 포함하는 요구사항을 해소한다. 이러한 속성 및 다른 속성과 본 발명의 일례의 실시예가 상세히 설명된다.

(ⅰ) 데이타-구동된 툴을 인에이블(Enabling data-driven tools)

설계자가 확장부를 프로세서 코어에 추가할 때마다, 그 확장부를 기존 툴셋에 집적하는데 상당한 양의 시간이 소요된다. 특히, EDA 툴은 업데이트되어야만 하고, 그래픽 사용자 인터페이스(GUI)는 변경되어야만 한다. 프로세서 설계 또는 소수의 확장부에 특정된 구성을 실시하는 동안, 이 방식은 머지않아 칩 설계에 관해 다수의(즉, 수백 또는 수십의 신규 확장부) 대표적인 시스템에 대해 작용 가능하지 않게 되었다. 따라서, 확장부 및 주변장치의 집적의 개발을 가속화하기 위해, 본 발명은 기존의 툴을 더욱 "데이타-구동된" 모델을 사용하도록 전환하는 장점을 갖는다. 신규 툴을 구동하기 위한 데이타는 다수의 상이한 관점에서 이상적으로 중앙화 및 액세스가 모두 가능한 어떠한 지점에 저장되어야만 하며, 그에 따라 일례의 시스템에서는 "구성 데이타베이스"가 사용된다.

본 출원인은 또한 기존 IP 라이브러리(프로세서 및 주변장치를 포함하고 있는)에 대해 "플러그-인"을 실시하는 유틸리티를 인지하였으면, 그 중심 컨셉은 IP 공급자가 그들 자신의 확장 성분을 저술(author)할 수 있고 그리고나서 이들 성분을 본 발명을 사용하여 IP 라이브러리내에 집적시킬 수 있도록 하는 것이다. IP 공급자 확장 성분은 그리고나서 독립적으로 분배될 수 있으며, 완전하게 집적된 설계 구현예를 작성하기 위해 하드웨어 및 소프트웨어 구축 프로세서에 포함될 수 있다. 이것은 기술(즉, ARChitect)의 기능성을 확장시키기 위해 상당한 작업이 요구되는 기존의 기술(본 출원인에 의해 제조되 본 명세서의 앞부분에서 언급돈 ARChitect 소스트웨어와 같은)로 가능한 유일한 것이다. 따라서, 본 발명의 한가지 목표는 전술된 분배/집적 프로세스를 가능한 한 중단없이 이루어지게 하는 것이다. 본 발명의 구성 데이타베이스는 인터페이스를 코어 및 툴에 제공함으로써 이것을 가능하게 한다.

(ⅱ) 단일 설계 저장소(Single design repository)

본 발명의 다른 주요 특징은 공유하기 위한 모든 툴에 대하여 각각의 프로세서 또는 IC 설계를 위한 단일의 중앙화된 또는 분포된 저장소의 사용에 있다. 예를들어, 더욱 상세히 후술되는 일례의 실시예에서, 사용자는 다른 소프트웨어 툴(예를들어, SeeCode 디버거, 프로파일러 등)에 의해 사용되고 있는 것과 동일한 코어 세팅을 프로그램 툴내로부터 선택한다. 본 발명은 따라서 각각의 구성을 위한공통 데이타 스토어를 제공함으로써 소프트웨어 툴 세트가 결합 유닛처럼 함께 작업하도록 한다. 일부 기존 솔루션은 제어 세팅을 저장하는 템플릿의 개념을 통합하지만, 이 정보는 다른 툴에 의해 사용되지 않는다.

본 방식은 또한 단일 확장된 코어, 균질한 확장 명령어/특징 세트를 갖는 복수의 코어 또는 이종의 확장 명령어/특징 세트를 갖는 복수의 코어에 적용된다는 장점을 갖는다.

(ⅲ) 정보 교환을 위한 포맷의 정의(Definition of format for information exchange)

본 발명에 의해 제공된 것과 같은 표준화된 정보 교환의 채택은 다음을 포함한 다수의 영역에서 이점을 갖는다:

a) 설계 조직 효율 - 종래 기술 하에서, 프로세서/IC의 각각의 성분 또는 확장부는 다수의 상이한 설계 팀에 의해 공동 작업적으로 구축된다. 이들 팀으로부터의 출력은 제품을 생성하기 위해 집적된다. 본 명세서에서 제공된 것과 같은 데이타베이스는 성분에 관한 모든 정보를 위한 단일 논리적 스토어를 제공하며, 각각의 팀이 자신의 성분/확장부에 대해 작업하면, 이러한 논리적 스토어는 예를들어, 단일 파일, 단일 스토어 매체 상의 다수의 파일, 로컬 데이타베이스 또는 분산 데이타베이스로 이루어질 수 있을 것이다. 이것은 프로그램적 집적이 덜 요구되기 때문에 더 우수한 조직화 효율의 결과로 나타난다.

b) 설계 조직화/주문자 집적 - 성분 또는 확장부를 개발하기 위해 설계 조직화내에서 사용되는 전술된 데이타베이스는 주문자에게 전송된 제품의 토대를 형성하기 위해 사용될 수 있으며, 이에 의해 이들 두 엔티티간의 더욱 효율적인 대화가 용이하게 되고, "해석"이 덜 필요하게 된다. 더욱이, 표준화된 교환 포맷의 사용은 주문자용의 코어/IC 및/또는 1차 설계 조직화가 유용하게 사용되는 신규 주문 확장부를 생성함에 있어서 다른 제3 설계자를 용이하게 한다.

특정 설계 속성

전술한 특징 및 기능성은 다음의 특별한 설계 속성을 통해 본 발명에서 구현된다. 다른 코딩 및 언어가 개발자의 특별한 필요성에 기초하여 대체될 수 있음을 인정되기는 하지만, 이들 속성의 특정 예의 구현예(자바-기반)는 본 명세서의 부록 I에 포함되어 있다.

1) XML, Javascript™ 및 Java™을 사용한 구성가능한 IP 인캡슐레이션- 일례의 실시예에서, 본 발명은 확장 가능한 마크업 언어(XML), 자바 및 자바스크립트의 조합을 사용하여 정적 및 동적 데이타 모두를 저장한다. 데이타 및 관련 IP가 모든 플랫폼 및 운영체계 상에서 작업하도록 데이타에 대해 플랫폼-독립적 또는 애그노스틱(agnostic) 포맷을 사용하는 것이 특히 장점을 갖는다. 일례의 변형이 간략화를 위해 데이타를 파일로써 저장하지만, 더욱 상세히 후술되는 바와 같이, 요구시 관계 데이타베이스 또는 객체 데이타베이스가 시행될 수도 있다. XML을 1차 저장 포맷으로써 사용하는 것은 데이타가 인간-판독가능한 텍스트로 저장된다는 것을 의미한다. 이것은 저장된 데이타(코드 "투명성")에 대한 단순한 방식의 시청을 제공할 뿐만 아니라 소스 코드 제어 시스템과 같은 기존의 개발 툴과의 집적을 제공한다. XML 및 IP가 분포 전에 완전하게 암호화되도록 하는 비독점적 암호화 방식이 사용되며, 아호해독은 사용자 사이트에서 제어된다.

데이타내로의 자바의 집적은 데이타와 그 데이타를 조작하는 툴간의 밀접한 커플링을 가능하게 한다. 예를들어, 데이타는 디스크 또는 다른 저장 위치로부터 자바 객체내로 자동적으로 로드되어, 정보를 기입 또는 판독하는 코드가 어떠한 변환을 수행하지 않아도 된다.

집적된 자바스크립트는 또한 확장성 스크립팅 지원을 제공한다. XNL에 스트링을 이식함으로써, 자바스크립트 서물문 및 표현식은 데이타내로 삽입될 수 있다. 사용된 자바스크립트 번역기는 스크립트가 자바 객체를 사용할 수 있도록 하여, 본 발명의 본 실시예가 XML, 자바 및 자바스크립트간에 상호작용가능성을 완성한다.

2) IP 제작 툴내의 집적된 디버거 - 본 발명은 IP내의 동적 데이타를 묘사할 능력을 포함한다. 예를들어, 전술된 ARCtangent 코어의 게이트 카운트가 정적인 것이 아니다. 버스폭을 변경시키고, 확장부를 추가하는 등은 게이트 카운트를 변경시킬 것이다. 따라서, 게이트 카운트에 관한 정보는 정적 숫치가 아닌 동적 표현식(예를들어, 자바스크립트의 일부)이 되어야만 한다. 이 표현식은 사용자가 선택한 다양한 설계 옵션 및 코어에 추가한 임의의 확장부에 기초하여 다양한 수학적 게산을 수행하며, 숫치값을 리턴한다. 이러한 계산을 IP내로 포함시키기 위해, 이러한 계산을 디버그 환경 내에서 실행(계산을 진행하여 나아가고, 변수값을 살펴보는 등등을 포함)하기 위한 수단이 요구된다. 그러므로, 본 발명은 사용자가 자신의 데이타에 관한 브레이크포인트를 설정할 수 있도록 하고 실제의(즉, 시뮬레이션되지 않은) IP 프로젝트에서 발생할 때의 다양한 계산을 진행하여 나아갈 수 있도록 하는 완전한 자바스크립트 디버거를 옵션으로 포함한다.

3) 집적된 IP 저술 및 구성 - 본 발명은 종래 기술에 비해 실질적으로 "반복적인" 설계 프로세스를 채용한다. 이들 종래 기술의 방식 하에서, 설계자는 요구된 확장부로 코어를 구축하며, 추가된 명령어를 도모하기 위해 HDL 및 다른 성분을 수정할 것이다. 여러 이유로 설계자가 프로세서 코어 설계를 변경하기를 원하다면, 설계자는 HDL을 다시 생성하고 명령어 HDL 코드(수동 또는 다른 방법에 의해)를 다시 추가하도록 요구될 것이다.

반대로, 본 발명의 반복적 방식은 설계자가 자신의 확장부 성분(예를들어, 명령어)을 소프트웨어 라이브러리 내로 집적할 수 있도록 한다. 이것은 라이브러리에 HDL(예를들어, VHDL)을 구축함으로써, 가산된 명령어가 빌드내에 자동적으로 집적된다는 것을 의미한다. 따라서, 방법학은 VHDL을 소프트웨어 라이브러리내로 집적하도록 하는 명령어를 도모하기 위해 수작업의 VHDL로부터 이동시킨다.

방법학에서의 이러한 이동을 용이하게 하기 위해, 소프트웨어는 라이브러리 내로의 IP의 집적에 더 큰 강조를 위치시켜야만 한다. 이것은 "IP 저술"이라는 문맥으로 지칭된다. 이 프로세스가 효율적으로 작동하도록 하기 위해, 집적된 저술 및 사용이 요구된다. 즉, 저술 기능성은 IP를 사용하는 것의 기존 기능성과 일치해야만 한다. 소프트웨어내에 구축된 전술된 <자바스크립트> 디버거는 사용자가 사용시 실행중인 자신의 스크립트를 확인하도록 해준다. 예를들어, VHDL에서의 교체 변수는 VHDL이 구축될 때에 확장되며, 사용자는 자신의 변수 스크립터 상에 브레이크포인트를 위치시키고, VHDL이 구축될 때에 이것이 실행되는지를 확인할 수있다.

4) 라이브러리 및 프로젝트로의 IP 정의 및 인스턴스의 분리 - IP 전달에 대한 객체 지향 접근의 일부로써, IP 성분 정의 및 인스턴스를 저장하기 위해 하나 또는 그 이상의 저장소가 요구된다. 본 발명은 데이타를 감추는 인캡슐레이션의 개념을 채용한다.

5) IP 프로젝트 파일 구조 - 본 발명은 관리가 용이한 영구 저장장치에 성분 인스턴스를 저장하는 방법을 채용한다. 이것은 소위 "IP 프로젝트"를 구성한다. 운영체계(OS) 파일 시스템은 단순한 계층적 데이타 구조로 데이타를 저장하기 위해 사용된다. 이와 달리, 시스템 API(어플리케이션 프로그래밍 인터페이스)의 사용을 통한 동일한 기능이 파일에 대하여 운영체계 동작인 것처럼 꾸미도록 기능하는 것을 달성하기 위해 dBase, 오라클 및 유사 데이타베이스 관리 시스템과 같은 데이타베이스 관리자가 채용될 것이다. 이러한 API는 운영체계 분야의 당업자에게는 널리 공지되어 있으며, 본 명세서에서 추가로 설명되지 않는다. 일례의 실시예에서, 파일 시스템의 디렉토리 구조에 기초한 단순한 트리 구조가 채용된다. 프로젝트에서의 각각의 성분 인스턴스는 다른 성분을 포함할 수 있는 저장장치(예를들어, 하드 디스크 드라이브) 상에 자신의 디렉토리를 갖는다. 또한, 각각의 성분은 그 성분(예를들어, 옵션)과 관련된 임의의 데이타를 저장하기 위해 '_data_' 디렉토리를 갖는다. 성분에 의해 소유된 라이브러리인 '_library_' 디렉토리 또한 상세히 후술되는 바와 같이 옵션적으로 제공된다.

표준 파일 시스템을 사용한다는 것은 사용자가 다수의 기존 툴을 갖는다는것을 의미하며, 사용자는 이 툴을 가지고 자신의 프로젝트를 관리한다. 예를들어, 사용자는 기존의 파일 서버, 소스 코드 제어 시스템 등을 사용하여 프로젝트를 공유할 수 있다. 사용자는 또한 파일 관리자/파일 압축 프로그램 등을 사용하여 자신의 프로젝트를 관리할 수 있다. 더욱이, IP에 관련하거나 IP를 사용하는 기존의 툴은 데이타 베이스 또는 적합한 데이타 스토어에 데이타를 저장하도록 수정되어야만 하지는 않는다. 예를들어, 일례의 설분의 일부인 C/C++ 코드는 특정 디렉토리에 저장되며, 그러므로 기존의 컴파일러는 수정없이 그 코드를 사용할 수 있다.

6) IP 라이브러리 구조 - 본 발명은 또한 관리하기가 용이하고 명명법으로부터 자유로운 라이브러리 구조를 제공한다는 장점을 갖는다. 특히, 클래스(자바 클래스)를 라이브러리 구조로 집적하는 방법뿐만 아니라, 라이브러리내의 성분이 고유하게 명명되도록(상이한 설계 엔티티가 동일 명칭으로 성분을 생성하지 못하도록) 하는 방법이 제공된다. 기본 라이브러리 저장장치는 단순히 OS의 파일 시스템이다. 그러나, 일례의 실시예에서, 디렉토리가 놓여지는 방식은 자바 패키지 구조에 대해 아날로그적이다.

저장을 우해 파일 시스템을 사용하는 것은 라이브러리를 관리가 용이하게 만든다. 기존 툴은 라이브러리를 시청, 관리 및 수정하기 위해 사용될 수 있다. 자바 패키지 컨번션에 관해 라이브러리 포맷을 기본으로 함으로써, 자바 클래스는 라이브러리에 성분의 일부로써 포함될 수 있으며, 그 성분 명칭은 고유의 것이 된다. 이것은 또한 자바 패키지 구조를 가지고 충밀한 집적을 가능하게 한다. 라이브러리는 자바 어플리케이션의 클래스 경로에 추가될 수 있으며, 라이브러리에 저장된클래스는 정상의 것으로써 액세스될 수 있다.

일례의 디렉토리 구조에서, 가장 낮은 레벨의 디렉토리는 성분 타입 및 링크 타입을 표현한다. 이들은 또한 디렉토리를 포함하며, 그에 따라 다른 파일 및 디렉토리를 포함한다.

7) 사이트, 링크 및 변수를 사용하여 IP 관계를 정의 - 본 발명은 각종의 상이한 IP 성분과, 이들 성분이 서로 관련하는 방법을 정의하는 능력을 제공한다. 시스템 툴은 IP 성분이 서로 어떻게 연결되는지와 어떠한 종류의 정보가 이러한 관계를 정의하는지에 관해 알려지게 된다. 한편, 종래 기술은 IP를 사용하는 각각의 어플리케이션내로 이 정보를 거의 코딩하지 않는다.

상이한 IP 성분이 어떠한 타입의 관계를 갖는지와 이러한 관계의 일부로써 통과되는 정보를 정확하게 특정함으로써, 정확한 토폴로지에서의 성분의 연결이 보장된다. 또한, 설계자는 성분을 툴내로 집적하기 위해 요구되는 모든 정보가 제공되는지를 검증할 수 있다.

8) 성분 링크 패턴 - 성분이 설계에 추라될 때, 성분이 연결될 수 있는 다수의 가능한 방식이 존재한다. 본 발명은 한사이트씩 나아가는 것을 기초로 하여 디폴트 연결 전략을 특정하기 위한 기술을 제공한다. 이것은 모든 성분에 적합한 하나의 방식이 존재하지 않아 소정 세트의 성분으로 사용될 수 있는 다수의 상이한 연결 체계가 존재하기 때문에 요구된다. 본 발명은 성분의 작성자가 자신의 성분에 관해 각각의 사이트(인터페이스)에 대한 연결 체계를 특정하도록 할 수 있다. 그 체계는 스크립트(예를들어, 자바스크립트) 또는 클래스(자바 클래스)의 일부 중의 하나로써 코딩되며, 스크립트/클래스는 성분이 어떻게 연결하는지에 관한 정보를 시스템에 제공하기 위해 실행된다. 이러한 접근은 소정 성분이 어떻게 연결하는지를 툴이 알지 못하고 성분 자체가 그 자체내에 인캡슐레션된 그 정보를 갖는 전술된 인캡슐레이션 개념을 통합한다.

9) 템플릿으로써 라이브러리에 저장된 프로젝트 - 설계자는 종종 스크래치로부터 프로젝트를 작성하기를 원하지 않고, 그 대신 최송 설계를 발생하기 위해 설계자가 수정할 수 있는 사전구성된 IP 프로젝트를 요구한다. 설계자는 또는 기존의 프로젝트로 통합될 수 있는 설계의 사전 구성된 '블록'을 원할 수도 있다. 본 발명은 프로젝트 또는 설계 블록의 템플릿을 발생하기 위한 능력을 제공하며, 이에 의해 이 필요성을 충족시킨다. 템플릿은 라이브러리에 저장되며, 다른 설계자 또는 설계의 최종 사용자에게 일부 또는 전체가 분배될 수 있다. 더욱이, 설계자는 동일 성분 또는 블록의 다수의 인스턴스로 설계를 작성하기 위해 수회 인스턴스된 단일 템플릿을 사용할 수 있다. 템플릿을 변경하는 것은 성분/블록의 인스턴스의 전부를 동시에 변경시키며, 이에 의해 한 성분씩의 수정을 제거한다.

10) 라이브러리에 저장된 구축 툴 정의 - 소정 프로젝트에 대해 구축 프로세스를 구축하는 방법학은 다수의 관점에서 그 결과의 HDL 자체 정도의 고유한 것이다. 일실시예에서, 구축 프로세스는 사용자가 수정/가산/제거할 수 있는 일련의 단계에 유효하다. 종래 기술은 구축 프로세스를 특정하기 위해 예를들어 Unix "makefile"을 사용한다. 그러나, 본 발명은 하나 또는 그 이상의 구축 "프로세스"를 라이브러리 및 프로젝트에 저장한다. 예를들어, 구축 프로세스 'VHDLbuilder', 'Hierarchy Builder' 및 'Test Builder'는 모두 라이브러리에 저장될 것이며, 그 빌드가 어떻게 구축되었는지를 특정하기 위해 설계에 추가될 수 있다. 'Generate Hierarchy', 'Async to Sync', 'Generate Rams'와 같은 서브-프로세스도 제공되며, 이에 의해 설계자가 개개의 설계 성분이 설계를 구축하기 위해 사용된 것과 동일한 형태로 이러한 서브-성분으로부터 주문형 구축 프로세스를 생성할 수 있게 된다. 구축 프로세스는 설계당 사용된 IP 블록의 다수의 카피를 허용하기 위해 고유하게 인스턴스된 변수 명으을 갖는 IP를 작성할 수도 있다는 장점을 갖는다. 이 장점은 다중-프로세서 시스템-온-칩 설계에 특히 유용하다.

11) 확장가능/동적 GUI - 신규 성분은 종종 그래픽 사용자 인터페이스(GUI)를 신규의 성분에 대한 패널, 메뉴 및 다이알로그가 존재하도록 변경하길 원한다. 다수의 종래 설계 방식에서, GUI는 신규 성분이 시스템에 추가될 때마다 수동으로 변경된다. 본 발명은 성분 정의의 일부인 GUI를 제공함으로써 이 문제를 해소한다. 이 기능성을 인에이블시키기 위해, GUI 코드의 일부분은 성분과 함께 분배된다. 일례의 실시예에서, GUI 객체를 포함하는 클래스-플랫폼 코드를 정의하기 위해 자바 랭귀지가 사용된다. 이 코드는 코드를 재컴퍼일할 필요없이 실행시간에 GUI 내로 플러그될 수 있다. GUI 루틴(예를들어, '위저드')은 자바 클래스로써 분산되어, 이들 루틴은 실행 어플리케이션내에 동적으로 포함될 수 있다. 이것은 성분의 개발자가 성분을 사용하도록 요구되는 GUI 성분을 작성하여 GUI 성분들을 성분내에 분산시킬 수 있다는 것을 의미한다.

본 발명의 GUI 또한 라이브러리에 저장된 정보로부터 실시간에서 자동적으로생성된다. 예를들어, 성분이 갖는 옵션이 성분 정의에 저장되며, 이 성분 정의는 관련 툴에 의해 분석되고, 관련 툴이 성분 정의로부터 적합한 GUI를 실행시간에 작성한다.

12) IP 데이타의 자동 업데이트 - 본 발명은 "IP update" 서버 또는 다른 엔티티에 의해 제공된 바와 같은 네트워크 인터페이스(예를들어, 인터넷, 인트라넷, LAN, WAN 등)를 통해 성분 또는 다른 관련 데이타에 대한 업데이트를 자동적으로 모으고 위치확인된 또는 다운로드된 신규 데이타, 업데이트 등의 사용자에게 알려주도록 옵션적으로 구성된다. 이러한 형태로, 사용자의 로컬 시스템 상에 제공된 시간이 경과된 정보는 소프트웨어의 사용 동안 자동적으로 교체되며, 이에 의해 실행 업데이트 기능성이 제공된다. 이러한 업데이트는 IP의 시간 경과된 카피와 관련된 오류성 동작이 제거되도록 보장하기 위해 "빌드"에 요구된 IP 업데이트가 자동적으로 포함될 수도 있는 사용자 지원에 향상된 메카니즘을 제공한다.

13) 디스플레이를 위한 IP 타입 카테고리화 - 본 발명의 라이브러리는 하드웨어, 소프트웨어, 테스트 등을 포함한 다수의 상이한 IP 성분을 포함할 수 있다. 따라서, 본 발명은 이러한 변경된 성분에 관련한 정보의 디스플레이를 관리할 수 있는 능력을 사용자에게 제공한다. 특히, 성분은 하나 또는 그 이상의 카테고리화 기준을 기초로 카테고리화되고, 이 카테고리 정보를 포함하도록 구성된다. 디스플레이/GUI 기능은 이들의 카테고리 속성에 기초하여 성분을 식별하고 성분을 요구된 바대로 디스플레이할 수 있다.

14) 인간이 판독 가능한 링크 - 종래 기술 하에서는, 링크, 사이트 및 성분을 사용하는 IP 프로젝트의 묘사가 숙련된 설계자에 의해조차도 항상 용이하게 이해되는 것은 아니었다. 이것은 설계자가 IP 설계의 세부사정을 잘 알고 있지 못하다면 특히 더 그렇다. 본 발명은 프로젝트를 묘사하는 묘사적 링크 구성요소를 발생함으로써 이 사항을 해소한다. 일실시예에서, 이 묘사는 평범한 언어(예를들어, 영어)로 되어 있어, 사용자가 성분간의 관계를 신속히 식별할 수 있다. 이것은 설계 툴이 대체로 더 직관적이 되게 하고, 해외 부류의 잠재적 사용자에 의해 액세스 가능하게 한다.

15) 성분이 자신의 종속도(dependency)을 포함 - 설계에서의 각각의 성분은 성분의 구문에 기초하여 변경하는 다수의 종속도 및 제약을 갖는다. 예를들어, 명령어 캐시는 그 메모리가 사용된 코어의 메모리 버스폭보다 더 큰 메모리 버스폭을 가질 수 없다. 툴은 이러한 종속도 및 제약이 툴내로 하드-코딩(hard-code)되지 않는 방식으로 이러한 종속도 및 제약에 대해 알게 될 필요가 있다. 따라서, 본 발명은 이러한 종속도/제약에 대한 데이타를 성분 정의부 자체에 저장한다. 이러한 종속도는 스크립트(예를들어, 자바스크립트) 또는 자바 클래스로 표현되며, 이러한 스크립트 또는 자바 클래스는 종속도가 요구된 바대로 단순하거나 복잡한 것으로 되도록 한다.

16) 성분 정의부에 저장된 각각의 성분에 대한 구축 정보 - 종래 기술의 솔루션은 소정 장치 및 임의의 관련 확장부를 어떻게 구축하는지에 대해 "하드 코딩된" 정보를 사용한다. 반대로, 본 발명은 "빌드 계층"을 작성하기 위해 각각의 성분으로부터 구축 정보를 사용함으로써 정보의 인캡슐레이션을 활용한다. 소위 "부모" 및 "자녀" 사이트는 다양한 성분에 대해 정의되며, 이에 의해 성분이 링크에 의해 링크될 때 구축 계층을 효율적으로 특정한다.

17) 플러그-인을 사용하는 툴 확장가능성 - 본 발명은 "플러그-인"의 사용자 추가를 도모하고 용이하게 하는 사용자 확장 가능한 툴렛을 추가로 제공한다. 일실시예에서, 자바 클래스 파일은 저장장치의 소정 디렉토리에 위치된다. 툴은 자바 반영 메카니즘을 사용하여 그 디렉토리내의 클래스를 검사하고, 이에 의해 툴에 의한 플러그-인의 사용을 용이하게 한다.

18) "도트" 오퍼레이터를 사용하여 데이타를 어드레싱 - 시스템의 라이브러리에 저장된 스크립트는 "도트" 오퍼레이터를 사용하여 정보(성분 타입 또는 성분 인스턴스로부터의 데이타를 포함하는)를 검색하는 메쏘드가 제공된다. 시스템내의 경로는 서브성분(그 첫번째 것이 타입 또는 인스턴스 데이타를 가르켜줌)으로 분할되며, 각각의 후속 서브성분은 그 기능과 관련된 하나 또는 그 이상의 객체를 리턴하기 위해 순차적으로 호출된다.

19) 링크에 걸친 변수 - 링크는 성분간의 관계를 정의한다. 관계의 정의는 종종 링크를 가로질러 전달되어야만 하는 데이타를 포함한다. 예를들어, 확장부 명령어는 코어 VHDL에 추가할 것이 어떤 VHDL인지를 코어에 알려주어야만 한다. 본 발명은 소정 성분에서의 각각의 사이트가 그 사이트를 가로질러 전달되는 데이타에 관한 정보를 포함하도록 구성된다. 이 정보는 '변수'의 형태이다. 일실시예에서, 각각의 변수는 데이타를 검색하기 위해 실행시간에서 평가되는 자바스크립트의 일부이다.

20) 플러그-인을 사용하는 확장 가능한 GUI 트리 - 본 발명의 GUI 트리의 다수는 종래의 트리 사용자 인터페이스 성분을 기초로 한다. 그러나, 제3 개발자로 하여금 그들 자신의 타입의 데이타를 라이브러리내로 추가할 수 있도록 툴이 구성되기 때문에, 이 데이타는 유용한 방식으로 트리 상에 나타내어져야만 한다. 이상적으로, 데이타의 설계자는 자신의 데이타가 트리에 어떻게 나타나는지를 특정할 수 있어야 한다. 따라서, 본 발명은 데이타를 트리에 어떻게 추가하는지를 툴에게 알려주는 정보 또는 명령어를 툴이 획득하도록 한다.

소프트웨어의 일례의 실시예

본 발명의 방법 및 아키텍쳐를 구현한 일례의 버젼의 소프트웨어가 설명된다. 다음의 설명이 본 명세서에서 이전에 설명된 ARCompact ISA 및 ARCtangent 프로세서와 함께 사용된 설계 소프트웨어를 통해 주로 이루어지지만, 본 발명은 다른 유형의 프로세서 및 IC(ASIC, FPGA, DAP, CISC 프로세서, 마이크로프로세서를 포함)와 앞에서 참조된 바와 같은 ISA에 동일하게 적용될 수도 있음을 이해할 수 있을 것이다.

또한, 다음의 설명이 마이크로컴퓨터 또는 다른 유사 처리 장치 상에서 실행하는 자바 기반 환경을 통해 제공되지만, 본 방법을 실시하기 위해 다른 소프트웨어 및 하드웨어 환경(미니컴퓨터, 워크스테이션, 네트워크 연결된 컴퓨터, '슈퍼컴퓨터' 및 메인프레임)이 이용될 수도 있음을 이해할 수 있을 것이다. 또한, 컴퓨터 프로그램의 하나 또는 그 이상의 부분이 요구시에 소프트웨어에 반대되는 것으로써의 하드웨어 또는 펌웨어로 구현될 수도 있으며, 이러한 다른 실시예는 컴퓨터기술 분야에서는 널리 알려진 것이다.

더욱이, 널리 공지된 공통 객체 요청 브로커 아키텍쳐(CORBA : Common Object Request Broker Architecture)가 본 발명과 함께 사용될 수도 있다. CORBA는 분산된 객체 지향 어플리케이션을 기입하기 위해 플렛폼-독립 랭귀지-독립 아키텍쳐를 제공한다. CORBA 객체는 동일 프로세스에, 동일 머신 상에 또는 로컬 혹은 비로컬 플랫폼 상에 상주할 수 있다. 자바 언어는 여러 관점에서 CORBA 성능을 실시하는 예를들어 자바 IDL에 반영된 바와 같이 CORBA 프로그램을 기입하기에 유용하다.

마지막으로, 이러한 개시에서의 예 및 논의가 주로 하드웨어 IP 및 VHDL에 관련하지만, 본 명세서에 설명된 방법학 및 장치는 예를들어 소프트웨어 또는 아날로그 하드웨어 설계와 같은 무수히 많은 다른 유형의 어플리케이션에 용이하게 사용될 수도 있을 것임에 유의하기 바란다.

상이한 유형의 데이타 - 2가지 유형의 데이타가 시스템의 전술된 "구성 데이타베이스" 내에 저장된다. 먼저, 각종 성분의 묘사를 포함한 툴을 구동하기 위한 데이타가 존재한다. 이 데이타는 그리고나서 IP 라이브러리가 되며, 이 라이브러리로부터 사용자는 자신의 시스템을 설계할 성분을 선택한다. 두번째로, 사용자에 의해 작성된 실제 설계를 묘사하는 데이타가 존재한다. 이 데이타는 사용자가 자신의 설계를 구축할 때 어떠한 옵션을 선택하였는지를 설명하여야만 하며, 이 정보는 여러 툴에 건네진다.

이들 2가지 유형의 데이타가 종종 상당히 상이하기 때문에, 이들은 각각 'IP라이브러리"와 "IP 프로젝트"로 별도로 카테고리화된다. IP 라이브러리는 성분 묘사와, 소프트웨어 툴을 구동하기 위한 데이타를 저장한다. 한편, IP 프로젝트는 사용자가 선택한 확장부 및 사용자가 선택한 옵션을 포함한 사용자 설계를 저장한다.

성분 기반 IP - IC 설계를 형성하기 위해 교환될 수 있는 설계 '성분'의 사용은 현 시점에서 광범위하게 수용되고 실시된다. IC는 특정 태스크를 수행하기 위해 설계되며, 우수하게 문서화된 인터페이스를 갖는다. 회로가 설계된 후, IC는 다른 제조업체로부터의 IC로 교체될 수 있다(인터페이스와 호환되는 한).

그러나, 이 성분 기반 개념은 소위 "구성 가능한" IP를 작성하도록 확장되어 왔다. 이러한 확장에 의해, 사용자는 자신의 필요성을 더욱 정확하게 적합화시키기 위해 설계내에 하나 또는 그 이상의 성분의 동작을 변경할 수 있다.

근래 몇년 동안, 소프트웨어 엔지니어는 성분을 사용하여 소프트웨어 개발을 가속하려고 시도하여 왔다. 스크래치로부터 복잡한 어플리케이션을 작성하는 것은 더 이상 받여들여질 수 없다. 환경 툴에 함께 플러그될 수 있는 표준 소프트웨어 블록으로부터 어플리케이션을 구축하는 것이 종종 더욱 효율적이다. 이러한 블록은 라이브러리, DLL, ActiveX control 등이 될 수 있다. 예를들어, 칼렌더 윈도우로 어플리케이션을 작성하고 있는 개발자는 완전한 기능의 칼렌더를 코딩하기 원하지 않을 것이다. 그 대신, 어플리케이션에 위치시키는 이미 존재하는 또는 "획득이 용이한" 칼렌더 콘트롤을 간편하게 획득한다.

그러나, 개발자는 이러한 "획득이 용이한" 성분을 주문할 수 있어야만 한다.전술한 칼렌더 예에서, 특정 컬러 방식 또는 데이타 디스플레이가 요구될 것이다. 더욱이, 제2 개발자가 제어 기능성을 주문하기를 원할 수도 있을 것이다. 이러한 종류의 주문화(customization)는 성분의 원개발자 또는 1차 개발자가 제1 장소에 사용자에 의해 주문되기 쉬운 동작 및 속성의 종류를 예상하고 성분에 제공된 디폴트를 대신하여 이러한 주문화를 허용하기 위한 "무시(override)" 메카니즘을 제공하는 한 제공하기가 비교적 간편하다.

전술한 예는 본 발명의 연산에 대해 다수의 방식과 유사하다. ARC 프로세서는 유사한 성능, 더욱 현저하게는 확장 가능한 명령어 및 레지스터를 갖는다. 예를들어, 일례의 ARCtangent 코어에서, 캐시 크기는 소정 범위(예를들어, 0.5K 내지 32K)에서 요구된 크기로 설정될 수 있다. 일반적으로 사용자가 자신의 코어/IC를 설계할 때에 사용자가 작성하고자 하는 주문 명령어가 무엇인지를 알지 못한다. 그러나, 코어에 대해 표준 '링크 타입'을 제공함으로써, 개발자는 그들이 좋아하는 임의의 명령어를 작성 및 추가할 수 있다. 이러한 유형의 확장가능성은 근본적으로 코어의 디폴트 동작을 무시하는 방식이다.

타입 및 인스턴스 - 본 발명은 소위 "타입"과 "인스턴스"를 추가로 구별한다. 타입과 인스턴스간의 차이는 중요한 개념이며, 이 개념은 이전에 설명된 IP 라이브러리 및 IP 프로젝트에서 매우 유용하다. 이 개념은 잘 이해된 객체 지향 프로그래밍 용어(즉, type=클래스, instance=객체)에서의 클래스와 객체간의 차이점에 직접적으로 유사하다.

타입 - 타입은 객체의 클래스를 묘사하기 위해 사용된다. 예를들어, 일례의ARCtangent 프로세서는 그것이 어떻게 사용되는지와 그것을 확장하기 위해 어떠한 성분이 사용될 수 있는지를 상세히 나타내는 타입 정의를 포함할 것이다. 이 정의는 실제적인 코어는 아니지만 유사 유형의 모든 장치(즉, ARCtangent 프로세서)에 적용하는 묘사이다. 코어 타입 정의는 그 중에서도 그것이 지원하는 클럭 속도, 그것을 VHDL 또는 다른 하드웨어 묘사 언어 표현식으로 어떻게 전환하는지, 확장부가 어떻게 그것에 연결될 수 있는지 등에 대한 정보를 포함할 것이다.

인스턴스 - 사용자가 ARChitec에 ARCtangent 코어를 작성하도록 알려줄 때, 이들은 component instance를 작성한다. 코어의 인스턴스는 레지스터 RAM 타입 또는 명령어 캐시 등을 가지고 있는지의 여부와 같은 정보를 포함할 것이다.

본 발명 내에서 IP 라이브러리 및 프로젝트의 타입 및 인스턴스에 대한 3가지 주요 사용, 즉 components, sites 및 link type이 존재한다. 이러한 관계는 도 2에 그래픽으로 도시되어 있다. 도 2에서, "타입"은 모서리가 둥근 직사각형(202)으로써 도시되고, "인스턴스"는 장방형 모서리를 갖는 직사각형(204)으로써 도시된다. 엔티티간의 점선은 "의 인스턴스이다"라는 관계를 나타낸다.

IP 라이브러러 - 앞에서 참조된 IP 라이브러리는 IC 소자를 생성하기 위해 사용될 수 있는 각종의 성분, 사이트 타입 및 링크 타입에 대한 정보를 모두 유지한다.

성분 타입 정의 - 성분 타입 정의는 라이브러리내에 대량의 정보를 구성한다. 이들은 설계에 사용될 수 있는 각종 성분의 정의이다. 예를들어, 코어, 확장부, 주변장치 등은 모두 자기 자신의 성분 정의를 가질 것이다. 각각의 성분 정의는 자기 자신의 서브디렉토리를 가지며, 이 서브디렉토리는 한 위치에 그 성분에 대한 데이타 전부를 유지한다. 이들 성분을 정의하기 위해 사용되는 정보의 주요 부분은 자신의 사이트 및 툴 데이타이다. 사이트는 2개의 성분이 어떻게 함께 결합하는지를 묘사한다. 성분에 의해 사용된 사이트는 항상 IP 라이브러리에 저장된 사이트 타입 정의의 인스턴스가 될 것이다. 도 3은 사이트 타입 정의, 성분 타입 정의 및 링크 타입 정의간의 관계를 도시한다.

링크 타입 정의 - 링크 타입은 성분간의 관계를 정의한다. 각각의 링크 타입 정의는 자기 자신의 서브디렉토리를 가지며, 이 서브디렉토리는 자신의 사이트 유형의 정의를 포함하는 자신의 데이타 전부를 유지한다.

또한, 본 발명은 "쉬운 영어" 링크 타입 지정을 채용한다. 대표적으로, 종래 기술 하에서, 링크는 예를들어 링크1이 '코어'(VHDL_Parent)를 '아이캐시'(VHDL_Child)에 연결시키는 것과 같이 자신이 링크하는 성분 및 사이트에 의하여 순수하게 묘사된다. 명백히, 이것은 사용자에게 매우 유용한 어느 것을 알려주지는 않는다. 관계에 대한 더욱 유용한 묘사는 다음이 될 것이다:

'icache' inserts VHDL code into 'core'

이제 사용자는 관계를 즉각적으로 판정할 수 있다.

이러한 기능성은 정보를 링크 타입에 있게 함으로써 본 발명에서 시행된다. 링크 타입이 특정 타입의 모든 링크의 정의라는 점을 상기하기 바란다. 이 경우, 2개의 엔드(end) 'Parent' 및 'Child'를 갖는 'VHDL'(상세히 후술됨)로 지칭된 링크 타입이 존재한다. 링크 타입에 저장된 정보는 프로그램에게 그 링크 타입(이경우, 코어를 캐시에 연결시키는 링크)의 인스턴스에 기초하여 스트링을 어떻게 작성하여야 하는지를 알려준다.

앞에서 제공된 예에서, 코드는 다음과 같이 될 것이다:

Parent.getName()+"inserts VHDL code into" +Child.getName();

따라서, 링크에 대한 정보는 프로그램이 그것에 대한 정보를 발견하지 못하도록 링크 타입으로 인캡슐레이션화된다.

템플릿 - 템플릿은 IP 라이브러리에 저장된 IP 프로젝트인 것이 효과적이다. 이들은 다음과 같은 2개의 주사용을 갖는다:

1) Starting configuration - 소프트웨어의 일례의 실시예는 "베이스케이스(basecase)' 프로세서 구성(즉, 아직 어떠한 확장부도 추가되지 않은), DSP, 일반 등과 같은 여러 개의 디폴트 셋업 또는 구성을 갖는다. 이러한 구성은 템플릿이 저장될 수도 있으며, 사용자의 설계를 개시하는 출발점이 되는 적합한 셋업을 사용자가 선택할 수 있게 할 것이다.

2) Repeated configuration - 사용자가 반복하고자 하는 자신의 설계의 일부를 작성한다면, 사용자는 그것을 템플릿으로 저장하여 자신의 설계에서 여러 번 그것을 불러 읽어들일 수 있다.

템플릿은 아래에 더욱 상세히 설명된다.

인캡슐레이션 - 종래 기술의 설계 시스템에서 툴이 제공되게 하는 방법과 관련된 불가능성 중의 하나는 IP 인캡슐레이션의 사용이 존재하지 않는다는 것이다. 달리 말하면, 이러한 시스템에서 IP의 특정 부분에 대한 정보는 다수의 툴 사이에서 전파될 수 없다. 예를들어, 신규 확장부를 추가하는 것은 빌더, 디버거, 컴파일러, 시뮬레이터 등을 포함하는 다수의 어플리케이션에 대한 변경을 요구한다. 실제로, 이 정보는 이들 어플리케이션의 소스 코드로 빈번하게 하드-코딩된다. 또한, IP의 사용시에 관한 규칙 또한 툴내로 하드 코딩될 것이다.

본 명세서에 개시된 본 발명의 일례의 실시예는 인캡슐레이션을 장려할뿐만 아니라, 실제로 사용되게 한다. 특히, IP의 일부분에 관한 모든 정보는 IP의 그 부분의 정의 내에 저장(정의에 의해 인캡슐레이션화)된다. 각각의 IP 성분은 그 성분 자체에 대해 그리고 그 성분이 다른 성분에 어떻게 관련하는지를 알지만, 설계에 사용된 IP의 다른 일부분에 대해서는 전혀 알지 못한다. 예를들어, 확장 명령어는 그 명령어가 코어 내에 위치되어야 한다는 것을 알지만, 그 명령어의 VHDL로 합병하기 위해 무엇이 요구되는지를 제외한 그 코어에 대한 그 밖의 것에 대해서는 아무 것도 알지 못한다. 이것은 코어가 확장 명령어에 영향을 미치지 않고서도 업데이트/교체될 수 있다는 것을 의미한다.

예를들어, 대표적인 종래 기술의 솔루션 하에서, 설계자는 다음과 같은 구축 소프트웨어 GUI 코드에서의 종속도를 직면할 것이다:

You cannot have the XMAC without the memory sequencer in the core.

그러나, 본 발명에서, XMAC 및 코어는 별도의 성분으로 취급되며, 종속도는 그 종속도가 관련한 성분(즉, 상기 예에서는 XMAC) 내에 위치된다. 종속도는 XMAC 성분의 일부로 이루어지며, 다음과 같이 판독된다:

This XMAC requires a memory sequencer.

다른 관점으로, 캐시가 코어의 버스폭보다 큰 버스폭을 가질 수 없다는 것을 나타내는 정보를 저장하도록 요구되는 경우를 고려해본다. 이 종속도는 명백히 캐시에 속하며, 그에 따라 그 데이타를 캐시 성분 타입에 위치시킬 것이다. 인코딩에 의하여, 다음이 사용될 수도 있을 것이다:

if the core bus with is greater than X, then print("cache bus with too small")

이를 달성하기 위해, 코어 및 캐시는 정보를 변경할 필요가 있다는 것은 명백해진다. 즉, 코어는 캐시에게 캐시의 버스폭이 얼마인지를 알려줄 필요가 있다. 그러므로, 코어와 그 데이타를 전달하는 캐시간에 링크가 존재해야만 한다. 이러한 링크가 존재하며, 캐시는 'ICache_cache'로써 그 링크를 참조한다. 그 링트 타입의 실제 정의는 캐시가 링크의 타단(즉, 코어)으로부터 'CoreBusWidth'로 치칭된 변수를 요청할 수 있다는 것을 특정한다. 따라서, 코어 버스폭을을 얻기 위해, 자바스크립트는 다음과 같이 될 것이다:

ICache_cache.BusWidth

다음에, 캐시는 자기 자신의 버스폭이 얼마인지를 알아야만 한다. 이것은 캐시 인스턴스에 대한 옵션 데이타, 즉 id.options.BusWidth를 취한다. 따라서, 종속도는 다음과 같이 될 것이다:

계층을 구축 - 전술된 바와 같이, 인캡슐레이션의 사용은 소프트웨어 또는 성분의 한 부분이 코드 전부(예를들어, VHDL)를 갖는 것은 존재하지 않는다는 요구한다. 각각의 성분은 자신의 VHDL 코드만을 갖는다. 따라서, 상이한 성분으로부터 VHDL을 취할 수 있고 그것을 구성요소의 단일의 VHDL 계층으로 만들기 위해 어셈블링할 수 있는 구축 프로세스가 존재되어야 한다. 본 발명의 기본 구축 아키텍쳐는 다음과 같이 상당히 간략하게 이루어지는 장점을 갖는다:

1) 프로젝트를 구축하기 위해 VHDL을 갖는 각각의 성분은 VHDL_Child 사이트를 갖는다.

2) 자신과 합병하기 위해 다른 성분으로부터 VHDL을 원하는 각각의 성분은 VHDL_Parent 사이트를 갖는다.

3) 사이트가 링크에 의해 연결될 때, 그들의 VHDL 사이트에 의해 연결된 성분의 계층적 트리가 발생된다.

4) 구축자는 자신의 VHDL 코드에 대해 최상위의 성분을 질의한다. 이 최상위 성분은 자신의 VHDLfiles을 판독하고 그리고나서 자신의 자녀로부터의 임의의 VHDL로 합병함으로써 VHDL을 작성하려고 시도한다. 자녀는 유사한 프로세스를 사용하여 자신의 VHDL을 작성할 것이다.

5) 프로세스는 구축 프로세스가 트리 밑으로 진행할 때 되풀이 된다 각각의 성분은 자신의 성분 유형으로부터 자신의 VHDL을 판독하고, 자신의 자녀로부터의 VHDL로 합병한다.

6) VHDL 코드가 반복을 완료하고 트리의 상단으로 진행할 때, 빌드가 완료되고, 모든 성분으로부터의 코드가 함께 합병된다.

본 발명에서 사용된 인캡슐레이션은 VHDL을 발생하기 위한 다른 메쏘드를 제공한다는 점에 유의하기 바란다. 특히, 예를들어 크기 및 버스폭 등의 약간의 기본 파라미터가 주어진다면 자신의 VHDL을 실시간으로 생성하는 RAM 성분과 같은 성분이 디스크로부터 VHDL을 판독함으로써 자신의 VHDL을 생성하는 것을 원하지 않는 경우를 고려해보자. 이 경우, 디스크 상에 저장된 VHDL은 존재하지 않으며, 단지 VHDL 텍스트를 요구된 바대로 생성하는 자바 클래스만이 존재한다.

툴로부터 구축 정보를 추출함으로써, 각각의 성분은 충분한 정보를 포함하여 이 정보로 VHDL을 구축한다. 이것은 설계자가 신규 확장부 및 주변장치를 기존 성분의 어떠한 것도 수정함이 없이 분배할 수 있게 한다.

전술한 설명은 VHDL 코드를 통하여 이루어졌지만, 동일한 프로세스가 Verilog, C++, 합성 스크립트 등에 적용될 수도 있다.

하드웨어 계층 생성 - VHDL 파일 자체가 생성되는 것과 동일한 시간에, 하드웨어 계층 또한 각각의 성분에 저장된 데이타로부터 구성된다. 하드웨어 계층은 성분 계층과 섞여지지 않아야만 하며, 이들은 반드시 관련되지 않아도 된다.

각각의 하드웨어 성분은 자기 자신을 계층을 묘사하며, 이 정보는 툴 데이타의 일부분에 저장된다. 예를들어, ARCangel 테스트 하드웨어 상에 실행될 빌드가 소프트웨어 시뮬레이션에 대한 빌드에 제공되지 않은 추가의 계층 레벨을 가질 때와 같이, 계층이 사용자에 의해 이루어진 선택에 좌우되어 설계시에 변경할 때, 정보는 동적이어서 자바스크립트를 사용하여 정의된다.

성분은 자신이 원하는만큼의 다수의 계수 레벨을 특정할 수 있다. 각각의 레벨은 구조, 동작 또는 합성 가능의 3가지 타입 중의 하나가 될 수 있다. 이것은 그래서 필요시 다른 어플리케이션 세팅에 좌우되어 상이하게 처리될 수 있다. 주목할만한 구조적 레벨은 다수의 다른 레벨을 함께 연결하는 것이 가능한 것으로 나타나는 계층적 레벨을 묘사한다.

특정된 각각의 레벨은 상위 블록명과, 그 상위 블록에 속하는 것으로 특정된 하나 또는 그 이상의 하위 HDL 블록을 갖는다. 구축시, 어플리케이션은 각각의 고유 상위 블록명에 대한 하나의 엔트리를 작성하고, 그 엔트리 하의 모든 성분에서 발견된 모든 하위 블록을 그룹화하며, 이에 의해 성분을 함께 연결하기 위해 사용된 최종 HDL 계층과, 다른 컴파일된 것을 작성한다.

데이타 은닉 및 동질성 - 본 발명에 사용된 바와 같은 인캡슐레이션은 실제로 성분이 자신과 그 관계에 대해 결국 알 수 있다는 것을 의미한다. 그러나, 이것은 성분이 정보와 교환하지 않는다는 것을 의미하지는 않는다. 성분은 거의 혼자 사용되지 않으며, 따라서 일부 정보를 서로에게 전달하여야만 한다. 그러나, 데이타의 일부분이 다른 것으로부터의 한 성분에 의해 요구된다면, 그 사실은 성분의 정의의 일부가 된다. 통상적으로, 이것은 링크 타입 및 사이트(전술됨. 그러나 예시된 실시예에서의 자바에서의 인터페이스와 필수적으로 동일함)를 사용하여 달성된다. 2개의 성분간에 관계가 존재하지 않는다면, 링크 타입은 그 관계에 대해 정의된다. 그리고나서, 정보는 그 링크를 통해 무슨 정보가 전달되었는지를 특정하기 위해 그 링크 타입에 추가된다. 링크 타입은 어떠한 타입의 저오가 전달되었는지만을 특정하며, 어떠한 정보인지 또는 그 정보가 어떻게 생성되었는지는 특정하지 않는다. 그것은 IP의 작성자가 그 정보를 어떻게 작성할지를 결정하는지에 달려있다.

라이브러리 및 프로젝트 - 전술된 바와 같이, 데이타는 객체 인스턴스 및 타입으로 분할된다. 인스턴스는 사용자가 설계에 고려하는 실제의 IP 성분이며, 타입은 그러한 객체의 메타-데이타 묘사이다. 이것은 자바/C++에서 각각 클래스 및 객체와 유사하다. 타입은 IP 라이브러리에 저장되며, 인스턴스는 IP 프로젝트에 저장된다. 라이브러리에는 성분 타입이 저장될뿐만 아니라 링크 타입도 저장된다. 유사하게, 프로젝트 또한 링크 인스턴스를 포함한다.

IP 프로젝트 - 도 4 내지 도 7을 참조하여, 본 발명에 따른 일례의 IP 프로젝트가 설명된다. 도 4는 IP 프로젝트(400)를 구성하는 1차 구조를 도시한다. 이러한 구조는 도 5에 도시되어 있는 계층(500)으로 배열된다. 프로젝트는 링크에 의해 연결된 다수의 성분 및 템플릿으로 구성된다. 도 6은 대표적인 프로젝트의 디렉토리 구조(600)를 도시한다.

링크 - 링크는 사이트를 함께 연결하기 위해 사용되며, 그에 따라 성분을 함께 연결시키기 위해 사용된다. 도 7은 2개의 성분(704, 706)을 연결하는 일례의 링크(702)를 도시한다. 본 실시예에서의 링크는 자신이 링크시키는 2개의 객체의 명칭과, 이러한 객체내에서의 링크 사이트의 명칭을 저장하며, 요구시 추가 타입의 정보를 저장하도록 구성될 수도 있다.

부모 및 자녀 성분 - 시스템 설계에서, 일부는 "부모"로써 다른 것은 "자녀"로써 성분의 계층이 거의 항상 존재한다. 본 명세서에 사용된 바와 같이, "부모", "자녀" 등의 용어는 단지 계층적 근원 또는 성분간의 결합을 지칭한다. 예를들어, 코어 성분은 그 확장부의 부모가 되도록 고려되며, 칩-레벨 성분은 코어의 부모가 될 것이다. 이러한 블록 기반 설계는 VHDL이 기입되는 방식과 SOC 설계 모두를 미러링한다. 도 8은 대표적인 성분 계층(800)을 예시한다.

도 8에서 알 수 있는 바와 같이, 최고 레벨에는 칩 성분(802)이 있다. 칩은 2개의 코어(804)를 포함한다(칩은 코어의 부모이다). 각각의 코어 또한 부모이며, 각각 2개의 확장부 성분(806)을 갖는다. 얼마나 깊게 이들 부모-자녀 관계가 형성될 수 있는지에 대한 제한은 없지만, 각각의 성분은 일반적으로 하나의 부모 성분을 가질 수 있다.

블랭크 성분 - 간혹, 실행 세부사항을 은닉하기 위해 성분을 함께 그룹화하는 것이 유용하지만, 명백한 부모 성분이 존재하지 않는다. 이 경우, 사용자는 객체에 대한 콘테이너로써 작용하는 블랭크 성분을 작성할 수 있다. 블랭크 성분은 가장 간략한 가능한 성분이며, 그 자신의 변수 또는 사이트를 갖지 않는다.

도 9는 성분의 그룹화가 없는 복잡한 시스템(900)을 도시한다. 도 9a에 도시된 바와 같이, 코어(902, 904)는 블랭크 성분을 사용하여 자신의 주변장치 및 로컬 메모리를 가지고 그룹화될 수 있다. 이러한 그룹화 후, 사용자는 시스템 레벨에서 설계를 볼 수 있게 될 것이며, 시스템 레벨은 메모리 및 2개의 블랭크 성분을 나타낼 것이며, 2개의 블랭크 성분은 '시스템1'(910) 및 '시스템2'(912)(도 9b)로 명명될 것이다. 사용자는 성분이 코어(920), 주변장치(922) 및 약간의 로컬 메모리(924)(도 9c)로 이루어졌는지를 확인하기 위해 성분 중의 하나를 '줌인'할 수 있다.

사용자는 통상적으로 자신의 설계를 논리 블록(성분)으로 분할할 것이며, 이들 블록은 별도로 개발될 수 있다. 예를들어, 자신의 설계는 상당히 상이한 태스크를 수행하는 2개의 코어를 포함할 수도 있을 것이다. 이러한 코어는 별도의 성분이며, 그에 따라 상이한 팀에 의해 개발될 수 있다. 통상적으로, 코어는 자신의 특정 태스크에 맞추어 자기 자신의 확장 명령어를 요구할 것이다. 이러한 명령어는 상이한 팀에 의해 정의되고 IP 라이브러리에 유지될 것이다. 신규 확장부의 정의는 확장부를 사용하는 코어의 일부로 구성될 수 있다. 따라서, 코어 성분은 도 10에 도시된 바와 같이 내부에 자신의 확장부를 갖는 자기 자신의 라이브러리를 포함할 수도 있다.

도 10의 예에서, 2개의 예의 확장부 MyExt1(1002) 및 MyExt2(1004)가 자신의 각각의 코어 내로부터의 유일한 변수이다. 그래서, 코어2는 MyExt1가 스코프(scope) 내에 있지 않기 때문에 MyExt1의 인스턴스를 작성할 수 없을 것이다. 유사하게, 코어1은 MyExt2를 인스턴스화하지 못할 것이다.

다시, 사용자는 성분에 대한 모든 정보를 인캡슐레이션화하고, 그 정보를 한 위치에 함께 저장한다. 이 방식은 사용자가 성분을 프로젝트에서 프로젝트로 이동시키도록 하여 관련 성분 타입 정보가 그들과 함께 이동하게 할 수 있다는 장점을 갖는다.

스코프 룰 - 성분 내에 라이브러리를 위치시키는 것은 그들의 가시성("스코프 룰")을 지배하는 약간의 룰이 틀림없이 존재하게 한다. 룰은 일반적으로 다음과 같이 설명된다:

ㆍ라이브러리가 자산의 부모 성분에 의해 보여질 수 있다. 이것은 라이브러리를 수용하는 성분이 그 라이브러리를 사용할 수 있다는 것을 의미한다.

ㆍ라이브러리가 자산의 부모 성분의 자녀에 의해 보여질 수 있다. 라이브러리를 수용하는 성분이 자녀라면, 이들 또한 라이브러리를 사용할 수 있다. 이 가시성은 손자, 증손자 등등까지 연장한다.

ㆍ광역의(global) 라이브러리가 모든 성분에 의해 보여질 수 있다. 일부 라이브러리는 광역적이며, 성분에 속하지 않는다. 이들은 모든 성분에 가시적이다.

템플릿 - 본 발명의 주요 목적 중의 하나는 크기 조정 가능하게 하는 것이다. 특히, 이러한 크기 조절 가능성은 소프트웨어가 단일 코더 시스템, 소형 다중-코어 시스템 또는 초대형 다중-코어 시스템을 표현할 수 있도록 한다. 이 크기 조절 가능성은 대체적으로 전술된 템플릿에 기인한다. 이러한 템플릿은 사용자가 성분의 일부 공통적으로 사용된 레이아웃을 설계하고 이들을 후속 사용을 위해 IP 라이브러리 내에 위치시킬 수 있도록 한다. 예를들어, USB 컨트롤러 및 일부 공유 메모리에 링크된 ARCtangent 코어는 템플릿을 포함할 것이다. 사용자는 자신의 설계에서의 템플릿 인스턴스를 단순히 작성함으로써 새로운 칩에 그 템플릿을 사용할 수 있다. 템플릿은 또한 10승 또는 100승의 성분을 갖는 초대형 시스템을 작성하는 우수한 방식을 제공한다. 예를들어, 100개의 동일 프로세서가 10의 10행으로 배열되는 칩 설계가 도 11의 일례의 실시예(1100)에 도시된 바와 같이 다음의방법론에 따라 작성될 수 있다.

먼저, 사용자는 전체 100개의 프로세서 설계를 실제적으로 유지할 칩을 작성한다. 사용자는 템플릿을 수용하기 위해 칩 성분 내부에 라이브러리를 작성한다. 다음에, 사용자는 라이브러리를 열고, 새로운 템플릿을 작성하며, 그들이 요구하는 코어 및 확장부로 간략한 설계를 레이아웃한다. 이 설계는 전부 100개의 코어가 작성될 템플릿이 될 것이다. 이에 대해서는 도 12를 참조하기 바란다.

코어 템플릿이 완성되어 저장된 후, 사용자는 라이브러리에 또다른 템플릿을 작성한다. 사용자가 위의 단계 2에서 작성한 코어 템플릿은 이제 사용을 위해 이용 가능한 것이며, 사용자는 10개의 프로세서의 행을 작성하기 위해 자신의 설계에 10개의 템플릿을 사용할 수 있다. 프로세서는 요구된 바대로 서로 인터페이스하며, 그리고 라이브러리에 저장된 신규 템플릿과 인터페이스한다. 이에 대해서는 도 13을 참조하기 바란다.

2개의 신규 템플릿이 이제 자신의 설계에 이용 가능하게 되었다. 사용자는 10 프로세서 행(1402)을 자신의 설계내로 수입하여, 이들을 요구된 바대로 연결시킨다. 10개의 동일한 프로세서의 10개 행을 갖는 설계가 작성된다. 이에 대해서는 도 14를 참조하기 바란다.

마지막으로, 사용자가 그들이 사용하는 프로세서 셋업을 변경하길 원한다면, 사용자는 원래 코어 템플릿을 간략하게 편집할 수 있고, 그러한 시도는 행 템플릿 및 프로젝트에 걸쳐 "번져나갈" 것이며, 이에 의해 각각의 코어 성분(또는 행 성분)을 개별적으로 수정해야 하는 사용자에 대한 조건이 제거된다.

템플릿이 설계에 사용될 수 있는 3가지 주요 방식이 존재한다. 먼저, 사용자는 사용자가 자신의 설계를 구축하는 시작점으로써의 템플릿을 선택할 것이다. 이 경우, 템플릿 프로젝트로부터의 정보는 설계에 카피되고, 사용자는 이것을 수정할 수 있다.

두번째로, 사용자는 템플릿을 기존 설게에 추가하여 기존 설계를 수정하고자 원할 수도 있을 것이다. 예를들어, 사용자가 이미 자신의 설계에 프로세서 코어를 갖고 있고, 사용자가 또다른 것(DSP 템플릿에 기초하여)을 추가하고자 원한다면, 이것은 용이하게 달성된다. 이 경우, 템플릿 프로젝트 정보는 자신의 프로젝트에 직접적으로 카피되며, 사용자는 신규 코어를 자신의 요구에 적합하게 수정하는 것으로부터 자유롭게 된다.

최종적으로, 사용자는 자신의 설계(이전의 100 코어 샘플에서와 같이)에 대형 구조를 복사하기 위해 템플릿을 사용할 수도 있을 것이다 이 경우, 사용자는 템플릿 정보가 자신의 설계에 포함되도록 원하지는 않을 것이지만, 그것에 대한 참고자료가 저장되도록 희망할 것이다. 이 방식은 사용자가 자신의 설계를 재작성함이 없이도 템플릿을 업데이트할 수 있도록 한다. 템플릿에 대한 참고자료만이 프로젝트에 저장되기 때문에, 사용자는 그 타입의 모든 다른 것을 변경하지 않고서는 한 템플릿을 수정할 수 없다.

IP 라이브러리 사용 - 전술된 바와 같이, 본 발명의 IP 라이브러리는 성분 타입, 링크 타입 및 템플릿에 대한 정보를 위한 저장소이다. 사용자의 시스템 상에 적어도 하나의 라이브러리가 존재하는 것은 틀림없지만, 소정 설계에서 채용될수 있는 최대 갯수는 없다. 본 실시예는 디렉토리 경로의 리스트를 유지하는 시스템-와이드 환경 변수를 이용한다. 이 예의 변수는 ARCLIB으로 지칭되며, IP 라이브러리 어플리케이션 프로그램 인터페이스(API)로 하여금 설계자가 사용하는 광역의 라이브러리의 전부를 찾아낼 수 있도록 한다. 더욱이, 한 라이브러리내의 데이타는 다른 라이브러리내의 데이타를 참조할 수 있다. 예를들어, 시스템 툴과 함께 제공된 ARC 라이브러리는 다른 라이브러리 내의 성분 타입에 의해 참조될 다수의 링크 타입을 포함한다.

대부분의 사용자는 하나 또는 2개의 라이브러리만을 사용할 것으로 생각된다. 예를들어, 소정 조직에서 모든 엔지니어에 의한 사용을 위한 메인 라이브러리가 존재할 것이다. 회사에 대한 이러한 메인 라이브러리는 회사가 라이센스를 가지고 있는 어떤 다른 IP와 함께 제공하는 표준 프로세서 코어를 포함할 것이다. 다른 라이브러리는 엔지니어가 동시에 작업하고 있는 성분을 유지하도록 구성될 수 있다. 그들의 로컬 머신은 도 15에 도시된 바와 같이 구성될 것이다. 이 예의 구성(1500)에서, C:＼는 자신의 로컬 하드 드라이브이고, S:＼는 모든 개발자에 의해 공유된 네트워크 드라이브이다. 프로세서 코어 라이브러리는 네트워크 드라이브 상에 저장되고, 그에 따라 모든 개발자에 의해 사용될 수 있다. 이것은 라이브러리 감독관이 신규 성분을 인스턴스적으로 추가하거나 버그를 수정할 수 있도록 해준다. 로컬 드라이브 상에는 회사 전반에 걸쳐 액세스 가능하게 되길 원하지 않는 자신의 성분 전부에 대한 사용자 라이브러리가 존재한다.

전술된 ARCLIB 환경 변수는 다음의 디렉토리를 유지하기 위해 예시된 실시예로 구성된다:

S:＼ARC Library

C:＼USER Library

[프로젝트1 및 프로젝트2 디렉토리는 IP 프로젝트라는 점에 유의하기 바란다.]

경험이 더욱 많은 사용자는 그들이 작업해야 할 각각의 프로젝트에 대한 라이브러리를 가질 것이며, 그리하여 특정 프로젝트를 위해 그들이 개발하는 성분(예를들어, 확장 명령어)은 IP 프로젝트의 일부가 될 것이다 IP 관리 툴은 사용자로 하여금 요구시 다른 라이브러리 중의 하나에 그들 성분을 전송하도록 한다. 일례의 진보된 셋업은 도 16에 도시되어 있다.

다시, 사용자 컴퓨터 상의 S:＼ 드라이브는 네트워크 드라이브이어서, 모든 사용자에 의해 공유될 것이며, 회사 전반의 라이브러리(예를들어, ARC 라이브러리)를 호스팅하기 위해 사용된다. C:＼ 드라이브는 사용자 로컬 하드 드라이브이며, 그에 따라 공유되지 않은 어느 것을 저장하기 위해 사용된다. 예시된 예의 특정 사용자는 이들이 자신의 유용한 확장부 및 템플릿 모두를 유지하는 사용자 라이브러리를 작성한다. 사용자 라이브러리에 부가하여, 사용자는 또한 사용자가 동시에 작업하고 있는 2개의 프로젝트, 프로젝트1 및 프로젝트2(이들은 IP 프로젝트임)를 갖는다. 이들 프로젝트의 일부로써, 사용자는 ARC에 대한 약간의 주문형 확장부를 작성하며, 그에 따라 사용자는 이들을 저장하기 위한 라이브러리를 작성한다. 이러한 라이브러리는 IP 프로젝트 디렉토리에 저장되며, 따라 프로젝트에 대해 로컬의 것이 된다.

ARCLIB 환경 변수는 다음의 디렉토리를 유지할 것이다:

S:＼ARC Library(절대 경로)

C:＼USER Library(절대 경로)

광역의 라이브러리에 추가하여, 각각의 프로젝트는 자신의 로컬 라이브러리를 갖는다. 그래서, 프로젝트1과의 사용을 위한 라이브러리의 총 목록은 다음과 같이 될 것이다:

S:＼ARC Library (절대 경로)

C:＼USER Library(절대 경로)

Library(상대 경로)

유사하게, 프로젝트 2에 대해서는 다음과 같이 될 것이다:

S:＼ARC Library(절대 경로)

C:＼USER Library(절대 경로)

Library(상대 경로)

각각의 리스트의 최종 라이브러리는 상대 경로이고, 이것은 사용자로 하여금 라이브러리에 대한 경로를 편집하지 않고서도 자신의 프로젝트를 이동시킬 수 있게 한다는 점에 유의하기 바란다. 양쪽의 프로젝트가 'Library'로 지칭된 라이브러리를 사용하지만, 이들은 그 경로가 프로젝트 경로에 대해 상대적이기 때문에 동일한 것으로 지칭되지 않는다.

IP 프로젝트 사용 - IP 프로젝트는 단순히 디스크에 저장되는 성분이다. 그러나, 전술된 바와 같이, 성분은 다른 성분을 포함할 수 있어서, 디스크에 단일 성분을 저장하는 것은 그 자녀(그리고, 그들의 자녀 등이)가 저장되도록 할 것이다. 예시된 실시예에서, 각각의 부모 성분은 하드 드라이브 상의 서브디렉토리로써 저장되며, 이것은 그 결과의 디렉토리 구조가 프로젝트 구조와 평행하다는 것을 의미한다. 예를들어, 다음의 다이아그램은 단순한 프로젝트를 도시한다. 최고 레벨에는 칩 성분(1702)이 존재하며, 이 칩 성분은 도 17에 도시된 바와 같이 2개의 코어(1704)를 포함한다.

도 18은 내 칩 프로젝트에 대한 일례의 디렉토리 구조(1800)를 예시한다. 도시된 바와 같이, 부모가 되는 모든 성분은 자신의 서브디렉토리를 갖는다. 그러므로, 예에서, 칩 및 코어는 모두 자녀를 가지며, 따라서 이들은 자신의 서브디렉토리를 갖는다.

명백히, IP 라이브러리는 성분 서브디렉토리의 임의의 것 내의 프로젝트에 포함될 수 있다. 이것은 프로젝트와 관련된 자신의 IP 라이브러리를 성분이 어떻게 가질 수 있는지를 설명한다. 상기의 예에서, 설계자는 코어1에서의 사용을 위한 자기 자신의 확장부를 작성할 것이다. 따라서, 도 19에 도시된 바와 같이 성분 타입 정의를 유지하기 위해 코어1에 포함된 라이브러리가 존재할 것이다.

도 19에 도시된 바와 같이, 사용자는 자신의 신규 확장부의 설계를 유지하기 위해 코어1(1902) 내부에 라이브러리를 작성하였다. 사용자가 신규 확장부를 설계한 후, 사용자는 확장부를 인스턴스화함으로써 코어에서 확장부를 사용한다. 이 프로젝트는 도 20의 디렉토리 구조(2000)를 포함할 것이다.

확장부가 코어1뿐만 아니라 코어2에서도 사용되어야만 하는 것으로 사용자가 결정할 가능성도 상당히 높다. 확장부가 양쪽 코어에 사용되도록 하기 위해, 설계자는 확장부를 양쪽 코어에 가시적인 라이브러리내에 위치시켜야만 할 것이다. 이러한 라이브러리에 대한 명백한(가능할뿐만 하니라) 장소는 도 21에 도시된 바와 같이 자신의 칩 성분(2100)내이다. 이제, 자신의 확장부 성분 정의(2102)가 양쪽 코어 내부에서 가시적이다.

본 발명의 전술된 부모-자녀 관계(다른 유사 관계뿐만 아니라)는 설계자가 자신의 프로젝트를 논리 블록으로 분할할 수 있도록 하며, 각각의 블록은 별도의 서브-프로젝트로 간주된다. 본 명세서에 사용된 바와 같은 IP 프로젝트라는 용어는 저장 장치(예를들어, 하드 드라이브)에 저장된 성분을 지칭하며, 따라서 사용자의 하드 드라이브 상에 저장된 임의의 성분을 지칭할 수 있다. 통상적으로, IP 프로젝트는 하나의 칩 성분으로 이루어지며, 이 칩 성분은 하나 또는 그 이상의 코어를 포함하며, 하나 또는 그 이상의 코어의 각각은 하나 또는 그 이상의 확장부를 포함하는(잠재적으로) 등등의 방식이 성립된다.

개발 시스템

다음의 설명은 각종 예의 개발 시스템에서의 라이브러리 및 프로젝트의 사용의 묘사를 제공한다. 개발 시스템은 예를들어, 전술한 설계 소프트웨어(예를들어, "ARChitect"), 컴파일러, 디버거 등과 같은 개발 툴뿐만 아니라 IP 관리 툴 및 다양한 라이브러리를 포함한다. 다음의 설명은 본질적으로 단지 예시적인 것이고, 본 발명과 함께 사용될 수 있는 상이한 개발 시스템 또는 성분의 조합의 총체를 나타내는 것은 아니라는 점을 인지하기 바란다.

아래에 상세히 설명된 개발 시스템의 일부가 소위 "소스 코드 제어 시스템"(SCCS)을 사용하는 것에 유의하기 바란다. 이러한 시스템은 특히 여러 개발자가 동일 세트의 파일에 대해 동시에 작업하고 있을 때에 대형 복합 시스템을 구축하기 위해 중요하다. 예로써, 요구된 자원을 대기할 소위 "테스트-앤드-웨이트" 기능(신호기(semaphore)와 같은)은 SCCS를 시행하기 위해 사용될 것이다. 종래 기술에서 널리 공지된 바와 같이, 신호기는 자원의 이용 가능성을 신호하기 위해 사용되는 메카니즘이다. 하나 또는 그 이상의 프로세스는 이용 가능성을 신호할 자원 신호기를 무한정으로 대기할 것이다. 이와 달리, 전술된 테스트 및 웨이트 기능성을 시행하기 위해 큐(queue)가 사용될 수도 있을 것이다. "큐"라는 용어는 일반적으로 프로세스간 커뮤니케이션을 위한 엔티티를 지칭하며, 분산 시스템 상의 어플리케이션부간에 메시지가 건네지도록 한다. 소정 프로세스는 자신의 큐를 작성하는 임의의 다른 프로세스에 메시지를 포스팅할 수 있다. 프로세스간 큐의 다수의 변형이 본 기술분양의 당업자에게는 널리 알려져 있다. 소스 코드 제어 시스템의 특정 실시는 일반적으로 프로그래밍 기술분야의 당업자에게 널리 알려져 있으며, 그에 따라 본 명세서에서는 추가로 설명되지 않는다.

프로세서 코어 및 SoC 시스템은 더욱 복잡하게 되고, 사용자는 자신의 프로젝트를 관리하기 위해 SCCS를 필요로 할 것으로 예상된다. 이러한 집적을 용이하게 하기 위해, 본 발명의 IP 라이브러리 및 IP 프로젝트 포맷은 논리 섹션이 개별적으로 인아웃 체크되도록 한다. 소스 코드 제어 시스템은 파일(일반적으로 텍스트 파일)로 작업하도록 설계된다. 예를들어, 체크-인/체크-아웃 연산은 개개의 파일 또는 전체 디렉토리에 관해 정상적으로 작용할 것이다. 따라서, 라이브러리 및 프로젝트에서의 논리적 구조는 단일 파일 또는 서브디렉토리로써 저장되는 장점을 갖는다. 예를들어, 다수의 코어를 갖는 다중-코어 프로젝트는 각각의 코어 및 그 연장부가 파일 또는 서브디렉토리로써 서장된다면 최상으로 시행될 것이다. 즉, 사용자는 작업할 코어를 "체크 아웃"할 것인 한편, 다른 사용자는 상이한 코어 상에서 작업한다. 이것은 모든 코어가 동일 파일에 저장되었다면 가능하지 않을 것이다.

단일 사용자 개발 시스템 - 도 22는 본 발명에 따른 일례의 단일 사용자 개발 시스템(2200)을 도시한다. 이 시스템의 속성은 (1)단일 사용자, (2)단일 IP 라이브러리, (3)다수의 IP 프로젝트 및 (4)소스 코드 제어 시스템 없음을 포함한다. 이것은 IC 개발 시스템의 가장 간략한 인스턴스이다. 사용자는 각종 프로젝트에 관해 홀로 작업한다.

다중-사용자 개발 시스템 - 도 23은 다음의 속성을 갖는 일례의 다중 사용자 개발 시스템(230)을 도시하며, 그 속성은 (1)다수의 사용자, (2)단일 IP 라이브러리, (3)다수의 IP 프로젝트, (4)소스 코드 제어 시스템 없음을 포함한다. 이 실시예에서, 여러 사용자는 상이한 프로젝트를 개발하지만, 성분 타입 정의의 하나의(또는 제한된 수의) 라이브러리를 사용한다. 따라서, 로컬 IP 프로젝트를 제외한 공유된 IP 라이브러리(모든 사용자에 의해 사용된)가 존재한다.

SCCS를 갖는 단일 사용자 개발 시스템 - 도 24는 SCCS를 갖는 일례의 단일사용자 개발 시스템(2400)을 예시한다. 이 시스템의 속성은, (1)단일 사용자, (2)단일 IP 라이브러리, (3)소스 코드 제어 시스템(SCCS)에 저장된 다수의 IP 프로젝트를 포함한다. 이 실시예는 프로젝트를 관리하기 위해 소스 코드 제어 시스템을 도입한 것을 제외하고는 이전의 단일 사용자 실시예와 동일하다. 임의의 복잡한 시스템을 개발할 때, 소스 코드 제어 시스템을 사용하도록 충고될 수 있을 것이다. 이것은 사용자가 IP 프로젝트에 관한 정상적인 SCCS 기능, 예를드어 버젼 제어, 체크인, 체크아웃, 브랜치화 등의 전부를 수행하도록 한다.

SCCS를 갖는 다중-사용자 개발 시스템 - 도 25는 SCCS를 갖는 일례의 다중-사용자 시스템(250)을 예시한다. 속성은 (1)다중 사용자, (2)단일 IP 라이브러리, (3)소스 코드 제어 시스템(SCCS)에 저장된 다중 IP 프로젝트를 포함한다. 이 실시예는 복수의 사용자가 종래의 소스 코드 제어 시스템을 사용하여 동시에 동일 프로젝트에 대해 어떻게 작업할 수 있는지를 예시한다. 이 경우, SCCS에 저장되는 하나의 프로젝트가 존재하지만, 각각의 사용자의 기기에 로컬적으로 체크아웃된다.

복수의 IP 라이브러리를 갖는 복수-사용자 개발 시스템 - 도 26은 복수-사용자, 복수-라이브러리 개발 시스템(2600)을 도시한다. 속성은 (1)복수의 사용자, (2)복수의 IP 라이브러리(일부는 로컬, 일부는 공유), (3)복수의 IP 프로젝트 및 (4)소스 코드 제어 시스템 없음을 포함한다.

도 22 내지 도 25의 실시예의 각각은 간혹 복수의 사용자간에 공유된 하나의 IP 라이브러리만을 포함한다. 그러나, 사용자가 자기 자신의 성분을 작성하거나 기존의 것을 수정하여 IP의 이러한 신규 부분을 IP 라이브러리(도 26)에 위치시키고자 원하는 때가 존재한다. 도 26의 실시예에서, 2명(또는 그 이상)의 사용자는 주요 성분(코어, 확장부 등)을 유지할 하나의 IP 라이브러리를 공유한다. 이들은 또한 자기 자신의 프로젝트에 사용하기 위한 주문형 성분을 유지할 로컬하게 저장된 자기 자신의 라이브러리를 갖는다. 로컬 라이브러리에 저장된 자기 자신의 성분의 일부는 다른 상이하지만 관련된 프로젝트에 관해 작업하는 다른 개발자에 의해서와 같이 조직화 전반에 걸쳐 사용할 수 있으며, 이 경우, 이들은 공유된 라이브러리에 전달될 것이다.

복수 IP 라이브러리 및 SCCS를 갖는 복수-사용자 개발 시스템 - 도 27은 일례의 SCCS를 갖는 복수-사용자, 복수-라이브러리 시스템(2700)을 도시한다. 속성은 (1)복수 사용자, (2)일부는 로컬이고 일부는 공유된 복수 IP 라이브러리, (3)복수의 IP 프로젝트 및 (4)SCCS를 포함한다. 이 실시예는 2명의 사용자가 공유된 프로젝트 및 공유된 IP 라이브러리에 관해 작업하고 이들 모두가 SCC에 저장된다는 점을 제외하고는 이전의 실시예와 유사하다.

복수의 IP 라이브러리, 프로젝트 라이브러리 및 SCCS를 갖는 복수-사용자 개발 시스템 - 도 28은 일례의 복수-사용자, 복수-라이브러리, 복수-프로젝트 개발 시스템(2800)을 도시한다. 속성은 (1)복수 사용자, (2)복수 IP 라이브러리(일부는 로컬, 일부는 공유, 일부는 프로젝트에 대해 로컬); 복수 IP 프로젝트 및 (4)SCCS를 포함한다. 이 실시예는 객체의 일부로써 라이브러리를 갖는다는 개념을 통합한다. 2명(또는 그 이상)의 사용자는 파일 서버에 저장된 광역 IP 라이브러리에 자기 자신의 로컬 라이브러리를 더하여 사용한다. 또한, 사용자가 작업하고 있는 프로젝트 중의 하나는 사용자가 작성한 약간의 프로젝트 특정 성분을 요구한다. 이들 성분은 IP 프로젝트 내부에서 라이브러리에 저장된다.

라이브러리 디렉토리 포맷

본 발명의 일례의 실시예에서의 IP 라이브러리의 디렉토리 구조는 다른 방식(및 언어)이 이용될 수도 있지만 주로 자바의 패키지 구조를 기초로 한다. 일례의 디렉토리 구조 방식은 하부의 디렉토리 구조를 미러링하고, 주기 또는 "도트"에 의해 분리된 패키지명에 기초된다. 예를들어, 자바에서, 'com.arc.architect' 클래스는 '＼com＼arc' 디렉토리에서 'architect.class' 파일을 찾음으로써 발견될 것이다. 디렉토리 트리의 깊이는 제한되지 않아서, 개발자는 자신의 클래스를 자신이 좋아하는 방식으로 그룹화할 수 있다. 그러나, 패키지의 명칭이 충돌하지 않는다면, 최고 레벨 패키지가 그에 따라 명명되어야 한다. 한가지 명명 방식은 반전된 회사 URL('www'이 없는) 후에 메인 패키지를 채용한다. 예를들어, ARC 웹 사이트는 'www.arc.com'이며, 반전된 URL은 'com.arc.www'이다. 다음으로, 'www'가 삭제되어 'com.arc'가 남는다. 따라서, ARC로부터의 임의의 자바 클래스에 대해 사용된 상단의 2개의 패키지 명칭은 'com' 및 'arc'가 되어야 한다. 따라서, 예의 클래스는 다음과 같이 되어야 한다:

com.arc.architect

com.arc.builder.filereader

com.arc.ipme.gui.componenttree

이들 클래스는 도 29에 도시된 디렉토리 구조(2900)에 저장될 것이다.

자바 - 예시된 실시예에서, 널리 공지된 Sun Microsystems "Java™" 랭귀지가 본 발명을 구현하는 소프트웨어를 실시하기 위해 사용될뿐만 아니라 IP 모델 자체의 집적부로써 사용된다. 전술된 바와 같이, 이 "IP 모델"의 한 아키텍쳐는 '전통적인' 정적 IP와 더 큰 슈퍼세트의 구성 가능한 IP를 통합한다. 설계 IP를 발생할 때, 설계자는 성분을 사용하기 위해 기본 정보를 포함할뿐만 아니라 최종 사용자가 IP를 더욱 효율적으로 사용할 수 있도록 각종 툴에 플러그-인할 것이다. IP의 설계자는 모든 플랫폼에 대해 플러그-인을 기입하도록 원하지 않으며, 최종 사용자는 자신의 IP(Windows, Unix 등)를 개발하기 위해 사용할 수도 있다. 따라서, 자바의 플랫폼 종속도 및 'run anywhere' 코드는 IP 플러그-인을 전달하기 위해 본 발명에 의해 채용되는 것이 좋다. 자바 패키지 모델은 또한 제3자가 소정 툴셋과의 사용을 위해 IP를 개발하려고 시작할 때 성분명이 충돌하지 않도록 보장하는 우수한 방식이다.

일례의 실시예에서 사용된 XML 포맷의 다음의 예가 제공된다:

상기의 예에서 알 수 있는 바와 같이, XML은 자바 클래스, 즉 'com.arc.data.OptionInst'을 명확하게 참조한다. 자바스크립트는 아래의 예에서예시된 바와 같이 그것을 스트링으로써 저장함으로써 XML에 이식될 수 있다:

자바스크립트는 본 명세서의 앞에서 참조되었고 아래에 설명되는 바와 같이 "도트 오퍼레이터"를 사용함으로써 XML을 참조할 수 있다.

도트 오퍼레이터를 사용하여 데이타를 검색하기 위한 기본적인 방법은 다음과 같다. 먼저, 각각의 경로는 항상 무엇인가에, 보편적으로는 성분 인스턴스에 관계한다. 이것은 경로에 의해 참조된 데이타를 찾기 위한 초기 스코프를 제공한다. 경로는 별도의 워드로 분할되며, 그 예를들면 'id.options.BusWidth'는 'id', 'options' 및 'BusWidth'로 분할된다. 경로의 첫번째 부분(즉, 'id')이 검사되며, 현재의 스코프는 는 그 객체를 탐색하도록 요청된다. 이 경우, 'id'에 대한 성분 인스턴스를 요청하는 것은 인스턴스 데이타를 탐색하기 위해 사용되는 객체를 리턴시킨다. 다음으로, 리턴되는 인스턴스 데이타 객체가 'options'으로 지칭되는 객체를 제공하기 위해 요구된다. 이 예에서, 이것은 하드 드라이브로부터 XML 파일을 로딩하는 것을 수반하며, 파일의 컨텐츠인 Java Object를 리턴시킨다.

최종적으로, 'BusWidth'로 지칭된 객체에 대해 파일 컨텐츠 객체가 요구된다. 이 예에서, BusWidth는 실제로 OptionInstance이다.

탐색 프로세서의 어느 지점에서 소프트웨어가 어떻게 적절하게 처리할지를알지 못하는 객체를 발견한다면, 그 소프트웨어는 그 객체를 어떻게 사용하는지를 그 소프트웨어에게 알려주는 플러그인을 검색한다. 이것은 본 명세서에 설명된 플러그인 프레임워크의 사용으로 이루어진다.

도트 오퍼레이터를 사용함으로써, 스크립트는 성분에서 벗어난 데이타를 복구할 수 있으며, 그 예를들면 'id.options.cachewidth'는 옵션에서 벗어난 캐시폭을 리턴시킬 것이다. 타입 및 인스턴스 데이타만이 특정되는 실시예에서, 제1 객체는 데이타가 타입 데이타 또는 인스턴스 데이타로부터 유래해야만 하는지를 특정하기 위해 'td' 또는 'id' 중의 하나가 되어야만 한다.

IP 라이브러리 및 객체 - 라이브러리는 다수의 상이한 타입의 객체, 예를들어 성분 타입, 링크 타입, 사이트 타입, 템플릿 등을 유지할 수 있다. 이들 객체는 자바 클래스가 고유하게 식별되어야만 한다는 동일한 이유로 고유 식별자를 갖는다. 자바에서, 클래스는 예를들어 'com.arc.architect'의 풀 패키지 경로를 사용함으로써 정밀하게 식별될 수 있다.

각종 라이브러리에서 객체를 찾아내기 위한 본 실시예에서 동일한 방식이 사용된다. 에를들어, 소정 회사(예를들어, ARC)로부터의 하드웨어 성분은 경로 'com.arc.ip.hardware.cores.tangent5_0'를 가질 것이다. 다음은 공통 객체 및 그들의 결과 라이브러리 구조의 예이다.

com.arc.ip.hardware.cores.tangent5_0

com.arc.ip.hardware.extensions.multiplier

com.arc.ip.hardware.extensions.barrelshifter

com.arc.ip.software.libraries.mathlib

도 30의 디렉토리 구조(3000)를 참조하기 바란다. 자바 패키지와 같이, 상위 레벨 패키지명은 충돌없는 명명 기술(예를들어, 'www'가 제거된 반전된 회사 URL)을 채용하여야 한다. 그 후, 다른 패키지명은 IP의 개발자에 의해 선택될 수 있다.

자바 클래스는 IP 성분의 일부로써 전달될 것이다. 이를 위해, IP 개발자는 툴 데이타(툴 데이타는 후속하여 상세히 설명된다)의 일부로써 성분을 갖는 하나 또는 그 이상의 클래스 파일을 선적할 것이다. 성분의 일부로써 자바 클래스를 예시하기 위해, 클래스 파일을 ARCtangent 프로세서에 삽입하는 다음의 예가 사용된다.

도 31은 일례의 ARCtangent Core IP의 디렉토리 구조(3100)를 예시한다. 도시된 바와 같이, CoreEditor.class 파일은 tangent5_0 성분 아래의 서브디렉토리에 저장된다. 이 파일이 라이브러리에 위치된다면, 도 32의 디렉토리 구조(3200)가 발생한다. 라이브러리를 자바 클래스경로의 일부로 함으로써, 클래스는 다음의 경로를 사용하여 액세스될 수 있다:

com.arc.ip.hardware.cores.tangent5_0.arc.gui.editor.CoreEditor

툴 데이타 및 인스턴스 데이타

본 발명의 예시된 일례의 실시예의 IP 라이브러리 및 IP 프로젝트에 저장된 정보는 2가지 타입의 데이타, 즉 (1)이들 성분이 어떻게 처리되는지를 툴에게 알려주기 위해 성분, 링크 및 사이트 타입에 저장되는 툴 데이타, (2)성분, 링크 및 IP프로젝트내의 사이트에 저장되고, 성분의 그 인스턴스에만 관련하는 정보인 인스턴스 데이타로 분할된다.

(ⅰ) 툴 데이타 - 틀 데이타는 특정 성분, 사이트 또는 링크 타입이 툴 데이타인지를 툴에게 알려주는 정보를 포함한다. 그러므로, 예를들어, 툴은 다음에 관련한 정보를 찾아내기를 원할 것이다:

1)소정 성분을 어떻게 구축할 것인지;

2)어떠한 경고 메시지가 성분에 적용될지, 그리고 이 메시지가 언제 디스플레이되어야 하는지;

3)사용자가 이 성분을 다른 성분에 어떻게 연결할 수 있는지;

4)이 성분을 위해 사용자가 어떠한 옵션을 선택할 수 있는지, 예를들어 현재의 ARC 코어는 캐시 크기, 버스폭 등에 대한 옵션을 가짐;

5)이 성분이 코어에 추가하는 명령어를 컴파일러가 어떻게 식별하는지; 그리고,

6)성분에 의해 사용된 인터럽트.

(ⅱ) 인스턴스 데이타 - 성분 인스턴스를 다른 것과 구별해주는 것은 인스턴스 데이타이다. 예를들어, 툴은 다음에 관한 정보를 획득하여야 한다:

1)사용자가 소정 성분에 대해 선택하는 옵션;

2)코어에 대한 프로파일링 데이타의 위치, 및

3)사용자에 의한 스크린 상에의 성분의 배치.

툴 데이타 및 인스턴스 데이타가 저장되는 방식의 중요한 부분은 그것이 어드레스되는 방식이다. 예를들어, 특정 성분 타입에 대한 툴 데이타는 파일의 수 메가바이트(MB)의 형태로 될 수 있다. 이들 파일은 일반적으로 논리적 디렉토리 구조로 배열될 것이다. 일례의 실시예에서, 디렉토리가 구성되는 방식은 자바 패키지가 배열되는 방식과 유사하다. 모든 툴 데이타는 라이브러리내의 성분 서브디렉토리에 저장된다. 그러나, 다른 구조가 본 발명과 함께 이용될 수도 있을 것이다.

본 발명의 인스턴스 데이타는 유사한 디렉토리 구조에 저장된다. 그러나, 성분 인스턴스 디렉토리 하의 '_data_' 서브디렉토리에 저장된다.

전술한 설명을 기초로, 성분 타입 및 성분 인스턴스에 대한 디렉토리 구조(3302, 3304)는 도 33에 도시된 바와 같다.

툴이 라이브러리로부터 툴 데이타를 탐색할 때, 툴은 데이타를 어드레스하기 위해 전체 경로를 사용한다. 또한, 자바와 같이, 경로는 '/' 또는 '＼' 대신에 ','를 사용한다. 또한, 경로의 제1 부분은 이들 2개의 분류가 특정될 때 'id'(인스턴스 데이타에 대해) 또는 'td'(툴 데이타에 대해) 중의 하나가 되어야만 한다. 에를들어, 성분 타입에서 'CacheSize'로 지칭된 옵션의 정의를 어드레스하기 위해, 경로는 다음과 같이 될 것이다:

td.options.CacheSize

이 에에서, 'options'은 파일이고, 'CacheSize'는 그 파일내의 XML 요소라는 점에 유의하기 바란다. 이 정보가 주어지면, 툴은 옵션 정의, 즉 그것이 어떠한 타입고, 어떠한 범위의 값을 취할 수 있는지 등에 대해 알게 된다. 사용자가 성분의 특정 인스턴스에 대해 선택한 실제 값이 결정된다. 이를 위해, 옵션 인스턴스 데이타가 활용된다. 툴이 프로젝트로부터 인스턴스 데이타의 여러 부분을 탐색할 때, 툴은 에이타를 어드레스하기 위해 전체 경로를('_data_' 디렉토리가 생략되고, '.'가 '/' 또는 '＼' 대신에 사용된다는 점을 제외하고는) 사용한다. 따라서, 변수 인스턴스 'CacheSize'에 대한 전체 경로는 다음과 같이 될 것이다:

id.options.CacheSize

툴 데이타 내의 인스턴스 데이타를 사용 - 본 발명은 툴 데이타가 인스턴스 데이타를 빈번하게 참조한다. 예를들어, 사용자가 성분에 대한 특정 옵션을 선택한다면, 에러 메시지가 디스플레이될 수도 있을 것이다. 그러므로, 툴 데이타는 다음과 같이 무엇인가를 탐색할 것이다:

메시지:

"Cache size cannot be greater than 16K with a bus width greater than 24"

조건:

id.option.CacheSize>16000 && id.options.BusWidth>24

위에 도시된 조건 표현식은 메시지 툴 데이타의 일부인 것이 명백하지만, 스크립트 해석기는 현재의 캐시 크기 및 버스폭을 알아야만 한다. 캐시 크기 및 버스폭은 인스턴스 데이타이ㅕ, 그에 따라 성분 인스턴스에 저장된다. 스크립트가 옵션에 대해 전체적으로 권한 부여된 경로를 어떻게 사용하는지에 주목하기 바란다. 이것은 스크립트 해석기가 요구된 파일에 대한 디렉토리 구조를 통해 검색하고 그리고나서 그 파일 내에서 정확한 XML 요소를 탐색할 수 있도록 해준다.

사이트에서의 변수 - 성분은 변수를 사용하여 사이트에 걸쳐 정보를 교환한다. 변소는 자바 객체를 콜러(caller)에게 리턴하기 위해 실행되는 스크립트의 일부로써 구현된 일구현예이다. 예를들어, 칩 객체는 칩의 클럭 속도를 설정하기 위해 사용되는 'Clock' 옵션을 가질 것이다. 그러나, 이 클럭 속도는 칩내의 모든 성분이 이들이 얼마나 신속하게 실행하는지를 알게 되도록 칩 내의 모든 성분에 전파되어야 한다. 클럭 속도에 대해 다른 성분에게 알려주기 위해, 그들을 링크시키기 위한 성분에 관한 클럭 링크 타입 및 사이트가 존재해야만 한다.

단순한 클럭 링크 타입에 대해 2개의 사이트 타입, 즉 마스터 및 슬레이브가 요구된다. 클럭 마스터 사이트 타입은 그 타입이 위치되는 성분이 클럭 속도를 제공하여야만 한다는 것을 특정한다. 유사하게, 클럭 슬레이브 사이트 타입은 성분이 클럭 속도를 수신할 것이라는 것을 특정한다. 클럭 마스터 사이트가 칩 상에 위치될 때, 설계자는 자신이 신규 사이트를 통해 클럭 속도를 제공할 필요가 있는 것에 대해 알게 될 것이다. 도 34는 이러한 2개의 일례의 성분(3402, 3404), 이들의 사이트(3406, 3408) 및 이들을 연결시키는 링크(3410)를 도시한다.

슬레이브 성분, 예를들어 경고 메시지에서서의 툴 데이타의 일부분을 고려해보면, 다른 툴 데이타와는 달리, 이러한 툴 데이타는 변수 인스턴스 등과 같은 인스턴스 데이타를 참조할 것이다.

메시지:

"Cache size cannot be greater than 32K with a chip clock speed greaterthan 200MHZ"

조건:

id.options.CacheSize>33000 && Clock[0].ClockSpeed>200

변수 앞에 'Clock' 사이트의 명칭을 놓음으로써, API는 칩의 마스터 사이트로부터 클럭 속도를 얻는다는 것을 알게 된다.

모든 변수는 성분 또는 그 사이트 중의 하나에 관련된다. 이를 달성하기 위해, 변수는 성분 타입의 '변수' 디렉토리에 파일로 저장된다. 각각의 사이트에 대해, 그 사이트로부터 이용 가능한 변수를 갖는 동일한 명칭의 "axml" 파일이 존재한다. 또한, 성분만에 속하는 변수를 갖는 'self.axml. 파일이 존재한다.

IP 라이브러리에서의 스크립팅

XML은 데이타 구조를 어드레스하기 위해 설계된 포맷이며, 프로그래밍 언어가 아니다. 데이타 구동 방식에 제공하지 않은 성분 타입 정의로 표현될 필요가 있는 정보의 여러 부분이 존재한다. 스크립팅 언어가 실행 시간에 해석되기 때문에 스크립팅 언어로 XML의 기능성을 연장시키는 것이 일반적이며, 코드는 XML 내부에 텍스트로써 직접 위치될 수있다.

툴 데이타 - 일부 툴 데이타는 표현식 평가로부터 이점을 갖는다. 에를들어, 특정 성분이 사용하는 게이트의 수에 대한 정보를 저장하는 툴 데이타의 일부분에 대해 고려하면, 이 정보는 사용자가 선택한 옵션에 좌우되어 변화할 수 있다. 예를들어, 배럴 시프터에 의해 사용된 게이트의 수는 사용자가 더 신속하게 선택하였는지 아니면 더 작게 선택하였는지의 여부에 좌우된다(더욱 복잡한 객체라면, 게이트의 수는 여러 변수값의 곱이 될 수 있다). 예를들어, 배럴 시프터 게이트 정보는 다음과 같이 계산될 필요가 있을 것이다:

그러나, 더 복잡한 예는 코어에 의해 사용된 게이트의 수일 것이다. 이 값은 다수의 속성에 기초한 계산을 요구할 것이다. 예를들어, 'Register File RAM', 'Cache Type', 'Cache Size', 'Memory Subsystem' 등을 고려할 필요가 있을 것이다.

기능성의 일부가 교체 사이트를 사용하여 교체될 때에 발생하는 것을 고려하면, 에를들어, 명령어 캐시가 또다른 캐시 성분에 의해 교체될 수 있는 경우, 코어에 의해 사용된 게이트의 수는 감소할 것이며, 신규 성분은 자신의 게이트의 수를 총계에 추가할 것이다. 따라서, 코어에 대한 게이트 카운트 계산은 디폴트 캐시가 사용되는지를 알아야만 할 것이다. 이를 행하기 위해, 게산은 캐시 오버라이드 사이트가 사용되는지의 여부를 고려해야할 것이다. 다음의 예를 고려한다:

툴 데이타에서의 스크립팅의 또다른 사용은 변수값을 툴을 구동하는 데이타에 넣는다. 예를들어, 신규 명령어를 추가하는 코어에 대한 확장부를 고려한다.한 배열에서, 각각의 확장 명령어는 성분이 작성될 때에 설정되는 사전 전의된 코드 번호를 갖는다. 인터페이스에 대한 툴 데이타는 도 35에 되시된 바와 같이 각종 툴에 대해 그 정보(3500)를 제공하기 위해 사용된다. 그러나, 코드 번호는 명령어 링크 타입의 변수가 될 것이다. 이것은 사용자가 신규 명령어에 대해 사용자가 사용하고자 원하는 코드를 선택하도록 할 수 있다. 링크 타입에 대한 툴 데이타는 'com.arc.ARCtangent.Instructions'을 포함하지만, 그 코드에 대한 수정된 값을 갖지 않는다. 그 대신, 스크립트(3600)의 일부분이 도 36에 도시된 바와 같이 사용된다. 도 36에 도시된 툴 데이타에서, 코드 번호는 도 35에서와 같이 더 이상 "33"이 아니며, 그 대신 정수에 대해 평가하는 스크립트의 일부분이 된다. 그러므로, 사용자가 소프트웨어로부터 코드를 변경할 때, 변경은 컴파일러, 디버거 등에 대한 툴 체인을 통해 리플한다.

스크립팅 랭귀지 - 일실시예에서, 본 발명은 스크립팅 랭귀지로써 ECMA 스크립트를 채용하며, 다른 언어도 성공적으로 대체될 수 있다. 이 언어는 JavaScript(Netscape) 및 Jscript에 기초하며, 동적 웹 페이지를 작성하도록 설계된다. 랭귀지는 유럽 컴퓨터 제조업체 연합에 의해 ECMA 스크립트로써 표준화되며, HTML(HTML은 XML의 서브세트임)에 대한 공공 스크립트 언어가 된다. ECMA 스크립트는 Java/C/C++ 과 유사한 신택스를 가지며, 스크립트가 조작하는 객체를 제공하는 호스트 어플리케이션의 원리레 기초한다. C-와 같은 신택스를 갖는 것은 다수의 엔지니어가 친밀감을 느끼도록 하는 장점을 갖는다. 그것은 함수, while 루프, for 루프, if/else 서술문뿐만 아니라 종래의 숫치 연산자(+, -, *, /, &,｜, >>, << 등)를 포함한다. 이것은 수학적 함수(sin, cos, log 등)에 대한 코어 객체 및 스트링 조작을 제공한다.

본 발명의 일례의 코드는 툴 데이타에 이식된 코드를 평가하는 완전한 JavaScript(ECMA) 해석기를 포함한다. 또한 예를들어 인터페이스 스크립팅, 테스트 스트립트와 같은 자기 자신의 필요성에 대한 해석기를 어플리케이션이 사용할 수 있도록 하는 것도 가능하다.

스크립트를 요구된 바대로 작업하기 위해, 정보의 여러 부분에 대한 액세스를 필요로 한다. 요구된 주요 정보는 다음을 포함한다:

1. 성분의 인스턴스 및 툴 데이타의 여러 부분

2. 성분이 다른 성분에 연결되는 방식(링크를 통해)

3. 연결된 성분으로부터의 변수.

스크립트의 각각의 부분은 스크립트가 판독 및 기입할 수 있는 모든 자바스크립트 변수를 유지하는 문맥 내부에서 실행한다. 성분 객체 모델에서, 이들 자바스크립트 변수는 인스턴스 데이타 및 링크에 대한 정보를 유지한다. 다음의 객체는 성분의 문맥에 있다:

ㆍ현재 성분의 모든 인스턴스 데이타를 볼 수 있다.

ㆍ현재 성분의 타입의 모든 데이타 툴을 볼 수 있다.

ㆍ현재 성분의 모든 변수 사이트를 볼 수 있다.

ㆍ모든 링크의 다른 엔드의 모든 변수를 볼 수 있다.

이것은 도 37의 관계(3700)에 그래픽으로 예시되어 있다.

실행되는 스크립트가 'Component'에 있다면, 다음의 변수를 볼 수 있을 것이다:

현재1, 현재2 및 현재3 - 이들은 스크립트와 동일한 성분에 속한다.

변수1 및 변수2 - 이들은 성분의 사이트에 속한다.

변수3 및 변수4 - 이들은 링크의 다른 엔드에 있는 사이트에 속한다.

그러나, 변수가 스코프에서 벗어날 때, 기타1, 기타2 및 기타3을 볼 수도 있을 것이다.

사이트 - 인스턴스 데이타에 관해, 스크립트는 사이트에 대한 정보를 획득할 수 있다. 각각의 사이트에 대해, 동일한 명칭의 문맥에 객체가 존재한다. 그 객체는 스크립트가 판독할 수 있는 다양한 멤버 변수를 갖는다. 멤버는 다음과 같다:

1) numLinks: - 이 사이트에 연결된 링크의 수

2) [n]: - 이 사이트에 연결된 n번째 링크를 획득

다음의 에는 이러한 개념을 예시한다.

예1 - 다음 코드는 캐시 성분이 코드가 첨부되는 코어에 관한 정보를 어떻게 찾는지를 보여준다:

예2 - 이 다음 예는 이 방식이 매우 복잡한 관계를 정의하기 위해 어떻게 사용될 수 있는지를 예시한다. 이 예에서, 코어 성분은 'Signal'로 치칭된 링크 사이트를 갖는다. 이 링크 사이트에 플러그하는 모든 성분은 신호에 지연량을 추가한다. 코어는 모든 성분의 전체 지연량이 1.0 미만이라는 것을 검증하여야 한다. 지연량은 신호 링크 타입의 확장부 역할의 변수가 될 것이다.

코어 성분은 지연량이 1을 초과하는지의 여부를 사용자에게 알려주는 경고 메시지를 가질 것이다. 이 경고는 경고자 유효한지 무효한지를 확인하기 위해 평가되는 스크립트의 관련 부분을 갖는다. 다음은 일례의 스크립트이다:

알 수 있는 바와 같이, 스크립트는 모든 연결된 성분을 통해 반복하며, 자신의 지연 값을 총계에 추가한다. 이 총계는 그 유효성을 판정하기 위해 1.0과 비교된다.

예3 - 앞의 예에서, 사용자가 다양한 확장 명령어에 의해 사용된 옵-코드(op-code)를 선택할 수 있는 곳에서는, 2개의 확장부가 동일한 옵-코드를사용하려고 시도하는 경우 경고 메시지가 존재할 것이다. 이 경고 메시지는 경고의 유효성을 확인하기 위해 평가되는 스크립트의 일부로 시행될 수 있다. 스크립트는 다음의 예에서와 같이 구성될 것이다:

이 코드는 어레이를 할당하며, 코어에 연결된 각각의 명령어 확장에 대해, 코드 번호에 의해 제공된 어레이 위치를 "참"으로 설정한다. 임의의 확장부가 이미 사용된 코드를 사용하려고 시도하는 경우, 그 어레이 엔트리는 이미 참으로 설정될 것이고, 경고가 나타난다.

트리 관리 - 본 발명은 또한 향상된 트리 관리를 제공한다. 이 기능은 전술된 플러그인 프레임워크에 기초한다. 툴이 트리에 어떻게 삽입되는지를 알지 못하는 데이타의 일부분을 통해 유입할 때, 이 점에 관해 툴에게 명령하는 플러그인을 검색한다. 예를들어, 제3 개발자가 C 파일에 추가되도록 요구된 파일을 무엇이 포함하는지에 대한 정보를 추가하기를 원한다면, 이 정보는 파일명의 리스트의 형태로 될 것이다. 툴이 이 정보를 트리에 어떻게 나타내는지에 대해 알지 못한다면, 개발자는 트리에 어떻게 추가하는지를 알려줄 treeable Provider를 자신의 데이타에 기입할 수 있다. 이 방식의 장점은 소프트웨어가 1차 개발자로부터의 입력없이도 제3 개발자 또는 최종 사용자에 의해 확장될 수 있다는 점이다. 이것은 자기 자신의 데이타를 성분에 포함하고자 원하는 다른 엔티티가 자신의 어코드 상의 IP에 대한 지원을 포함할 수 있게 한다.

툴 확장가능성 - 앞에서 참조된 바와 같이, 본 발명은 실행 시간에서 클래스를 찾기 위해 자바의 반영 메카니즘에 기초한 확장 가능한 툴을 이용한다. 이것은 최종 사용자로 하여금 1차 설계자에 의해 추가의 수정에 대한 필요성없이 어플리케이션에 자신의 클래스를 추가할 수 있도록 한다. 이것은 상이한 파일 타입을 로드 및 시하기 위한 플러그인, 라이브러리 및 프로젝트 트리를 주문하기 위한 플러그인 및 성분에 저장된 상이한 타입의 데이타를 시청하기 위한 플러그인 등을 포함한다. 예를들어, 제3자가 자기 자신의 적합한 데이타 포맷을 포함하는 라이브러리에 파일을 추가하고자 한다면, 제3자는 그 데이타를 소프트웨어내로 로딩하고 그것을 GUI 내에서 시청하기 위한 플러그인을 작성할 수 있다. 이것은 자바 클래스 또는 자바 파일을 플러그인을 위치시키기 위해 개시시에 분석되었던 저장 장치(예를들어, 시스템 하드 드라이브) 상의 디렉토리 내로 위치시킴으로써 일실시예에서 달성된다.

플로그린은 정확한 디렉토리에 자바 클래스를 위치시킴으로써 단순하게 툴에추가될 수 있다. 툴은 이들이 무슨 성능을 가졌는지를 알아내기 위해 자바 반영을 이용하여 클래스를 검사한다. 플러그인은 자신의 태스크를 자동적으로 수행할 수 있다. 예를들어, 플러그인은 클래스를 일직선화하거나 데이타의 신규 부분에 편집기를 제공할 수 있다.

HTML 문서 생성 - 본 발명의 다른 특징에서, 일례의 어플리케이션은 사용자가 선택한 특정 프로젝트 구성에 대한 문서를 자동적으로 생성한다. 다양한 특징이 주문형 HTML 사용자 문서로 문서화된다. 포함된 정보는 성분 정의내의 데이타로부터는 동적으로 구축되지만, 성분 인스턴스내에서는 옵션에 의해 구성되며, 이것은 프로젝트에 특정한 주문형 문서 세트를 구축하는데 필수적이라는 것을 나타낸다. 예를들어, 승산기가 설계에 포함된다면, 명령어 세트 문서는 이 확장부에 의해 추가된 명령어를 포함할 것이며, 게이트 카운트는 성분에 의해 취해진 게이트를 디스플레이할 것이다. 승산기를 더 작은 실행으로 설정하도록 승산기 옵션을 구성하며, 게이트 카운트는 문서에 대해 감소할 것이다. 이 정보는 주문형 HTML 문서에 반영될 필요가 있다.

HTML 문서를 생성함에 있어서, 데이타는 프로젝트에 포함된 모든 성분으로부터 인입되며, 대부분의 경우 이들은 하드웨어 성분이지만, 실제로 소프트웨어 패러다임에 적용될 수 있다. 데이타는 수집 및 포맷되어, 사용자에 의해 판독 가능한 태뷸러 포맷의 HTML로써 출력된다. 하드웨어 프로젝트에 대한 생성된 테이블의 예는 설계 서머리, 인터럽트, 레지스터 세트, 명령어 세트 및 게이트 카운트의 예가 된다.

구축 시퀀서 - 본 발명의 일례의 실시예에서, 설계를 구축하는 프로세스는 빌드 시퀀서에 의해 처리된다. 이것은 빌드 프로세스에서의 각각의 자동 스텝에 대한 별도의 '시퀀스'를 가지며, 사용자로 하여금 종래의 방식보다 더 우수한 제어를 가능하게 한다. HDL 또는 컴파일 스크립트를 재구축함이없이 사용자가 단지 검사 코드를 재컴파일하고 검증 테스트를 실행할 수 있도록 결정할 수 있어 신규 성분을 개발할 때에 상당한 시간을 절감할 수 있는 예가 존재할 것이다.

시퀀서는 사용자에 의해 설정된 옵션에 의해 제어되며, 이들은 시퀀스에서 예를들어 참 또는 거짓으로값을 설정함으로써 어느 단계가 실행하는지를 결정한다.

각각의 시퀀스 단계는 프로젝트 및 IP 라이브러리로부터 인스턴스 및 툴 데이타에 대한 액세스를 갖는 자바스크립트의 섹션이 필수적이다. 일부 추가 기능은 명령 라인어플리케이션을 실행하고, 메시지를 출력 윈도우에 로그하고, 파일을 처리하는 것과 같은 공통 동작을 수행하기 위해 사전 정의된 자바스크립트의 형태로 제공된다. 사용자는 또한 이들이 모두 IP 라이브러리 자체에 포함되어 있을 때에 이들 사전 정의된 스크립트의 프레임워크에 자유로이 추가된다.

토폴로지 디스플레이 - 본 발명의 일례의 실시예는 사용자 설계에 관한 그래픽 표현을 보여주도록 적합화된 "토폴로지 시청"을 포함한다. 토폴로지 데이타는 설계에 포함될 때 성분이 어떻게 디스플레이되어야 하는지와, 다른 성분과 그룹화되어야 하는지 아니면 자신만이 표현되어야 하는지의 여부의 상세를 제공하는 각각의 성분에 저장된다. 토폴로지 도면은 특정 링크 정보를 그리고 그룹화하며 디스플레이하는 것을 자동적으로 처리한다. 또한 토폴로지 도면은 자신의 옵션 값을변경하고 설계로부터 옵션값을 삭제할 수 있도록 성분을 선택하기 위한 클릭 또는 포인트를 제공한다. 현재의 IP 라이브러리내의 모든 이용가능한 성분을 디스플레이하는 성분 뷰어와 관련하여, 현재의 프로젝트에 성분을 추가하기 위한 드롭 앤드 드래그 기능을 제공한다.

성분에 의해 제공된 데이타를 사용함으로써, 어떠한 특정 설계에 허용된 성분의 각각의 타입의 수에 대한 사용자 피드백을 제공하며, 이에 의해 사용자는 불법적 성분의 조합을 작성하는 것이 방지된다.

집적회로 소자

전술된 바와 같이, 본 출원인의 ARCtangent 프로세서 코어 구성은 본 명세서에 설명된 일례의 실시예의 IC 소자에 기초하여 사용된다. 그러나, 요구시 다른 배열 및 구성으로 대체될 수 있다. 소자는 본 명세서에서 언급된 방법을 사용하여 획득된 주문화된 VHDL 설계를 사용하여 제조되며, 이 방법은 논리적 레벨 표현식으로 합성되며, 반도체 기술 분야에 널리 공지된 제조 기술 및 레이아웃을 사용하여 물리적 소자로 축소된다. 예를들어, 본 발명은 0.35, 0.18 및 0.1 미크론 공정과 호환 가능하며, 궁극적으로는 더 소형의 또는 다른 해상도의 프로세스에 적용될 것이다. 본 소자를 제조하기 위한 일례의 프로세스는 IBM 사에 의해 제공된 0.1 미크론 "블루 로직" Cu-11이며, 다른 방법도 가능하다.

본 발명의 IC 소자가 직렬 통신장치, 병렬 포트, 타이머, 고전류 드라이버, 아날로그-디지털(A/D) 변환기, 디지털-아날로그(D/A) 변환기, 인터럽트 프로세서, LCD 드라이버, 메모리 및 기타 유사장치와 같은 일반적으로 입수가능한 주변장치를포함할 수도 있다는 것을 당업자는 인식할 수 있을 것이다. 또한, 상기 프로세서는 앞서 본 명세서에서 언급된 바와 같이 단일 패키지에 서로 다른 여러 가지 기능성(functionalities)을 부여하는데 유용한 시스템-온-칩(system-on-chip: SoC) 장치를 구성하기 위해 기타 다른 커스텀(custom) 또는 어플리케이션 특수 회로를 포함할 수도 있다. 본 발명은 상기 방법 및 장치를 이용하여 결합가능한 주변장치 및 기타 회로의 유형, 개수 또는 복잡성에 국한되지 않는다. 아울러, 제한성은 시간이 지남에 따라 개선되는 반도체 공정의 물리적 용량에 의해 주로 부과된다. 따라서, 본 발명을 이용한 복잡도 및 집적도가 반도체 공정이 개선됨에 따라 향상될 것으로 기된다.

본 발명의 일부 특징들은 지금까지 발명의 특성 단계의 시퀀스면에서 설명되었지만, 이들 설명은 단지 본 발명의 보다 넓은 범위의 방법을 예시한 것에 불과하며, 특수 응용분야에서 요구된 것처럼 수정될 수도 있다. 일부 방법 단계들은 상황에 따라 불필요하거나 선택적으로 수행될 수도 있다. 또한, 일부 방법단계 또는 기능성은 이미 개시된 실시예 또는 변경된 2이상의 단계를 수행하는 순서에 부가될 수도 있다. 모든 변형예는 본 명세서에 개시되고 권리주장된 발명의 범위내에 포함되는 것으로 간주된다.

앞서 상기 상세한 설명이 다양한 실시예에 적용되는 발명의 신규한 특징를 도시하고, 설명하며, 지적했지만, 예시된 장치 또는 과정의 형태 및 상세의 다양한 생략, 대체 및 변경이 본 발명의 범위를 벗어나지 않고 당업자에 의해 이루어질 수도 있다는 것을 이해할수 있을 것이다. 전술한 상세한 설명은 어떠한 의미로도 제한적이지는 않지만, 본 발명의 일반적인 원리를 예시한 것으로 간주되어야 한다. 본 발명의 범위는 하기 특허청구의 범위를 참조하여 결정되어야 한다.

첨부 1(예시 코드)

첨부2(예시코드)

Claims (44)

1. 집적회로의 설계를 발생하기 위한 컴퓨터로 처리되는 시스템에 있어서,

   객체 지향 설계 환경을 포함하는 것을 특징으로 하는 시스템.
2. 제1항에 있어서, (ⅰ)디버깅되는 코드내의 적어도 하나의 브레이크포인트의 설정과, (ⅱ)상기 설계의 발생 동안의 상기 코드를 통한 단계형 진행을 허용하도록 적합화된 스크립트 디버거를 포함하는 디버그 환경을 추가로 포함하는 것을 특징으로 하는 시스템.
3. 제1항 또는 제2항에 있어서, 상기 환경은 상기 집적회로의 사용자 구성가능성을 허용하도록 적합화되며, 상기 집적회로의 적어도 하나의 성분이 객체에 의하여 묘사되는 것을 특징으로 하는 시스템.
4. 제3항에 있어서, 상기 성분의 묘사의 적어도 일부분은 인캡슐레이션화되는 것을 특징으로 하는 시스템.
5. 제3항에 있어서, 상기 성분의 묘사의 적어도 일부분이 대화형이며, 상기 대화형 성분의 적어도 하나가 그와 관련된 적어도 하나의 링크를 갖는 것을 특징으로 하는 시스템.
6. 제1항에 있어서, 상기 설계내의 성분을 표현하는 객체는 타입 및 인스턴스를 포함하는 것을 특징으로 하는 시스템.
7. 제6항에 있어서, 상기 타입의 적어도 하나가 적어도 하나의 라이브러리에 저장되며, 상기 인스턴스의 적어도 하나가 적어도 하나의 프로젝트에 저장되는 것을 특징으로 하는 시스템.
8. 제7항에 있어서, 적어도 하나의 링크 타입 및 적어도 하나의 링크 인스턴스를 추가로 포함하는 것을 특징으로 하는 시스템.
9. 제1항에 있어서, 상기 객체 지향 환경은 복수의 성분 인스턴스를 프로젝트로써 계층적 데이타 구조에 저장하도록 적합화되는 것을 특징으로 하는 시스템.
10. 제9항에 있어서, 상기 계층적 데이타 구조는, 상기 프로젝트의 상기 성분 인스턴스의 각각이 상기 시스템과 관련된 저장장치 상에 자기 자신의 디렉토리를 포함하는 트리 구조를 포함하는 것을 특징으로 하는 시스템.
11. 제10항에 있어서, 상기 성분의 적어도 하나는 그 성분과 관련된 데이타를 저장하도록 적합화된 제1 디렉토리와, 상기 적어도 하나의 성분에 의해 소유된 적어도 하나의 라이브러리 성분을 포함하는 제2 디렉토리를 갖는 것을 특징으로 하는 시스템.
12. 제1항에 있어서, 상기 객체 지향 환경은 상기 시스템과 관련된 복수의 이질적 툴과 호환 가능하게 되도록 적합화된 표준화된 데이타 구조를 갖는 것을 특징으로 하는 시스템.
13. 제1항에 있어서, 상기 설계 내의 복수의 성분은 인캡슐레이션화된 객체를 포함하며, 상기 인캡슐레이션화된 객체는 하나 또는 그 이상의 상기 성분이 어떻게 링크될 수 있는지에 관해 상기 적어도 하나의 툴에 제공된 정보를 갖고 있는 것을 특징으로 하는 시스템.
14. 제1항에 있어서, 상기 설계와 관련되고 각각이 적어도 하나의 인터페이스를 갖는 복수의 성분은 인캡슐레이션화된 객체를 포함하며, 상기 인캡슐레이션화된 객체의 각각은 적어도 하나의 디폴트 접속 구성 또는 상기 적어도 하나의 사이트를 특정하는 정보를 갖고 있는 것을 특징으로 하는 시스템.
15. 제14항에 있어서, 상기 정보는 툴에 의한 개시시에 실행되도록 적합화된 스크립트를 포함하며, 상기 스크립트의 상기 실행은 상기 구성을 묘사하는 것을 특징으로 하는 시스템.
16. 제1항에 있어서, 상기 환경은 라이브러리 내에 저장된 복수의 상이한 구축 프로세스를 포함하는 것을 특징으로 하는 시스템.
17. 제16항에 있어서, 상기 구축 프로세스의 적어도 하나는 적어도 하나의 프로젝트와 관련되며, 상기 적어도 하나의 구축 프로세스는 상기 프로젝트와 관련된 설계가 구축되는 방식을 특정하는 것을 특징으로 하는 시스템.
18. 제16항에 있어서, 적어도 하나의 구축 프로세스는 상기 출력의 다수의 카피가 상기 설계에 사용되도록 하는 고유하게 인스턴스화된 변수명을 갖는 것을 특징으로 하는 시스템.
19. 전술한 항들 중의 어느 한 항에 있어서, 상기 설계는 복수의 성분 정의를 포함하며, 상기 성분 정의의 적어도 일부가 각각 GUI 코드의 적어도 일부분을 포함하는 것을 특징으로 하는 시스템.
20. 제19항에 있어서, 상기 GUI 코드는 자바 랭귀지 GUI 객체를 포함하는 것을 특징으로 하는 시스템.
21. 제19항에 있어서, 상기 GUI 코드는 실행 어플리케이션에 동적으로 포함될수 있는 자바 스크립트로써 분포된 루틴을 포함하는 것을 특징으로 하는 시스템.
22. 전술한 항들 중 어느 한 항에 있어서, 상기 객체 지향 설계 환경은 네트워크 인터페이스를 통해 적어도 하나의 원격 정보 소스에 접속되며, 상기 환경은 상기 네트워크 인터페이스를 통해 성분 또는 다른 관련 데이타에 대한 업데이트를 자동적으로 획득하기 위해 상기 적어도 하나의 소스와 협동하도록 구성되는 것을 특징으로 하는 시스템.
23. 제1항에 있어서, 적어도 하나의 GUI 기반 함수와;

    설계 라이브러리와;

    상기 라이브러리내에 배치된 복수의 이질성 설계 성분을 추가로 포함하며,

    상기 라이브러리는 하나 또는 그 이상의 기준에 기초하여 상기 성분을 카테고리화하며, 상기 적어도 하나의 GUI 함수는 특정 성분을 이 성분의의 카테고리 기준을 기초로 하여 식별하고, 후속하여 이들을 디스플레이하는 것을 특징으로 하는 시스템.
24. 제1항에 있어서, 상기 설계 환경은 설계 내에서 링크될 수도 있는 복수의 설계 성분을 포함하며, 상기 링크는 인간에 의한 판독이 가능한 적어도 일부분을 포함하는 것을 특징으로 하는 시스템.
25. 제1항에 있어서, 상기 설계는 인캡슐레이션된 객체로써 표현된 복수의 성분을 포함하며, 상기 인캡슐레이션된 객체의 적어도 일부는 표현된 성분의 적어도 하나의 종속도를 묘사하는 정보를 갖고 있는 것을 특징으로 하는 시스템.
26. 제25항에 있어서, 상기 표현된 성분의 적어도 하나는 명령어 캐시를 포함하며, 상기 정보는 최대의 메모리 버스폭을 포함하는 것을 특징으로 하는 시스템.
27. 제25항에 있어서, 상기 정보는 적어도 하나의 자바스크립트를 포함하는 것을 특징으로 하는 시스템.
28. 제1항에 있어서, 상기 설계는 인캡슐레이션화된 객체에 의해 표현된 복수의 성분을 포함하며, 상기 인캡슐레이션화된 객체는 설계 계층 정보를 포함하는 적어도 하나의 인터페이스를 포함하는 것을 특징으로 하는 시스템.
29. 제28항에 있어서, 상기 적어도 하나의 인터페이스는 관련 성분의 제1 및 제2 인터페이스를 포함하며, 제1 인터페이스는 부모 인터페이스를 포함하고, 제2 인터페이스는 자녀 인터페이스를 포함하는 것을 특징으로 하는 시스템.
30. 전술한 항들 중의 어느 한 항에 있어서, 적어도 하나의 플러그-인 모듈의 추가를 허용하도록 적합화된 복수의 툴을 갖는 사용자 확장 가능한 소프트웨어 툴셋을 추가로 포함하는 것을 특징으로 하는 시스템.
31. 제30항에 있어서, 적어도 하나의 객체 클래스 파일이 저장장치의 소정 디렉토리에 위치되며, 상기 툴은 상기 툴에 의한 상기 적어도 하나의 플러그-인 모듈의 사용을 허용하기 위해 상기 적어도 하나의 클래스 파일을 검사하는 것을 특징으로 하는 시스템.
32. 전술한 항들 중의 어느 한 항에 있어서, 상기 객체 지향 설계 환경은 데이타 라이브러리를 포함하며, 상기 라이브러리에 저장된 데이타는 복수의 서브성분으로 분할된 경로 정의를 사용하여 검색되도록 적합화되는 것을 특징으로 하는 시스템.
33. 제32항에 있어서, 상기 복수의 서브성분은 타입 또는 인스턴스 데이타를 나타내는 제1 서브성분과, 서브성분관 관련된 하나 또는 그 이상의 객체를 리턴시키기 위해 순차적으로 호출되는 복수의 다른 서브성분을 포함하는 것을 특징으로 하는 시스템.
34. 제1항에 있어서, 상기 설계는 인캡슐레이션화된 객체에 의해 표현된 복수의 성분을 포함하며, 상기 객체는 각각 다른 객체와의 적어도 하나의 인터페이스를 가지며, 상기 적어도 하나의 인터페이스는 그 인터페이스를 통해 전달된 데이타에 관한 정보를 갖고 있는 것을 특징으로 하는 시스템.
35. 제34항에 있어서, 상기 복수의 성분은 프로세서 코어 및 확장 명령어를 포함하며, 상기 정보는 상기 확장부에 대한 상기 코어와 관련된 HDL에 추가되어야만 하는 HDL을 포함하는 것을 특징으로 하는 시스템.
36. 제34항에 있어서, 상기 정보는 상기 데이타를 검색하기 위해 실행시간에 평가되는 스크립트를 포함하는 것을 특징으로 하는 시스템.
37. 전술한 항들 중의 어느 한 항에 있어서, 적어도 하나의 확장 가능한 GUI 트리를 추가로 포함하며, 상기 확장 가능한 GUI 트리는 사용자가 상기 트리와 적어도 하나의 플러그-인 모듈간의 관계를 특정할 수 있도록 하는 것을 특징으로 하는 시스템.
38. 전술한 항들 중의 어느 한 항에 있어서, 상기 사용자에 의해 선택된 특정 구성과 관련된 주문형 문서를 자동적으로 발생하도록 추가로 적합화되는 되는 것을 특징으로 하는 시스템.
39. 전술한 항들 중의 어느 한 항에 있어서, 사용자가 상기 설계의 발생 동안에 복수의 별도의 구축 시퀀스 중의 하나 또는 그 이상을 선택적으로 할용할 수 있도록 적합화된 구축 시퀀스를 추가로 포함하는 것을 특징으로 하는 시스템.
40. 제39항에 있어서, 상기 복수의 시퀀스는 컴파일 시퀀스 및 검증 시퀀스를 포함하는 것을 특징으로 하는 시스템.
41. 제1항에 있어서, 상기 설계 내의 각각의 성분에 의해 제공된 정보에 기초하여 상기 설계의 기하학적 표현식을 발생하도록 적합화된 적어도 하나의 모듈을 추가로 포함하는 것을 특징으로 하는 시스템.
42. 제41항에 있어서, 상기 설계의 성분 중의 적어도 일부는 인캡슐레이션화된 객체에 의해 표현되며, 상기 인캡슐레이션화된 객체의 각각은 상기 기하학적 표현식을 어셈블하기 위해 상기 모듈에 의해 사용된 정보를 포함하는 것을 특징으로 하는 시스템.
43. 제42항에 있어서, 상기 기하학적 표현식은 GUI 환경의 일부로써 디스플레이되며, 상기 GUI 환경은 상기 인캡슐레이션화된 객체 내에 위치된 제2 정보를 활용하고 상기 성분의 불법적 조합이 설계에 나타날 때에 사용자 알림을 제공하도록 적합화되는 것을 특징으로 하는 시스템.
44. 복수의 성분을 갖는 집적회로 설계 내에 계층을 발생하기 위한 방법에 있어서,

    상기 복수의 성분 중의, 각각 제1 타입의 사이트를 갖는 적어도 일부의 성분에 코드를 제공하는 단계와;

    상기 복수의 성분 중의 상기 코드를 갖지 않은 성분에 관해 제2 타입의 사이트를 정의하는 단계와;

    상기 제1 및 제2 사이트의 적어도 일부를 연결시켜 계층을 발생하는 단계를 포함하는 것을 특징으로 하는 방법.