KR100329305B1 - 시스템설계검증방법및설계검증장치 - Google Patents

Abstract

정적 부분 순서 축소 및 기호 검증을 사용하는 본 발명의 방법 및 장치는, 검증될 하드웨어와 소프트웨어를 둘다 포함하는 시스템의 설계를 가능하게 한다. 이 시스템은 하드웨어-중심 언어와 소프트웨어-중심 언어로 적절하게 명시되며, 특성들은 한 번에 하나를 검증한다. 각 특성은 그것이 하드웨어-중심인지 소프트웨어 -중심인지 식별된다. 소프트웨어를 거의 함유하지 않는 하드웨어-중심 특성은 정적 부분 순서 축소를 사용하지 않는다. 소프트웨어의 실질적인 양을 갖는 소프트웨어-중심 특성 및 하드웨어-중심 특성은 정적 부분 순서 축소를 사용한다. 부분 순서 축소에 따라, 소프트웨어-중심 언어 명세는 동기 형식으로 변환되고, 하드웨어-중심 명세와 조합된다. 그 조합된 명세는 COSPAN과 같은 기호 검증에 적용되고, 그 결과가 표시된다.

Description

시스템 설계 검증 방법 및 설계 검증 장치

관련출원의 참고문헌

본 출원은 1997년 11월 3일 출원된 미합중국 임시 특허출원 번호 제 60/064,080호의 이익를 가지고 있음을 주장한다. 본 출원은 또한 이와 함께 동일 날짜에 동일 발명가들이 출원한 "정적 부분 순서 축소(Static Partial Order Reduction)"라는 명칭의 제2 출원과 관련있다.

발명의 배경

본 발명은 하드웨어 및 소프트웨어 설계 검증에 관한 것이다. 하드웨어/소프트웨어 공동설계의 한 면은 하드웨어/소프트웨어 인터페이스에서의 검증을 다루고 있다. 하드웨어 및 소프트웨어를 분리해서 설계할 경우에는 일반적으로 각 설계그룹의 기대치가 나머지 하나의 구현과 조화되지 않는다는 것이 공통적인 문제점이다. 이것은 특히 하드웨어(또는 소프트웨어)가 소프트웨어(또는 하드웨어)의 행동을 제어하면서, 하드웨어와 소프트웨어가 광범위하게 상호 작용하는 상황에서 더욱 그러하다. 그러한 접속이 적절하게 취급되지 않을 경우, 논리적 오류가 생기기 쉬우며, 결국 생산성이 저하되고 비용이 많이 들게 된다. 하드웨어는 소프트웨어쪽을, 또 소프트웨어는 하드웨어쪽을 대략적으로 이해하기만 하면 성공적으로 설계할 수 있다는 일반적인 추정은 복잡한 시스템에서 적용될 수 없다. 하드웨어(또는 소프트웨어) 설계팀은 소프트웨어(또는 하드웨어) 설계에 의해 한정된 그의 "환경"의 정밀한 묘사를 요구한다. 하드웨어 설계와 소프트웨어 설계의 형식적 모델이 이러한 요구의 지원에 사용된다면, 접속 부조화의 문제점은 형식적 환경 묘사의 문맥(context)에서 설계를 개발하는 방법의 문제로 이동된다.

개념적으로는, 형식 검증은 이러한 문제에 대한 해결책을 제공할 수 있었다. 그러나, 이와 관련해 모델-점검의 직접 응용은 대부분 불가능하다. 왜냐하면, 각측은 각각 그러한 응용가능한 검증의 한계에 자주 근접하기 때문이다. 또한, 이것은 소프트웨어에 대한 유한상태 검증에서 본질적인 어려움이 있으며, 이것은 종종 기억장치에 대한 그의 의존도의 계산상의 무한상태 시스템으로서 비춰진다.

하드웨어/소프트웨어 공동설계는 방법론의 표현으로 널리 다루어져 왔지만, 형식적 공동검증에 대해 실행 가능한 방법이 공개된 것은 없다. 이러한 공동검증 문제는 주로 검사(testing)의 문제로서 취급되며, 여러 가지 시판되는 도구들은 하드웨어와 관련해 소프트웨어를 검사하기 위해 출시되었고, 소프트웨어와 관련해 하드웨어를 검사하기 위해 출시되었다.

위와는 달리, 부분 순서 축소(Partial Order Reduction)와 기호 상태공백 탐색은 모델점검의 고유의 계산상의 복잡성과 맞서서 널리 적용되어왔다. 일반적으로, 이러한 기술은 별개로, 즉 하드웨어만 또는 소프트웨어만 응용된다. 왜냐하면 그들은 호환될 수 없는 것으로 보였기 때문이다. 문헌에서 밝혀진 부분 순서 축소 알고리즘은 본질적으로 깊이 우선 탐색과 관련해 명시 상태 열거(explicit state enumeration)에 기초한 것이다. 선행기술에서 밝혀진 부분 순서 축소는 상태들을 열거하는 경로에서동적으로유래된다. 기호검증(symbolic verification)은 각 부울 함수(Boolean functions)에 의해 정의된 여러 군의 상태만을 다룬다. 상태 달성가능성은 상태-공백의 너비 우선 탐색을 실행하는 단조 상태 세트 연산자의 근사치(convergence)로 표현된다.

이와 관련해 부분 순서 축소의 문제는 상태-공백 탐색의 경로에서 연기될 수 있는 특정 트랜지션(transition)이 (그래서 목적하는 축소치로 올림), 무한히 연기되지 않는다는 (그래서 불완전한 탐색을 하게 됨) 것을 보장하는 것과 관련이 있다. 이것은 명시상태 열거와 관련해 실행되는 통상의 방법은 깊이 우선 탐색 동안 임의의 사이클-닫음 경로에서 그렇게 연기된 모든 트랜지션을 조사하는 것이다.

그럼에도 불구하고, 부분 순서 축소와 기호 검증이 조합될 수 없다는 근본적인 이유는 없다. 아마도 그러한 조합을 위한 첫 번째 공개된 제안은 문헌 [R. Alur, R.K. Brayton, T.A. Henzinger, S. Zadeer, 및 S.K. Rajamani, in "Partial order reduction in symbolic state space exploration,"Conference on Computer Aided Verfication (CAV97), LNCS 1254, Springer-Verlan, (1997) 340-351페이지]에 의해서 제공된 것이다. 이 논문에서, 사이클-닫음 조건은 기호 나비 우선 탐색의 경로에서 일부 추가 단계로 교체되고, 이들 추가의 단계들은 변경될 정상 모델점검 알고리즘을 필요로 한다.

하드웨어/소프트웨어 공동검증의 장애는 기존 모델점검 알고리즘들(model checking algorithm)을 변경할 필요없이 부분 순서 축소(partial order reduction) 및 기호 검증(symbolic verification)을 사용하는 방법에 의해서 극복된다. 특히, 하드웨어는 하드웨어-중심 언어로 명시되고, 소프트웨어는 소프트웨어-중심 언어로 명시되며, 두가지 명세는 두가지 언어로 작동되도록 적응된 단일 설계 검증도구에 적용된다. 기능상으로는, 그러한 공동설계는 검증될 특성들을 확인하고 그러한 특성들을 각각 검증함으로써 검증된다. 각 특성을 검증함에 있어서, 각 특성의 행동에 영향을 미치는 시스템의 하드웨어 부분과 소프트웨어 부분에서 그들의 소자만이 고려된다. 검증 프로세스에 있어서, 정적 부분 순서 축소는 고려될 필요가 있는 소프트웨어 상태들를 확인하기 위해 사용되며, 이것은 다른 소프트웨어 상태들을 고려하지 않도록 한다. 설명된 정적 부분 순서 축소(static partial order reduction)는 모델 점검 알고리즘으로부터 완전히 분리되므로, 그것은 특정 탐색 기술에 의존하지 않는다.

동기 하드웨어 모델과 호환성인 비동기 소프트웨어 모델의 부분 순서 축소를 갖기 위해서는, 비동기 모델은 동등한 동기 모델로 변형되고, 부분 순서 축소는 자동동작(automation)에 의해 한정된 제약조건들에 의해 실행된다. 이러한 자동조작은 컴파일 시간으로 한정된다. 동기 변환은 동기를 시뮬레이션 하기 위해 미결정주의를 사용하며, 제약조건들은 부분 순서 축소와 관련된 중복 트랜지션을 제거한다. 그러므로, 부분 순서 축소의 전체의 내재하는 형식은, 검증도구를 개선할 필요가 전혀없이 컴파일러에 의해 정적으로 창출된다.

