KR20120054142A - ＱｏＳ 및 전송 효율 개선을 위한 ＳｏＣ 기반 시스템 네트워크에서의 인터페이스 장치의 통신방법 및 그에 의해 통신하는 인터페이스 장치 - Google Patents

Abstract

QoS 및 전송 효율 개선을 위한 SoC 기반 시스템 네트워크 프로토콜이 개시된다. 네트워크를 통한 통신을 개시하는 인터페이스인 개시자 및 개시자의 통신 개시에 응답하는 인터페이스인 목적지 사이에서의 데이터 전송을 위한 네트워크 프로토콜에서는 개시자로부터 채널을 통해 목적지로 전송되는 전송 신호 또는 상기 채널을 통해 목적지로부터 전송되는 응답 신호에 포함된 정보를 정의하는 명령어를 포함하되, 최상위 비트가 네트워크에서 개시자와 목적지 사이의 트랜잭션의 우선순위를 나타내는 커맨드 신호가 전송되며, 전송 신호에 포함된 제어 정보는 우선순위 필드를 포함하는 복수의 필드로 구성되고, 트랜잭션의 우선순위는 커맨드 신호의 최상위 비트 및 우선순위 필드를 조합하여 얻어진 값을 기초로 결정된다. 본 발명에 따르면, 커맨드 신호의 최상위 비트 및 전송 신호의 제어 정보에 포함된 우선순위 필드에 의해 트랜잭션의 우선순위를 결정함으로써 기존에 하드웨어 상에서 우선순위를 고정적으로 결정하였던 것과 달리 소프트웨어 상에서 유동적으로 우선순위를 제어할 수 있다. 또한 정렬 및 비정렬 주소에 대한 지원을 강화함으로써 사용자가 원하는 바이트 레인을 용이하게 사용할 수 있으며, 자주 단일 데이터를 교환하는 개시자와 목적지 사이의 통신이 제어 정보 없이 가능하도록 함으로써 전송 효율을 높일 수 있다.

Description

ＱｏＳ 및 전송 효율 개선을 위한 ＳｏＣ 기반 시스템 네트워크 프로토콜{SoC-based system network protocol for QoS and improvement of transfer efficiency}

본 발명은 QoS 및 전송 효율 개선을 위한 SoC 기반 시스템 네트워크 프로토콜에 관한 것으로, 보다 상세하게는, 칩 기반의 시스템에서 데이터 교환을 위한 네트워크 프로토콜에 관한 것이다.

반도체 공정 기술과 시스템 설계기술의 발달로 인하여 시스템 온 칩(System-on-Chip : SoC) 기술은 최근 급속도로 발전해왔으며, 시스템을 구성하는 기술과 방법이 다양화됨에 따라 SoC 내부구조가 더욱 복잡해지고 있다. 또한 고품질의 다양한 멀티미디어 데이터에 대한 요구로 인해 처리해야 할 데이터의 양이 기하급수적으로 늘어났다. 이를 위해 병렬 처리를 위한 다중 프로세서를 내장하며 다양한 기능을 보유하기 위해 각종 통신 및 주변 장치용 IP가 포함되어 여러 개의 칩셋으로 시스템이 구성되고 병렬 처리를 위해 네트워크 온 칩(Network-on-Chip : NoC)의 도입이 연구되는 등 시스템 내부의 통신이 매우 복잡해지고 있다. 이에 따라 시스템의 성능이 연산기의 연산 능력보다는 데이터 통신 성능에 의해 더 큰 영향을 받게 되었고, 이러한 문제를 해결하기 위해 다양한 온 칩 네트워크(on-chip-network) 구조와 프로토콜에 대한 연구가 진행되었다.

AMBA AHB, AMBA AXI, WISHBONE, CoreConnect, OCP, SNP, XSNP 등이 대표적인 인터페이스 프로토콜이고 대표적인 온 칩 네트워크 구조로는 Nostrum, Hermes, QNOC, aSoC, Octagon, AEthereal, SoCBus, SNA, AMBA interconnect matrix, AXI Interconnect, Smart Interconnect 등이 있다.

온 칩 프로토콜의 경우 위에서 언급한 SoC 내부 통신을 위한 프로토콜은 Nostrum 등의 Network-on-Chip이나 PCI express 등의 오프 칩(off-chip) 통신을 위한 프로토콜과는 호환성이 떨어져 NoC나 오프 칩 프로토콜로 이용하기에는 부적합하다. 데이터 폭이 좁은 오프칩 통신의 경우에도 제어 신호선이 많은 프로토콜은 적합하지 않다. 최근 다중 코어를 이용한 프로세서 설계가 활발해지면서 프로세서 간(processor-to-processor) 또는 칩셋 간 연결과 같은 오프 칩 통신에 다양하게 적용될 수 있는 상업용 기술들이 개발되고 있다. 이러한 설계 추세는 온 칩 통신과 오프 칩 통신이 유기적으로 연결되면서 오프 칩 통신의 고성능화를 요구한다.

오프 칩 통신은 온 칩 통신에 비해 신호선 수에 대한 제약이 많은 편이다. 인터페이스 신호 선의 수는 패키지의 입출력 핀 수 및 PCB의 배선 수와 직접적으로 연관이 있기 때문에 물리적 비용과 동작 주파수에 민감하다. 따라서 NoC가 포함된 다중 칩셋의 경우 세 가지 이상의 프로토콜이 혼재되는 양상이 발생할 수 있다. 이는 시스템 설계를 복잡하게 하고 통신중 프로토콜 변환에 의한 성능 저하를 유발하게 된다.

한편 기존의 대부분의 인터페이스 프로토콜은 비대칭적 프로토콜로 마스터(master)에 의한 통신 시작과 슬레이브(slave)에 의한 통신 종료라는 형식을 가진다. 따라서 AHB와 같이 즉시 응답을 요구하는 양방향 프로토콜의 경우에는 통신 완료시까지 통신 채널을 열어 놓아야 하는 비효율성을 가지며, AXI와 같은 점대점(point-to-point) 통신 기반의 프로토콜에서도 단방향 통신을 지원하여 통신 채널을 열어 놓을 필요가 없는 경우에도 마스터가 명령을 전달한 뒤 수행 결과를 슬레이브로부터 받기 위해서는 인터럽트나 폴링 등의 방식을 통해 마스터가 다시 통신을 시작해야 하는 문제를 가진다.

기존의 프로토콜에서는 이를 해결하기 위해서 IP가 마스터와 슬레이브 인터페이스를 동시에 가지도록 하여 성능을 향상시킬 수 있으나, 마스터와 슬레이브 인터페이스의 비대칭적 구조로 인해 하나의 IP가 두 가지 기능 모두를 가지기 위해서는 두 배의 신호선이 요구된다. 또한 데이터 전송시 다양한 기능을 제공하고 성능을 개선하기 위해 많은 제어 신호선을 포함한 프로토콜이 많은데, SoC 규모가 커지고 많은 기능 블록들이 하나의 시스템에 통합되면 많은 수의 신호선은 상당한 배선 혼잡(routing congestion)을 야기할 수 있다. 따라서 부가 신호선의 수를 최소화하면서 원하는 효과를 얻을 수 있는 기술이 필요하다.

SoC 시스템의 통신 패턴이 다양해지면서 온 칩 네트워크 상에서도 컴퓨터 네트워크와 같이 QoS(Quality of Service)를 지원하는 차등화된 서비스를 제공하고 있다. 기존 구조에서는 대부분 온 칩 네트워크에서 QoS를 결정하며, 실제 통신을 수행하는 IP가 QoS를 선택할 수 있는 기회를 제공하지는 않는다. 이것은 기존의 온 칩 네트워크 구조가 특정 시스템 전용으로 사용되거나 다양한 시스템의 특성에 대한 고려 없이 구조적인 지원만 하기 때문이다. 또한, 기존 프로토콜은 QoS 지원에 대한 고려를 하지 않고 있기 때문에 IP 설계자는 IP가 상황에 따라 QoS를 선택적으로 발생시키도록 구현할 수 없다. 최근에 AMBA AXI4에서 QoS 신호가 추가되기는 하였으나, 해당 신호를 어떻게 사용할지에 대한 충분한 검토가 이루어지지 않아 그 기능이 명확하게 정의되지 않은 상태이다.

MPSoC(Multi-Processor SoC)와 같이 병렬처리로 인한 다양한 통신 트래픽이 발생될 수 있는 구조에서 QoS를 IP 수준에서 결정할 수 있다면 보다 효율적인 통신을 수행할 수 있다.

본 발명이 이루고자 하는 기술적 과제는, 대칭적 구조를 가지며 다양한 통신 방식에 동시에 적용 가능하고, 신호를 송신하는 인터페이스 수준에서 QoS를 결정하는 한편 신호 송수신 사이클의 횟수를 감소시킬 수 있는 QoS 및 전송 효율 개선을 위한 SoC 기반 시스템 네트워크 프로토콜을 제공하는 데 있다.

상기의 기술적 과제를 달성하기 위한, 본 발명에 따른 QoS 및 전송 효율 개선을 위한 SoC 기반 시스템 네트워크 프로토콜은, 네트워크를 통한 통신을 개시하는 인터페이스인 개시자 및 상기 개시자의 통신 개시에 응답하는 인터페이스인 목적지 사이에서의 데이터 전송을 위한 것으로, 상기 개시자로부터 채널을 통해 상기 목적지로 전송되는 전송 신호 또는 상기 채널을 통해 상기 목적지로부터 전송되는 응답 신호에 포함된 정보를 정의하는 명령어를 포함하되, 최상위 비트가 상기 네트워크에서 상기 개시자와 상기 목적지 사이의 트랜잭션의 우선순위를 나타내는 커맨드 신호가 전송되며, 상기 전송 신호에 포함된 제어 정보는 우선순위 필드를 포함하는 복수의 필드로 구성되고, 상기 트랜잭션의 우선순위는 상기 커맨드 신호의 최상위 비트 및 상기 우선순위 필드를 조합하여 얻어진 값을 기초로 결정된다.

