최 종 연 구 보 고 서

고장 감내형 고성능 프로세셔 시스템 구조에 관한 연구

수탁연구기관 : 명지대학교

한 국 전 자 통 신 연 구 소

제 출 문

한국전자통신연구소장 귀하

본 보고서를 고장 감내형 고성능 프로세서 시스템 구조에 관한 연구의 최종 연구보고서로 제출합니다.

1996 년 12 월 30 일

수 탁 기 관 : 명지대학교

수탁 기관장 : 고 건 (인)

수탁 책임자 : 이광배 (인)

선임 연구원 : 김현욱, 여환근

연 구 원 : 유충열, 문태수

보조 연구원 : 권순상, 곽승욱

임영묵, 김태욱

요 약 문

1. 제 목

고장 감내형 고성능 프로세서 구조에 관한 연구

2. 연구의 목적 및 중요성

근래에 와서 시스템의 오동작이 치명적인 결과와 막대한 재산상의 문제를 초래할 수도 있는 실시간 시스템을 사용한 응용 분야가 점차 확산되고 있다. 예를 들어 증권 거래소의 컴퓨터 시스템이나 철도청의 기차표 예매 시스템의 고장, 전화교환 시스템의 고장으로 인하여 극도의 문제를 야기시킬 수 있다. 한 예로 1990 년 미국 AT&T 사의 장거리 전화 교환 시스템이 작은 고장으로 인해 고장을 일으켜 수십만 통화의 장거리 전화가 연결되지 못해 미국내 전체에 극도의 혼란을 야기시켰었다. 이러한 시스템의 제작 시에 내포될 수 있는 고장의 요인과 시스템의 동작 중에 외부의 요인에 의하여 발생할 수 있는 오류로 인한 시스템의 손실을 방지하고 이 오류로 인한 극도의 혼란과 막대한 경제적 손실을 미연에 방지하기 위해 고장 감내 시스템이 사용되어야 한다. 특히 순간적으로 많은 양의 정보를 처리해야 하는 통신의 분야에 있어서 매우 중요한 관건이라고 할 수 있다. 본 연구에서는 앞으로의 초고속 정보화 시대의 ATM 제어 시스템에 적합한 고장 감내 구조를 제안하고 그에 대한 하드웨어 구현 방법 및 성능 평가를 수행하고자 한다. warm standby sparing 고장 감내 구조를 사용한 시스템에서 고장 발생시 데이터 무손실은 오늘날의 기술 수준으로 볼 때 사실상 구현이 불가능하며, 분산 시스템 상에서의 고장 발생시에는 도미노 효과 등으로 인한 엄청난 재앙을 유발할 수 있기 때문에 고장 발생시에도 데이터 무손실이 가능한 hot standby sparing 기법에 대한 보다 많은 연구가 필요하다. hot standby sparing 고장 감내 구조는 다중화 보드들 간에 끊임없는 동기화를

요구하며, ATM 제어 시스템은 soft 실시간 제한 내에서 동작해야 하므로 시스템의 요구 조건에 부응하면서도 전체 시스템 성능을 크게 저하시키지 않는 고장 감내 구조의 개발이 필요하다.

3. 연구의 내용 및 범위

가. 연구 내용

정보화 사회에서 요구되는 ATM 교환기 제어 시스템은 방대한 양의 정보를 결함없이 신속하게 처리할 수 있는 능력이 필요하다. 이중화 구조상에서 warm standby sparing 기법을 사용하는 경우에는 고장 발생시 데이터 손실을 최소화시키기 위해서 보다 신속한 고장 감지 방법의 개발이 필요하며, 또한 최악의 경우에는 거짓 데이터가 시스템 전체로 확산되는 문제점을 지니고 있으므로 그러한 문제점을 최소화하고 본 연구의 목표에 취합하는 이중화 구조를 갖는 ATM 제어 시스템에서의 hot standby sparing 고장 감내 구조를 설계하였다.

본 연구에서는 기존의 ft-sparc 고장 감내 컴퓨터를 기본 모델로 하여 I/O 버스상에서 고장 감지 및 이중화 프로세서 모듈간에 동기 동작이 수행되도록 설계함으로써 기존의 hot standby sparing 기법에서의 문제점인 급격한 전체 시스템 성능 저하 문제 (이중화 모듈간에 빈번한 동기 동작 수행으로 인해 발생)를 크게 개선시켰다. 또한 I/O 버스상에서의 동기 동작 점검시, 이중화 모듈간에 지연(delay) 문제를 해결할 수 있는 방법을 제시하였다. 마지막으로 제안된 고장 감내구조에 대한 성능 평가를 위해서 동일 구조의 warm standby 고장 감내 구조와 시스템 가동률면에서 비교 분석하였다.

나. 연구 범위

- I/O 버스를 이용한 기존 ft-sparc 고장 감내 구조에 대한 연구 및 분석

- ATM 고장 감내 구조에 필요한 I/O 버스상에 고장 감지 및 동기 동작에 대한 연구

- 부분별 고장 감내 구조 설계

- 전체 고장 감내 구조 설계

- 시뮬레이션을 통한 성능 예측 및 분석

4. 연구 결과

본 연구를 통해 얻은 결과는 다음과 같다.

- ft-sparc 고장 감내 구조에 대한 연구 분석 자료

- I/O 버스상에서의 고장 감지 및 동기 동작 방식에 대한 자료

- 부분 및 전체 고장 감내 구조 설계에 관한 자료

- 시뮬레이션을 통한 성능 평가 및 비교 자료

5. 활용에 대한 건의

본 연구로부터 획득한 기술을 차세대 결함 허용 교환 시스템 및 ATM 교환 시스템 개발시 사용할 수 있으며, 다른 동기화를 필요로 하는 실시간 다중 시스템개발 및 NMR 결함 허용 시스템 개발시에도 적용할 수 있다. 또한 시스템 고유용성을 요구하는 시스템과 그와 관련된 정보 통신 분야에 활용될 수 있을 것이다.

6. 기대 효과

본 연구를 통해서 실시간 ATM 제어 시스템에 적합한 동기 방식과 hot standby 고장 감내 구조에 대한 기술적 향상을 얻을 수 있으며, 또한 이러한 이중화 구조가 전체 ATM 제어 시스템 성능에 미치는 영향을 계산하여 그에 따른 개선된 구조를 구현시킬 수 있다.

이 연구를 통해서 확보한 기술은 다른 soft 실시간 네트워크 시스템에 적용하여 발전시킬 수 있으리라 생각된다. 또한, 본 연구에서는 현재 국내와 국외에서 개발 중인 ATM 교환기의 제어 시스템에 대한 고장 감내 구조를 다루므로, 본 연구를 통한 기술의 확보는 국가 정보 통신기간 산업의 발전에 중요한 영향을 미치고, 고성능 ATM 교환기 개발을 가능하게 함으로써 국내 및 해외 시장 확보에 도움을 줄 수 있을 것이다.

Summary

1. Subjects

· A study on the fault tolerant high performance processor system architecture.

2. Objects.

· Develop the hot standby sparing fault tolerant architecture fitted to ATM control system.

3. Contents

· Analysis of traditional hot standby sparing fault tolerant architectures based-on I/O bus.

· Study on fault detection and synchronization.

· Design of hot standby sparing fault tolerant architectures applicable to practical ATM control system.

· Performance evaluation through simulation.

4. Results

· Fault detection and synchronization technique on I/O bus for hot standby sparing fault tolerant architectures.

· Technique correcting delay between two processor modules.

· I/O bus-based hot standby sparing fault tolerant architecture applicable to ATM control system.

· Performance evaluation through simulation.

5. Suggestion

· Applicable to the high performance fault tolerant system architectures for future control system in high speed network.

· Applicable to the related multimedia area.

- 목 차 -

제 1 장 서 론

제 2 장 I/O 버스를 이용한 기존 고장 감내 구조

제 1 절 기술적 개요

1. Architecture

2. ft - SPARC CPUSet

3. Processor Fault Tolerance : Alternative Approaches

4. Power Subsystem

5. Fault Tolerant I/O Bus

6. Disk Subsystem

7. Ethernet Networking

8. Fault Tolerant I/O

9. Operating System

10. CMS(Configuration Management System)

11. Serviceability

제 2 절 하드웨어 개요 35

1. Introduction

2. Configuration Management System (CMS)

3. Hardware Configuration Changes

4. Configuration Change Examples

5. Drive Subsystem

6. Ethernet LAN Subsystem

제 3 절 고장 감내 기술

1. OEM Device Integration

2. Creating Fault Tolerant Device Drivers

3. FTIO Bus

제 3 장 고장 감내 IO-Bus 에 근거한 시스템 구조에 대한 제안

제 1 절 하드웨어 구조 및 기능

제 2 절 고장 감내 이중화 모듈 구조의 시스템 동작

제 4 장 성능 평가 및 비교

제 1 절 마르코프 상태도를 이용한 불가동률의 계산

1. 단일 프로세서로 구성된 warm standby 모델

2. I/O Bus 를 기반으로 한 hot standby 모델

제 2 절 성능 평가에 대한 분석 및 고찰

제 5 장 결 론

참 고 문 헌

부 록

- 그림 목차 -

그림 1. 타이밍 분석도

그림 2. 타이밍 분석도

그림 3. 이중화 고장 감내 프로세서 모듈 구조

그림 4. 프로세서 모듈의 상세 구조

그림 5. 고장 감내 이중화 모듈 구조 시스템 동작 흐름도

그림 6. 시스템 초기화에 대한 흐름도

그림 7. 클럭 동기화에 대한 흐름도

그림 8. 클럭 동기화 과정

그림 9. Mbus 입력 동작에 대한 흐름도

그림 10. Mbus 출력 동작에 대한 흐름도

그림 11. 시스템 재구성에 대한 흐름도

그림 12. 클럭 비동기화 과정 설명도

그림 13. 시스템 재통합에 대한 흐름도

그림 14. 단일 프로세서로 구성된 warm standby 모델에 대한 상태도

