KR20050099626A

KR20050099626A - 집적 회로의 시험 방법 및 그 장치

Info

Publication number: KR20050099626A
Application number: KR1020057015017A
Authority: KR
Inventors: 안칸 프라마닉; 마크 엘스톤; 레온 첸; 로버트 사우어
Original assignee: 주식회사 아도반테스토
Priority date: 2003-02-14
Filing date: 2004-02-16
Publication date: 2005-10-14
Also published as: JP2007052028A; TWI344595B; EP1592975B1; DE602004011320D1; JP2006520947A; JP3954639B2; WO2004072669A1; DE602004011320T2; ATE384269T1; CN1784609A; JP2006518460A; WO2004072670A1; CN1784609B; TW200508855A; KR20050101216A; EP1592975A1; EP1592976A1; JP3939336B2; EP1592976B1

Abstract

자동화된 시험 장비(ATE)와 같은 반도체 시험 시스템을 위한 분산형 운영 체계가 개시된다. 상기 운영 체계는, 시스템 제어기에 의하여 하나 또는 그 이상의 사이트 제어기의 제어를 가능하게 하기 위한 호스트 운영 체계를 포함한다. 각각이 사이트 제어기와 관련된 하나 또는 그 이상의 지역 운영 체계는 관련된 사이트 제어기에 의하여 하나 또는 그 이상의 시험 모듈의 제어를 가능하게 한다. 각 시험 모듈은 시험 사이트에서 대응되는 피시험 장치에 대하여 시험을 수행한다.

Description

집적 회로의 시험 방법 및 그 장치{METHOD AND APPARATUS FOR TESTING INTEGREATED CIRCUITS}

본 출원은 2003.2.24.자 미국 출원 제60/449,622호 "집적 회로를 시험하기 위한 방법 및 장치"; 2003.2.14.자 미국 출원 제60/447,839호 "반도체 집적 회로를 위한 시험 프로그램 개발 방법 및 구조"; 2003.3.31.자 미국 출원 제10/404,002호 "시험 에뮬레이터, 시험 모듈 에뮬레이터, 및 프로그램을 수록한 기록 매체"; 및 2003.3.31.자 미국 출원 제10/403,817호 "시험 장치 및 시험 방법"의 이익을 주장하며, 이들 모두를 참조에 의하여 본 출원에 편입시킨다. 또한, 본 출원은, 2003.2.14.자 미국 출원 제60/447,839호 "반도체 집적 회로의 시험 프로그램 개발 방법 및 구조"의 우선권을 주장하는 동일자 미국 출원 "반도체 집적 회로의 시험 프로그램 개발 방법 및 구조"의 전체를 참조에 의하여 편입시킨다.

본 발명은 집적 회로(Integrated Circuits; ICs)의 시험에 관한 것이며, 특히 하나 또는 그 이상의 집적 회로를 시험하기 위한 자동 시험 장비(automated test equipment; ATE)에 관한 것이다.

시스템 온 칩(System-on-a-Chip; SOC) 장치의 복잡성과 또한 칩 시험 비용의 감소에 대한 요구가 증가함에 따라, IC 제조자들과 테스터 공급자들은 IC 시험의 수행 방법에 관하여 다시 생각하게 되었다. 관련 산업에 대한 연구에 의하면, 리엔지니어링(re-engineering) 없이는 가까운 미래에 테스터의 예상 비용이 극적으로 지속 증가할 것이라고 한다.

시험 장비의 높은 비용에 대한 주요 원인으로서는, 통상적인 테스터의 구조가 가진 전문성을 들 수 있다. 각 테스터 제조자들은, 예를 들어 아도반테스트, 테러다인 및 에질런트와 같은 회사들 사이에 상호 비호환적(incompatible)일 뿐만 아니라, 아도반테스트에 의하여 제조된, 예컨대 T3300, T5500 및 T6600 시리즈의 테스터들과 같이 플랫폼들 상호 간에도 비호환적인 다수의 테스터 플랫폼(platform)을 가지고 있다. 이러한 비호환성 때문에, 각 테스터는 다른 테스터에서는 사용될 수 없는 자신만의 전문화된 하드웨어 및 소프트웨어 구성 요소들을 필요로 하게 된다. 게다가, 하나의 테스터로부터 다른 테스터로 시험 프로그램을 이전하기 위하여는 상당한 프로그램 번역(translation) 작업이 요구되며, 제3 공급자에 의한 솔루션이 개발되기도 곤란하다. 하나의 플랫폼을 위해 제3 공급자의 솔루션이 개발되었다 하더라도, 다른 플랫폼으로 이전되거나 재사용될 수 없다. 하나의 플랫폼으로부터 다른 플랫폼으로의 프로그램 번역 처리는 일반적으로 복잡하고 오류를 발생시키기 쉬워, 결과적으로 추가적인 노력과, 시간 및 시험 비용의 증가를 가져 온다.

운영 체계와 시험 분석 도구/응용 프로그램과 같은 테스터 소프트웨어는 호스트 컴퓨터(host computer) 상에서 실행된다. 그 구조의 전용성(dedicated nature) 때문에, 모든 하드웨어와 소프트웨어는 특정의 테스터에 대하여 고정된 구성으로 유지되어야 한다. IC를 시험하기 위하여, 피시험 장치(DUT)의 응답을 수집하고 피시험 장치가 합격 또는 불합격인지를 판단하기 위한 것뿐만 아니라, 시험을 위한 데이터, 신호, 파형 및 전류와 전압 레벨을 정의하기 위한 테스터의 일부 또는 모든 역량을 사용하는 전용 시험 프로그램이 개발된다.

테스터는 다양한 종류의 IC들을 시험할 수 있어야 하기 때문에, 하드웨어 및 소프트웨어 구성 요소들 모두는 광범위한 동작 범위에서 작동하도록 설계된다. 그리하여, 하나의 테스터는 많은 시험 상황에서 사용되지 않을 많은 자원을 포함하게 된다. 동시에, 특정의 IC에 대하여, 상기 테스터는 그 IC에 적합한 가장 바람직한 자원을 제공하지 않을 수도 있다. 예를 들어, 내장형(embeded) 마이크로 제어기(microcontroller), 대형 내장형 DRAM 및 플래시 메모리와 PCI 및 USB와 같은 다양한 기타 코어(core)를 포함하는 복잡한 SoC인 'A'를 시험하는 데에 적합한 로직 테스터는, 내장형 마이크로 제어기와 대형 내장형 DRAM/플래시 메모리 대신에 디지털-아날로그 변환기(DAC)와 시그마-델타 변환기(Sigma-Delta converter)를 포함하는 주문형 집적회로(ASIC)인 'B'에 대하여는 적합하지 않은 것으로 밝혀질 수도 있다. 상기 ASIC인 B를 시험하기에 적합한 테스터는, 내장형 메모리의 시험을 위한 강력한 지원보다는 아날로그 및 복합 신호 시험 유닛을 더 필요로 할 것이다.

따라서, 시험 요건에 따라 재구성될 수 있는 테스터를 제공하는 것이 바람직하다. 또한, 다른 공급자의 장비를 ATE와 연결하여 사용하는 것이 바람직하다. 그러나 통상적인 시험 시스템의 전문화된 특성과 각 공급자의 장비가 갖는 데이터 포맷의 전유물적 특성에 의하여, 다른 공급자의 장비를 끼워 넣거나 사용하는 것은 종종 불가능하다.

도 1은, 통상적인 테스터 구조를 도시한다.

도 2는, 본 발명의 일 실시예에 의한 시스템 구조를 도시한다.

도 3은, 본 발명의 일 실시예에 의한 소프트웨어 구조를 도시한다.

도 4는, 본 발명의 일 실시예에 의한 시험 클래스의 사용을 도시한다.

도 5는, 본 발명의 일 실시예에 의한 테스터 시스템과 공급자 제공 모듈 자원의 상호 작용을 도시한 단일 모델링 언어(Unified Modeling Language; UML) 도면이다.

도 6은, 사이트 제어기에 의하여 유지되는 사용자의 시험을 관리하기 위한 사이트 제어기 객체(site controller object)의 일 실시예를 도시한다.

도 7은, 시스템 제어기 측에서 대용하는 것으로서, 도 6에 도시된 사이트 제어기 객체를 나타내는 객체의 일 실시예를 도시한다.

도 8은, 본 발명의 일 실시예에 의한 시험 환경을 도시한다.

본 발명의 일 실시예에 의한 개방형 구조(open architecture)의 시험 시스템에 의하면 제3 공급자의 모듈을 사용할 수 있게 된다. 상기 시험 시스템의 하드웨어 및 소프트웨어의 프레임워크(framework)는 서로 다른 공급자로부터의 모듈들이 플러그 앤 플레이(plug-and-play) 방식으로 상호 작용할 수 있도록 하는 표준 인터페이스(standard interface)를 포함한다. 상기 모듈들은 기능 유닛(functional unit), 디지털 핀 카드(digital pin card), 아날로그 카드(analog card) 또는 장치 전력 공급기(device power supply)와 같은 하드웨어이거나, 또는 시험 수행 도구(test executive tool), 시스템 모니터링 또는 라이센싱 도구(system monitoring or licensing tool)를 포함하는 도구(tool) 또는 유틸리티(utility), 유닛 레벨 제어기(unit-level controller)(예를 들어, 기본 기구(base instrument), GPIB 제어), 데이터베이스와 같은 소프트웨어이거나 또는 다른 장비를 제어하기 위한 소프트웨어일 수도 있다.

본 발명의 일 실시예에 의하면, 상기 구조(architecture)는 마이크로소프트의 윈도우즈 운영 체계 하에서의 분산형 객체 환경(distributed object environment)이다. 상기 테스터는, 제어기와 모듈 간 통신뿐만 아니라, 모듈 간 통신도 허용하는 모듈 제어 소프트웨어 및 백플레인 통신 라이브러리(backplane communication library)를 포함하는 모듈화된 시스템이다. 상기 모듈은, 예를 들어, 디지털 모듈, 장치 전력 공급기(device power-supply; DSP) 모듈, 임의 파형 생성기(arbitrary waveform generator; AWG) 모듈, 디지털화 모듈(digitizer module) 및 특정 응용 소프트웨어(application specific software)를 포함한다.

본 발명의 일 실시예에 의하면, 모듈 접속 가동기(enabler)는, 다중 모듈 접속(multi-module connection) 및 동기화 메카니즘을 제공하는 스위치 매트릭스 네트워크(switch matrix network)를 포함한다. 동일한 타입의 다수의 피시험 장치가 시험 될 때, 이 스위치 매트릭스 네트워크는 다수의 제어기와 테스트 사이트(test site) 사이에 공통 시험 데이터와 자원을 공유할 수 있게도 한다.

사이트마다 독립적인 제어기 때문에, 모든 시험 사이트는 비동기적으로 동작할 수 있다. 이것은 사실상 다수의 피시험 장치의 시험을 가능하게 한다. 이러한 모듈화 및 다수 사이트 구성은 또한 시스템의 신축성(scalability)을 제공한다. 본 발명의 일 실시예에 의한 시스템에 의하면, 단일의 제어기가 다수의 피시험 장치를 제어하고 시험하도록 구성될 수 있다.