본 발명에 따른 QoS 및 전송 효율 개선을 위한 SoC 기반 시스템 네트워크 프로토콜에 의하면, 개시자로부터 목적지로 주소, 제어 정보 및 데이터를 포함하는 패킷 형태의 전송 신호가 전송됨과 동시에 전송 신호에 포함된 정보를 정의하는 명령어를 포함하는 커맨드 신호를 전송하되, 커맨드 신호의 최상위 비트 및 전송 신호의 제어 정보에 포함된 우선순위 필드에 의해 트랜잭션의 우선순위를 결정함으로써 기존에 하드웨어 상에서 우선순위를 고정적으로 결정하였던 것과 달리 소프트웨어 상에서 유동적으로 우선순위를 제어할 수 있다. 또한 정렬 및 비정렬 주소에 대한 지원을 강화함으로써 사용자가 원하는 바이트 레인을 용이하게 사용할 수 있으며, 자주 단일 데이터를 교환하는 개시자와 목적지 사이의 통신이 제어 정보 없이 가능하도록 함으로써 전송 효율을 높일 수 있다.

도 1은 본 발명에 따른 네트워크 프로토콜에 따라 전송되는 신호들을 나타낸 도면,
도 2는 SBI 필드에 포함된 정보들을 나타낸 도면,
도 3은 비정렬 주소를 사용할 때 DALGN의 값에 따라 패킷의 데이터가 각 바이트 레인에 채워지는 순서를 나타낸 도면,
도 4는 응답 정보의 각 필드에 포함된 정보들을 나타낸 도면,
도 5a 내지 도 5d는 정규 전송에서의 전송 패킷 및 응답 패킷의 형태를 도시한 도면,
도 6a 내지 도 6c는 각각 RW=0인 경우 및 RW=0이 아니고 개시자가 분할 전송을 요청하는 경우에 이루어지는 정규 읽기 동작의 예를 도시한 도면,
도 7a 내지 도 7d는 각각 RW=0일 때 SBI를 포함한 경우와 SBI-lock인 경우 및 RW=0이 아닌 경우에 이루어지는 정규 쓰기 동작의 예를 도시한 도면,
도 8a 및 도 8b는 SBI32 모드 전송에 사용되는 전송 패킷을 도시한 도면,
도 9a 및 도 9b는 각각 SBI32 모드의 쓰기 동작 및 읽기 동작의 예를 도시한 도면,
도 10a 및 도 10b는 각각 단일 데이터 전송의 전송 패킷과 응답 패킷을 도시한 도면,
도 11은 단일 데이터 전송에 의한 쓰기 및 읽기 동작의 예를 도시한 도면,
도 12a 및 도 12b는 확장 전송에 사용되는 전송 패킷을 도시한 도면,
도 13은 주소가 32비트 이하인 경우에 32비트 채널에서 사용되는 정규 전송 패킷을 도시한 도면, 그리고,
도 14a 및 도 14b는 채널폭이 서로 다른 IP 간에 정규 쓰기 통신 및 SBI32 모드의 쓰기 통신이 수행되는 일 예를 도시한 도면이다.

이하에서 첨부된 도면들을 참조하여 본 발명에 따른 QoS 및 전송 효율 개선을 위한 SoC 기반 시스템 네트워크 프로토콜의 바람직한 실시예에 대해 상세하게 설명한다.

본 발명에 의해 제안되는 프로토콜을 이하에서는 통합 시스템 인터페이스 프로토콜(Unified System Interface Protocol : USIP)이라 한다. 본 발명에 따른 USIP는 다양한 환경에 적용 가능하며, 대칭적 구조에 따라 단순한 인터페이스를 가지는 점대점 프로토콜이다. 도 1은 USIP에 따라 전송되는 신호들을 나타낸 도면으로, valid(VLD), ready(RDY), command(CMD) 및 channel(CHN)의 네 가지 신호로 구성되며, 핸드셰이킹(handshaking) 통신을 수행한다. 도 1에서 I와 D는 각각 통신을 시작하는 인터페이스인 개시자(initiator)와 그에 응답하는 인터페이스인 목적지(destination)를 의미한다.

도 1에 표시된 네 가지의 신호 중에서 VLD는 현재 통신이 유효함을 의미하는 것이며, RDY는 유효한 통신이 정상적으로 수신될 수 있음을 의미한다. VLD와 RDY가 동시에 활성화되면 통신이 이루어진 것으로 간주한다. 또한 CHN은 데이터와 주소 및 제어 정보가 전달되는 물리 채널이며, CMD는 현재 CHN을 통해 전달되는 정보의 의미와 특징을 나타낸다.

각각의 신호는 단방향으로 전달되며, 들어오는 신호와 나가는 신호의 한 쌍으로 구성되고, 각 채널은 서로 독립적으로 동작하여 하나의 인터페이스는 기본적으로 양방향 독립 통신(duplex)을 수행한다. USIP에서는 하나의 CHN을 데이터, 제어 정보(Side Band Information : SBI) 및 주소정보의 전달용으로 사용하는데, 실제 온 칩 통신의 하나의 트랜잭션 내에서 주소정보는 단순 증감하며 제어 정보는 일정기간 동안 유지되는 특성을 가지므로 채널의 공유 사용이 가능하다.

USIP는 대칭적 구조를 가지므로 IP(Intellectual Property)의 물리적인 인터페이스만으로는 개시자와 목적지를 구분할 수 없고, 실제 데이터 전송이 발생할 때 역할 구분이 이루어진다. 따라서 도 1에 도시된 바와 같이 모든 인터페이스는 신호선의 추가 없이 개시자와 목적지로서의 역할을 수행할 수 있다. 논리적인 기능면에서 보면, 개시자는 AMBA의 마스터 역할을 하고, 목적지는 슬레이브 역할을 한다. AMBA의 경우에 마스터와 슬레이브의 기능이 동시에 필요한 DMAC 등은 두 개의 인터페이스를 필요로 하지만, USIP에서는 하나의 인터페이스에 의해 개시자와 목적지의 역할을 수행할 수 있으므로 인터페이스 개수가 IP의 기능에 따라 증가하지 않는다. 이러한 특성은 USIP에서 기존의 마스터/슬레이브 개념을 벗어나 모든 IP가 능동적으로 데이터 전송을 개시하는 통신 방식을 가능하게 한다.

USIP에서는 64비트 핸드셰이킹 통신을 기본으로 수행하여 142개의 신호선을 요구한다. 기존의 AMBA AHB가 64비트 마스터와 슬레이브 인터페이스를 동시에 가지기 위해서는 416개, AMBA AXI의 경우에는 600개의 신호선을 요구하므로 USIP의 네트워크 효율성이 기존의 프로토콜에 비해 뛰어남을 알 수 있다. 채널의 신호선은 필요에 따라 128비트 이상으로 늘어나거나 32비트 이하로 줄어들 수 있으며, 신호선이 128비트로 늘어날 경우 두 개의 채널값이 한번에 전송되고, 줄어들 경우에는 하나의 채널값이 두 번 또는 그 이상의 횟수로 나누어 전송된다.

한편, 채널을 통해 주소, 데이터 및 제어 정보가 전달되므로 채널에 실린 정보의 의미와 특성을 나타내는 명령어가 커맨드 신호(CMD)를 통해 함께 전달된다. CMD는 5비트 신호로, 최상위 비트(MSB)는 트랜잭션의 우선순위 또는 패킷의 마지막을 나타내며, 하위 4비트는 14개의 명령어를 나타낸다. 각각의 명령어는 채널을 통해 전달되는 정보를 정의하는 것으로, CMD의 코드에 따른 명령어의 동작 특성을 다음의 표 1에 나타내었다.

MSB	코 드	명령어	동작 특성
	0000	IDLE	통신하고 있지 않음
F	0001	RSPO	목적지로부터의 단순 응답, 데이터가 뒤따르지 않음
F	0010	RSP	목적지로부터의 응답, 데이터가 뒤따름
F	0011	RSPD	단일 데이터 전송의 응답, 응답과 데이터가 동시에 전송
E	0100	DATA	트랜잭션 데이터
E	0101	EXT	확장 모드
-	0110		유보
E	0111	SBI	전송 신호의 제어 정보(SBI64 모드)
F	1000	AWD	단일 데이터 쓰기 동작을 위한 주소
F	1001	AWS	SBI32 모드의 쓰기 동작을 위한 주소(SBI_H 포함)
F	1010	AWT	정규 쓰기 동작을 위한 주소
F	1011	ARTO	정규 읽기 동작을 위한 주소(SBI와 데이터 없음), SBI-lock 상태에서 RW=0인 경우에만 사용
F	1100	ARD	단일 데이터를 포함하는 읽기 동작을 위한 주소
F	1101	ARSO	SBI32 모드의 읽기 동작을 위한 주소(데이터 없음(RW=0), SBI_H 포함)
F	1110	ARS	SBI32 모드의 읽기 동작을 위한 주소(SBI_H 포함)
F	1111	ART	정규 읽기 동작을 위한 주소