그림 15. I/O 버스를 이용한 hot standby 모델에 대한 상태도

그림 16. standby 모듈에서의 데이터 복구 시간 변화에 따른 불가동률

그림 17. 운영 요원에 의한 복구율 변화에 대한 불가동률

그림 18. 데이터 회복 시간 변화에 대한 불가동률

제 1 장 서 론

오늘날 전체 산업 분야의 급격한 발전은 시스템의 오동작이 과거와 다르게 치명적인 결과와 막대한 재산상의 문제를 초래할 수 있다. 특히 순간적으로 많은 정보를 처리해야 하는 정보 통신 분야에 있어서 시스템이 높은 신뢰도를 갖도록 하는 일이 매우 중요한 관건이라고 할 수 있다.

ATM 제어 시스템은 고성능 및 고유용성 (high availability)이 요구되는 교환 시스템으로서 범용 컴퓨터와는 다른 고장 감내 구조와 동작을 필요로 한다. 범용 컴퓨터 응용분야에서는 대부분의 경우 시스템 고장 발생시 이를 감지하여 시스템 동작을 일시 중지시키고 필요한 복구 동작을 수행한 후 시스템을 재 가동시킨다. 그러나 ATM 제어 시스템에서는 시스템 고장 감지시 시스템 동작을 가능한 중지시키지 않고 계속 유지시키면서 고장 복구 동작을 동시에 수행시켜야만 한다. 이는 ATM 교환 시스템으로의 호 요청이 끊임없이 이루어지기 때문에 시스템의 일시적인 동작 중지는 ATM 교환망을 이용하는 사용자들에게 극도의 혼란을 야기시킬 수 있기 때문이다. 그러므로 고유용성을 필요로 하는 기존의 교환시스템에서는 고장 감내 구조로서 이중화구조 상에서 standby sparing 기법을 사용하고 있다.

standby sparing 기법은 크게 세가지로 구분되는 데 cold standby sparing, warm standby sparing, hot standby sparing 들이다. cold standby sparing 기법은 standby 상태에 있는 시스템 모듈이 결함 발생으로 인해 active 상태로 전환되기 전까지 전원 공급이 중단되어 있으므로 active 기능을 수행하기까지에는 다소의 시간이 걸린다. 그러므로 고유용성을 요구하는 교환기의 고장 감내 시스템에는 이 기법이 적합하지 않다. warm standby sparing 기법은 active 상태에 있는 시스템 모듈이 시스템 정상 동작 시에 concurrent write 방식을 사용하여 그 자신의 메모리 재용과 standby 상태에 있는 시스템 모듈의 메모리 내용이 동일하도록 시스템을 동작시키기 때문에, 고장 발생 시에 standby 시스템 모듈이 active 상태로 전환되고 본래의 정상 기능을 수행하는데 걸리는 시간은 cold standby sparing 기법보다 매우 짧다. 그러나 고장의 종류와 정도에 따라서 다소의 데이터 손실이 발생하며 또한 active 시스템 모듈과 standby 시스템 모듈간에 주기적인 고장 점검이 요구된다. hot standby sparing 기법에서는 모든 시스템 모듈이 active 하게 동작하므로 정상 동작시 모든 시스템 모듈의 상태와 내용이 시스템 동기화를 통해서 같도록 유지되어야 한다. 이 기법에서는 외부 시스템과의 데이터 교환시 단지 한 모듈이 master 로서 동작하게 된다. 임의의 한 시스템 모듈로부터의 고장 발생시 고장 감지 즉시 고장 모듈을 시스템으로부터 제거하고 수행 중이던 일을 계속 진행시킬 수 있으므로 고장 감지로부터 시스템 정상기능 재가동까지 걸리는 시간일 극히 짧다. 또한 단일 시스템 고장으로부터의 데이터 손실이 발생하지 않는 고장 감내 구조의 설계가 가능하다. 반면에 정상 동작 중에 장 감내 시스템 모듈간 동기화 유지와 결함으로부터 복구된 시스템 모듈의 재정상 가동 등이 해결해야 할 큰 문제점이다.

ATM 교환망은 현재 추진되고 있는 광대역 종합 정보 통신망(B-ISDN)의 중추로서 시스템 간의 모든 정보 교환은 ATM 교환망을 통해서 이루어지게 된다. 최근

국외에서 상용 ATM 교환 시스템 개발을 발표하였으며 국내에서도 ETRI (한국전자통시연구소)와 일부 기업간에 협력하에 ATM 교환 시스템 개발에 힘쓰고 있다.

현재 개발되어 사용되고 있는 AT&T 사의 ESS-5 교환기, ETRI 의 TDX-10 및 대부분의 교환기들은 고장 감내 구조로서 warm standby sparing 기법을 사용하고 있다. 그 이유는 고장 감내 구조로서 Hot standby Sparing 기법을 사용하는 교환 시스템이 데이터 무손실 등 많은 장점을 지니고 있으나 실시간 교환 시스템 구현시 동기화 문제가 매우 복잡하기 때문이다.

현재 많은 고장 감내 시스템들이 개발되어 사용되고 있고 하드웨어 가격의 하락으로 경제성 있는 상용 고장 감내 시스템들이 출현하여 여러 분야에서 활용되고 있다. 그러나, 보다 나은 고장 감내 시스템에 대한 필요성이 정보화 시대의 출현과 더불어 급속히 증대하고 있으며 이에 대한 연구도 활발히 진행되고 있다. 이러한 추세에 발맞추어 본 연구에서는 이중화 구조를 갖는 ATM 제어 시스템에서의 hot standby sparing 고장 감내 구조를 I/O 버스를 기본으로 하여 구현시키는 방법을 연구함으로써 고성능 및 고유용성을 유지하는 차세대 무손실 ATM 제어 시스템 개발에 기여하는 것을 최종 목표로 하고 있다.

제 2 장 I/O 버스를 이용한 기존 고장 감내 구조

제 1 절 기술적 개요

1. Architecture

a. CPUSet :

·tight synchronization 으로 동작

·failure 는 FT i/O bus 의 하드웨어 비교 logic 으로 감지

·I/O 동작시에만 CPUSet 들을 비교 (동기 동작)

⇒ 시스템 성능 향상

b. I/O Subsystems :

·all parts 이중화

·I/O subsystem elements 내의 에러는 software 나 firmware 로 감지

·Driver 내의 software checking 기법 :

·command time-out

·command & data checksum

·동일 subsystem 의 다른 element 들간에 비교

·error 감지시, software 로 시스템 재구성

2. ft - SPARC CPUSet

·description :

·DMA controller : FT I/O 버스를 통한 고속 data read

·block checksum generator : FT I/O 버스를 통한 block 정보 전송 검증

⇒ 프로세서 overhead 제거

·4 maintenance bus interfaces : 시스템내의 다른 module 들 제어

a. Processor Fault Detection

·tight synchronization : 모든 CPUSet 들은 동시에 동일한 동작 수행

·clock 신호 : PLL(Phase Lock Loop)을 사용하여 CPUSet 들에 전송

(각 CPUSet 은 clock 생성기 및 수신기 내장)

·clock 생성기 fail 시, 각 CPUSet 은 진단시스템을 통해 고장

CPUSet 을 offline 시킨 후 다음 I/O 동작때까지 자신의 clock 생성기를 구동

·정상동작시, 각 프로세서는 full processor/memory bandwidth 로 작업 I/O 동작시, CPUSet 들은 동시에 동일 read 및 write 동작을 수행하여야 함.

·CPUSet element 내의 failure 종류

·memory corruption

·microprocessor failure

·Two modes of CPUSet bus interface operation : master & checker

all CPUSets : checker mode enabled

only master CPUSet : master mode enabled

·I/O operation 시, master CPUSet 이 FT I/O 버스 상에 요청을 대행 (put)

write cycle : address & data

read cycle : address only

read 요청의 data-in phase 동안, 각 CPUSet 은 4bit parity word 를 생성한 후 나머지 CPUSet 들과 비교한다.

⇒ read data 가 동일함만을 check

(read data 의 correctness 는 검증할 수 없음)

·정상 I/O 동작시 :

① I/O 요청

② I/O bus 를 통한 수행 (CPUSet 들간에 불일치 점검)

③ 버스 요청 완료

④ processing 계속

·고장 발생 감지시 : (즉 cpuset 불일치) ⇒100msec 이내로 완료

① I/O 요청 중지

② CPUSet 들의 진단 routine 구동 및 고장 CPUSet 발견

③ 시스템 재구성:

(DMR) good CPUSet 이 maintenance 버스들을 이용하여 failed CPUSet 을 offline 시킴

(TMR) 한 good CPUSet 이 나머지 CPUSet 들을 offline 시킨 후 나머지 good CPUSet 을 reintegration(2.b 참조) 시킴

·대부분의 CPUSet failure 는 transient (일시적)

⇒ offline 으로 permanent failure 인지 check 필요

·ft-SPARC CMS(configuration Management System) :

user 가 permanent failure 없는 module 을 reintegration 할 수 있게 해준다. (즉 시스템을 원래의 DMR 또는 TMR mode 로 환원)

b. CPUSet Re-integration

·re-integration : CPUSet failure 후에 새 CPUSet 을 시스템에 재결합

·고장 복구 :

① 새 CPUset mode 삽입

② 완전한 self-test 수행

③ re-integration : (normal UNIX process)

step 1 : master main memory 내용을 새 CPUSet 의 memory 로 copy(memory copy 는 user process 의 정상 동작을 방해하지 않고 수행됨)

step 2 : copy 동작중 수정된 memory 영역은 반복 동작으로 재 copy

step 3 : copy 완류시, CPUSet 들은 잠시 동작 중지(halt)되었다가 동기를 맞춰 restart

3. Processor Fault Tolerance : Alternative Approaches

a. software checkpointing : (Tandem Non-Stop family)

·software checkpointing : 'checkpoint'들 간에 short burst 로 user process 를 구동 checkpoint 에서, process 의 snapshot

(즉 processor state, registers, volatile memory 내용등)이 취해져서 memory나 disk 에 저장된다.