플러그 앤 플레이 또는 대체 가능한 모듈이라는 개념은 하드웨어 및 소프트웨어의 모든 레벨에서 표준 인터페이스를 사용함으로써 가능하게 된다. 소프트웨어에서는, 모듈들을 가동(enable)시키고, 활성화(activate)하며, 제어(control)하고 감시(monitor)하기 위하여 프레임워크 클래스(framework class)가 사용된다. 상기 프레임워크는 공통의 시험 관련 동작(test-related operation)을 구현하는 클래스와 메소드(method)의 집합이다. 이것은 전력 공급 및 핀 일렉트로닉스 계열화(power supply and pin electronics sequencing), 전류/전압 레벨 및 타이밍 조건 설정, 측정 획득, 시험 흐름 제어 등을 위한 클래스를 포함한다. 상기 프레임워크는 또한, 실행 시간 서비스(runtime service) 및 디버깅(debugging)을 위한 메소드도 제공한다. 프레임워크 객체는 본 발명의 일 실시예에 따라 표준 인터페이스를 구현하는 동안 작업할 수도 있다. 상기 프레임워크 클래스의 C++ 기반 참조 구현(C++-based reference implementation)이 제공된다. 사용자도 또한 자신만의 특별한 프레임워크 클래스를 개발할 수 있다.

하드웨어-소프트웨어 사이의 인터페이스와 통신은 백플레인 통신 라이브러리를 통하여 획득될 수 있다. C++ 언어 기반 시험 프로그램을 통해 억세스되는 개방형 백플레인 통신 라이브러리와 C++ 상층의 GUI 시험 프로그래밍 레이어(GUI test programming layer)는 상기 시험 시스템의 일반화된 사용자 인터페이스를 제공한다. C/C++ 구조를 이용하여 시험 프로그램을 생성하기 위한 메소드는 미국 특허 출원 제60/447,839호에 개시되어 있다. 통신 라이브러리는, 사용자의 응용 프로그램과 시험 프로그램에 대하여 투명한(transparent) 방식으로 사이트와 통신하는 메카니즘을 제공한다. 본질적으로, 상기 백플레인 통신 라이브러리는 테스터의 백플레인(이때, "백플레인"이라는 것은 반드시 물리적인 하드웨어인 것만을 의미하지는 않는 추상적인 의미에서의 뒤판을 의미한다.) 사이에서의 통신을 위한 인터페이스를 제공하며, 그리하여 특정 사이트에 접속된 모듈과 통신하기 위하여 필요한 함수들(functions)을 제공한다. 이러한 라이브러리의 사용으로 인해 모듈 공급자들이 자신의 드라이버(driver)(예컨대, MS 윈도우즈 레벨의 드라이버)를 제작할 필요가 없어진다. 이것은, 공급자의 고유한 모듈 소프트웨어가 대응되는 하드웨어 모듈과 통신하기 위하여 표준 백플레인 드라이버를 사용할 수 있게 한다. 본 발명의 일 실시예에 의하면, 상기 백플레인 통신 프로토콜은 패킷 기반 포맷(packet based format)을 사용한다.

개방형 구조의 이점 중 하나는, 전반적인 테스터의 활용을 단순화한다는 것이다. 그것은 제3 공급자의 솔루션을 개발하고 주요한 재작업 없이도 이들 솔루션을 다시 사용할 수 있는 메카니즘을 제공한다. 어떠한 주어진 테스트 사이트에 대하여도 희망에 따라 적합한 모듈을 선택하고 사용할 수 있다. 모듈들은 대체 가능하기 때문에, 피시험 장치에 대한 최적의 시험을 성취하기 위하여 각 테스트 사이트를 재구성할 수 있다. 그것은 또한 플랫폼 간 비호환성의 문제를 단순화한다. 이러한 모든 단순화는 노력의 감소, 더욱 빠른 순환 시간(turn-around-time) 및 결과적으로 시험 비용의 감소를 가져 온다.

본 발명은 적어도 하나의 피시험 장치를 시험하기 위한 시스템을 제공한다. 상기 시스템은 적어도 하나의 피시험 장치에 적어도 하나의 시험(시험 계획의 일부일 수 있는)을 적용하기 위한 적어도 하나의 시험 모듈을 제어하기 위한 적어도 하나의 사이트 제어기를 포함한다. 시스템 제어기는 상기 적어도 하나의 사이트 제어기를 제어한다.

시험 모듈 인터페이스는 사이트 제어기를 제1 시험 모듈과 인터페이스하기 위한 시험 모듈 함수들을 정의하며, 여기서 확장되지 않은 시험 모듈 인터페이스는 상기 사이트 제어기를 상기 제2 시험 모듈과 인터페이스하기에 충분치 못하므로, 상기 테스트 모듈 인터페이스는 상기 사이트 제어기를 제2 테스트 모듈과 인터페이스하도록 확장 가능하다.

상기 시스템은 또한, 사용자 정의 가능 시험 클래스(user-definable test class)와 같은 확장 가능한 시험 함수(test function)로서, 피시험 장치에 특유한 특성으로부터 독립적인 시험 함수를 포함한다. 시험은 상기 확장 가능한 시험 함수의 구현(implementation)이다.

시험 모듈은 테스터 핀 인터페이스를 사용하여 피시험 장치와 통신할 수 있으며, 상기 테스터 핀 인터페이스는 피시험 장치에 특유한 특성으로부터 독립적이다. 상기 시험 모듈 인터페이스는 시험 모듈 인터페이스 클래스를 포함할 수 있으며, 상기 테스터 핀 인터페이스는 테스터 핀 인터페이스 클래스를 포함할 수 있다.

본 발명의 일 실시예에 의한 분산형 운영 체계(distributed operating system)는 시스템 제어기에 의한 적어도 하나의 사이트 제어기의 제어를 가능하게 하기 위한 호스트 운영 체계(host operating system)와, 관련된 사이트 제어기에 의한 적어도 하나의 시험 모듈의 제어를 가능하게 하기 위한, 각 사이트 제어기와 관련된 적어도 하나의 지역 운영 체계를 포함한다. 적어도 하나의 시험 모듈은 대응하는 피시험 장치에 대하여 시험을 수행한다.

상기 호스트 운영 체계는, 상기 적어도 하나의 사이트 제어기의 동작을 동기화할 수 있고, 상기 시스템 제어기와 상기 적어도 하나의 사이트 제어기 사이의 통신을 중재할 수 있으며, 상기 적어도 하나의 사이트 제어기의 동작을 감시할 수 있다. 사이트 제어기는 상기 사이트 제어기와 관련된 상기 적어도 하나의 시험 모듈의 동작을 감시할 수도 있다.

상기 호스트 운영 체계는 상기 적어도 하나의 사이트 제어기와 통신하기 위한 적어도 하나의 호스트 인터페이스를 포함한다. 시험 모듈 인터페이스는 사이트 제어기를 제1 시험 모듈과 인터페이스하기 위한 시험 모듈 함수들을 정의하며, 여기서 확장되지 않은 시험 모듈 인터페이스는 상기 사이트 제어기를 상기 제2 시험 모듈과 인터페이스하기에 충분치 못하므로, 상기 테스트 모듈 인터페이스는 상기 사이트 제어기를 제2 테스트 모듈과 인터페이스하도록 확장 가능하다.

상기 호스트 운영 체계는 적어도 하나의 호스트 프레임워크 클래스(host framework class)를 포함할 수 있으며, 상기 적어도 하나의 호스트 프레임워크 클래스는, 사용자가 상기 적어도 하나의 사이트 제어기를 제어하기 위한 응용 프로그램에 고유한 클래스들을 개발할 수 있도록 하기 위하여 표준 컴퓨터 언어(예컨대 C/C++)로 개발될 수 있다.

각 지역 운영 체계는 적어도 하나의 지역 프레임워크 클래스를 포함할 수 있으며, 상기 적어도 하나의 지역 프레임워크 클래스는, 사용자가 상기 적어도 하나의 시험 모듈을 제어하기 위한 응용 프로그램에 고유한 클래스들을 개발할 수 있도록 하기 위하여 표준 컴퓨터 언어(예컨대 C/C++)로 개발될 수 있다.

각 사이트 제어기에 의하여 제어되는 모듈의 개수는 증감 가능하다. 대응되는 사이트 제어기와 관련된 상기 지역 운영 체계는, 상기 사이트 제어기에 의하여 제어되는 시험 모듈의 형식이 재구성되도록 할 수 있다. 상기 호스트 운영 체계는 상기 시스템 제어기에 의하여 제어되는 사이트 제어기의 개수가 증감 가능하도록 하며, 또한 상기 시험 시스템에 의하여 시험되는 피시험 장치의 개수가 증감 가능하도록 한다.

에뮬레이터(emulator)는, 후보 시험 모듈이 시험 시스템과 호환성을 갖는지를 검증하기 위하여 후보 시험 모듈의 시험 시스템에서의 사용을 모의 실험(simulation) 하여도 좋다.

도 1은, 어떻게 신호가 생성되고 피시험 장치에 인가되는가를 도시하는 통상적인 테스터의 일반적인 구조를 도시한다. 각 피시험 장치의 입력 핀은 시험 데이터를 인가하는 드라이버 2에 접속되며, 한편 각 피시험 장치의 출력 핀은 비교기 4에 접속된다. 대부부의 경우에, 각 테스터 핀(채널)이 입력 핀 또는 출력 핀의 어느 하나로 동작할 수 있도록 3상 드라이버-비교기가 사용된다. 하나의 피시험 장치에 전용인 테스터 핀들은 집합적으로, 관련된 타이밍 생성기 6, 파형 생성기 8, 패턴 메모리 10, 타이밍 데이터 메모리 12, 파형 데이터 메모리 14 및 데이터 전송률(data rate)을 정의하는 블록 16과 함께 작업하는 시험 사이트를 형성한다.

도 2는, 본 발명의 일 실시예에 의한 시스템 구조 100을 도시한다. 시스템 제어기(SysC) 102는 다수의 사이트 제어기(SiteCs) 104와 연결된다. 상기 시스템 제어기는 또한 관련된 파일(file)에 억세스(access)하기 위하여 네트워크에 연결될 수도 있다. 각 사이트 제어기는, 모듈 접속 가동기(module connection enabler) 106을 통해, 시험 사이트 110에 위치한 하나 또는 그 이상의 시험 모듈 108을 제어하기 위하여 연결된다. 상기 모듈 접속 가동기 106은 접속된 하드웨어 모듈 108의 재구성을 가능하게 하며, 또한 (패턴 데이터의 로딩(loading), 응답 데이터의 수집, 제어 공급, 등을 위한) 데이터 전송을 위한 버스로서도 기능한다. 나아가, 상기 모듈 접속 가동기를 통해, 하나의 사이트의 모듈은 다른 사이트의 모듈에 억세스할 수 있다. 상기 모듈 접속 가동기 106은 서로 다른 시험 사이트들이 동일하거나 서로 다른 모듈 구성을 갖도록 한다. 다시 말하면, 각 시험 사이트는 서로 다른 개수와 형식의 모듈들을 채용할 수 있다. 가능한 하드웨어 구현으로서는, 전용 접속, 스위치 접속, 버스 접속, 링(ring) 접속, 및 스타(star) 접속 등이 포함된다. 상기 모듈 접속 가동기 106은, 예를 들어, 스위치 행렬(switch matrix)에 의하여 구현될 수도 있다. 각 시험 사이트 110은 피시험 장치 112와 관련되며, 상기 피시험 장치는 로드 보드(loadboard) 114를 통해 대응되는 사이트의 모듈에 접속된다. 본 발명의 일 실시예에 의하면, 하나의 사이트 제어기는 복수의 피시험 장치 사이트들과 접속될 수 있다.