표 1을 참조하면, MSB가 F인 경우는 우선순위를 나타내는 것으로서, 주소나 응답 명령처럼 채널을 통해 최초로 전송되는 정보에 대응하는 명령어에 대해 적용된다. F=1이면 'Fast' 모드이며, 네트워크는 트랜잭션을 발생시킨 개시자에 원래 정의된 우선순위를 무시하고 최우선순위를 부여한다. 그에 따라 개시자 IP에서 QoS를 선택할 수 있는 방법을 제공함으로써 소프트웨어 차원에서의 제어에 의해 QoS 구현을 가능하게 하였다. F=0이면 'Normal' 모드로서, 네트워크에서 정의된 우선순위에 따라 트랜잭션을 처리한다.

특히, 네트워크 구조가 패킷에 포함된 제어 정보를 해석하는 경우에 F 비트와 제어 정보의 QoS 비트를 연동함으로써 4레벨의 QoS 지원 수준을 결정할 수 있다.

MSB가 E인 경우에는 채널을 통해 두 번째 이후로 전송되는 정보에 대응하는 명령어에 대해 적용되며, 패킷의 마지막을 알리기 위해 사용된다. E=1이면 채널의 데이터가 패킷의 마지막임을 나타내어 네트워크가 채널을 회수할 수 있다. 또한 E=0인 경우에는 다음에 데이터가 계속될 것임을 암시하여 채널을 계속 열어두도록 한다.

표 1의 15개의 명령어는 읽기 및 쓰기 주소가 채널에 있고 트랜잭션이 개시됨을 알리는 8개의 명령어(AW 및 AR로 시작하는 명령어)와 응답 개시를 알리는 3개의 명령어(RSP, RSPD, RSPO)를 포함하는 F 계열의 명령어와 채널에 있는 데이터의 종류를 나타내는 2개의 명령어(DATA, SBI) 및 명령어 확장을 위한 명령어(EXT)를 포함하는 E 계열의 명령어, 그리고 현재 통신을 하고 있지 않음을 의미하는 IDLE 명령어로 구성된다. IDLE 명령어는 F 계열 및 E 계열 중 어디에도 속하지 않는다.

8개의 주소 관련 명령어는 읽기 또는 쓰기 동작을 위한 주소를 정의함과 함께 5개의 읽기 및 3개의 쓰기 통신 방식에 따라 다른 값을 가지며, 자세한 통신 방식은 뒤에서 설명한다. 응답 개시를 나타내는 세 개의 명령어는 개시 명령어의 종류에 따라 사용되는데, RSP의 경우에는 DATA 명령어와 함께 데이터가 포함된 패킷을 구성하고, 순수한 쓰기 동작과 같이 데이터가 없는 단순 응답의 경우에는 RSPO 명령이 사용된다. 또한 RSPD는 DATA 명령어가 뒤따르지 않는다는 점에서는 RSPO와 동일하지만 채널을 통해 데이터가 응답정보와 함께 전달된다는 점에서 차이가 있다. DATA는 채널에 순수한 데이터가 있음을 의미하고, SBI는 채널에 SBI64 모드의 제어 정보가 있음을 의미하며, 다양한 통신 방식을 지원하기 위해 사용된다. EXT는 바로 이전에 전송된 명령어가 계속됨을 나타내며, 주로 데이터 폭이 넓은 영역으로부터 좁은 영역으로 통신을 수행할 때 사용된다. E 계열 명령어인 DATA, SBI 및 EXT의 경우 패킷의 마지막에 위치하면 E=1이 되고, 그렇지 않으면 E=0이다.

이와 같은 명령어들은 네트워크에 직접적으로 채널에 관한 정보를 제공하며, 네트워크가 패킷을 효과적으로 전달하는 데 도움을 준다. 채널을 통해 전달되는 제어 정보 신호(SBI)는 버스 구조의 네트워크에서는 실시간으로 해석되기 어려우므로 전송에 반영하기가 어렵고 NoC 구조에서만 적용이 가능하다. 또한 패킷 전달과 관련된 복잡한 정보가 포함되어 네트워크의 하드웨어 구조가 매우 복잡해지며, 제어 정보 신호의 종류가 바뀌면 네트워크를 다시 설계하여야 한다는 문제가 있다. 반면, 별도의 신호선을 통해 전달되는 명령어의 경우에는 버스 구조에서도 실시간으로 해석 및 적용이 가능하고, 패킷의 시작과 끝을 알리며 채널을 통해 전달되는 내용에 대한 정보만이 포함되어 있으므로 네트워크에 부담을 주지 않으면서 통신에 반드시 필요한 정보만을 제공할 수 있다.

앞에서 설명한 바와 같이 제어 정보 신호는 별도의 신호선을 이용하지 않고 채널을 통해 전송되며, 개시자로부터는 SBI의 형태로 전달되고, 목적지로부터는 응답 정보의 형태로 전송된다. SBI 및 응답 정보는 복수의 필드로 구성된다.

도 2는 SBI 필드에 포함된 정보들을 나타낸 도면이다. 도 2에서 각 필드 값의 위에 표시된 숫자는 시작과 끝의 비트 위치를 나타내며, 각 필드 값의 아래에 표시된 숫자는 해당 필드의 비트수를 나타내는 것이다. SBI는 각각 32비트의 SBI_H 및 SBI_L로 나누어지는데, 도 2의 (a)는 SBI_H를, (b)는 SBI_L을 나타낸 것이다. 뒤에서 설명할 통신 방식 중에서 32비트의 SBI만을 이용하는 SBI32 모드에서는 도 2의 (a)에 도시된 SBI_H를 이용하고, 64비트의 SBI를 이용하는 SBI64 모드에서는 SBI_H 및 SBI_L을 모두 이용한다.

다음의 표 2는 도 2에 나타낸 SBI의 각 필드 값과 동작 특성 및 각 필드의 기본값을 나타낸 것이다.

SBI 필드	설명	크기[비트]	기본값
PID	Protocol ID	2	0(USIP)
QoS	Quality of Service	1	0
REQRSP	Request Response	1	1
RW	Read and Write enable	2	0
DRSP	Delayed Response	1	0
BLEN	Burst Length	4	3(4 버스트)
BSIZ	Burst Size	3	3(8 바이트)
BTYP	Burst Type	2	1
RBL	Response Burst Length	3	0
STRB	Strobe	1	0
TID	Transaction ID	4	0
LID	Link ID	6	-
DALGN	Data Align	1	0
CTYP	Cache Type	4	0
PTYP	Protect Type	3	2
SBIL	SBI-lock	1	0
LTYP	Lock Type	2	0
LIDEXT	Network ID Extension	4	0
TIDEXT	Order ID Extension	2	0
BTLN	Byte Lane	8	255

이하에서는 표 2에 포함된 SBI의 각 필드값에 대하여 상세하게 설명한다.

PID(Protocol ID)는 다수의 이종 프로토콜을 사용할 때 각각의 프로토콜에 ID(identification)를 부여하여 구분할 목적으로 사용되는 프로토콜 정보 필드이다. 최대 4 개의 이종 프로토콜을 동시에 지원할 수 있으며, IP가 아닌 프로토콜 변환기와 같은 유닛에서 사용하는 신호이다. PID를 사용함으로써 서로 다른 프로토콜을 사용하는 IP들 사이에서 통신이 수행되는 경우에도 각각의 IP가 사용하는 프로토콜 정보를 알 수 있으므로 적절하게 프로토콜을 변환할 수 있다.

QoS(Quality of Service)는 네트워크와 목적지에 대해 대역폭 품질을 보장하는 통신을 요구할 때 이용되는 우선순위 필드이며, 네트워크와 목적지가 이 기능을 지원할 때 의미가 있다. 앞에서 설명한 바와 같이 QoS 비트는 명령의 F 비트와 함께 이용되어 2비트의 신호를 형성한다. 따라서 네트워크가 SBI를 해석하는 경우에 F 비트를 상위 비트로 하여 QoS 비트와 함께 0~3의 QoS 수준을 의미하며, 각 수준의 정확한 내용은 시스템 설계자에 의해 결정될 수 있다. 다만 0은 QoS가 활성화되지 않은 것을 의미하며, 1 이상인 경우에 활성화되어 그 값이 커질수록 QoS의 수준이 높아진다.

예를 들면, QoS 수준이 높아지면 해당 패킷에 대하여 네트워크는 더 큰 대역폭을 보장하는 범위에서 라우팅을 실행하고, 목적지 역시 정해진 대역폭을 만족하도록 응답의 우선순위를 조절한다. 네트워크가 SBI를 해석하지 못하는 경우에는 F 비트에 의해서만 네트워크가 QoS를 지원하고, 목적지는 F 비트와 QoS 비트를 조합하여 정해진 수준에 따라 QoS를 지원한다. 일반적으로 목적지가 out-of-order completion 통신을 지원하지 않으면 F를 1로 만들어 응답하는 것 이상의 QoS 지원은 어렵다.

이와 같이 F 비트와 QoS의 값을 사용하여 다양한 수준의 QoS를 결정할 수 있도록 함으로써, 개시자와 목적지 간의 연결선 수의 증가를 최소화할 수 있으며, 버스 구조와 NoC 구조에서 모두 QoS 지원이 가능해진다.

REQRSP(Request Response)는 응답 요구 신호로서, 이 값이 0인 경우에는 목적지가 응답신호를 보내지 않아도 되며, 목적지에서 오류가 발생한 경우에도 응답을 보낼 필요가 없다. 목적지가 REQRSP 신호를 해석하지 않아 응답신호를 전송하는 경우에 개시자는 이를 무시한다.