⇒ safe point 설정 : next burst 동안 fault 가 발생하면 이 지점에서 작업이 다시 시작될 수 있다.

·프로세서 에러 감지를 위해 두 개의 프로세서와 comparator 필요

·문제점 :

·checkpoint 를 삽입하는 code 가 길고 느리다.

·응용 프로그램이 해당 platform 에서만 구동되도록 만들어짐 (definition, proprietary)

⇒ software 와 maintenance 비용 증가 main stream software package 및 개발 tool 부재 숙련 staff 부족

b. Hardware Comparison

·hardware comparison system : 다중 unit 에서 동일 업무 수행 및 결과 비교

·고장 발견

·redundancy 제공 ⇒ 고장 발생후 processing 계속

·lowest level of comparison : microprocessor level (stratus)

·매 processor bus cycle 마다, 두개 또는 세개의 processor 들의 입출력들이 서로 비교된다.

·processor 고장 감지에 대한 가장 간단한 방법

·단점 : 일정 시간이 비교 동작에 소요되며 microprocessor 성능이 저하됨

⇒ microprocessor clock speed 증가는 비교 동작에 의한 성능 저하를 부각시킴

·processing unit 의 성능 개선을 위해서 시스템내의 비교 횟수 감축 즉 global memory 및 I/O 와의 동작시 비교 동작 수행 : (Tandem S2)

·세 개의 processing unit ⇒ voting : vote 전에 module 간에 동기 필요

(각 processor 는 자신의 clock 소유)

·동기 동작 : I/O access 에 먼저 도달한 processor 모듈은 나머지

processor 모듈들이 동일 위치에 도달할때까지 halt 됨

⇒ 성능에 영향을 줄만큼의 시간 소요

c. ft-SPARC

·hardware fault detection

·software fault resolution :

recovery software 가 fault 원인을 발견하고 결함 CPUSet 을 power off 시킴으로 시스템을 재구성

4. Power Subsystem

·시스템 고장의 주 원인중의 하나

·power problems :

·failure of external power supply

·brownouts and spikes on the external supply

·internal converter failure

·regulation failure

·power shorts within system modules

5. Fault Tolerant I/O Bus

·description :

·FT I/O bus :

·asynchronous 64 address/data bus

·8 bit parity for 64 bit data

·support up to 8 I/O controllers

·2 distinct, redundant FT I/O buses

a. Geographic Addressing

·각 slot 은 unique address 가짐 : 3 address pins ( 각 FT I/O bus slot 에)

·각 slot 은 32 Mb 의 FT I/O bus address space 에 부응

· disk 와 tape module : geographically addressed

b. Interrupts

·FT I/O bus: 동일 priority 를 갖는 radial interrupts 방식

c. Online Module Replacement

·controller 의 삽입과 추출은 active bus 를 glitch 시키지 않음

·module extractor 와 연결된 power interlock ; 추출전 power off 보장

·power on 시키려면 thumbscrew 로 꽉 조여야 함

d. Maintenance Bus

·4 maintenance bus : CPUSet 와 system module 간에 control message 전송에 사용

·message :

·controller power on/off

·각 controller card 의 상태 LEDs set/unset

·message 경로:

step 1 : maintenance bus 는 시스템내 각 geographical location 으로 message passing

step 2 : CPUSet 및 각 module 은 message 해석 및 수행

·maintenance bus 기능 :

① control message 전송

② module EEPROM 내용 read/write : 각 module 은 EEPROM 을 가짐

·EEPROM : module #, serial #, inception date, repairs, updates, power on/off times, module 이 deactivate 된 원인 등과 같이 module 에 대한 정보 내장

-->·이 정보는 user level program 에서 read 할 수 있음

·module 고장 수리시 read 된다.

·시스템의 질적 향상에 도움

e. FTIO Bus Adapters

·FTIO bus 는 industry 표준 버스로의 bridging 을 지원

·ft-SPARC 내에 표준 disk 및 I/O controller 들은 VMEbus 와 SBus based 임

f. ft-VMEbus Adapter

·ft-SPARC 시스템과 VMEbus controller 간에 interface

·Adapter 기능 : 32 MB FTIO bus address space 지원

step 1. : FTIO bus 요청 수신

step 2 : VMEbus 요청으로 변환

step 3 : VMEbus controller 모드로 pass

·FT 시스템 원칙 : CPUSet main memory 에 직접 write 할 수 있는 bus master controller 사용 금지

(unprotected data write 가 the CPUSet 을 corrupt 시킬 수 있으므로)

·VMEbus master 수용

step 1 : VMEbus adapter 상에 auxiliary memory area 로 데이터 전송

step 2. CPUSet : CPUSet 은 데이터를 main memory 로 DMA 전송

·Adapter 기능

·VME block move 요청 : VME controller 와 CPUSet 간에 최대 data 전송

·write posting : 데이터가 실제적으로 VME controller 로 write 되기 전에 CPUSet은 write 요청은 완료시킴

·complete VMEbus SYSCON signal 지원

·No arbitration

·VMEbus interrupt ---> ft-SPARC slot interrupt ---> adapter 의 ,VMEbus interrupt cycle 완료 및 interrupt level 과 vector 기록

g. ft-Sbus Adapter : 64MB address space (64MB window)

·Sbus : third party controller 및 peripheral메 대한 open interface

standard

·ft-Sbus adapter : 1 또는 2 개의 Sbus controller 지원

→ ft-Sbus adapter 에 설치된 2 Sbus controller card 들은 하나의 공통 Sbus 를 공유

·두 Sbus controller 간에 통신 및 Sbus controller 로부터 ft-Sbus adapter card memory 로의 전송

⇒ 시스템 memory 의 다른 부분을 overwriting 시킴으로써 Sbus card 가 시스템 fault 를 일으키는 것을 방지

·ft-Sbus adapter : 모든 Sbus clock 과 arbitration signal 들을 생성

·Sbus interrupt --> FTIO bus radial interrupt --> OS kernel 에 의해 적절한 device driver 로 dispatch

6. Disk Subsystem

a. I/O controller

·ft-SPARC 용 disk controller : IOSET combined SCSI and Ethernet controller (ELP)

b. Disk Subsystem

·all components 이중화 :

·dual disk controller

·dual SCSI buse

·dual disks

·mirrored disk :

·데이터가 두개의 별도 disk 에 독립적으로 write 된다.

⇒ 두 disk 가 동일한 정보 보유

·disk read 는 어느 한 disk 가 담당

c. Disk Reintegration

·reintegration 절차 :

stepl : 고장 component 대체

step2 :

·new disk 로의 정상 disk 상에 현재 정보 copy (user level background task 로 수행)

·background copy 도중 OS 에 의한 (application software 를 포함한) 새로운 write 는 두 mirror disk 에 수행한다.

step3 : copy 완료시, mirror pair 로 동작

d. Data Integrity

·end-to-end checksum algorithm 사용

⇒ disk data 가 전송도중 corrupt 되지 않도록 보증

·전송데이터 : 데이터 block + checksum

·checksum 은 수신측에서 전송된 데이터 block 을 사용하여 재생되며, 재생된 checksum 과 수신된 checksum 비교

7. Ethernet Networking

·IOset 과 ELP 로의 단일 ethernet connection 지원

·single modem 와 fault tolerant mode

·fault tolerant mode : 두 ethernet controller 함께 동작

·primary : packet 송신 및 수신

·backup : packet 수신 only primary 와 동일 address 로 초기화

·system control panel EEPROM : physical 시스템 ethernet address 들 저장

·각 ethernet interface 에게 하나의 physical address 보유

→ switchover 시, 한 interface 는 consistent physical address 모유

·ARP(Address Resolution Protocol) network 환경에서 동작 가능

8. Fault Tolerant I/O

a. Asynchronous Communications

·VICP asynchronous communications controller 사용

→ 16 또는 32 asynchronous ports 지원

·VICP 는 driver card 에 연결되고, driver card 는 line card 에 연결됨

·driver card :

·VICP +5V 출력을 취하여 RS232 level 로 변환

·port당 driver 회로 결함을 감지하는 logic 포함 ( 16 port까지)

·line card : 8 I/O port 들에 대한 physical connector 와 관련 line 보호 회로 포함

·VICP controller : single mode 또는 fault tolerant mode

·fault tolerant mode :

·primaries : 한 controller 의 port 들, 실제 data 송신

·backups : 나머지 controller 의 port 들, output disabled

·character output 시 :

step1 : CPUSet 상에 device driver 가 primary VICP controller 에게 command를 보낸다.

step2 : primary controller 는 한 character 를 output 한다.

① driver card 상에 detector 회로로 먼저 주입

② character 송신

③ detector check

·character input 시 : character 들이 두 controller card 에 의해 read

- character 들을 받아들이기 전에, CPUSet 는 결함을 감지하기 위하여 두 card들간에 input character count 를 비교한다.

·VICP controller card 내의 결함은 heartbeat command packet 을 사용하여 UNIX device driver 에 의해 감지한다.

·sysconfig(8) tool : fault 발생시 system administrator 가 working ports 를 그 backup 으로 move 시키는 것

9. Operating System

·구성 software :

·CMS : user level

·solaris 2.X UNIX Kernel : kernel level

·virtual ideal hardware platform :

·Failure recovery s/w ⇒

·FTIO bus 용 FT nexus device driver

·device drivers

·I/O controller 용 FT leaf driver low level fixup

·DMR/TMR hardware

·low level software 와 device driver 는 고장 감지 후에도 계속 동작하도록 쓰여짐

·device driver :

·controller 들을 handle

·hardware 고장시 software recovery 전략 구현

·low - level fixup routines :

CPUSet 이 cpu 고장을 감지할 때, 그 문제를 진단하고 해결한다.

⇒ 시스템이 processing 을 계속 수행하도록 허용

10. CMS(Configuration Management System)

·CMS : 시스템 내의 변경에 대한 response 를 운영

·시스템 model 구성 요소 : 계층 구조적 item

·item : 모든 시스템 구성 부분 → physical(power supply)과 virtual disk partition

