KR20070020247A

KR20070020247A - 모듈식 테스트 시스템을 모의하는 방법 및 시스템

Info

Publication number: KR20070020247A
Application number: KR1020067024540A
Authority: KR
Inventors: 콘라드 무카이; 안칸 프라마닉; 마크 엘스톤; 토시아키 아다치; 리안 엘. 첸
Original assignee: 주식회사 아도반테스토
Priority date: 2004-05-22
Filing date: 2005-05-23
Publication date: 2007-02-20
Also published as: ATE377767T1; DE602005003225T2; US20050262412A1; EP1756605A1; DE602005003225D1; EP1756605B1; JP3911007B1; US7210087B2; TWI352211B; JP2008519247A; WO2005114237A1; TW200610082A

Abstract

모듈식 테스트 시스템을 모의하는 방법이 본 발명에 개시된다. 본 방법은, 하나 이상의 벤더 모듈(vendor module) 및 그에 대응하는 피시험 디바이스(DUT) 모델을 제어하는 제어기를 제공하는 단계, 하나 이상의 벤더 모듈과 그에 대응하는 DUT 모델 사이에서 표준 인터페이스를 확립하는 시뮬레이션 프레임워크(simulation framework)를 생성하는 단계, 시뮬레이션 프레임워크를 구성하는(configuring) 단계, 및 시뮬레이션 프레임워크를 이용하여 모듈식 테스트 시스템을 모의하는 단계를 포함한다.

시뮬레이션, 프레임워크, 벤더 모듈, 인터페이스, 로드

Description

모듈식 테스트 시스템을 모의하는 방법 및 시스템{METHOD AND SYSTEM FOR SIMULATING A MODULAR TEST SYSTEM}

[관련 출원의 상호 참조]

본 출원은, 아도반테스토 사(Advantest Corporation)에 의해 2004년 5월 22일자로 출원된 미국 임시출원 제60/573,577호 "개방형 구조 테스트 시스템의 소프트웨어 개발(Software Development in an Open Architecture Test System)"의 이익을 주장하며, 그 전체를 참조에 의해 본 출원에 편입시킨다.

본 발명은, 자동화 테스트 장비(automated test equipment;ATE) 분야에 관한 것이다. 특히, 본 발명은, 모듈식 테스트 시스템을 모의하는(simulating) 방법 및 시스템에 관한 것이다.

반도체 생산에 있어 주비용이 드는 것은, 실행성 및 기능성에 대해 집적 회로를 시험하는 테스트 프로그램의 개발 및 유지이다. 보통 이러한 활동은, 실제 테스터 하드웨어에 많은 작업 시간을 부과한다. 그러나, 현존하는 반도체 테스터 는, 테스트 프로그래밍 언어의 의미를 체크하는 것을 제외하고는, 테스트 프로그램을 모의하는 능력이 거의 또는 전혀 없다. 이 한계는, 기술자들에게 실제 테스터 하드웨어에 테스트 프로그램을 디버그(debug)하도록 한다. 그러나, 테스트 프로그램 개발을 위한 테스터 하드웨어를 이용하는 것은, 비싼 테스트 장비의 비용 효율적인 이용이 아니다. 또한, 보통 테스터는 기술자 그룹 사이에 공유되어 있기 때문에, 테스터를 이용하기 위해 할당된 시간의 양은 제한되어 있으며, 이는 개발이 연속적으로 일어나는 공정의 테스트 프로그램의 개발에 장애를 일으킨다. 테스트 프로그램 개발에서 그러한 제한은, 집적 회로의 생산을 지연시킬 수 있는데, 이는 생산품 출하를 지연시키고 시장 기회를 잃어버릴 수 있다.

따라서, 비싼 테스트 장비를 이용함 없이, 테스트 프로그램의 기능성을 증명하는 방법 및 시스템이 필요하다. 특히, 테스트 프로그램, 벤더 모듈(vendor module), 및 그에 대응하는 피시험 디바이스(device-under-tests;DUTs)로, 모듈식 테스트 시스템을 모의하는 방법 및 시스템이 필요하다.

본 발명의 목적은, 테스트 프로그램 개발용 테스터 하드웨어의 이용량을 감소시키고, 그로 인해 유용한 테스터 장비의 이용을 최적화시키는 것이다. 본 발명의 다른 목적은, 테스터 장비에서 운용되기 전에, 테스트 프로그램, 모듈 및 DUTs의 문제를 확인하는 것이다. 본 발명의 또 다른 목적은, 테스트 프로그램, 모듈, 및 DUTs의 병행 개발을 위한 환경을 제공하고, 그로 인해 전체 생산품 개발 시간을 감소시키는 것이다.

모듈식 테스트 시스템을 모의하는 개시된 방법은, 최종 사용자에 의해 구성될 수 있는 시뮬레이션 프레임워크(simulation framwork)를 제공한다. 프레임워크는, 벤더 에뮬레이션(emulation) 모듈 및 DUT 모델을 로드(load)하고, 시뮬레이션 프레임워크 API를 통해 테스트 프로그램을 이행하기 위하여 시뮬레이션 환경을 구성하는데 이용된다. 이 방법은, 벤더의 소프트웨어 에뮬레이션을 설치하고 시스템 구성 파일(system configuration file)을 편집함으로써, 새로운 벤더 모듈이, 현존하는 설비에 추가되도록 한다. 또한 이 방법은, 기술자들이, 비싼 테스터 장비의 최소화된 사용으로 그들 자신의 워크스테이션에서 테스트 프로그램을 개발하도록 한다.

일실시예에 의하면, 모듈식 테스트 시스템을 모의하는 방법은, 적어도 하나의 벤더 모듈 및 그에 대응하는 DUT 모델을 제어하는 제어기를 제공하는 단계, 적어도 하나의 벤더 모듈과 그에 대응하는 DUT 모델 사이에서 표준 인터페이스를 확립하는 시뮬레이션 프레임워크를 생성하는 단계, 시뮬레이션 프레임워크를 구성하는 단계, 및 시뮬레이션 프레임워크를 이용하여 모듈식 테스트 시스템을 모의하는 단계를 포함한다.

다른 실시예에 의하면, 모듈식 테스트 시스템은, 하나 또는 그 이상의 벤더 모듈, 하나 또는 그 이상의 DUT 모델, 벤더 모듈 및 그에 대응하는 DUT 모듈을 제어하는 제어기, 및 벤더 모듈과 DUT 모델 사이에서 표준 인터페이스를 확립하는 시뮬레이션 프레임워크를 포함한다. 모듈식 테스트 시스템은, 시뮬레이션 프레임워크를 구성하는 수단, 및 시뮬레이션 프레임워크를 이용하여 모듈식 테스트 시스템을 모의하는 수단을 더 포함한다.

본 발명의 상술한 특징 및 이점들뿐만 아니라 그들의 추가적인 특징 및 이점들은, 다음 도면과 함께 취해진 본 발명의 실시예의 상세한 설명의 결과로서, 이하에서 더욱 명확하게 이해될 것이다.

도 1a는, 본 발명의 일실시예에 따른 개방형 구조(open architecture) 테스트 시스템을 도시한다.

도 1b는, 본 발명의 일실시예의 시뮬레이션 시스템의 개략도를 도시한다.

도 2는, 모듈식 테스트 시스템을 모의하는 시뮬레이션 프레임워크를 도시한다.

도 3a는, 본 발명의 일실시예에 따른 시뮬레이션 채널 객체(simulation channel object)를 처리하는 시뮬레이션 프레임워크를 도시한다.

도 3b는, 본 발명의 일실시예에 따른 스텝(step), 슬루(slew), 및 아날로그 파형을 도시한다.

도 4는, 본 발명의 일실시예에 따른 시뮬레이션 컴포넌트(component)를 처리하는 시뮬레이션 프레임워크를 도시한다.

도 5는, 본 발명의 일실시예에 따른 시뮬레이션 이벤트 객체를 처리하는 시뮬레이션 프레임워크를 도시한다.

도 6은, 본 발명의 일실시예에 따른 에뮬레이션 모듈과 로드보드(loadboard) 모델 사이의 채널을 도시한다.

모듈식 테스트 시스템을 모의하기 위한 방법 및 시스템이 제공된다. 이하의 설명은, 본 발명의 기술 분야에서 통상의 지식을 가진 자로 하여금, 본 발명을 만들고 이용할 수 있도록 제시된다. 특정 실시예 및 적용의 설명은, 단지 예시로서만 제공될 뿐이다. 여기에 설명된 예시의 다양한 수정 및 조합이, 당업자에게 매우 명백할 것이며, 여기에 정의된 일반 원리는 본 발명의 본질 및 범위로부터 이탈하지 않은 채, 다른 예 및 적용 분야에 적용될 수 있다. 그러므로, 본 발명은 설명되고 보여진 예에 한정되도록 의도된 것은 아니지만, 여기에 개시된 원리 및 특징에 부합하는 가장 넓은 범위를 따르게 될 것이다.

도 1a는, 본 발명의 일실시예에 다른 개방형 구조 테스트 시스템을 도시한다. 시스템 제어기(SysC) 102는, 다중 사이트 제어기(SiteCs) 104에 연결된다. 또한 시스템 제어기는, 관련 파일에 액세스하기 위해 네트워크로 연결될 수 있다. 모듈 접속 인에이블러(module connection enabler) 106을 통해, 각각의 사이트 제어기는, 테스트 사이트 110에 위치한 하나 또는 그 이상의 테스트 모듈 108을 제어하기 위하여 연결된다. 모듈 접속 인에이블러 106은, 접속된 하드웨어 모듈 108의 재구성(reconfiguration)을 허용하며, 또한 (패턴 데이터를 로드하고, 응답 데이터를 수집하며, 제어를 제공하는 등을 위한) 데이터 전송용 버스로서 작용한다. 또 한, 모듈 접속 인에이블러를 통해, 한 사이트의 모듈은 다른 사이트의 모듈에 액세스할 수 있다. 모듈 접속 인에이블러 106은, 다른 테스트 사이트가 동일하거나 다른 모듈 구성을 갖도록 한다. 다시 말해, 각각의 테스트 사이트는, 다른 수 및 타입의 모듈을 채용할 수 있다. 하드웨어가 가능한 실행은, 전용 접속, 스위치접속, 버스 접속, 링 접속, 및 성형 접속(star connection)을 포함한다. 모듈 접속 인에이블러 106은, 스위치 매트릭스(switch matrix)에 의해 실행될 수 있다. 예를 들면, 각각의 테스트 사이트 110은 DUT 112와 결합되는데, 이것은 로드 보드 114를 통해 대응 사이트의 모듈에 접속된다. 다른 실시예에 의하면, 단일 사이트 제어기는, 다중 DUT 사이트에 접속될 수 있다.