상기 시스템 제어기 102는 전체적인 시스템 관리자로서 기능한다. 그것은 사이트 제어 활동을 조직하며, 시스템 레벨의 병렬 시험 전략을 운영하며, 또한 추가적으로 시스템 레벨의 데이터 로깅(data-logging) 및 오류 처리 지원과 함께 처리기(handler)/프로브(probe) 제어를 제공한다. 동작 설정(operational setting)에 따라, 상기 시스템 제어기 102는 상기 사이트 제어기 104의 동작과 분리된 CPU에 배치될 수도 있다. 또는, 공통의 CPU를 상기 시스템 제어기 102와 상기 사이트 제어기 104가 공유할 수도 있다. 이와 유사하게, 각 사이트 제어기 104는 그 자신의 전용 CPU(중앙 처리 장치)에 배치되거나, 하나의 CPU 내의 개별 프로세스 또는 쓰레드(thread)로서 배치될 수도 있다.

상기 시스템 구조는, 개별 시스템 구성 요소가 반드시 분산형 시스템의 물리적 구성 요소일 필요는 없으며, 집적된 단일 시스템의 논리적 구성 요소로서 간주될 수도 있다는 이해를 바탕으로, 도 2에 도시된 바와 같은 분산형 시스템으로서 개념적으로 가시화될 수 있다.

도 3은, 본 발명의 일 실시예에 의한 소프트웨어 구조 200을 도시한다. 상기 소프트웨어 구조 200은, 상기 시스템 제어기 220, 적어도 하나의 사이트 제어기 240, 및 관련 하드웨어 시스템 구성 요소 102, 104, 108에 대응되는 적어도 하나의 모듈 260을 포함하는 분산형 운영 체계를 나타낸다. 상기 모듈 260에 추가하여, 상기 구조 200은 소프트웨어 중에 모듈 에뮬레이션 280을 위한 대응되는 구성 요소를 포함한다.

예시적인 선택으로서, 이 플랫폼을 위한 개발 환경은 마이크로소프트의 윈도우즈를 기반으로 할 수 있다. 이러한 구조의 사용으로 인해, 프로그램과 지원 이전성에서 부수적인 이점이 있다(예를 들어, 현장의 서비스 엔지니어는 진보된 진단을 수행하기 위한 테스터 운영 시스템을 실행시키는 노트북 컴퓨터를 접속시킬 수 있다.). 그러나 대규모의 연산 집약적인 동작(예컨대, 시험 패턴 컴파일(compile)과 같은)을 위하여는, 관련 소프트웨어를 분산된 플랫폼들 사이에서 작업 스케줄링(job scheduling)이 가능하도록 독립적으로 실행될 수 있는 독립적 존재로서 제작할 수도 있다. 그리하여, 일괄 작업(batch job)을 위한 관련된 소프트웨어 도구들은 다수의 플랫폼 형식에서 실행될 수 있다.

예시적 선택으로서, ANSI/ISO 표준 C++이 상기 소프트웨어를 위한 네이티브 언어(native language)로서 채택될 수 있다. 물론, 제3 공급자가 자신의 선택에 따라 다른 언어로 상기 시스템에 집적할 수 있게 하는 다수의 선택 사항(공칭 C++ 인터페이스 상층의 레이어를 제공하는)이 존재한다.

도 3은, 상기 테스터 운영 체계 인터페이스 290, (예를 들어, 시험을 목적으로 사용자에게 공급되는) 사용자 구성 요소 292, (예를 들어, 기초적 접속성 및 통신을 위한 소프트웨어 인프라스트럭쳐(infrastructure)로서 공급되는) 시스템 구성 요소 294, (예를 들어, 모듈 개발기(module developer)로서 공급되는) 모듈 개발 구성 요소 296, 및 (예를 들어, 모듈 개발자 이외의 외부 소스(external source)로서 공급되는) 외부 구성 요소 298을 포함하는 공칭 소스(nominal source)에 따라 구성 요소의 조직에 의한 음영 처리(shading)를 도시한다.

소스 기반 조직(source-based organization)의 관점에서 볼 때, 상기 테스터 운영 체계(Tester Operating System; TOS) 인터페이스 290은 다음을 포함한다. 즉, 시스템 제어기와 사이트 제어기 간 인터페이스 222, 프레임워크 클래스 224, 사이트 제어기와 모듈 간 인터페이스 245, 프레임워크 클래스 246, 예정된 모듈 레벨 인터페이스, 백플레인 통신 라이브러리 249, 섀시 슬롯 인터페이스(chassis slot IF (Interface)) 262, 로드 보드 하드웨어 인터페이스 264, 백플레인 시뮬레이션 인터페이스 283, 로드보드 시뮬레이션 인터페이스 285, 피시험 장치 시뮬레이션 인터페이스 287, 피시험 장치의 베리로그 모델을 위한 베리로그 프로그래밍 언어 인터페이스(Verilog Programming Language Interface; PLI) 288 및 피시험 장치의 C/C++ 모델을 위한 C/C++ 언어 지원 289가 포함된다.

사용자 구성 요소 292는 다음을 포함한다. 즉, 사용자 시험 계획(user test plan) 242, 사용자 시험 클래스(user test class) 243, 하드웨어 로드보드(hardware loadboard) 265, 피시험 장치 266, 피시험 장치 베리로그 모델 (DUT Verilog model) 293 및 피시험 장치 C/C++ 모델 291을 포함한다.

시스템 구성 요소 294는 다음을 포함한다. 즉, 시스템 도구 226, 통신 라이브러리 230, 시험 클래스 244, 백플레인 드라이버 250, 하드웨어 백플레인 261, 시뮬레이션 프레임워크 281, 백플레인 에뮬레이션 282 및 로드보드 시뮬레이션 286을 포함한다.

모듈-개발 구성 요소 296은 다음을 포함한다. 즉, 모듈 명령 구현(module commands implementation) 248, 모듈 하드웨어 263, 및 모듈 에뮬레이션 284를 포함한다.

외부 구성 요소 298은 외부 도구(external tools) 225를 포함한다.

상기 시스템 제어기 220은 사이트 제어기와의 인터페이스 222, 프레임워크 클래스 224, 시스템 도구 226, 외부 도구 225 및 통신 라이브러리 230을 포함한다. 상기 시스템 제어기 소프트웨어는 사용자를 위한 상호 작용의 제1차 지점이다. 그것은, 본 발명의 사이트 제어기로의 게이트웨이(gateway)와, 본 출원의 출원인에 의한 미국 특허 출원 제60/449,622호에 개시된 다중 사이트/피시험 장치 환경에서의 사이트 제어기의 동기화를 제공한다. 그래픽 사용자 인터페이스 기반 또는 기타의 사용자 응용 프로그램과 도구들은 상기 시스템 제어기 상에서 실행된다. 상기 시스템 제어기는 또한, 시험 계획, 시험 패턴 및 시험 파라미터 파일을 포함하는 모든 시험 계획과 관련된 정보들을 위한 저장고로서 동작할 수도 있다. 시험 파라미터 파일은, 본 발명의 일 실시예에 의한 객체 지향적 환경에서의 시험 클래스를 위한 파라미터화 데이터를 포함한다.

제3 개발자들은 표준 시스템 도구들 226에 추가하여 (또는 그 대신에) 도구들을 제공할 수도 있다. 상기 시스템 제어기 220 상의 상기 표준 인터페이스 222는 상기 도구들이 상기 테스터와 시험 객체에 억세스하기 위하여 사용하는 인터페이스들을 포함한다. 상기 도구들(응용 프로그램들) 225, 226은 상기 시험 및 테스터 객체의 상호 작용적이며 일괄적인 제어를 가능하게 한다. 상기 도구들은 (예를 들어 SECS/TSEM의 사용을 통해) 자동화 기능을 제공하기 위한 응용 프로그램을 포함한다.

상기 시스템 제어기 220 상에 존재하는 상기 통신 라이브러리 230은, 사용자 응용 프로그램과 시험 프로그램에 투명한 방식으로 상기 사이트 제어기 240과 통신할 수 있는 메카니즘을 제공한다.

상기 시스템 제어기 220과 관련된 메모리에 존재하는 상기 인터페이스 222는, 상기 시스템 제어기 상에서 실행되는 프레임워크 객체와의 개방형 인터페이스를 제공한다. 상기 사이트 제어기 기반 모듈 소프트웨어가 패턴 데이터에 억세스하고 추출할 수 있게 하는 인터페이스도 포함된다. 또한, 스크립팅 엔진(scripting engine)을 통해 상기 테스터와 시험 구성 요소에 억세스하고 조작할 수 있는 능력을 제공하는 스크립팅 인터페이스(scripting interface)와 함께, 응용 프로그램과 도구들이 상기 테스터와 시험 객체들에 억세스하기 위하여 사용하는 인터페이스도 포함된다. 이것은 그들의 기능을 수행하기 위한 상호작용적이고, 일괄적이며 원격적인 응용 프로그램을 위한 공통의 메카니즘을 가능하게 한다.

상기 시스템 제어기 220과 관련된 상기 프레임워크 클래스 224는, 표준 인터페이스의 참조 구현(reference implementation)을 제공하면서 상기한 객체들과의 상호작용을 위한 메카니즘을 제공한다. 예를 들어, 본 발명의 상기 사이트 제어기 240은 기능적 시험 객체(functional test object)를 제공한다. 상기 시스템 제어기 프레임워크 클래스는 상기 기능적 시험 객체의 원격 시스템 제어기 기반 대행자(remote system controller-based surrogate)로서 대응하는 기능적 시험 프록시(functional test proxy)를 제공한다. 따라서, 상기 표준 기능적 시험 인터페이스는 시스템 제어기 220 상의 도구들에게 이용 가능하게 된다. 상기 시스템, 모듈 개발 및 인터페이스 구성 요소 294, 296 및 290은 각각, 상기 시스템 제어기와 상기 사이트 제어기 사이에 분산된 운영 체계로서 고려될 수도 있다. 상기 프레임워크 클래스는 상기 호스트 시스템 제어기와 관련된 운영 체계 인터페이스를 효과적으로 제공한다. 그것은 또한, 상기 사이트 제어기로의 게이트웨이를 제공하는 소프트웨어 요소를 구성하며, 또한 다중 사이트/피시험 장치 환경에서의 상기 사이트 제어기와의 동기(synchronization)를 제공한다. 따라서, 이 계층(layer)은, 상기 통신 계층을 직접 다룰 필요 없이 사이트 제어기를 조작하고 그에 억세스하기에 적합한 본 발명의 일 실시예에 의한 객체 모델을 제공한다.