·attribute : item 의 상태

·response : CMS 에 의해 감지된 attribute 변화에 대한 대응

·higher level item 고장은 그 계층을 따라 하향 전달되며, lower level item 들을 offline 시킨다.

·변경은 errorlog device 로부터 CMS 로 보내지는 message 를 조사함으로써

확인한다.

step1 : device driver 는 error device 를 통해 message 를 issue

step2 : message 복사본이 CMS 로 보내진다.

step3 : CMS 는 그 device 의 현재 attribute 를 계산

step4 : 변경 발생시, CMS 는 그 대응 response initiate

·response :

- warning message

- phone home error reporting

- hell script 형태의 UNIX command

step5 : response 를 결정한 후, CMS 는 인식한 state 변경, response 이유 그리고 response 자체를 log 시킨다.

·ft - SPARC device driver 는 CMS 로 attribute 를 보고한다. 또한 IOCTL functions 가 추가되었다.

·IOCTL function : 특정 action 을 수행하도록 그 driver 에게 지시하기 위해서 user - level program 들을 사용 할 수 있는 function

→ 즉 device driver 는 response 동안 CMS 에 의해 사용되는 user-level controller program 과 pair(쌍)를 이룬다.

·user program 은 attribute 변경이 그 device driver 에게 pass 되도록 쓰여지거나 또는 그 driver 가 어떤 조치를 취하도록 쓰여진다.

·두 CMS user interface : fixit(8)과 sysconfig(8)

·Fixit : normal CMS user interface

·요청시, 시스템내의 모든 failed module 을 display

·three state lights :

·green for 'UNIX running'

·yellow for 'Needs Service'

·red for 'New Fault'

·fault 발생시

step1 : CMS 는 new fault light 를 set 시킨다. (2 light 는 user 가 조치를 취할 때까지 on 상태 유지)

step2 : 어떤 module 이 failure flag 를 on 시켰는지 결정하기 위하여 'fixit' invoke

step3 : - user 는 고장을 log 하기 위하여 support org 와 연락 또는

- CMS 는 service cent 에 자동으로 'phone home'

⇒ new fault right off and need service light on

step4 : user 는 고장 모듈을 제거하고 new module 로 대체

step5 : user 는 new module 을 re - integrate 하기 위해 fixit 사용

step6 : re - integration 완료시, need service light off

·Sysconfig :

·system item 과 distribute 를 display 하기 위해 사용되는 system configuration tool

·system developer 와 service engineer 에 위해 사용

11. Serviceability

·Easy - serviceability :

·각 system major component 는 power regulator 와 bus adaptor 를 포함한 self - contained module 이다.

·module 은 그 위치에 따라 self configure

·automatic power up/down

·Service overhead 감소

·low repair time 은 service cost 를 감소시킨다.

→ 대부분의 대체 시간은 '1 분'이내

제 2 절 하드웨어 개요

1. Introduction

a. Key components

·fault tolerance 하드웨어 design 특징 :

·모든 중요한 하드웨어 부품의 이중화

·module 화 : 모든 active 부품과 일부 passive 부품

·user 는 모든 module 을 시스템 동작을 중지시키지 않은 채로 대체시킬 수 있다 : hot-replacement

⇒ thumbscrew 가 모든 module 은 user replaceable

b. System Modules

·fault tolerance 기능을 갖춘 ft-SPARC basic configuration :

·2 CPUset modules : cpu & memory 포함

·drive subsystem :

·2 IOset modules :

·SCSI disk controller

·1 ∼ 2 hard disk drives

·single module 로 집적된 Ethernet controller

·서로 mirror pair 형성 (IOset 간)

·removable media drive module :

·첫 번째 IOset module 에 의해 control 된다.

·QIC, DAT, CD-ROM drive 등

·2 power modules

·One fan module

·Control panel

·Console part

·2 (1 FT port) Ethernet connections

c. Controls and connectors

(1) Control Panel

·3 LEDs : New fault : red

·Need Service : yellow

·Unix running : green

·Power switch : locked switch

(2) External Connectors

·serial I/O 또는 LAN subsystem 은 external connector 요구

d. Module Numbers

·모든 module 들은 module number 를 갖는다.

⇒ module 의 기능 및 호환성 표시

e. Module Characteristics

(1) Module Locations and Mnemorics

·module location 은 mnemonics 로 표시 : 예) S0, C0, T1

·cpuset locations : C0, C1

·IO module locations : S0 ∼ S6, S8 ∼ S14 ⇒ 2 groups

·IO module 은 disk 와 tape 를 포함한 모든 IO 동작 제어

(단 system console/modem connections 는 제외)

⇒ 예) IOset module, VICP serial IO controller modules

·2 FTIO buses B0 와 B1 : cpuset 과 IO module 간에

main data path

·S0 와 S8 은 기본 고장 감내 시스템의 IOset 으로 사용된다.

·S0, S8, S6, S14 : 다른 IO module폭의 두배인 IOset 에 사용된다. (다른 location에서는 IOset 이 두 slot 을 점유)

·IOset 은 SCSI device controller 내장

·Tape Module Locations : T0, T1

·T0 와 T1 은 IO module location S0 또는 S8 과 연결되는 자체 SCSI bus 를 갖는다.

·Power Module Locations : P0, P1

·각 module 은 두 독립적인 power bus 를 통해 28V(DC)를 다른 부품에게 공급한다.

·Fans Module Location : F0

·6 cooling fans

·Serial Communication Locations : R0 ∼ R7

·serial IO subsystem 을 위한 driver board module 과 line board module

·IO module location 에 있는 하나이상의 VICP module 과 연관해서 이 module들은 ft-SPARC system 과의 asynchronous serial IO traffic 을 취급한다.

(system console traffic 은 별도임)

·IO Connector Locations : M0 ∼ M7

·기타 IO connector 용

·Control Panel - CP

·시스템 동작중 control panel 을 대체하기 위해서 Power 스위치는 'ON'에 있어야만 한다.

·시스템의 serial 번호는 control panel 의 EEPROM 내에 저장되어 있다.

(2) Module Indicator LEDs : 최소 2 개 (green and red)

Power On(green) : off, change Me(red) : off ⇒ no power, offline

Power On(green) : on, change Me(red) : off ⇒ power on, normal

Power On(green) : off, change Me(red) : on ⇒ module 결함

Power On(green) : on, change Me(red) : on ⇒ integration 중

(3) Injector/Ejector Mechanism

·대부분의 module 에 대해, thumbscrew 는 module 이 삽입되거나 제거될 때 power-off condition 을 강요하기 위해서 module 의 power-handling 회로와 상호 작용한다.

·다른 module type 에 대해, thumbscrew 에 screw 하자마자 power-handling 회로는 switch-on 된다.

·잘못된 location 에 삽입된 module 들에 대해, module 들이 reintrgration 될 때까지 switch-on 이 되지 않는다.

f. Module Identification

·대체 module 을 install 하기 전에, 고장 module 과의 호환성을 점검

g. Fault Tolerance in an ft-SPARC System

·이 문맥에서, mains supply 의 결함은 normal hardware 결함이 아니다.

·Error Detection :

step 1 : 한 Cpuset 이 inconsistency(모순) 감지

step 2 : Cpuset 은 IO subsystem 과의 access 를 거부하도록 즉시 switch됨

step 3 : MCE(Master-Checker Error) exception handler 로의 error interrupt 발생

step 4 : good Cpuset 확인 및 master 화

step 5 : 대체 Cpuset 이 install 되고 re-integration 될 때까지 master Cpuset으로만 동작 계속

·CMS 는 고장 감내 IO subsystem 의 두 controller 모듈들 간에 연관 관계를 관리한다.

2. Configuration Management System (CMS)

·CMS 는 fault tolerance 를 위한 software

→ hardware 는 fault-tolerant non-stop 동작을 지원하는데 부족

·CMS 특징

·system definition file /etc/cms/sysdef

·각 hardware configuration 을 define

·hardware faillure 나 module 제거시 대응책 서술

·sysconfig (DEM/VAR 요원용)

·sysdef 에 대한 configuration 변경 지원

·fixit (일반 user 용)

·고장 module 대체에 필요한 기능 제공

a. System Definition File sysdef : configuration 을 위해 몇 개의 descriptor

·최소 요건 : CMS 는 시스템 내에 각 module 또는 object 에 대해 하나의 descriptor 를 요구

·sysdef 는 현재 이용할 수 있는 모든 hardware expansions 포함

·sysdef 을 edit 하는 경유 :

·현존 sysdef 에 없는 하나 이상의 module 을 추가하는 경유

·sysdef 에 의해 지정된 CMS 대응 방법을 변경하는 경우

b. Descriptors(또는 Data Structures) Used by the CMS

·module : 대체 가능한 hardware element

·object : module 그룹, module part 또는 다른 object 그룹

·각 type 의 module 이나 object 에 대한 sysdef 의 spec :

·한 모듈 또는 object 에 대해 descriptor 내에서 요구되는 element

·시스템 내에서 허용되는 module 이나 object 의 최대수

·Module and Object Types

Module types Object Types

cpuset power_subsystem

power cpu_subsystem

fans unit

control_panel FTnet

ioset ionet

tape

elp

null

c. Module Designations

·module 또는 object 명칭 : 'type-name' + '0 ∼ (n-1)' n: 최대허용 수

예) cpuset 1, fan_tray 0

→명칭에 사용된 번호와 physical location (예:F0, F8)간에 mapping 은 fix 안 됨. 즉 모듈에 대한 descriptor(object)는 아님)에 'location' attribute 를 포함시킴으로써 flexible mapping 제공

·geographical addressing scheme 사용 : 'location' attribute element 는 OS가 해당 module 을 access 할 수 있는 physical memory address 결성

·sysdef 는 'NULL' location 을 포함하여, 각 module 에 대한 설치 가능 location들을 열거한다.

·한 module 이 고장으로부터 대체중이므로 일시적으로 부재일 때 CMS 는 그 모듈이 이론적으로 존재하지만 일시적으로 access 할 수 없다고 간주