RW(Simultaneous Read and Write enable)는 동시 읽기/쓰기 신호로서 한 번의 트랜잭션에서 읽기와 쓰기 동작이 동시에 일어난다. RW는 크기가 2비트이므로 0에서 3의 값을 가지며, RW=0인 경우 동시 읽기 및 쓰기 기능은 활성화되지 않고 0이 아닌 경우에만 활성화된다. RW 기능이 활성화되면 읽기와 쓰기 명령의 경우에 서로 다른 결과가 발생한다. RW 기능이 활성화된 읽기 명령의 경우 읽기 주소의 값을 먼저 읽고 패킷의 데이터를 쓰기 주소에 쓰는 '읽기 후 쓰기' 동작이 수행되고, RW 기능이 활성화된 쓰기 명령의 경우에는 패킷의 데이터를 먼저 쓰기 주소에 쓰고 읽기 주소에서 데이터를 읽는 '쓰기 후 읽기' 동작을 한다. 읽기와 쓰기 주소가 다를 경우에는 읽기 명령 및 쓰기 명령에 따른 동작에 따라 동일한 결과가 얻어질 수도 있지만, 읽기 주소와 쓰기 주소가 서로 동일한 경우에는 완전히 다른 결과를 보인다.

RW가 활성화된 경우에는 그 값에 따라 추가로 제공되어야 하는 주소가 결정된다. 즉 RW가 활성화된 읽기 명령의 경우에는 데이터를 쓰기 위한 쓰기 주소가 추가로 필요한데, RW=1이면 읽기 주소와 쓰기 주소가 동일하고, RW=2이면 목적지 내에서 미리 정해진 주소가 쓰기 주소로 이용된다. RW=3인 경우에는 패킷에서 쓰기 주소를 제공하는데, SBI 명령어 뒤에 EXT 명령어가 따라오면서 쓰기 주소를 제공한다. RW가 활성화된 쓰기 명령의 경우도 읽기 명령과 유사한 동작을 하되, 읽기 주소가 RW 값에 따라 달라진다는 차이점이 있다.

이와 같이 RW는 읽기와 쓰기가 연속적으로 필요한 통신을 하나의 트랜잭션으로 처리하도록 하여 통신 효율을 높일 수 있다. 예를 들면, 메모리에 저장된 값과 프로세서의 레지스터에 있는 값을 서로 바꿀 경우 한 번의 통신으로 이러한 처리가 가능하다. 또한 목적지가 외부와 통신하는 IP일 경우에 프로세서에서 밖으로 내보내는 데이터를 주면서 동시에 목적지가 외부에서 받은 값을 읽어 올 수 있다. 목적지가 연속적으로 일련의 데이터를 처리하는 연산기일 경우에는 이전의 연산 결과를 읽어 오면서 새로운 데이터를 공급하는 동작이 한 번의 통신으로 가능하게 된다.

DRSP(Delayed Response)는 지연 응답 허용 신호로서, 쓰기 후 읽기 또는 단순 읽기 동작에서 목적지가 읽기 명령에 대한 응답을 특정한 조건이 만족되어야 할 수 있는 경우에 사용된다. 예를 들면, 읽기 주소에 저장된 값이 변화한 이후에 읽기 명령에 대한 응답을 하는 경우가 있다. 이러한 경우에 DRSP는 개시자가 목적지에 데이터를 공급하고, 그 데이터를 이용한 연산이 끝난 뒤 연산 결과를 읽어 오는 동작이 하나의 트랜잭션에서 이루어지도록 하여 통신 효율을 높일 수 있다. 또한 목적지에서는 데이터 전송이 언제 가능해질지 알 수 없는 상태에서 개시자가 목적지에 데이터를 요청하면 데이터가 준비된 후에 개시자로 전송할 수 있다.

개시자는 DRSP를 사용하는 경우에는 응답이 언제 전송될지 알 수 없기 때문에 응답을 기다리는 동안 다른 작업을 수행할 수 있어야 한다. 이는 개시자에서 폴링 동작을 하거나 목적지에서 인터럽트 신호를 사용하지 않을 수 있도록 하면서 한 번의 통신으로 전송 동작을 완료함으로써 통신 효율을 높이기 위함이다. 목적지는 IP의 특성에 따라 응답 지연의 시간제한을 가지며, 제한된 시간이 경과하여도 응답할 수 없는 경우에는 일시적 오류(provisional error) 응답을 하게 된다. 외부와 통신하는 IP의 경우에 데이터가 장시간 동안 도달하지 않은 경우가 일 예이다.

BLEN(Burst Length)은 트랜잭션의 버스트 크기를 의미하며, 최대 32개까지 가능하다. 다음의 표 3에 BLEN 값에 따른 버스트의 길이를 나타내었다.

BLEN	버스트 길이
0000 (0)	unspecified
0001 (1)	1
0010 (2)	2
0011 (3)	3
0100 (4)	4
0101 (5)	5
0110 (6)	6
0111 (7)	7
1000 (8)	8
1001 (9)	10
1010 (10)	12
1011 (11)	16
1100 (12)	20
1101 (13)	24
1110 (14)	28
1111 (15)	32

BLEN은 4비트의 버스트 길이 신호로서, 표 3에 나타난 바와 같이 8 버스트까지는 1 단위로 증가하고, 12 버스트까지는 2 단위로, 그리고 32 버스트까지는 4 단위로 버스트 길이가 증가한다. 그리고 BLEN=0인 경우에는 unspecified burst이며, 명령어의 E 비트에 의해 패킷의 마지막 데이터가 결정된다.

또한 BSIZ(Burst Size)는 전송되는 데이터의 크기를 의미하며, 8~ 1024비트까지 가능하고, 채널폭보다는 클 수 없다. BTYP(Burst Type)은 AMBA AXI에서 지원하는 주소 고정(fixed), 주소 증가(increment)와 주소 래핑(wrapping)의 세 가지를 지원하며, 추가로 사용자 정의(predefined sequence) 주소 방식을 지원한다. 이는 목적지에 미리 정해진 순서대로 주소값을 저장해 놓고 그에 따라 주소값을 변화시키며 동작하는 방식이다. 목적지에서 개시자가 접근 가능한 주소가 연속이 아니거나 특정한 순서대로 데이터를 읽거나 쓸 필요가 있을 때 한 번의 트랜잭션으로 통신을 완료함으로써 통신 효율을 증가시킨다.

BLEN은 일반적으로 개시자의 SBI와 동일한 값을 사용하나, 목적지에 따라 다른 값을 사용할 수도 있다. 이러한 경우에 목적지의 BLEN 값은 개시자의 BLEN 값보다 클 수는 없으며, 작은 값을 사용하는 경우에는 2회 이상의 응답 패킷을 전송한다. 이때 응답 패킷의 BLEN의 총합은 개시자 BLEN의 값과 동일하여야 한다.

2회 이상의 패킷으로 나누어 응답하는 경우에는 BID(Burst ID), 즉 분할 식별 필드의 값에 의해 구분한다. 즉, BID가 0이면 개시자와 목적지의 BLEN 값이 동일하여 한 번의 응답으로 끝나는 경우이고, 2회 이상으로 응답이 나누어지는 경우에는 1에서 시작하여 7까지 사용 가능하고, 마지막 패킷의 BID는 0이 되어 총 8개의 패킷으로 나누어 응답할 수 있다. 응답을 구성하는 패킷의 개수에 무관하게 마지막 패킷의 BID는 0이 된다.

RBL(Response Burst Length)은 하나의 전송 요청에 대해 응답 패킷을 나누어 보내도록 하는 분할 응답(split response) 요청에 이용된다. 즉, RBL은 하나의 패킷의 버스트 길이를 얼마로 할 것인지를 알려주는 것이므로, 전체 패킷의 버스트 길이보다 작아야 하고, 나누어진 패킷의 수가 8을 넘으면 안된다. 이는 응답 패킷이 8개까지만 나누어질 수 있기 때문이다.

RBL은 개시자가 비교적 큰 크기의 블록 데이터를 다루는 경우에는 한 번의 전송 요청으로 모든 데이터를 받으면서 비교적 작은 크기의 버퍼를 이용하여 통신이 가능하게 한다. 또한 목적지는 버스트 길이가 긴 응답을 여러 개로 나누어 전송하므로 패킷 사이에 높은 우선순위를 가지거나 QoS를 보장해야 하는 응답을 끼워넣을 수가 있어 시스템의 전송 효율을 증가시킬 수 있다.

RBL=0인 경우에는 목적지에 의해 분할 응답이 결정되고, RBL의 값이 5와 6인 경우는 각각 8과 16 버스트 길이이며, RBL=7인 경우는 분할 응답이 허용되지 않음을 의미한다. 나머지 값은 분할 응답의 버스트 길이와 같다.

전체 버스트 길이가 RBL의 배수가 되지 않는 경우에는 마지막 패킷을 RBL보다 작게 만들어 전체 길이를 맞출 수 있다. 목적지가 응답 패킷의 분할 기능을 지원하지 않는 경우에는 RBL을 무시하고 하나의 패킷으로 응답하므로, 개시자는 첫 전송에서 응답 분할 여부를 확인하여 지원하지 않는 경우에는 개시자가 한 번에 수용 가능한 크기로 전송 요청을 분할하여 여러 번에 걸쳐 요청해야 한다.