시스템 제어기 102는, 전반적인 시스템 관리자로서 작용한다. 그것은 사이트 제어기 활동을 조정하고, 시스템-레벨 병행 테스트 전략을 관리하며, 또한 추가적으로 시스템-레벨 데이터로깅(datalogging)뿐만 아니라 핸들러(handler)/프로브(probe) 제어, 및 에러-처리 지원(error-handling support)을 제공한다. 시스템 제어기 102는, 테스트 환경을 증명하고 디버그할 때, 테스트 기술자를 위한 상호 작용의 초기점이다. 그것은 사이트 제어기 104로의 게이트웨이를 제공하고, 복합-DUT 환경에서 사이트 제어기 활동의 동기화(synchronization)를 관리한다. 그것은, 테스트 시뮬레이션 모듈과 같은, 사용자 애플리케이션 및 도구(tools)를 더 운용한다. 작동 설정에 의존하여, 시스템 제어기 102는 사이트 제어기 104의 작동으로부터 분리된 CPU 상에 배치될 수 있다. 대신에, 공통의 CPU가 시스템 제어기 102 및 사이트 제어기 104에 의해 공유될 수 있다. 유사하게, 각각의 사이트 제어 기 104는, 자체 전용 CPU(중앙 처리 장치)상에, 또는 같은 CPU 내의 여러 프로세스(process)나 쓰레드(thread)로서 배치될 수 있다.

사이트 제어기 104는, DUTs를 시험하는 테스트 플랜(test plan)을 운용할 책임이 있다. 테스트 플랜은, 테스트 방법론을 캡슐화하는 표준, 또는 사용자 공급 테스트 클래스(Test Classes)뿐 아니라 프레임워크 클래스(Framework Classes)를 이용함으로써, 특정 테스트를 생성한다. 또한, 테스트 플랜은, 표준 인터페이스를 이용하는 하드웨어를 구성하고, 테스트 흐름을 정의한다.

본 발명의 시스템 구조는, 개별적인 시스템 컴포넌트가, 본질적으로 분산된 시스템의 물리적 컴포넌트로서가 아니라, 집적된 모놀리식(monolithic) 시스템의 논리적(logical) 컴포넌트로서 또한 간주될 수 있다는 이해와 함께, 도 1에 도시된 분산 시스템으로 개념적으로 생각될 수 있다. 플러그앤플레이(plug-and-play) 또는 대체 가능 모듈은, 하드웨어와 소프트웨어 레벨 모두의 표준 인터페이스의 이용에 의해 용이해진다. 테스터 작동 시스템(tester operating system;TOS)은, 사용자로 하여금, 테스트 플랜 프로그래밍 언어를 이용하여 테스트 플랜 프로그램을 쓰고, 특정 피시험 디바이스(DUT)에 특정한 방식으로 테스트 시스템을 작동시키도록 한다. 또한, 그것은 사용자로 하여금, 테스트 플랜 프로그램에 공통으로 이용된 테스트 시스템 작동의 시퀀스(sequence)를 패키지(package)하도록 한다. 이 라이브러리는, 가끔 테스트 클래스 및 테스트 템플릿(template)으로 언급된다.

도 1b는, 본 발명의 일실시예의 시뮬레이션 시스템의 개략도를 도시한다. 시뮬레이션 시스템은, 제어기 모델 121, 하나 또는 그 이상의 벤더 에뮬레이션 모 듈 122(벤더 에뮬레이션 모듈이라는 용어는 또한, 벤더 모듈이나 에뮬레이션 모듈로도 언급된다는 점을 유의), 하나 또는 그 이상의 피시험 디바이스(DUT) 모델 124, 및 로드보드 모델 126을 포함한다. 시뮬레이션 환경을 어셈블리 언어로 번역하기 위해, 사용자는, 에뮬레이션 모듈, 로드보드 모델, 및 DUT 모델이 시뮬레이션 프레임워크를 통해 어떻게 접속되는지를 설명하는, 시스템 구성 파일 및 오프라인 구성 파일(둘 모두 아래에서 상세하게 설명된다)을 생성한다. 시뮬레이션 이행은, 테스트 프로그램에 의해 모듈 모델로 로드된 패턴에서 수행된다.

시뮬레이션 프레임워크는, 로드보드 모델 106, 하나 또는 그 이상의 테스터 채널 128, 및 하나 또는 그 이상의 DUT 채널 130을 공급한다. 모듈은, 벤더의 동적 링크 라이브러리(dynamic link libraries;DLLs)로부터 로드된다. 각 블록은, 모듈의 단일 인스턴스(instance)를 나타낸다. DLL은, 같은 모듈 타입의 다중 인스턴스를 생성하기 위해 여러 번 로드될 수 있다. DUT 모델 124는, 그 모델이 C++로 쓰여진다면 DLLs, 또는 베릴로그(Verilog) 모드 중 어느 하나로서 공급될 수 있다.

로드보드 모델 126은, 사용자에 의해 구성 가능하다. 사용자는, 테스터 채널 128을 대응하는 DUT 채널 130에 맞추고, 각 접속과 관련된 전송 지연(transport delay)을 특정한다. 모든 접속은, 양방향성을 갖고, 따라서, 커넥터를 출력 드라이버나 입력 스트로브(input strobe)로서 지명하는데 어느 특별한 고려도 필요로 하지 않는다.

시뮬레이션 프레임워크

테스트 시스템 시뮬레이션의 주요 부분은, 시뮬레이션 프레임워크인데, 이는 또한 프레임워크로서 언급된다. 프레임워크는, 두 개의 기본 서비스를 제공한다. 첫째, 각 벤더 모듈이, 시스템 버스를 통해 정상적인 테스터 작동 중에서와 실질적으로 같은 방식으로 프로그램되도록 한다. 버스 호출(bus calls)을 모의함으로써, 테스트 프로그램은 에뮬레이트된 모듈 레지스터로 쓸 수 있고, 그에 의해 테스트를 구성한다. 다른 서비스는, 테스트 이행의 시뮬레이션이다. 프레임워크는, 에뮬레이트된 모듈과 DUT 모델 사이의 물리적 접속을 위한 모델을 제공한다. 프레임워크는, 또한 다양한 시뮬레이션 컴포넌트의 이행 시퀀스를 유지하기 위한 장치를 공급한다.

테스트 시스템이 시뮬레이션 모드(오프라인 모드)에 있을 때, 테스터 모듈 하드웨어와 통신하는데 이용된 디바이스 드라이버를, 공유 메모리를 통해 프레임워크와 통신하는 소프트웨어 모듈로 대체한다. 실제 테스터에서, 모듈로의 통신은, 버스로서 알려진 하드웨어 모듈에 의해 용이해진다. 대체로 버스는, 2진(binary) 패턴을, 벤더의 하드웨어 모듈의, 어드레스로 불러낼 수 있는(addressable) 레지스터로 보내는 명령을 이용한다. 시뮬레이션에서, 같은 명령은, 특정의 에뮬레이트된 모듈을 목표로 하여, 프레임워크에 의해 수취되고 해석된다. 다음으로 프레임워크는, 모의 레지스터에 데이터를 저장할 수 있도록, 레지스터 어드레스 및 데이터를 모듈로 보낸다. 테스트 프로그램 로딩은, 최종적으로 어드레스/데이터 쌍의 기본 유닛으로 분해되기 때문에, 이 간단한 모델은, 테스트 프로그램이 모듈과 갖는 모든 상호 작용을 지원한다. 이 프로세스의 부차적 결과는, 교정(calibration) 및 진단 프로그램 개발을 또한 지원하는 시뮬레이션이다.

온라인과 오프라인 모드 사이의 실행시간(runtime) 소프트웨어의 유일한 차이는, 시스템 버스 디바이스 드라이버에 있기 때문에, 온라인 환경에서의 테스트 프로그램의 동작과 오프라인 환경에서의 그에 대응하는 동작 사이에는, 고도의 상관 관계가 있다. 그러므로, 시뮬레이션은, 사용자의 테스트 프로그램 및 기초가 되는 테스터 작동 시스템(TOS)의 동작에 관하여 정밀하다.

프레임워크는 또한, 테스터 모듈과 DUT 사이의 물리적 접속의 상세한 모델을 제공한다. 모든 접속은 전선(wire)의 전압으로서 모델링되기 때문에, 기초가 되는 물리적 현상을 재생한다. 모듈/DUT 상호 작용에는 데이터 형식에 관한 어떤 가정도 없기 때문에, 프레임워크에 의해 확립된 애플리케이션 프로그래밍 인터페이스(application programming interface;API)를 이용하는 한, 프레임워크는 에뮬레이션 모듈과 DUT 모델의 조합으로 작동한다. 프레임워크는, 둘이 동시에 같은 전선의 드라이브를 공급할 때, 전압의 자동 일치를 제공한다.

테스트 프로그램의 이행 중에 시뮬레이션을 제어하기 위해, 프레임워크는, 벤더의 모듈이 이벤트를 기록하고 수취하도록 하는, API의 다양한 방법을 제공한다. 프레임워크는, 에뮬레이트된 모듈 및 DUT 모델의 이행의 시퀀스를 제어하기 위해 이 이벤트를 이용한다. 이 이벤트를 관리하고 모듈이 이벤트를 어떻게 처리하는지에 관한 기본 법칙을 특정함으로써, 모듈 에뮬레이션을 생성하는 플렉시블 템플릿(flexible template)은, 모듈식 테스트 시스템의 사용자들에게 유용하도록 만들어진다.

도 2는, 모듈식 테스트 시스템을 모의하는 시뮬레이션 프레임워크를 도시한 다. 시뮬레이션 프레임워크는, 시뮬레이션 매니저(SimMgr) 클래스 202, 시뮬레이션 채널(SimChannel) 클래스 204, 시뮬레이션 컴포넌트(SimComponent) 클래스 206, 및 시뮬레이션 이벤트 매니저(SimEventMgr) 클래스 208을 포함한다. SimMgr 클래스 202는, 시뮬레이션 프로세스를 관리한다. SimCoponent 206은, 벤더가 이용하는 베이스 클래스이다. 일정한 요구 동작은, 이 클래스 내에서 실행된다. 그 방법 중 많은 것이 (C++에서) 가상이고, 벤더 실행을 필요로 한다. SimComponent 클래스로부터 계승한 CAnalogModule 클래스 210은, 요구된 벤더 특정 기능성을 추가하는데 이용된다.