·Theoretical configuration : CMS 가 존재한다고 믿는 모듈과 관련 object 들

·physical configuration : 시스템 내에 실제 존재하는 모듈 set (실제 attribute 전보 포함)

·theoretical configuration 을 변경하기 위해서, CMS 에 의해 사용되고 있는 module descriptor 와 object descriptor 변경 필요

d. The sysconfig Utility

·어떠한 module 또는 object 의 attribute 와 constituents(구성원)를 보거나 수정하도록 도와준다 (단 system_attribute 는 변경 안됨)

·시스템 configuration 변경 :

·하드웨어 module 의 첨가, 이전, 제거 → physical configuration 변경

·fault-tolerant 결합 생성과 분리 : 고장 감내 결합 생성을 위해 mirrored pair 를 형성하기 위하여 unit object 를 사용하여야 한다. 즉 sysconfig 를 사용하여 이 unit의 constituent 들을 조정하고 mirrored pair 로 확인시켜야 한다.

·theoretical configuration 변경없이 상태 변경에 사용

→ fault-management tool

·CMS 는 OS 동작을 중지시키지 않고 일 수행

e. The Fixit Utility : end-user 용

· 고장 발생시 :

·NEW FAULT LED on

·system console 상에 message

·/etc/cms/status_log file 내에 measage

·대체 module install 후에 쉽게 re-integration 할 수 있도록 도와 줌

3. Hardware Configuration Changes

a. Possible Configuration

·basic configuration :

2 cpuset modules, 2 IOset module, one removable media drive

module, 2 power module, console port, one fans module,

2(one FT pair) Ethernet connections

· Extra subsystems :

Disk subsystem, LAN subsystem, WAN subsystem

b. Power Budget for 28-volt

·total DC power subsystem budget of 600 watts

4. Configuration Change Examples

·Configuration 변경 절차 (기본) :

step1 : physical configuration 변경 → 하드웨어 설치 또는 재배치

step2 : theoretical configuration 변경 → CMS 에게 physical configuration 변경 통보 및 반영 ('location' attribute 변경)

step3 : re-integration → system 상에서의 on-line 화

('reg_condition' attribute 를 'online'으로 set)

a. Adding a Hardware Module : SI location 에 한 ELP module 을 첨가하는 경우

(1) hardware 즉 physical configuration 변경

·SI location 에 ELP module 삽입

·관련 interface cable 설치

(2) theoretical configuration 변경 및 on-line

step1 : enter 'sysconfig'

→ 각 module 에 대해 1 line씩 현재 theoretical configuration display

step2 : enter 'i elp'

→ Not Here ELP module 을 포함한 모든 가능한 ELP module 을 display

step3 : enter 'e all present'

→ Hot Here ELP module 만 display

step4 : enter 'itemnumber' (display 왼편에 있는 line 번호)

→ 관련 descriptor 의 상세 내용 display

step5 : enter 'NULL location attribute 를 갖는 itemnumber'

→해당 attribute 에 대한 possible value 들 display

step6 : enter 'SI 값을 갖는 itemnumber'

<theoretical configuration 변경 완료>

<on-line 화> step7 : enter 'reg_condition attribute 에 대한 itemnumber'

→possible value 들 display

step8 : select 'online'

→CMS 가 성공적으로 완료시, 'condition' attribute 는 'offline'에서 'online'으로 변경됨

<on-line 화 완료>

·'condition' : system attribute

·New Fault LED on : 'reg_condition'이 'online'으로 변경될 때

off : 'condition'이 'online'으로 변경될 때

·'g' command : 'exit' from sysconfig

b. Removing a Hardware Module

·/etc/cms/sysconfig, rule file : sysconfig 를 통제

·module 상태가 'offline'인 경우에만 'location' attribute 변경 가능

·removing 절차

step1 : 'reg_condition'을 'offline'으로 set

step2 : 'condition'이 'offline'임을 확인

step3 : 'location'을 'NULL'로 set

step4 : 시스템으로부터 해당 hardware module 제거

c. Moving a Module to a New Location

·Removing + Adding 절차 이용

d. More Complex Configuration Changes

·mirrored disk 을 위해 IOset module 을 첨가하는 경우, 다음 사실을 CMS 에게 알려야 한다 :

·두 IOset 은 online 상태다.

·한 unit object (IOset disk mirrored pair 로 구성된 한 logical disk) 가 두 IOset에 유관하다.

→이때 두 IOset module 은 해당 unit object 의 'constituent'

·unit object 의 경우, constituent 에 배정된 값은 object 와 그 constituent 들간에 logical 상호 의존성만을 나타낸다.

·CMS 는 constituent 들간에 실질 의존성(physical dependency)이 실제로 존재하는지 점검할 수 없다. ⇒요원이 직접 check

e. Adding a Mirrored Pair of IOsets : disk 첨가

→고장 감내 IOset pair 설치

(1) hardware configuration 변경

·각 module 을 해당 location 에 삽입

(2) theoretical configuration 변경

step1 : enter 'sysconfig'

step2 : enter 'i ioset'

step3 : enter 'e all-present'

step4 : enter '해당 module itemnumber'

step5 : enter 'NULL location itemnumber'

step6 : select 'sb' (첫번째 extra IOset module 구성)

step7 : 이전 sysconfig menu 로 return 하여 두 번째 extra

IOset module 에 대해 동일 동작 반복

→select 's14'

<mirrored 절차> step8 : sysconfig 의 top menu 로 return

step9 : enter 'e all'

step10 : enter 'i unit' →각 unit object 당 1 line display

step11 : enter '미사용 itemnumber'

step12 : select 'null first_disk and second_disk constituents', 그리고 'IOset n1'과 'IOset n2'로 각각 변경

step13 : select '해당 reg_condition' attribute

step14 : 'reg_condition'을 'dualled'로 set

<mirrored 절차 완료>

<online 절차> step15 : mirror object 당 1 line 씩 display 하는 sysconfig

menu 로 return

step16 : enter 'i constituents itemnumber'

→새로 변경된 mirror object 에 대한 itemnumber 선택

step17 : select 'IOset n1 line'

step18 : select '해당 reg_condition' attribute

step19 : select 'online'

step20 : 'condition' attribute 가 'online'(수초이내)임을 확

<online 절차 완료> 인한 후, IOset n2 에 대해 step15 - step19 반복

<mirror copy 동작> step21 : 'mirror copy' 동작 시작

→1 분당 30MB disk copy, 시스템 내에 다른 load 가 있으면 더 느려질 수 있다.

step22 : integration 완료시 sysconfig 로부터 exit ('g' command 사용)

·/dev directory 내에 FTscsi : unit # node 를 통해 새로운 mirrored IOset pair를 access 할 수 있다.

·mirrored pair 상에 file system 을 만들려는 경우, 먼저 disk partition 을 정의하여야 한다. ("Disk partition" section 참조)

5. Drive Subsystem

a. Introduction

·drive subsystem 의 disk part 는 IOset module pair 로 이루어져 있으며, 각 IOset module 은 하나의 SCSI disk controller 와 하나 또는 두 개의 hard disk drive 를 갖는다. 또한 각 IOset module 은 하나의 Ethernet LAN interface 를 갖는다.

→ IOset module 의 SCSI part 와 LAN interface part 간에는 최소 interaction 존재

b. Hardware Reference Information

(1) Subsystem Modules

·drive subsystem 구성 modules :

·2 IOset modules (LAN controller 기능 포함) → s0, s8

·Cartridge tape drive 또는 removable media module → t0

·removable media drive module 은 고장 감내가 아님

·location s0 와 t0 는 hot-insertable SCSI bus 에 의해 상호 연결되어 있다. (s1 과 t1 도 동일한 경우)

(2) LED Indictors

·각 IOset 또는 tape drive module 은 두 개의 indicator LED 를 갖는다.

→Power On LED, Change Me LED

c. Software Reference Information

·세가지 주요 layers (drive subsystem 에 대한) :

·hardware layer : IOset 과 removable media module 로 구성

·mirroring layer : FT scsi device driver 내에서 구현

→단일 logical unit 으로 보이도록 두 IOset mirror pair 에 의해 제공되는 disk storage 를 함께 merge 시킨다.

·partition/winder layer : FT scsidevice driver 내에서 구현

·IOset module 에 대해, storage space 를 partition 들로 분할

·tape drive module 에 대해, rewind-on-close 기능 제공(option)

(1) Managing the Hardware Layer of the Drive Subsystem

· 일반적으로 location sb module 에 대해 ioset2, location s14 module 에 대해 ioset 3 을 사용한다.

·최대 허용 IOset 수 : 8

·'reg_condition' attribute 를 'online'으로 변경한 후 (IOset module 첨가시), CMS 는 configuration 에 대한 device driver 의 관찰(view)이 'location' setup 과 일치하도록 보장하는 command 를 device driver 에게 보낸다.

(2) Managing the Mirroring Layer of the Drive Subsystem

·mirroring layer 와 partitioning layer 간에 interface 에서, 각 IOset 또는 mirrored IOset pair 에 의한 storage 가 한 logical unit 으로 나타내어진다.

→한 IOset 또는 IOset 들을 시스템에 참가할 때마다, CMS 에서 한 unit object 를 setup 시켜야 한다.

·mirrored pair 를 생성하거나 분해하기 위해서 하나 이상의 unit object 에 대한 configuration 을 변경시켜야 한다.

·location sb 와 s14 를 사용하는 mirrored IOset pair 에 대해 unit1 을 사용

·IOset 들을 별도 unit 으로 사용하는 경우(sb 와 s14 에 대해) unit1 과 unit2 를 사용

·single IOset 을 첨가하는 경우, 'first_disk'나 'second_disk'를 CMS IOset module name 과 일치하도록 변경

(3) Managing the partitioning/winder Layer of the Drive Subsystem

·이 layer 는 tape drive 를 access 하는 winder 기능에 대해 전혀 관리 불요구

→/dev/rmt directory 내의 node 를 통해 이 기능을 access