분할 응답의 경우, 개시자가 요청한 경우에는 RBL 값에 따라 패킷이 나누어지고, 목적지의 사정이나 필요에 의해 분할하는 경우에는 목적지에서 적절한 버스트 길이로 나누어 보낸다. 목적지가 분할 응답을 지원하지 않는 경우에는 RBL 값에 무관하게 BID=0인 상태로 SBI의 BLEN 값에 따라 응답하고, 개시자는 이후 분할 응답을 요청하지 않는다.

TID(Transaction ID)는 개시자가 내보내는 패킷 또는 트랜잭션의 ID를 의미하며, outstanding address 방식이나 out-of-order completion 방식의 트랜잭션에서 서로 다른 트랜잭션을 구분하기 위해 이용된다. SBI32 모드에서는 16개까지의 ID가 부여되고 SBI64 모드에서는 TIDEXT(Transaction ID Extension)와 함께 64개의 ID가 부여된다.

LID(Link ID)는 현재 개시자 IP가 연결된 포트의 ID인 개시자 식별 필드를 의미한다. LID는 IP 동작과는 무관하며, 네트워크에 의해 이용되는 부분이다. 따라서 주소값을 이용하여 목적지를 찾아가는 주소 라우팅 방식에서 개시자는 LID 부분은 비워둔 채로 통신을 진행하고, 네트워크에서 LID 값을 채워준다. LID는 6 비트의 크기를 가지며, SBI32 모드에서는 64개의 ID를 부여할 수 있고, SBI64 모드에서는 LIDEXT(Link ID Extension)와 함께 1,024개까지의 ID를 부여할 수 있다.

그러나 각 IP에 대해 좌표가 주어지고 개시자가 이 좌표를 지정하여 패킷을 만들면 네트워크가 좌표를 이용하여 목적지를 찾아가는 XY 라우팅 방식에서는 개시자가 LID 값에 좌표를 채워서 보내게 된다.

USIP는 기본적으로 비정렬 주소를 허용한다. DALGN(Data Align)은 비정렬(unaligned) 주소를 사용할 때 데이터를 주소에 대응하는 바이트 레인(byte lane)부터 시작하여 전송하지 않고 첫 번째 바이트 레인부터 채워 보내는 경우에 이용되는 정렬 필드이다. DALGN이 활성화되면 0번 바이트 레인부터 BSIZ만큼의 바이트 레인이 데이터로 채워진다. 도 3에는 DALGN의 활성에 따라 달라지는 데이터 전송 방식의 예가 도시되어 있다.

도 3의 (a) 및 (b)는 각각 BSIZ의 값이 3일 때 DALGN이 활성화되지 않은 경우와 활성화된 경우에 데이터 정렬 형태를 나타낸 도면으로, DALGN의 값이 0으로 설정된 경우에는 (a)와 같이 주소의 시작 지점으로 지정된 위치로부터 데이터가 정렬되어 결과적으로 5개의 패킷으로 데이터가 전송되지만, DALGN의 값이 1로 설정된 경우에는 (b)와 같이 첫 번째 바이트 레인으로부터 데이터가 정렬되어 4개의 패킷으로 데이터가 전송된다.

또한 도 3의 (c) 및 (d)는 각각 BSIZ의 값이 0일 때 DALGN이 활성화되지 않은 경우와 활성화된 경우에 데이터 정렬 형태를 나타낸 도면이다. 도 3의 (c)를 참조하면 DALGN의 값이 0으로 설정된 경우에는 주소의 시작 지점에 대응하는 바이트 레인에 데이터가 채워지지만, (d)와 같이 DALGN의 값이 1로 설정된 경우에는 그에 무관하게 첫 번째 바이트 레인에 데이터가 채워지는 것을 확인할 수 있다.

CTYPE(Cache Type)은 현재 진행중인 통신의 캐시 특성을 나타내며, AMBA AXI와 동일한 방식으로 정의된다. 캐시 타입에 따른 동작 특성을 다음의 표 4에 나타내었다.

캐시 타입	동작 특성
0000	캐시 불가능 및 버퍼 불가능
0001	버퍼 가능
0010	캐시 가능, 비할당
0011	캐시 및 버퍼 가능, 비할당
0100	유보
0101	유보
0110	즉시 쓰기로 캐시 가능, 읽기에만 할당
0111	나중 쓰기로 캐시 가능, 읽기에만 할당
1000	유보
1001	유보
1010	즉시 쓰기로 캐시 가능, 쓰기에만 할당
1011	나중 쓰기로 캐시 가능, 쓰기에만 할당
1100	유보
1101	유보
1110	즉시 쓰기로 캐시 가능, 읽기 및 쓰기에 할당
1111	나중 쓰기로 캐시 가능, 읽기 및 쓰기에 할당

PTYP(Protection Type)은 3 비트 신호로 현재 진행 중인 통신의 보호 특성을 나타내며, 하위 비트가 1이면 priviledged, 0이면 normal, 가운데 비트가 1이면 non-secure, 0이면 secure, 상위 비트가 1이면 명령어(instruction), 0이면 데이터를 나타내어 AMBA AXI와 동일한 방식으로 정의된다.

LTYP(Lock Type)은 분리할 수 없는(atomic) 통신을 지원하기 위해 사용되는 잠금 유형 필드이며, AMBA AXI에서 지원하는 Normal, Exclusive, Locked의 세 가지 접근 방식과 함께 추가로 SBI-lock 접근 방식을 지원한다. SBI-lock 접근 방식에서는 SBI64모드에서 사용되는 SBI_L의 SBIL값이 활성화된다. SBI-lock 접근 방식에 대하여는 뒤에서 상세하게 설명한다.

SBIL은 앞에서 설명한 바와 같이 LTYP이 SBI-lock 접근 방식일 때 유효한 제어 정보 잠금 필드이다. SBIL이 1이면 목적지에서 현재 패킷의 SBI 값을 저장하고, 이후 SBI가 없는 패킷이 들어오면 저장된 SBI 값을 이용한다. 그 뒤에 동일한 개시자로부터 SBI를 포함하면서 LTYP이 SBI-lock이 아닌 패킷이 들어오면 해당 패킷에 대해서만 새로운 SBI를 적용하고, SBI가 없는 패킷이 들어오면 다시 저장된 SBI 값을 이용한다.

SBI-lock 상태에서 다른 개시자가 SBI-lock을 시도할 경우에 목적지는 SBI-lock 실패(failure) 응답을 전송하여 목적지가 이미 SBI-lock 되어 있음을 알린다. 따라서 개시자가 목적지를 SBI-lock 모드로 설정하고 필요한 통신을 마친 뒤 SBI-lock을 해제하지 않으면 이 기능이 필요한 다른 개시자가 통신을 하지 못하게 되어 통신 효율이 저하되므로, 개시자는 SBI-lock 통신이 완료되면 LTYP이 SBI-lock인 상태에서 SBIL을 0으로 설정한 전송 신호를 목적지로 전송하여 목적지를 SBI-lock 접근 모드에서 해제시키는 것이 바람직하다.

BTLN(Byte Lane)은 8바이트의 채널을 바이트 단위로 활성화시키는 역할을 한다. 8 비트의 BTLN은 각 비트가 8바이트의 바이트 레인과 연결되어 BTLN의 비트가 0이면 해당 비트에 연결된 바이트는 비활성화된다. 또한 BTLN은 STRB가 활성화된 경우에만 유효하다.

한편, 도 2에 도시된 SBI 포맷에서 (a)의 SBI_H에 포함된 2비트와 (b)의 SBI_L에 포함된 8비트는 유보(reserved) 영역으로, 추후에 SBI의 특정 필드를 확장하기 위한 것이다. 예를 들면, SBI_H의 2비트는 LID와 주소의 확장에 이용할 수 있고, SBI_L의 8비트는 LIDEXT와 TIDEXT의 확장에 이용할 수 있다. 또한 유보 영역은 특정 시스템에서 PID의 값에 따라 프로토콜 변환기에 의해 특정 프로토콜의 정보를 저장하여 프로토콜 간의 호환성을 증가시키는 데 이용할 수도 있다. 이러한 경우에 해당 프로토콜 변환기는 특정 시스템에서만 사용이 가능하다.

응답 신호 역시 SBI에 대응하는 응답 정보를 포함하여 전송되며, 응답 정보는 복수의 필드로 구성되어 32비트의 길이를 가진다. 도 4는 응답 정보의 각 필드에 포함된 정보들을 나타낸 도면으로, 도 2와 마찬가지로, 도 4에서 각 필드 값의 위에 표시된 숫자는 시작과 끝의 비트 위치를 나타내며, 각 필드 값의 아래에 표시된 숫자는 해당 필드의 비트수를 나타내는 것이다.

도 4를 참조하면, 응답 정보의 각 필드에 포함된 정보는 SBI와 유사하다. 다음의 표 5는 응답 정보의 각 필드에 관한 정보를 나타낸 것이다.

응답 정보 필드	설명	크기	기본값
PID	Protocol ID	2	0
QoS	Quality of Service	1	-
RW	Read and Write	1	0
BLEN	Burst Length	4	-
BID	Burst ID	3	0
RESP	Response	3	0
TIDEXT	Transaction ID extension	2	-
TID	Transaction ID	4	-
LIDEXT	Link ID extension	4	-
LID	Link ID	6	-