CAnalogModule 클래스 210은, CSimAWG 객체 212 및 CsimDigitizer 객체 214라 불리는, 일련의 SimChannel 파생 객체를 포함한다. 이 객체는, 시스템 리소스(제어 구조에서 IResource 파생 클래스)를 나타내는데, 여기에서 CSimAWG 객체는 D/A 채널(디지털 명령으로부터의 아날로그 출력)을 모델링하는 아날로그 파형 생성기(analog waveform generator)이고, CSimDigitizer 객체는 대응하는 A/D 채널(아날로그 신호로부터의 디지털 입력)을 모델링한다. IResource 파생 클래스 요구는, 이 실행 클래스로 편입되고, 이 클래스는 파형을 생성하고 읽기 위한 시스템 제공 유틸리티를 이용한다. SimEventMgr 클래스 208은, 시뮬레이션 이벤트 객체 216을 더 포함한다. 시뮬레이션 프레임워크의 각 컴포넌트의 상세한 설명은, 아래에 설명된다.

시뮬레이션 프레임워크는, 에뮬레이션 모듈 및 DUT 모델 개발자들에게 일련의 미리 정해진 인터페이스 및 디자인의 제한을 강요한다. 이것은, 시뮬레이션 프 레임워크의 요건에 맞는 모델이, 시뮬레이션 내의 다른 컴포넌트와 호환된다는 점을 입증한다. 시뮬레이션 프레임워크는, 에뮬레이션 모듈 및 DUT 모델 모두에 공통인 API를 위한 제1 부분, 모듈 모델에 특정한 제2 부분, 및 DUT 모델에 특정한 제3 부분의, 세 부분으로 분리된다. 한 실행에 의하면, 벤더 에뮬레이션 모듈은, 이벤트-기반 모델로 여겨지고, 반면에 DUT 모델은 시간-기반 모델로 여겨진다. 다른 실시예에 의하면, 에뮬레이션 모듈과 DUT 모델 모두, 이벤트-기반, 또는 시간-기반 모델 중 어느 하나일 수 있다.

시뮬레이션 채널

도 3a는, 본 발명의 일실시예에 따른 시뮬레이션 채널 객체를 처리하는 시뮬레이션 프레임워크를 도시한다. 시뮬레이션 프레임워크는, 모듈 클래스 302, DUT 클래스 304, 및 시뮬레이션 채널(SimChannel) 클래스 306을 포함한다. SimChannel 클래스 306은 시뮬레이션 파형 이터레이터(simulation waveform iterator;SimWaveformIter) 클래스 308을 포함하고, 모듈 클래스 302는 시뮬레이션 채널 식별자(SimChanID) 클래스 310을 포함한다.

SimChannel 클래스 306은, 패턴 이행 중에, 각각 모듈 클래스 302 및 DUT 클래스 304를 통해, 에뮬레이션 모듈 및 DUT 모델에 I/O 능력을 제공한다. 이 클래스를 이용하기 위해, 빈(empty) 채널 객체는 각 모듈 채널 또는 DUT 핀을 위해 구성된다. 시뮬레이션 구성 파일(아래에 설명됨)의 설정에 기초하여, 이 채널은 시뮬레이션 프레임워크에 의해 로드보드상의 대응 채널과 접속된다. 시뮬레이션 프레임워크는, 로드보드 접속을 만드는데 이용되는 getChannel() 메쏘드를 통해 SimChannel 객체에 관한 참조를 획득한다.

모듈과 DUT 모델 모두에 공통한 요소는, 채널로의 I/O 호출이다. 모듈과 DUTs 사이의 모든 I/O 호출은, 특정 시간에 전압 레벨을 설정함으로써 행해진다. 이것은 SimChannel 클래스 306으로부터 set() 메쏘드에 의해 제공된다. 이 메쏘드는, 호출 루틴(calling routine)이, SimChannel 클래스 306에 접속된 출력 버퍼에 엔트리(entry)를 기록함으로써 특정 시간에 전압을 특정하도록 한다.

일실시예에 의하면, set() 메쏘드는, 전압 시간 이력에 한 시점을 기록한다. 파형의 타입은, 채널이 어떻게 구성되는지에 달려있다. 도 3b는, 본 발명의 일실시예에 따른 스텝, 슬루, 및 아날로그 파형을 도시한다. 스텝 채널에서는, 전압 전이(voltage transition)가 순간적이고, 따라서 t1과 t2 사이에서는 v1의 전압을 리턴한다. 슬루 채널에서는, 현재 상태로부터 명령된 상태로의 전압 전이에 유한한 시간이 걸린다. 전이의 기울기는, 시스템 구성 파일의 슬루 영역에서 슬루레이트(slewRate) 파라미터에 의해 결정된다. 마지막으로, 아날로그 채널에서는, 전압이 평평하게 되지 않는다. 시간점들 사이에서 전압은, 구분 선형 내삽(piece-wise linear interpolation)을 통해 계산된다. 마지막 점을 넘어 읽는다면, 값은 마지막 두 점으로부터 외삽된다; 그러므로, t2에 대한 세트 호출을 넘어 어느 점도 추가되지 않는다면, 대시 라인(dashed line)은 전압이 채널로부터 읽혀진다는 것을 나타낸다.

off() 메쏘드는, 우선 전압에 대한 드라이브를 끄는데 이용된다. 이것은, 두 컴포넌트가 채널의 반대측에 동시에 쓸 때 일어난다. 만일 한 측이 set() 메쏘 드를 호출한다면, 다음으로 전압이 구동되는 것으로 여겨진다. 만일 다른 측이 off() 메쏘드를 호출한다면, 다음으로 전압은 반응이 없는 것으로 여겨진다. 이 경우에, 구동 전압이 보급되고, 양측의 전압이 분석된 후에, 각 채널로부터 읽혀진 전압은 set() 명령을 갖는 전압 입력이다. 양측이 set() 메쏘드를 호출하거나 양측이 off() 메쏘드를 호출한다면, 다음으로 전압 이력은 평균 전압값으로 설정된다.

end() 메쏘드 호출은, 채널이 분석(resolution)될 준비가 되어 있고, 그 결과 채널의 다른 측에 있는 컴포넌트에 의해 읽을 준비가 되어 있다는 것을 시뮬레이션 프레임워크에 알린다. end() 메쏘드가 채널에 호출되지 않는다면, 그 채널의 신호는 채널의 반대측에 있는 컴포넌트가 채널로부터 읽도록 신호를 받지 않았기 때문에, 시뮬레이션의 나머지를 통해 전달되지 않을 수 있다. 전형적으로 사용자는 시간 범위에 걸쳐 전압을 특정하기 위해 여러 세트 호출을 만들고, 다음으로 시간 범위의 끝에 end() 메쏘드를 한번 호출한다.

SimWaveformIter 클래스 308은, 파형의 전이를 확인한다. 사용자는 SimChannel 클래스 308에서 getWaveformIter() 메쏘드를 호출함으로써, 파형 이터레이터의 인스턴스를 얻는다. 이 메쏘드는, 사용자가, 시작하고 끝나는 시간뿐만 아니라, 높고 낮은 전압을 특정하도록 요구한다. 이 데이터를 이용하여, getWaveformIter() 메쏘드는, SimWaveformIter 클래스 308의 인스턴스를 리턴한다. getWaveformIter() 메쏘드는, 사용자가 파형의 모든 에지 전이를 거쳐 나아가도록 한다. 그것은 각 전이에 대해, 전이의 시간 및 전이를 따르는 파형의 상태(state) 를 리턴한다. 상태는 열거된 타입 State_t로서 특정된다. 이 타입에 대해 가능한 값은, H(높음), L(낮음), 및 Z(트라이스테이트)이다.

본 발명의 한 실행에 의하면, getWaveformIter() 메쏘드의 일례는 아래에 보여진다.

void findHighs( SimChannel &sc, const Voltage& vhi , const Voltage&vlo, const Time&t_start, const Time&t_end)