예를들면, 소프트웨어 모델은 SDL 언어를 사용한다. 하드웨어는 VHDL 또는 Verilog의 합성된 서브세트(subset)로 표현된다. 이 두가지 모델은 접속을 통해서 조합되며, 이들의 각각은 소프트웨어측에 대해서는 SDL 처리와 같이 보이고, 하드웨어측에 대해서는 HDL 모듈인 것 같다. 소프트웨어 모델과 하드웨어 모델은 둘다 검증도구에 적용된다. 예를들면, 검증도구 COSPAN이 사용되며, 소프트웨어 모델과 하드웨어 모델은 둘다, COSPAN의 입력 언어인 S/R로 프리-컴파일(pre-compile)된다. 축소된 모델은 동기 모델과 동일한 방법으로 COSPAN에 의해 점검된다.

도 1은 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템의 소프트웨어-중심도.

도 2는 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템의 하드웨어-중심도.

도 3은 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템의 특성이 대부분 하드웨어를 포함하거나, 대부분 소프트웨어를 포함하는 것을 설명한 도면.

도 4는 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템의 설계 검증 프로세스의 흐름도.

도 5는 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템에 대한 검증 프로세스의 더욱 상세한 흐름도.

도 6은 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템의 설계 검증을 수행하는 장치의 기능도.

* 도면의 주요부분에 대한 부호의 설명 *

10, 11, 12, 14, 15, 16 : 소프트웨어 프로세스(software process)

20, 21, 22 : 소프트웨어/하드웨어 인터페이스(software/hardware interface)

25, 26, 27 : 인터페이스 소자(interface elements)

30, 31, 32 : 하드웨어 소자(hardware elements)

35, 36, 37 : 하드웨어 서브시스템(hardware subsystem)

100 : 시스템(system)

110 : 소프트웨어 부분(software part)

120 : 하드웨어 부분(hardware part)

131, 132, 133, 134 : 폐곡선(closed curve)

상세한 설명

추상적 행동 설계 모델로부터 출발하는 설계 방법론은 상상할 수 있었다. 이 모델은 소프트웨어와 하드웨어를 구별하지 못할 수도 있다. 그렇다면, 문장론적으로(syntactically) 반영될 필요가 없으며, 구조적으로(architecturally) 증명할 필요도 없으며, 아마도 주해(annotation)로서만 나타난다. 그러한 단일화된 추상적 행동 모델은 형식적으로 검증될 수 있었고, 하드웨어 및 소프트웨어 소자들을 분리하기 위해 (검증가능한 방법으로) 형식적으로 세분될 수 있었다. 그러한 세분의 검증은 추상적 설계 모델에서 검증된 특성들이 하드웨어 실행모델과 소프트웨어 실행모델의 조합된 행동에 의해 도출되어, 그러한 세분에서 이들 특성들을 더 점검할 필요성을 갖게 되는 것을 보증한다.

그러한 접근방법의 이점은, 오늘날 합성가능한(synthesizable) 수준에서 수행되는 기능적 검증은 설계모델이 단순한 추상적 행동 수준에서 대신 수행될 수 있다는 것이다. 이는 검증 과정에도 도움이 되고, 그의 기능적 디버깅(debugging)을 단순화하고 가속화하는 데에도 도움이 되며, 설계 오류를 고치기 위해 변경될 필요가 있는 구조를 더욱 감소시킬 것이다. 이러한 더욱 용이한 설계개발의 단계에서, 검증은 예비 구조에서 논리적 결점을 발견함으로써 구조적 설계 전개를 지원하기 위해 사용될 수 있다. 또한, 설계 사이클에서 더욱 용이한 단계에서 디버깅을 지원하는 것은 전체 설계 개발의 공지된 촉진제이다. 반대로, 일단 합성가능한 모델은 완료되기만 하면, 종래의 설계 방법론은 통상 훨씬 늦은 단계로만 검사 및 기능적 디버깅을 한다. 그러므로, 성공적인 세분 설계 개발 방법론은 설계 공정을 가속화시키기도 하고 더욱 신뢰성있는 설계를 생산하기도 하는 것이다.

그러나 적어도 본 발명에 있어서, 하드웨어와 소프트웨어는 추상화의 상이한 레벨에서 비춰지며 설계의 개념적으로 상이한 관점을 포함하기 때문에, 각각의 응용예들에 만들어진 상이한 언어들로 그들을 나타내는 것은 당연한 것이다. 따라서, 하드웨어를 하드웨어-중심 형식 언어로 표현하고, 마찬가지로 소프트웨어를 소프트웨어-중심 형식 언어로 표현하고, 두가지 시스템 정의를, 두가지 언어를 수용하도록 적응된 검증도구에 적용할 수 있다. 그러나, 그러한 요구는 적절한 언어들을 채용하는 것이며, 그러한 소망은 수정할 필요 없이 기존의 검증도구들 중의 임의의하나를 채용하는 것이다.

하드웨어 설명 언어의 선택은 현재 용도에 의해 강하게 설명된다. 즉 그의 이점은 VHDL 또는 Verilog를 사용하는 것이다. 이러한 언어들은 그들의 용도에 있어서 형식적 설명 기술보다는 저 레벨 프로그래밍 언어에 더욱 가깝지만, 합성으로부터 그들에 부착된 강한 의미, 및 더욱 구조적인 구조물을 위한 감지된 지원이 그들을 적합한 형식 설명 언어로 만든다.

하드웨어와는 달리, 소프트웨어를 위한 형식 설명 언어를 광범위하게 수용되지 않는다. 소프트웨어 프로젝트의 크기가 그들의 관리를 점점 더 어렵게 만듦에 따라, 소프트웨어 개발에서 형식 언어와 형식 검증을 사용하는 가치는 더 잘 이해되어왔다. 일부 회사들은 그들 자신의 형식언어 및 도구를 설계하여 왔으며, 다른 언어가 국제적 표준에 의해 촉진되어왔다. ITU-T(공식적으로 CCITT)의 표준언어인 명세 및 기술 언어(SDL:Specification and Description Language)는 이 언어들의 가장 유망한 것 중의 하나이다. 그것은 ITU-T에 의해 정규적으로 업데이트되고 있으며, 이미 소프트웨어 프로젝트에서 일부 응용예들이 발견되었다. 그러므로, 본 발명의 첫 번째 출시품은 현재 정의된 바와 같은 SDL 언어를 사용할 것이지만, VHDL 또는 Verilog의 사용도 기술되지 않았고, SDL의 규정도 기술되지 않았으며, 여기에 설명된 원리와 맞는 배치의 성공적인 구체화를 위해서 필요함을 이해해야 한다.