표 5에서, 기본값이 '-'로 표시된 경우는 개시자가 보낸 값과 동일한 값을 사용하는 경우를 말한다. 읽기 응답의 경우, BLEN은 개시자로부터 전달된 값을 사용하는 것을 원칙으로 하나, 분할 응답의 요청이 있는 경우에는 개시자가 요청한 해당 버스트 길이를 사용하고, 분할 응답의 요청이 없는 경우에도 목적지에서 분할 응답을 할 것으로 결정하면 목적지에 의해 그 값이 결정된다. 쓰기 응답의 경우에는 RW≠0이면 읽기 응답과 동일하며, RW=0인 단순 쓰기 응답이면 목적지에서 전송받은 데이터의 버스트 길이가 BLEN의 값으로 결정되어 개시자가 응답 신호로부터 실제 전달된 데이터의 수를 확인할 수 있다.

PID는 프로토콜 변환기에서 그 값이 채워지며, QoS는 개시자가 전송한 SBI와 동일한 값을 사용한다. RW=0이면 목적지에서 동시 읽기 및 쓰기 동작을 지원하지 않음을 의미하므로, 개시자는 목적지와의 첫 번째 통신에서 응답의 RW 값을 확인하여 응답의 RW 값이 0으로 설정되어 있으면 그 이후에는 RW 기능을 사용하지 않는다.

RESP(Response)는 개시자의 트랜잭션에 대한 응답 신호로서, 다음의 표 6에 나타낸 바와 같이 6종류의 응답이 있다.

응답신호	동작 특성
000	일반적 접근 정상 완료
001	배타적 접근 정상 완료
010	영구적 오류
011	디코더 오류
100	일시적 오류
101	SBI-lock 실패
110	읽기 쓰기 동시 접근 실패
111	유보

RESP=0이면 일반적(normal) 접근이 정상적으로 끝났음을 의미하며, 배타적(exclusive) 접근이 실패했거나 목적지가 배타적 접근을 지원하지 않는 경우이다. RESP=1이면 배타적 접근이 성공했음을 의미한다. RESP=2이면 목적지에서 영구적인 오류가 발생하여 통신이 실패했음을 의미하고, 개시자는 동일한 통신을 다시 시도할 수 없다. RESP=3이면 디코딩 오류가 발생한 경우로서, 네트워크 또는 기본(default) 목적지에서 응답신호를 전송한다. RESP=4이면 일시적 오류가 발생한 경우로서, 해당 통신은 실패하였으나 개시자가 다시 통신을 시도하면 성공할 수 있음을 의미한다. 이 응답은 목적지가 잠겨있는(locked) 경우에도 이용된다.

한편, RESP=5는 SBI-lock 오류를 의미하며, 이미 SBI-lock으로 되어 있는 목적지에 다른 개시자가 SBI-lock을 시도할 경우에 발생시키는 응답이다. RESP=6이면 RW 동작의 경우에 목적지가 RW 동작을 지원하지 않거나 다른 원인에 의해 오류가 발생하여 읽기 명령의 경우에는 쓰기 동작이 실패하고, 쓰기 명령의 경우에는 읽기 동작이 실패했음을 의미한다. 즉, 부가적으로 수행되는 동작이 실패한 경우에 RESP=6이 되며, 읽기 명령에 대한 읽기 동작이 실패하거나 쓰기 명령에 대한 쓰기 동작이 실패한 경우에는 RESP=2 또는 4의 오류 응답이 전송된다.

TIDEXT, TID, LIDEXT 및 LID는 개시자로부터 전송된 값을 그대로 이용하여 네트워크가 응답 패킷을 개시자로 보낼 때 이용한다.

이상에서 설명한 구조를 가지는 USIP를 이용한 통신은 주소, 제어 정보 및 데이터가 순차적으로 CHN 신호선을 통해 명령어와 함께 핸드셰이킹 방식으로 전달됨으로써 수행된다. 본 발명에 따른 네트워크 프로토콜인 USIP를 이용한 신호 송수신 방법으로는 세 가지의 전송 방식과 두 가지의 응답 방식이 가능하다.

첫 번째의 전송 방식은 정규 전송(regular transfer) 방식이다. 도 5a 내지 도 5d는 정규 전송에서의 전송 패킷 및 응답 패킷의 형태를 도시한 도면이다. 정규 전송 패킷은 도 5a에 도시된 것과 같이 64비트의 주소와 SBI64 모드를 이용하며, 데이터도 64비트를 기본으로 하여 주소는 AWT 또는 ART 명령어와 함께 전달된다. 그에 대한 응답 패킷은 도 5b에 도시된 것과 같이 32비트 응답신호에 0을 패딩(padding)하여 64비트의 응답신호의 형태로 만들어진다.

도 5c는 SBI와 DATA 없이 주소만 전송되는 정규 전송인 ARTO 명령어의 패킷 형태를 도시한 것으로, RW=0이고 SBI-lock인 읽기 동작에서 사용된다. 또한 도 5d는 RW=0인 경우 쓰기 요청에 대해 응답 신호만 전송되는 RSPO 명령어의 패킷 형태를 도시한 도면이다.

도 6a 내지 도 6c는 각각 RW=0인 경우 및 RW=0이 아니고 개시자가 분할 전송을 요청하는 경우에 이루어지는 정규 읽기 동작의 예를 도시한 도면이다. 도 6a의 (a)에 도시된 경우에 RW=0이므로 ART와 SBI(E) 명령어로 구성되는 전송 패킷이 개시자로부터 목적지로 전송되며, RSP와 DATA 명령어로 구성되는 응답 패킷이 목적지로부터 개시자로 전송된다. 여기서 SBI(E)와 DATA(E) 명령어는 E=1인 경우, 즉 해당 패킷의 마지막임을 의미한다.

도 6a의 (b)에 도시된 경우는 SBI-lock된 상태이므로 전송 패킷에서 SBI가 생략되고, 목적지는 이전 전송에서 저장된 SBI값을 사용한다. 이 경우에 전송 패킷에는 도 5c에 도시된 것과 같이 주소만 전달되는 ARTO 명령어가 사용되며, 응답 패킷은 도 5d에 도시된 바와 같이 0으로 패딩된 64비트의 응답신호 형태로 만들어진다. SBI의 전송이 생략됨에 따라 전송 사이클이 감소하므로 네트워크의 효율성을 높일 수 있다.

도 6b에 도시된 바와 같이 RW가 0이 아닌 경우에는 읽기 후 쓰기 동작이 수행되며, 전송 패킷에는 DATA 명령어가 포함되어 목적지와 개시자 모두에 데이터가 전달된다. 이 경우에는 도 6b의 (a)와 같이 ART 명령어로 시작하여 DATA(E) 명령어로 패킷이 종료된다. 또한 SBI-lock인 경우에는 도 6b의 (b)와 같이 ART 명령어로 시작하며 SBI 명령어가 생략된 패킷이 전송된다.

앞에서 설명한 바와 같이 정규 전송에서는 하나의 읽기 전송 요청이나 RW가 0이 아닌 쓰기 전송 요청에 대해 응답을 여러 개의 패킷으로 나누어 보내는 분할 응답 요청이 가능하다. 개시자에서 분할 응답을 요청한 경우, 즉 RBL이 0이 아닌 경우에는 도 6c에 도시된 바와 같이 응답이 최대 8개의 패킷으로 나누어 전송되고, QoS를 보장하는 범위 내에서 다른 응답이나 전송 요청이 패킷 사이에 들어갈 수 있다.

도 7a 내지 도 7d는 각각 RW=0일 때 SBI를 포함한 경우와 SBI-lock인 경우 및 RW=0이 아닌 경우에 이루어지는 정규 쓰기 동작의 예를 도시한 도면이다. 도 7a는 RW=0이고 전송 패킷에 SBI가 포함되는 정규 쓰기 동작에 관한 것으로, REQRSP=1인 경우에는 (a)와 같이 RSPO 명령어를 포함하는 응답 패킷이 전송되지만, REQRSP=0인 경우에는 (b)와 같이 응답 패킷이 전송되지 않는다. 도 7b는 RW=0이고 SBI-lock인 경우로서, 읽기 동작의 경우와 마찬가지로 SBI가 생략되고 AWT와 DATA 명령어만 전송 패킷에 포함되어 전송된다. 도 7b의 (a)의 경우에는 REQRSP=1이므로 응답 패킷이 전송되지만, (b)의 경우에는 REQRSP=0이므로 응답 패킷이 전송되지 않는다.

도 7c는 RW가 0이 아닌 경우로서, 쓰기 후 읽기 동작이 수행된다. 따라서 전송 패킷 및 응답 패킷에 모두 DATA 명령어가 포함되며, 도 7c의 (a) 및 (b)는 각각 SBI를 포함한 경우와 SBI-lock인 경우를 나타낸 것이다. 도 7d에 도시된 바와 같이 쓰기 동작의 경우에도 RW=0이 아닌 경우에는 목적지로부터 분할 응답을 전송할 수 있다.

주소가 32비트이고 SBI64 모드가 필요하지 않은 경우에는 SBI32 모드 전송이 수행된다. 도 8a 및 도 8b는 SBI32 모드 전송에 사용되는 전송 패킷을 도시한 도면이다. 또한 도 9a 및 도 9b는 각각 SBI32 모드의 쓰기 동작 및 읽기 동작의 예를 도시한 도면이다.

도 8a는 RW가 0이 아닌 경우의 전송 패킷으로, 정규 전송과 마찬가지로 전송 패킷과 응답 패킷 모두 데이터를 포함한다. 이때 전송 패킷에는 AWS 또는 ARS 명령어와 함께 주소와 SBI_H가 함께 전달되고, 64비트 데이터가 뒤따르게 된다. 한편, 32비트 주소를 사용하더라도 SBI64 모드의 기능이 필요한 경우에는 정규 전송 방식이 사용된다. 도 8b는 RW=0인 경우에 읽기 동작을 위한 전송 패킷으로, 데이터를 전송할 필요가 없으므로 ARSO 명령어를 사용하여 주소와 SBI_H만 포함된 전송 패킷이 전송된다.