·여분의 mirror IOset pair 를 추가하는 경우, partition 들을 생성하기 전에 sysconfig 를 사용하여 pair 를 형성시켜야 한다.

→두 IOset 이 동일 size 인 경우, 한 IOset size 가 pair 를 access 하는 logical disk의 sized 와 동일하므로 위의 절차가 필연적인 것은 아니다.

·Disk Partitioning

·Administrative area " IOset 의 처음 2MB disk space 점유

→ booting-up 시, OS install 시, drive subsystem 에 대한 configuration Management 동작시, 시스템은 이 area 를 access

·Normal partitions " swap partition 과 UNIX file system 을 포함하는 partition

·Manual Disk Partitioning

·Partition 이 system boot 후에 이용될 수 있도록 다음 command 들은 shell script 내에 포함되어야 한다.

·partition 생성 방법

step 1 : IOset module unit 이 online 임을 확인

step 2 : unit 내에 disk size 설정

→scsictl unit# size (byte)

step 3 : 새 partition 을 생성하기 전에 이미 사용중인 disk part 확인

→ disk usage 정보를 보기 위하여 'scsictl show' 사용

step 4 : partition 생성

→ scsictl make part # : partition on unit # at base(byte) size(byte) size(byte)

step 5 : partition 상에 minor objects 를 생성하는 경유

→ scsictl make part #_m : minor type bc sub part #

step 6 : /devices 내에 devices 생성

→ drvconfig -i FTscsi

step 7 : /dev 내에 link 생성

→ devlinks -t/etc/cms/drv/FTscsi.tab

·완료시, 해당 partition 에 대한 device 는 다음과 같이 보여준다:

/dev/FTscsi : part #_m block

/dev/FTscsi : part #_m, raw character

(4) Driver Initialization

·IOset partition 은 IOset 자체의 partitioning 에 대한 정보를 포함하기 때문에, 이 정보를 해독하기 위해서 FTscsi driver 는 어떤 가정을 만든다.

·가정 : ·boot IOset 들은 location S0 와 S8 에 있다.

·이 IOset 은 각각 해당 IOset 의 첫 번째 2MB disk space 내에 administrative area 를 갖는다.

·tape drive 는 location T0 에 있다.

6. Ethernet LAN Subsystem

a. Introduction

·두가지 Ethernet LAN interface 구현방식

·IOset module 에 포함된 LAN interface

·LAN interface 만을 제공하는 ELP module

(1) configuration

·두 LAN interface 들로 구성되는 subsystem :

·단일 고장 감내 Ethernet LAN subsystem

·두개의 비 고장 감내 Ethernet LAN subsystem 들

·각 IOset module 의 drive software 는 정상 동작중에 이 module 의 LAN part 와 거의 interaction 을 갖지 않는다.

→ 즉 두 기능을 한 module 로 통합

b. Hardware Information

(1) Hardware Required

·시스템 cabinet 내부

·IOset 또는 ELP module

·각 IOset 이나 ELP module 에 대해, 하나의 cable assembly CABLE-ENET.

·시스템 cabinet 외부

·각 Ethernet module 에 대해, 하나의 Ethernet transceiver 와 하나의 transceiver cable

·고장감내 LAN subsystem 에 대해, 그 시스템에 연결된 두 개의 transceiver 는 동일 Ethernet network cable 상에 있어야만 한다.

(2) LED Indicators

·LAN subsystem 내의 각 controller module 은 두 LED 를 갖는다:

·Power On LED

·Change Me LED

c. Software Reference Information

·Ethernet LAN subsystem 하드웨어를 추가하거나 변경한 후, 다음 소프트웨어 조종을 수행하라

·hostname 을 integrate 하라

·¡etc/nodename file 은 system hostname 을 포함해야 한다.

·IP address 를 갖는 hostname 에 대한 entry 는 /etc/hosts 내에 존재해야 한다.

·hostname 은 /etc/hostname/FTnet0 file 내에 역시 존재해야 한다.

⇒ second LAN : hostname 1, third LAN : hostname 2

·sysconfig 를 사용하여, 새 하드웨어를 online 시켜라.

(1) Adjusting the CMS view of the Subsystem

·CMS 관점에서 본 LAN subsystem 의 두 주요 layers :

·hardware layer : IOset 또는 ELP module 에 의해 제공된 LAN interface 로 구성

·device driver 내의 paralleling layer : subsystem 의 logical interface

→고장감내 Ethernet LAN subsystem 의 경우, 이 layer 는 두 LAN interface 들이 단일 고장 감내 interface 로 보이도록 해준다.

·IOset module 내의 LAN interface 에 대해 세 번째 layer 존재

→ 세 번째 layer 내에 IOset module 은 drive subsystem 에 속하며, LAN subsystem 에 속하지 않는다.

·정상 시스템 동작 동안, FTnet device driver 는 그림 c-1 관계를 알고 있다.

→ boot 시, CMS 는 /etc/cms/configfile file 로부터 이 정보를 읽어 해당 driver 로 pass 한다.

·sysconfig 에 의한 변경은 FTnet device driver 와 /etc/cms/configfile file 로 전달된다.

(2) Managing the LAN Interfaces

·IOset 이 LAN interface 를 제공하는 경우, CMS 는 IOset 의 LAN 기능을 표현하기 위해서 IOset object 를 사용한다.

·IOnet 은 module 이라기 보다 object 이므로 'location' attribute 를 갖지 않는다. 그 대신에 IOnet 은 각 IOnet object 와 IOset module 간에 1 대 1 mapping 을 제공하는 한 controller constituent 를 갖는다.

→ 두 개의 다른 device driver 가 하나의 CMS entity 와 interact 하는 상황을 회피

·IOnet object 는 CMS 와 FTnet driver 간에 상호 작용(interact)을 다루며, scsi device driver 는 IOset module 과 상호작용한다.

·관례적으로, ionet n 의 controller constituent 는 ionet n 으로 set 된다.

·ELP module 이 LAN interface 를 제공하는 경우, ELP module 과 상호작용하는 하나의 device driver 만이 존재하므로 CMS 모델의 hardware layer 는 여분의 object 를 포함시킬 필요가 없다.

→ hardware layer 에서 각 ELP 는 elp module 로 표시된다.

·한 module 추가시 sysconfig 를 이용한 변경 방법 :

·IOset module 추가시 :

·대응 ionet object 의 'req_condition'을 'online'으로 set

·ELP 추가시 :

step 1 : 미사용 elp module 선택

step 2 : ELP module part 번호와 일치하는 type 과 revision

step 3 : 'location' 'sn'

step 4 : 'req_condition' 'online'

·변경후, CMS 는 driver 의 configuration 관점이 setting 된 configuration 과 일치하도록 보장하기 위해서 FTnet device driver 로 한 command 를 보낸다.

·IOset 또는 ELP module 제거시, 'req_condition' 과 'location' attribute 만을 변경하라.

·IOset module 에 대해, IOset module 의 setting 을 변경하기 전에 IOnet object의 setting 을 변경하라

→요구 setting :

·'req_condition 을 'offline'

·'location'을 'NULL'

(3) Managing the Paralleling Layer of the LAN Subsystem

·IOset 또는 ELP module 를 추가할 때마다, 새 LAN interface 를 다루기 위하여 FTnet object 를 set up 시킬 필요가 있다.

·미사용 FTnet 은 first_net 과 second_net constituents 가 null 0 임.

·FTnet object 와 동일 suffix 를 갖는 시스템 hostname 를 포함하도록 /etc/hosts file 를 수정하라

→ 예) FTnet 2 에 대해 hostname 2

·basic 시스템 configuration 에서의 두 IOset module 의 LAN

interface 에 의해 형성된 logical interface 에 FTnet 0 을 사용하라.

·사용할 FTnet object 를 결정한 후, sysconfig 를 사용한 변경 방법 :

·first_net 에 대한 두가지 방법

·첫번째 LAN interface 가 IOset 에 있는 경우 : ionet n

·첫번째 LAN interface 가 ELP 에 있는 경우 : elp n

·second_net 은 ionet n 또는 elp n 으로 set

·first_net 과 second_net constituent 는 다를 수 있다.

→ 하나는 network object, 나머지는 elp module

·나머지 configuration 부분들이 모두 완료되면, CMS 는 network interface 가 on-line 임을 보증하며 고장 감내 기능을 제공한다.

(4) Ethernet Addresses

·각 시스템은 16 개의 유일 Ethernet address 를 배정받아 control panel 의 EEPROM memory 내에 저장한다.

·Eth_net address 들과 8 개의 LAN subsystem 들간에는 1 대 1 mapping 이 존재한다.

·각 IOset 또는 ELP module 초기화는 적절한 Ethernet address 와의 초기화를 포함한다.

→고장 감내 subsystem 을 구성하는 두 controller module 들에 대해 동일 Ethernet address 사용

·IOset 과 ELP controller module 들은 built-in Ethernet address 를 갖지 않는다.

제 3 절 고장 감내 기술

1. OEM Device Integration

a. Module Integration

·ft-SPARC 시스템으로 새 driver 를 갖는 IO device 를 integrate 시키는데 필요한 절차 :

step 1 : 고장감내 device driver 작성

(driver 내에 CMS interface 포함)

step 2 : device 를 한 module 로 assemble

step 3 : 시스템 내에 모듈 장착

step 4 : Abdication process 구동

2. Creating Fault Tolerant Device Drivers

a. Kernel Level Device Drivers

·고장 감내를 성취하기 위한 4 가지 변경 사항 :

(1) Driver Hardening

·최소 조건으로 IO device 내에서 발생하는 결함이 kernel 내에 어느 다른 부분도 오염시킬 수 없다는 것을 driver 는 보장해야 한다.

(2) Fault Detection

·driver 는 IO device 내에 결함을 감지하고, 그 device 를 offline 으로 mark 할 수 있다.

(3) Fault Correction

· 고장 감지시, driver 는 결함 IO device 로부터 backup IO device 로 IO 동작을 자동으로 전환시킬 수 있다.