{

SimWaveformIter iter = sc . getWaveformIter ();

for (; ! iter . end (); iter . next ())

{

if ( iter . getState () == SimWaveformIter ::H)

{

cout << " waveform goes high at " << iter . getTime (). getValue ()

<< endl ;

}

SimWaveformIter 클래스 308은, 다음 메쏘드를 포함한다.

ㆍ start(): 이터레이터를 제1 전이로 설정한다.

ㆍ end(): end() 메쏘드는, 이터레이터가 에지 시퀀스의 끝에 있는지를 체크한다. 이 메쏘드가 트루(true)를 리턴한다면, getTime 및 getState의 결과가 정의되지 않았다는 점을 유의한다.

ㆍ next(): next() 메쏘드는, 다음 전이로 이터레이터를 이동시킨다.

ㆍ getTime(): getTime() 메쏘드는, 현재 전이에 대한 시간을 리턴한다.

ㆍ getState(): getState() 메쏘드는, 현재 에지의 상태를 획득한다. 에지는, 에지 시간 후에 기초가 되는 파형의 상태에 적용된다.

다른 실시예에 의하면, SimChannel 클래스 306은, 특정 시간에 채널의 전압을 읽는 능력을 제공한다. 이것은, 단일 시간 인수(argument)를 이용하여 read() 메쏘드를 통해 행해진다. read()에 의해 리턴된 값은, 시간 대 전압 정보를 포함하는 테이블에 저장된 데이터로부터 내삽된다. 내삽의 메쏘드는, 시뮬레이션 구성 파일에 정의된 것과 같이 채널 구성에 기초한다. 채널이 스텝 채널로서 구성된다면, 다음으로 구형파(square wave) 모델이 이용된다. 채널이 슬루 채널로서 구성된다면, 다음으로 슬루 모델은 유한한 시간에 걸쳐 일어나는 전압 전이를 내삽하는데 이용된다. 채널이 아날로그 채널이라면, 다음으로 전압은 구분 선형 내삽을 이용하여 계산된다.

또한, 사용자는 채널의 데이터를 관리할 책임이 있다. 이것은 flush() 메소드를 통해 행해진다. 이 메쏘드는, 클린업 단계(clean-up phase)에 대한 채널을 기록한다. 그것은 플러쉬(flush) 인수에 의해 특정된 시간에 앞서 어떠한 읽기도 일어날 수 없음을 나타낸다. flush() 메쏘드가 호출될 때, 특정 시간 전의 모든 기록은, 다음 클린업 사이클 중에 채널로부터 제거된다. flush() 메쏘드는, 메모리 한계가 시뮬레이션의 완성을 방해할 수 있는 긴 패턴을 위해 규칙적으로 호출된다.

또 다른 실시예에 의하면, 채널에 기록하기 위해, 출력 전압을 특정하는 초기 메쏘드는, set() 메쏘드인데, 여기에서 사용자는 시간 및 관계 전압을 파라미터로 특정한다. 이 메쏘드는, 채널의 시간 이력으로 입력을 제공한다. 드라이브가 꺼진다면, off() 메쏘드가 이용될 수 있다. 이것은, 신호가 인터페이스의 다른 측으로부터 구동되는 경우, 그 채널에 전압을 지시한다는 것을 가리킨다. off() 메쏘드는, 드라이브와 스트로브 작동 모두를 수행하는 양방향성 채널에 우선 이용된다.

사용자는, 채널로 입력된 값의 세트가 인터페이스의 다른 측으로 전송할 준비가 되었음을 지시할 수 있다. 이것은 오버로드된(overloaded) end() 메쏘드를 통해 행해진다. end() 메쏘드는, end() 호출에 특정된 시간을 포함하여 그 시간까지, 채널의 값을 읽을 준비가 되었음을 시뮬레이션 프레임워크에 알린다. 인수가 없는 end() 메쏘드는, set() 또는 off() 호출 중 어느 하나에서 최대 시간을 디폴트(default)로 한다는 점을 유의한다. end() 메쏘드는, set() 메쏘드가 실시되도록 호출된다. end() 메쏘드가 호출되지 않는다면, 어느 데이터도 채널의 다른 끝으로 전송되지 않는다.

일실시예에 의하면, 공통 API 클래스가 다음과 같이 이용된다.

// create some channels in constructor

SimChannel MyStepChannel ;

SimChannel MySlewChannel ;

SimChannel MyAnalogChannel ;

…

// channel registration

SimChannel ＊ getChannel( const SimChanID & chan )

{

if( chan . getIndex () == MY _ STEP _ CHANNEL _ INDEX )

{

return & MyStepChannel ;

}

else if( chan . getIndex () == MY _ SLEW _ CHANNEL _ INDEX )

{

return & MySlewChannel ;

}

else if( chan . getIndex () == MY _ ANALOG _ CHANNEL _ INDEX)

{

return & MyAnalogChannel ;

}

…

}

// running a pattern

void handleEvent ( const SimEvent & event , const Time &t)

{

if ( event . isWriteEvent ())

{

…

// set some output voltages on the step channel

MyStepChannel . set ( t0 , hi _ level );

MyStepChannel . set ( t2 , lo _ level );

MyStepChannel . end ( t4 );

// set some output voltages on the slew channel

MySlewChannel . set ( t0 , hi _ level );

MySlewChannel . set ( t2 , lo _ level );

MySlewChannel . end ( t4 );

// set some output voltages on the analog channel

MyAnalogChannel . set ( t0 , lo _ level );

MyAnalogChannel . set ( t1 , hi _ level );

MyAnalogChannel . set ( t2 , hi _ level );

MyAnalogChannel . set ( t3 , lo _ level );

MyAnalogChannel . set ( t4 , lo _ level );

…

}

else if ( event . isReadEvent ())

{

…

// now strobe the step channel

Voltage strobe _ value = MyStepChannel .read( t5 );

MyStepChannel . flush ( t5 );// done reading

…

}

…

}

스텝 및 슬루 파형에서는, 단지 전이만이 특정될 필요가 있는 반면, 아날로그 신호에 대해서는, 파형의 모든 코너가 특정될 필요가 있다.

getWaveformIter() 메쏘드는, 호출기(caller)가 윈도우 스트로브(window strobe)로부터 이용할 수 있는 상태를 리턴하도록 한다. 그것은, 높은 입력 전압, 낮은 입력 전압, 및 타임 윈도우(time window)를 인수로서 취하고, 전압이 교차되는 시간을 포함하는 객체를 리턴한다.

SimChanID 클래스 310은, 채널 인덱스를 캡슐화한다. 테스트 시스템에는 두 세트의 채널 인덱스가 있는데, 하나는 테스터 채널 공간용이고, 다른 하나는 DUT 채널 공간용이다. SimChanID 클래스는, 각 공간에 인덱스를 설명하는 20 비트 단어를 캡슐화한다. 최상위 비트는, 채널 인덱스가 테스터 채널 공간에 있는지, 또는 DUT 채널 공간에 있는지를 가리킨다. 다음 비트는, 모든 채널이 이용되고 있는지를 가리키는 플래그(flag)이다. 다음 7 비트는, 각각 테스터 모듈이나 DUT 중 어느 하나를 위한 포트나 DUT 인덱스이다. 최하위 12 비트는, 로컬 인덱스 값(4K 채널)에 이용된다.

SimChanID 클래스 310은, 다음 방법을 포함한다.

ㆍ SimChanID(): SimChanID() 메쏘드는, 모든 채널 비트가 설정된다면 트루를 리턴한다.

ㆍ getIndex(): getIndex() 메쏘드는, 로컬 채널 공간에서 인덱스를 리턴한 다. isTestChannel 및 isDUTChannel 메쏘드는, 인덱스가 각각 테스터를 위한 것인지 또는 DUT 공간을 위한 것인지를 나타낸다. all() 메쏘드가 트루를 리턴한다면, 다음으로 이 메쏘드의 결과는 정의되지 않는다.

ㆍ getPort(): getPort() 메쏘드는, 주어진 채널 ID에 대한 포트를 리턴한다. 포트 및 인덱스의 조합은, 유일하게 로드보드 한 측의 모든 채널을 확인한다.

ㆍ isDUTChannel(): isDUTChannel() 메쏘드는, 채널이 DUT 채널 공간에 있다면 트루를 리턴한다.

ㆍ isTesterChannel(): isTesterChannel() 메쏘드는, 채널이 테스터 채널 공간에 있다면 트루를 리턴한다.

시뮬레이션 컴포넌트

도 4는, 본 발명의 일실시예에 따른 시뮬레이션 컴포넌트를 처리하는 시뮬레이션 프레임워크를 도시한다. 시뮬레이션 프레임워크는 시뮬레이션 컴포넌트 베이스(SimComponentBase) 클래스 401을 포함한다. SimComponent 클래스 402 및 SimComponentStepped 클래스 406은, SimComponentBase 클래스로부터 파생된다. 벤더 에뮬레이션 모듈(Module) 클래스 404는 SimComponent 클래스로부터 파생된다. 가상 기능은, 모듈의 동작을 정의하기 위해, SimComponent 클래스 402 내에서 개발된다. 유사하게, DUT 클래스 408은, SimComponentStepped 클래스 406으로부터 파생된다. SimComponentBase 401은, SimComponent 402 및 SimComponentStepped 406 클래스 모두에 의해 공유된 메쏘드를 포함하는 공통의 베이스 클래스이다.

Module 클래스 404는, 시뮬레이션 이벤트 객체를 처리하는 handleEvent() 메 쏘드를 호출한다. handleEvent() 메쏘드는, registerEvent(), 및 SimComponent 클래스의 raiseEvent()에 의해 제공된 어떤 서비스와 함께 이용된다. registerEvent() 메쏘드는, 모듈이 시뮬레이션 프레임워크를 갖는 이벤트를 기록하도록 한다. 이벤트는, 단일 채널, 채널 그룹, 또는 전체 모듈과 관련될 수 있다. 또한 이벤트는, 특정 시간을 갖고 기록될 수 있는데, 이 경우에 호출기는 읽기나 쓰기 이벤트 중 어느 하나로서 이벤트를 확인한다. 이벤트가 쓰기 이벤트라면, 다음으로 모듈을 위한 handleEvent() 콜백(callback)은, 시뮬레이션이 기록 시간(registration time)에 도달하자마자, 불려 내어진다. 이벤트가 읽기 이벤트라면, 다음으로 handleEvent() 콜백은, 단지 이벤트가 관련된 모든 채널이 분석되고 읽을 준비가 되어 있는 후에만, 불려 내어진다.

handleEvent() 호출이 관련된 시간을 갖는 이벤트(즉, 동기화 이벤트)에 응답하여 만들어질 때, 다음으로 모듈은, 시뮬레이션이 적절하게 동작하도록 시뮬레이션 프레임워크에서 정의된 바와 같이 API에 의해 규정된 규칙을 따를 필요가 있다:

ㆍ 쓰기 이벤트를 위해, 모듈은, 단지 쓰기 이벤트의 시간 후의 시간에 대한 전압값을 설정할 수 있다.

ㆍ 읽기 이벤트를 위해, 모듈은, 단지 읽기 이벤트의 시간 전의 시간에 대한 전압값을 읽을 수 있다.

이벤트는 또한, 시간 없이 기록될 수 있다(즉, 비동기화 이벤트). 이 이벤트는 다른 모듈에 의해, 또는 시뮬레이션 프레임워크에 의해 개시된다. 이 이벤트 는 두 기능을 지원한다. 제1 기능은, 인터럽트(interrupt)와 같은 시스템의 잘 알려진 일정한 이벤트를 처리하기 위한 것이다. 제2 기능은, 인터모듈(inter-module) 통신을 처리하기 위한 것이다. 비동기화 이벤트는, 한 모듈이 일정한 세트 조건이 일어난 다른 모듈을 통지하도록 한다. 일례는, 디지털 핀 모듈이 현 사이클과 관련된 에지를 출력하도록, 사이클의 시작에서 디지털 핀 모듈을 통지하는 동기화 모듈이다.

벤더의 모듈이 프레임워크로 로드되기 위해, 벤더는 바람직하게, 에뮬레이션 모듈 모델을 유지하는 객체의 생성 및 파괴를 지원하는 DLL로부터 어떤 미리 정의된 기능을 이출(export)한다. 이 규격화된 인터페이스는, 각 모델을 로드하는 세부사항을 숨긴다.

시뮬레이션 모델은, SimComponent 클래스로부터 파생되는데, 이느 시뮬레이션 프레임워크에 액세스 가능하도록 만들어진다. 모델을 정의하기 위해, 사용자는 SimComponet 클래스에서 특정된 가상 기능을 실행한다. 모듈의 가상 기능은, 두 카테고리로 된다:

ㆍ 파생된 클래스가 제공할 필요가 있는 가상 메쏘드; 및

ㆍ 사용자가 재정의할 수 있는 실행을 디폴트 실행을 갖는 기본 기능.

이 기능들 이외에, 또한 이 클래스는 이벤트 관리용 파생 클래스에 서비스를 제공한다.

DUT 모델은, 시뮬레이션 프레임워크의 SimComponentStepped 클래스 406으로부터 파생함으로써 실행된다. 개발자는, 모듈의 동작을 정의하기 위해, SimComponentStepped 클래스 406에서 가상 기능을 실행한다. 예를 들면, run() 메쏘드는, DUT 모델이 특정된 타임 윈도우에 걸쳐 운용되도록 한다. 인터페이스의 간단성 때문에, 모델 디자이너에게는, DUT가 모델링 될 수 있는 방법에 있어서 넓은 범위가 주어진다. 이 범위는, 베릴로그 모델을 운용하는 서버에 접속하는 C/C++ 모델이나 DLLs용 공통 인터페이스에 의해 지원된다. DUT 모델이 어떻게 실행되는지에 대한 세부사항은, 그러한 모델이 호환성 있게 사용되도록 하면서, 시뮬레이션의 나머지로부터 분리된다. 시뮬레이션 프레임워크에서 DUT 모델을 제공하기 위해, SimComponentStepped 클래스는 다음 가상 메쏘드를 포함한다:

ㆍ run(): 사용자는 특정된 타임 윈도우를 통해 DUT 모델을 운용한다. 다음의 run() 호출은, 마지막 run() 호출이 종결된 곳에서 시작할 수 있다.

ㆍ handleISVM(): 이 메쏘드는, 특정된 채널용 파라미터 측정 유닛(parametric measurement unit;PMU)으로부터 측정을 리턴한다. PMU는, 테스트가 일시 정지된 상태, 또는 테스트들의 사이에 있는 동안, 채널에 있는 정적 DC 측정을 만드는데 이용된다는 점을 유의한다.

ㆍ handleVSIM(): 이 메쏘드는, 특정된 채널용 PMU 측정을 리턴한다.

ㆍ handleVSVM(): 이 메쏘드는, 특정된 채널용 PMU 측정을 리턴한다.

시뮬레이션 프레임워크로 DUT 모델을 로드하기 위해, DLL은, DUT 모델을 유지하는 객체의 생성 및 파괴를 지원하는 한 세트의 미리 정의된 기능을 이출한다. 이 규격화된 인터페이스는, 각 모델을 로드하는 세부사항을 숨긴다.

시뮬레이션 이벤트 매니저

도 5는, 본 발명의 일실시예에 따른 시뮬레이션 이벤트 객체를 처리하는 시뮬레이션 프레임워크를 도시한다. 시뮬레이션 프레임워크는, 모듈 클래스 502, 시뮬레이션 이벤트 매니저(SimEventMgr) 클래스 504, 및 시뮬레이션 이벤트(SimEvent) 클래스 506을 포함한다.

SimEventMgr 클래스 504는, SimEvent 클래스 506의 인스턴스를 생성한다. SimEventMgr 클래스 504는, 벤더 인덱스를 유지하는데 이용된다. 이 인덱스는, 유일하게 이벤트의 패밀리를 확인한다. 정상적으로 이벤트의 패밀리는 벤더와 관련되고, 이것은 벤더 ID 문자열(string)을 지정한다. 또한 클래스는, 둘 또는 그 이상의 모듈 그룹이 분리된 이벤트 공간의 이벤트를 공유할 수 있도록, 사용자가 이벤트의 다른 패밀리를 생성하도록 한다.

일실시예에 의하면, 특정 벤더 인덱스용 SimEventMgr 객체를 생성하기 위해, 다음 구성이 이용된다:

SimEventMgr ( const OFCString &, SimChanID :: ChannelSpace _t)

문자열 인수는, 이벤트 패밀리를 특정한다. 채널 공간 타입은, 이벤트용 채널이 테스터 채널 (SimChanID::TESTER_SPACE)인지 또는 DUT 채널(SimChanID::DUT_SPACE) 인지를 나타낸다. 예를 들면, 사용자가 "ADVANTEST" 테스터 모듈용 이벤트를 생성하고 싶다면, 다음 메쏘드가 호출된다.

SimEventMgr emgr (_T(" ADVANTEST "), SimChanID :: TESTER _ SPACE );

모듈 개발자는, 모듈이 속해있는 각 도메인(domain)용 SimEventMgr의 인스턴스를 생성한다. 이 객체들은, 모듈의 존재의 지속에 이용된다. 예를 들면, 다음 호출 세트가 다양한 도메인용 이멘트를 생산하기 위해 만들어진다:

SimEventMgr m_ advmgr (_T(" ADVANTEST "), SimChanID :: TESTER _ SPACE );

SimEventMgr m_ msomgr (_T(" MSO _ CONSORTIUM "),

SimChanID ::TESTER_SPACE);

SimEventMgr m_ pwrmgr (_T(" POWER _ GROUP "), SimChanID :: TESTER _ SPACE );

시뮬레이션의 과정 중에, 이 객체 각각은, 도메인의 각각에 대한 이벤트를 생산할 수 있다. 이 방식으로, 다른 벤더에 의해 생성된 모듈은, 공유 도메인을 위한 고유명(unique name)을 합의함으로써 이벤트를 공유할 수 있다. DUT 모델이 이벤트를 기록할 필요가 있는 이벤트에서, clientmgr() 메쏘드가 이용된다. 두 채널은 다른 인덱스 공간에 속해 있기 때문에, DUT 공간과 테스터 공간 사이에는 구별이 있다는 것을 유의한다.

SimEventMgr clientmgr (" CLIENT ", SimChanID :: DUT _ SPACE );

다양한 메쏘드가 이벤트를 생성하기 위해 이용된다. 동기화 이벤트를 생성하는 메쏘드는 다음을 포함한다:

ㆍ SimEvent makeReadEvent(SimEvent::LocalCode_t): 이 메쏘드는, 모듈의 모든 채널용 읽기 이벤트를 생성한다.

ㆍ SimEvent makeReadEvent(SimChanID::Index_t, SimEvent::LocalCode_t): 이 메쏘드는, 단일 채널용 읽기 이벤트를 생성한다.

ㆍ SimEvent makeReadDomainEvent(SimEvent::Domain_t, SimEvent::LocalCode _t): 이 메쏘드는, 특정 도메인용 비동기화 이벤트를 생성한다.

ㆍ SimEvent makeWriteEvent(SimEvent::LocalCode_t): 이 메쏘드는, 모듈의 모든 채널용 쓰기 이벤트를 생성한다.

ㆍ SimEvent makeWriteEvent(SimChanID::Index_t, SimEvent::LocalCode_t): 이 메쏘드는, 단일 채널용 쓰기 이벤트를 생성한다.

ㆍ SimEvent makeWriteDomainEvent(SimEvent::Domain_t, SimEvent::LocalCode_t): 이 메쏘드는, 단일 채널용 쓰기 이벤트를 생성한다.

채널 인덱스를 파라미터로서 취하지 않는 기능은, 모든 채널용 이벤트를 생성한다. 사용자 특정 채널 인덱스 및 로컬 코드를 파라미터로서 취하는 기능은, 특정 채널용 SimEvents를 생산한다. 인수로서 도메인을 취하는 기능은, 특정 도메인에 속한 채널 그룹에 이용된다.

비동기화 이벤트를 생성하는 메쏘드는 다음을 포함한다:

ㆍ makeAsyncEvent(): 이 메쏘드는, 비동기화 시리얼 넘버(serial-number) 기반 이벤트를 생성하는데 이용된다.

ㆍ makeDomainEvent(): 이 메쏘드는, 특정 채널용 비동기화 도메인-기반 이벤트를 생성하는데 이용된다.

ㆍ makeSysEvent(): 이 메쏘드는,시스템 이벤트를 생성하는데 이용된다.

ㆍ isMyEvent(): 이 메쏘드는, 이벤트의 도메인을 체크한다. 주어진 이벤트가 이벤트 메니저와 같은 도메인에 속해 있는 때에는, 트루를 리턴한다.

일실시예에 의하면, 상술한 구성예에서 세 개의 이벤트 매니저를 생산하는 모듈 개발자가, 이벤트가 어느 도메인에 속할지 결정할 필요가 있다면, 다음 접근 방식이 이용될 것이다.

if (m_ advmgr . isMyEvent ( event ))

{

// an ADVANTEST event

}

else if (m_ msomgr . isMyEvent ( event ))

{

// an MSO event

}

else if (m_ pwrmgr . isMyEvent ( event ))

{

// a power event

}

SimEvent 클래스 506은, 다음 메쏘드를 포함한다.

ㆍ isChannelEvent(): 이 메쏘드는, 이벤트가 단일 채널용인지를 체크한다. 메쏘드는, 이벤트가 채널-기반 이벤트라면, 트루를 리턴한다.

ㆍ isDomainEvent(): 이 메쏘드는, 이벤트가 도메인용인지를 체크한다. 메쏘드는, 이벤트가 도메인-기반 이벤트라면, 트루를 리턴한다.

ㆍ isReadEvent(): 이 메쏘드는, 객체가 읽기 이벤트인지를 체크한다. 메쏘드는, 이벤트가 읽기 이벤트라면, 트루를 리턴한다.

ㆍ isSerialNumberEvent(): 이 메쏘드는, 이벤트가 특정 시리얼 넘버용인지를 체크한다. 메쏘드는, 이벤트가 특정 시리얼 넘버용이라면, 트루를 리턴한다.

ㆍ isSysEvent(): 이 메쏘드는, 객체가 시스템 이벤트인지를 체크한다. 메쏘드는, 이벤트가 시스템 이벤트라면, 트루를 리턴한다.

ㆍ isWriteEvent(): 이 메쏘드는, 객체가 쓰기 이벤트인지를 체크한다. 메쏘드는, 이벤트가 쓰기 이벤트라면, 트루를 리턴한다.

ㆍ getChan(): 이 메쏘드는, SimChanID 객체를 얻는다.

ㆍ getCode(): 이 메쏘드는, 로컬 사용자 코드를 얻는다.

ㆍ getDomain(): 이 메쏘드는 도메인을 얻는데, 이는 이벤트의 도메인 인덱스를 리턴한다.

ㆍ getSerialNumber(): 이 메쏘드는 시리얼 넘버를 얻는다.

ㆍ getSysCode(): 이 메쏘드는, 시스템 이벤트 코드를 얻는다.

ㆍ numArgs(): 메쏘드는, 사용자 인수의 넘버를 리턴한다.

ㆍ popArg(): 이 메쏘드는, 큐(queue)에서 다음 사용자 인수에 액세스한다. 인수는 추가된 것과 같은 순서로 회수된다는 점을 주의해야 한다. 인수가 한번 회수되면, 더 이상 이벤트로부터 이용되지 않는다. numArgs()보다 더 많이 popArg를 호출하는 것은, 버려지는 예외를 가져온다.

ㆍ pushArg(): 이 메쏘드는, 사용자 인수를 추가한다.

구성 파일

시뮬레이션 프레임워크는, 시뮬레이션 구성 파일, 및 오프라인 구성 파일의 두 개의 구성 파일을 이용한다. 시뮬레이션 구성 파일은, 시뮬레이션 중에 테스터 모듈이 이용 가능한 것을 특정한다. 오프라인 구성 파일은, DUT 모델이 로드되는 것과, 테스터에 어떻게 접속되는지를 특정한다.

SimTester 기능이 초기에 시작될 때, 시뮬레이션 구성 파일이 로드된다. 이 파일의 설정은, SimTester 프로세스의 시간동안 유효한 상태로 남아있다. 오프라인 구성 파일은, 사용자의 테스트 플랜의 일부로서 로드된다. 파일명은, 테스트 프로그램 언어(test program language;TPL) 명령 OfflineDef로 특정된다. 이 명령은, 사용자의 테스트 프로그램에서는 어디에서든지 나타날 수 있지만, 전통적으로 다른 하이레벨 명령과 함께 testplan.tpl 파일에 위치한다.

일실시예에 의하면, 샘플 시뮬레이션 구성 파일이 아래에 주어진다. 아래에 나타난 바와 같이, 파일은 계층 블록(hierarchical block)으로 나누어진다. 글로벌 블록(Global block)은, 시스템 광역(system-wide) 파라미터를 포함한다. EMUModule 블록은, 에뮬레이터 모델을 포함하는 DLL을 지명하고, 모델이 로드되는 포트를 특정한다. EMUModule 블록은, 시뮬레이션 프레임워크용 모듈 인터페이스를 포함한다.

# T2000 System Software version of the configuration

Version 0.0.1;

Global

{

InitVoltage 0.5 V; # Required. Initial voltage on all

# wires.

RecoveryRate 2.5 V/ns; # Optional. For drive conflict in

# analog signals.

}

# Module Emulator.

EMUModule "module1" # Module DLL.

{

Waveform # Optional. Resource declaration.

{

Step 1-32, 35; # Step type waveforms on channels 1 thru 32

# channel 35.

Analog 33, 34 # Analog waveform on channels 33 and 34.

}

port 1 # Declares the GBUS port for this module.

{

SerialNumber 1; # Required. Should match setting in Module

# Configuration File.

ProductRevision 1; # Required. Should match setting in Module

# Configuration File.

Params # To be passed to DLL.

{

test "param1";

key "abc";

}

port 8

{

LogicalPort 3; # Optional. Designate Logical Port to use in

# offline configuration file. Default is the

# GBUS port

SerialNumber 2;

ProductRevision 1;

Params # To be passed to DLL

{

test "param1";

key "abc";

}

# Module Emulator

EMUModule "module2"

{

Waveform

{

Step 1-32;

}

Port 2

{

SerialNumber 1;

ProductRevision 1;

}

# Module Emulator

EMUModule "dps"

{

Waveform

{

Slew 1-32 @ 2.0 V/nS; # The slew rate is required for all slewing

# waveforms.

}

Port 4

{

SerialNumber 1;

ProductRevision 1;

}

사용자는, 시뮬레이션에 이용될 DUT 모델을 지명하고, 또한 이 모델이 테스터 리소스에 어떻게 첨부되는지를 나타내기 위해, 오프라인 구성 파일을 공급할 수 있다. 일실시예에 의하면, 샘플 오프라인 구성 파일이 아래에 나타나 있다. PinConnections 블록의 예외와 함께, 이 파일은 시뮬레이션 구성 파일과 유사한 구조를 갖는다는 점을 유의한다. 글로벌 블록은, 시스템 광역 설정을 설명한다. DUTModel 블록은, DUT 모델을 포함하는 DLL을 설명하고, DUT 모델을 로드하기 위해 포트를 특정한다. PinConnections 블록은, 각 핀이 테스터에 어떻게 접속되는지를 나타낸다.

# T2000 Version of the syntax

Version 0.0.1;

Global

{

RegSelect "PatTraceSel"; # Pattern Tracing - Name of OASIS Simulated

# Register Selection File.

}

DUTModle "DUT1Sim"

{

Waveform

{

Step 1-32;

}

DUT 1

{

Params

{

param1Name "param1Value";

param2Name "param2Value";

}

PinConnections

{

L3.1 1 1.0 ns;

L3.2 8 1.0 ns;

L3.3 2 1.0 ns;

L3.4 7 1.0 ns;

L3.5 3 1.0 ns;

L3.6 6 1.0 ns;

L3.7 4 1.0 ns;

L3.8 5 1.0 ns;

L3.9 9 1.0 ns;

L3.10 16 1.0 ns;

L3.11 10 1.0 ns;

L3.12 15 1.0 ns;

L3.13 11 1.0 ns;

L3.14 14 1.0 ns;

L3.15 12 1.0 ns;

L3.16 13 1.0 ns;

}

DUTModel "DUT2Sim"

{

Waveform

{

Slew 1-16 @ 2.0 V/ns;

}

DUT 2

{

Params

{

param1Name "param1Value";

param2Name "param2Value";

}

PinConnections

{

L2.1 1; # no delay specified means a delay of 0

L2.2 2;

L2.3 3;

L2.4 4;

L2.12 5;

L2.13 6;

L2.14 7;

L2.15 8;

}

프레임워크 구성

상술한 바와 같이, 모듈 벤더는 하드웨어 모듈의 에뮬레이션을 공급하도록 요구된다. 이 요구 때문에, 벤더 모듈을 얻는 사용자는, 또한 그 컴포넌트의 에뮬레이션 모듈을 얻는다. 에뮬레이션 모듈은, 시뮬레이션 프레임워크에 의해 로드될 수 있는 모듈을 만드는 인터페이스를 갖는 DLL 타입이 된다. 이것은, 벤더의 DLL에 위치한, 미리 정의된 한 세트의 인터페이스 요구를 통해 특정된다. 에뮬레이션 모듈을 시뮬레이션 프레임워크에 로드하기 위해, 시뮬레이션 구성 파일은, 사용자에 의해 제공되거나, 테스트 시스템에 의해 생성된다. 시뮬레이션 구성 파일은, 로드되는 각 DLL을 열거한다. DLL을 지명하는 것에 더하여, 시뮬레이션 구성 파일은 모의되는 테스트 시스템의 하드웨어 설정에 부합하는 파라미터를 특정한다. 이 것은, 모듈 포트 넘버, 모듈 시리얼 넘버, 채널 넘버, 각 채널의 파형의 형식, 및 시뮬레이션 전반에 걸쳐 이용된 참조 전압, 등을 포함한다. 시뮬레이션 구성 파일은, 시뮬레이션의 결과인 다른 파라미터들을 포함한다. 이것들은, 모듈로부터 DUT 핀으로 채널을 첨부하는데 이용된 논리 참조(logical reference), 및 모듈이 로드될 때 DLL로 지나가는 특정 파라미터를 포함한다.

일실시예에 의하면, 시뮬레이션 매니저는, 시뮬레이션을 구성하기 위해 다음 기능을 수행한다.

ㆍ 시뮬레이션 구성 파일에 의해 지시된 대로 모든 컴포넌트를 로드한다;

ㆍ 다양한 사이트 중에서 컴포넌트와 리소스를 나눈다; 또한

ㆍ 모든 쓰레드에서 패턴 이행을 관리하는 중앙 객체를 제공한다.

또한, 시뮬레이션 매니저는, 다음 기능을 수행하기 위해 구성 파일을 이용한다.

ㆍ 모든 컴포넌트 및 인터페이스 객체를 인스턴스화한다;

ㆍ 구성 파일에 의해 특정된 대로 모든 컴포넌트를 접속한다; 또한

ㆍ 컴포넌트 채널로부터 인터페이스 객체까지 맵핑을 제공한다.

SimMgr의 단지 하나의 인스턴스만이 존재한다는 것을 증명하기 위해서는, SimMgr을 생성할 수 있는 유일한 대중적 메쏘드가 create() 메쏘드라는 점을 유의한다. 매칭(matching) release() 메쏘드는, 시뮬레이션 후에 리소스를 클린업하는데 이용된다. creat() 메소드는, 인수 리스트에서 특정된 시뮬레이션 구성 파일에 시뮬레이션 베이스를 생성한다. 경로(path) 인수는, 시뮬레이션 구성 파일 내로 참조된 다른 텍스트 파일용 베이스 경로를 특정하는데 이용된다. 이 파일들은, 베이스 경로에 대한 경로로서 특정된다.

시뮬레이션 프레임워크가 한번 구성되면, 테스트 프로그램 및 특정될 목표가 되는 DUT 모델을 기다린다. 테스트 프로그램을 로드하기에 앞서, TOS는, 하나 또는 그 이상의 DUT 모델이 특정된 시뮬레이션 프레임워크를 통지한다. 이것은, 오프라인 구성 파일이라 불리는 다른 구성 파일을 통해 행해진다. DUT 모델은, 미리 정의된 일련의 인터페이스 요건을 만족시키는 C/C++로 쓰여진 최종 사용자 공급 DLL 타입이나, 시뮬레이션으로부터 접속을 기다리는 서버에서 운용되는 베릴로그 모델로서 된다. 오프라인 구성 파일은, 로드하기 위해, 하나 또는 그 이상의 DUT 모델 DLLs를 특정한다. 또한, 그 파일은, DUT의 하드웨어 설정에 부합하는 파라미터를 특정한다. 이것은, 파형의 채널과 형식, DUT 핀으로의 논리 테스터 채널의 배선(wiring), 및 그 배선과 관련된 전송 지연을 포함한다. 오프라인 구성 파일은 또한, 시뮬레이션의 결과인 다른 파라미터를 포함한다. 이것들은, DUT 모델을 로드할 때, DLL로 지나간 특정 파라미터를 포함한다. 베릴로그 DUT 모델에 액세스하기 위해, 프레임워크는, 특별한 DUT 모델 DLL을 제공한다. 이 모델은, 특정 베릴로그 모델을 운용하는 프로그램이 운용되는 특정 서버로 접속하도록 구성될 수 있다.

프레임워크 초기화( initialization )

일실시예에 의하면, 시뮬레이션 프레임워크의 초기화는, 다음 과정을 포함한다:

1. 모듈 DLLs를 로드하고, 시뮬레이션 구성 파일에 기초하여 메모리의 모듈 에뮬레이션 객체를 인스턴스화한다;

2. 사용자에 의하여 제공될, (로드될 DUT 모델, 및 어떻게 그것들이 모듈에 접속되는지를 설명하는) 오프라인 구성 파일을 기다린다;

3. 시뮬레이션을 구축하기 위해 양 구성 파일을 다음과 같이 이용한다.

a. 모듈 및 DUTs를 다양한 사이트로 지정하기 위하여, 버스 에뮬레이션을 경유하여 시스템으로 프로그램된 사이트 정보를 이용한다;

b. 모듈을, 특정 사이트 전용인 시뮬레이션 프레임워크의 로드보드 모델로 접속한다; 또한

c. 각 사이트의 DUT 모델을, 로드보드 모델의 대응 사이트로 접속한다.

4. 테스트 플랜이 언로드(unload)될 때, 단계 3에서 생성된 구조를 언로드하고, 다른 오프라인 구성 파일을 기다린다.

프레임워크는, 멀티 쓰레드의 시뮬레이션을 용이하게 하기 위해 퍼사이트 베이시스(per-site basis)의 시뮬레이션을 중단한다. 사이트는, 병행하여 모의될 수 있다. 결과적으로, 미리 정의된 시뮬레이션 사이트에 따라 시뮬레이션을 해체하는 것은, 서로에 대하여 쓰레드-안전(thread-safe)으로 만들고, 수행과 충돌할 수 있는 잠금 메카니즘(locking mechanism)에 대한 요구를 피한다.

구성 데이터를 로드할 때, 시뮬레이션 프레임워크는, 로드보드를 경유한, 시 뮬레이션 프레임워크에 있는 객체로의, 모듈에 있는 각 채널을 위한 접속을 구성함으로써, 시뮬레이션을 구축하기 시작한다. 도 6은, 본 발명의 일실시예에 따라, 에뮬레이션 모듈과 로드보드 모델 사이의 채널을 도시한다. 채널은, 에뮬레이션 모듈 602, 양방향성 인터페이스 모델 604, 및 로드보드 모델 606을 포함한다. 에뮬레이션 모듈 602는, I/O 포트 SimChannelA 603을 포함하고, 또한 유사하게 로드보드 모델은, I/O 포트 SimChannel B 607을 포함한다. 양방향성 인터페이스 604 내에는, 에뮬레이션 모듈 602로부터 로드보드 모델 606으로 데이터를 전송하는 SimWaveform A2B 버퍼 608, 및 로드보드 모델 606으로부터 에뮬레이션 모듈 602로 데이터를 전송하는 SimWaveform B2A 버퍼 610의 두 개의 버퍼가 있다. 도 6에 도시된 바와 같이, 에뮬레이션 모듈 602는, SimWaveform A2B 버퍼 608에 쓰고, SimWaveform B2A 버퍼 610으로부터 읽는다. 반면에, 로드보드 모델 606은, SimWaveform B2A 버퍼 610에 쓰고, SimWaveform A2B 버퍼 608로부터 읽는다.

SimWaveform A2B와 SimWaveform B2A 버퍼의 각각은, 채널에 관한 정보를 저장하는 테이블을 포함한다. 특히, 버퍼는, 임의의 시점에 채널 객체로부터 읽은 전압을 저장한다. 테이블 엔트리의 시간 사이에서 읽혀진 채널의 전압값은, 상술한 도 3b에 설명된 여러 표준 모델 중 하나를 이용하여 내삽된다. 특정 채널로 이용하기 위한 모델의 선택은, 사용자가 구성 가능하다. 모델을 교환하는 것은, SimWaveform을 다른 파형 클래스용 베이스 클래스로 만듦으로써 행해진다. SimWaveform은, 주어진 시간의 전압을 리턴하는 가상 기능 read()를 갖는다. 각각의 파생된 클래스는, 모델링되는 파형(예를 들면, SimWaveformStep은 구형파를 모 델링한다)에 따라 read()을 실행한다. 유사한 기술이 윈도우 스트로브를 모델링하는데 이용된다.

도 6에 도시된 바와 같이, DUT 모델 612는, 로드보드에 연결된다. 이 접속은, 시뮬레이션 프레임워크의 SimWire 클래스의 인스턴스를 이용함으로써 만들어진다. SimWire 클래스는, 양방향성 인터페이스 객체에서 버퍼로 액세스를 갖는다. SimWire 클래스는, DUT와 모듈 사이에서 드라이브 충돌(drive conflict)을 분석한다. 도 6에서 로드보드 606과 DUT 모델 612 사이의 접속은, 에뮬레이션 모듈 602와 로드보드 606 사이의 접속의 미러 이미지(mirror image)이다. 이 접속의 세부 사항은, 모듈과 로드보드 사이의 접속의 세부사항이 보다 명확하게 나타날 수 있도록, 다이아그램에서 누락되어 있다.

시뮬레이션이 구성된 후, 테스트 프로그램이 로드된다. 이것은, 시스템 버스 디바이스 드라이버로 호출을 만드는 것을 포함한다. 오프라인 모드에서, 하드웨어로의 디바이스 드라이버 액세스는, 사이트 제어기 프로세스가 시뮬레이션 프레임워크 프로세스와 통신하도록 하면서, 공유 메모리 I/O로 전환된다. 두 시뮬레이션 셋업의 유일한 다른 컴포넌트는 디바이스 드라이버에 있기 때문에, 온라인과 오프라인 테스트 시뮬레이션의 동작 사이에는, 고도의 상관 관계가 있다.

프레임워크 이행

테스트 플랜 이행 중에는, 두가지 타입의 시뮬레이션 운용이 있다. 첫번째는 이벤트-기반 시뮬레이션이다. 모의되는 컴포넌트는, 보통 에뮬레이션 모듈이다. 이 컴포넌트는, 시뮬레이션이 시작하기 전에 그들의 동작이 테스트 프로그램 에 의해 특정되기 때문에, 본직적으로 이벤트-기반이다. 시뮬레이션의 다른 타입은, 시간-기반 시뮬레이션이다. 모의되는 컴포넌트는, 보통 DUT 모델이다. 이 컴포넌트는, 그들의 상태가 외부 자극 및 현재의 내부 상태에 기초하여 앞으로 전파되기 때문에, 본질적으로 시간-기반이다. 시뮬레이션 프레임워크는, 이행 및 이벤트-기반과 시간-기반 시뮬레이션 사이의 데이터 전송을 조정한다.

이벤트-기반 시뮬레이션은, 기록 및 처리 프로세스를 이용한다. 전형적으로 에뮬레이션 모듈인 시뮬레이션 컴포넌트는, 각 시뮬레이션 이벤트에 대해 기록될 필요가 있다. 기록 후, 테스트 이벤트의 조건이 생성할 때, 적절한 시뮬레이션 과정이 이행되도록 하면서, 컴포넌트의 이벤트 핸들러 콜백이 불려 내어진다.

시간-기반 시뮬레이션은, 이벤트-기반 컴포넌트의 출력에 의존한다. 시뮬레이션 프레임워크는, 시간-기반 컴포넌트를 공급하는 모든 채널용 이벤트-기반 컴포넌트에 의해 생성된 자극을 포착하는 타임 윈도우를 계산한다. 다음으로 시간-기반 컴포넌트는, 계산된 타임 윈도우와 함께 호출된다. 이벤트-기반 컴포넌트로부터 시간-기반 컴포넌트로 보내진 데이터는, 안정적일 필요가 있다. 이 안정성의 기준은, 출력 채널에 쓸 때, 일련의 소정의 타이밍 요건을 만족시키는 이벤트-기반 컴포넌트를 가짐으로써 강화된다.

시뮬레이션 프레임워크는, 에뮬레이션 모듈과 DUT 모델 사이의 드라이브 충돌의 자동 분석을 제공한다. 드라이브 충돌은, 전형적으로 테스트 프로그램의 타이밍 에러에 의해 유발된다. 실제 하드웨어에서 일어나기 전에 이 에러를 확인하는 것은, 그렇게 하는 것이 DUT와 테스트 장비 모두에 대한 손상을 피할 수 있기 때문에 중요하다. 로드보드 모델의 SimWire 객체는, 드라이브 충돌을 분석한다. SimWire의 양측 모두의 컴포넌트가 입력을 수취한 후, 시뮬레이션 프레임워크는, 양측으로부터의 신호를 분석하기 위하여 SimWire 객체를 호출한다. 만일 한 채널만이 드라이브 입력을 갖는다면, 적절한 전송 지연이 적용되면서, 그것이 다른 채널로 복사된다. SimWire 객체로의 다측이 드라이브 입력을 수취한다면, 다음으로 출력 버퍼의 전압은 이 충돌을 반영하도록 설정된다. 출력 버퍼들이 한번 설정되면, 그들로부터 읽기 위해 기록된 모듈이 호출된다. 다음으로 분석된 전압 데이터가 액세스된다. 전압 분석이 SImeWire 객체에 캡슐화되기 때문에, 그 프로세스는 시뮬레이션의 나머지에 투과성이 있다.

모듈식 테스트 시스템을 모의하는 개시된 방법에 의해, 많은 이점이 달성된다. 첫째, 개시된 방법은, 테스트 프로그램의 정확하고 상세한 시뮬레이션을 제공함으로써, 기술자들로 하여금, 비싼 테스터 장비에서와는 대조적으로 그들 자신의 워크스테이션의 테스트 프로그램을 개발할 수 있도록 한다. 둘째, 개시된 방법은, 테스트 장비상에서 운용되기 전에 테스트 프로그램, 에뮬레이션 모듈, 및 DUT 모델의 문제를 확인하고, 그에 의해 그러한 문제들이 보다 일찍 해결되도록 한다. 셋째, 개시된 방법은, DUTs의 시장에, 보다 짧은 테스트 프로그램 개발 사이클 및 보다 빠른 시간을 가능하게 하는 병행 개발 모델을 지원한다.

본 발명의 기술 분야의 당업자는, 기초가 되는 동일한 기본 메카니즘 및 방법론을 여전히 채용하면서, 개시된 실시예의 많은 가능한 수정 및 조합이 이용될 수 있다고 인식할 것이다. 상기의 기술(技術)은, 설명을 목적으로, 특정 실시예를 참조하여 쓰여졌다. 그러나, 상술한 예시적 설명은, 완벽한 것으로, 또는 본 발명을 개시된 정확한 타입으로 한정하기 위해 의도된 것이 아니다. 상술한 내용에 비추어 많은 수정 및 변형이 가능하다. 본 발명의 원리 및 실제 적용 분야를 설명하기 위해, 또한 본 발명의 기술 분야의 당업자로 하여금, 본 발명, 및 고려된 특정 이용에 적합한 다양한 수정이 이루어진 다양한 실시예를 가장 잘 활용할 수 있도록 하기 위하여, 실시예들이 선택되고 설명되었다.

Claims

모듈식 테스트 시스템을 모의하는(simulating) 방법에 있어서,

하나 이상의 벤더 모듈(vendor module) 및 그에 대응하는 피시험 디바이스(DUT) 모델을 제어하는 제어기를 제공하는 단계;

상기 하나 이상의 벤더 모듈과 그에 대응하는 DUT 모델 사이에서 표준 인터페이스를 확립하는 시뮬레이션 프레임워크(simulation framework)를 생성하는 단계;

상기 시뮬레이션 프레임워크를 구성하는(configuring) 단계; 및

상기 시뮬레이션 프레임워크를 이용하여 상기 모듈식 테스트 시스템을 모의하는 단계를 포함하는 방법.
제1항에 있어서,

시뮬레이션 프레임워크를 생성하는 단계는,

상기 벤더 모듈과 상기 모듈식 테스트 시스템 사이의 통신을 처리하는 벤더 모듈 인터페이스를 생성하는 단계; 및

DUT 모델과 상기 벤더 모듈 사이의 통신을 처리하는 DUT 모델 인터페이스를 생성하는 단계를 포함하는 방법.
제2항에 있어서,

상기 벤더 모듈 인터페이스를 생성하는 단계는,

제1 세트의 소정의 표준 인터페이스에 따라 상기 벤더 모듈을 실행하는 단계; 및

상기 벤더 모듈의 동작을 모델링하는 가상 기능(virtual function)을 실행하는 단계를 포함하는 방법.
제2항에 있어서,

상기 DUT 모델 인터페이스를 생성하는 단계는,

제2 세트의 소정의 표준 인터페이스에 따라 상기 DUT 모델을 실행하는 단계; 및

상기 DUT 모델의 동작을 모델링하는 가상 기능을 실행하는 단계를 포함하는 방법.
제2항에 있어서,

시뮬레이션 프레임워크를 생성하는 단계는,

상기 벤더 모듈 및 상기 DUT 모델의 출력 채널의 동적 전압 레벨을 설정하는 공통 인터페이스를 제공하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 시뮬레이션 프레임워크를 구성하는 단계는,

시뮬레이션 구성 파일(simulation configuration file;SCF)를 생성하는 단계; 및

상기 시뮬레이션 구성 파일을 상기 모듈식 테스트 시스템으로 로드(load)하는 단계를 포함하는 방법.
제6항에 있어서,

상기 시뮬레이션 구성 파일은,

하나 또는 그 이상의 벤더 모듈 DLLs;

상기 모듈식 테스트 시스템의 하드웨어 설정(setting); 및

시뮬레이션 파라미터(parameters)를 포함하는 방법.
제6항에 있어서,

상기 시뮬레이션 프레임워크를 구성하는 단계는,

오프라인 구성 파일을 생성하는 단계; 및

상기 오프라인 구성 파일을 상기 모듈식 테스트 시스템으로 로드하는 단계를 포함하는 방법.
제8항에 있어서,

상기 오프라인 구성 파일은,

하나 또는 그 이상의 DUT 모델 DLLs;

상기 DUTs의 하드웨어 설정; 및

오프라인 시뮬레이션 파라미터를 포함하는 방법.
제8항에 있어서,

상기 시뮬레이션 프레임워크를 구성하는 단계는,

벤더 모듈 DLLs를 로드하는 단계;

상기 오프라인 구성 파일을 수취하는 단계; 및

상기 시뮬레이션 구성 파일 및 상기 오프라인 구성 파일에 따라 시뮬레이션 구조를 구축하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

상기 벤더 모듈의 이벤트-기반 시뮬레이션을 수행하는 단계;

상기 DUT 모델의 시간-기반 시뮬레이션을 수행하는 단계; 및

상기 이벤트-기반 시뮬레이션과 시간-기반 시뮬레이션 사이에서 시뮬레이션 데이터를 전송하는 단계를 포함하는 방법.
제11항에 있어서,

시뮬레이션 데이터를 전송하는 단계는,

시뮬레이션 중에, 벤더 모듈과 상기 DUT 모델 사이에서 드라이브 충돌(drive conflict)을 자동으로 분석하는 단계를 포함하는 방법.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

복수의 DUT 모델을 병행하여 시험하는 단계를 포함하는 방법.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으로 하나 또는 그 이상의 벤더 모듈을 추가하는 단계를 포함하는 방법.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으로부터 하나 또는 그 이상의 벤더 모듈을 제거하는 단계를 포함하는 방법.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으로 하나 또는 그 이상의 DUT 모델을 추가하는 단계를 포함한다.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으 로부터 하나 또는 그 이상의 DUT 모델을 제거하는 단계를 포함하는 방법.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

운용 시뮬레이션을 중단하지 않고, 상기 모듈식 테스트 시스템으로 하나 또는 그 이상의 DUT 모델을 추가하는 단계를 포함하는 방법.
제1항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 단계는,

운용 시뮬레이션을 중단하지 않고, 상기 모듈식 테스트 시스템으로부터 하나 또는 그 이상의 DUT 모델을 제거하는 단계를 포함하는 방법.
모듈식 테스트 시스템에 있어서,

하나 또는 그 이상의 벤더 모듈;

하나 또는 그 이상의 피시험 디바이스(DUT) 모델;

상기 벤더 모듈 및 그에 대응하는 DUT 모델을 제어하는 제어기;

상기 벤더 모듈과 상기 DUT 모델 사이에서 표준 인터페이스를 확립하는 시뮬 레이션 프레임워크;

상기 시뮬레이션 프레임워크를 구성하는 수단; 및

상기 시뮬레이션 프레임워크를 이용하여 상기 모듈식 테스트 시스템을 모의하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 시뮬레이션 프레임워크는,

벤더 모듈과 상기 모듈식 테스트 시스템 사이의 통신을 처리하는 벤더 모듈 인터페이스; 및

DUT 모델과 상기 벤더 모듈 사이의 통신을 처리하는 DUT 모델 인터페이스를 포함하는 시스템.
제21항에 있어서,

상기 벤더 모듈 인터페이스는,

제1 세트의 소정의 표준 인터페이스에 따라 실행되는 벤더 모듈; 및

상기 벤더 모듈의 동작을 모델링하는 가상 기능을 포함하는 시스템.
제21항에 있어서,

상기 DUT 모델 인터페이스는,

제2 세트의 소정의 표준 인터페이스에 따라 실행되는 DUT 모델; 및

상기 DUT 모델의 동작을 모델링하는 가상 기능을 포함하는 시스템.
제21항에 있어서,

상기 시뮬레이션 프레임워크는,

상기 벤더 모듈 및 상기 DUT 모델의 출력 채널의 동적 전압 레벨을 설정하는 공통 인터페이스를 더 포함하는 시스템.
제20항에 있어서,

상기 시뮬레이션 프레임워크를 구성하는 상기 수단은,

시뮬레이션 구성 파일(SCF)을 생성하는 수단; 및

상기 모듈식 테스트 시스템으로 상기 시뮬레이션 구성 파일을 로드하는 수단을 포함하는 시스템.
제25항에 있어서,

상기 시뮬레이션 구성 파일은,

하나 또는 그 이상의 벤더 모듈 DLLs;

상기 모듈식 테스트 시스템의 하드웨어 설정; 및

시뮬레이션 파라미터를 포함하는 시스템.
제25항에 있어서,

상기 시뮬레이션 프레임워크를 구성하는 상기 수단은,

오프라인 구성 파일을 생성하는 수단; 및

상기 모듈식 테스트 시스템으로 상기 오프라인 구성 파일을 로드하는 수단을 포함하는 시스템.
제27항에 있어서,

상기 오프라인 구성 파일은,

하나 또는 그 이상의 DUT 모델 DLLs;

상기 DUTs의 하드웨어 설정; 및

오프라인 시뮬레이션 파라미터를 포함하는 시스템.
제27항에 있어서,

상기 시뮬레이션 프레임워크를 구성하는 상기 수단은,

벤더 모듈 DLLs를 로드하는 수단;

상기 오프라인 구성 파일을 수취하는 수단; 및

상기 시뮬레이션 구성 파일 및 상기 오프라인 구성 파일에 따라 시뮬레이션 구조를 구축하는 수단을 더 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 상기 수단은,

상기 벤더 모듈의 이벤트-기반 시뮬레이션을 수행하는 수단;

상기 DUT 모델의 시간-기반 시뮬레이션을 수행하는 수단; 및

상기 이벤트-기반 시뮬레이션과 상기 시간-기반 시뮬레이션 사이에서 시뮬레이션 데이터를 전송하는 수단을 포함하는 시스템.
제30항에 있어서,

상기 시뮬레이션 데이터를 전송하는 수단은,

시뮬레이션 중에, 벤더 모듈과 상기 DUT 모델 사이에서 드라이브 충돌을 자동으로 분석하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 상기 수단은,

복수의 DUT 모델을 병행하여 시험하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 수단은,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으로 하나 또는 그 이상의 벤더 모듈을 추가하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 상기 수단은,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으로부터 하나 또는 그 이상의 벤더 모듈을 제거하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 상기 수단은,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으로 하나 또는 그 이상의 DUT 모델을 추가하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 수단은,

상기 시뮬레이션 프레임워크를 변경하지 않고, 상기 모듈식 테스트 시스템으로부터 하나 또는 그 이상의 DUT 모델을 제거하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 수단은,

운용 시뮬레이션을 중단하지 않고, 상기 모듈식 테스트 시스템으로 하나 또는 그 이상의 DUT 모델을 추가하는 수단을 포함하는 시스템.
제20항에 있어서,

상기 모듈식 테스트 시스템을 모의하는 수단은,

운용 시뮬레이션을 중단하지 않고, 상기 모듈식 테스트 시스템으로부터 하나 또는 그 이상의 DUT 모델을 제거하는 수단을 포함하는 시스템.