도 9a는 SBI32 모드의 쓰기 동작을 도시한 도면으로, (a)와 같이 REQRSP=1이고 RW=0이면 전송 패킷에만 데이터가 포함되고 응답 패킷에는 RSPO 명령어만 포함된다. (b)는 REQRSP=0이고 RW=0인 쓰기 동작을 나타내며, 응답 패킷이 전송되지 않는다. 도 9a의 (c)는 RW가 0이 아닌 경우로서, 전송 패킷과 응답 패킷 모두에 데이터가 포함됨을 확인할 수 있다.

도 9b는 SBI32 모드의 읽기 동작을 도시한 도면으로, RW=0인 경우에는 (a)와 같이 ARSO 명령어와 SBI_H만 전송되며, 응답 패킷에 데이터가 포함된다. 또한 RW가 0이 아닌 경우에는 (b)와 같이 전송 패킷과 응답 패킷 모두에 데이터가 포함된다.

이와 같이 SBI32 모드를 사용하는 경우에는 주소와 SBI가 한번에 전송되므로 SBI의 전송에 따른 전송 사이클 증가를 제거함에 따라 전송 성능을 향상시킬 수 있다. 또한 SBI32 모드의 경우에 32비트 주소를 원칙으로 하지만 SBI_H의 하위 3비트가 유보 영역에 해당하므로 주소값을 확장할 수 있다. 따라서 최대 35비트의 주소를 이용하여 32GB의 메모리 영역을 관리할 수 있다. 한편 SBI32 모드에서는 SBI_L에 포함된 기능은 사용할 수 없다.

세 번째의 전송 방식인 단일 데이터 전송(Single Data Transfer : SDT)은 단일 32비트 데이터의 전송에 이용된다. 도 10a 및 도 10b는 각각 단일 데이터 전송의 전송 패킷과 응답 패킷을 도시한 도면이고, 도 11은 단일 데이터 전송에 의한 쓰기 및 읽기 동작의 예를 도시한 도면이다. 쓰기 동작의 경우에는 도 10a에 도시된 것과 같이 상위 32비트에 데이터가 위치하고 하위 32비트에 주소가 위치한다. 이때 SBI가 전달되지 않으므로 LID를 알 수 없어 도 11의 (a)에 도시된 바와 같이 응답 패킷이 전송되지 않는다.

그러나 응답이 반드시 필요한 경우에는 BSIZ가 0이므로 주소의 하위 2비트가 사용되지 않는다는 점을 이용하여 응답 요청을 할 수 있다. 주소의 하위 2비트가 0인 경우는 응답이 필요하지 않은 경우이고, 0이 아닌 세 가지의 경우에는 하위 2비트가 개시자를 식별하는 개시자 코드로서 사용되어 3개의 값에 대해 목적지에 미리 각각의 개시자 코드에 대응하는 LID 값을 저장하여 전송된 주소값의 하위 2비트에 해당하는 개시자에 대해 응답을 전송한다.

즉, 하나의 목적지는 최대 3개의 개시자에 대해 쓰기 동작의 단일 데이터 전송에 대한 응답을 할 수 있고, 해당 개시자는 특정 목적지에 대해 자신에게 할당된 개시자 코드를 기억하여 필요한 경우에 응답을 요청할 수 있다. 따라서 응답이 필요 없는 쓰기 동작은 반드시 주소가 32비트 단위로 정렬되며, 하위 2비트가 0으로 설정되어야 한다. 목적지에서는 BLEN, BSIZ 및 REQRSP를 제외하고는 SBI_32의 기본값을 이용하며, 세 개의 필드에 대한 기본값은 BLEN=1, BSIZ=2 및 REQRSP=0으로 한다.

쓰기 동작의 단일 데이터 전송에서 응답을 요구하는 경우에는 이러한 동작이 가능한 개시자와 목적지가 미리 정해지고, 정해진 개시자와 목적지 사이에서만 동작이 가능하다. 또한 TID가 없으므로 전송 요청 이후에 응답이 올 때까지는 다음 전송 요청을 할 수 없다는 문제도 있다. 이러한 기능은 3~4개의 IP로 구성된 서브 네트워크에서 내부 통신에 이용할 목적으로 만들어진 것이다. 따라서 전체 네트워크에 걸쳐 이러한 기능을 이용하게 되면 시스템 설계가 복잡해지고 하나의 전송 사이클이 추가로 요구되지만, AWS 명령을 이용하면 동일한 기능을 구현할 수 있으므로 반드시 필요한 경우에만 한정해서 사용하는 것이 바람직하다.

읽기 동작의 경우, 도 9b에 도시된 SBI32 모드의 읽기 동작에서의 전송 패킷과 동일하게 상위 32비트에 SBI_H가 위치하고 하위 32비트에 주소가 위치하지만, 도 10b 및 도 11의 (b)에 도시된 바와 같이 응답 패킷에 RSPD 명령어가 포함되어 응답신호와 32비트 데이터가 한번에 전송된다. SDT에서의 읽기 동작은 SBI_H가 포함되기는 하지만 단일 데이터 전송이라는 특성상 변화시킬 수 있는 제어 정보 신호가 제한적이다.

SDT에 의하면 32비트 주소 시스템 또는 64비트 시스템의 32비트 주소영역 내에서 32비트의 단일 데이터를 빠르게 전송할 수 있다. 즉, 하나의 전송 사이클 내에서 신속하게 데이터를 전달하여 전송 효율을 극대화할 수 있으며, 목적지 IP를 재구성하거나 파라미터 등을 신속하게 전송할 필요가 있을 때 이용한다. 데이터가 2개 이상 필요한 경우에는 연속해서 SDT를 2회 이상 발생시키면 되지만, 데이터가 4개 이상이거나 쓰기 전송 후 목적지에서 개시자로 결과값을 재전송해야 하는 경우에는 AWS 또는 ARS 명령을 이용하는 것이 유리하다.

USIP에서는 마지막 데이터가 DATA(E) 명령어와 함께 전달되므로 개시자에서 버스트 크기를 미리 예측할 수 없을 때 미지정(unspecified)의 버스트 길이를 이용하거나 적당한 크기의 버스트 길이를 정하고 마지막 데이터를 DATA(E) 명령어와 함께 보내면 전송이 종료되므로 조기 종료(early termination)가 가능하다.

한편, 채널폭이 128비트 이상으로 확장되는 경우에는 확장 전송(extended transfer)이 가능하다. 도 12a 및 도 12b는 확장 전송에 사용되는 전송 패킷을 도시한 도면이다. 도 12a를 참조하면, 확장 전송은 정규 전송의 경우에 있어서 AWT와 ART 명령어, 64비트 SBI 및 64비트 주소가 합쳐진 128비트 신호와 함께 전송된다. 도 12b를 참조하면, SBI32 모드의 경우에는 AWS나 ARS의 경우에 상위 64비트에 첫 번째 데이터가 포함되고, 이후 데이터 명령어와 함께 128비트의 데이터가 전송된다.

반대로 채널폭이 32비트 이하로 줄어드는 경우에 주소가 32비트 이하이면 주소를 확장시킬 필요가 없다. 도 13은 주소가 32비트 이하인 경우에 32비트 채널에서 사용되는 정규 전송 패킷을 도시한 도면이다.

도 14a 및 도 14b는 채널폭이 서로 다른 IP 간에 정규 쓰기 통신 및 SBI32 모드의 쓰기 통신이 수행되는 일 예를 도시한 도면이다. 먼저 도 14a를 참조하면, (a)에 도시된 바와 같이 64비트의 개시자와 32비트의 목적지가 통신하는 경우, 개시자의 전송 패킷은 32비트 채널에서 EXT 명령어를 이용하여 분할된다. 이때 주소는 상위 32비트가 모두 0이면 확장되지 않고 생략된다. DATA(E) 명령어와 함께 전송되는 데이터는 두 개로 분리되면서 DATA-EXT(E) 명령어를 동반한다. 즉, 마지막 64비트의 경우에 상위 32비트 데이터는 DATA 명령어와 함께 전송되고, 하위 32비트 데이터는 EXT(E) 명령어와 함께 전송된다. EXT(E)는 E=1로서 패킷의 마지막임을 의미한다.

응답 패킷의 경우, RSP 명령어와 함께 전송되는 응답신호가 32비트이므로 EXT 명령에 의해 확장할 필요가 없다. 따라서 응답 패킷은 EXT 명령어 없이 생성되고, 64비트 채널로 넘어가면서 RSP에 0이 패딩되고 데이터는 64비트 단위로 모아서 DATA 명령어와 함께 전송된다.

도 14a의 (b)에 도시된 바와 같이 개시자가 32비트이고 목적지가 64비트인 경우, 주소와 SBI는 EXT 명령어에 의해 확장되고, 데이터는 32비트 단위로 패킷이 구성된다. 또한 32비트 주소인 경우에는 확장명령 없이 전송된다. 이와 같이 전송된 전송 패킷은 목적지에 도달하여 64비트 패킷으로 바뀌면서 EXT 명령어가 사라지며, 32비트 주소인 경우에는 0으로 패딩된다. 목적지로부터 전송되는 64비트 응답 패킷이 32비트 개시자에 도달하면 데이터가 EXT 명령어를 이용하여 32비트 패킷으로 확장된다.