상기 사이트 제어기 240은, 사용자 시험 계획 242, 사용자 시험 클래스 243, 표준 시험 클래스 244, 표준 인터페이스 245, 사이트 제어기 프레임워크 클래스 246, 모듈 고레벨 명령 인터페이스(module high level command interface)(예를 들어, 예정된 모듈 레벨 인터페이스) 247, 모듈 명령 구현 248, 백플레인 통신 라이브러리 249, 및 백플레인 드라이버 250을 주재한다(host). 바람직하게, 대부분의 시험 기능성은 상기 사이트 제어기 104/240에 의하여 처리되며, 그리하여 상기 시험 사이트 110의 독립적인 동작이 가능하게 된다.

시험 계획 242는 사용자에 의하여 작성된다. 상기 계획은, C++과 같은 표준 컴퓨터 언어로 직접 작성될 수도 있고, C++ 코드를 생성할 수 있는 보다 상위 레벨의 시험 프로그래밍 언어로 기술되어 실행가능한 시험 프로그램으로 컴파일될 수도 있다.

상기 시험 계획은, 상기 프레임워크 클래스 246 및/또는 상기 사이트 제어기에 관련된 표준 또는 사용자 공급 시험 클래스 244를 이용함으로써 시험 객체를 창출하고, 상기 표준 인터페이스 245를 사용하여 하드웨어를 구성하며, 상기 시험 계획 흐름을 정의한다. 그것은 또한, 상기 시험 계획을 실행하는 동안 필요한 임의의 추가적인 로직(logic)도 제공한다. 상기 시험 계획은 소정의 기초적 서비스를 지원하며, 디버그 서비스(예컨대, 브레이크-포인팅(break-pointing))과 같은 기초적 객체들(underlying objects)의 서비스로의 인터페이스와, 기초적 프레임워크(underlying framework)와 표준 클래스로의 억세스를 제공한다.

상기 사이트 제어기와 관련된 상기 프레임워크 클래스 246은, 공통의 시험 관련 동작을 구현하는 클래스들과 메소드들의 집합이다. 상기 사이트 제어기 레벨 프레임워크는, 예를 들어 전력 공급 및 핀 일렉트로닉스 계열화, 레벨 및 타이밍 조건 설정, 측정 획득, 시험 흐름 제어 등을 위한 클래스를 포함한다. 상기 프레임워크는 또한, 실행 시간 서비스(runtime service) 및 디버깅(debugging)을 위한 메소드도 제공한다. 상기 프레임워크 객체는 표준 인터페이스의 구현을 통해 작업할 수도 있다. 예를 들어, 상기 테스터 핀 프레임워크 클래스의 구현은, 시험 클래스가 하드웨어 모듈 핀과 상호작용하기 위하여 사용할 수도 있는 일반적인 테스터 핀 인터페이스를 구현하도록 표준화된다.

특정의 프레임워크 객체는, 상기 모듈들과 통신하기 위하여, 상기 모듈 레벨 인터페이스 247의 도움을 받아 작업하도록 구현될 수도 있다. 상기 사이트 제어기 프레임워크 클래스는, 각 사이트 제어기를 지원하는 지역 운영 체계 인터페이스로서 효과적으로 동작할 수 있다.

일반적으로, 90퍼센트 이상의 프로그램 코드가 장치 시험을 위한 데이터이며, 나머지 10퍼센트의 코드가 시험 방법론을 실체화한다. 상기 장치 시험 데이터는 피시험 장치에 의존된다(예를 들어, 전력 공급 조건, 신호 전압 조건, 타이밍 조건, 등). 상기 시험 코드는, 특정의 장치 조건을 ATE 하드웨어에 로드(load)하는 메소드와, 사용자에 특정한 객체들(예컨대, 데이터 로깅(data logging))을 실체화하는데 필요한 것들로 이루어진다. 본 발명의 일 실시예에 의한 프레임워크는, 하드웨어에 독립적인 시험과, 사용자가 피시험 장치 시험 프로그래밍의 작업을 수행할 수 있도록 하는 테스터 객체 모델을 제공한다.

시험 코드의 재사용 가능성을 증대시키기 위하여, 상기 코드는, 어떠한 장치 특유적 데이터(예컨대, 핀 명칭, 자극 데이터(stimulus data), 등) 또는 장치-시험 특유적 데이터(예컨대, DC 유닛을 위한 조건들, 측정 핀들, 목표 핀의 개수, 패턴 파일의 명칭, 패턴 프로그램의 어드레스)로부터도 독립적으로 만들어질 수 있다. 만약 시험을 위한 코드가 이러한 형식의 데이터와 함께 컴파일된다면, 상기 시험 코드의 재사용 가능성은 감소될 것이다. 따라서, 본 발명의 일 실시예에 의하면, 어떠한 장치 특유적 데이터 또는 장치-시험 특유적 데이터도, 코드의 실행 시간 동안의 입력으로서, 상기 시험 코드가 외부적으로 활용할 수 있도록 만들어질 수 있다.

본 발명의 일 실시예에 의하면, 본 명세서에서 'ITest'로 표기되는 것으로서, 표준 시험 인터페이스의 구현인 시험 클래스(Test Class)는 특정 형식의 시험을 위하여 시험과 코드의 구별(따라서, 코드의 재사용 가능성)을 실현한다. 이러한 시험 클래스는 그 자신의 별도의 인스턴스(instance)를 위한 템플리트(template)로서 간주될 수도 있으며, 상기 인스턴스들은 상호 간에 단지 장치 특유적 및/또는 장치-시험 특유적 데이터의 기반 상에서만 서로 다르다. 시험 클래스들은 상기 시험 계획 파일에 명기된다. 각 시험 클래스는 전형적으로 특정 형식의 장치 시험 또는 장치 시험을 위한 셋업을 구현한다. 예를 들어, 본 발명의 일시예에 의하면, 피시험 장치의 모든 기능적 시험을 위한 기저 클래스(base class)로서, 예를 들어 기능적 시험(FunctionalTest)와 같은 ITest의 특정적인 구현이 제공된다. 그것은, 시험 조건 설정, 패턴 실행 및 실패한 스트로브(failed strobes)의 존재에 기초한 시험 상태 결정과 같은 기초적인 기능성(basic functionality)을 제공한다. 다른 형식의 구현은, 본 명세서에서 'ACParametricTests' 및 'DCParametricTests'로서 표기되는 AC 및 DC 시험 클래스들을 포함한다.

모든 시험 형식들은 소정의 가상 메소드들(virtual methods)(예컨대, init(), preExec() 및 postExec())의 디폴트 구현들(default implementations)을 제공할 수 있다. 이러한 메소드들은 디폴트 행위(default behavior)의 오버라이드(override) 및 임의의 시험 특유적 파라미터의 설정을 위한 시험 엔지니어의 진입점(entry points)이 된다. 그러나 주문형 시험 클래스들(custom test classes)도 또한 시험 계획에 사용될 수 있다.

시험 클래스에 의하여, 사용자는 특정 시험의 특정 인스턴스를 위한 옵션(opetion)을 지정하는데 사용되는 파라미터들을 제공함으로써 클래스 행위(class behavior)를 구성할 수 있다. 예를 들어, 기능적 시험은, 실행할 패턴 목록을 지정하기 위하여 PList 및 TestConditions이라는 파라미터와, 시험을 위하여 레벨(Level) 및 타이밍 조건(Timing conditions)을 각각 취할 수 있다. (시험 계획 기술 파일에서 서로 다른 "시험" 블록들(blocks)을 사용함으로써) 이러한 파라미터를 위한 서로 다른 값들을 지정함으로써, 사용자는 기능적 시험의 서로 다른 인스턴스를 생성할 수 있다. 도 4는 하나의 시험 클래스로부터 어떻게 서로 다른 시험 인스턴스들이 유도될 수 있는지를 도시한다. 템플리트 라이브러리(Template Library)는 일반 알고리즘 및 데이터 구조(generic algorithm and data structure) 의 범용 라이브러리로(general-purpose library)서 채용될 수 있다. 이 라이브러리는 상기 테스터의 사용자에게 가시적일 수 있으며, 그리하여 상기 사용자는, 예를 들어, 사용자 정의 시험 클래스를 생성하기 위하여 시험 클래스의 구현을 수정할 수도 있다.

사용자 개발 시험 클래스로서, 상기 시스템의 일 실시예는, 모든 시험 클래스들이, 예컨대 ITest와 같은, 하나의 시험 인터페이스로부터 유래한다는 점에서 그러한 시험 클래스들을 상기 프레임워크로서 통합하는 것을 지원하며, 그리하여 상기 프레임워크는 그들을 상기 시스템 시험 클래스들의 표준 세트와 같은 방식으로 조작할 수 있다. 사용자들은, 이러한 추가적인 설비들의 이점을 이용하기 위하여 자신의 시험 프로그램들에 주문형 코드(custom code)를 사용하여야 한다는 점을 이해하면서, 자신의 시험 클래스들에 추가적인 기능성을 자유롭게 편입시킬 수 있다.

각 시험 사이트 110은 하나 또는 그 이상의 피시험 장치 106의 시험 전용이며, 시험 모듈 112의 구성 가능한 집합을 통해 기능한다. 각 시험 모듈 112는 특정 시험 과제를 수행하기 위한 존재(entity)이다. 예를 들어, 시험 모듈 112는 피시험 장치의 전력 공급기, 핀 카드, 아날로그 카드 등의 어느 것일 수 있다. 이러한 모듈식 접근 방법(modular approach)에 의하여 높은 수준의 유연성과 구성 가능성이 제공된다.

모듈 명령 구현 클래스들 248은 모듈 하드웨어 공급자(module hardware vendor)에 의하여 제공될 수 있으며, 공급자에 의하여 선택된 명령 구현 메소드에 따라 하드웨어 모듈들을 위한 모듈 레벨 인터페이스들을 구현하거나, 표준 인터페이스의 모듈 특유 구현을 제공할 수 있다. 이러한 클래스들의 외부 인터페이스들은 예정된 모듈 레벨 인터페이스 요건 및 백플레인 통신 라이브러리 요건에 의하여 정의된다. 이러한 레이어는 또한, 메소드들(함수들)과 데이터 요소들의 추가를 허용하기 위한 시험 명령들의 표준 세트의 확장을 위하여 제공한다.

상기 백플레인 통신 라이브러리 249는, 백플레인 간의 표준 통신을 위한 인터페이스를 제공하며, 그리하여 상기 시험 사이트에 접속된 모듈들과 통신하기 위하여 필요한 기능들을 제공한다. 이것은, 공급자에 특유한 모듈 소프트웨어가 대응하는 하드웨어 모듈들과 통신하기 위하여 백플레인 드라이버 250을 사용할 수 있게 한다. 상기 백플레인 통신 프로토콜은 패킷 기반 포맷(packet based format)을 사용할 수도 있다.

테스터 핀 객체들(Tester Pin objects)은 물리적인 테스터 채널들을 나타내며, 본 명세서에서 'ITesterPin'으로 표기된 테스터 핀 인터페이스(tester pin interface)로부터 유래한다. 본 발명의 일 실시예에 의한 소프트웨어 개발 키트(software development kit; SDK)는, 예정된 모듈 레벨 인터페이스인 IChannel의 형식으로 구현되는 것으로서, 테스터핀(TesterPin)으로 불릴 수도 있는 ITesterPin의 디폴트 구현(default implementation)을 제공한다. 공급자들은 IChannel의 형식으로 그들의 모듈의 기능성을 구현할 수 있다면, 상기 테스터핀을 자유롭게 활용할 수 있으며, 그렇지 않으면 그들은 자신의 모듈과 작업할 수 있도록 ITesterPin의 구현을 제공하여야만 한다.