·그 device 가 CMS 에 위해 관리될 예정이라면 그 driver 는 CMS interface 를 포함시켜야 한다.

(4) Driver Conversion : ft-SPARC 용으로 Solaris 2 driver 변환 방법

① Directory Structure

·대부분의 ft-SPARC file 들은 /etc/cms 하에 있으며, 다음 directory 들을 포함한다.

·bin : 실행 프로그램 또는 shell scripts, ft driver 들에 대한 drv binary들, .tab, .conf

·FTheaders : ftddi interface 에 대한 header file 들

·hw_headers : hardware 서술 header file 들

·src : CMS daemon (configd) example driver 를 만드는 장소

·PC : PCs (logic analyzer) 상에서 사용할 프로그램들

·lib : library 들

② Locations

·ft-SPARC system 은 module set 들로 이루어져 있다.

·모든 module 은 한 location 을 가지며, 각 location 이름은 ft-SPARC 내에 주 indexing 시스템으로서 사용된다.

③ Virtual Addresses

·현 Solaris kernel 에서 virtual address space 는 제한되어 있다.

·'ftddi_map_regs()' call 은 virtual space 를 배정한다.

·IO card 에 대해 대량의 virtual space 가 필요한 경우, ftddi_copy 를 사용하여 card 와의 data copy 를 수행할 수 있다.

→ 큰 block 의 data 를 copy 할 때 특히 효과적임

④ DMA

·FTIO bus 는 단일 master (CPUset 들의 insync set) bus 이다.

·DMA 를 사용하는 IO card 에 대해, 데이터 전송시 bridge card 들 상에서 이용할 수 있는 local RAM 을 사용해야 한다.

→IO card 의 DMA master 는 local RAM 에 데이터를 전송하며, processor 나 Cpuset 의 DMA controller 는 그 데이터를 main core 로 전송한다. 그러므로 driver 는 local RAM 배정을 다루어야 한다.

·CPUset 은 FTIO bus 상에서 이용할 수 있는 bandwidth 를 증가시키기 위해 DMA controller 를 포함한다.

·'ftddi_copy' routine 은 block 데이터 전송시 사용되어야 한다.

→이 루틴은 DMA 를 사용할 것인지 programmed IO 를 사용

할 것인지 자동으로 결정한다.

⑤ Instances

·Solaris kernel 은 한 driver 의 multiple instances 를 갖는 능력을 제공한다.

·각 instance 는 그 자신의 data space 를 갖지만 해당 driver 의 나머지 instance들과 text 와 global data 를 공유한다.

·single instance driver 사용 또는 multiple instance driver 사용 선택 가능 :

·multiple instance driver 사용 : IO subsystem 내의 각 card 가 독립적이고, 그 driver 가 traffic 을 switch 하지 않는 경유

·single instance driver 사용 : card 들간의 통신 요구

⑥ Attach/Probe

·standard Solaris driver model 에서, kernel 은 startup 시 driver probe routine 을 call 한다. 그 driver 의 prove routine 이 'true'를 return 하면, 그 driver 의 attach routine 이 call 된다.

→ 즉, 그 device 가 startup 시 존재하지 않으면 그 driver 는 attach(소속)되지 않는다.

⇒ft-SPARC 과 같이 hot pluggable 시스템에 대해 부적절

·ft-SPARC 에 대해, CMS 는 무엇이 존재해야만 하는지 한 driver 에게 알려준다. 그때 그 driver 는 device probing 대신에 실제로 존재하는 device 들을 점검한다. 그 driver 는 probe call 시, DDI_NOTCARE 를 return 해야 하며, 그것은 attach routine 이 향상 call 되도록 만들어 준다. probe 나 attach routine 내에는 IO card에 대한 어떠한 access 도 없어야 한다.

⑦ changes to support ft_SPARC environment

·주요 변경 :

·device register 들이 kernel 로 map 되는 방법

·interrupt 들이 register(기록)되는 방법

·ddi_map_regs → ftddi_loc_map

ddi_unmap_regs → ftddi_loc_unmap

·ddi_add-intr() → ftddi_add_intr

ddi_remove_intr() → ftddi_remove_intr

·ftddi_vme_iak 요구 :

interrupt acknowledge 가 hardware bit 에 의해 자동으로 이루어지는 전통적인 시스템 내의 한 VME board 로 interrupt acknowledge 를 발생시키기 위해 필요

→ ft-STARC 에서, interrupt routine 이 call 될 때 ftddi_vme_iack 이 call되어야만 한다.

b. Driver Hardening

(1) Capture Data to the FT Core

·어떤 값이 그 device 상에서 점검되었고 re-read 는 정확할 것이라고 가정하지 마라. 먼저 그 값을 core 로 읽어 들여라.

(2) Loop Termination

·모든 loop 에서 종점이 있도록 하라. 즉 loop 상에 제한을 두어라.

(3) Static States

· 어떤 status 값이 부정확하게 return 되는 경우 발생할 수 있는 infinite loop 들을 점검하라.

(4) FTIO Bus Modules

·FTIO bus 에 plug 되는 module 들에 대한 device driver 들을 어떠한 IO slot 에 있는 device 들도 지원해야만 한다.

(5) checklist

·driver hardening 을 위한 점검 목록 :

·한 device 로부터 읽는 모든 데이터와 pointer 들을 점검하라.

·한 device 로부터 return 되는 pointer 들이 제대로 정렬되어 있도록 보장하라.

·control 데이터에 따라 수행하기 전에 그 데이터를 core 로 read 하라.

·모든 loop 가 무조건 종료하도록 보장하라.

c. Fault Detection

(1) Device Error Detection

·Device error 들을 core 내에서 transport protocol 을 구동시킴으로써 감지될 수 있다. 이 protocol 은 kernel 또는 user space 내에 drive 이내 또는 상위에서 구동될 수 있다. 그 driver 는 이 protocol 에 대해 알 필요가 없다.

예) Ethernet subsystem 에서, driver 내에 transport protocol 이 없지만 kernel 내에서 구동하는 TCP 가 data integrity (데이터 정확성)를 보장한다.

→ 이 경우 그 protocol 은 한 error 가 감지되었다는 사실을 그 driver 에게 신호로 알려주는 방법을 갖고 있지 않다. 그러므로 필요시 backup IO device 로 switchover 할 수 있도록 그 driver 는 별도로 결함을 감지해야만 한다.

(2) Fault Detection in the Driver

·한 driver 내에서 구동하는 한 protocol 로서, disk driver 에서 사용되는 end-to-end checksumming 이 있다.

→ error 감지시, 그 driver 는 결함을 정정하는 조치를 취한다.

d. Fault Correction

·device dependent 이지만 가능한 transparent 한 방식으로 이루어져야 한다.

·fault correction 은 자주 교체(alternate)device 로의 switching 동작을 의미한다.

·교체 device 로의 switch 시 잠재하는 함정은 error 를 감지하고 switchover routine 을 call 한 후 결함 device 와 관련된 variable 이나 pointer 를 사용하여 processing 을 계속하는 것이다.

·두 번째 device 가 install 되어 있지 않거나 이미 고장난 상태에서, 첫 번째 device에 error 가 발생하는 경유 필연적으로 offline 시키지 않아야만 한다. 그 대신 가능한 결함 device 에서 정상 driver 가 일하듯이 행동해야만 한다. 이것은 false positive가 그 device 에 의해 제공된 service 를 이용할 수 없도록 하지 못하도록 보장한다. (false positive : 한 device 가 결함이 있다고 감지되었으나 실제로 아닌 경우 또는 subsystem 의 또 다른 부분이 에러를 일으키고 있는 경우)

· switchover 때까지 사용되지 않는 secondary device 를 지원하는 driver 에서, 그 driver 는 미사용 device 가 제거되지 않았다는 것을 보장하기 위해서 적당히 자주 (즉 매초당 한 번) 미사용 device 를 점검해야만 한다. 이 점검은 board 가 초기화되자마자 그 board 에 magic 번호를 write 하고 watchdog routine 에 이 번호를 점검하는 driver 에 의해 달성될 수 있다. 이것은 driver 가 재초기화시키지 않은 채, 제거되거나 대체중인 board 의 문제를 해결한다.

(1) Latent Faults (잠복성 결함)

·latent fault 는 어떤 다른 fault 가 발생할 때까지 그 자신을 나타내지 않는 fault이다.

·일반적으로 latent fault 를 감지하지 않은 채 남겨둔다면 궁극적으로 시스템 고장을 유발시킬 것이다. latent fault 점검없이, 이중화 시스템의 전체 시스템 신뢰도는 단순 시스템보다 겨우 약간 높을 수 있다.

· 고장 감지 device driver 가 latent fault 를 감지할 수 있는 효과적인 방법은 controller 들의 primary 와 secondary 역할을 자주 switch 하는 것이다.

→ 이 경우, 두 controller 가 완전히 동작중임을 보장한다.

(2) Transient Faults

·transient fault 는 단 한번 발생하고, 그 결함으로부터 시스템이 회복된 후 결코 재발하지 않는 fault 이다.

·모든 진짜 transient fault 는 noise 에 의해 발생한다.

·noise source 가 존재해야만 한다.

·이 source 로부터의 noise 는 noise 에 민감한 시스템 부분에 도달할 수 있어야만 한다.

·transient fault 를 일으킬 수 있는 요소 :

1. module 설계시 error : 가장 흔함

2. 외부에서 생성된 noise 가 AC power 나 signal line 을 통해 전도되거나 Alpha particle 등에 의한 방사로 인해서 시스템에 들어갈 수 있다.

3. noise 는 시스템에서 기계적으로 생성될 수 있다. (이것은 partial oxide breakdown 과 같은 IC 회로내의 문제를 포함한다) 간헐적인 연결이 이 경우 가장 흔한 noise source 다.

4. False positive 는 고장 감지 하드웨어나 소프트웨어 내에 error 들에 의해 발생될지도 모른다.