다음으로 도 14b를 참조하면, SBI32 모드에서는 정규 전송의 경우와 비교하여 SBI 명령어가 없는 점만 차이를 보인다. 즉, 64비트 개시자와 32비트 목적지가 통신하는 경우, 개시자로부터 전송되는 전송 패킷은 EXT 명령어를 포함하지 않고 목적지 채널에 도착하면 EXT 명령어를 포함하도록 변환된다.

64비트 패킷이 32비트 패킷으로 바뀌면 AWT와 AWS 명령어가 32비트씩 두 번에 걸쳐 전송되는데, 상위 32비트가 먼저 AWT 또는 AWS 명령어와 함께 전송되고, 하위 32비트는 EXT 명령어와 함께 전송된다. 목적지에서는 이를 64비트로 모아서 적절히 해석한다. 이때 AWT와 AWS는 서로 다른 방식으로 32비트로 분리되는데, AWT의 경우에는 상위 32비트가 AWT 명령어와 함께하고, AWS는 주소값인 하위 32비트가 AWS와 함께한다. 이는 네트워크에서 일반적으로 주소를 보고 내부 라우팅을 진행하므로 주소가 패킷의 앞에 위치하게 하고, 64비트 주소인 경우에는 상위 비트가 앞에 나타나게 해서 라우팅 사이클을 줄이기 위한 것이다.

다만, 정규 전송에서 32비트 주소 공간을 사용하는 경우에 상위 32비트는 모두 0이므로 전송하지 않고 하위 32비트를 바로 전송한다. 따라서 64비트 주소 체계를 사용하는 경우에는 상위 32비트 값이 0인 주소 영역은 사용하지 않거나 특별한 용도로만 사용하는 것이 좋다.

위 경우와는 반대로 정규 쓰기 전송에서 128비트 이상으로 변환하는 경우에는 확장 전송으로 변환하여 64비트 주소와 64비트 SBI가 하나로 모아지고, SBI32 모드의 AWS 명령어는 SBI와 데이터를 하나로 모은다.

앞에서도 설명한 바와 같이 본 발명의 USIP에서는 IP 재활용을 위해 다른 프로토콜 인터페이스 기반의 IP와의 호환성을 보장하는 PID를 이용한다. 두 개의 프로토콜만 존재할 경우에는 성능 저하를 감수해서라도 어느 정도 프로토콜 변환이 가능하지만, 셋 이상의 프로토콜이 섞여 있을 경우에는 프로토콜 변환기가 이미 한번 변환된 신호를 받게 되어 신호의 해석에 어려움이 따른다. 이 경우 통신 자체가 안 되거나 성능 저하가 매우 커질 수 있다.

따라서 SBI의 PID 값을 이용하여 처음 신호를 발생시킨 IP가 사용하는 프로토콜을 알 수 있고, 필요할 경우 SBI의 유보 영역을 이용하여 프로토콜 변환에 필요한 추가 정보를 제공할 수 있다. 유보 영역의 정보는 PID에 따라 서로 다른 의미를 가지므로 적은 비트수로도 많은 정보를 전달할 수 있다. 따라서 시스템 설계자는 시스템에 포함되는 프로토콜을 파악하여 PID를 부여하고 필요할 경우 SBI의 미사용 영역을 PID에 따라 필요한 정보를 전달하도록 정의하여 가장 효율적인 통신이 가능하도록 시스템을 설계할 수 있다.

다양한 프로토콜 기반의 IP가 섞여 있는 경우 모든 IP는 프로토콜 변환기를 통해 신호를 전달하는데, 변환기의 네트워크 방향 인터페이스는 본 발명의 프로토콜을 사용한다. 따라서 통신하는 상대편 IP가 어느 프로토콜을 사용하는지 알 수 없다. PID는 상대편 IP가 사용하는 프로토콜에 대한 정보를 제공하여 적절한 행동을 취할 수 있도록 해준다. 예를 들면, AXI 기반 IP가 AHB 기반 IP와 통신하는 경우 AHB 기반 IP는 전송 요청 이후 응답이 올 때까지 다음 전송을 시작하지 못하므로 응답을 빨리 보내주어야 전체 시스템의 성능 저하를 막을 수 있다. 또한 사용자가 유보 영역을 사용하기를 원하지 않으면 AHB 기반 IP가 이해하지 못하는 기능을 사용하지 않음으로써 원활한 통신이 이루어지도록 할 수 있다.

본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

이상에서 본 발명의 바람직한 실시예에 대해 도시하고 설명하였으나, 본 발명은 상술한 특정의 바람직한 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자라면 누구든지 다양한 변형 실시가 가능한 것은 물론이고, 그와 같은 변경은 청구범위 기재의 범위 내에 있게 된다.

Claims (8)

1. 네트워크를 통한 통신을 개시하는 인터페이스인 개시자 및 상기 개시자의 통신 개시에 응답하는 인터페이스인 목적지 사이에서의 데이터 전송을 위한 네트워크 프로토콜에 있어서,
   상기 개시자로부터 채널을 통해 상기 목적지로 전송되는 전송 신호 또는 상기 채널을 통해 상기 목적지로부터 전송되는 응답 신호에 포함된 정보를 정의하는 명령어를 포함하되, 최상위 비트가 상기 네트워크에서 상기 개시자와 상기 목적지 사이의 트랜잭션의 우선순위를 나타내는 커맨드 신호가 전송되며,
   상기 전송 신호에 포함된 제어 정보는 우선순위 필드를 포함하는 복수의 필드로 구성되고, 상기 트랜잭션의 우선순위는 상기 커맨드 신호의 최상위 비트 및 상기 우선순위 필드를 조합하여 얻어진 값을 기초로 결정되는 것을 특징으로 하는 네트워크 프로토콜.
2. 제 1항에 있어서,
   상기 전송 신호에 포함된 제어 정보에는 분할 응답 필드가 더 포함되며, 상기 응답 신호는 상기 분할 응답 필드의 값에 대응하는 길이의 복수 개의 분할 응답 신호로 나누어져 전송되되, 상기 분할 응답 필드의 값이 0이 아닌 경우에는 상기 응답 신호에 포함된 응답 정보의 버스트 길이 필드의 값에 대응하는 길이의 복수 개의 분할 응답 신호로 나누어지고, 상기 분할 응답 필드의 값이 0인 경우에는 상기 응답 신호가 상기 분할 응답 신호로 전송되지 않거나 상기 목적지에 의해 설정된 버스트 길이의 분할 응답 신호로 전송되는 것을 특징으로 하는 네트워크 프로토콜.
3. 제 2항에 있어서,
   상기 응답 신호에 포함된 응답 정보에는 상기 복수 개의 분할 응답 신호를 각각 구분하기 위한 분할 식별 필드가 더 포함된 것을 특징으로 하는 네트워크 프로토콜.
4. 제 2항에 있어서,
   상기 전송 신호가 쓰기 동작에 관한 것인 경우에 상기 버스트 길이 필드의 값은 상기 전송 신호에 의해 전달된 데이터의 버스트 길이와 동일하게 설정되는 것을 특징으로 하는 네트워크 프로토콜.
5. 제 1항 내지 제 4항 중 어느 한 항에 있어서,
   상기 전송 신호에 포함된 제어 정보에는 상기 개시자가 연결되어 있는 포트의 식별코드를 나타내는 개시자 식별 필드가 더 포함되며, 상기 목적지의 주소값을 이용하여 상기 개시자로부터 데이터가 전송되는 경우에는 상기 네트워크에 의해 상기 개시자 식별 필드의 값이 설정되고, 상기 목적지의 네트워크 좌표를 이용하여 상기 개시자로부터 데이터가 전송되는 경우에는 상기 개시자에 의해 상기 개시자 식별 필드의 값이 설정되는 것을 특징으로 하는 네트워크 프로토콜.
6. 제 1항 내지 제 4항 중 어느 한 항에 있어서,
   상기 전송 신호에 포함된 제어 정보에는 정렬 필드가 더 포함되며, 상기 정렬 필드의 값이 0이 아니면 상기 주소 정보에 대하여 비정렬 방식이 지원되는 경우에 첫 번째 바이트 레인으로부터 순차적으로 데이터가 정렬되어 전송되는 것을 특징으로 하는 네트워크 프로토콜.
7. 제 1항 내지 제 4항 중 어느 한 항에 있어서,
   상기 전송 신호에 포함된 주소 정보가 쓰기 동작을 수행할 주소 정보이고, 쓰기 동작의 대상인 데이터의 길이가 상기 채널의 폭의 절반에 해당하는 경우에는 상기 전송 신호가 상기 주소 정보와 상기 데이터를 함께 포함하는 패킷의 형태로 전송되고, 상기 전송 신호에 포함된 제어 정보의 값은 사전에 설정된 기본값으로 설정되는 것을 특징으로 하는 네트워크 프로토콜.
8. 제 7항에 있어서,
   상기 전송 신호에 포함된 제어 정보에는 상기 개시자가 연결되어 있는 포트의 식별코드를 나타내는 개시자 식별 필드가 더 포함되며, 상기 주소 정보에 포함된 개시자 코드에 대응하는 개시자 식별 필드의 값이 상기 목적지에 사전에 저장된 경우에 상기 개시자 코드를 포함하는 전송 신호를 전송한 개시자로 상기 응답 신호가 전송되는 것을 특징으로 하는 네트워크 프로토콜.

Images