본 발명의 상기 테스터 시스템에 의하여 제공되는 것으로서, 본 명세서에서 'IMode'로 표기되는 상기 표준 모듈 인터페이스는, 포괄적으로 공급자의 하드웨어 모듈을 나타낸다. 상기 시스템을 위한 공급자 제공 모듈 특유의 소프트웨어는 동적 연결 라이브러리(dynamic link library: DLL)와 같은 실행 가능한(executable) 형식으로 제공될 수 있다. 특정 공급자로부터의 각 모듈 형식을 위한 소프트웨어는 하나의 DLL로 캡슐화(encapsulated)될 수 있다. 그러한 각 소프트웨어 모듈은, 상기 모듈 인터페이스 명령을 위한 공급자 특유의 구현을 제공할 책임이 있으며, 상기 공급자 인터페이스 명령은 모듈 소프트웨어 개발을 위한 API를 포함한다.

상기 모듈 인터페이스 명령에는 두 가지 국면이 존재한다. 즉, 첫째로, 그들은 사용자가 상기 시스템의 특정 하드웨어 모듈과 (간접적으로) 통신하기 위한 인터페이스로서 복무하며, 또한, 둘째로, 그들은 제3 개발자가 자기 자산의 모듈들을 상기 사이트 제어기 레벨 프레임워크로서 통합하기 위하여 이용할 수 있는 인터페이스를 제공한다. 그리하여, 상기 프레임워크에 의하여 제공되는 상기 모듈 인터페이스 명령은 두 개의 형식으로 구분된다. 즉,

첫째로, 그리고 가장 명백하게는, 상기 프레임워크 인터페이스를 통해 상기 사용자에게 노출되는 "명령들(commands)"이다. 그리하여, 예를 들어, 테스터 핀 인터페이스(ITesterPin)는 레벨과 타이밍 값을 취하고 설정할 메소드들을 제공하며, 한편 전력 공급기 인터페이스(IPowerSupply)는 전력을 공급하거나 공급하지 않기 위한 메소드들을 제공한다.

나아가, 상기 프레임워크는 예정된 모듈 레벨 인터페이스의 특별한 카테고리를 제공하며, 상기 예정된 모듈 레벨 인터페이스는 상기 모듈들과 통신하는 데에 사용될 수 있다. 이들은 공급자 모듈들과 통신하기 위하여 프레임워크 클래스들(즉, 프레임워크 인터페이스들의 "표준" 구현)에 의하여 사용되는 인터페이스들이다.

그러나 상기 두 번째 국면, 즉 모듈 레벨 인터페이스의 사용은 선택적이다. 그렇게 하는 것의 이점은, 공급자들이 ITesterPin 및 IPowerSupply와 같은 클래스들의 구현을 이용할 수 있다는 것이다. 그러나 만약 이러한 인터페이스들이 상기 공급자들에게 적적하지 않다면, 그들은 그들의 상기 프레임워크 인터페이스의 주문형 구현(예를 들어, ITesterPin, IPowerSupply, 등의 공급자 구현)을 제공하는 것을 선택할 수도 있다. 그리고나서 이들은 그들의 하드웨어에 적합한 주문형 기능성을 제공할 수 있다.

그리하여, 상기 모듈 특유의 공급자 소프트웨어의 통합은 두 가지 서로 다른 수단에 의하여 성취될 수 있다. 즉, 관련 프레임워크 클래스 및 인터페이스의 주문형 구현, 또는 모듈 레벨 인터페이스의 특별한 카테고리의 주문형 구현이 그것이다.

두 가지 방법의 예시적 응용 프로그램이 도 5의 도움을 받아 다음에 제시되는바, 도 5는, 본 발명의 일 실시예에 의한 테스터 시스템과 공급자 제공 모듈의 상호 작용을 도시한 단일 모델링 언어(Unified Modeling Language; UML) 클래스 도면이다.

새로운 디지털 모듈의 공급자, 즉 제3자 A(Third Party A; TPA)는 그의 하드웨어 모듈과 통신하기 위한 소프트웨어 모듈을 제공한다. 이 소프트웨어 모듈은 상기 표준 인터페이스 IModule을 구현한다. 이 모듈 오브젝트를 'TPAPinModule'이라 칭하자. 상기 공급자 TPA는, 그의 모듈에서, 이 경우에 IChannel인, 관련된 예정 모듈 레벨 인터페이스를 구현함으로써, 본 명세서에서 'TesterPin'으로 표기되는 상기 'ITesterPin' 인터페이스의 표준 시스템 구현을 이용할 수 있다. 이것은, TesterPin이 모듈들과 통신하기 위하여, IChannel과 같은 표준의 예정된 모듈 레벨 인터페이스를 사용한다는 사실에 의하여 가능하게 된다. 따라서, TPAPinModule은 단순히 TesterPin 객체들을 생성하고 노출시킴으로써 핀들을 제공한다.

이제, 다른 공급자, 즉 제3자 B(Third Party B; TPB)를 고려하는데, 상기 TPB는 상기 IChannel 인터페이스가 그의 하드웨어와 잘 동작하지 않는다고 결정한다. 따라서, TPB는 그 자신의 'IModule' 구현(TPBPinModule)뿐만 아니라, 상기 'ITesterPin' 인터페이스, 즉 TPBTesterPin의 구현도 또한 제공할 필요가 있다.

이러한 접근 방식은 제3 개발자에게 그들의 하드웨어와 지원 소프트웨어를 개발하는 방식의 선택에 막대한 유연성을 제공한다. 그들이 상기 IModule 인터페이스를 구현하도록 요구되는 한편, 그들은, 적합해 보이는 바에 따라, 모듈 레벨 인터페이스 또는 'TesterPin'과 같은 객체를 구현할 것인지를 선택할 수 있다.

실제로, 공급자들은 상기 ITesterPin 인터페이스에서 지원되지 않는 확장을 제공하기 위하여 TesterPin을 구현할 것을 선택할 수 있다. 상기 프레임워크는 특정 인터페이스 또는 소정 객체로의 구현 포인터(implementation pointer to an object)를 추출하기 위한 메카니즘을 사용자에게 제공할 것이다. 이것은, 사용자 코드가 ITesterPin 포인터를 가지고 있을 때, 상기 프레임워크는, 필요하다면, 그것이 예컨대 TPBTesterPin 객체를 지시하는지를 결정할 수 있을 것이라는 것을 의미한다. (이러한 특성은 표준 C++ 실행 시간 형식 식별(Run Time Type Identification; RTTI)을 통해 제공될 수 있음을 주의하여야 한다.) 다시 말하면, 상기 시험 계획이 상기 ITesterPin 인터페이스를 요구할 때, 상기 인터페이스는, 차례로, 직접 상기 TesterPin 클래스의 상기 공급자의 테스터 핀 구현을 불러내며, 상기 TesterPin 클래스는 모듈 특유적 정보(예를 들어, 특정의 피시험 장치 자극(stimulus)을 제공하도록 설정된 레지스터의 어드레스)를 편입시킨다.

요컨대, 상기 프레임워크 코드는 항상 상기 ITesterPin 인터페이스를 이용할 것이며, 한편 사용자들은 필요에 따라 모듈 공급자들에 의하여 제공되는 특정 특색 및 확장을 자유롭게 이용할 수 있다. 다시 말하면, 모듈 공급자는, 예를 들면, 상기 클래스의 표준 시스템 구현에 메소드들(함수들)을 추가할 수 있다. 사용자를 위한 타협으로서는, 특정 공급자의 확장을 이용함으로써 상기 코드의 다른 공급자의 모듈과의 사용성이 낮아진다는 점이다.

모듈식 레벨에서, 상기 시스템 100은 명목상 두 개의 동작 모드를 가진다. 온라인(online) 동작 모드에서는, 모듈 요소 260(예컨대 하드웨어 요소)가 사용되며, 오프라인(offline) 동작 모드에서는, 소프트웨어의 모듈 에뮬레이션 280이 사용된다.

상기 온라인 동작 모드에 있어서는, 상기 모듈 요소 260은 하드웨어 백플레인 261, 섀시 슬롯 인터페이스 262, 모듈 하드웨어 263, 로드보드 하드웨어 인터페이스 264, 하드웨어 로드보드 265 및 피시험 장치 266을 포함한다.

상기 오프라인 동작 모드에 있어서는, 상기 소프트웨어의 모듈 에뮬레이션 280은, 시뮬레이션 프레임워크 281, 백플레인 에뮬레이션 282, 백플레인 시뮬레이션 인터페이스 283, 모듈 에뮬레이션 284, 로드보드 시뮬레이션 인터페이스 285, 로드보드 시뮬레이션 286 및 피시험 장치 시뮬레이션 인터페이스 287을 포함한다. 피시험 장치의 시뮬레이션을 위하여는 두 개의 모듈이 도시된다. 베리로그를 사용하는 모델은 상기 베리로그 PLI(프로그래밍 언어 인터페이스) 288 및 피시험 베리로그 모델 293을 포함한다. C/C++을 사용하는 모델은 C/C++ 언어 지원 289 및 피시험 장치 C/C++ 모델 291을 포함한다. 상기 시뮬레이션은, 예를 들어 PC와 같은 임의의 컴퓨터상에서 수행될 수 있다.

온라인 모드에서는, 상기 모듈 공급자는, 디지털 테스터 채널, 피시험 장치 전원 공급기 또는 직류 측정 유닛과 같은 시험을 지원하기 위한 물리적 하드웨어 구성 요소를 제공한다. 상기 모듈들은 상기 섀시 슬롯 인터페이스 262를 통해 상기 하드웨어 백플레인 261과 인터페이스한다.

오프라인 작업을 위하여, 상기 시스템 제어기의 등가물(equivalent)을 실행하는 PC 기반 또는 다른 환경은, 추가적으로 하드웨어의 에뮬레이션뿐만 아니라, 상기 사이트 제어기 레벨 프레임워크 및 소프트웨어의 하위 계층을 위한 실행 시간 환경을 제공할 모든 책임을 진다.

상기 백플레인 에뮬레이션 282는 상기 물리적 백플레인 261을 위한 소프트웨어 대행자(software surrogate)를 제공한다. 이것은, 상기 백플레인 시뮬레이션 인터페이스 283을 통해 상기 (공급자 제공) 모듈 에뮬레이션 소프트웨어 284와 통신한다.