일단 하드웨어/소프트웨어 설계가 검증되면, 시스템의 SDL 기술자는 소프트웨어의 개발단계에서 사용되는 형식 문서로서의 역할을 하며, VHDL은 하드웨어를합성하기 위해 사용될 수 있다. 형식 검증의 지원에 의해, 추상적 SDL 모델에 대해 세분사항이 점검되고, 그 다음에 COSPAN과 같은 일부 검증도구에 의해 발생되는 C 코드의 도움으로 자동적으로 합성된다. COSPAN은 문헌 [H. Hardin, Z. Har'El, 및 R.P. Kurshan, "COSPAN," Conference on Computer Aided Verification (CAV 96), LNCS 1102, Springer-Verlag, (1996) 423-427페이지]에 설명되어있다. COSPAN은 루센트 테크놀로지에 의해 허가된 것이며, COSPAN을 채용하는 장치는 캐던스 설계 시스템스 회사(Cadence Design System, Inc.)로부터 허가된 것이다.

SDL을 사용하는 것은 SDL로부터 S/R로 번역하기 위해 컴파일러가 존재한다는 또다른 이점을 가지고 있으며, S/R은 COSPAN의 원래 언어이다. 이 컴퓨터는 또한 루센트 테크놀로지로부터 허가될 수 있다.

VHDL로부터 S/R로 번역하는 번역기는 케던스 설계 시스템 회사로부터, FormalCheck^TM라는 도구의 부품으로서 입수할 수 있다.

하드웨어와 소프트웨어 사이의 인터페이스는 SDL에도 설명되어 있지만, 문맥을 약간 수정한 것은 문헌 [V. Levin, E. Bounimova, O Basbugoglu 및 K. Inan, in "A verifiable Software/Hadware Codesign Using SDL and COSPAN", Proceedings of the COST 247 Inter-national Workshop on Applied Formal Methods In System Design, Maribor, Slovenia, 1998, 6-16페이지]에 설명되어있다. 본질적으로, 그것은 인터페이스 프로세스에 의해 하드웨어 부분으로부터 (조합된) 신호들을 판독 및 기록할 수 있다. 소프트웨어 프로세스와 다른 인터페이스 프로세스의 인터페이스프로세스의 공동작용은 SDL 통신 메카니즘에 의해 완벽하게 취급된다. 즉, 버퍼를 통해서 신호 교환된다. 그러므로, 인터페이스 프로세스는 소프트웨어 부분의 관점으로부터 또다른 소프트웨어 프로세스인 것처럼 보인다. 인터페이스 프로세스는 하드웨어의 동기 방식으로 인터페이스 변수들(interface variable)라고 부르는 공용 변수를 사용한 하드웨어와 상호작용한다. 그러므로, 그것은 시스템의 하드웨어 부분에 또다른 하드웨어 모듈과 같이 나타난다. 공동설계 시스템의 하드웨어, 소프트웨어 및 접속부분은 S/R로 번역된다. 이것은 상이한 특성들을 갖는 상이한 부품들을 갖는, 전체 공동설계 시스템이 단일의 동기 시스템으로서 처리될 수 있도록 해준다.

본 발명자들은 공동설계 시스템에서 두가지 종류의 글로벌 트랜지션들(grobal transitions)을 구별한다. 단일 SDL 프로세스의 트랜지션은 소프트웨어 트랜지션이라고 부른다. 다른 종류의 글로벌 트랜지션은 하드웨어 트랜지션이다. 하드웨어는 동기 특성을 갖기 때문에, 하드웨어 트랜지션은 동기 하드웨어 소자에서 모든 하드웨어 모듈의 동시 트랜지션에 대응한다. 인터페이스 프로세스는 두가지 종류의 트랜지션을 모두 가질 수 있다. 인터페이스 변수가 참고되는 인터페이스 프로세스의 트랜지션은 하드웨어 트랜지션으로서 계수한다. 그렇지 않으면, 그것은 소프트웨어 트랜지션으로서 계산산한다. 서로 다른 추상화 레벨들이 하드웨어와 소프트웨어를 위해 사용될 수 있기 때문에, 우리는 소프트웨어와 하드웨어의 상대속도에 대한 가정은 하지 않는다.

위에 지시한 바와 같이, 하드웨어-중심 형식 언어로 하드웨어를 표현하고,마찬가지로 소프트웨어-중심 형식 언어로 소프트웨어를 표현하고, 두 가지 언어를 모두 수용하도록 적응된 검증도구에 두 가지 시스템 정의를 적용할 수 있었다. 그러나, 다룰 때 충분하지 않을 수 있는 것이 실제 설계이다. 순수한 하드웨어 또는 순수한 소프트웨어 시스템의 종래의 검증은 이미 복잡성을 다룸에 있어서 큰 문제점에 직면한다. 하드웨어 및 소프트웨어 시스템이 모두 함께 고려될 때 훨씬 더 큰 복잡성을 다룰 수 있도록 하기 위해서, 또다른 새로운 접근방법을 취한다. 특히, 검증될 소프트웨어/하드웨어 시스템은 검증될 필요가 있는 특성에 의해 표현되며, 검증될 특성들의 각각은 (주로 시스템의 소프트웨어 부분을 참작하는) 소프트웨어-중심 또는 (주로 시스템의 하드웨어 부분을 참작하는) 하드웨어-중심이 되는 것으로 식별된다. 그런 다음에, 특성의 검증은 그러한 식별에 따라 진행된다.

도1은 시스템의 소프트웨어-중심도를 묘사한 것이다. 이러한 견지에서, 소프트웨어 모듈들(10-13)은 다른 하나와 통신하는 프로세스이고, 이 프로세스들의 각각은 연관된 하드웨어 소자 또는 서브시스템과 어느 정도 상호작용한다. 이러한 상호작용은 소프트웨어/하드웨어 인터페이스를 통해서 수행된다. 그러므로, 도1에서, 소프트웨어 프로세스(10)는 소프트웨어/하드웨어 인터페이스(20)을 통해서 하드웨어 소자(30)와 인터페이스 접속하도록 도시되고, 소프트웨어 프로세스(11)는 소프트웨어/하드웨어 인터페이스(21)을 통해서 하드웨어 소자(31)와 접속하게 나타내고, 소프트웨어 프로세스(12)는 소프트웨어/하드웨어 인터페이스(22)을 통해서 하드웨어 소자(32)와 접속하게 나타내고, 소프트웨어 프로세스(13)는 소프트웨어/하드웨어 인터페이스(23)을 통해서 하드웨어 소자(32)와 접속하게 나타내었다. 원으로 나타낸 소프트웨어 시스템은 순수한 SDL 시스템을 형성하고, 모든 프로세스는 비동기로 조합한다. 하드웨어 소자와 함께 인터페이스 프로세스들은 이러한 SDL 시스템의 환경을 형성한다. 그러므로 환경의 개념은 SDL 시스템의 행동에 대한 제약조건들을 실행하는 조직화된 세계가 된다. 소프트웨어-중심 접근방법의 도움은 소프트웨어 특성들을 검증하는 것이기 때문에, 하드웨어 부분은 일반적으로 국지화 축소를 통한 추상화의 고 레벨로 자동적으로 축소될 수 있다. 이것은 여기에 참고로 기재된 문헌 [R.P.Kurshan in "Computer-Aided Verification of Coordinating Processes: The Automata-Theoretic Approach," Princeton Univ. Press]에 설명되어있다. 하드웨어 부분의 역할은 그의 검증을 지원하여, 소프트웨어 부분을 적절하게 제약하는 것이다.

도2는 시스템의 하드웨어-중심도를 묘사한 것이다. 이러한 관점에서, 하드웨어 소자들과 서브시스템들은 서로 상호접속되어 있으며, 그 소자들 또는 시스템들 각각은 소프트웨어 모듈과 통신한다. 이러한 통신은 하드웨어/소프트웨어 인터페이스를 통해서 수행된다. 그러므로, 도2에서, 하드웨어 서브시스템(34)은 인터페이스 소자(24)를 통해서 소프트웨어 프로세스(14)와 통신하고, 하드웨어 서브시스템(36)은 인터페이스 소자(26)를 통해서 소프트웨어 프로세스(16)와 통신하고, 하드웨어 서브시스템(37)은 인터페이스 소자(27)를 통해서 소프트웨어 프로세스(17)와 통신한다. SDL 시스템으로서 표현된 각 프로세스는 하나의 인터페이스 프로세스만을 갖는다. 이중 소프트웨어-중심도와는 달리, 하드웨어-중심도에서는 동일한 서브시스템의 부품인 하드웨어 모듈만이 한 번에 고려된다. 즉, 소프트웨어를 통해서, 간접적으로만 서로에게 연결된 2개 이상의 상이한 하드웨어 시스템을 포함하는 배치에서, 검증 문제는 2가지 이상의 독립된 검증 문제를 포함하여 처리된다. 그러므로 도2의 점선으로 표시된 박스(200) 안에서, 모든 모듈은 동기로 조합한다. 더 큰 시스템에서 다른 하드웨어 소자가 있다면, 그들은 각 하드웨어-중심 모델에서 처리되어야 한다. 순수한 SDL 시스템과 함께 인터페이스 프로세스는 하드웨어 부품의 환경을 형성하고, 하드웨어의 1차 입력에 대해 제약조건을 수립한다.

완전한 시스템은 하드웨어-중심 또는 소프트웨어-중심으로서 항상 간단히 묘사될 수 있는 것은 아니라는 것을 알아야 한다. 그러므로, 여기 설명된 원리 중의 하나에 따라, 검증될 시스템은 그 시스템을 특징화하는 특성들의 세트의 각각에 대해 별도로 처리된다. 이러한 이론은 그의 원하는 특성 모두에 대해 시스템이 적당히 검증할 때, 의도한대로 작동할 것이라는 것이다.

도3은 매우 복잡한 방법으로 상호작용하는 소프트웨어 및 하드웨어 소자들을 갖는 시스템(100)을 설명한다. 또한, 이 시스템은 소프트웨어 부분(110) 및 하드웨어 부분(120)을 포함하는 것을 알 수 있다. 위에 지적한 바와 같이, 검증될 특정의 특성에 대해 그 시스템의 일부는 부적합함을 정할 수도 있다. 이것은 폐곡선의 내부 영역과 외부 영역에 의해 도3에 설명되어있다. 폐곡선(131)의 내부영역은 관심대상의 특정 특성에 포함된 시스템 소자들을 포함하고, 폐곡선(131) 외부 영역은 참여하지 않은 시스템 소자에 대응하므로, 특정 특성을 검증하는 프로세스에서 고려될 필요가 없다. 폐곡선(131)으로 표시된 관심대상의 특정 특성은 대부분 그 시스템의 소프트웨어 소자, 즉 프로세스를 포함하며, 그 시스템의 하드웨어 소자, 즉소자 또는 서브시스템은 아주 조금만 포함한다. 그러므로, 유리하게는 이 특정 특성은 소프트웨어-중심으로 고려되는 것이 최상이다. 예를들면 검사될 필요가 있는 도3 시스템의 또다른 특성은 폐곡선(132) 내에 시스템 소자에 의해 둘러 싸여있고, 그 특성은 대부분 하드웨어를 포함한다. 그러므로, 이러한 특성은 하드웨어-중심이 되는 것으로 고려되는 것이 최상일 수 있다.

다른 가능성을 설명하기 위해서, 폐곡선(133 및 134)은 공통으로 일부 소프트웨어 프로세스를 갖는 두가지 소프트웨어-중심 특성들을 보여준다. 이들은 하드웨어 인터페이스의 일부를 공유한다.

요약하기 위해, 본 명세서에 따르면, 시스템의 검증은 검증될 특성들의 집합에 의해 한정된다. 각 특성은 소프트웨어-중심 언어로 표현된 소프트웨어 프로세스를 조합하는 것과, 하드웨어-중심 언어로 표현된 하드웨어 소자를 상호작용하는 것을 포함한다. 각 특성은 각각 검증된다. 각 특성의 검증은 검사된 특성의 작용에 참여하는 시스템 소자만을 포함하며, 이것은 검증 복잡성을 감소시킨다 (즉 계산상의 부담을 감소시킨다).

이것은 도4의 흐름도에 설명되어 있는데, 도4에서 검증될 시스템의 특성이 블록(201)에서 식별되면, 검증될 특성은 블록(202)에서 선택되고, 그 특성에 관여하는 시스템 소자들은 블록(203)에서 식별된다. 그 특성이 검증되는 블록(204)으로 프로세스가 계속되고, 검증이 확정적이면, 제어는 블록(202)으로 복귀하여 다른 특성을 검증한다. 그렇지 않으면, 제어는 블록(203)에서 사용된 가정의 일부 또는 설계가 수정되는 블록(205)으로 통과하여, 또다른 검증 시도를 위해 블록(204)으로제어를 복귀시킨다. 블록(204)의 작동에 대해 더 상세히 설명하면, 특성들은 소프트웨어-중심 또는 하드웨어-중심으로서 식별된다. 예를들면, 이것은 식별하고 소프트웨어-중심 또는 하드웨어-중심으로 특성을 명시하는 사용자에 의해 이루어진다. 그러나, 특성이 소프트웨어-중심 또는 하드웨어-중심인지에 무관하게, 한 특성이 소프트웨어 부분과 하드웨어 부분을 둘다 가질 예측은 두가지 도전을 제시한다. 하나는 우리가 설계의 기호 검증을 사용하기 원한다는 것이고, 다른 하나는 소프트웨어를 검증하는 것이 실질적인 계산상의 문제를 제시한다는 것이다.

이러한 도전들은 수정된 정적 부분 순서 축소 알고리즘을 사용하여, 소프트웨어에 의해 표시된 그래프를 축소시키고, 동기 모델로 소프트웨어를 컴파일하고, 하드웨어 부분과 소프트웨어 부분의 표현을 공통언어 표현으로 조합하고, 조합된 표현을 기호 검증에 적용함으로써 설명된다.

한가지 특성의 소프트웨어 부분에 대해 정적 부분 순서 축소를 수행하는 동안, 소프트웨어 부분과 하드웨어 부분 사이의 접속에서 시스템의 행동에 대한 어떤 가정을 하는 것이 도움이 된다. 왜냐하면, 그러한 가정은 계산상 복잡성과 필요한 계산의 부피를 축소시키기 때문이다. 예를들면, 소프트웨어 모듈로의 특정 입력이 어떤 선택된 상태에서 작동하지 않는다고 가정하면, 코드 포함된 모듈의 실질적인 부분을 부적절하게 만든다. 이러한 가정을 하는 것은 하드웨어가 소프트웨어에 신호를 공급하는 어느 지점에서 그 시스템에서 연결을 단절시키고, 대신에 외부 신호를 공급하는 것과 같다. 물론, 이것은 하드웨어에 영향을 미치는, 특히 특정 입력에 적용된 신호를 정상적으로 발생하는 하드웨어 부분에 영향을 미치는 소프트웨어에 의해 어떤 행동을 가져올 수 있다. 그러므로, 검증 프로세스의 부분은 하드웨어가 특정 입력에서 선택된 상태를 만들 것이라는 검증을 요구한다. 이러한 검증이 실패하면, 사용자는 두가지 선택에 직면하다. 즉 가정된 입력 조건을 위해 검증하도록 설계를 수정하거나, 입력에 대한 더 약한 가정이 수용될지 여부를 평가한다. 후자가 선택되면, 더 약한 가정이 이루어지고 검증이 반복된다. 그러므로, 공동설계가 안정화되기 전에 작은 검증 반복이 필요할 수 있다.

상태 달성가능성의 경로에서 동적으로 감소되는 것을 구현하는 부분 순서 축소 기술의 종래의 구체예와는 달리, 수정된 실현에 필요한 것은 동료 하드웨어 부분의 동기 성질과 호환되는 알고리즘, 및 기호적으로 달성가능성 분석을 적용할 수 있는 알고리즘이다. 이러한 요구는 기호 탐색과 호환되는 방법으로 (컴파일 시간 동안) 정적으로 부분 순서 축소를 구현하는 방법을 요구한다.

부분 순서 축소가 축소되지 않은 시스템의 트랜지션 관계에 대한 제약으로서 보여질 수 있다고 출발하면, 자동조작-이론 근거에 기초를 이루는 COSPAN과 호환할 수 있는, 그러한 제약조건이 자동적으로 동기로 표시될 수 있다는 것이 밝혀졌다. 또한, COSPAN은 수용하지 못한 나머지의 탐구를 방해하는 방법으로 안전 제약조건을 효율적으로 실행한다. 또한, COSPAN의 중심 알고리즘이 상기 설명된 사이클-닫음 조건을 실행하기 위해 논쟁될 필요가 있다고 먼저 상상하더라도, 그것은 명백히 이것을 피하는 방법이 발견되는 큰 이점의 것이다. 대신에, 사이클-닫음 조건은 정적으로 한정된 제약조건 자동조작으로 실행된다.

짝이 되는 하드웨어 부분들의 동기 성질과 혼화될 수 있는 SDL 명세를 만들기 위해서, 부분 순서 축소로부터 돌출된 SDL 명세는 동일한 동기 명세로 변형된다. 이것은 비동기를 시뮬레이션하기 위한 미결정을 사용하여 수행된다. 이것은 여기에 참고로 기재한 문헌 [R.P. Kurshan, M, Merritt, A. Orda, 및 S. Sachs in "Modeling Asynchrony with a Synchronous Model,"Conference on Computer Aided Verification (CAV 95), LNCS 939, Springer-Verlag, (1995) 339-352페이지]에 기재되어있다. 동기 형식으로 변환 및 정적 부분 축소는 컴파일러 안에 포함되며, 이미 설명한 바와 같이 이 컴파일러는 루센트 테크놀로지사로부터 허가될 수 있다.

하드웨어-중심 검증은 공동설계의 하드웨어측에 주로 관련되는 특성들을 점검하기 위해 사용된다. 그러한 성질을 연결함에 있어서, 도2에 도시된 시스템의 하드웨어-중심도에서 소프트웨어 모듈은 그 하드웨어를 통해서만 조합할 수 있는 별개의 SDL 시스템에 대응한다. 소프트웨어-중심 시스템을 가지고는, 부분 순서 축소에 이어 국지화 축소를 적용할 수 있다. 그러나, 소프트웨어측이 하드웨어-중심 검증에서 수반된 것이 거의 없다면, 국지화 축소는 만족시킬 수 있으며, 부분 순서 알고리즘에 이어 국지화 축소 알고리즘을 가동시키는 것보다 더 빠를 수 있다.

도5는 도4의 흐름도를 확대한 흐름도이다. 블록(401)을 실행하기 전에, 검증될 시스템의 소프트웨어 부분에 대해 예를들면 SDL 언어로 명세를 얻고, 검증될 시스템의 하드웨어 부분에 대해, 예를들면 VHDL 언어로 하드웨어 명세를 얻고, 검증될 특성들의 세트는 하드웨어-중심 또는 소프트웨어-중심으로서 그들의 특징화와 함께 얻고, 그 시스템의 초기 제약조건을 형성하는 그 시스템의 행동에 대한 가정이 제공된다. 특성들의 각각에 참여한 시스템 소자들은 이들 명세의 부분으로서 포함된다. 블록(401)은 검증될 특성을 선택하고, 그 특성에 참여한 시스템 소자를 식별하고, 검증될 특성에 합당한 시스템의 행동에 대한 가정을 검색하는 블록(402)으로 제어를 보낸다. 그런 다음에 제어는 검사될 특성이 하드웨어-중심인지 소프트웨어-중심인지를 결정하는 결정 블록(404)으로 보낸다. 블록(404)의 결정에 기초해서, 제어는 블록(405) 또는 블록(406)으로 보낸다. 검증될 특성이 하드웨어-중심이면, 블록(405)은 이 특성의 소프트웨어 부분이 부분 순서 축소를 수행하는 장점에 충분히 큰지를 결정한다. 그러한 경우이면, 제어는 블록(406)으로 통과한다. 그렇지 않으면 제어는 블록(407)으로 통과한다. 블록(406)은 검사된 특성에 합당한 제약조건을 사용하며, 정적 부분 순서 축소를 수행하고, 생성되는 상태-공백 그래프를 동기 형식으로 변환시키고, 그것을, 하드웨어 부분과 함께, 동기 시스템과 호환될 수 있는 어떤 선택된 언어로 컴파일한다. 예를들면, 이것은 검증도구(COSPAN)의 본래 언어인 S/R일 수 있다. 블록(407)은, 소프트웨어 부분에 대한 부분 순서 축소를 수행하지 않는 것을 제외하고는 동일하다. 블록(406 및 407)의 결과는 검사된 특성에 합당한 제약조건을 사용하는 국지화 축소를 수행하는 블록(408)에 적용되고, 그런 다음에 검증을 수행하는 블록(409)에 적용된다. 그 검증 결과는 그 검증이 성공적이었는지 그렇지 않은지를 결정블록(410)에 적용한다. 검증이 성공적이 아니면, 검증 프로세스의 제어에 있는 사용자에게 정보가 제공된다(블록 411). 그 사용자는 또다른 검증을 시도할지를 결정한다. 그러한 경우에, 그 사용자는 설계를 가정(일반적으로 그들을 약화시킴)하거나 도전하며, 블록(404)으로 제어를 복귀시킨다. 한가지 특성이 검증되면, 특성들이 검증될 필요를 가지는지를 평가하는블록(403)으로 제어가 통과하고, 또 그렇다면 블록(401)로 제어가 복귀한다. 그렇지 않으면, 처리는 종료된다.

도6은 소프트웨어/하드웨어 설계를 검증하기 위한 하드웨어 배치의 기능도를 도시한 것이다. 선(501)은, 소자(301)에 저장된, VHDL과 같은 하드웨어-중심 언어로, 검증될 시스템의 하드웨어 부분의 명세를 제공한다. 선(502)는 소자(302)에 저장된, SDL과 같은 소프트웨어-중심 언어로, 검증될 시스템의 소프트웨어 부분의 명세를 제공한다. 제어기(304)는 선(503) 위의 사용자 입력에 응답하고, 이들 입력의 일부는, 그 시스템의 다양한 특성들에 비해, 검증될 시스템의 행동에 대한 가정 또는 제약조건이다. 검증될 특정 특성을 선택하며, 제어기(304)는 소자(302)로부터 합당한 SDL 명세를 검색하고, 소자(301)로부터 합당한 VHDL 명세, 및 제약조건을 검색하고, 소자(303)에게 그들을 적용시킨다. 소자(303)는 상기 설명된 블록(406 및 407)의 기능을 수행하고, 국지화 축소를 수행하는 소자(305)에게 생성되는 명세를 보내고, 그의 출력을 소자(306)에 제공하는데, 소자(306)은 형식 검증도구이다. 검증도구가 COSPAN이면, 소자(303)는 S/R로 출력을 생산하는 것이 바람직하며, 소자(305 및 306)은 조합된다( COSPAN은 국지화 축소를 포함하기 때문이다).

소자(306)는 제출된 명세의 검증을 수행하고, 설계가 검증되는지를 확인하거나, 실패를 나타내고 상황을 식별하는 출력을 제공하거나, 특성이 실패해서 정확하게 작동되면서 검증될 수 없는 조건을 제공한다. 이 출력은 VCD와 같은 표준화된 포맷으로 제공되는 것이 유리하며, 검증후 사용자 제시 도구(307)에 적용된다. 예를들면, 도구(307)는 루센트 테크놀로지사로부터 입수할 수 있는 ODAN 모듈이다.

물론, 숙련된 기술자는 도6의 다양한 처리 소자들에 의해 수행된 기능들이 부수적인 메모리와 제어 소자들과 함께 적합한 단일의 처리기에서 실행될 수 있다는 것을 수용할 것이다.

정적 부분 순서 축소

부분 순서 축소 기술에 대한 광범위한 문헌이 있다. 예를들면, 문헌 [P. Godefroid, and P. Wolper, "A Partial Approach to Model Checking,: 6th Annual IEEE Symposium Logic in Computer Science, 1991, Amsterdam, 408-415페이지; D. Peled, "Combining Partial Order Reductions with On-the-fly Model-Checking," Formal Methods in System Design U(1996), 39-64페이지; 및 A. Valmaui, "Stubborn sets for reduced state space generation," 10th International Conference on Application and Theory of Petri Nets, Bonn, Germany, LNCS 483, Springer-Verlag, (1989) 491-515 페이지]을 참조. 일반적으로, 부분 순서 축소는 삽입된 사건의 문맥과의 조화의 모델에서 관찰을 이용한다. 동시발생 사건은 가능한 모든 순서로 사건을 실행함으로써 모델화된다. 그러한 축소는 그러한 시스템을 위한 특성들이 서로 다른 순서들 사이를 구별할 수 없어서, 원래 시스템의 트랜지션 및 상태의 서브세트만을 함유하는 검사된 시스템의 표현을 생성한다는 사실을 알아냈다. 이러한 표현은 축소되지 않은 모델의 지수이며, 그 특성에 관한 축소되지 않은 모델과 동일한 것이다. 축소된 상태 그래프에서의 경로인 지수에서 행동의 서브세트는 점검된 특성을 보존하는 것만을 요구한다. 즉, 모델-점검 알고리즘이 축소된 상태 그래프에 적용되면, 그 특성이 보유할 때에 긍정적인 대답을 하게 되고, 보유하지 않을 때는 반대가 된다. 상기 언급된 문헌에서 Peled에 의해 제시된 접근방법은 예를들면 앰플 세트 방법을 사용한다. 이 방법에서는, 그 모델 시스템의 각 상태를 위해, 다음에 실행될 수 있거나 허용되는 (원자) 트랜지션의 세트가 있다. 이들은 "허용된"이라고 표시한다. 단순한 모델-점검 알고리즘은 일반적으로 깊이 우선 탐색 또는 너비 우선 탐색을 수행함으로써 검사하에 프로그램의 상태 그래프를 구축한다. 그러한 탐색은, 허용된 트랜지션을 적용함으로써 발생된 그의 바로 아래 계승자를 조사하기 위해 초기 상태 및 진행과 함께 시작하며, 그 다음에 다시 그들의 계승자를 조사하고, 이런 식으로 한다. 상이한 탐색 전략은 계승자들이 탐색된 순서에 의해 서로 다양하다. 주어진 상태(s)로부터, 부분 순서 축소는 허용된 트랜지션의 서브세트, 즉 세트 앰플(s)만을 조사한다. 그러한 앰플 세트는 생기는 지수에서 점검된 특성의 보존을 보장하는 일부 조건을 강제하도록 선택된다.

모든 상태는 점검된 특성의 형성에서 나타난 원자 제안의 일부 서브세트에 의해 표시되고, L(s)은 s안에 보유하는 제안 세트를 표시한다고 가정한다.

앰플(s)을 선택하기 위해 본 발명자들이 사용한 조건을 제시하기 전에, 두 개 이상의 개념이 정의된다. 실행의 순서에 무관하게, 하나를 실행하고 이어서 임의의 상태(s)에서 나머지 하나를 출발하는 것이 동일한 후속 상태(s')를 가져온다면, 첫 번째 개념은 트랜지션의 쌍은 독립적이라고 말한다는 것이다. 또한, 그들의 중의 하나가 먼저 허용되면, 두 번째를 실행한 후, 첫 번째 하나는 허용된 채로 남아있는다. 두 번째 개념은 보이지 않는 트랜지션의 것이다. 실행될 때, 상태 라벨링을 변경하지 않을 경우에 트랜지션은 보이지 않는다. 즉, 상태(s)와 상태(s')의 쌍의 각각에 대해, 보이지 않는 트랜지션이 s로부터 실행되어 s'를 생성한다면, 그 라벨은 동일하게 남아있다. 즉, L(s) = L(s').

이제 주어진 성질을 보존하기 위한 생성되는 부분 순서 축소에 대한 앰플(s) 세트에 대해 충분한 조건들이 주어질 수 있다. 이러한 조건의 설명 및, 그들이 주어진 특성을 보존하는 축소된 상태 그래프를 보장한다는 증거는 상기 언급된 Peled 연구에서 출현한다.

상태(s)는 앰플 = 허용된 것일 때, 즉, 모든 트랜지션이 선택될 때 완전히 확장된다고 말한다.

· C0 [비공백 조건] 앰플(s)은 허용된(s)이 공백일 경우에만 공백이다.

· C1 [앰플 분해] 상태(s)로부터 출발하는, 시스템의 모든 행동의 경우에, 앰플(s)에서 어떤 트랜지션에 의존하는 트랜지션은, 앰플(s)로부터 트랜지션되기 전에는 (축소되지 않은 모델에서) 절대로 나타나지 않는다.

· C2 [비가시성 조건] s가 완전히 확장되지 않으면, 그 안의 트랜지션은 아무것도 보이지 않는다.

·C3 [사이클 닫음 조건] 축소된 상태 그래프의 각 사이클을 따라 적어도 하나의 상태는 완전히 확장된다.

이러한 조건들을 구현하기 위한 제1 모델-점검 시스템은 SPIN인데, 이것은 문헌 [G. J. Holtzmann, 및 D. Peled, in "An Improvement in Formal Verification," 7th International Conference on Formal Description Techniques,Berne, Switzerland, 1994, 177-194페이지]에 기재되어있다. 이러한 조건을 보장하기 위해서는, SPIN의 탐색 메카니즘이 변경되었고 축소를 위해 특수화되었다. 조건 C0 및 C2는 점검하기 평범하다. C0은 로칼 문장 점검이고, C2는 설계에 대해 문장론적으로 부여된 법칙을 관찰함으로써 보장된다. 조건 C1은 현재상태(s)에서 허용된 트랜지션에 대한 점검 세트로 번역가능하다. 예를들면, 어떤 프로세스가 메시지 교환 또는 글로벌 변수들을 포함하지 않는 로칼 트랜지션만을 그의 현재 프로그램 계수기로부터 실행할 수 있다면, 그의 트랜지션 세트는 조건 C1을 만족시키도록 보장된다. 조건 C3은 선택된 앰플 세트가 사이클을 닫았는지 여부를 점검함으로써 취급된다(깊이 우선 탐색에서, 탐색 스택에 이미 있는 상태가 도달했을 때 이것이 발생한다). 그렇다면, 현재 선택된 앰플은 또다른 선택에 의해 버려진다.

SDL로부터 S/R로 번역하는 컴파일러를 만들 때, 이미 설명한 바와 같은, 부분 순서 축소를 사용하는 것이 바람직하지만, 몇 가지 목적은 SPIN에서 사용된 것과 상이한 해답을 묘사한다. 가장 특히, 기호 상태 공백 탐색을 사용할 수 있기 위해서, 깊이 우선 탐색의 사용에 의존하지 않는 축소 알고리즘을 사용하는 것이 바람직하다. 다음에 설명된 축소는, 모델-점검 알고리즘의 어떠한 수정도 없이, 동기 모델들을 위한 임의의 모델-점검 알고리즘과 함께 사용될 수 있다는 이점이 추가되었다. 또한, 이 새로운 부분 순서 축소 알고리즘은 매우 일반적이며, 사용된 상태 공백 탐색의 모드로 민감하지 않다.

너비 우선 탐색과 관련해 축소를 구현하는 데에 주요 장애는 상태가 완전히 확장된 것이 없는 사이클의 가능성을 피할 필요가 있다는 것이다. 제1블러시(blush)에서, 조건 C3은 너비 우선 탐색과 관련해 이것을 달성하기 위해 모델-점검 알고리즘으로의 실제 변화가 필요할 것임을 제안한다. 사실, 본 발명자들은, 이것은 모델-점검 알고리즘에 대한 수정없이, 매우 단순하고 일반적으로 달성될 수 있음을 밝혀내었다.

원칙적으로, 알고리즘은 상기 언급된 문헌에서 Holtzmann과 Peled, 또는 상기 언급된 LNCS 1254 공개물에서 Alur 등에 의해 설명된 것처럼 최소한 좋은 축소 (달성된 상태에 의해 측정됨)를 생성할 수 있어야 하지만, 기호 분석을 사용하여, 달성된 상태의 수는 나쁜 복잡성 척도이다. 또한, 일반적으로 교차 알고리즘을 비교하기 어려운, 축소의 크기와 그 축소를 생성하는 비용 사이에 균형이 있다.

수정된 부분 순서 축소 알고리즘에 따라, C3 조건은 C3'로 교체된다.

· C3' : 축소된 상태 공백에 있는 각 사이클은 트랜지션(T)으로부터 적어도 하나를 포함하도록 T의 세트가 있다. 앰플(s)이 T로부터의 트랜지션을 포함한다면, s는 완전히 확장된다.

트랜지션(T)의 세트는, 모든 다른 허용된 트랜지션들에 붙기 때문에 그러한 의미에서 고정 트랜지션(sticky transion)이라고 부를 수 있다.

그러한 세트(T)를 발견하기 위한 쉬운 방법은 점검된 시스템의 각 프로세스의 정적 제어 흐름 그래프를 쳐다보는 것이다. 글로벌 상태의 임의의 사이클은 각 성분 프로세스에서 사이클(또는 가능하게는 자기-루프)로 계획한다. 각 로칼 사이클을 단절시킴으로써, 각 글로벌 사이클은 단절되도록 보장된다. 이것은 상기 조건 (C3')를 보장하는 것을 더욱 강화시키도록 제안한다; 즉,

· C3' : 모델화된 시스템의 프로세스의 정적 제어 흐름에서 각 사이클은 적어도 하나의 고정 트랜지션을 포함하며, 앰플(s)이 고정 트랜지션을 포함하면, s는 완전히 확장된다.

조건 C3"은, 각 성분 프로세스로부터 글로벌 상태 공백으로 상승된, 고정 트랜지션(T)의 세트를 발견하기 위해, (작은) 성분 프로세스들에 대한 정적 분석 알고리즘을 사용함으로써 만족될 수 있다. 최소 고정 세트가 NI라는 것을 발견하는 것은 어렵지만, (정적 제어 흐름 그래프에 있는 사이클이 없을 때까지 고정 트랜지션을 제거하는 것과 같다), 그것이 NP라는 것은 훨씬 더 큰 글로벌 상태 그래프가 아닌 작은 로칼 제어 흐름 그래프(즉 각 프로세스)의 크기에서 어렵다. 또한, 최소치(T)를 발견할 필요는 없다. 로칼 제어 그래프에서 고정 트랜지션의 세트를 발견하는 한가지 방법은 깊이 우선 탐색의 경로에서의 모든 백-에지(back-edge), 즉 현재 탐색된 상태로부터 현재 탐색 스택에서의 한 상태까지의 에지를 선택하는 것이다. 생성되는 T는 각 로칼 백-에지의 상승이다. 로칼 제어 그래프는 작기 때문에, 그들은 컴파일 시간에 많은 비용없이 탐색될 수 있다. (임의의 문장론적(syntactic) 트랜지션은 로칼 제어 그래프에서 에지가 된다고 가정한다. 이것은 많은 불만족스러운 트랜지션을 갖는 프로세스에 의해 좌절될 수 있지만, 이것은 보통 그러한 경우는 아니며, 프르세스는 작을 뿐만 아니라 여분의 트랜지션 세트를 가짐으로써 계획된다.

우선권은 고정(sticky)이 아닌 트랜지션으로 주어진다는 것을 주지해야 한다. 적어도 하나의 고정 트랜지션을 통과하지 않고 닫힐 수 있는 사이클은 없지만,고정 트랜지션은 연기될 수 있다. 글로벌 사이클은, 상이한 프로세스들로부터 상승된 고정 트랜지션 때문에, 하나 이상의 완전히 확장된 상태를 포함할 수 있다는 것이 가능하다. 그러나, 고정 트랜지션은 낮은 우선권을 갖기 때문에, 또 축소 알고리즘은 다른 트랜지션을 먼저 선택하려고 하기 때문에, 그들이 모두 동일한 상태로부터 취해질 수 있는 지점으로 그들의 몇 개를 연기할만한 가치가 있을 수 있다. 이것은 고정 트랜지션의 확장이 사이클을 따라 어느 곳에서나 발생할 수 있기 때문에 가능하다.

사실, 하나는 다음과 같이 약화된 조건(C3)일 수 있다. 모든 메시지는 점차적으로 공백되고 메시지를 전송하는 것("전송" 사건)은 사이클을 닫을 것을 필요로 하기 때문에, 축소된 상태 그래프에서 한 사이클은, 메시지를 수신하는 것만으로 이루어져 있다. 따라서, 메시지 수신만을 갖는 로칼 제어 흐름 사이클은 고정 트랜지션을 포함할 필요가 없으며, 그것은 글로벌 상태 그래프에서 하나의 사이클로부터 계획된 또다른 사이클의 일부이어야 한다. (메시지 전송에 대해서 이것이 사실일지라도, 대기행렬은 점차적으로 채워질 것이다. 메시지를 전송 및 수신하는 것과 동시에 동일한 이완이 허용된다면, 그들은 다른 하나의 효과를 삭제하고 글로벌 상태 그래프 사이클의 일부일 수 있다) 이러한 관찰은 각 프로세스의 제어 그래프의 크기에서 선형인 알고리즘을 설계하기 위해 사용될 수 있다. 프로세스의 제어 그래프로부터 수신하는 트랜지션을 제거한 후, 임의의 백-에지를 식별하기 위해 나머지 트랜지션에 대해 선형 시간 탐색이 수행될 수 있으며, 그들을 고정 트랜지션으로서 표시할 수 있다.

조건 C3을 더욱 이완하는 많은 방법이 있다. 하나는 고정 트랜지션을 더 표시함에 있어서 어느범위 까지 사용자를 포함하는 것이다. 이것은 위에 설명한 바와 같이, 모은 백-에지를 선택함으로써 발생될 더 많은 임의의 할당을 축소한다. 또다른 방법은 적은 프로세스를 조합한 후 백-에지 분석을 수행하는 것이다. 이것은 더 큰 구조의 사이클만이 단절될 필요가 있다.

COSPAN에서 탐색 제어에 무관한 부분 순서 축소를 달성하기 위해, S/R의 선택 메커니즘이 계획된다. 이 메커니즘은 선택 변수들을 사용하는 것으로 구성된다. 이들 변수는 조합될 수 있고, 그 상태의 부분이 아니므로, 임의의 메모리를 발생시키지 않는다. 계승자 상태에 대해 결정할 때, 각 프로세스는 그의 선택 변수의 가능한 값들 사이에서 미결정적으로 선택한다. 임의의 프로세스의 선택은 다른 프로세스의 선택에 의존할 수 있다(이러한 관계가 1-사이클일 때). 특히 앰플(s)의 크기는 가능한 한 작은 앰플(s) 세트로, 즉, 가장 적은 수의 허용 트랜지션으로 프로세스를 선택함으로써 최적화될 수 있다.

프로세스의 각 로칼 상태에서, 현재 허용된 트랜지션이 조건 C1을 만족시키는지 여부를 결정한다. 그렇다면, 이 상태에서 프로세스가 앰플인 것이 결론지어진다. 이것을 결정하는 한가지 방법은 다음과 같다. 허용된 고정 트랜지션을 갖지 않는다면, 또 모든 그의 허용된 트랜지션이 수신 또는 내부 트랜지션이면 한 상태에서 프로세스가 앰플인 것으로 간주된다. 그 프로세스가 내부 트랜지션만을 가진다면(로칼 변수만이 언급되는 트랜지션), 그것은 프로세스의 허용된 트랜지션이 C1을 만족한다는 것이 명백하다. 왜냐하면, 이러한 변수들을 언급할 수 있는 다른 프로세스는 없기 때문이다. 마찬가지로, 그 프로세스가 수신 트랜지션만을 가질 경우, 그 프로세스의 허용된 트랜지션은 다시 C1을 만족한다. 또다른 프로세스의 전송 트랜지션은 수신 트랜지션이 판독한 동일한 메시지 큐를 변경시킬 수 있지만, 그들의 실행 순서는 중요하지 않다. 그 문제는 몇가지 프로세스가 잠재적으로 앰플 세트인 허용된 트랜지션을 가질 수 있다는 것이다. 이들 모든 세트를 선택하는 것은 선택된 트랜지션을 최소화하는 목적의 계수기가 될 것이다. 실제로, 선택 메커니즘은 이것을 해결하기 위해 사용될 수 있다. 프로세스가 앰플이면, 그것은 이 사실에 대해 다른 프로세스들을 알리기 위한 글로벌 선택 변수들을 사용할 수 있다. 몇가지 프로세스들이 동시에 앰플이라면, 그들은 정적(인덱스 번호) 우선권을 통해서 그들 중의 하나를 선택한다. 다른 앰플 프로세스는 그들이 앰플 세트를 제공하기 위한 선택된 후보자가 아니라는 것과, 이 세트에 트랜지션을 기여하지 않는다는 것을 전달받는다.

본 발명의 정신과 범위로부터 벗어나지 않고, 본 발명의 원리를 설명하는 상기 설명과, 다양한 수정 및 변경이 서로 다른 구체예에서 포함될 수 있으며, 이것은 다음의 청구범위에서 한정된다는 것을 이해해야 한다.

본 발명의 하드웨어 및 소프트웨어 설계의 검증 방법 및 장치에 의해, 하드웨어/소프트웨어 공동설계에서 하드웨어 및 소프트웨어를 분리해서 설계하지 않고, 조화시킬 수 있다. 특히 하드웨어(또는 소프트웨어)가 소프트웨어(또는 하드웨어)의 행동을 제어하면서, 하드웨어와 소프트웨어가 광범위하게 상호 작용하는 상황에서 매우 유용하다. 본 발명의 검증 방법 및 장치에 의해, 하드웨어/소프트웨어 공동설계에서 발생하기 쉬운 논리적 오류를 제거함으로써, 생산성을 높이고 비용절감 효과를 가져온다.

Claims (27)

1. 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템의 설계를 검증하기 위한 방법에 있어서,

   소프트웨어-중심 언어로 되어있는 소프트웨어 부분의 제1 명세(specification)의 입력을 수용하는 단계와;

   상기 제1 명세의 크기를 축소시키기 위해 부분 순서 축소(partial order reduction)를 수행하는 단계와;

   상기 제1 명세를 동기 형식으로 변환시키는 단계와;

   하드웨어-중심 언어로 되어있는 하드웨어 부분의 제2 명세의 입력을 수용하는 단계와;

   상기 축소된 제1 명세와 상기 변환된 제1 명세에 의해 표현된 설계를 검증하는 단계와;

   상기 검증 단계의 결과를 제시하는 단계를 포함하는, 시스템 설계 검증 방법.
2. 제 1 항에 있어서, 상기 검증하는 단계는,

   검증도구가 상기 소프트웨어-중심 언어로 표현된 입력들에 대해 작동할 수 없으면, 상기 변환된 제1 명세를 상기 검증도구의 명세 언어로 번역하는 단계와;

   상기 검증도구가 상기 하드웨어-중심 언어로 제시된 입력들에 대해 작동할수 없으면, 상기 제2 명세를 상기 검증도구의 명세 언어로 번역하는 단계를 포함하는, 시스템 설계 검증 방법.
3. 제 1 항에 있어서, 상기 부분 순서 축소는 정적(static) 부분 순서 축소인, 시스템 설계 검증 방법.
4. 제 1 항에 있어서, 상기 결과들을 제시하는 단계는, 설계가 기대했던 대로 작동할 것임을 지적하는 확인 출력을 제시하는 단계, 또는 특정 세트(set)의 상황 하에 기대했던 대로 작동하도록 상기 시스템의 오류를 나타내는 반대의 예를 제시하는 단계를 포함하는, 시스템 설계 검증 방법.
5. 제 1 항에 있어서, 상기 검증도구는 COSPAN이고, 상기 제1 명세를 번역하는 단계는 상기 제1 명세를 S/R 명세 언어로 번역하는, 시스템 설계 검증 방법.
6. 제 1 항에 있어서, 상기 검증도구는 COSPAN이고, 상기 제2 명세를 번역하는 단계는 상기 제2 명세를 S/R 명세 언어로 번역하는, 시스템 설계 검증 방법.
7. 제 1 항에 있어서, 상기 제1 명세는 SDL 명세 언어로 되어있는, 시스템 설계 검증 방법.
8. 제 1 항에 있어서, 상기 제2 명세는 VHDL 또는 Verilog 명세 언어로 되어있는, 시스템 설계 검증 방법.
9. 제 1 항에 있어서, 상기 검증단계는 상기 시스템을 특징화하는 특성들의 세트를 검증하는 단계를 포함하는, 시스템 설계 검증 방법.
10. 소프트웨어 부분과 하드웨어 부분을 둘다 갖는 시스템의 설계의 검증 방법에 있어서,

    소프트웨어-중심 언어로 되어있는 소프트웨어 부분의 명세, 하드웨어-중심 언어로 되어있는 하드웨어 부분의 명세, 상기 시스템이 가지고 있는 특성들의 명세, 및 초기의 제약조건들(constraints)의 세트의 입력을, 기억장치 내로 수용하는 단계와;

    검증될 특성을 선택하는 단계와;

    선택된 특성을 검증하는 단계와;

    상기 검증하는 단계가 실패할 경우, 상기 실패를 표시하고, 상기 제약조건들 및/또는 명세들로 수정본들을 제공하기 위한 기회를 제공하는 단계와;

    상기 수정본들을 수용하는 단계와;

    상기 검증하는 단계로 복귀시키는 단계와;

    상기 검증하는 단계가 성공하는 경우에 검증될 또다른 특성을 선택하는 단계를 포함하는, 시스템 설계 검증 방법.
11. 제 10 항에 있어서, 하드웨어-중심 언어로 되어있는 상기 하드웨어 부분의 명세 및 상기 소프트웨어 부분의 명세는 명세들의 집합을 포함하고, 각각의 명세는 각각 상기 특성들 중의 특정한 하나에 관련되는 상기 시스템의 소자들의 명세를 나타내는, 시스템 설계 검증 방법.
12. 제 10 항에 있어서, 상기 검증하는 단계는,

    상기 선택된 특성에 관한 하드웨어 명세 부분과 소프트웨어 명세 부분을 상기 기억장치로부터 검색하는 단계와;

    상기 검색된 소프트웨어 명세 부분을 동기 형식으로 변환시키는 단계와;

    상기 검증도구가 상기 소프트웨어-중심 언어로 제시된 입력들에 대해 작동할 수 없으면, 상기 변환된 명세를 상기 검증도구의 명세 언어로 번역하는 단계와;

    상기 검증도구가 상기 하드웨어-중심 언어로 제시된 입력들에 대해 작동할 수 없으면, 상기 검색된 하드웨어 명세 부분을 상기 검증도구의 명세 언어로 번역하는 단계를 포함하는, 시스템 설계 검증 방법.
13. 제 12 항에 있어서, 상기 검증하는 단계는 국지화 축소(location reduction) 단계를 더 포함하는, 시스템 설계 검증 방법.
14. 제 12 항에 있어서, 상기 검증하는 단계는 상기 선택된 특성에 관련된 제약조건들을 상기 기억장치로부터 검색하는 단계와, 상기 검색된 제약조건들에 응답하여 국지화 축소하는 단계를 더 포함하는, 시스템 설계 검증 방법.
15. 제 10 항에 있어서, 상기 검증하는 단계는,

    상기 선택된 특성에 관한 하드웨어 명세 부분과 소프트웨어 명세 부분을 상기 기억장치로부터 검색하는 단계와;

    상기 선택된 특성이 하드웨어-중심인지 소프트웨어-중심인지를 식별하는 단계와;

    상기 선택된 특성이 소프트웨어-중심일 경우 검색된 소프트웨어 명세 부분에 부분 순서 축소를 적용하는 단계와;

    상기 선택된 특성이 하드웨어-중심이지만 상기 검색된 소프트웨어 명세 부분이 미리 선택된 조건을 만족시키는 경우, 상기 검색된 소프트웨어 명세 부분에 상기 부분 순서 축소를 적용하는 단계와;

    상기 선택된 특성이 하드웨어-중심이고 상기 검색된 소프트웨어 명세 부분이 상기 미리 선택된 조건을 만족시키지 못할 때, 소프트웨어 부분의 상기 검색된 명세를 동기 형식으로 변환시키고, 상기 선택된 특성이 소프트웨어-중심이거나 상기 검색된 소프트웨어 명세 부분이 상기 미리 선택된 조건을 만족시키지 못할 때, 상기 부분 순서 축소의 결과들을 동기 형식으로 변환시키는 단계와;

    검증도구가 상기 소프트웨어-중심 언어로 제시된 입력들에 대해 작동할 수 없으면, 상기 변환된 명세를 상기 검증도구의 명세 언어로 번역하는 단계와;

    상기 검증도구가 상기 하드웨어-중심 언어로 제시된 입력들에 대해 작동할 수 없으면, 상기 검색된 하드웨어 부분의 명세를 상기 검증도구의 명세 언어로 번역하는 단계를 포함하는, 시스템 설계 검증 방법.
16. 제 15 항에 있어서, 상기 특성이 하드웨어-중심인지 식별하는 단계는 상기 기억장치에서 발견된 정보에 기초해서 이루어지는, 시스템 설계 검증 방법.
17. 제 15 항에 있어서, 상기 부분 순서 축소는 정적 부분 순서 축소인, 시스템 설계 검증 방법.
18. 제 15 항에 있어서, 상기 검색하는 단계는 또한 상기 선택된 특성에 관한 제약조건들을 검색하고, 상기 부분 순서 축소를 적용하는 단계는 상기 검색된 제약조건들을 채용하는, 시스템 설계 검증 방법.
19. 제 15 항에 있어서, 상기 검증하는 단계는 국지화 축소 단계를 더 포함하는, 시스템 설계 검증 방법.
20. 제 19 항에 있어서, 상기 검증하는 단계는 상기 선택된 특성에 관한 제약조건들을 상기 기억장치로부터 검색하는 단계와, 상기 검색된 제약조건들에 응답하여 국지화 축소하는 단계를 더 포함하는, 시스템 설계 검증 방법.
21. 소프트웨어를 포함하는 시스템의 설계의 검증 방법에 있어서,

    상기 시스템의 명세에 대해 정적 부분 순서 축소를 수행하는 단계와;

    상기 정적 부분 순서 축소의 결과들을 동기 형식으로 변환시키는 단계와;

    상기 변환단계의 결과들에 의해 표시된 설계를 검증하는 단계와;

    상기 검증하는 단계의 가시적 결과들을 제시하는 단계를 포함하는, 시스템 설계 검증 방법.
22. 제 21 항에 있어서, 상기 검증하는 단계는 국지화 축소를 수행한 후에 기호검증(symbolic verification)을 수행하는, 시스템 설계 검증 방법.
23. 제 22 항에 있어서, 상기 기호 검증은 상태 달성가능성 분석(state reachability analysis)을 채용하는, 시스템 설계 검증 방법.
24. 제 22 항에 있어서, 상기 기호 검증은 기호 상태-공백 탐색을 채용하는, 시스템 설계 검증 방법.
25. 설계의 검증 장치에 있어서,

    상기 설계의 명세, 특성들의 집합 및 제약조건들을 저장하기 위한 메모리와;

    제어기와;

    소프트웨어를 설명하고 상기 메모리로부터 얻은, 상기 명세의 부분들에 응답하여, 상기 제어기의 제어하에 정적 부분 순서 축소 분석을 수행하는 제1 처리기와;

    상기 제어기로부터의 제어 신호들에 응답하여 소프트웨어를 설명하는 상기 명세의 부분들을 동기 형식으로 변환시키거나, 상기 제1 처리기의 출력신호를 동기형식으로 변환시키는 제2 처리기와;

    상기 메모리로부터 얻은 상기 명세의 부분들에 응답하고, 하드웨어를 설명하고, 상기 제2 처리기의 출력신호에 응답하는 검증도구와;

    상기 검증도구에 응답하는 디스플레이를 포함하는, 설계 검증 장치.
26. 설계의 검증 장치에 있어서,

    상기 설계의 명세, 특성들의 집합 및 제약조건들을 저장하기 위한 메모리와;

    상기 메모리에 저장된 신호들에 응답하여, 기호 검증이 뒤따르는 상기 설계에 대한 정적 순서 축소를 수행하는 저장된 프로그램 처리기와;

    상기 설계가 검증되는지 여부를 나타내는 상기 처리기에 의해 제공된 신호들에 응답하는 디스플레이를 포함하는, 설계 검증 장치.
27. 설계의 검증 장치에 있어서,

    상기 설계의 명세, 특성들의 집합 및 제약조건들을 저장하기 위한 메모리와;

    제어기와;

    소프트웨어를 설명하고 상기 메모리로부터 얻은, 상기 명세의 부분들에 응답하여, 정적 부분 순서 축소 분석을 수행하는 제1 수단과;

    소프트웨어를 설명하는 상기 명세의 부분들을 동기 형식으로 변환시키거나, 상기 제1 처리기의 출력신호를 동기 형식으로 변환시키기 위한 제2 수단과;

    상기 제2 처리기의 출력신호들에 응답하여, 하드웨어를 설명하고 상기 메모리로부터 얻은, 상기 명세의 부분들에 응답하는 제3 수단과;

    상기 제1 수단, 상기 제2 수단 및 상기 제3 수단을 제어하기 위한 제4 수단과;

    상기 제3 수단에 응답하는 디스플레이를 포함하는, 설계 검증 장치.