·Transient fault 는 발생하지 않는다고 가정되므로 모든 의심나는 그러한 fault 는 해당 module 의 repair 를 요구한다. 유일한 예외는 alpha particle 에 의한 RAM error 와 같이 물리적 현상에 의한 fault 이다. 이 경우에 결함 module 의 reintegration 이 허용된다.

·위 방식 적용시 결론 :

1. 설계 error 는 명백히 수정되어야만 한다.

2. ft-SPARC 시스템은 외부 간섭에 대해 매우 잘 보호되므로 외부 noise source 는 거의 문제를 일으키지 않아야 한다.

3. 내부 noise source 들이 진짜 고장이다 : 그 고장들은 재 발생될 수 있기 때문에 transient error 로 간주되지 않아야 한다.

·module history(EEPROM 내에)에 포함된 고장 정보는 OEM 이 고장원인을 추적하도록 허용해 주며, 결론적으로 설계 error 를 입증하도록 도와줄 지도 모른다.

·transient error 가 잘 알려진 경우, 결함 module 은 자동으로 reintegrate 될 수 있다(예로, 시스템이 sync 로부터 벗어나도록 만드는 정정할 수 있는 memory error

들) driver 는 CMS 에게 무슨일이 일어났는지 보고하고, CMS 는 그 모듈을 reintegrate 한다.

·한 driver 내에서 채택 가능한 고장 감지 방법들 :

·drive hardening 소프트웨어에 의해 감지된 문제들은 실제로 device 결합이라고 한다.

·'I am alive' protocol 을 가져라.

·가장 간단한 형태는 IO device 가 가능한 자주 한 magic 번호를 write 하도록 하는 것이다. I device driver 는 주기적으로 이 magic 번호를 점검한 후 없앤다. 이 방법은 processor stopping 과 같은 IO device 내의 총체적 결함들을 감지한다. 즉 이 기법은 대부분의 결함을 감지한다.

·또 다른 protocol 은 IO device 로 null command 를 보낸 후 그 driver 로 return시킨다.

·모든 command block 을 time stamp 하고, 주기적으로 제시간 내에 완료하지 못한 block 들에 대해 점검하라.

→ reasonable time 을 결정하는 문제가 존재

·command block 들을 checksum 하라,

·IO device 로부터 bus error 에 대한 slot access control circuit 를 점검하라.(아래 참조)

·IO device 상에서 주기적으로 진단 test 를 구동시켜라.

→ 가능하면 primary 와 secondary IO device 들간에 구동되어야 한다.

(3) Slot Access Control Circuit

·각 FTIO bus slot 에 대한 access 는 'enable' 또는 'disable'될 수 있다.

·access 가 enable 일 때, read 나 write 는 정상적으로 발생

·access 가 disable 일 때, slot access 는 bus 를 access 하지 않은 즉시 'transfer-acknowledge'를 return 한다.

·desabled access 는 read 시 random data 를 return 하고, write 시 아무 일도 하지 않는다.

·이 control circuit 를 slot RAM 이라 일컫는다.

·한 bus error 가 발생할 때, virtual machine exception code 는 결함 address 를 조사한다. 만약 그 에러가 한 IO module 내에 존재한다면, exception code 는 그 결함 slot 을 disable 시킨다. 그후 그 driver 는 bus error 를 더 이상 발생시키지 않으면서 그 module 에 대한 access 를 계속할 수 있다.

·궁극적으로 driver 는 한 bus error 가 존재한다는 것을 나타내기 위해 'ftddi_loc_disabled()'를 call 해야만 한다. 그후 그 driver 는 결함을 보고하고 해당 module 을 offline 시켜야 한다.

·module 이 online 으로 복구되도록 시도하기 전에 해당 slot 은 'slotctl' command를 통해 재 enable 된다.

·VME bridge adaptor 는 예기치 않은 특성을 갖는다 :

그 adaptor 가 bus error 를 생성하자마자, adaptor power 가 희귀될 때까지 그 adaptor 는 그 slot 에 대한 더 이상의 bus cycle 에 응답하지 않는다. 몇몇 VME card 들은 host 에 의해 access 될 수 있기 전에 그 내부 회로를 초기화할 필요가 있기 때문에 이러한 일이 한 문제일 수 있다. 재초기화 도중 그 card 가 bus error 를 일으키지 않도록 보장하기 위해서 한 slot 에 power 를 인가한 후 충분한 시간이 허용되어야 한다.

·slot access control circuit 가 check 되는 시점은 신중히 고려되어야 한다. 일반적으로 OS 로 데이터를 return 하기 전에 점검이 이루어져야 한다. 정확한 error가 보고되도록 slot access control 은 모든 error 조건에서 점검되어야 한다.

3. FTIO Bus

·Simple single master IO bus\

·Support the following properties

·hot insertion/removal

·arbitrary locked sequences

·64 bit block transfers

→ use address bus for extra data bits

·Data Bus : B_D (0.....31)

·Parity Word Bus : B_DP64(0....7) or B_DP(0....7)

·B_DP64(4....7) : Parity data for B-D(0....31)

·B_DP64(0....3) : Parity data for B_A(0....31)

or 64 bit block transfer

·Data Enable Bus : B_DE/L(0....3)

·Big-endian addressing

Address Data Enable Parity0 B_D(31...24) B_DE/L(0) B_DP64(4)1 B_D(16...23) B_DE/L(1) B_DP64(5)2 B_D(8...15) B_DE/L(2) B_DP64(6)3 B_D(0...7 ) B_DE/L(3) B_DP64(7)

·Address Bus : B_A(0.....31)

·IO addressing range : 32 Mbytes per slot

·8 slot addresses

·B_A(2....28) defined as address line

·B_A28 high : FTIO bus slave 에 의해 decode

·B_A28 low : CPU set 상에 slave device 에 의해 사용

·All Accesses : Alignment on the same boundary as their size byte : 2 ∼ 5/2 byte

·Write/Read Bus : B_WRITE/L

·B_WRITE/L asserted ⇒

·Locked Sequence Bus : B_LOCK/L

·전송은 Locked Sequence 로 이루어짐

⇒ lock 된 IO module 은 lock 시킨 module 에 의해서만 access 가능

·undefined operation 제공

·Block Transfer Bus : B_BLOCK/L

·block data 전송

·32 bit 또는 64 bit block 전송 지원

·Block 전송 동안 모든 B_DE(0....3)/L lines Asserted

·64 Bit Transfer Bus : B_64BIT/L

·B_D(0....31) & B_A(0....31) 사용

·단지 block 전송시에 사용 가능

·undefined operation 제공

Address Data Parity0 B_A(24....31) B_AP64(0)1 B_A(16....23) B_DP64(1)2 B_A( 8....15) B_DP64(2)3 B_A( 0....7 ) B_DP64(3)4 B_D(24....31) B_DP64(4)5 B_D(16....23) B_DP64(5)6 B_D( 8....15) B_DP64(6)7 B_D( 0....7 ) B_DP64(7)

·Address Strobe : B_AS/L

·실제 Address 전송

·Address 는 B_AS/L 이 assert 되기 전 setup time 동안 유효하며, assert 된 후 hold time 동안 지속

·Address 는 B_AS/L leading edge 시 latch

·Block 전송시 전체 block cycle 동안 B_AS/L 지속

·Data Strobe : B_DS/L

·실제 Data 전송

·Write cycle : data 와 parity 는 B_DS/L leading edge 에서 setup 되고 지속됨

·Read cycle : slave 는 B_ACK/L leading edge 에서 data 를 setup 시키고 B_DS/L trailing edge 까지 지속

·Timeout 시 B_DS/L 은 통고없이 제거

·Block 전송시 각 word당 한번씩 B_DS/L asserted

·64 bit write : (master)

step 1 : put address

step 2 : assert address strobe

step 3 : address hold time까지 대기

step 4 : address line 을 64 bit data line 으로 변경

step 5 : assert B_DS/L

·64 bit Read : (master)

step 1 : put address

step 2 : assert address strobe

step 3 : address hold time까지 대기

step 4 : tristate address line

step 5 : assert B_DS/L

·B_RESET/L

·unused, reserved line

·FTIO bus slave 의 reset 은 maintenance bus 를 통해서 수행

·B_R(0....3) : Reserved Lines

·Acknowledge Bus : B_ACK/L

·B_DS/L 을 제거하도록 master 에게 알리는 slave 의 신호 응답

·Error 시에는 B_ACK/L 을 assert 시키지 않음

·slave 는 최대 허용 시간내에 B_ACK/L 로 응답해야 함

(응답 실패시 master 는 timeout 되고 해당 cycle 종료)

·Interrupt Bus : B_SIRQ/L(0....7)

·각 IO slot 으로 부터의 radial interrupt lines (8 개 IO slot)

·Any time, Asynchronous Interrupt

·Maintenance Bus : B0_MBSCL B0_MBSDA

B1_MBSCL B1_MBSDA

CPU_MBSCL CPU_MBSDA

PM_MBSCL PM_MBSDA

·4 maintenance buses

·각 maintenance bus 는 12C chip 들에 연결되도록 설계

·MBSCL : clock

·MBSDA : Data

·Polling 방식 사용 : 무슨 일이 발생하였는지 발견하기 위해서 CPU set 은 slave device 들을 poll

·Slot Address : SA(0....2)

·maintenance bus 와 general address decoding 에 사용

·IO module 이 bus 0 에 속하는지 bus 1 에 속하는지 알릴 수 있는 mechanism 이 없음

그림 1. 타이밍 분석도

그림 2. 타이밍 분석도

· B_DS asserted → slave drive : 0, 0

· B_AS negated → slave tristate : 40, 40

· B_AS asserted → B_DS asserted : -15, -30, 1000, 1000

· B_DS asserted → B_DS negated : 0, 101000

· B_DS negated → B_DS asserted : 50, 35, 1000

· B_DS negated → B_AS negated : 30, 15 (normal, min)

-15, -30 (timeout, min)

1000, 1000 (max)

· B_AS negated → B_AS asserted : 80, 65

· B_LOCK negated → B_LOCK asserted : 50, 35

· B_AS negated → B_LOCK negated : 30, 15