상기 모듈 에뮬레이션 소프트웨어 284는, 상기 모듈 공급자에 의하여 제공되는 것이 바람직하며, 전형적으로 모듈 263의 특정 공급자 구현과 함께 밀접히 관련된다. 그리하여, 상기 모듈 에뮬레이션 소프트웨어는 전형적으로 서로 다른 공급자들에 의하여 제공되는 모듈들 상호 간에 서로 다른 세부 사항을 갖는다. 이 경우, 상기 모듈 시뮬레이션에 의하여, 상기 공급자는 소프트웨어 모델(예를 들어, 상기 모듈 에뮬레이션 소프트웨어 284)을 통해 하드웨어 기능성을 노출시키며, 시뮬레이션 된 로드보드 286으로 자극 신호(stimulation signal)를 송신하며, 상기 시뮬레이션된 로드보드 286으로부터 피시험 장치 응답 신호를 수신하고 처리할 수 있게 된다. 여기서, 상기 시뮬레이션된 로드보드 286은, 상기 피시험 장치 시뮬레이션 인터페이스 287을 통해 피시험 장치 모델링 소프트웨어 291, 293에 접속된다. 어떤 경우에는, 공급자들은 상기 모듈의 간단한 기능적 시뮬레이션을 제공하고 상기 모듈 펌웨어(firmware)의 에뮬레이션을 우회하는 것이 유리하다는 것을 알게 될 수도 있다. 상기 모듈 에뮬레이션 소프트웨어는 상기 시뮬레이션된 피시험 장치의 시뮬레이션된 모듈 자극 신호에 대한 응답을 알려진 양호한 피시험 장치의 응답과 비교한다. 이러한 비교에 기초하여, 상기 소프트웨어는 상기 모듈에 의하여 실행중인 시험이 소망하는 대로 상기 피시험 장치를 시험하는 자신의 목표를 충족시키는지의 여부를 판단하고, 상기 사용자가 온라인 물리적 테스터 상의 IC(물리적 피시험 장치)에 그것을 사용하기 전에 상기 모듈을 디버그(debug)할 수 있도록 돕는다.

상기 로드보드 시뮬레이션 인터페이스 285는, 상기 모듈 에뮬레이션 계층 및 상기 시뮬레이션 된 로드보드 286으로의 또는 그리로부터의 신호의 통로로서 복무한다. 상기 로드보드 시뮬레이션 구성 요소 286은, 소켓 매핑(socket mapping)과 상기 피시험 장치 시뮬레이션 인터페이스 287으로의 또는 그리로부터의 신호의 전파(propagation)를 지원한다.

상기 피시험 장치 시뮬레이션은 네이티브 코드(native code)(예를 들어, C/C++) 시뮬레이션 또는 목표 피시험 장치 293의 기능적 모델로의 베리로그 프로그래밍 언어 인터페이스일 수 있다. 상기 모델은 상기 피시험 장치 시뮬레이션 인터페이스 287을 통해 상기 시뮬레이션 된 로드보드와 인터페이스한다.

이러한 계층들의 전체적인 제어는 상기 시뮬레이션 프레임워크 281에 의하여 제공된다는 점을 주의하여야 한다. 상기 시뮬레이션 프레임워크는, 상기 시뮬레이션된 피시험 장치의 알려진 자극 신호에 대한 응답을 측정한다. 상기 시스템 에뮬레이션의 방법 미국 특허 출원 제10/403,817호에 개시되어 있다.

통신 및 제어

통신 및 제어는 관련 소프트웨어 객체의 운영을 통해 수행된다. 바람직하게는, 통신 메카니즘은 상기 시스템 제어기의 객체 모델 뒤에 가려진다. 이 객체 모델은 상기 사이트 제어기 상에서 발견된 상기 클래스들 및 객체들로의 프록시(proxy)를 제공하며, 그리하여 응용 프로그램의 개발(예를 들어, IC 장치의 시험)을 위한 편리한 프로그래밍 모델을 제공한다. 이렇게 함으로써, 응용 프로그램 개발자들(예를 들어, 상기 ATE 시스템의 사용자들)이 상기 응용 프로그램과 상기 사이트/시스템 제어기 사이의 통신의 상세에 관련된 불필요한 세부 사항을 회피할 수 있게 한다.

도 6은, 사이트 제어기 소프트웨어 240의 사이트 제어기 104에 의하여 유지되는 사이트 제어기 객체(site controller object)의 일 실시예를 도시한다. 상기 사이트 제어기 객체는 명령 배출기("CmdDispatcher") 602, 기능성 시험 메시지 처리기("FunctionalTestMsgHandler") 604 및 기능성 시험("FunctionalTest") 606을 포함한다. 인터페이스는 메시지 처리기 인터페이스("IMsgHandler") 608 및 시험 인터페이스("ITest") 610을 포함한다.

상기 사이트 제어기 소프트웨어 240은, 바람직하게 응용 프로그램이 억세스를 위하여 필요로 할 수도 있는 모든 기능성 클래스들(functional classes)을 포함한다. 이러한 클래스들은, 예를 들어, 시험들(Tests), 모듈들(Modules), 핀들(Pins), 등을 포함한다. 상기 사용자의 시험들 및 소프트웨어 도구들은 전형적으로 서로 다른 컴퓨터상에 존재하기 때문에, 메시지들은 상기 시스템 제어기 상의 상기 도구들로부터 상기 사이트 제어기 상의 서버로 송신될 것이다. 이 서버는 명령 배출 객체(Command Dispatch object) 상의 메소드를 호출할 것이다.

상기 명령 배출 객체(CmdDispatcher) 602는 메시지 처리기 객체의 지도(map)를 유지하는데, 상기 메시지 처리기 맵은 상기 IMsgHandler 인터페이스 608을 구현한다. 도 6은 IMsgHandler, FunctionalTestMsgHandler 604의 특정적 구현을 도시한다. 상기 CmdDispatcher 객체 602에 의하여 수신된 메시지들은 함께 통신될 객체의 식별자(identifier)를 포함한다. 상기 FunctionalTestMsgHandler 객체 604가 도시된 경우, 이 식별자는 내부 지도(internal map)에서 발견되며, 상기 내부 지도는 상기 특정적 구현으로 귀착된다.

본 실시예에서는, IMsgHandler 608은, 'handleMessage()'라는 하나의 메소드로 구성된다. 이 메소드는 바람직하게 하나의 구현 클래스로서 구현된다. 도시된 경우에서, 상기 FunctionalTestMsgHandler 604는 상기 메시지를, 인입되는 메시지의 정확한 성질에 따라 여섯 개의 메소드 중 어느 하나로 전달한다. 상기 인입되는 메시지의 헤더(header)는, 상기 메시지 처리기가 상기 메시지를 어떻게 처리할 것이며 어디로 전달할 것인지를 결정하게 하는 메시지 식별자(message id)를 포함한다.

상기 시스템 제어기 102에서 대응되는 통신 환경은 상기 시스템 제어기 소프트웨어 220의 도구들 225, 225 섹션과 관련된다. 도 7은, 도 6에 도시된 상기 사이트 제어기 객체에 대응하는 시스템 제어기 소프트웨어 220의 사기 시스템 제어기 102 상에서 유지되는 도구 객체(tool object)(또는 시스템 제어기 객체)의 일 실시예를 도시한다. 상기 도구 객체는, 객체 명령 배출기("CmdDispatcher") 702, 기능성 시험 메시지 처리기("FunctionalTestMsgHandler") 704 및 기능성 시험 프록시("FunctionalTestProxy") 706을 포함한다. 인터페이스는, 메시지 처리기 인터페이스("IMsgHandler") 708, 시험 클라이언트 인터페이스("ITestClient") 710, 및 배출 인터페이스("IDispatcher") 712를 포함한다. 또한, 유틸리티 응용 프로그램(utility Application) 714도 역시 포함한다.

본 실시예에 있어서, 상기 클래스 CmdDispatcher 702, IMsgHandler 708, 및 FunctionalTestMsgHandler 704는 도 6에 도시된 것과 같다. 그러나 FunctionalTest 606(또는 임의의 다른 사이트 제어기 클래스)의 인스턴스화(instantiatoin)는 사용되지 않는다. 대신에, 상기 도구 객체는 상기 사이트 제어기 104 상의 각 객체와 통신하기 위한 프록시 클래스들을 구비한다. 따라서, 예를 들어, 상기 도구 객체는 FunctionalTest 606 대신에 상기 클래스 FunctionalTestProxy 706을 포함한다. 이와 유사하게, 상기 도구 객체의 ITestClient 710은 사이트 제어기 객체의 ITest 610과 같지 않다. 일반적으로, 상기 시스템 제어기 102 상에서 실행되는 응용 프로그램들은 상기 사이트 제어기 상에 제공된 정확히 그대로의 인터페이스를 사용하지는 않을 것이다. 이 경우에, ITest 610의 세 가지 메소드들(즉, preExec(), execute(), 및 postExec())은 ITestClient 710의 하나의 메소드(즉, runTest())로 대체된다. 또한, ITestClient 710은 바람직하게 두 개의 인터페이스를 가지며, 즉, 그것은 IDispatch 712로부터 상속받는데, 여기서 상기 IDispatch 712는 마이크로소프트 구성 요소 객체 모델(Microsoft Component Object Model; COM)으로서 구현된다. 그것은 그 인터페이스를 구현하는 객체에 억세스하기 위한 스크립트 엔진을 활성화하는 인터페이스를 제공한다. 이렇게 함으로써, 상기 시스템은 마이크로소프트의 윈도우즈 플랫폼상에서 스크립트 가능(scriptable)하게 된다.

도 6 및 7에 도시된 실시예의 동작의 예로서, 상기 시스템 제어기 102 상에서 실행 중인 응용 프로그램(예를 들어, 상기 도구 섹션(tool section) 226, 228 중의 어느 하나의)은, 시험 계획 242가 하나 또는 그 이상의 FunctionalTest 객체 606을 포함하는 사이트 제어기 104와 통신할 수 있다. 상기 사이트 제어기 104 상에서의 상기 시험 계획 242를 초기화(initialization)하는 동안, 대응하는 시험-계획 객체가 상기 사이트 제어기 104 상으로 로드(load)되고, 상기 사이트 제어기 104는 시험 계획 메시지 처리기("TestPlanMessageHandler") 객체를 구축하고 그것을 CmdDispatcher 객체 602에 등록한다. 이것은 상기 메시지 처리기에 고유의 식별자(ID)를 할당한다. 유사한 동작이, 상기 시험 계획 242를 구성하는 다른 시험 계획(TestPlan) 객체와도 발생한다.

상기 시스템 제어기 103 상의 응용 프로그램(예를 들어 도구들 226, 228 내의)은 상기 통신 라이브러리 230을 초기화하고, 통신 채널을 통해 상기 사이트 제어기 104와 접속하고, 상기 TestPlan 객체를 위한 식별자를 획득한다. 상기 라이브러리는 TestPlanProxy 객체를 구축하고 이 식별자로 그것을 초기화한다. 초기화하는 동안, 이 프록시 객체는 그것이 얼마나 많은 시험을 포함하는지와 그들의 형식 및 식별자들을 판단한다. 그것은 각 형식(이 경우에는 단 한 가지 형식)에 대한 적합한 DLL들을 로드하며, 그들의 식별자 값으로 그들을 초기화하면서 그들을 위한 프록시 객체를 구축한다.

상기 TestProxy 객체도 또한 순서대로 초기화된다. 이를 수행하기 위하여, 그들은 자신의 명칭들(그들의 식별자 값을 이용하여)을 획득하기 위한 적합한 메시지들을 구축하고, 그들을 상기 사이트 제어기 104의 통신 서버로 송신하며, 상기 사이트 제어기 104는 상기 메시지를 상기 CmdDispatcher 602로 넘겨 준다. 이 객체는 그의 내부 지도에서 그 목적지 식별자(destination ID)를 조회하고, 상기 FunctionalTestMsgHandler 객체 604의 메시지 처리(handleMessage()) 메소드로 상기 메시지를 전달한다. 예를 들어, 만약 상기 메시지가 시험 명칭을 획득하기 위한 요구였다면, 이러한 객체들은 그들 각각의 시험의 명칭들을 획득하고 적합한 명칭 스트링(name string)과 함께 상기 응용 프로그램의 시험 프록시로 회신한다.

초기화가 완료된 후에, 상기 응용 프로그램은 시험 계획 객체 및 그를 통하여 모든 시험 객체로의 원격 억세스를 구비한다. 이제 상기 사용자는 상기 응용 프로그램의 예를 들어 "시험 계획 실행"이라는 버튼을 누를 수 있다. 결과적으로, 상기 응용 프로그램은 상기 시험 계획 프록시 객체 상에서 상기 시험 계획 실행("RunTestPlan()") 메소드를 호출한다. 이러한 메소드는 상기 시험 계획 객체의 목적지 식별자를 가지고 RunTestPlan 메시지를 구축하며, 상기 RPC 프록시 상의 메시지 송신("sendMessage()") 함수를 호출하는데, 상기 RPC 프록시는 상기 사이트 제어기로 상기 메시지를 송신한다.

상기 사이트 제어기 104 상의 상기 통신 서버는, 상기 시험 계획의 식별자를 넘겨 주면서 상기 CmdDispatcher 객체 602 상의 상기 handleMessage() 메소드를 호출한다. 상기 CmdDispatcher 객체 602는, 상기 시험 계획 객체를 위한 상기 메시지 처리기를 찾으며 그의 내부 지도에서 이 식별자를 조회하고, 이 객체 상의 상기 handleMessage() 메소드를 호출하는데, 그것은 다시 상기 시험 계획 객체 상의 상기 RunTestPlan() 메소드를 호출한다. 이와 유사한 방식으로, 상기 응용 프로그램은 상기 시험 객체의 명칭과 마지막 실행 상태를 획득한다.

통신 라이브러리를 사용하기 위한 방법

이하는 상기 통신 라이브러리 230의 사용의 일례이다.

상기 통신 라이브러리는 바람직하게 정적 라이브러리(static library)이다. 응용 프로그램은, 통신 라이브러리.h("CommLibrary.h") 파일을 통해 이 통신 라이브러리를 이용할 수 있다. 상기 통신 라이브러리 클래스를 이출(export)할 필요가 있는 응용 프로그램은, 상기 인클루드 파일에 추가하여 정의되는 "COMMLIBRARY_EXPORTS", "COMMLIBRARY_FORCE_LINKAGE"라는 프리프로세서 정의(preprocessor definition)를 구비해야만 한다. 상기 통신 라이브러리를 이입(import)하는 응용 프로그램은 어떠한 프리프로세서 정의도 정의할 필요가 없다. 상기 통신 라이브러리가 서버로서 사용될 때, 상기 응용 프로그램은 다음의 "CcmdDispatcher"의 정적 함수, 즉 "InitializeServerunsigned long portNo)"를 호출하여야 한다.

상기 portNo는, 상기 서버가 경청(listen)해야 할 포트(port)의 번호이다. 상기 서버에 대응하는 상기 명령 배출기는, CCmdDispatcher 클래스 상의 정적 함수: "getServerCmdDispatcher"를 호출함으로써 추출될 수 있다.

상기 통신 라이브러리가 클라이언트로서 사용될 때에는, 상기 응용 프로그램은 다음의 CcmdDispatcher의 정적 함수, 즉

InitializeClientconst OFCString serverAddress,

unsinged long serverPortNo,

CcmdDispatcher **pCmdDispatcher,

OFCString serverId)

를 호출해야만 한다.

상기 serverAddress 및 ServerPortNo는 상기 클라이언트가 접속해야할 것이다. 이 함수는 상기 클라이언트에 대한 명령 배출기 포인터와 그것이 접속해야만 하는 서버 식별자(serveId)를 초기화시킨다. 또한, 이후의 시점에, 상기 클라이언트는 정적 함수인 "getClientCmdDispatcher"를 호출함으로써 상기 serverId에 대응되는 명령 배출기를 추출할 수 있다.

상기 통신 라이브러리가 컴파일될 때, 빌드(build)가 "ClientInterface.idl" 및 "ServerInterface.idl"이라는 파일들로부터 배제된다. 상기의 바람직한 실시예는, 이들 인터페이스 정의 파일들을 위한 이미 생성된 스터브 및 프록시 파일을, 상기 프록시 및 스터브(stub) 구현 파일들을 동일한 라이브러리로 링크(link)시키도록 적용한다. 그리하여, 상기 서버와 클라이언트는 동일한 어드레스 공간에서 인스턴스화(instantiated)될 수 있다. 바람직하게, 상기 통신 라이브러리 작업을 동일한 어드레스 공간에서의 서버와 클라이언트로서 작업하도록 상기 인터페이스 정의 파일 및 스터브 파일에서의 이하와 같이 변경될 수 있다.

인터페이스 정의 파일의 변경

이하의 명칭 공간 선언(namespace declaration)은 바람직하게 각 인터페이스 정의 파일에 추가된다. 이것은 상기 프록시 구현 함수들과 우리 자신의 인터페이스 함수의 구현 사이에 명칭의 충돌을 방지하기 위한 것이다. 이하의 명칭 공간 선언은 상기 serverInterface.idl에 추가된다.

cpp_quote("#ifdef_cplusplus")

cpp_quote("namespace COMM_SERVER")

cpp_quote("{")

cpp_quote("#endif")

cpp_quote("}")

상기 스터브 구현 파일에서의 상기 함수는, 상기 인터페이스에 선언된 함수들을 위한 우리 자신의 구현 함수들을 호출하기 위하여 변경되는데, 우리는 상기 인터페이스에서 선언된 각 함수들에 대응하는 달리 명명된 함수를 가지고 있다.

함수 호출에서의 혼동을 방지하기 위하여, 상기 구현 함수의 명칭에 "COMM_" 문자열을 이용하여 접두어를 추가하는 것이 바람직하다. 그리하여, 상기 스터브 함수의 코드는 "functionName" 대신에 "COMM_functionName"으로 호출되도록 변경된다.

이러한 방법이 작동하도록, 모든 존재하는 기능적 클래스들은 그들의 대응하는 메시지 처리기 객체와 프록시 클래스들을 구비하여야 한다. 모든 메시지 처리기 객체는 상기 통신 라이브러리에 의하여 제공되는 IMsgHandler 클래스로부터 유래하여야 한다. IMsgHandler 클래스는 추상적인 클래스이다. 메시지 처리("handleMessage"), 객체 식별자 설정("setObjectId"), 에러 처리("handleError")를 위한 정의를 제공하는 것은 바람직하게는 상기 메시지 처리기의 구현자(implementor)의 책임이다. 모든 메시지 형식은 일(1)로부터 시작하여야 한다(우리는 영(0)을 handleError를 위하여 예비해 두었다.). 상기 기능적 클래스는 바람직하게, 그들의 멤버 변수(member variable)로서 그들의 대응하는 메시지 처리기를 구비한다. 상기 기능적 클래스의 구축자(constructor)에 있어서, 상기 기능적 클래스는, 그의 메시지 처리기에 의하여 제공되는 함수를 호출함으로써, 자기 자신을 상기 메시지 처리기에 등록시켜야 한다. 다음으로, 상기 메시지 처리기 객체는, 파라미터로서 상기 메시지 처리기와 함께 상기 명령 배출기 상의 "addMsgHandler" 함수를 호출함으로써 상기 명령 배출기에 등록되어야 한다. 상기 addMsgHandler 함수는 상기 메시지 처리기 및 상기 기능적 클래스에 식별자를 할당할 것이다. 상기 기능적 클래스의 파괴자(destructor)는 상기 함수 클래스 식별자를 파라미터로서 송신함으로써 상기 명령 배출기 상의 "removeMsgHandler" 함수를 호출하여야 한다. 프록시 클래스들도 또한 기능적 클래스들에 관하여 설명한 바와 동일한 등록 프로시져를 따라야 한다.

이하의 "CTestPlan" 클래스는, 본 발명의 바람직한 실시예에 따른 전형적인 기능적 클래스들을 개시한다. 즉,

File: - TestPlan.h

Class CTestPlan

{

private:

unsigned long m_Id;

CTestPlanMsgHandler m_tplMsgHandler;

}

File: - TestPlan.cpp

extern CcmdDispatcher *g_pCmdDispatcher;

CTestPlan::CTestPlan

{

m_tplMsgHandler.setTestPlan(this);

g_pCmdDispatcher.AddMsgHandler(&m_tplMsgHandler)

}

CTestPlan::~CTestPlan

{

g_pCmdDispatcher.removeMsgHandler(m_Id)

}

상기 g_pCmdDispatcher 객체는 상기 통신 DLL들에 의하여 노출되는 getCmdDispatcher()를 호출함으로써 초기화되어야 한다. 이하의 "CTestPlanMsgHandler" 클래스는 전형적인 메시지 처리기가 어떠한 것인지를 개시한다.

File: - TestPlanMsgHandler.h

Class CtestPlanMsgHandler:public IMsgHandler

{

public:

setTestPlan(CTestPlan *pTestPlan);

setTestPlanProxy(CTestPlanProxy *pTestPlanProxy);

void handleMessage(unsigned long msgType,

unsigned long senderId,

unsigned long senderMsgLen,

byte *pSenderMsg)

void handleSetName(unsigned long senderId,

unsigned long senderMsgLen,

byte *pSenderMsg);

void handleGetName(unsigned long senderId,

unsigned long senderMsgLen,

byte *pSenderMsg);

private:

CTestPlan m_pTestPlan;

CTestPlanProxy m_pTestPlanProxy;

typedef void(CFuncTestMsgHandler::*handlerFn)(unsigned long, unsigned long, byte*);

std::map<int, handlerFn>m_handlers;

}

File: - TestPlanMsgHandler.cpp

CTestPlanMsgHandler::CTestPlanMsgHandler

{

m_handlers[HandleError]=handleError;

m_handlers[GetName]=handleGetName;

m_handlers[SetName]=handleSetName;

}

void

CTestPlanMsgHandler::handleMessage(unsigned long msgType,

unsigned long senderId,

unsigned long senderMsgLen,

byte *pSenderMsg)

{

if(msgType==0)

{

handleError(senderId, senderMsgLen, pSenderMsg);

}

else

{

handlerFn fn=NULL;

hIter_t fIter;

fIter=m_handlers.find(msgType);

if(fIter==m_handlers.end())

{

return;

}

fn=fIter->second;

if(NULL!=fn)

{

(this->*fn)(senderId, senderMsgLen, pSenderMsg);

}

void

CTestPlanMsgHandler::handleSetName(unsigned long senderId,

unsigned long senderMsgLen,

byte *pSenderMsg)

{

if(m_pTestPlanProxy != NULL)

{

OFCString tplName=ByteToString(senderMsgLen, pSenderMsg)

m_TplProxy->setName(tplName);

}

void

CTestPlanMsgHandler::handleGetName(unsigned long senderId,

unsigned long senderMsgLen,

byte *pSenderMsg)

{

OFCString testName;

if(m_pTestPlan != NULL)

{

unsigned long l_destId

unsigned long l_msgType;

unsigned long l_senderId;

unsigned l_senderMsgLen;

byte *l_senderMsg=NULL;

if(m_pTestPlan->getName(testName)!=true)

{

//If a failure has occurred Send error message

char *errorString="Error retrieving name";

l_destId=senderId;

l_msgType=HandleError;

l_senderId=m_Id;

l_senderMsgLen=strlen(errorString);

l_senderMsg=StringToByte(errorString);

sendMsg(l_destId,

l_msgType,

l_senderId,

l_senderMsgLen,

l_senderMsg);

return;

}

l_destId=senderId;

l_msgType=SetName;

long l_senderId=m_Id;

l_senderMsgLen=testName.length();

l_senderMsg=NULL;

StringToByte(testName, &l_senderMsg);

sendMsg(l_destId,

l_msgType,

l_senderId,

l_senderMsgLen,

l_senderMsg);

DELETE_BYTE(l_senderMsg);

}

void

CTestPlanMsgHandler::handleError(unsigned long senderId,

unsigned long senderMsgLen,

byte *pSenderMsg)

{

OFCString errorString;

ByteToString(senderMsgLen, pSenderMsg, errorString);

m_pTestPlanProxy->setError(errorString);

}

이하의 CTestPlanProxy 클래스는 전형적인 프록시 클래스가 어떠한 것인지를 개시한다.

File: - TestPlanProxy.h

Class CTestPlanProxy

{

CTestPlanProxy(unsigned long serverID);

~CTestPlanProxy();

private:

CTestPlanProxy();

unsigned long m_Id;

unsigned long m_serverId;

CTestPlanMsgHandler m_tplMsgHandler;

}

File: - TestPlanProxy.cpp

extern CcmdDispatcher *g_pCmdDispatcher;

CTestPlanProxy::CTestPlanProxy(unsigned long serverID)

{

m_serverld=serverId;

m_tplMsgHandler.setTestPlanProxy(this);

g_pCmdDispatcher.AddMsgHandler(&m_tplMsgHandler)

///initialize the proxy with its name.

unsigned long msgType;

unsigned long senderMsgLen;

byte *pSenderMsg=NULL;

msgType=GetName;

senderMsgLen=0;

pSenderMsg=NULL;

sendMsg(m_clientId,

msgType,

m_Id,

senderMsgLen,

pSenderMsg);

//Check if the error string has been set by the message handler.

if(m_errorString.length() != 0)

{

OFCString errorString = m_errorString;

m_errorString="";

throw exception(errorString.c_str());

}

CTestPlanProxy::~CTestPlanProxy

{

g_pCmdDispatcher.removeMsgHandler(m_Id)

}

상기 g_pCmdDispatcher 객체는 getCmdDispatcher()를 호출함으로써 초기화 되어야만 한다.

시스템 구성 및 시험

도 8은, 본 발명의 일 실시예에 의한 공칭 시험 시퀀스(nominal testing sequence) 800을 도시한다. 상기 시험 시퀀스 800은, 시험 준비 806 및 시스템 시험 808을 둘러싼 시험 환경 804에의 모듈들의 설치 802를 포함한다. 최초에, 새로운 모듈(하드웨어 또는 소프트웨어 또는 그들의 조합)이 (예컨대 공급자 품질 제어 등에 기초한 소정의 외부 프로세스에 의하여) 인증된다 812. 설치 802는 먼저 오프라인 시뮬레이션 810을 위한 하드웨어 모듈 에뮬레이션의 설치, 모듈 자원 파일(module resource file)과 시험 프로그램 개발을 위한 인터페이스의 설치 및 패턴 컴파일을 위한 모듈에 특유한 패턴 컴파일러(module specific pattern compiler)의 설치를 포함하는 시험 준비 806을 요구한다. 다음으로, 교정(calibration) 816, w진단(diagnostics) 818, 및 구성(configuration) 320으로부터의 입력으로 시스템 시험 808이 실행된다. 그리고 나서, 새로운 모듈을 위하여, (1) 인터페이스 제어, (2) 동기화, 계열화(sequencing) 및 반복성(repeatability), (3) 에러/경고 처리(error/alarm handling), (4) 다중 사이트 제어, 및 (5) 다중 도구 모듈 제어(multi-instrument module control)를 포함하는 시스템 시험 808이 실행된다.

이상, 본 발명의 특정적인 예시로서의 실시예에 관하여 상세히 설명하였으나, 본 발명의 기술 분야에서 통상의 지식을 가진 자라면, 본 발명의 신규한 개시와 이점으로부터 본질적으로 이탈하지 않은 채 상기 예시적인 실시예에 대한 다양한 수정이 가능하다는 것을 즉시 이해할 수 있을 것이다. 따라서, 그러한 모든 수정은 이하의 특허청구범위에 정의된 본 발명의 범위에 포함되어야 한다.

상기한 바와 같이, 본 발명에 의하면, 시험 요건에 따라 재구성될 수 있는 테스터를 제공할 수 있다. 또한, 다른 공급자의 장비를 ATE와 연결하여 사용할 수 있게 된다.

Claims

적어도 하나의 피시험 장치(DUT)를 시험하기 위한 반도체 시험 시스템의 분산형 운영 체계(distributed operating system)에 있어서,

시스템 제어기(system controller)에 의하여 적어도 하나의 사이트 제어기(site controller)의 제어를 가동(enable)시키는 호스트 운영 체계(host operating system); 및

관련된 사이트 제어기에 의하여 적어도 하나의 시험 모듈(test module)의 제어를 가동시키기 위하여 각 사이트 제어기와 관련되는 적어도 하나의 지역 운영 체계(local operating system) - 상기 적어도 하나의 시험 모듈은 대응되는 피시험 장치에 대하여 시험을 수행함 -;

를 포함하는 분산형 운영 체계.
제1항에 있어서,

상기 호스트 운영 체계는, 상기 적어도 하나의 사이트 제어기의 동작을 동기화하는 분산형 운영 체계.
제1항에 있어서,

상기 호스트 운영 체계는, 상기 시스템 제어기와 상기 적어도 하나의 사이트 제어기 사이의 통신을 중재(arbitrate)하는 분산형 운영 체계.
제1항에 있어서,

상기 시스템 제어기는 상기 적어도 하나의 사이트 제어기의 동작을 감시하는 분산형 운영 체계.
제1항에 있어서,

사이트 제어기는, 상기 사이트 제어기와 관련된 적어도 하나의 시험 모듈의 동작을 감시하는 분산형 운영 체계.
제1항에 있어서,

상기 호스트 운영 체계는, 상기 적어도 하나의 사이트 제어기와 통신하기 위한 적어도 하나의 호스트 인터페이스(host interface)를 포함하는 분산형 운영 체계.
제6항에 있어서,

상기 적어도 하나의 호스트 인터페이스는, 사이트 제어기와 관련된 상기 적어도 하나의 시험 모듈과 통신하는 분산형 운영 체계.
제1항에 있어서,

사이트 제어기를 제1 시험 모듈과 인터페이스하기 위한 시험 모듈 함수를 정의하는 시험 모듈 인터페이스를 더 포함하되,

확장되지 않는 시험 모듈 인터페이스는 상기 사이트 제어기를 제2 시험 모듈과 인터페이스하기에 불충분하므로, 상기 시험 모듈 인터페이스는, 상기 사이트 제어기를 제2 시험 모듈과 인터페이스하도록 확장 가능한

분산형 운영 체계.
제1항에 있어서,

상기 호스트 운영 체계는 적어도 하나의 호스트 프레임워크 클래스(host framework class)를 포함하는 분산형 운영 체계.
제9항에 있어서,

상기 적어도 하나의 호스트 프레임워크 클래스는, 사용자가 상기 적어도 하나의 사이트 제어기를 제어하기 위한 응용 프로그램에 특유한 클래스를 개발할 수 있도록 하기 위하여 표준 컴퓨터 언어(standard computer language)로 개발되는 분산형 운영 체계.
제10항에 있어서,

상기 표준 컴퓨터 언어는 C 또는 C++인 분산형 운영 체계.
제1항에 있어서,

각 지역 운영 체계는 적어도 하나의 지역 프레임워크 클래스(local framework class)를 포함하는 분산형 운영 체계.
제12항에 있어서,

상기 적어도 하나의 지역 프레임워크 클래스는, 사용자가 상기 적어도 하나의 시험 모듈을 제어하기 위한 응용 프로그램에 특유한 클래스를 개발할 수 있도록 하기 위하여 표준 컴퓨터 언어(standard computer language)로 개발되는 분산형 운영 체계.
제13항에 있어서,

상기 표준 컴퓨터 언어는 C 또는 C++인 분산형 운영 체계.
제1항에 있어서,

각 사이트 제어기에 의하여 제어되는 상기 모듈의 개수는 증감 가능한 분산형 운영 체계.
제1항에 있어서,

대응되는 사이트 제어기와 관련된 상기 지역 운영 체계는, 상기 사이트 제어기에 의하여 제어되는 시험 모듈의 형식을 재구성할 수 있게 하는 분산형 운영 체계.
제1항에 있어서,

상기 호스트 운영 체계는, 상기 시스템 제어기에 의하여 제어되는 사이트 제어기의 개수를 증감 가능하게 하는 분산형 운영 체계.
제1항에 있어서,

상기 호스트 운영 체계는 상기 시험 시스템에 의하여 시험되는 피시험 장치의 개수를 증감 가능하게 하는 분산형 운영 체계.
제1항에 있어서,

상기 적어도 하나의 시험 모듈은 하드웨어 및/또는 소프트웨어를 포함하는 분산형 운영 체계.
제1항에 있어서,

후보 시험 모듈(candidate test module)이 상기 시험 시스템과 호환 가능한지의 여부를 검증하기 위하여, 상기 후보 시험 모듈을 상기 시험 시스템에 사용하는 시뮬레이션(simulation)을 수행하기 위한 에뮬레이터(emulator)를 더 포함하는 분산형 운영 체계.
제1항에 있어서,

제1 시험 사이트에서의 제1 집합의 모듈들이 제2 시험 사이트의 제2 집합의 모듈들과 다르게 구성된 분산형 운영 체계.
제1항에 있어서,

제1 시험 사이트는 제1 피시험 장치를 시험하기 위한 제1 구성을 가지며, 제2 시험 사이트는 제2 피시험 장치를 시험하기 위한 제2 구성을 가지며, 상기 제1 및 제2 시험 사이트는 제3 피시험 장치를 대신 시험하기 위한 제3 시험 사이트를 함께 형성하도록 재구성될 수 있는 분산형 운영 체계.
제1항에 있어서,

제1 시험 사이트의 제1 모듈은 제2 시험 사이트의 제2 모듈에 억세스할 수 있는 분산형 운영 체계.
제1항에 있어서,

시험 모듈과 함께 사용되기 위한 예정된 집합의 함수들과 인터페이스들을 구비한 통신 라이브러리를 더 포함하는 분산형 운영 체계.