KR20070020289A - 시맨틱 프로세서 저장 서버 구조 - Google Patents

Abstract

저장 서버는 클라이언트 요청에 응답하고 파스(parse)를 위해 시맨틱 프로세서를 사용한다. 시맨틱 프로세서 내의 직접 실행 파서는 입력 스트림을 파스하는데, 입력 스트림은 정의된 문법에 따르면 클라이언트 저장 서버 요청으로 구성된다. 데이타를 조정(예를 들면, 데이타 이동, 수학 및 논리 연산)할 수 있는 시맨틱 프로세서 실행 엔진은 상기 클라이언트-요청 동작을 수행하기 위해 직접 실행 파서로부터의 요청에 응답하여 마이크로코드 세그먼트를 실행한다. 결과적인 동작 효율은 몇몇 실시예에서 전체 서장 서버가 시맨틱 프로세서 자체가 작은 파워를 소모하면서 미디어 장치의 PCB에 놓일 수 있는 작은 집적 회로로 축약되게 한다.

Description

시맨틱 프로세서 저장 서버 구조{Semantic processor storage server architecture}

본 발명은 일반적으로 저장 서버에 관련된 것으로서, 좀더 구체적으로는 디지탈 시맨틱 프로세서를 사용하는 저장 서버 구현에 관련된다.

전통적으로 저장 서버(storage server)는 이하 "클라이언트"라고 불리우는 다른 컴퓨터나 연산 장치로 미디어와 파일 액세스를 제공하는 네트워크 컴퓨터이다. 저장 서버는 광대역 네트워크(WAN), 지역 네트워크(LAN) 상에서 액세스 가능하고 및/또는 다른 연산 장치와 전용 P2P 연결을 공유할 수 있다.

저장 서버는 NAS(Network Attached Storage) 서버, SAN(Storage Area Network) 서버 및 애플리케이션-스타일 서버를 포함하여 여러 가지 종류가 있다.

NAS 서버는 디렉토리 구조를 포함한다. NAS 서버로의 요청(request)은 일반적으로 파일 경로/파일명 및 생성, 읽기, 쓰기, 첨부 등의 동작을 특정한다. NAS 서버는 상기 요청(request)을 하나 이상의 디스크 섹터/블럭 디스크 액세스 트랜젝션으로 변환하고, 디스크(혹은 다른 저장 미디어)를 액세스하며, 요청된 파일-레벨 트랜젝션을 수행한다. 이러한 서버는 조각난 파일을 복원하고 디스크 혹은 다른 쓰기 가능한 미디어 상에 프리 섹터의 위치를 정하기 위한 File Allocation Table(FAT)과 파일 시작 지점을 정하기 위한 디렉토리 구조를 유지하고 이용한다.

SAN 서버는 일반적으로 디스크 섹터/블럭-기반 트랜젝션을 위한 직접 요청(request)을 수신하고, 파일 시스템이나 데이타 블록 간의 관계에 대해서 아무런 지식을 가지고 있지 않다. 비록 블록 요청이 미디어 장치 상의 블럭 물리적 블럭 동작에 관련되어 있다고는 하나, 좀더 전형적으로는 SAN 서버는 논리 블럭을 지원하고 - 그리하여 서버로 하여금 마치 RAID(Redundant Array of Independent Disks) 설계에서와 같이 하나의 물리적 디스크가 여러 개의 논리 드라이브처럼 나타나게 하거나 혹은 여러 개의 물리적 디스크 드라이브가 하나의 논리적 드라이브로 나타나도록 허용한다.

애플리케이션-스타일 서버는 일반적으로 미디어-특정 포맷에서 미디어로의 액세스를 제공한다. 예를 들면, 애플리케이션-스타일 서버는 파일로부터 스트리밍 미디어를 읽고 스트리밍 패킷 포맷에 캡슐화할 때 (파일명을 알지 못할 수도 있는 혹은 파일에 직접 액세스 하는 권한을 가진) 클라이언트에 의한 파일 경로/파일 명에 대한 확실한 지식 없이도 스트리밍 오디오 혹은 비디오로의 접근을 제공할 수 있다.

구조적으로, 대부분의 저장 서버는 일반 목적 컴퓨터와 약간 다르다. (몇몇 경우에 일반적인 디스크 드라이브와 디스크 버스 컨트롤러보다 좀더 빠른다.) 도 1은 전형적인 저장 서버(20)에 대한 블럭도이다. 중앙 처리 장치(CPU, 22), 즉 전형적으로는 하나 이상의 마이크로프로세서는 저장된 프로그램 명령에 따라 서버를 가동한다. 프로세서의 타입은 종종 시계열적(sequential) 명령 처리 실행 스타일을 제안한 그 발명자 이름을 따서 Von Neumann(VN) 프로세서 혹은 장치라 불리운다.

CPU(22)는 전면부 버스(FSB, 26)를 거쳐 메모리 컨트롤러/허브(MCH, 24)로 연결되는데, 이러한 메모리 컨트롤러/허브는 CPU(22)를 마이크로 프로세서 프로그램 명령을 저장하고 데이타를 저장, 공급 및/또는 사용하는 다른 시스템 컴포넌트로 인터페이싱하는 역할을 담당한다. MCH(24)는 메모리 버스(32)를 통해 시스템 메모리(30)를 관리한다. MCH(24)는 또한 PCI(Peripheral Component Interconnect) 연결 장치와 메모리(30) 혹은 CPU(22) 간에 데이타를 이동시키기 위해 허브 버스(42)를 거쳐 PCI 브릿지(40)와 통신한다.

많은 다른 종류의 데이타 소스/싱크 디바이스가 브릿지(40) 혹은 PCI 버스(44)를 거쳐 서버(20)에 연결될 수 있다. 저장 서버의 목적 상, 두가지 필요한 장치는 네트워크 인터페이스 카드(NIC, 50)와 ATA (AT Attachment) 컨트롤러(60)와 같은 미디어 컨트롤러이다.

NIC(50)는 서버로 하여금 LAN(Local Area Network) 혹은 다른 네트워크, 파이버 채널 스위치 패브릭(Fibre Channel switch fabric), 또는 서버에 대해 네트워크 가시성(可視性)을 제공하는 클라이언트 혹은 다른 장치로의 P2P 연결에 직접적으로 연결되도록 한다. NIC(50)은 서버가 클라이언트로부터 데이타 요청을 수신하고 그러한 요청에 응답하도록 통신 경로를 제공한다. 실제적인 네트워크 물리적 통신 프로토콜은 예를 들면 어떠한 유선 혹은 무선 통신 프로토콜이 사용될 수 있도록 다른 NIC를 삽입하고 CPU(22) 위에 그 NIC를 위한 소프트웨어 장치 드라이버를 로딩함에 의해 변경될 수 있다.

ATA 컨트롤러(60)는 하드 디스크, 광학 디스크 및/또는 테이프 드라이브와 같은 미디어 장치(64)를 부가하기 위해 적어도 하나의 ATA 버스(62)를 제공한다. 각각의 ATA 버스(62)는 하나 혹은 두개의 미디어 장치(64)가 서장 서버(20)에 부착되게 한다. 몇몇 서버는 SATA(serial ATA) 컨트롤러 혹은 SCSI(Small Computer System Interface) 호스트 어댑터와 같은 다른 컨트롤러를 채용할 수 있다.

저장 서버로 동작하기 위해, CPU(22)는 다양한 소프트웨어 프로그램을 실행하여야만 한다. NAS와 더불어, 두 공동 포맷은 NFS(Networked File System) 및 CIFS(Common Internet File System)인데, 전자는 주로 UNIX 환경에서 볼 수 있고, 후자는 마이크로소프트 운영 시스템 환경에서 볼 수 있다. NFS 서버에 대해서는, 다음과 같은 소프트웨어 프로세스가 NFS를 구현하는데 도움을 준다. NIC(50)를 위한 네크워크 장치 드라이버; TCP/IP 드라이버; RPC(Remote Procedure Call); TCP/IP에서 NFS 서버 소프트웨어로 데이타를 제시하기 위한 XDR(External Data Representation) 드라이버; NFS 서버 소프트웨어 자체; 로컬 파일 시스템; 로컬 파일 시스템에서 NFS 서버 소프트웨어를 인터페이스 하기 위한 VFS(Virtual File System) 드라이버; 데이타 버퍼링 소프트웨어; 및 저장 컨트롤러/호스트 어댑터를 위한 장치 드라이버. 각각의 NFS 데이타 트랜젝션을 위해서는, CPU(22)는 반드시 이러한 소프트웨어 엔티티(entity) 각각, 만일 필요하다면 그 들간의 스위칭 콘텍스트를 위한 프로세스를 실행하여야만 한다. 적절한 성능을 제공하기 위해, 저장 서버(20)는 마이크로 프로세서, 칩셋, 네트워크 인터페이스, 메모리 다른 주변기기 및 냉각 팬을 동작시키기 위해 강제 공냉과 상당한 정도의 파워 서플라이를 필요로 하는 상대적으로 높은 속도와 파워에서 동작한다. 1Gbps(Gigabit per second) 전이중(full duplex) 네트워크 연결에서 동작하는 현재의 기술은 대략 300W의 전력을 필요로 하고, 800 inch³ 공간을 차지하며 저장 미디어없이 약 $1,500 정도의 비용이 든다.

몇몇 사업자들은 명시적으로 NAS 요청을 프로세싱하기 위한 주문형 집적 회로 하드웨어를 제작하는 것을 시도해 왔다. 그러한 회로를 위한 설계 비용은 통신 프로토콜이 변하는 지금의 세상에서는 초과 지출될 수 없는데, 특정 프로토콜과 저장 인터페이스의 한정된 조합을 다루기 위해 제작된 특정한 복합 회로는 빠른 속도로 무용지물화 되어 가고 있다.

많은 저장 서버 애플리케이션에서 마이크로 프로세서/시퀀셜 프로그램 접근법은 비효율적이고 다루기 힘들다는 것이 인식되어 왔다. 대부분의 저장 서버의 존재는 NIC에서 수신된 클라이언트 요청에 대한 응답으로 저장 서버 기능을 수행하는데 사용되었다. 요청(requests) 그 자체는 한정된 수의 요청 기능(function)과 옵션을 가진 프로토콜-특정 포맷에서 특정하게 맞추어 만들어 진다. 이러한 요청에 응답하여 적절히 정의된 저장 시스템 커맨드가 미디어 장치로 공급되고 이러한 커맨드의 결과는 프로토콜-특정 데이타그램을 클라이언트에게 되돌려 보내는데 사용된다.

저장 서버 프로그램성(性)과 코드 공통성은 상당한 정도로 요구되는 특성이다. 따라서, (인텔사나 AMD사에 의해 사용되는 것과 같은) 큰 부피의 프로세서와 칩셋이, 프로그램성과 표준 운영 시스템의 사용을 허용하고 이렇게 함으로써 비용을 낮추기 위해 사용되어 왔다. 불행하게도 일반 목적 마이크로 프로세서 기반 시스템의 유연성과 파워는 그러한 운영 설정에서는 더더욱 사용하지 않게 되어가고 있거나 비효율적으로 사용되고 있다.

본 발명은 일반적으로 시맨틱(semantic) 프로세서로 불리우는 대표적인 실시예에서 사용하는 저장 서버를 위해 다른 구조를 제공한다. 이러한 장치는 설정 변경이 가능하고, 바람직하게는 프로세싱이 "프로그래밍"에 의존하는 VN 머신(machine)과 같이 재설정 변경 가능하다. 여기서 사용된 바와 같이, "시맨틱 프로세서"는 적어도 두 가지 컴포넌트를 담고 있다. 정의된 문법에 의거한 입력 스트림을 파스(parse)하는 직접 실행 파서(direct execution parser); 및 상기 직접 실행 파서로부터의 요청에 응답하여 (예를 들어 데이타 이동, 수학 및 논린 연산 같은) 데이타 조작을 할 수 있는 실행 엔진이다.

시맨틱 프로세서의 프로그래밍은 VN 머신에 의해 사용되는 전통적인 기계어 코드와 다르다. VN 머신에서는 데이타 패킷의 프로토콜 입력 파라미터가 브랜칭(branching), 루핑(looping) 및 드레드 스위칭(thread-switching) 비효율성과 함께 시퀀셜 기계 명령문을 사용하는 모든 가능한 입력에 시계열적으로 대조된다. 이에 반해, 시맨틱 프로세서는 입력 스트림의 시맨틱(semantics)에 직접 응답한다. 다른 말로 하면, 시맨틱 프로세서가 실행하는 "코드" 세그먼트는 입력 데이타에 의해 직접 구동된다. 예를 들면, 75 혹은 패킷에서 나타날 수 있는 CIFS 커맨드 중에서, 아래에서 상술된 실시예의 싱글 파싱 사이클은 시맨틱 프로세서가 패킷에서 전송된 실제의 CIFS 커맨드와 관련된 문법과 마이크로 명령을 로드(load)하도록 허락하기 위해 필요한 전부이다. 아래의 실시예에서 상술되는 것과 같이 저장 서버 애플리케이션에서, 시맨틱 프로세서는 선행 기술 VN 프로세서, 칩셋과 부가된 장치의 많은 기능을 수행할 수 있다. 시맨틱 프로세서는 네트워크 포트 혹은 데이타그램 인터페이스로부터 데이타그램을 수신한다. 이러한 데이타그램의 몇몇은 데이타 동작을 위한 클라이언트 요청을 포함한다. 시맨틱 프로세서는 서버에 의해 지원되는 서버 프로토콜 문법을 위해 설계된 파서 테이블(parser table)을 사용하여 수신된 데이타그램의 성분들을 파스(parse)한다. 파스된 것에 기초하여, 시맨틱 프로세서는 데이타 저장 장치(들)과 응답 데이타 동작을 처리한다. 일반적으로, 데이타 동작(data operation)은 마이크로 명령 코드 세그먼트를 단순 실행 유닛(들)에 론칭(launching)함으로써 이루어진다. 데이타 동작이 수행됨에 따라, 시맨틱 프로세서는 클라이언트에 되돌려 보내기 위해 응답 데이타그램을 생성한다. 몇몇 실시예에서는 결과적인 동작 효율은 전체 저장 서버가, 시맨틱 프로세서가 겨우 몇 와트(watt) 소모하는 미디어 장치의 PCB 상에 놓여질 수 있는 상대적으로 작은 집적회로로 모아지도록 한다.

본 발명은 도면을 참조한 개시 내용을 살펴봄으로써 가장 잘 이해될 수 있다.

도 1은 전형적인 Von Newmann 머신 저장 서버에 대한 블럭도이다.

도 2는 본 발명의 일반적인 저장 서버 실시예에 대한 블럭도이다.

도 3은 발명의 좀더 상세한 저장 서버 실시예를 블럭 형태로 나타낸다.

도 4는 이더넷(Ethernet)/IP/TCP/CIFS 저장 서버 클라이언트 요청(request) 프레임의 일반적인 구조를 보여준다.

도 5는 도 4의 CIFS 프레임 구조의 SMB(Storage Message Block) 부분을 자세히 보여준다.

도 6은 본 발명에 실시예로서 유용한 시맨틱 프로세서 구현을 블럭 형태로 보여준다.

도 7은 몇몇 개의 물리적 데이타 저장 장치를 가지는 저장 서버 구현에 대한 블럭도를 보여준다.

도 8은 데이타 저장 장치의 PCB(Printed Circuit Board)에 구현될 수 있는 본 발명의 실시예의 블럭도이다.

도 9는 디스크의 드라이브 일렉트로닉스와 직접 통신하는 시맨틱 프로세서가 있는 구현에 대한 블럭도를 보여준다.

도 10은 본 발명의 실시예에 따른 번역기(translator)-저장 서버 블럭도를 보여준다.

도 11은 외부 저장 인터페이스를 통해 시맨틱 프로세서에 의해 복수의 물리적 데이타 저장 장치가 액세스되는 시스템 실시예를 보여준다.

도 12는 다중 물리적 데이타 저장 장치가 포트 확장기(extender)를 통해 시맨틱 프로세서에 연결된 시스템 실시예를 보여준다.

도 13은 본 발명의 실시예에서 유용한 다른 시맨틱 프로세서 구현 예를 보여준다.

도 14는 본 발명의 실시예에서 유용한 시맨틱 프로세서를 블럭 형태로 나타낸다.

도 15a는 본 발명의 실시예에서 유용한 한가지 가능한 파서 테이블(parser table) 구조를 보여준다.

도 15b는 본 발명의 실시예에서 유용한 한가지 가능한 프로덕션 룰 테이블(production rule table) 구조를 보여준다.

도 16은 본 발명의 실시예에서 유용한 입력 버퍼를 위한 구현을 블럭 형태로 나타낸다.

도 17은 본 발명의 실시예에서 유용한 직접 실행 파서(DXP)의 구현을 블럭 형태로 나타낸다.

도 18은 도 14에서 시맨틱 프로세서에서 데이타 입력을 처리하기 위한 흐름도 예를 담고 있다.

도 19는 본 발명의 실시예에서 유용한 다른 시맨틱 프로세서 구현을 나타낸다.

도 20은 본 발명의 실시예에서 유용한 포트 입력 버퍼(PIB)에 대한 한 실시예를 블럭 형태로 나타낸다.

도 21은 본 발명의 실시예에서 유용한 직접 실행 파서(DXP)를 위한 다른 실시예를 블럭 형태로 나타낸다.

도 22는 도 19의 시맨틱 프로세서에서 데이타 입력을 처리하기 위한 흐름도를 담고 있다.

도 23은 본 발명의 실시예에서 유용한 시맨틱 프로세서를 블럭 형태로 나타낸다.

도 24는 도 23에서 재순환 버퍼와 함께 시맨틱 프로세서에서 수신된 패킷을 프로세싱하기 위한 흐름도를 담고 있다.

도 25는 본 발명의 실시예에서 유용한 다른 좀더 상세한 시맨틱 프로세서를 나타낸다.

도 26은 도 25의 시맨틱 프로세서에서, 수신된 IP 조각 패킷의 흐름도를 담고 있다.

도 27은 도 25의 시맨틱 프로세서에서 수신된 암호화된 및/또는 인증되지 않은 패킷의 흐름도를 담고 있다.

도 28은 본 발명의 실시예에서 유용한 다른 시맨틱 프로세서 구현을 나타낸다.

도 29는 도 28의 시맨틱 프로세서에서 TCP 연결을 통해 수신된 iSCSI 패킷의 흐름도를 담고 있다.

도 30 내지 43은 좀더 상세한 메모리 서브 시스템이다.

도 2는 본 발명의 많은 실시예를 대표하는 고(高) 레벨의 도면을 나타낸다. 저장 서버는 데이타그램 인터페이스(90)와 저장 인터페이스(110)를 갖는 시맨틱 프 로세서(100)로 구성된다. 데이타그램 인터페이스(90)는 보이는 바와 같이 네트워크(80)를 통해 혹은 클라이언트로 P2P 연결을 거쳐 서버로 클라이언트 연결성을 제공한다. 저장 인터페이스(110)는 시맨틱 프로세서가 클라이언트 요청에 응답하여 데이타 저장 장치(12)와 데이타 트랜젝션을 개시하기 위한 경로(path)를 제공한다. 데이타 저장 장치는 로컬일 수 있다. 데이타 저장 장치는 예를 들면 만약 시맨틱 프로세서(110)가 물리적 저장을 위해 리모트 SAN 서버를 같은 시간에 사용하는 동안 클라이언트로 NAS 서버를 에뮬레이트한다면, 선택적으로, 제시된 서버로 네트워크상 연결일 수 있다.

도 3은 시맨틱 프로세서(100)를 포함하는 저장 서버(200)의 좀더 상세화된 블럭도를 포함한다. 데이타그램 인터페이스(90)는 시맨틱 프로세서(100)의 버퍼(130)를 물리적 인터페이스 장치(PHY) 즉, 이더넷, 파이버 채널, 802.11x, 범용 시리얼 버스, 파이어 와이어(Firewire), 혹은 다른 물리적 레이어(layer) 인터페이스를 위한 광학, 전기 혹은 무선 주파수 드라이버/수신기 쌍으로 연결한다. 데이타그램 인터페이스는 버퍼(130)로 입력 디지털 데이타 스트림을 제공하고, 버퍼(130)로부터 출력 디지털 데이타 스트림을 수신한다.

도 3에서, 저장 인터페이스(110)는 데이타 저장 장치(120)와 시맨틱 프로세서(100) 간에 블럭 I/O로서 구현되어 있다. 다양한 실시에에서, 이 버스는 시맨틱 프로세서와 데이타 저장 장치의 구성 성능에 따라서 케이블 연결(iSCSI, 파이버 채널, SATA) 혹은 회로 보드 버스(SATA)일 수 있다. 도 3은 예를 들면 디스크 컨트롤러(122), 드라이브 일렉트로닉스(124) 및 디스크 플래터, 모터 및 읽기/쓰기 헤 드(126) 같은 하드 디스크 타입의 미디어 장치의 주요 구성 성분을 보여준다.

시맨틱 프로세서(100)를 위한 하나의 구성이 도 3의 저장 서버에서 나타나 있다. 시맨틱 프로세서(100)는 버퍼(130)(즉, 입력 "스트림")에서 수신된 입력 패킷 혹은 프레임의 프로세싱을 제어하는 직접 실행 파서(DXP, 140)를 포함한다. DXP(140)는 현재 프레임에서 현재 심볼까지의 파싱에 기초하여 터미널과 논-터미널(non-terminal) 심볼의 내부 파서 스택을 유지한다. 파서 스택의 탑(top)에서의 심볼이 터미널 심볼(terminal symbol)일 때, DXP(140)는 입력 스트림 헤드에서의 데이타를 터미널 심볼에 대조하고 계속 진행하기 위해 매치를 기대한다. 파서 스택의 탑에 있는 심볼이 논-터미널(non-terminal) 심볼인 때에, DXP(140)는 스택 상에 문법 프로덕션(production)을 확장하기 위해 논-터미널 심볼과 현재 입력 데이타를 사용한다. 파싱이 진행됨에 따라, DXP(140)는 시맨틱 코드 명령 엔진(SEE, 150)이 입력의 세그먼트를 프로세스하거나 다른 동작을 수행하도록 명령한다.

이 구조는 실행 엔진에 과제를 할당하는 정교한 문법 파서와 함께, 데이타가 요구하는 바에 따라, 데이타그램 프로토콜과 같은 매우 구조화된 입력에 대해 유연성이 있고 강력하다. 바람직한 실시예에서, 시맨틱 프로세서는 테이블을 수정함에 의해 재설정 가능하고, 그렇게 함으로써 VN 머신의 유연성을 갖는다. 시맨틱 프로세서가 주어진 입력에 대해 응답하기 때문에, 시맨틱 프로세서는 일반적으로 VN 머신보다 좀다 작은 명령 세트로 효과적으로 동작할 수 있다. 명령 세트는 또한 이득을 가져다 주는데 이는 시맨틱 프로세서가 아래에서 설명되는 바와 같이 머신 콘텍스트에서 데이타 프로세싱을 허락하기 때문이다.

시맨틱 프로세서(100)는 주어진 기능을 수행하기 위해 적어도 세 개의 테이블을 사용한다. 프로덕션 룰을 가져오기 위한 코드는 파서 테이블(PT, 170)에 저장되어 있다. 문법 프로덕션 룰은 프로덕션 룰 테이블(PRT, 180)에 저장되어 있다. SEE(150)를 위한 코드 세그먼트는 시맨틱 코드 테이블(SCT, 190)에 저장되어 있다.

파서 테이블(170)에서의 코드는 테이블(180)에서 프로덕션 룰을 가리킨다. 파서 테이블 코드는 예를 들면 열-행 포맷 혹은 컨텐트-어드레서블 포맷으로 저장되어 있다. 열-행 포맷에서는, 테이블의 열이 내부 파서 스택 상의 논-터미널 코드에 의해 인덱스되고, 테이블의 행은 입력의 헤드(예를 들어 현재 Si 버스 상에 있는 심볼)에서 입력 데이타 값에 의해 인덱스된다. 컨텐트-어드레서블 포맷에서, 논-터미널 코드와 입력 데이타 값의 연결은 테이블에 입력을 제공할 수 있다.

프로덕션 룰 테이블(180)은 파서 테이블(170)에서 코드에 의해 인덱스된다. 테이블들은 도 3에 나타난 바와 같이 연결될 수 있는데, 파서 테이블로의 쿼리(query)는 논-터미널 코드와 입력 데이타 값에 적용가능한 프로덕션 룰을 직접적으로 되돌려줄 것이다. 직접 실행 파서는 스택의 탑에서 논-터미널 코드를 PRT로부터 되돌려진 프로덕션 룰로 대체할 것이고 그 입력을 파스하는 것을 계속할 것이다.

실제적으로, 많은 다른 문법을 위한 코드는 프로덕션 룰 테이블에 동시에 있을 수 있다. 예를 들면, 코드의 한 세트는 MAC(Media Access Control) 패킷 헤더 포맷 파싱에 관련되고, 다른 코드 세트는 ARP(Address Resolution Protocol) 패킷 프로세싱, 인터넷 프로토콜(IP) 패킷 프로세싱, TCP(Transmission Control Protocol) 패킷 프로세싱, RTP(Real-time Transport Protocol) 패킷 프로세싱 등에 관련될 수 있다. CIFS, NFS 및/또는 다른 저장 서버 프로토콜을 위한 문법은 저장 서버 성능을 더하기 위해 프로덕션 룰 코드 메모리에 더해진다. 논-터미널 코드는 프로덕션 룰 코드 메모리(122) 혹은 특정 프로토콜에 관련된 블럭 내에 어떤 특정한 순서로 할당될 필요는 없다.

시맨틱 코드 테이블(90)는 파서 테이블 코드에 의해 및/또는 프로덕션 룰 테이블(180)로부터 인덱스될 수 있다. 일반적으로, 파싱 결과는 DXP(140)로 하여금 주어진 프로덕션 룰에 대해 시맨틱 코드 테이블(190)로부터의 코드 세그먼트가 로드되고 SEE(150)에 의해 실행되어야 하는지의 여부를 검출하도록 허용한다.

시맨틱 코드 실행 엔진(150)은 머신 콘텍스트(160)로의 액세스 경로를 가지는데, 머신 콘텍스트는 구조화된 메모리 인터페이스이고 컨텍스츄얼(contextual) 심볼에 의해 주소 지정이 가능한다. 머신 콘텍스트(160), 파서 테이블(170), 프로덕션 룰 테이블(180) 및 시맨틱 코드 테이블(190)은 동기 DRAM 및 CAM 혹은 이러한 리소스의 조합과 같은 외부 메모리와 온칩 메모리를 사용할 수 있다. 각각의 테이블 혹은 콘텍스트는 하나 혹은 그 이상의 다른 테이블 혹은 콘텍스트와 함께 단지 공유된 물리적 메모리로의 콘텍스츄얼(contextual) 인터페이스를 제공할 것이다.

시맨틱 프로세서(100)의 기능 블럭을 위한 상세한 설계 최적화는 본 발명의 사상에 포함되지 않는다. 적용 가능한 시맨틱 프로세서 기능 블럭도의 상세한 구조 예를 위해서는, 독자는 현재 계류 중인 출원 10/351,030을 참조하면 될 터인데, 현재 본원에 결합되어 있다.

저장 서버 콘텍스트에서 시맨틱 프로세서(100)의 기능은 특정 예로 더 잘 이해될 수 있을 것이다. 이 예에서는, CIFS 커맨드와 데이타 구조가 이더넷/IP/TCP 지원 구조에서 사용된다. 당업자는 이미 나타난 개념이 다른 서버 통신 프로토콜에도 적용된다는 것을 인식할 것이다.

도 4는 (트레일러와 체크섬을 무시한) 이더넷/IP/TCP/CIFS 프레임(250)의 관련된 헤더/데이타 블럭을 보여준다. MAC 헤더는 무엇보다도, 서버(200)를 위해 의도된 모든 프레임을 위한 서버(200)의 MAC 어드레스를 포함한다. 서버(200)는 여러 가지 네트워크와 트랜스포트 프로토콜을 지원할 수 있지만 여기 예에서는 IP(Interent Protocol) 네트워크 헤더와 TCP(Transmission Control Protocol) 트랜스포트 프로토콜 헤더를 사용한다. 다음의 TCP 헤더는 CIFS SMB(Storage Message Block) 헤더 HEADER1과 HEADER1에 관련된 데이타를 포함하는 SMB 데이타 버퍼 BUFFER1이다. 많은 CIFS 오피코드(opcode)는 최대 프레임 길이가 넘지 않는 한, 만일 원한다면 동일한 SMB에서 다른 CIFS 오피코드(opcode)와 결합될 수 있다. 제2, 제3 등의 오피코드를 위한 추가적인 헤더는 제 1 헤더에서 암시된 다른 모든 필드와 함께, 제 1 헤더의 마지막 몇 개의 필드만을 포함한다. 보이는 바와 같이, 마지막 SMB 헤더는 HEADERN과 BUFFERN을 포함한다.

도 5는 프레임의 제 1 SMB 헤더와 버퍼에 대한 추가적인 상세도이다. 전체 SMB 헤더는 일단 그 프로토콜을 의미하는데, 즉, 문자 0xFF는 이것이 SMB 헤더인 것을 의미한다. 커맨드 문자는 프로토콜 문자에 뒤이어 나오는데, 요청되고 있는 혹은 응답하는 동작에 대한 오피코드(opcode)를 나타낸다. 스테이터스(status) 및 플래그(flags) 필드는 어떻게 다른 SMB 필드가 해석되어야만 하는지 및/또는 에러가 발생했는지를 판단한다. MAC 시그내쳐(이 경우 MAC은 Media Authentication Code를 나타낸다)는 유효한 때에는, 메시지를 인증하는데 사용될 수 있다.

SMB의 다음 4개의 필드는 TID, PID, UID 및 MID 필드이다. TID(Tree Identifier)는 클라이언트가 성공적으로 서버 리소스에 연결되었을 때 서버에 의해 클라이언트에 할당된다. 클라이언트는 할당된 TID가 나중의 요청에서 그 리소스를 참조하는데 사용한다. PID(Process Identifier)는 클라이언트에 의해 할당되는데 비록 서버가 PID를 인식하고 클라이언트에 응답하기 위해 그것을 사용함에도 불구하고 그 사용은 전적으로 클라이언트에 달려있다. UID(User Identifier)는 연결을 인증한 사용자를 식별하기 위해 서버에 의해 할당된다. MID(Multiplex Identifier)는 각각의 트랜젝션을 위해 서로 다른 MID를 사용함으로써, 클라이언트가 다중 미결 트랜젝션을 위해 동일한 PID를 사용하도록 허용한다.

파라미터 필드는 다양한 길이와 구조를 갖는데, 첫 번째 문자는 일반적으로 다음의 파라미터의 길이를 가리키고, SMB 오피코드에 적절한 파라미터 워드가 뒤이어 온다. 만일 오피코드가 제 2 SMB 헤더이고 버퍼가 따라오는 것이라면, 어떤 파라미터 워드는 뒤따르는 오피코드이고 뒤따르는 간략화된 헤더에 대한 옵셋임을 나타낸다.

SMB는 바이트 카운트와 바이트 카운트 길이의 버퍼와 함께 끝난다. 이러한 버퍼는 파일명을 보내거나, 쓰기 데이타를 서버로 전송하거나 혹은 읽기 데이타를 클라이언트로 전송하는데 사용된다.

이러한 배경하에 시맨틱 프로세서(100)(도 3)를 위한 기본 CIFS 기능 설명이 진행될 수 있다.

도 3과 도 4를 참조하면, 버퍼(130)에서 수신된 각각의 새로운 프레임은 MAC 헤더와 함께 시작된다. MAC 헤더는 목적지 어드레스, 소스 어드레스, 패이로드 타입 필드, 패이로드, 체크섬(checksum)을 포함한다. DXP(140)는 할당된 어드레스(들)을 저장 서버(200) 그리고 브로드캐스트(broadcast) 어드레스와 일치를 위해 목적지 어드레스를 파스(parse)한다. 만일 목적지 어드레스가 파스를 실패하면, DXP는 프레임을 몰아내기 위해 SEE(150) 상에 SEE 코드 세그먼트를 론칭(launch)한다. 그렇지 않으면, 소스 어드레스는 SEE에 의해 소모되고, 응답에서의 사용을 위해 저장되며, 패이로드 타입 필드는 파스된다.

이 예에서, MAC 패이로드 타입은 IP로 파스된다. DXP는 결과적으로 파서 자신의 파서 스택 상으로 파싱되는 IP 헤더를 위한 프로덕션 룰을 로드하고, IP 헤더를 통해 작업을 수행한다. 이는 예를 들어 패킷이 저장 서버를 위해 의도되었다는 것을 확인하기 위해 목적지 IP 어드레스를 파싱하는 것과, 리턴 패킷을 위해 IP 헤더 체크섬을 체크하고, 어드레싱 테이블을 갱신하고, 목적지 및 소스 어드레스를 저장하기 위해 SEE를 발송하는 것과 다른 프로세싱 및/또는 IP 조각 패킷을 재조립하는 것을 포함한다. IP 헤더에서 나타난 프로토콜은 다음 헤더(이 경우에는 TCP 헤더)를 위한 프로덕션 룰을 DXP 파서 스택 상에 로드하도록 파스된다.

그 다음 TCP 헤더가 파스된다. SEE는 목적지 어드레스, 소스 IP 어드레스, 목적지 포트 및 소스 포트(만약 유효한 연결이 존재할 때 - 이 예에서는 이 조건이 만족되었다고 가정)와 관련된 TCP 연결 콘텍스트를 로드하도록 발송된다. SEE는 그러고나서 연결 콘텍스트를 갱신하기 위해 필요한 시퀀스 번호, 인식(acknowledgment) 번호, 윈도우, 체크섬 및 다른 필드를 소비한다. 연결 콘텍스트는 응답에서 사용을 위해 저장된다.

MAC, IP 및 TCP 헤더가 저장 서버로 유효한 연결로 파스되었다고 가정하면, 입력 스트림에서 다음 심볼은 데이타가 SMB 요청을 포함한다는 것을 나타낼 것이다. DXP(140)는 이 심볼을 파스하고 그것의 스택 상에 CIFS 문법 프로덕션 룰을 로드한다.

다음 입력 심볼은 CIFS 커맨드(CIFS 오피코드)를 위한 논-터미널 심볼과 매치될 것이다. 예를 들면, 파서 테이블은 CIFS 오피코드와 이 논-터미널 심볼의 각각의 가능한 조합을 위한 엔트리를 포함할 수 있다. CIFS 커맨드가 파스된 때에, 커맨드 필드에 있는 CIFS 오피코드 관련 문법이 파서 스택에 로드된다.

CIFS 헤더의 스테이터스와 플래그는 파스될 수 있지만, 바람직하게는 SEE(150)에 의해 소모되고 패킷 컨텐트를 해석하는데 있어서 필요한 사용을 위해 머신 콘텍스트(160)에 저장된다.

MAC 시그내쳐, TID, PID, UID 및 MID 필드는 리턴 프레임을 만드는데 사용되기 위해 필드를 저장하는 SEE로 향하게 되고, 유효한 소스로부터 유래하고 적절한 리소스로 방향지워진 바와 같이 패킷을 인증하기 위해 머신 콘텍스트(160)에서 검색을 수행한다.

파라미터 필드 포맷은 CIFS 오피코드에 따라 달라진다. 오피코드에 따라, 파 라미터 필드의 구성 성분을 파스하거나 SEE(150)가 마이크로코드의 세그먼트를 사용하여 파라미터를 소모하는 것이 바람직할 것이다. 보통의 CIFS 커맨드에 대한 몇몇 예들이 주어질 것이다.

CIFS NEGOTIATE 클라이언트 요청은 클라이언트가 이해하는 CIFS 특수 언어를 식별하기 위해 새로운 클라이언트에 의해 사용된다. NEGOTIATE를 위한 파라미터 필드는 ByteCount를 포함하는데, 널(NULL)-종료 스트링으로서, 받아들일 수 있는 특수 언어 목록을 작성하는 ByteCount가 뒤따라 온다. NEGOTIATE를 위한 프로덕션 룰은 SEE(150)가 ByteCount를 저장하도록 DXP(140)를 재촉하고, DXP(140)는 NULL 문자까지 제 1 입력 스트링을 파스한다. 만일 스트링이 알려진 특수 언어까지 파스하면, DXP(140)는 SEE(150)로 하여금 현재 프레임 콘텍스트에 대한 특수 언어에 대한 코드를 저장하게 한다. SEE(150)는 모든 특수 언어가 파스되었는지를 나타내는 ByteCount 심볼이 파스되었는지 여부를 결정한다. 만일 그렇지 않다면, SEE(150)는 파서 스택의 탑(top) 위에 논-터미널 심볼을 푸쉬하는데, 이는 DXP(140)가 다른 특수 언어를 위해 남은 입력을 파스하도록 한다. 프로세스는 ByteCount 심볼이 파스될 때까지 계속된다. 이 때, SEE(150)는 DXP(140)가 특수 언어를 위해 파싱을 멈추게 하기 위해 입력 스트림의 헤드 위로 심볼을 푸쉬한다. DXP(140)는 그리고 나서 패킷 파싱을 종료하고 SEE(150)가 특수 언어(즉, 미리 프로그램된 계측 선호도에 따라)를 선택하도록 명령하고 새로운 세션과 관련된 파라미터에 함께 클라이언트에게 응답 패킷을 되돌려 보낸다. SEE(150)는 또한 머신 콘텍스트(160) 내에 새로운 세션 콘텍스트를 셋업한다.

클라이언트가 NEGOTIATE 응답을 수신하는 때에, 보통은 클라이언트는 SESSION_SETUP_ADNX가 세션을 종료하도록 SMB를 전송할 것이다. DXP(140)는 이 SMB를 받은 때에, 제 1 파라미터(WordCount)를 파스할 수 있고 또한 이것이 오피코드로 맞는 것인지를 검증한다. 제 2 파라미터인 AndXCommand는 제 2 커맨드 X가 역시 이 커맨드를 따라 이 프레임에 나타나는지 그리고 어떤 커맨드가 나타나는지를 나타낸다(CIFS는 다중-오피코드 SMB를 형성하기 위해 다음의 오피코드와 연결될 수 있는 오피코드인지를 식별하기 위해 "AndX"를 사용한다). 만일 AndXCommand가 어떤 제 2 오피코드도 존재하지 않는다고(0xFF) 나타내면, DXP(140)는 이것을 파스하고 계속 실행할 수 있다. 만일 개별적인 오피코드가 존재하면, 프로세싱은 좀더 복잡하다.

제 2 오피코드는 여러 가지 방법으로 취급될 수 있다. 한 가지 방법은 제 1 및 제 2 오피코드의 각각의 다양한 조합을 위해 구분되는 문법 변형을 기록하는 것이다. 이는 그럴듯하지만, 파서 테이블 및 프로덕션 룰 테이블 제한에 따라서는 잠재적으로는 비효율적이다. 다른 방법은 높은 레벨의 문법 파싱 오피코드 및 각각의 파스된 오피코드를 프로세싱하는 낮은 레벨 문법을 가지는 다중-레벨 문법을 사용하는 것이다. 제 3의 방법은 SEE(150)로부터 푸쉬백(pushback) 매커니즘을 사용하는 것이다. 이 방법에서는, 예를 들면, AndXCommand 파라미터는 SEE(150)가 입력 스트림으로부터 AndXCommand를 저장하도록 하는 프로덕션 룰을 로드한다. 제 1 오피코드가 완전히 파스되었을 때, SEE(150)은 AndXCommand 파라미터를 입력 스트림의 헤드 상으로 다시 푸쉬하는 마이크로코드 세그먼트를 실행하도록 촉구된다. DXP(140)는 그러고 나서 새로운 오피코드를 파스하고 그 시점부터 계속하는데, 만일 제 2 오피코드가 있다면 새로운 오피코드를 위해 파라미터 필드 문법을 로드한다. SMB에서 추가적인 AndX 커맨드는 동일한 방법으로 취급될 것이다.

SESSION_SETUP_ANDX의 다른 파라미터들은 파싱없이, 대부분이 세션 콘텍스트에서 저장되어야 할 혹은 패스워드의 경우 검증되어야 할 파라미터를 포함하는 것과 비슷하게 SEE(150)에 의해 소모될 것이다. NULL-종료 스트링 파라미터는 널 종료 심볼(null termination symbol)을 가리키도록 파스될 수 있고, 뒤이어 SEE(150)로 하여금 그 길이가 이제 결정되는 심볼을 저장하도록 하는 명령이 뒤따른다.

일단 SESSION_SETUP_ANDX 커맨드가 파스되면, SEE(150)에는 응답 패킷을 만들도록 명령이 주어진다. 하지만 만일 제 2 오피코드가 포함된다면, 각각의 오피코드가 프로세스될 때가지는 패킷은 완결되지 않을 것이다.

LOGOFF_ANDX 커맨드는 세션을 종료하도록 사용된다. 이 오피코드에 대응하여 시맨틱 프로세서에 의해 수행되는 주 기능은 SEE(150)로 하여금 당해 세션을 위해 머신 콘텍스트(160)로부터 세션 콘텍스트를 제거하도록 하는 것이다.

TREE_CONNECT_ANDX 커맨드는 세션을 파라미터 스트링 Path에 의해 표시된 공유된 서버 리소스와 연결하는 것을 위해 사용된다. 이 커맨드와 함께 포함된 Path 스트링은 오직 길이를 위해 파스될 수 있고 및/또는 정확한 서버명을 위해 파스될 수도 있다. Path 명의 나머지도 파스될 수 있는데, 유효한 경로가 생성될 수 있고 쓰기 가능한 리소스에서 자주 파괴될 수 있기 때문에, 각각의 디렉토리에 대한 정확한 프로덕션 룰 코드를 가지고 있는 것은 상당히 어려운 일일 것이다. 따라서, 경로(path)는 개방을 위해 전형적으로는 SEE(150)로 넘어간다. 선택적으로, DXP(140)는 "/" 문자에 대해 파스할 수 있고 경로(path)를 SEE(150)로 한 번에 한 레벨씩 넘겨준다. SEE(150)는 블럭 I/O 버스(110)를 거쳐 데이터 저장 장치(120) 상에 저장되어 있는 디렉토리를 읽고, 루트 디렉토리에서 시작하고 요청된 경로가 존재하고 클라이언트에 의해 제한되지 않는다는 것을 확인함으로써 지정된 경로를 통해 통과한다. 경로가 유효하고 사용가능하다고 가정하면, SEE(150)는 응답 패킷을 만들고 세션 콘텍스트에 경로를 저장한다.

NT_CREATE_ANDX 커맨드는 파일 혹은 디렉토리를 생성하거나 오픈한다. 트리 연결 커맨드 같이, DXP(140)는 데이타 저장 장치(120)와 블럭 I/O 트랜젝션을 위해 SEE(150)로 이러한 커맨드의 대부분을 넘겨준다. SEE(150)는 만일 가능하다면, 적절한 디렉토리를 수정하고, 파일 식별자(file identifier: FID)를 오픈 파일에 지정하고, 머신 콘텍스트(160)에 오픈 파일을 위한 파일 콘텍스트를 생성함으로써 이 파일을 오픈 및/또는 생성한다. SEE(150)는 그 다음 파일 생성/오픈 요청의 결과를 나타내는 적절한 응답 프레임을 구성한다.

READ_ADNX와 WRITE_ANDX 커맨드는 오픈 FID로 혹은 이것으로부터 데이타를 읽고 쓰기 위해 클라이언트에 의해 사용된다. DXP가 FID 파라미터로 파스되는 때에, DXP는 SEE(150)가 Si-버스로부터 FID를 제거하고 머신 콘텍스트(160)에 대응되는 파일 콘텍스트를 지정하도록 신호를 준다. SEE(150)는 이 후에 데이타 저장 장치(120) 상에 데이타를 읽거나 쓰기 위한 적절한 블럭 I/O 트랜젝션을 수행하고 클라이언트에게 리턴 패킷을 만든다. 쓰기 동작 리턴 프레임은 선택적으로 만들어질 수 있고 데이타 저장 장치와의 모든 블럭 I/O 트랜젝션이 완결되기 전에 전송된다.

위에서 제시된 커맨드들은 가능한 CIFS 커맨드의 부분집합이다. 당업자는 위에서의 예로부터 어떻게 시맨틱 프로세서가 완전한 CIFS 기능성을 구현할 수 있는지를 이해할 수 있을 것이다. 더욱이, 이러한 CIFS 커맨드를 수행하는 시맨틱 프로세서에 의해 예시되는 개념은 시맨틱 프로세서 상에 다른 저장 서버 프로토콜을 구현하는데 있어 적용가능하다.

도 6은 다른 시맨틱 프로세서 실시예(300)를 보여준다. 시맨틱 프로세서(300)는 4개의 시맨틱 코드 실행 엔진(152, 154, 156 및 158)을 포함한다. 시맨틱 코드 실행 엔진(158)은 블럭 I/O 회로(112)와 통신한다. 머신 콘텍스트(160)는 두 개의 기능 유닛인 다변 머신 콘텍스트 데이타 메모리(variable machine context data memeory : VMCD, 162)와 어레이 머신 콘텍스트 데이타 메모리(array machine context data memory : AMCD, 164)를 갖는다. 각각의 SEE는 V-Bus를 통해 VMCD(162)와 그리고 A-Bus를 통해 AMCD와 상호 동작을 수행할 수 있다.

시맨틱 프로세서(300)에서, DXP(140)는 SEE 작업이 파싱 중 특정 지점에서 론치(launch)되어야 한다고 결정하는 때에, DXP(140)는 SEE 중의 하나가 SCT(140)로부터 마이크로 명령을 로드하도록 신호를 준다. 어떤 명령 세크먼트를 핸들링하는 것은 DXP(140)에게 DXP가 어떤 사용 가능한 SEE를 선택할 수 있다고 가리킬 수 있고 혹은 이러한 핸들링은 특정 SEE(예를 들면 블럭 I/O 112로의 유일한 액세스인 SEE 158)가 그 코드 세그먼트를 수신하여야 한다는 것을 가리킬 수도 있다. 복수 SEE의 사용 가능성은 (블럭 I/O 같은) 몇몇 느린 작업이 모든 프로세싱을 가로막는 것 없이 많은 작업들이 평행하게 진행될 수 있도록 허용한다.

비록 엄격하게 필요한 것은 아니지만, 특정한 종류의 작업은 특정 SEE에 할당될 수 있다. 예를 들면, SEE 152는 IP, TCP 및 다른 프로토콜의 입력 측을 핸들링하고, 들어오는 CIFS 프레임으로부터 데이타로 클라이언트, 세션 및 파일 콘텍스트를 갱신하는 것을 담당하는 지정된 입력 프로토콜 SEE가 될 수 있다. SEE 154는 디렉토리, file allocation table 및 사용자/패스워드 리스트를 파악하고 갱신하는 혹은 사용자와 요청을 인증하는 것과 같은 파일 시스템 오퍼레이션을 수행하도록 지정될 수 있다. SEE 156은 응답 프레임을 만드는 것과 같은 프로토콜의 외부적 측면을 처리하도록 지정될 수 있다. SEE 158은 데이타 저장 장치(들)과의 트랜젝션을 처리하도록 지정될 수 있다. 그러한 배분과 더불어, 하나의 SEE는 다른 파싱 작업으로 넘어간 DXP(140)를 거쳐가야 하는 일 없이, 다른 SEE에 마이크로코드를 론칭(launching)할 수 있다. 예를 들면, SEE 154는 디렉토리를 회수하거나 갱신하기 위해 블럭 I/O SEE 158 상에 작업을 론칭할 수 있다. 다른 예로서, 출력 프로토콜 SEE 156은 응답 패킷에 대해 데이타가 준비된 때에 다른 SEE에 의해 세트될 수 있는 신호를 가질 수 있다.

각각의 SEE는 데이타에 머신-콘텍스트 액세스를 허용하기 위한 파이프라인 레지스터를 포함한다. 표준 CPU와 반대로, 바람직한 SEE 실시예는 SEE 실시예가 그 위에서 동작하게 되는 데이타에 사용되는 물리적 데이타 저장 구조 개념을 가지고 있지 않다. 대신에, 데이타에 대한 액세스는 머신-콘텍스트 트랜젝션 형태를 가진다. (예를 들어 스칼라 같은) 다양한 데이타는 V-bus 상에서 액세스되고 어레이 데 이타는 A-bus 상에서, 그리고 입력 스트림 데이타는 Si-bus 상에서 액세스된다. 예를 들면, 데이타 콘텍스트 ct 내의 주어진 위치 offset에 위치한 길이 m 옥텟(octet)의 스칼라 데이타 요소를 읽기 위해, SEE는 버스 요청 {read, ct, offset, m}을 발행하는 V-bus 인터페이스를 촉구하기 위해 명령 디코더를 사용한다. 콘텍스트 mct는 시맨틱 프로세서의 마스터 콘텍스트(master context)를 가리키고, 다른 서브-콘텍스트는 RSP가 각각의 능동 CIFS 세션, 각각의 오픈 파일, 각각의 오픈 트랜젝션 등과 같은 입력 데이타를 처리함에 따라 보통 생성되고 없어진다.

일단 SEE 파이프라인 레지스터에 커맨드가 내려 지면, SEE 파이프라인 레지스터는 데이타 전송 프로세스를 처리한다. 만일 다중 버스 전송이 m 옥텟(octet)을 읽거나 쓰기 위해 필요하다면, 파이프라인 레지스터는 완결을 위해 트랜젝션을 추적한다. 예로써, 6-옥텟(octet) 필드는 두 개의 마이크로 명령 - 제 1 명령은 Si-bus로부터 파이프라인 레지스터로 6-옥텟을 읽고, 제 2 명령은 레지스터에서 V-bus를 통해 머신-콘텍스트 변수에 6-옥텟을 쓴다 - 을 사용하여 스트림 입력으로부터 머신 콘텍스트 변수로 전송될 수 있다. 레지스터 인터페이스는 전송에 영향을 미치는데 필요한 아무리 많은 버스 데이타 싸이클이라도 수행한다.

VMCD(162)는 V-bus 상에서 개시된 요청을 취급한다. VMCD(162)는 머신-콘텍스트 변수 데이타 요청을 물리적 메모리 트랜젝션으로 변환하는 능력을 가진다. 그리하여 VMCD(162)는 우선적으로 물리적 메모리 개시 어드레스로 변환 테이블 레퍼런싱 머신 콘텍스트 식별자(translation table referencing machine context identifier)를 유지하고, 콘텍스트 할당 및 할당 해제를 위한 메커니즘을 포함하고, 콘텍스트가 주어진 SEE에 의해 잠기게(lock) 되고, 요청된 트랜젝션이 요청된 콘텍스트의 범위 바깥으로 내던져지지 않는 것을 확증한다. 채용된 실제의 저장 메커니즘은 애플리케이션에 따라 변한다. 메모리는 완전히 내부에 있을 수도 있고, 완전히 외부 장치일 수도 있으며, 두 개가 섞여있을 수도 있고, 큰 외부 메모리를 가진 캐쉬 등일 수도 있다. 외부 메모리는 주어진 구현에서 AMCD, 입력 및 출력 버퍼, 파서 테이블, 프로덕션 룰 테이블, 및 시맨틱 코드 테이블과 같은 다른 메모리 섹션을 위해 외부 메모리와 공유될 수 있다.

A-bus 인터페이스와 AMCD(164)는 유사하게 동작하지만, 어레이 머신 콘텍스트 구조를 가진다. 바람직하게는, 다른 종류의 어레이와 테이블이 할당될 수 있고, 크기가 재편될 수 있으며, 할당이 취소될 수 있고, 써질 수도 있고, 읽혀질 수도 있으며, 검색 및 가능하게는 해쉬될 수도 있고 단순한 버스 요청을 사용하는 소팅이될 수도 있다. 실제의 근본적인 물리적 메모리는 예를 들면 빠른 온-보드 RAM, 외부 RAM 혹은 ROM, 컨텐트-어드레서블 메모리 등을 포함하여 다른 종류의 어레이와 테이블과는 다르다.

도 3에서 보인 저장 서버 구조는 본 발명의 실시예에 따른 많은 가능한 기능적 서버의 배분 중의 하나이다. 다른 가능한 구성이 도 7 내지 도 10에 나와있고 아래에서 설명될 것이다.

도 7은 하나 이상의 전통적인 SATA 드라이브에 대한 인터페이스를 가진 저장 서버(500)를 나타낸다. (표준 전기 혹은 광 컨넥터 포트 혹은 안테나 같은) 네트워 크 연결(502)은 클라이언트로 하여금 파이버 채널(Fibre Channel) 이더넷 등과 같은 원하는 프로토콜을 지원하는 PHY 510과 통신하도록 허용한다. 이더넷을 위해서는, Broadcom BCM5421 혹은 Marvell 88E1011과 같이 상업적으로 이용 가능한 PHY가 사용될 수 있다.

PHY (510)는 RSP(520)로 입력 프레임을 공급하고 RSP(520)로부터 출력 프레임을 구동한다. RSP(520)는 위에서 설명된 구성 중의 하나로, 계류 중인 출원 10/351,030, 혹은 다른 기능적으로 유사한 시맨틱 프로세싱 구성으로 구성될 수 있다.

RAM(530)은 예를 들어 머신 콘텍스트와 버퍼를 위해 RSP(520)로 물리적 저장을 제공한다. RAM(530)은 여러가지 종류의 메모리(DRAM, 플래쉬, CAM 등) 혹은 싱크로너스 DRAM과 같은 단일 타입으로 구성될 수 있다. 부트 ROM 혹은 부트 플래쉬 메모리는 파서, 프로덕션 룰 및 시맨틱 코드 테이블이 동작 중에 휘발성 메모리에 저장된 때에 RSP(520)를 초기화하는데 사용될 수 있다. 비 휘발성 테이블 저장의 일부는 RSP(520)가 데이타 저장 장치와 통신할 수 있도록 허용하도록 부트 메모리 내에 충분한 코드가 있는 한 데이타 저장 장치 상에 존재할 수 있다.

SATA 컨트롤러(540)는 RSP(520)의 디스크 액세스 요청을 다루기 위해 RSP(520)의 블럭 I/O 포트로 연결된다. SATA 컨트롤러(540)는 예를 들면 SII 3114 혹은 Marvell 88SX5080과 같이 상업적으로 사용 가능한 SATA 컨트롤러일 수 있다.

시리얼 ATA 컨트롤러(540)는 SATA 버스를 거쳐 하나 이상의 SATA 데이타 저장 장치로 연결된다. 보인 바와 같이, 저장 서버(500)는 SATA 버스 BUS0에서 BUSN 을 통해 드라이브 550-0에서 550-N을 지원한다.

PHY 510, RSP 520, RAM 530 및 SATA 컨트롤러 540는 바람직하게는 공통의 PCB(도시되지 않음) 상에서 상호연결된다. 회로 보드(circuit board)는 SATA 케이블링이 BUS0에서 BUSN까지 제공하는 것과 함께 공동의 인클로져(enclosure) 내의 드라이브들로 정렬될 수 있다. 선택적으로, SATA 버스 시그널링은 PCB 상에서 각각의 드라이브를 위한 커넥터로 혹은 뒷판으로의 커넥터를 통해 라우팅될 수 있다.

다른 저장 서버 구현(600)이 도 8에 나타나 있다. 바람직하게는, 이 구현에서 전체 서버는 저장 서버 클라이언트에 연결을 제공하기 위해 네트워크 연결(602)과 함께 디스크 드라이브의 PCB 상에 구현된다. 비록 저장 서버 구조(500)는 혹 동일한 방법으로 패키지화될 수도 있지만, 저장 서버(600)는 RSP(620) 내에 PHY(610) 및 SATA 컨트롤러(640)를 집적함으로써 공간 및 비용 절약을 이루었다. SATA 컨트롤러(640)는 바람직하게는 SEE를 사용하여 최소한 부분적으로 구현된다.

RSP(620)의 SATA 컨트롤러 섹션은 SATA 케이블 혹은 회로 보드 버스를 통해 드라이브 일렉트로닉스(66)로 인터페이스하는데, 드라이브 일렉트로닉스는 SATA 인터페이스, 디스크 캐쉬 및 드라이브 컨트롤 일렉트로닉스를 포함한다.

도 9의 저장 서버(700)에서 보는 바와 같이, 미디어 장치 내에 공동 회로 보드 상에 구현된 전체 저장 서버와 함께, SATA 인터페이스 전체를 제거하는 것이 가능하다. 도 9에서는 RSP(740) 내에 디스크 컨트롤러 기능이 구현되었다. (Marvell 88C7500 과 같은) 컨트롤 장치, 블럭 770으로 도시된 모터, 서보는 RSP(740)와 직접 인터페이스 한다.

도 10은 본질적으로 "변환" 게이트웨이인 저장 서버(800)를 보여준다. 저장 서버(800)는 네트워크 802에, 궁극적으로는 저장 서버 클라이언트에 연결하기 위한 제 1 네트워크 물리적 인터페이스 PHY1(블럭 810)로 구성된다. 저장 서버 인터페이스(800)는 또한 네트워크 혹은 P2P 연결을 거쳐 예시된 SAN 서버(850)와 같은 하나 이상의 물리적 서버로 연결하기 위한 제 2 네트워크 물리적 인터페이스 PHY2(블럭 840)를 포함한다. 부가된 메모리(830)와 함께 RSP(820)는 PHY1 과 PHY2에 부가된다. PHY1은 예를 들면 이더넷 PHY가 될 수 있고, PHY2는 예를 들면 파이버 채널(Fibre Channel) PHY가 될 수 있다.

동작 중에는, RSP(820)는 원격으로 부가된 서버(850) 상에서 요청을 개시함으로써 NAS-스타일 혹은 애플리케이션 스타일 요청과 같은 클라이언트 요청에 응답한다. 그리하여 서버(800)는 네트워크(802) 상에서 클라이언트에 서버로서 나타나고, 서버(850) 상에 클라이언트로서 나타난다. 비록 서버(850)는 SAN 서버로 예시되었지만, 서버(850)는 NAS 혹은 애플리케이션 스타일 서버일 수 있다. 만일 PHY1 및 PHY2가 동일한 서버 프로토콜을 지원하면, 저장 서버(800)는 스칼라화될 수 있는 서버 팜(farm), 암호화 포인트 및/또는 방화벽을 위한 통합 포인트로서 유용한 기능을 제공할 수 있다.

양 PHY1 및 PHY2가 RSP(820)에 데이타그램을 제공할 때, RSP(820)는 양 입력 스트림을 위한 파싱을 제공할 수 있다. 예를 들면, PHY1과 PHY2 양 입력 스트림이 공동 입력 버퍼에 저장될 수 있고, RSP(82) 내에 DXP(도시되지 않음)가 양 입력 스트림에서 데이타그램을 파스하고 양방향 변환 작업을 조화시킬 수 있을 것이다. RSP(820)는 두개의 DXP로 구성될 수 있는데, 하나는 각각의 물리적 포트를 다루고, SEE 및 다른 RSP 리소스의 공통 뱅크를 공유한다.

앞선 실시예는 도 11 및 도 12에서 볼 수 있는 바와 같은 다중 물리적 데이타 저장 장치로의 액세스를 제공하는 다른 시스템 구조에도 적용될 수 있다. 도 11에서, 저장 서버(900)는 RSP(100)를 예를 들면 보는 바와 같이 4개의 장치 120-1, 120-2, 120-3, 120-4와 같은 복수의 물리적 데이타 저장 장치로 연결하는 저장 인터페이스를 포함한다. 이러한 데이타 저장 장치는 RAID(Redundant Array of Independent Disks) 컨트롤러로서 동작하는 RSP, 혹은 저장 인터페이스(110)의 일부로서 구현된 분리된 RAID 컨트롤러(도시되지 않음)를 갖는 RAID 어레이로서, 몇몇 실시예에서 액세스될 수 있다. 4개의 데이타 저장 장치는 선택적으로 JBOD(Just a Bunch Of Disks) 어레이로서 구성될 수 있다.

일반적으로, RSP(100)는 클라이언트를 위해 저장 서버 가상화(virtualization)의 다른 형태를 수행할 수 있다. 다른 대안적 형태에서는, 클라이언트 애플리케이션에 의해 사용된 디스크 섹터 어드레스는 RSP에 의해 수많은 물리적 장치로부터 특정 장치의 C-H-S(Cylinder-Head-Sector) 어드레스로 맵핑된다. 그러한 구성에서, 데이타 저장 장치 120-1 내지 120-4(그리고 잠재적으로 많은 이러한 장치들)는 클라이언트를 위해 물리적 리소스의 정교한 컨트롤 및 디스클 할당을 허용하는, 지리적 상호 지정은 필요없다. RSP는 분리된 매개 장치가 클라이언트를 위해 가상화 기능의 전체 혹은 일부를 제공하게 되는 경우 가상화 구성 내에서 기능할 수도 있다.

도 12는 포트 확장자(950)를 포함하는 저장 서버 시스템(1000)에서 RSP(100)의 사용을 나타낸다. 포트 확장자(950)는 (내부 혹은 외부) RSP(100)와 관련된 단일 SATA 컨트롤러 포트로 연결되지만, (예를 들어 도시된 장치 120-1 내지 120-4와 같은) 다중 물리적 데이타 저장 장치와 통신한다. 이러한 구성은 데이타 저장 장치와 통신을 위해 RSP 상에서 오직 하나의 포트를 사용할 때 전체 시스템 대역폭을 증가시킬 수 있다.

도 13은 본 발명의 실시예에서 유용한 다른 시맨틱 프로세서 구현(1100)을 보여준다. 시맨틱 프로세서(1100)는 포트 0 PHY 93, 포트 1 PHY 94 및 PCI-X 인터페이스 95와 통신하는데, 각각은 원한다면 프로세서(1100)에 집적되든지 혹은 프로세서(1100)에 외부적으로 연결될 수 있다. 도 3의 버퍼(130)는 PIB(Port Input Buffer, 132) 및 POB(Port Output Buffer, 134)로 대체되는데, PIB와 POB는 반드시 필요한 것은 아니지만 바람직하게는, 프로세서(1100)의 일부로 통합된 공통 메모리 섹션에 있다. PIB(132)는 각각의 포트 0, 포트 1 및 PCI-X 인터페이스를 위한 적어도 하나의 입력 큐(queue)에 연결되고 그러한 입력 큐를 유지하며, 다른 큐 역시 포함할 것이다. POB(134)는 각각의 포트 0, 포트 1 및 PCI-X 인터페이스를 위한 적어도 하나의 출력 큐에 연결되고 그러한 출력 큐를 유지하며, 다른 큐 역시 포함할 것이다. 포트 0 및 포트 1은 전형적으로는 기가비트 이더넷과 같은 데이타그램 인터페이스를 나타내고, 반면에 PCI-X 인터페이스는 친숙한 PXI-X 버스에 연결된다. 저장 서버 설계에 따라, 저장 리소스는 이러한 포트들 중 어느 하나에 연결될 수 있고, 클라이언트는 포트 1, 포트 2 혹은 두 포트 모두에 연결될 수 있다.

도 3과는 다르게, 도 13에서 직접 실행 파서(140)는 파서 소스 선택기(136)를 통해 PIB(132)에 있는 복수의 입력 큐 각각으로부터 입력을 수신할 수 있다. 예를 들면, 직접 실행 파서(140)는 각각의 입력 소스를 위한 독립된 파서 스택을 유지할 수 있고, 패킷이 파싱을 끝내는 때마다 혹은 예를 들면 SEE가 패킷 필드 상에서 어떤 계산을 수행하는 때 같이 하나의 패킷 파싱이 스톨(stall)되는 때에 입력 소스를 스위치하기 위해 파서 소스 선택기에 신호를 줄 수 있다. SEE 클러스터(152)는 N 개의 시맨틱 코드 실행 엔진 150-1 ~ 150-N 으로 구성된다. SEE 클러스터는 바람직하게는 Sx-Bus를 통해 DXP(140)와 통신하고 개별 SEE로 작업을 분배하기 위한 단일 발송기(도시되지 않음)를 포함한다.

PIB 읽기 컨트롤러(133) 및 POB 쓰기 컨트롤러 블럭(135)은 SEE 클러스터(152)를 위해 각각 PIB(132) 및 POB(134)로 액세스를 제공한다. 보는 바와 같이, 파서 소스 선택기(136) 및 PIB 읽기 컨트롤러(133)는 SEE 클러스터가 다른 입력으로부터 데이타를 액세스하는 동안 DXP(140)로 하여금 한 입력으로부터의 데이타와 작업하도록 허락한다. PIB 읽기 컨트롤러(133)와 POB 쓰기 컨트롤러(135)는 우선적으로는 입력과 출력 버퍼로 논-블럭킹 액세스를 허락한다.

머신 콘텍스트 포트 컨트롤러(154)는 SEE 클러스터(152)를 위한 머신 콘텍스트(160)로의 액세스를 제공한다. 포트 버퍼 컨트롤러와 같이, 머신 콘텍스트 포트 컨트롤러(154)는 SEE 클러스터(152)를 위해 머신 콘텍스트(160)로 논-블럭킹 액세스를 제공한다.

머신 콘텍스트(160)는 SEE 클러스터(152)와 관리 마이크로프로세서(195)를 위한 메모리 작업에 우선 순위를 매기고 그 작업들을 실행하며, 전형적으로는 타겟 데이타 액세스의 속성에 각각 의존하는 하나 이상의 특화된 캐쉬를 포함한다. 머신 콘텍스트(160)는 인라인 암호화/인증을 수행하는데 사용될 수 있는 하나 이상의 암호화 및/또는 인증 엔진을 포함할 수 있다. 하나 이상의 전통적인 메모리 버스 인터페이스는 머신 콘텍스트(160)와 물리적 메모리(165)를 연결하는데, 물리적 메모리는 예를 들면 DRAM(Dynamic Random Access Memory), CAM(Content Addressable Memory) 및/또는 다른 어떤 종류의 원하는 저장 장치로 구성될 수 있다. 물리적 메모리(165)는 프로세서(1100) 상에, 프로세서(1100) 외부에, 혹은 이 두 위치 가운데 분리되어 위치할 수 있다.

관리 마이크로프로세서(195)는 시맨틱 프로세서(1100)를 위한, 합리적으로 전통적 소프트웨어로 성취될 수 있는 원하는 기능을 수행한다. 예를 들면, 마이크로프로세서(195)는 머신 콘텍스트(160)를 통해 물리적 메모리(165) 상의 자신의 명령 공간과 데이타 공간과 인터페이스 할 수 있고, 프로세서를 부팅하기 위한 전통적인 소프트웨어를 실행할 수 있으며, 파서 테이블, 프로덕션 룰 테이블, 시맨틱 코드 테이블을 로드하거나 수정할 수 있고, 통계를 모으고, 로그인을 수행하며, 클라이언트 액세스를 관리하고 에러 복구 등을 수행한다. 바람직하게는, 마이크로프로세서(195)는 SEE가 마이크로프로세서 대신에 작업을 수행할 것을 요구하기 위해 SEE 클러스터(152)에서 발송기와 통신할 수 있다. 관리 마이크로프로세서는 바람직하게는 시맨틱 프로세서(1100)상에 통합되어 있다.

앞선 실시예 내에서, 시맨틱 유닛은 블럭들이 디스크에 써질 때에 데이타의 블럭을 암호화할 수 있고 및/또는 블럭이 디스크로부터 읽혀지는 때에 데이타의 블럭을 복호화할 수 있다. 이는 디스크 드라이브나 드라이브 상에 휴지 중인 데이타에 보안을 제공한다. 예를 들면, 시맨틱 유닛이 디스크에 쓰기 위해 데이타 패이로드를 수신할 때, 쓰기를 위한 데이타 패이로드를 준비하는데 있어 하나의 동작은 패킷을 암호화하는 것을 포함할 수 있다. 이 프로세스의 역(逆)은 디스크로부터 암호화된 데이타를 읽기 위해 사용될 수 있다.

비록 특정 목적 실행 엔진이 도시되고 설명되었지만 대안적인 구현이 일반 목적 프로세서를 위한 프론트-엔드(front-end) 데이타그램 프로세서로서 파서를 사용할 수 있다.

앞선 실시예에서 예시된 바와 같이, 많은 다른 시맨틱 프로세서 기반 저장 서버가 본 발명의 범위 안에 포함된다. 저기능 엔드(low-functionality end)에서, 예를 들어 파이버 채널에 의해 기업 네트워크에 연결된 SAN-스타일 서버가 가능하다. NAS 스타일 서버는 위에서 설명한 CIFS 실시예에서 상술된 바와 같은 좀더 정교한 특징을 포함한다. 변환-게이트웨이 서버는 물리적 서버에 클라이언트 가시성(可視性)을 허용하지 않으면서 클라이언트에게 잠재적으로 크고 변화하는 근본적인 물리적 서버의 어레이로의 접근성을 제공한다.

변환-게이트웨이 서버 및 물리적 서버 양자는 애플리케이션 스타일 서버로서 만들어질 수 있다. 애플리케이션 스타일 서버로서, 데이타는 애플리케이션 스타일 포맷으로 취급된다. 예를 들면, 비디오상 요구(video-on-demand) 서버는 다중 클라이언트에 의한 사용을 위해 비디오를 저장할 수 있고, 비디오의 다른 파트를 다른 클라이언트에게 흘려보낼 수 있는데 각각이 독립적인 통로를 가지도록 허락한다. 뮤직-요구(music-on-demand) 서버는 동일하게 동작할 수 있다. 애플리케이션 스타일 서버는 또한 카메라가, 상대적으로 작은 내부 버퍼 및/또는 플래쉬 카드로 동작하도록 허용하기 위해 디지털 카메라로부터 디지털 카메라 사진을 저장하는 유무선 서버와 같이, 애플리케이션을 위해 저장 공간을 제공할 수 있다. 이러한 서버는 상대적으로 작고, 배터리로 동작하며, 필드 사용을 위해 휴대용일 수 있다.

시맨틱 프로세서 저장 서버 구현은 예를 들면 홈 컴퓨터 데이타 및/또는 오디오/비디오 네트워크에서의 사용을 위해서와 같이, 무선 프로토콜을 실행할 수 있다. 비록 상세한 실시예는 전통적인 저장 장치, 프린터, 스캐너, 멀티 기능 프린터에 관심이 집중되어 왔지만, 다른 데이타 변환 장치는 역시 시맨틱 프로세서 저장 서버에 부가될 수 있다.

당업자는 여기에서 다루어진 개념들이 많은 다른 유용한 방법으로 사용될 수 있다는 것을 인식할 것이다. 시맨틱 프로세서 저장 서버가 서버에 의해 파스될 수 있는 변하는 프로토콜에 의해 다른 클라이언트 타입에 사용될 수 있도록 만들어 질 수 있다는 것은 아주 명백하다. 만일 원한다면, 저장 서버는 (예를 들면 신뢰받는 클라이언트에 의해서는 SAN 액세스 및 다른 이들에 의해서는 NAS 액세스와 같이) 다른 클라이언트 부류에 의한 액세스를 허용하기 위해 멀티 저장 서버 프로토콜을 파스할 수 있다.

도 14는 본 발명의 실시예에 따른 시맨틱 프로세서(2100)의 블럭도를 나타낸다. 시맨틱 프로세서(2100)는 입력 포트(2110)를 통해 수신된 데이타 스트림(예를 들면 입력 "스트림"), 입력 버퍼(2300)에서 패킷의 프로세싱을 제어하는 직접 실행 파서(DXP, 2400), 패킷의 세그먼트 프로세싱 혹은 다른 동작을 수행하기 위한 시맨틱 프로세싱 유닛 및 패킷 세크먼트를 저장하고 증대시키기 위한 메모리 서브시스템(2130)을 버퍼링하기 위한 입력 버퍼(2300)를 포함한다.

DXP(2400)는 현재 입력 프레임의 파싱 혹은 현재 입력 심볼까지의 패킷에 기초한 논-터미널 (그리고 가능하게는 터미널) 심볼의 내부 파서 스택(2430)을 유지한다. 파서 스택(2430)의 탑(top)에서 심볼이 터미널 심볼일 때, DXP(2400)는 입력 스트림의 헤드에서 데이타 DI를 터미널 심볼에 대조하고 계속하기 위해 매치를 기대하게 된다. 파서 스택(2430)의 탑(top)에서 심볼이 논-터미널(NT) 심볼일 때, 스택 상에서 문법 프로덕션을 확장하기 위해 DXP(400)는 논-터미널 심볼 NT와 현재 입력 데이타 DI를 사용한다. 파싱이 계속되면서, DXP(2400)는 SPU(2140)에게 입력 세그먼트를 프로세스하거나 혹은 다른 동작을 수행하도록 명령한다.

시맨틱 프로세서(2100)는 최소한 세 개의 테이블을 사용한다. SPU(2140)를 위한 코드 세그먼트는 시맨틱 코드 테이블(2150)에 저장된다. 복잡한 문법 프로덕션 룰은 프로덕션 룰 테이블(PRT, 2250)에 저장된다. 이러한 프로덕션 룰을 꺼내기 위한 프로덕션 룰(PR) 코드는 파서 테이블(PT, 2200)에 저장된다. 파서 테이블 내의 PR 코드는 DXP(2400)가 주어진 프로덕션 룰에 대해 SPU(2140)에 의해 시맨틱 코드 테이블(2150)로부터 코드 세그먼트가 로드되고 실행되어야 하는지를 검출한다.

파서 테이블(2200) 내의 프로덕션 룰(PR) 코드는 프로덕션 룰 테이블(2250)에서 프로덕션 룰을 가리킨다. PR 코드는 예를 들어 열-행 포맷 혹은 컨텐트-어드 레서블 포맷으로 저장된다. 열-행 포맷에서는, 테이블의 열은 내부 파서 스택(2430)의 탑(top) 상에 논-터미널 심볼 NT에 의해 인덱스되고, 테이블의 행은 입력의 헤드에서 입력 데이타 값(혹은 값들) DI에 의해 인덱스된다. 컨텐트-어드레서블 포맷에서는, 논-터미널 값 NT와 입력 데이타 값(혹은 값들) DI의 연결이 테이블에 입력을 제공한다. 바람직하게는, 시맨틱 프로세서(2100)는 DXP(2400)가 파서 테이블에 입력을 제공하기 위해 논-터미널 심볼 NT를 현재 입력 데이타 DI의 8 바이트로 연결하는 경우에, 컨텐트-어드레서블 포맷을 실행한다. 선택적으로, 파서 테이블(2200)은 논-터미널 심볼 NT와 DXP(2400)으로부터 받은 8 바이트 현재의 입력 데이타 DI를 연결한다.

본 발명의 몇몇 실시예에서 도 14에서 보인 것보다 더 많은 구성 요소를 포함한다. 하지만, 본 발명의 동작을 이행하기 위한 목적 상, 그러한 구성 요소는 지엽적인 것이고 본 개시에서는 생략된다.

본 발명의 몇몇 실시예를 위한 일반 파서 동작은 우선 도 14, 15a, 15b, 16 및 17을 참조하여 설명될 것이다. 도 15a는 파서 테이블(2200)에 대해 개연성있는 일실시예를 보여준다. 파서 테이블(2200)은 프로덕션 룰 코드 메모리(2220)로 구성되어 있다. PR 코드 메모리(2220)는 프로덕션 룰 테이블(PRT, 2250)에 저장된 대응되는 프로덕션 룰을 액세스하는데 사용되는 다수의 PR 코드를 포함한다. 실제적으로는, 많은 다른 문법을 위한 코드가 프로덕션 룰 메모리(2220) 내에 동시에 존재할 수 있다. 특정 검색 실행에 의해 요구되지 않는 이상, 입력 값(예를 들어 n이 바이트 상의 선택된 매치 길이인 경우 현재의 입력 값 DI[n]와 연결된 논-터미 널(NT) 심볼)은 PR 코드 메모리(2220)에서 어떤 특정한 순서로 지정될 필요는 없다.

다른 실시예에서는, 파서 테이블(2200)은 또한 DXP(2400)으로부터 NT 심볼과 데이타 값 DI[n]을 수신하는 어드레서(2210)를 포함한다. 어드레서(2210)은 NT 심볼을 데이타 값 DI[n]과 연결하고, 상기의 연결된 값을 PR 코드 메모리(2220)에 적용한다. 선택적으로, DXP(2400)는 NT 심볼과 데이타 값 DI[n]들을 파서 테이블로 전송하기 전에 이들을 연결한다.

비록 개념적으로는 NT 코드와 데이타 값의 각각의 고유한 조합에 대해 하나의 PR 코드를 갖는 매트릭스로서 프로덕션 룰 코드 메모리(2220)의 구조를 바라보는 것이 종종 유용하지만, 본 발명은 그런 식으로 제한되지는 않는다. 다른 종류의 메모리 및 메모리 구조가 다른 애플리케이션을 위해 적절할 수 있다.

예를 들면, 본 발명의 실시예에서, 파서 테이블(2200)은 어드레서(2210)가 CAM(Content Addressable Memory)이 PRT(2250)에서 프로덕션 룰과 대응되는 PR 코드를 검색하기 위한 키로서 NT 코드와 입력 데이타 값 DI[n]을 사용하는 경우 상기 CAM으로서 구현될 수 있다. 바람직하게는, CAM은 TCAM 엔트리(entry)와 함께 있는 3위(Ternary) CAM이다. 각각의 TCAM 엔트리는 NT 코드와 DI[n] 매치 값으로 구성된다. 각각의 NT 코드는 다중 TCAM 엔트리를 가질 수 있다. DI[n] 매치 값의 각각의 비트는 "0", "1" 혹은 "X"("Don't care"를 나타냄)로 설정될 수 있다. 이러한 것은 PR 코드가 파서 테이블(2200)이 매치를 찾기 위해 오직 DI[n]의 어떤 비트/바이트 만이 코딩된 패턴에 매치할 것을 요구하도록 허용한다. 예를 들면, TCAM의 한 열은 IP 목적지 어드레스 필드를 위한 NT 코드 NT_IP를 포함할 수 있고, 뒤이어 시맨틱 프로세서를 포함하는 장치에 대응되는 IP 목적지 어드레스를 나타내는 4 바이트가 따라온다. TCAM 열의 나머지 4 바이트는 "don't care"로 설정된다. 그리하여 DI[8]의 처음 4 바이트가 올바른 IP 어드레스를 포함하는 경우, NT_IP와 DI[8]이 파서 테이블에 제시되고 DI[8]의 마지막 4 바이트가 무엇을 담고 있는지에 상관없이 매치가 일어나게 된다.

TCAM 이 "Don't care" 성능을 채용하고 단일 NT를 위해 다중 TCAM이 있을 수 있기 때문에, TCAM은 주어진 NT 코드와 DI[n] 매치 값에 대해 복수의 매칭 TCAM을 발견할 수 있다. TCAM은 자신의 하드웨어를 통해 이 매치에 우선순위를 매기고, 최 우선순위 매치 만을 출력으로 내보낸다. 더욱이, NT 코드 및 DI[n] 매치 값이 TCAM에 제출되는 때에, TCAM은 수신된 NT 코드와 DI[n] 매치 코드와 모든 TCAM 엔트리를 병렬적으로 매치하려고 시도한다. 그리하여, TCAM은 시맨틱 프로세서(2100)의 단일 클럭 싸이클에 파서 테이블(2200)에서 매치가 발견되었는지를 판단하는 능력을 가진다.

이러한 구조를 바라보는 다른 방법은 "변수 예측(variable look-ahead)" 파서로써이다. 비록 8 바이트 같은 고정된 데이타 입력 세그먼트가 TCAM에 인가되지만, TCAM 코딩은 다음 프로덕션 룰이 입력의 현재 8 바이트의 어떤 부분에라도 근거를 둘 수 있도록 허용한다. 만일 입력 스트림의 헤드에서 현재 8 바이트 내의 어떤 곳에 있는 오직 한 비트 혹은 바이트가 현재 룰에 대해 이해관계를 갖는다면, TCAM 엔트리는 나머지가 매치되는 동안 무시되도록 코드될 수 있다. 본질적으로, 현재의 "심볼"은 입력 스트림의 헤드에서 64 비트의 조합으로서 주어진 프로덕션 룰에 대해 정의될 수 있다. 영리한 코딩을 한다면, 주어진 파싱 작업에서 파싱 싸이클 수, NT 코드 및 테이블 엔트리가 일반적으로 줄어들 수 있을 것이다.

파서 테이블(2200)에서 TCAM은 앞에서 설명한 바와 같이 NT 및 DI[n]에 매칭되는 TCAM 엔트리(2230)에 대응되는 PR 코드를 생산하다. PR 코드는 DXP(2400)에, 직접 PR에 혹은 양쪽 모두에 다시 보내질 수 있다. 한 실시예에서는, PR 코드는 매치를 생성하는 TCAM 엔트리의 열 인덱스이다.

어떤 TCAM 엔트리(2230)도 NT 및 DI[n]와 매치하지 않을 때, 몇 가지 옵션이 있다. 한 실시예에서는, PR 코드가 "유효" 비트에 의해 동반되게 되는데, 이 유효 비트는 만일 어떤 TCAM 엔트리도 현재 입력과 매치되지 않는다면 세트되지 않는 상태로 남아 있게 된다. 다른 실시예에서, 파서 테이블(2200)은 파서 테이블에 제공되는 NT에 대응되는 디폴트 PR 코드를 만든다. 유효 비트 혹은 디폴트 PR 코드의 사용은 도 15b와 연계되어 설명될 것이다.

DXP(2400)와 SPU(2140)가 한 회로에 집적되는 때에, 파서 테이블에 칩 상에 올려 질 수도 있고 그렇지 않을 수도 있으며 양쪽 모두도 가능하다. 예를 들면, 온-칩에 위치한 스태틱(static) RAM(SRAM) 혹은 TCAM은 파서 테이블(2200)으로 작용할 수 있다. 선택적으로, 오프-칩 DRAM 혹은 TCAM 메모리는 오프-칩 메모리를 위한 메모리 컨트롤러로 작용하는 혹은 이러한 메모리 컨트롤러와 통신하는 어드레서(2210)를 가지면서, 파서 테이블(2200)을 저장할 수 있다. 다른 실시예에서는, 파서 테이블(2200)은 파서 테이블(2200)의 섹션을 가질 수 있는 온-칩 캐쉬를 가지 면서, 오프-칩 메모리 상에 있을 수 있다.

도 15b는 프로덕션 룰 테이블(2250)에 대한 가능성 있는 구현예를 나타낸다. PR 테이블(2250)은 프로덕션 룰 메모리(2270), MAPT(Match All Parser entries Table) 메모리(2280) 및 어드레서(2260)로 구성된다.

한 실시예에서, 어드레서(2260)는 DXP(2400) 혹은 파서 테이블(2200) 중 하나로부터 PR 코드를 수신하고, DXP(2400)으로부터 NT 심볼을 수신하게 된다. 바람직하게는, 수신된 NT 심볼은 파서 테이블(2200)에 보내진 NT 심볼과 동일한 것인데, NT 심볼은 수신된 PR 코드 위치를 정하는데 사용된다. 어드레서(2260)는 대응대는 프로덕션 룰과 디폴트 프로덕션 룰 각각을 액세스하기 위해 이러한 수신된 PR 코드와 NT 심볼을 사용한다. 본 발명의 바람직한 실시예에서, 수신된 PR 코드는 프로덕션 룰 메모리(2270)에서 프로덕션 룰의 어드레스를 지정하고, 수신된 NT 코드는 MAPT(2280)에서 디폴트 프로덕션 룰의 어드레스를 지정한다. 어드레서(2260)는 몇몇 구현에서는 필요하지 않을 수 있으나, 사용되는 때에는, DXP(2400)의 일부, PRT(2250)의 일부 혹은 중간 기능 블럭이 될 수 있다. 예를 들어 만일 파서 테이블(2200) 혹은 DXP(2400)가 어드레스를 직접 만든다면 어드레서는 필요하지 않을 수 있다.

프로덕션 룰 메모리(2270)는 3개의 데이타 세그먼트를 포함하는 프로덕션 룰(2262)을 저장한다. 이 데이타 세그먼트는 심볼 세그먼트, SPU 엔트리 포인트(SEP), 그리고 스킵 바이트 세그먼트(skip byte segment)를 포함한다. 이러한 세그먼트들은 고정 길이 세그먼트 이거나 혹은 널(null)로 끝나는 가변 길이 세그먼 트들이다. 심볼 세그먼트는 (도 17의) DXP 파서 스택(2430) 상에 푸쉬되는 터미널 및/또는 논-터미널 심볼을 포함한다. SEP 세그먼트는 데이타의 세그먼트를 프로세싱하는데 있어 SPU(2140)에 의해 사용되는 SPU 엔트리 포인트(SEP)를 포함한다. 스킵 바이트 세그먼트는 자신의 버퍼 포인터를 증가시키고 입력 스트림의 프로세싱을 촉진하는 입력 버퍼(300)에 의해 사용되는 스킵 바이트 데이타를 포함한다. 프로세싱 프로덕션 룰에 사용되는 다른 정보는 프로덕션 룰(2262)의 일부로서 또한 저장될 수 있다.

MAPT(2280)는 디폴트 프로덕션 룰(2264)을 저장하는데, 이 실시예에서 이 디폴트 프로덕션 룰은 프로덕션 룰 메모리(2270)와 동일한 구조를 가지고, PR 코드가 파서 테이블 검색 동안 지정되지 못하는 때에 액세스된다.

비록 프로덕션 룰 메모리(2270)와 MAPT(2280)가 두 개의 독립된 메모리 블럭으로 나타나 있지만, 본 발명은 그에 제한되는 것은 아니다. 본 발명의 바람직한 실시예에서, 각각의 프로덕션 룰과 디폴트 프로덕션 룰이 복수의 널-종료 세그먼트를 가지고 있는 때에 프로덕션 룰 메모리(2270)와 MAPT(2280)는 온-칩 SRAM 으로서 구현된다.

프로덕션 룰과 디폴트 프로덕션 룰이 다양한 길이를 가지므로, 그들의 각각의 메모리 2270 및 2280으로 단순한 인덱싱을 허용하는 접근법이 바람직하다. 한 접근법에서는, 각각의 PR은 고정된 최대 수의 심볼, SEP 및 스킵 바이트 필드같은 보조 데이타를 수용할 수 있다. 주어진 PR이 최대 수의 심볼 혹은 허용된 SEP을 필요로 하지 않는 때에는, 시퀀스는 널(NULL) 심볼 혹은 SEP으로 종료될 수 있다. 주 어진 PR이 최대 수보다 더 많은 수를 요구하는 때에는, 첫번째는 제로의 스킵 바이트 값을 내고, 두번째가 다음 파싱 싸이클에서 액세스되도록 스택에 NT를 푸쉬하도록 함으로써 두 개의 PR로 나누어질 수 있다. 이러한 접근법에서, TCAM 엔트리 및 PR 테이블 엔트리 간의 일대일 대응이 유지될 수 있는데, TCAM에서 얻어진 열 어드레스는 역시 PR 테이블(250)에서 대응되는 프로덕션 룰의 열 어드레스이다.

PRT(2250)의 MAPT(2280) 섹션은 유사하게 인덱스될 수 있으나, PR 코드 대신 NT 코드를 사용한다. 예를 들어, PR 코드 상의 유효 비트(valid bit)가 세트되지 않으면, 어드레서(2260)는 PR 테이블 어드레스로서 현재 NT 에 대응되는 열을 선택할 수 있다. 예를 들면, 만일 2256 NT가 허용되면, MAPT(2280)는 각각이 NT의 하나로 인덱스된 2256 엔트리를 포함할 수 있을 것이다. 파서 테이블(2200)이 현재 NT와 데이타 입력 DI[n] 에 대응되는 엔트리를 가지지 않는 때에, MAPT(2280)로부터 대응되는 디폴트 프로덕션 룰이 액세스된다.

IP 목적지 어드레스를 예로 들면, 파서 테이블은 적절한 파싱 싸이클 동안 두 개의 예상되는 목적지 어드레스 중의 하나에 응답하도록 구성된다. 모든 다른 목적지 어드레스에 대해서는, 어떤 파서 테이블 엔트리도 찾을 수 없을 것이다. 어드레서(2260)는 현재 NT에 대한 디폴트 룰을 검색할 것인데, 이는 DXP(2400) 및/또는 SPU(2140)가 전혀 상관없는 패킷으로서 현재의 패킷을 털 수 있도록 지시한다.

비록 상기 프로덕션 룰 테이블 인덱싱 접근법은 상대적으로 단순하고 빠른 룰 액세스를 제공하지만, 다른 인덱싱 설계도 가능하다. 가변 길이 PR 테이블 엔트리에 대해서는, PR 코드는 프로덕션 룰의 물리적 메모리 시작 어드레스를 결정하기 위해 산술적으로 조정될 수 있다. (이는 예를 들어 만일 프로덕션 룰이 확장된 길이에 의해 분류되고 PR 코드가 룰의 분류된 위치에 따라 할당된다면 가능하다.) 다른 접근법에서는, 중간 포인터 테이블이 PR 코드로부터 PRT(2250) 내의 프로덕션 룰의 어드레스 혹은 NT 심볼로부터 MAPT(2280) 내의 디폴트 프로덕션 룰을 결정하는데 사용될 수 있다.

프로덕션 룰(2262 혹은 2264))로부터의 심볼, SEP 및 스킵 바이트 값의 사용은 추가적인 기능 유닛인 입력 버퍼(2300)가 좀더 상세히 설명된 이후에 아래에서 설명될 것이다.

도 16은 본 발명의 실시예에서 유용한 입력 버퍼(2300)에 대한 개연성 있는 구현을 나타낸다. 입력 버퍼(2300)는 입력 포트(2110)를 통해 데이타를 수신하는 버퍼(2310), 버퍼(2310)에서 데이타를 제어하기 위한 제어 블럭(2330), 전송 에러에 대해 수신된 데이타를 체크하기 위한 에러 체크(EC) 블럭(2320), DXP(2400) FIFO가 버퍼(2310) 내의 데이타에 액세스하게 허용하는 FIFO 블럭(2340) 및 SPU(2140)가 버퍼(2310) 내의 데이타에 대한 랜덤 액세스를 하도록 허용하는 랜덤 액세스(RA) 블럭(2350)으로 구성된다. 바람직하게는, EC 블럭(2320)은 수신된 데이타 프레임 혹은 패킷이 IPG(inter-packet gap) 위반 및 이더넷 헤더 에러에 대한 체킹에 의해 그리고 CRC(Cyclic redundancy Codes) 계산에 의해 에러를 가지고 있는지를 결정한다.

패킷, 프레임 혹은 다른 새로운 데이타 세그먼트가 입력 포트(2110)를 통해 버퍼(2310)에서 수신된 때에, 입력 버퍼(2300)는 포트 ID를 DXP(2400)로 전송하고 새로운 데이타가 도착했음을 DXP(2400)에게 경고한다. EC 블럭(2320)은 에러에 대한 새로운 데이타를 체크하고 스테이터스 신호에서 DXP(2400)에 보내진 스테이터스(status) 비트를 세트한다. DXP(2400)이 수신된 데이타 세그먼트의 헤더를 통해 파스하기로 결정하는 때에, DXP는 입력 버퍼(2300)에 버퍼(2310)로부터 일정 양의 데이타를 요청하거나 버퍼(2310)가 DXP(2400)에 데이타를 보내지 않으면서 버퍼의 데이타 헤드 포인터를 증가시키도록 요청하는 Control_DXP 신호를 보낸다. Control_DXP 신호를 받는 때에, 컨트롤 블럭(2330)은 (만일 요청되었다면) FIFO 블럭(2340)을 통해 버퍼(2310)로부터 DXP(2400)로의 데이타를 포함하는 Data_DXP 신호를 전송한다. 본 발명의 실시예에서, 컨트롤 블럭(330)과 FIFO 블럭(340)은 Data_DXP 신호에서 DXP(2400)에 보내진 때에 컨트롤 문자를 데이타 세그먼트로 추가한다. 바람직하게는, 컨트롤 문자는 전송된 데이타의 각각의 바이트의 시작에 추가되고 연이은 데이타 바이트가 터미널 혹은 논-터미널 심볼인지를 나타내는 1-비트 스테이터스 플래그를 포함한다. 컨트롤 문자는 특별 논-터미널 심볼, 예를 들어 start-of-stack, end-of-stack, port_ID 등을 또한 포함할 수 있다.

SPU(2140)가 SPU(2140)로 하여금 입력 버퍼 데이타 내의 데이타를 액세스하도록 요구하는 SPU 엔트리 포인트(SEP)를 DXP(2400)으로부터 수신하는 때에, SPU(2140)는 입력 버퍼(2300)에 버퍼(2310)에서의 특정 지점의 데이타를 요청하는 Control_SPU 신호를 전송한다. Control_SPU 신호를 수신하는 때에, 컨트롤 블럭(2330)은 SPU(2140)에 Sideband 신호를 전송하고 뒤이어 버퍼(2310)로부터의 데이타를 포함하는 Data_SPU 신호를 RA 블럭(2350)을 통해 SPU(2140)으로 전송한다. Sideband 신호는 바람직하게는, 보내지고 있는 데이타의 얼마나 많은 수의 바이트들이 유효한지와 데이타 스트림에 에러가 있는지를 나타낸다. 본 발명의 실시예에서, 컨트롤 블럭(2330)과 RA 블럭(2350)은 데이타 스트림이 SPU(2140)에 보내지는 때에 데이타 스트림에 컨트롤 문자를 부가한다. 바람직하게는, 컨트롤 문자는 필요하다면 패킷의 말단이나 데이타 스트림의 프레임에 계산된 CRC 값과 에러 플래그를 부가하는 것을 포함한다.

도 17은 DXP(2400)에 대해 가능한 블럭 구현예를 보여준다. 파서 컨트롤 유한 스테이트 머신(FSM, 2410)은 도 17에서 다른 논리 블럭에서의 입력에 근거하여 전체 DXP(2400) 동작을 제어하고 시퀀스한다. 파서 스택(2430)은 DXP(2400)에 의해 실행되는 심볼을 저장한다. 입력 스트림 시퀀스 컨트롤(2420)은 DXP(2400)에 의해 프로세스되도록 입력 버퍼(2300)로부터 입력 데이타 값을 불러낸다. SPU 인터페이스(2440)는 DXP(2400)을 대신하여 SPU(2140)에 작업을 발송한다. 이 블럭들의 특정 기능들은 아래에서 설명될 것이다.

도 14 내지 도 17에서의 블럭들의 기본 동작이 도 18의 데이타 스트림 파싱에 대한 흐름도를 참조하여 기술될 것이다. 흐름도(2500)는 본 발명의 방법 실시예에 대한 예시를 위해 사용된다.

블럭 2510에 따르면, 시맨틱 프로세서(2100)는 입력 포트(2110)를 통해 입력 버퍼(2300)에서 패킷이 수신되는 것을 기다린다.

다음 판단 블럭 2512는 블럭 2510에서 패킷이 수신되었는지를 판단한다. 만일 패킷이 아직 수신되지 않았다면, 프로세싱은 시맨틱 프로세서(2100)가 패킷이 수신되기를 기다리는 블럭 2510으로 넘겨진다. 만일 패킷이 입력 버퍼(2300)에서 수신되었다면, 다음 블럭 2520에 따라 입력 버퍼(2300)는 Port ID 신호를 DXP(2400)에 보내는데, 이 경우 Port ID 신호는 NT 심볼로서 파서 스택(2430) 상에 푸쉬된다. Port ID 신호는 DXP(2400)에게 패킷이 입력 버퍼(2300)에 도착하였음을 알려준다. 본 발명의 바람직한 실시예에서, Port ID 신호는 입력 스트림 시퀀스 컨트롤(2420)에 의해 수신되고 FSM(2410)으로 전송되는데, 이 신호는 파서 스택(2430) 상에 푸쉬된다. 바람직하게는, Port ID 에 앞서거나 병렬적으로 보내지는 1 비트 스테이터스 플래그는 Port ID를 NT 심볼로서 표시한다.

다음 블럭 2530에 따르면, DXP(2400)는 파서 스택(2430)의 탑(top) 상의 심볼이 bottom-of-stack 심볼이 아니고 DXP는 더 이상의 다른 입력을 기다리고 있지 않다고 결정한 후, 입력 버퍼(2300)로부터 입력 스트림 데이타의 N 바이트를 요청하고 수신한다. DXP(2400)는 입력 스트림 시퀀스 컨트롤(2420) 및 입력 버퍼(2300) 간에 연결된 DATA/CONTROL 신호를 통해 데이타를 요청하고 수신한다.

다음 판단 블럭 2532는 파서 스택(2430) 상의 심볼이 터미널(T) 혹은 NT 심볼 인지를 판단한다. 이 결정은 바람직하게는 FSM(2410)이 파서 스택(2430) 상의 심볼의 스테이터스 플래그를 읽음으로써 수행될 수 있다.

심볼이 터미널 심볼이라고 판단되면, 다음 블럭 2540에 의거해, DXP(2400)는 T 심볼과 수신된 N 바이트로부터 온 데이타의 다음 바이트 간의 매치를 체크한다. FSM(2410)은 입력 스트림 시퀀스 컨트롤(2420)에 의해 수신된 데이타의 다음 바이트를 파서 스택(2430) 상의 T 심볼에 대조함으로써 매치 체크를 한다. 체크가 완료 된 후, FSM(2410)은 파서 스택(2430)에서 바람직하게는 스택 포인터를 감소시킴으로써 T 심볼을 빼낸다.

다음 판단 블럭 2542는 T 심볼과 데이타의 다음 바이트 간에 매치가 있는지 여부를 판단한다. 매치가 있으면 실행은 다음 블럭 2530으로 넘어가는데, 이 곳에서 DXP(2400)는 파서 스택(2430) 상의 심볼이 bottom-of-stack이 아니라는 것과 더 이상의 입력을 기다리고 있지 않다는 것을 판단한 후, 입력 버퍼(2300)로부터 추가적인 입력 스트림 데이타를 요청하고 수신한다. 본 발명의 바람직한 실시예에서, DXP(2400)은 T 심볼 매치가 이루어진 후, 하나의 입력 심볼이 사용된 이후 DI 버퍼를 다시 채우기 위해 입력 스트림의 오직 한 바이트를 요청하고 수신할 것이다.

매치가 이루어지면, 현재 데이타 세그먼트의 나머지는 어떤 환경에서는 파스될 수 없다고 여겨진다. 다음 블럭 2550에 따르면, DXP(2400)는 파서 스택(2430)을 리셋하고 입력 버퍼(2300)으로부터 현재의 패킷 나머지를 제거하기 위해 SEP을 론칭(launch)한다. 본 발명의 실시예에서, FSM(2410)은 나머지 심볼을 빼내거나 혹은 바람직하게는 top-of-stack 포인터를 bottom-of-stack 심볼로 셋팅함으로써 파서 스택(2430)을 리셋한다. DXP(2400)는 SPU 인터페이스(2440)를 통해 SPU(2140)에 커맨드를 전송함으로써 SEP을 론칭한다. 이 커맨드는 SPU(2140)이 SCT(2150)로부터 마이크로 명령을 로드하도록 요구하는데, 이 명령이 실행되면 SPU(2140)로 하여금 입력 버퍼(2300)으로부터 파스할 수 없는 데이타 세그먼트의 나머지를 제거할 수 있게 한다. 그러고 나면 실행은 블럭 2510으로 넘겨진다.

데이타 스트림에서 파스 가능하지 않은 모든 경우에서 현재 데이타 세그먼트 의 파싱을 포기하는 결과를 낳는 것은 아니라는 것을 명심해야 한다. 예를 들면, 파서는 문법과 함께 보통의 헤더 옵션을 직접적으로 취급하도록 구성될 수 있다. 다른 덜 난해하고 일상적인 헤더 옵션은 파싱을 위해 헤더 옵션을 SPU롤 넘겨주는 디폴트 문법 룰을 사용하여 취급될 수 있다.

판단 블럭 2532에서 심볼이 NT 심볼이라고 판단되는 때에, 다음 블럭 2560에 따라, DXP(2400)는 파서 스택(2430)으로부터의 NT 심볼과 입력 스트림 시퀀스 컨트롤(2420)에서의 수신된 N 바이트 DI[n]를 파서 테이블(2200)로 전송하는데, 이 때 파서 테이블(2200)은 앞에서 설명된 바와 같이 매치를 체크한다. 예시된 실시예에서, 파서 테이블(2200)은 NT 심볼과 수신된 N 바이트를 연결한다. 선택적으로, NT 심볼과 수신된 N 바이트는 파서 테이블에 보내지기 전에 연결될 수 있다. 바람직하게는, 수신된 N 바이트는 SPU 인터페이스(2440)와 파서 테이블(2250) 양쪽에 동시에 전송되고, NT 심볼은 파서 테이블(2200)과 PRT(2250) 양쪽에 동시에 보내진다. 체크가 끝나고 난 후, FSM(2410)은 바람직하게는 스택 포인터를 감소시킴으로써 파서 스택(2430)에서 NT 심볼을 빼낸다.

다음 판단 블럭 2562 는 파서 테이블(2200)에서 N 바이트 데이타와 연결된 NT 심볼에 매치가 있는 지를 판단한다. 매치가 있다면, 다음 블럭(2570)에 따라, 파서 테이블(2200)은 PR 코드를 매치와 대응되는 PRT(2250)로 되돌려 보내는데, 이러한 경우 PR 코드는 PRT 2250 내의 프로덕션 룰에 어드레스를 지정한다. 선택적으로, PR 코드는 DXP(2400)를 통해 파서 테이블(2200)에서 PRT(2250)로 보내진다. 실행은 이제 블럭 2590에서 계속된다.

매치가 이루어지면, 다음 블럭 2580에 따라, DXP(2400)는 PRT(2250)에서 디폴트 프로덕션 룰을 검색하기 위해 수신된 NT 심볼을 사용한다. 바람직한 실시예에서, 디폴트 프로덕션 룰은 PRT(2250) 내의 MAPT(2280) 메모리에서 검색된다. 선택적으로, MAPT(2280) 메모리는 PRT(2250)가 아닌 메모리 블럭에 지정될 수 있다.

본 발명의 바람직한 실시예에서, PRT(2250)이 PR 코드를 수신하는 때에, PRT는 DXP(2400)에 발견된 프로덕션 룰 혹은 디폴트 프로덕션 룰 중 대응되는 PR 만을 되돌려 보낸다. 선택적으로, PR 및 디폴트 PR은 DXP(2400)이 어떤 것이 사용될 지의 결정과 함께 DXP(2400)로 되돌려 보내진다.

다음 블럭 2590에 따르면, DXP(2400)는 PRT(2250)로부터 수신된 룰을 프로세스한다. DXP(2400)에 의해 수신된 룰은 프로덕션 룰 혹은 디폴트 프로덕션 룰 중의 하나이다. 본 발명의 실시예에 따라, FSM(2410)은 룰을 세 개의 세그먼트로 나누는데, 심볼 세그먼트, SEP 세그먼트 및 스킵 바이트 세그먼트이다. 바람직하게는, 룰의 각각의 세그먼트는 쉽고 정밀한 분리를 가능하게 하도록 고정된 길이이거나 널(null)로 종료된다.

예시된 실시예에서, FSM(2410)은 프로덕션 룰의 심볼 세그먼트에 포함된 T 및/또는 NT 심볼을 파서 스택(2430)으로 푸쉬한다. FSM(2410)은 프로덕션 룰의 SEP 세그먼트에 포함된 SEP를 SPU 인터페이스(2410)로 보낸다. 각각의 SEP는 SCT(2150)에 지정된 마이크로 명령으로의 어드레스를 포함한다. SEP를 받은 때에, SPU 인터페이스(2440)는 SEP에 의해 가리켜지는 마이크로 명령을 펫치(fetch)하고 실행하도록 SPU(2140)를 배분한다. SPU 인터페이스(2440)는 또한 많은 경우에 SPU에 의해 완료되어야 하는 작업이 더 이상의 입력 데이타를 필요로 하지 않을 것임에 따라, 현재 DI[N] 값을 SPU(2140)로 보낸다. 선택적으로, SPU 인터페이스(2440)는 SPU(2140)에 의해 실행되어야 하는 마이크로 명령을 펫치하고 이들을 이들의 배분과 동시에 SPU(2140)으로 전송한다. FSM(2410)은 입력 스트림 시퀀스 컨트롤(2420)을 통해 프로덕션 룰의 스킵 바이트 세그먼트를 입력 버퍼(300)로 전송한다. 입력 버퍼(2300)는 자신의 버퍼 포인터를 증가시키기 위해 스킵 바이트 데이타를 사용하여 입력 스트림에서 위치를 가리키게 된다. 각각의 파싱 싸이클은 따라서 0에서 8 사이의 어떤 수의 입력 심볼도 사용할 수 있다.

DXP(2400)가 PRT(2250)으로부터 수신된 룰을 프로세스한 후에, 다음 판단 블럭(2592)은 파서 스택(2430) 상의 다음 심볼이 bottom-of-stack 심볼인지를 판단한다. 만일 다음 심볼이 bottom-of-stack 심볼이면, 실행은 블럭 2510으로 넘겨지는데, 거기서 시맨틱 프로세서(2100)는 입력 포트(2110)를 통해 입력 버퍼(2300)에서 수신되는 새로운 패킷을 기다린다.

다음 심볼이 bottom-of-stack 심볼이 아니라면, 다음 판단 블록 2594는 DXP(2400)가 파서 스택(2430) 상의 다음 심볼 프로세싱을 시작하기 전에 추가 입력을 기다릴지 여부를 판단한다. 예시된 실시예에서, DXP(2400)는 SPU(2140)가 입력 스트림의 프로세싱 세그먼트를 시작하고 SPU(2140)가 프로세싱 결과 데이타를 되돌려 보내는 것 등을 기다릴 수 있다.

DXP(2400)이 더 이상의 입력을 기다리지 않는 때에는, 실행은 블럭 2530으로 되돌려 보내지는데, DXP(2400)은 입력 버퍼(2300)로부터 입력 스트림 데이타를 요 청하고 수신한다. DXP(2400)이 추가 입력을 기다리고 있다면, 실행은 입력이 수신될 때까지 블럭 2594로 되돌아 간다.

도 19는 다른 시맨틱 프로세서 실시예를 보여준다. 시맨틱 프로세서(2600)는 다수의 시맨틱 프로세싱 유닛(SPU) 2140-1 에서 2140-N을 포함하는 시맨틱 프로세싱 유닛(SPU) 클러스터(2640)을 포함한다. 바람직하게는, SPU 2140-1에서 2140-N 각각은 동등하고 동일한 기능을 갖는다. SPU 클러스터(2640)는 메모리 서브시스템(2130), SPU 엔트리 포인트(SEP) 발송기(2650), SCT(2150), 포트 입력 버퍼(PIB, 2700), 포트 출력 버퍼(POB, 2620) 및 머신 중앙 처리 유닛(MCPU, 2660)에 연결된다.

DXP(2800)이 SPU 작업이 파싱 중 특정 포인트에서 론칭되어야 한다고 결정하는 때에, DXP(2800)는 SEP 발송기(2650)에게 시맨틱 코드 테이블(SCT, 2150)로부터 마이크로 명령을 로드하고 다수의 SPU 2140-1부터 2140-N 로부터 SPU를 배정하도록 신호를 준다. 로드된 마이크로 명령은 작업이 수행되고 배정된 SPU에 보내질 것을 지시한다. SPU는 SEP 발송기(2650)에 의해 지시되는 때에 직접 SCT(150)로부터 마이크로 명령을 선택적으로 로드할 수 있다.

더 자세한 설명을 위해 도 20을 참조하면, PIB(2700)는 적어도 하나의 네트워크 인터페이스 입력 버퍼(2300)(2300-0 및 2300-1이 도시되어 있음), 재순환 버퍼(2710) 및 PCI-X(Peripheral Component Interconnect) 입력 버퍼(2300_2)를 포함한다. POB(2620)는 적어도 하나의 네트워크 인터페이스 출력 버퍼와 PCI-X 출력 버퍼를 포함한다(도시되지 않음). 포트 블럭(2610)은 하나 이상의 포트를 포함하는 데, 각각의 포트는 물리적 인터페이스, 즉 예를 들면 이더넷, 파이버 채널, 802.11x, USB, 파이어와이어(Firewire), SONET, 혹은 다른 물리적 레이어(layer) 인터페이스를 위한 광학적, 전기적 혹은 무선 드라이버/리시버 쌍을 포함한다. 바람직하게는, 포트 블럭(2610) 내의 포트의 수는 PIB(2700) 내의 네트워크 인터페이스 입력 버퍼의 수 및 POB(2620) 내의 출력 버퍼의 수와 일치한다.

도 19를 참조하면, PCI-X 인터페이스(2630)는 PIB(2700) 내의 PCI-X 입력 버퍼, POB(2620) 내의 PCI-X 출력 버퍼 및 외부 PCI 버스(2670)에 연결된다. PCI 버스(2670)는 디스크 드라이브와 같은 다른 PCI-가능 컴포넌트, 추가적인 네트워크 포트를 위한 인터페이스 등에 연결될 수 있다.

MCPU(2660)는 SPU 클러스터(2640)과 메모리 서브시스템(2130)과 연결된다. MCPU(2660)는 전통적인 소프트웨어에서 합리적으로 이루어질 수 있는, 시맨틱 프로세서(2600)를 위한 원하는 기능을 수행한다. 이러한 기능은 자주 있는 것은 아니고, 코드 복잡성 때문에 SCT(2150)에 포함되는 것을 보증할 수 없는, 시간 상으로 중요한 기능은 아닌 것들이다. 바람직하게는, MCPU(2660)는 또한 SPU가 MCPU를 대신하여 작업을 수행하도록 요청하기 위해 SEP 발송기(2650)와 통신할 수 있다.

도 20은 본 발명의 실시예에서 유용한 포트 입력 버퍼(PIB, 2700)에 대한 가능한 구현예를 나타낸다. PIB(2700)는 두 개의 네트워크 인터페이스 입력 버퍼(2300_0 및 2300_1), 재순환 버퍼(2710) 및 PCI-X 입력 버퍼(2300_2)를 포함한다. 입력 버퍼 2300_0, 2300_1 및 PCI-X 입력 버퍼 2300_2는 기능적으로 입력 버퍼 2300과 동일하지만, 이들은 각각 포트 블럭(2610)과 PCI-X 인터페이스(2630)으로의 서로 다른 입력으로부터 입력 데이타를 수신한다.

재순환 버퍼(2710)는 SPU 클러스터(2640)으로부터 재순환 데이타를 수신하는 버퍼(2712), 버퍼(2712)에서 재순환 데이타를 컨트롤하기 위한 컨트롤 블럭(2714), DXP(2800, 도 21) FIFO로 하여금 버퍼(2712) 내의 재순환 데이타로의 액세스를 허용하는 FIFO 블럭(2716), SPU 클러스터(2640) 내의 SPU가 버퍼(2712) 내의 재순환 데이타로의 랜덤 액세스를 허용하는 랜덤 액세스(RA) 블럭(2718)으로 구성된다. 재순환 데이타가 SPU 클러스터(2640)로부터 버퍼(2712)에서 수신되는 때에, 재순환 버퍼(2710)는 Port ID를 DXP(2800)로 전송하고, DXP(2800)에게 새로운 데이타가 도착했음을 알려준다. 바람직하게는, 전송된 Port ID는 버퍼(2712) 내의 첫번째 심볼이다.

DXP(2800)가 재순환 데이타를 통해 파스하기로 결정한 때에, DXP는 버퍼(2712)로부터 특정 양의 데이타를 요청하는 혹은 버퍼(2712)의 데이타 포인터를 증가시키는 Control_DXP 신호를 재순환 버퍼(2710)에 전송한다. Control_DXP 신호를 수신하는 때에, 컨트롤 블럭(2714)은 버퍼(2712)로부터 데이타를 담고 있는 Data_DXP 신호를 FIFO 블럭(2716)을 통해 DXP(2800)으로 보낸다. 본 발명의 실시예에서, 컨트롤 블럭(2714)과 FIFO 블럭(2716)은 Data_DXP 신호를 이용하여 DXP(2800)에 보내지는 재순환 데이타에 컨트롤 문자를 추가한다. 바람직하게는, 컨트롤 문자는 전송되는 각각의 바이트 데이타 시작에 추가되고 바이트 데이타가 터미널 혹은 논-터미널 심볼인지를 명시한다.

SPU 클러스터(2640) 내의 SPU(2140)가 SPU(2140)로 하여금 재순환 스트림 내 의 데이타를 액세스하도록 요구하는 SPU 엔트리 포인트(SEP)를 DXP(2800)으로부터 수신하는 때에, SPU(2140)는 재순환 버퍼(2710)에 버퍼(2712)로부터 특정 지점의 데이타를 요청하는 Control_SPU 신호를 전송한다. Control_SPU 신호를 수신하는 때에, 컨트롤 블럭(2714)은 버퍼(2712)로부터의 데이타를 포함하는 Data_SPU 신호를 RA 블럭(2718)을 통해 SPU(2140)으로 전송한다.

도 21은 DXP(2800)에 대한 개연성있는 블럭 구현예를 보여준다. 파서 컨트롤 유한 스테이트 머신(FSM, 2410)은 도 17에서 예시된 DXP(2400)에 대해 설명된 것과 유사한 방법으로, 도 21에서 다른 논리 블럭으로부터의 입력에 근거하여 전체 DXP(2800) 동작을 제어하고 시퀀스한다. 다른 점은 입력 버퍼(2700)에서 다중 파싱 입력의 존재에 기인한다. 이러한 차이점은 파서 컨트롤 FSM(2410), 스택 핸들러(2830) 및 입력 스트림 시퀀스 컨트롤(2420)에 넓게 퍼져있다. 더불어, 도 17의 파서 스택(2430)는 다수의 파서 스택 2430_1 부터 2430_M까지를 유지할 수 있는 파서 스택 블럭(2860)으로 대체된다. 마지막으로 파서 데이타 레지스터 뱅크(2810)가 추가되었다.

스택 핸들러(2830)는 DXP(2800)에 의해 실행되어야 하는 심볼을 저장하고 시퀀싱함으로써 다수의 파서 스택 2430_1 부터 2430_M 까지를 컨트롤한다. 본 발명의 일 실시예에서, 파서 스택 2430_1 부터 2430_M 까지가 단일 메모리에 지정되는데, 이 경우 각각의 파서 스택은 메모리의 고정된 부분에 배정된다. 선택적으로, 파서 스택 블럭(2860) 내의 파서 스택 2430_1 부터 2430_M 까지의 수 및 각각의 파서 스택의 크기는 능동 입력 데이타 포트 및 문법에 의해 지시되는 바에 따라 스택 핸들 러(2830)에 의해 동적으로 결정되고 변경될 수 있다.

DXP(2800)는 파서 테이블 인터페이스(2840), 프로덕션 룰 테이블(PRT) 인터페이스(2850), 입력 스트림 시퀀스 컨트롤(2420) 및 SPU 인터페이스(2440)를 포함하는 다수의 인터페이스 블럭을 통해 입력을 수신한다. 일반적으로, 앞에서 설명된 데로 이러한 인터페이스는 입력 스트림 시퀀스 컨트롤(2420)의 예외를 가지면서 기능한다.

입력 스트림 시퀀스 컨트롤(2420) 및 데이타 레지스터 뱅크(2810)는 PIB(2700)로부터 입력 스트림 데이타를 가져온 후 보유하고 있게 된다. 데이타 레지스터 뱅크(2810)는 수신된 입력 스트림 데이타를 저장할 수 있는 다수의 레지스터로 구성된다. 바람직하게는, 레지스터의 수는, 파서 스택 블럭(2860) 내에 존재할 수 있고 각각의 레지스터는 N 개의 입력 심볼을 가지고 있을 수 있는 파서 스택 2430_1 부터 2430_M 까지의 최대 수와 같다.

파서 컨트롤 FSM(2410)은 입력 스트림 시퀀스 컨트롤(2420), 데이타 레지스터 뱅크(2810) 및 다른 입력 버퍼 간에 파싱 콘텍스트를 스위치하기 위한 스택 핸들러(2830)를 컨트롤한다. 예를 들면, 파서 컨트롤 FSM(2410)은 현재 입력 버퍼 2300_0, 입력 버퍼 2300_1, PCI-X 입력 버퍼 2300_2 혹은 재순환 버퍼(2710)으로부터의 데이타와 동작 중인지를 나타내는 콘텍스트 스테이트(context state)를 보존한다. 이 콘텍스트 스테이트는 입력 스트림 시퀀스 컨트롤(2420)로 전송되는데, 이로 인해 적절한 입력 혹은 재순환 버퍼로의 커맨드로 데이타 입력 혹은 문법 내의 스킵 커맨드에 응답하도록 한다. 콘텍스트 스테이트는 데이타 레지스터 뱅크(2810) 로 전송되는데, 현재 콘텍스트 스테이트와 대응되는 레지스터를 액세스하도록 그 레지스터 로드와 읽기가 이루어진다. 마지막으로, 콘텍스트 스테이트는 스택 핸들러(2830)로 전송되는데, 스택 핸들러(2830)가 파서 스택 2430_1 부터 2430_M 중에 올바른 것을 액세스하도록 푸쉬(push) 및 팝(pop) 커맨드를 내린다.

파서 컨트롤 FSM은 언제 파싱 콘텍스트를 스위치할 것인지를 결정한다. 예를 들면, bottom-of-stack 심볼이 특정 파서 스택 상에 이르렀을 때, 혹은 특정 파서 콘텍스트가 SPU 동작 때문에 멈추었을 때, 파서 컨트롤 FSM는 다음 파싱 콘텍스트의 스테이트를 검사하고 파싱이 준비된 파싱 콘텍스트에 이를 때가지 라운드-로빈 방식으로 계속된다.

도 15a, 15b 및 19 내지 21에서 블럭의 기본 동작들이 도 22에서 데이타에 대한 흐름도를 참조하여 설명될 것이다. 흐름도(2900)는 본 발명의 일실시예에 따른 방법을 예시하는데 사용된다.

판단 블럭(2905)에 따르면, DXP(2800)는 스톨된 파서 스택에 대응되는 데이타가 아닌 새로운 데이타가 PIB(2700)에 수신되었는지를 판단한다. 본 발명의 실시예에서, PIB(2700) 내의 4 개의 버퍼는 각각이 고유 Port ID를 갖는데, 이 Port ID들은 새로운 데이타가 수신되는 때에 DXP(2800)으로 전송된다. 바람직하게는, 재순환 버퍼(2710)는 각각의 순환 데이타 세그먼트 내의 첫번째 바이트로서 자신의 고유 Port ID를 포함한다. PIB(2700) 내의 4 개의 버퍼가 독립적인 입력을 가지기 때문에, DXP(2800)는 복수의 Port ID를 동시에 수신할 수 있다. DXP(2800)이 복수의 Port ID를 받는 때에, 바람직하게는 DXP는 포트에 존재하는 새로운 데이타를 파스 하게 되는 시퀀스를 결정하는 라운드 로빈 아비트래이션(arbitration)을 사용한다. 본 발명의 일실시예에서, 파서 스택은 파싱이 특정 스트림에서 정지되어야 하는 때에 DXP(2800)에 의해 저장될 수 있다. 파서 스택은 FSM(2410)이 스택 핸들러(2830)에게 파서 스택의 선택을 스위치하도록 명령하는 Control 신호를 보내는 때에 저장된다.

새로운 데이타가 아직 수신되지 않았을 때, 프로세싱은 블럭 2905로 되돌아가는데, 이 경우 DXP(2800)는 PIB(2700)에 의해 수신되는 새로운 데이타를 기다린다.

새로운 데이타가 수신되었을 때, 다음 블럭 2910에 따르면, DXP(2800)는 선택된 버퍼의 Port ID를 NT 심볼로서 선택된 파서 스택에 푸쉬하는데, 이 경우에 선택된 버퍼는 DXP(2800)이 파스하도록 선택한 PIB(2700) 내의 버퍼이고, DXP(2800) 내의 선택된 파서 스택은 DXP(2800)이 실행되어야 할 심볼을 저장하도록 선택한 파서 스택이다. 각각의 포트를 위해 로드된 문법 혹은 문법의 일부는 그 포트를 위해 로드된 초기 논-터미널 심볼에 따라 달라진다. 예를 들면, 만약 한 입력 포트가 SONET 프레임을 수신하고 다른 입력 포트가 이더넷 프레임을 수신한다면, 개별 포트에 대한 Port ID NT 심볼이 각각의 포트에 대한 적절한 문법을 자동으로 선택하기 위해 사용될 수 있다.

본 발명의 실시예에서, 입력 스트림 시퀀스 컨트롤(2420)은 라운드 로빈 아비트래이션(arbitration)을 통해 PIB(2700) 내의 버퍼를 선택하고, 스택 핸들러(2830)는 파서 스택 블럭(2860) 내의 파서 스택을 선택한다. 본 발명의 바람직한 실시예에서, FSM(2410)은 PIB(2700) 내의 버퍼 선택을 가능하게 하기 위해 입력 스트림 시퀀스 컨트롤(2420)로 신호를 전송하고, 레지스터를 선택하기 위해 데이타 레지스터 뱅크(2810)로 Control Reg 신호를 전송한다. 또한 FSM(2410)은 버퍼 선택을 가능하게 하기 위해 혹은 파서 스택 블럭(2860)에서 파서 스택을 동적으로 할당하기 위해 스택 핸들러(2830)로 Control 신호를 전송한다.

예시적 목적을 위해, 입력 버퍼 2300_0은 DXP(2800)에 의해 선택된 Port ID를 가지고 파서 스택 2430_1은 입력 버퍼 2300_0으로부터의 데이타를 파싱하는 데 있어 DXP(2800)에 의해 사용되는 문법 심볼을 저장하기 위해 선택되는 것을 가정한다. 본 발명의 예시적 목적 상, 스택 핸들러(2830)가 SYM 코드와 Control 신호 각각에서 FSM(2410)으로부터 Port ID 및 Push 커맨드를 받은 후에, Port ID는 스택 핸들러(2830)에 의해 파서 스택 2430_1로 푸쉬된다. Port_ID에 선행하는 1 비트 스테이터스 플래그는 NT 심볼로서 Port ID를 표시한다.

다음 블럭 2920에 따르면, DXP(2800)는 선택된 버퍼 내에서 스트림으로부터 N 바이트의 데이타 (혹은 그 일부)를 요청하고 수신한다. 예시된 실시예에서, DXP(2800)는 PIB(2700) 내의 입력 버퍼 2300_0과 입력 스트림 시퀀스 컨트롤(2420) 간에 연결된 DATA/CONTROL 신호를 통해 N 바이트의 데이타를 요청하고 수신한다. 입력 스트림 시퀀스 컨트롤(2420)에 의해 데이타가 수신된 후, 데이타는 데이타 레지스터 컨트롤(2810) 내의 선택된 레지스터에 저장되는데, 여기서 데이타 레지스터 컨트롤(2810) 내의 선택된 레지스터는 현재의 파싱 콘텍스트에 의해 컨트롤된다.

다음 블럭 2930에 따르면, DXP(2800)는 DXP가 더 이상의 입력을 기다리고 있 지 않으며 선택된 파서 스택 상의 심볼이 bottom-of-stack 심볼이 아니라는 것을 판단한 후에, 선택된 파서 스택의 탑(top) 상의 심볼과 수신된 N 바이트(혹은 그 일부)를 프로세스한다. 블럭 2930은 탑 심볼이 터미널 혹은 논-터미널 심볼인지 판단을 포함한다. 이 결정은 스택 핸들러에 의해, 바람직하게는 파서 스택 2430_1의 탑 상의 심볼의 스테이터스 플래그를 읽고 그 스테이터스를 프레픽스(P : prefix) 코드 신호로서 FSM(2410)에 전송함으로써 수행될 수 있다.

심볼이 터미널(T) 심볼이라고 판단되면, 판단 블럭 2935에서 DXP(2800)는 T 심볼과 수신된 N 바이트로부터의 다음 바이트 데이타 간에 매치를 체크한다.

본 발명의 바람직한 실시예에서, DXP(2400)에 의해 사용되고 T 심볼의 매치가 이루어졌는지를 체크하는 매치 신호 M이, 비교기(2820)가 스택 핸들러(2830)로부터 T 심볼 및 데이타 레지스터 컨트롤(2810) 내의 선택된 레지스터로부터의 다음 바이트 데이타와 함께 입력되는 때에, 비교기(2820)에 의해 FSM(2410)으로 전송된다.

현재 파서 스택의 탑 상에 심볼이 논-터미널 심볼이라고 판단되는 때에는, 블럭 2945에서 DXP(2800)는 파서 스택 2430_1로부터 NT 심볼 및 뱅크(2810)로부터 선택된 레지스터 내의 수신된 N 바이트를 파서 테이블(2200)로 전송한다. 예시된 실시예에서, NT 심볼 및 수신된 N 바이트는 파서 테이블 인터페이스(2840)에 보내지는데, 이 경우 이들은 파서 테이블(2200)에 보내지기 전에 연결된다. 선택적으로, NT 심볼 및 수신된 N 바이트는 파서 테이블(2200)로 직접 전송될 수 있다. 몇몇 실시예에서, 선택된 레지스터 내에 수신된 N 바이트는 SPU(2140) 및 파서 테이 블(2200)로 동시에 보내진다.

바람직하게는, 파서 스택(2430_1) 상의 심볼은 비교기(2820), 파서 테이블 인터페이스(2450) 및 PRT 인터페이스에 동시에 보내진다.

유효한 블럭 2935 T 심볼 매치가 시도되는 것을 가정할 때, 그 매치가 성공적이라면, 실행은 블럭 2920으로 넘어는데, 이 경우 DXP(2800)는 PIB(2700)로부터 N 바이트의 추가 데이타를 요청하고 수신한다. 본 발명의 일실시예에서, DXP(2800)는 T 심볼 매치가 이루어진 후 스트림 데이타의 한 바이트 만을 요청하고 수신할 것이다.

블럭 2935 매치가 시도되었으나 성공적이지 못한 경우, 다음 블럭 2940에 따르면, 문법이 지시하는 때에 DXP(2800)는 선택된 파서 스택을 비우고 현재 입력 버퍼로부터 현재의 데이타 세그먼트의 나머지를 제거하기 위해 SEP을 론치(launch)한다. DXP(2800)는 나머지 심볼을 꺼내기 위해 컨트롤 신호를 스택 핸들러(2830)에 전송함으로써 파서 스택 2430_1을 리셋하고 스택 포인터를 bottom-of-stack 심볼로 세트한다. DXP(2800)는 SPU 인터페이스(2440)를 통해 SPU 발송기(2140)에 커맨드를 전송함으로써 SEP를 론치하는데, 이 경우 SPU 발송기(2650)는 SCT(2150)으로부터 마이크로 명령을 펫치(fetch)하기 위해 SPU(2140)를 배정한다. 마이크로 명령은 실행되었을 때 입력 버퍼 2300_0으로부터 현재 데이타 세그먼트의 나머지를 제거한다. 다음 실행은 블럭 2905로 넘어가는데, 이 경우 DXP(2800)는 스톨된 파서 콘텍스트를 갖는 데이타 입력이 아닌 데이타 입력에 대한 새로운 데이타가 PIB(2700)에서 수신되었는지를 판단한다.

top-of-stack 심볼이 논-터미널 심볼이라 가정했을 때, 블럭 2945 매치가 블럭 2935 매치를 대신해 시도된다. 파서 테이블에서 N 바이트 데이타와 연결된 NT 심볼로의 매치가 있는 때에는, 실행은 블럭 2950으로 진행한다. 파서 테이블(2200)은 DXP(2800)의 매치에 대응되는 PR 코드를 되돌려 보내고, DXP(2800)은 PRT(2250)에서 프로덕션 룰을 검색하기 위해 PR 코드를 사용한다. 일 실시예에서, 프로덕션 룰은 PRT(2250) 내에 지정된 PRT 메모리(2270)에서 검색된다.

예시된 실시예에서, PR 코드는 중간 파서 테이블 인터페이스(2450) 및 PRT 인터페이스(2460)를 통해 파서 테이블(2200)로부터 PRT(2250)로 전송된다. 선택적으로, PR 코드는 파서 테이블(2200)로부터 PRT(2250)로 직접 전송될 수 있다.

판단 블럭 2945에서 매치가 성공적이지 못하면, 다음 블럭 2960에 따라, DXP(2800)는 PRT(2250) 내의 디폴트 프로덕션 룰을 검색하기 위해 선택된 파서 스택으로부터 NT 심볼을 사용한다. 한 실시예에서, 디폴트 프로덕션 룰이 PRT(2250) 내에 위치한 MART(2280) 메모리에서 검색된다. 선택적으로, MART(2280) 메모리는 PRT(2250)가 아닌 메모리 블럭 내에 위치할 수 있다.

예시된 실시예에서, 스택 핸들러(2830)는 프로덕션 룰 인터페이스(2850)와 파서 테이블 인터페이스(2840) NT 심볼을 동시에 전송한다. 선택적으로, 스택 핸들러(2830)는 NT 심볼을 파서 테이블(2200)과 PRT(2250)에 직접 보낼 수 있다. PRT(2250)가 PR 코드 및 NT 심볼을 수신하는 때에, PRT는 프로덕션 룰과 디폴트 프로덕션 룰을 PRT 인터페이스(2850)로 동시에 전송한다. 프로덕션 룰 인터페이스(2480)는 FSM(2410)에 적절한 룰을 되돌려 보내기만 한다. 다른 실시예에서는, 프로덕션 룰과 디폴트 프로덕션 룰 양쪽 모두가 FSM(2410)에 보내진다. 또 다른 실시예에서는, PRT(2250)는 PR 코드가 PRT(2250)에 보내졌는지에 따라 PR 혹은 디폴트 PR 중 하나를 PRT 인터페이스(2850)에 전송하기만 한다.

블럭 2950 혹은 블럭 2960이 실행되면 다음 블럭 2970으로 진행한다. 블럭 2970에 따르면, DXP(2800)는 PRT(2250)으로부터 수신된 프로덕션 룰을 프로세스한다. 본 발명의 실시예에서, FSM(2410)은 프로덕션 룰을 3 개의 세그먼트로 나누는데, 심볼 세그먼트, SEP 세그먼트 및 스킵 바이트 세그먼트이다. 바람직하게는, 앞에서 설명한 바와 같이 각각의 프로덕션 룰의 세그먼트는 쉽고 정밀한 분리를 가능하게 하기 위해 고정된 길이거나 널-종료를 갖는다.

도 22의 블럭 2970은 다음의 차이를 가지면서 도 18의 블럭 2590과 유사한 방식으로 동작한다. 첫째로, 프로덕션 룰의 심볼 세그먼트는 현재 콘텍스트를 위해 올바른 파서 스택 상으로 푸쉬된다. 둘째로, 프로덕션 룰의 스킵 바이트 섹션은 데이타 레지스터 뱅크 내의 적절한 레지스터 및 현재 콘텍스트를 위해 적절한 입력 버퍼를 조절하는데 사용된다. 셋째로, SEP가 SEP 발송기에 전송되는 때에, 명령은 SPU에 의해 시맨틱 코드의 실행을 위한 적절한 입력 버퍼를 지시한다.

다음 판단 블럭 2975에 의하면, DXP(2800)는 선택된 버퍼 내의 입력 데이타가 추가적인 파싱을 필요로 하는지를 결정한다. 본 발명의 실시예에서, 입력 버퍼 2300_0에서의 입력 데이타는 파서 스택 2430_1이 bottom-of-stack 심볼이 아닌 심볼을 가리키고 있을 때에 추가적인 파싱이 필요하다. 바람직하게는, FSM(2410)은 파서 스택 2430_1에 대한 스택 포인터가 bottom-of-stack 심볼을 가리키고 있을 때 스택 핸들러(2830)로부터 스택 비었음 신호 SE를 수신한다.

선택된 버퍼에서의 입력 데이타가 더 이상 파스될 필요가 없을 때에는, 실행은 블럭 2905로 넘어가는데, 이 곳에서 DXP(2800)는 스톨된 파서 스택을 가진 입력 버퍼가 아닌 다른 입력 버퍼가 PIB(2700)에서 새로운 데이타를 기다리고 있는 지를 판단한다.

선택된 버퍼에서 입력 데이타가 추가적인 파스가 필요하다면, 다음 판단 블럭 2985에 따라, DXP(2800)는 DXP가 선택된 버퍼에서 입력 데이타 파싱을 계속할 수 있는지를 판단한다. 본 발명의 실시예에서, SPU 동작이 진행 중이거나 실행 중인 것 때문에, 입력 데이타의 부족, 다른 입력 데이타가 DXP(2800)에서 파싱에 대해 우선 순위를 가지는 경우 등 여러 가지 이유 때문에 여전히 파싱이 필요한 때에, 파싱은 주어진 버퍼로부터의 입력 데이타에서 정지할 수 있다. 한 실시예에서는, 입력 버퍼 2300_0에서 입력 데이타보다 우선 순위를 가지는 다른 입력 버퍼가 이전에 자신의 파서 스택이 저장되거나 혹은 문법이 지시하는 바에 따라 더 높은 우선 순위를 가지는 입력 버퍼일 수 있다. DXP(2800)는 스테이터스 신호를 통해 SEP 발송기(2650)에 의해 SPU 프로세싱 지연에의 경고를 받고, FSM(2410)에 저장된 스테이터스 값에 의해 우선 순위 파싱 작업에 대해 경고를 받는다.

DXP(2800)가 현재 파싱 콘텍스트에서 파싱을 계속할 때 실행은 블럭 2920으로 넘어가는데, 이 경우에 DXP(2800)은 선택된 버퍼 내에서 입력 데이타로부터 N 바이트의 데이타까지를 요청하고 수신한다.

DXP(2800)가 파싱을 계속하지 못할 때에는, 다음 블럭 2990에 따라, DXP(2800)는 선택된 파서 스택을 저장하고 뒤이어 선택된 파서 스택, 데이타 레지스터 뱅크(2810) 내의 선택된 레지스터 및 선택된 입력 버퍼를 선택 해제한다. FSM(2410)으로부터 스위치 Control 신호를 받은 후에, 스택 핸들러(2830)는 파서 스택 블럭(2860) 내의 다른 파서 스택을 선택함으로써 파서 스택 2430_1을 저장하고 선택 해제한다.

입력 스트림 시퀀스 컨트롤(2420)은 FSM(2410)으로부터 스위치 신호를 수신한 후에, 입력 데이타를 받은 PIB(2700) 내에 다른 버퍼를 선택함으로써 입력 버퍼 2300_0을 선택 해제하고, 데이타 레지스터 뱅크(2810)는, FSM(2410)으로부터 스위치 신호를 받은 후에, 다른 레지스터를 선택함으로써 선택된 레지스터를 선택 해제한다. 입력 버퍼 2300_0, 선택된 레지스터, 파서 스택 2430_1은 DXP 2800에 의해 파스될 PIB 2700 내의 새로운 데이타를 기다리는 아무런 데이타가 없을 때에 능동으로 남아 있을 수 있다.

실행은 블럭 2905로 넘어가는데, 여기서 DXP(2800)는 스톨된 파서 스택이 아닌 다른 입력 버퍼가 PIB(2700)에서 수신되었는지를 판단한다.

도 23은 본 발명의 실시예에 따른 시맨틱 프로세서(3100)의 블럭도를 보여준다. 시맨틱 프로세서(3100)는 입력 포트(3120)를 통해 수신된 패킷 데이타 스트림을 버퍼링하기 위한 입력 버퍼, 입력 버퍼(3140)에서 수신된 패킷 데이타의 프로세싱을 제어하는 직접 실행 파서 DXP(3180), 재순환 버퍼(3160) 및 패킷 프로세싱을 위한 패킷 프로세서(3200)를 포함한다. 입력 버퍼(3140) 및 재순환 버퍼(3160)는 바람직하게는 FIFO(first-in-first-out) 버퍼이다. 패킷 프로세서(3200)는 패킷의 세그먼트를 프로세싱하기 위한 혹은 다른 동작을 수행하기 위한 실행 엔진(3220) 및 패킷의 세그먼트를 저장 및/또는 증가시키기 위한 메모리 서브시스템(3240)으로 구성된다.

DXP(3180)는 패킷의 프로세싱 혹은 입력 버퍼(예를 들어 입력 "스트림") 내의 프레임 및 재순환 버퍼(3160)(예를 들어 재순환 "스트림")를 제어한다. DXP(3180)가 입력 버퍼(3140)로부터의 입력 스트림과 재순환 버퍼(3160)로부터의 재순환 스트림을 동일한 방식으로 파스하기 때문에, 입력 스트림의 파싱만이 아래에서 설명될 것이다.

DXP(3180)는 현재 심볼까지의 현재 프레임의 파싱에 기초하여 터미널 및 논-터미널 심볼의 내부 파서 스택을 유지한다. 파서 스택의 탑에서의 심볼(들)이 터미널 심볼이면, DXP(3180)는 입력 스트림의 헤드에 있는 데이타를 터미널 심볼에 대조하고 계속 진행을 위해 매치를 기대한다. 파서 스택의 탑에서의 심볼이 논-터미널 심볼인 때에는, DXP(3180)는 스택 상에서 문법 프로덕션을 확장하기 위해 논-터미널 심볼 및 현재 입력 데이타를 사용한다. 파싱이 계속되면서, DXP(3180)는 실행 엔진(3220)으로 하여금 입력의 세그먼트를 프로세스하거나 다른 동작을 수행하도록 명령한다.

시맨틱 프로세서(3100)는 최소한 두 개의 테이블을 사용한다. 컴플렉스(complex) 문법 프로덕션 룰은 프로덕션 룰 테이블 PRT(3190)에 저장된다. 이 프로덕션 룰을 꺼내기 위한 코드는 파서 테이블 PT(3170)에 저장된다. 파서 테이블(3170)의 코드는 DXP(3180)이 주어진 프로덕션 룰에 대해 패킷 프로세서(3200) 프로세싱이 패킷의 세그먼트에 대해 수행되어야 한다는 것을 결정하도록 허용한다.

본 발명의 몇몇 실시예는 도 23에서 보여진 구성 요소보다 더 많은 것을 포함한다. 도 23에서 보여진 시맨틱 프로세서 내의 패킷 흐름 설명이 더 복잡한 실시예가 언급되기 전에 먼저 이루어져야 할 것이다.

도 24는 도 23의 시맨틱 프로세서(3100)를 통해 수신된 패킷의 프로세싱을 위한 흐름도(3300)를 포함한다. 흐름도(3300)는 발명의 방법을 예시하기 위해 사용되었다.

블럭 3310에 따르면 패킷은 입력 포트(3120)를 통해 입력 버퍼(3140)에서 수신된다. 다음 블럭 3320에 따르면, DXP(3180)는 입력 버퍼(3140) 내의 패킷의 헤더를 통해 파스를 시작한다. 패킷이 패킷 패이로드의 프로세싱을 가능하게 하는 부가적인 조정 혹은 추가적인 패킷이 필요하지 않는 경우에 있어서, DXP(3180)는 헤더를 통해 완전하게 파스할 것이다. 패킷이 패킷 패이로드의 프로세싱을 가능하게 하는 부가적인 조정 혹은 추가적인 패킷이 필요한 경우에는 DXP(3180)는 해더를 파스하는 것을 종료할 것이다.

판단 블럭 3330에 따르면, DXP(3180)가 헤더를 통해 완전히 파스할 수 있었는지 여부가 조사되어야 한다. 만일 DXP(3180)가 헤더를 통해 완전히 파스할 수 있었다면, 다음 블럭 3370에 따라, DXP(3180)는 패킷 패이로드를 프로세스하기 위해 패킷 프로세서(3200) 내의 루틴을 호출하고 시맨틱 프로세서(3100)는 입력 포트(3120)를 통해 입력 버퍼(3140)에서 수신되는 다음 패킷을 기다린다.

만일 DXP(3180)가 헤더 파싱을 마쳐야 한다면, 다음 블럭 3340에 따라, DXP(3180)는 패킷을 조정하기 위해 패킷 프로세서(3200) 내의 루틴을 호출하거나 다른 패킷을 기다린다. 조정 완료 혹은 추가적인 패킷 도착 시점에 패킷 프로세서(3200)는 조정된 패킷을 생성한다.

다음 블럭 3350에 따르면, 패킷 프로세서(3200)는 조정된 패킷(혹은 그 일부)을 재순환 버퍼(3160)에 쓴다. 이는 재순환 버퍼(3160)가 메모리 서브시스템(3240)에 직접 메모리 액세스를 갖거나 혹은 실행 엔진(3220)이 메모리 서브시스템(3240)으로부터 조정되어 맞추어진 패킷을 읽고 그 다음 조정된 패킷을 재순환 버퍼(3160)에 쓰는 것에 의해 성취될 수 있다. 선택적으로, 패킷 프로세서(3200) 내에서 프로세싱 시간을 줄이기 위해, 특화된 헤더가 조정된 패킷 전체 대신에 재순환 버퍼(3160)에 써질 수 있다. 이 특화된 헤더는 패킷 프로세서(3200)로 하여금 패킷 프로세서의 메모리 서브시스템(3240)에서 전체 패킷을 전송할 필요없이 조정된 패킷을 프로세스하도록 해준다.

다음 블럭 3360에 따르면, DXP(3180)는 재순환 버퍼(3160) 내의 데이타 헤더를 통해 파스를 시작한다. 실행은 블럭 3330으로 넘어가는데, 여기서 DXP(3180)가 헤더를 통해 완전히 파스할 수 있었는지가 조사된다. 만일 DXP(3180)가 헤더를 통해 완전히 파스할 수 있었다면, 다음 블럭 3370에 따라, DXP(3180)는 패킷 패이로드를 프로세스하기 위해 패킷 프로세서(3200) 내의 루틴을 호출하고 시맨틱 프로세서(3100)는 입력 포트(3120)를 통해 입력 버퍼(3140)에서 수신된 다음 패킷을 기다린다.

만일 DXP(3180)가 헤더 파싱을 종료해야 한다면, 실행은 블럭 3340으로 넘어 가는데, 이곳에서 DXP(3180)는 패킷 프로세서(3200)가 패킷을 조정하도록 루틴을 호출하거나 다른 패킷을 기다리는데, 그렇게 함으로써 조정된 패킷을 생성한다. 패킷 프로세서(3200)는 조정된 패킷을 재순환 버퍼(3160)에 쓰고 DXP(3180)는 재순환 버퍼(3180) 내의 패킷의 헤더를 통해 파스를 시작한다.

도 25는 다른 시맨틱 프로세서(3400) 실시예를 보여준다. 시맨틱 프로세서(3400)는 해슁 기능 혹은 컨텐트-어드레서블 메모리(CAM) 검색을 통해 DRAM에서 데이타를 액세스하기 위한 어레이 머신-콘텍스트 데이타 메모리(AMCD), 암호화를 위한 암호화 블럭(3440), 데이타의 복호화 혹은 인증, DRAM(3480)으로 혹은 DRAM(3480)으로부터의 캐슁 콘텍스트 컨트롤 블럭을 위한 콘텍스트 컨트롤 블럭 캐쉬(3450), 기본 동작에서 사용되는 데이타를 캐슁하기 위한 일반 캐쉬(3460) 및 DRAM(3480)으로부터 읽히고 써지는 데이타 스트림의 캐슁을 위한 스트리밍 캐쉬(3470)를 포함한다. 콘텍스트 컨트롤 블록 캐쉬(3450)는 바람직하게는 소프트웨어-제어 캐쉬, 즉, 프로세스는 언제 캐쉬 라인이 사용되고 비워지는지를 판단한다. 각각의 다섯 블럭이 DRAM(3480)과 연결되어 있고 시맨틱 코드 실행 엔진(SEE)은 시맨틱 프로세싱 유닛 SPU(3410)로 불리우기도 한다. SEE(3410)는, DXP(3180)에 의해 신호가 오면, 패킷의 세그먼트를 프로세스하거나 다른 동작을 수행한다. DXP(3180)가 SEE 작업이 파싱 중에 특정 포인트에서 론칭되었다고 판단하면, DXP(3180)은 SEE(3410)에 시맨틱 코드 테이블 SCT(3420)으로부터 마이크로 명령을 로드하도록 신호를 준다. 로드된 마이크로 명령은 SEE(3410)에서 실행되고 패킷의 세그먼트는 그에 따라 프로세스된다.

도 26은 도 25의 시맨틱 프로세서(3400)를 통해 수신된 인터넷 프로토콜(IP)-조각 패킷의 프로세싱을 위한 흐름도(3500)를 포함한다. 흐름도(3500)는 본 발명의 실시예에 따라 한 가지 방법을 예시하기 위해 사용된다.

일단 패킷이 입력 포트(3120)를 통해 입력 버퍼에서 수신되면 DXP(3180)는 입력 버퍼(3140) 내의 패킷의 헤더를 통해 파스를 시작하고, 블럭 3510에 따라 DXP(3180)는 패킷이 IP-조각난 패킷으로 판명되었으므로 수신된 패킷의 헤더를 통한 파싱을 종료한다. 바람직하게는, DXP(3180)는 IP 헤더를 통해 완벽히 파스하지만 (TCP, UDP, iSCSI 등과 같은) 후속 레이어에 속하는 모든 헤더를 통한 파스는 종료한다.

다음 블럭 3520에 따르면, DXP(3180)은 SEE(3410)에 SCT(3420)으로부터 적절한 마이크로 명령을 로드하고 입력 버퍼(3140)로부터 수신된 패킷을 읽도록 신호를 준다. 다음 블럭 3530에 따르면, SEE(3410)는 스트리밍 캐쉬(3470)를 통해 수신된 패킷을 DRAM(3480)에 쓴다. 비록 블럭 3520과 3530이 두 개의 독립된 단계로 보여지고 있지만, 이들은 SEE(3410)가 패킷을 동시에 읽고 쓰는 것에 의해 한 단계로서 선택적으로 이루어질 수도 있다. 이 SEE(3410)에 의한 읽기와 쓰기의 동시 동작은 SEE 파이프라인으로 알려져 있으며, 여기서 SPU(3410)는 시맨틱 프로세서(3400) 내의 두 개의 블럭 간에 전송되는 스트리밍 데이타에 대한 통로 혹은 파이프라인으로 동작한다.

다음 판단 블럭 3540에 따르면, SPU(3410)는 CCB(Context Control Block)가 올바른 IP 패킷 조각의 컬렉션과 시퀀싱을 위해 할당되었는가를 판단한다. IP 조각 난 패킷에 대응되는 조각을 컬렉팅하고 시퀀싱하기 위한 CCB는 바람직하게는 DRAM(3480)에 저장된다. CCB는 DRAM(3480)에 IP 조각에 대한 포인터, 아직 도착하지 않은 IP 조각 패킷에 대한 비트 마스크 및 시맨틱 프로세서(3400)가 할당된 시간 후에 추가적 IP 조각 패킷을 기다리는 것을 끝내고 DRAM(3480) 내에 CCB에 저장된 데이타를 풀어 주도록 강제하는 타이머 값을 포함한다.

SPU(3410)는 바람직하게는 CCB가 키로서 수신된 IP 패킷 조각의 헤더로부터의 식별 및 프로토콜과 결합된 수신된 IP 조각 패킷의 IP 소스 어드레스를 사용하여 AMCD(3430)의 컨텐트-어드레서블 메모리(CAM) 검색 기능을 액세스하는 것에 의해 할당될 수 있는지를 판단한다. 선택적으로, IP 조각 키는 DRAM(3480) 내의 독립된 CCB 테이블에 저장되고 수신된 IP 패킷 조각의 헤더로부터 식별 및 프로토콜과 결합된 수신된 IP 조각의 IP 소스 어드레스를 사용함에 의해 CAM으로 액세스된다. 이 IP 조각 키의 선택적 어드레싱은 키 겹침과 크기 문제를 피한다.

만일 SPU(3410)가 CCB가 특정 IP 조각 패킷에 대한 조각의 컬렉션 및 시퀀싱에 대해 할당되지 않았다는 것으로 판단되면 실행은 블럭 3550으로 넘어가는데 그곳에서 SPU(3410)는 CCB를 할당한다. SPU(3410)는 바람직하게는 할당된 CCB와 대응되는, 수신된 IP 조각의 IP 소스 어드레스 및 수신된 IP 조각 패킷의 헤더로부터의 식별 및 프로토콜로 구성되는 키를 AMCD(3430) 내의 IP 조각 CCB 테이블에 입력하고 CCB에 위치한 타이머를 시작하도록 한다. 주어진 조각 패킷에 대한 첫번째 조각이 수신되었을 때, IP 헤더는 다음 재순환을 위해 CCB에 저장된다. 추가의 조각을 위해서는, IP 헤더가 저장될 필요는 없다.

일단 CCB가 IP 조각 패킷의 컬렉션과 시퀀싱을 위해 할당되었다면, 다음 블럭 3560에 따라, SPU(3410)는 CCB 내의 DRAM(3480) (IP 헤더를 뺀) IP 조각 패킷으로의 포인터를 저장한다. 조각에 대한 포인터는 예를 들면 연결된 리스트로서 CCB내에 정렬될 수 있다. 바람직하게는, SPU(3410)는 수신된 조각과 대응되는 마스크의 부분을 표시함으로써 새로이 할당된 CCB에 비트 마스트를 또한 갱신한다.

다음 판단 블럭 3570에 따르면, SPU(3410)는 패킷으로부터의 모든 IP 조각이 수신되었는지를 판단한다. 바람직하게는, 이 판단은 CCB의 비트 마스크를 사용함으로써 이루어진다. 당업자는 본 발명에서의 사용을 위해 비트 마스크 혹은 동등한 추적 메커니즘을 구현하는 여러 가지 기술을 사용할 수 있다는 것을 이해할 것이다.

만일 조각 패킷에 대해 모든 IP 조각이 수신되지 않았다면, 시맨틱 프로세서(3400)는 다른 조각이 수신될 때까지 그 조각난 패킷에 대한 추가적인 프로세싱은 미룬다.

만일 모든 IP 조각이 수신된다면, 다음 블럭 3580에 따라, SPU(3410)는 타이머를 리셋하고 올바른 순서에 따라 DRAM(3480)으로부터 IP 조각을 읽고, 이들을 추가적인 파싱과 프로세싱을 위해 재순환 버퍼(3160)에 쓴다. 바람직하게는, SPU(3410)는 재순환 버퍼(3160)에 특화된 헤더와 (조각화 비트가 세트되지 않은 상태로) 재조립된 IP 패킷의 첫번째 부분 만을 쓴다. 특화된 헤더는 DXP(3180)가 모든 IP 조각 패킷을 재순환 버퍼(3160)로 전송할 필요없이 DRAM(3480)에 저장된 재조립된 IP 조각 패킷의 프로세싱을 지시할 수 있도록 한다. 특화된 헤더는 IP와 CCB로의 포인터에 대한 파서 문법을 로드하는 지정된 논-터미널 심볼로 구성될 수 있다. 파서는 보통은 IP 헤더를 파스하고 좀 더 높은 레이어(예를 들면 TCP) 헤더를 파스하는 것으로 진행해 나간다.

본 발명의 실시예에서, DXP(3180)는 재순환 버퍼(3160)에서 혹은 라운드 로빈 아비트래이션을 통한 입력 버퍼(3140)에서 수신된 데이타를 파스할 것을 결정한다. 라운드 로빈 아비트래이션의 높은 레벨의 설명은 패킷 데이타 스트림을 수신하기 위한 제 1 및 제 2 버퍼를 참조하여 이루어질 것이다. DXP(3180)가 제 1 버퍼 내의 패킷의 파싱을 완료한 후에, 제 2 버퍼가 데이타가 파스되도록 사용가능한지를 판단할 것을 기대한다. 만일 그렇다면, 제 2 버퍼로부터의 데이타는 파스된다. 그렇지 않다면, DXP(3180)는 제 1 버퍼가 데이타가 파스되도록 사용가능한지를 결정하도록 기대한다. DXP(3180)는 제 1 버퍼 혹은 제 2 버퍼에서 데이타가 파스되도록 사용가능할 때가지 이 라운드 로빈 아비트래이션을 계속한다.

도 27은 도 25의 시맨틱 프로세서(3400)를 통한 복호화 및/또는 인증이 필요한 수신된 패킷의 프로세싱을 위한 흐름도(3600)를 포함한다. 흐름도(3600)는 본 발명의 실시예에 따른 다른 방법을 예시하는데 사용된다.

일단 패킷이 입력 버퍼(3140) 혹은 재순환 버퍼(3160)에서 수신되고 DXP(3180)가 수신된 패킷의 헤더를 통해 파스를 시작하면, 블럭 3610에 따라, DXP(3180)는 패킷이 복호화 및/또는 인증이 필요하다고 판단되었으므로 수신된 패킷의 헤더를 통한 파싱을 종료한다. 만일 DXP(3180)가 재순환 버퍼(3160)로부터의 패킷 헤더를 통한 파스를 시작하면, 바람직하게는 재순환 버퍼(3160)는 앞에서 언 급한 특화된 헤더 및 재조립된 IP 패킷의 첫번째 부분만을 포함할 것이다.

다음 블럭 3620에 따르면, DXP(3180)는 SPU(3410)에 SCT(3420)로부터 적절한 마이크로 명령을 로드하고 입력 버퍼(3140) 혹은 재순환 버퍼(3160)로부터 수신된 패킷을 읽도록 신호를 준다. 바람직하게는, SPU(3410)는 재순환 버퍼에 미리 놓여지지 않은 데이타에 대해 재순환 버퍼(3160) 대신 DRAM(3480)으로부터 패킷 조각을 읽는다.

다음 블럭 3630에 따르면, SPU(3410)는 수신된 패킷을 암호화 블럭(3440)에 쓰는데, 이 경우 패킷은 인증되든지 복호화되든지 혹은 양쪽 모두이다. 바람직한 실시예에서, 복호화와 인증은 암호화 블럭(3440)에서 병력적으로 수행된다. 암호화 블럭(3440)은 T-DES(Triple Data Encryption Standard), AES(Advanced Encryption Standard), MD-5 (Message Digest 5), SHA-1(Secure Hash Algorithm 1), RC-4(Rivest Cipher 4) 알고리즘 등의 사용을 통해 패킷의 인증, 암호화 혹은 복호화를 가능하게 한다. 비록 블럭 3620 및 3630이 독립된 두 개의 단계로 도시되었지만, 이들은 선택적으로 SPU(3410)가 패킷을 동시에 읽고 쓰는 한 단계로 수행될 수도 있다.

복호화된 및/또는 인증된 패킷이 SPU(3410)에 씌여지는데, 다음 블럭 3640에 따르면, SPU(3410)는 패킷을 추가 프로세싱을 위해 재순환 버퍼(160)에 쓴다. 바람직한 실시예에서, 암호화 블럭(3440)은 DRAM(3480)에 데이타를 쓰고 읽을 수 있는 직접 메모리 액세스 엔진을 포함한다. 복호화된 및/또는 인증된 패킷을 DRAM(3480)에 쓰는 것으로써, SPU(3410)는 DRAM(3480)으로부터 복호화된 및/또는 인증된 패킷 의 헤더를 읽을 수 있고 후속적으로는 이들을 재순환 버퍼(3160)에 쓸 수 있다. 패킷의 패이로드가 DRMA(3480)에 남아 있기 때문에, 시맨틱 프로세서(3400)는 프로세싱 시간을 줄인다. IP 조각화와 함께, 특화된 헤더는 파서에게 방향을 정하고 CCB 정보를 SPU(3410)에 넘겨 주기 위해 재순환 버퍼에 씌여질 수 있다.

재순화 버퍼(3160)를 통한 복수 넘겨줌(패스)은 IP 조각화와 암호/인증이 시맨틱 프로세서(3400)에 의해 수신된 단일 패킷에 포함될 때에 필요할 것이다.

도 28은 다른 시맨틱 프로세서 실시예를 보여준다. 시맨틱 프로세서(3700)는 다수의 시맨틱 실행 엔진(SPU) 3410-1, 3410-2 ... 3410-N을 포함하는 시맨틱 실행 엔진(SPU) 클러스터(3710)를 포함한다. 바람직하게는, 3410-1로부터 3410-N 까지 각각의 SPU는 동일하고 같은 기능을 갖는다. SPU 클러스터(3710)는 메모리 서브시스템(3240), SPU 엔트리 포인트(SEP) 발송기(3720), SCT(3420), 포트 입력 버퍼 PIB (3730), 포트 출력 버퍼 POB (3750) 및 머신 중앙 처리 유닛 MCPU (3771)에 연결된다.

DXP(3180)가 SPU 작업이 파싱에서 특정 포인트에서 론칭되어야 한다고 판단할 때, DXP(3180)는 SEP 발송기(3720)에게 시맨틱 코드 테이블 SCT(3420)으로부터 마이크로 명령을 로드하고 작업을 수행하기 위해 SPU 클러스터 3710 내의 3410-1부터 3410-N 까지 다수의 SPU로부터 SPU를 할당하도록 신호를 준다. 로드된 마이크로 명령과 수행되어야 할 작업은 할당된 SPU로 전송된다. 할당된 SPU는 마이크로 명령을 실행하고 그에 따라 데이타 패킷이 프로세스된다. SPU는 SEP 발송기(3720)에 의해 명령될 때에 SCT(3420)으로부터 마이크로 명령을 선택적으로 로드할 수 있다.

PIB(3730)는 적어도 하나의 네트워크 인터페이스 입력 버퍼와 재순환 버퍼 및 PCI-X(Peripheral Component Interconnect) 입력 버퍼를 포함한다. POB(3750)는 적어도 하나의 네트워크 인터페이스 출력 버퍼와 PCI-X 출력 버퍼를 포함한다. 포트 블럭(3750)은 하나 이상의 포트를 포함하는데 각각은 예를 들면 이더넷, Fibre Channel, 802.11x, USB, 파이어와이어(Firewire), 혹은 다른 물리적 레이어 인터페이스를 위한 광학적, 전기적 혹은 무선 주파수 드라이버/리시버 쌍 같은 물리적 인터페이스로 구성된다. 바람직하게는, 포트 블럭(3740) 내의 포트의 수는 PIB(3730) 내의 네트워크 인터페이스 입력 버퍼의 수와 POB(3750) 내의 출력 버퍼의 수와 일치한다.

PCI-X 인터페이스(3760)는 PIB(3730) 내의 PCI-X 입력 버퍼, POB(3750) 내의 PCI-X 출력 버퍼, 외부 PCI 버스(3780)에 연결된다. PCI 버스(3780)는 디스크 드라이브와 같은 PCI-케이블 컴포넌트, 추가적인 네트워크 포트 등의 인터페이스에 연결된다.

MCPU(3771)는 SPU 클러스터(3710) 및 메모리 서브시스템(3240)과 연결된다. MCPU(3771)는 표준 하드웨어 상에서 동작하는 전통적인 소프트웨어로 통상 수행되는 시맨틱 프로세서(3700)를 위한 모든 원하는 기능을 수행한다. 이러한 기능은 보통 자주 발생하지 않는, 그리고, 복잡성 때문에 SCT(3420)에 포함되는 것을 보장할 수 없는 시간에 구애받지 않는 기능들이다. 바람직하게는, MCPU(3771)는 또한 MCPU 대신에 SPU가 작업을 수행할 것을 요청하기 위해 SPU 클러스터(3720)에서 발송기와 통신할 수 있다.

본 발명의 실시예에서, 메모리 서브시스템(3240)은 암호화 블럭(3440), 콘텍스트 컨트롤 블럭 캐쉬(3450), 일반 캐쉬(3460) 및 스트리밍 캐쉬(3470)를 DRAM(3480)과 외부 DRAM(3791)에 연결하는 DRAM 인터페이스(3790)로 구성된다. 이 실시예에서, AMCD(3430)은 외부 SRAM(Static Random Access Memory)(3795)에 연결되는 외부 TCAM(3793)에 직접 연결된다.

도 29는 도 28의 시맨틱 프로세서(3700)를 통해 수신된 iSCSI(Internet Small Computer Systems Interface)의 프로세싱을 위한 흐름도(3800)를 포함한다. 흐름도(3800)는 본 발명의 실시예에 따른 다른 방법을 예시하기 위해 사용된다.

블럭(3810)에 따르면, iSCSI 데이타의 전송을 위해 적어도 하나의 TCP(Transmission Control Transmission) 세션을 갖는 iSCSI 연결이 이니시에이터(initiator)와 타겟 시맨틱 프로세서(3700) 사이에 확립된다. 시맨틱 프로세서(3700)는 PT(3160) 내에 적절한 문법과 PRT(3190) 및 TCP 세션을 확립하기 위해 SCT(3420) 내에 마이크로코드를 갖고 MCPU(3771)를 통해 iSCSI 연결의 초기 로그인과 인증을 프로세스한다. 한 실시예에서, SPU 클러스터(3810) 내의 하나 이상의 SPU는 만일 더 이상의 TCP/iSCSI 패킷이 할당된 시간 프레임 안에 도착하지 않는다면 TCP 재배열, 윈도우 크기 제한 및 TCP 세션 종료를 위한 타이머를 위해 DRAM(3480) 내에 CCB를 할당하는 것을 포함하여 TCP 세션을 위한 스테이트를 조직하고 유지한다. TCP CCB는 일단 iSCSI 연결이 MCPU(3771)에 의해 확립되면 그 CCB와 iSCSI CCB를 연관시키기 위한 필드를 포함한다.

TCP 세션이 이니시에이터로 확립된 후, 다음 블럭 3820에 따라, 시맨틱 프로 세서(3700)는 블럭 3810에서 확립된 TCP 세션에 대응되는 TCP/iSCSI 패킷이 PIB(3730)의 입력 버퍼(3140)에 도착하는 것을 기다린다. 시맨틱 프로세서(3700)가 입력 데이타를 프로세싱하기 위해 3410-1 부터 3410-N 까지의 다수의 SPU를 가지기 때문에, 시맨틱 프로세서(3700)는 블럭 3810에서 확립된 TCP 세션에 대응되는 다음 TCP/iSCSI 패킷을 기다리는 동안 복수의 패킷을 병렬적으로 수신하고 프로세스할 수 있다.

TCP/iSCSI 패킷은 포트 블럭(3740)의 입력 포트(3120)를 통해 PIB(3730)의 입력 버퍼(3140)에서 수신되고, DXP(3180)는 입력 버퍼(3140) 내에서 패킷의 TCP 헤더를 통해 파스한다. 다음 블럭 3830에 따르면, DXP(3180)는 SEP 발송기(3720) 에 SCT(3420)로부터 적절한 마이크로 명령을 로드하도록 신호를 주고, SPU 클러스터(3710)로부터 SPU를 할당하며, 실행되었을 때 할당된 SPU가 입력 버퍼(3140)로부터 수신된 패킷을 읽고 스트리밍 캐쉬(3470)를 통해 DRAM(3480)에 수신된 패킷을 쓰도록 요구하는 할당된 SPU 마이크로 명령을 전송한다. 할당된 SPU는 TCP CCB를 지정하기 위해 AMCD(3430)의 검색 기능을 사용하고, DRAM(3480)에 수신된 패킷의 위치에 대한 포인터를 TCP CCB에 저장하고, TCP CCB에 있는 타이머를 재시작한다. 할당된 SPU는 풀어 놓아지고 DXP(3180)이 판단하는 것에 따라 다른 프로세싱을 위해 할당될 수 있다.

다음 블럭 3840에 따르면, 수신된 TCP/iSCSI 패킷은 만일 필요하다면, 패이로드 데이타의 올바른 시퀀싱을 확증하기 위해 재배열된다. 선행 기술에서 잘 알려진 바와 같이, TCP 패킷은 만일 모든 선행하는 패킷이 도착하였다면 올바른 순서로 되어있다고 여겨진다.

수신된 패킷이 올바른 순서로 되어있다고 판단되는 때에는, 담당 SPU는 SEP 발송기(3720)에게 iSCSI 재순환을 위해 SCT(3420)로부터 마이크로 명령을 로드하도록 신호를 준다. 다음 블럭 3850에 따르면, 할당된 SPU는 특화된 iSCSI 헤더를 생성하기 위해 CSI 헤더, TCP 헤더로부터의 TCP 연결 ID와 iSCSI 논-터미널을 결합한다. 할당된 SPU는 그 후 특화된 iSCSI 헤더를 PIB(3730) 내의 재순환 버퍼(3160)에 쓴다. 선택적으로, 특화된 iSCSI 헤더는 대응되는 iSCSI 패이로드와 함께 재순환 버퍼(3160)로 보내질 수 있다.

다음 블럭(3860)에 따르면, 특화된 iSCSI 헤더는 파스되고 시맨틱 프로세서(3700)는 iSCSI 패이로드를 프로세스한다.

다음 판단 블럭 3870에 따르면, 수신된 TCP/iSCSI 패킷에 다른 iSCSI 헤더가 있는지가 조사된다. 만일 'YES'라면, 실행은 블럭 850으로 넘어가는데, 이 곳에서 수신된 TCP/iSCSI 패킷 내의 제 2 iSCSI 헤더가 제 2 iSCSI 패이로드를 프로세스하는데 사용된다. 선행 기술에서 잘 알려진 바와 같이, 단일 TCP/iSCSI 패킷에 복수의 iSCSI 헤더와 패이로드가 있을 수 있으며 그리하여 주어진 iSCSI 패킷에 대하여 재순환 버퍼(3160)와 DXP(3180)를 통해 보내지는 다수의 패킷 세그먼트가 있게 된다.

만일 'NO'라면, 블럭 3870은 블럭 3820으로 실행이 넘겨지는데 이곳에서 시맨틱 프로세서(3700)은 블럭 3810에서 확립된 TCP 세션에 대응되는 다른 TCP/iSCSI 패킷을 기다린다. 할당된 SPU는 놓여지고 DXP(3180)이 판단하는 것에 따라 다른 프 로세싱을 위해 할당될 수 있다.

당업자가 이해하는 바와 같이 복수의 패킷 세그먼트는 암호화, 인증, IP 조각화 및 iSCSI 데이타 프로세싱의 어떤 조합이라도 시맨틱 프로세서(3700)에 의해 수신된 단일 패킷에 포함되는 때에, 다른 시점에서 재순환 버퍼(3160)를 통해 넘겨질 수 있다.

메모리 서브 시스템

도 30은 메모리 서브시스템을 좀더 자세하게 보여준다. SPU(3710)의 클러스터와 ARM(3814)이 메모리 서브시스템(3240)에 연결된다. 선택적인 실시예에서, ARM(3814)은 SPU(3710)를 통해 메모리 서브시스템(3240)에 연결된다. 메모리 서브시스템(3240)은 다른 종류의 메모리 액세스에 각각 적응된 복수의 서로 다른 캐쉬 영역 3460, 3450, 3470, 3430 및 3771을 포함한다. 복수의 캐쉬 영역 3460, 3450, 3470, 3430 및 3771은 일반적으로 캐쉬 영역 3825로 참조된다. SPU 클러스터(3710)와 ARM(3814)는 메인 DRAM 아비터(3828)를 통해 외부 DRAM(3791A)와 통신하는 모든 다른 캐쉬 영역(3825)과 통신한다. 한 구현 예에서는 그러나 CCB 캐쉬(3450)가 CCB DRAM 컨트롤러(3826)를 통해 독립된 외부 CCB DRAM (3791B)으로 통신을 할 수 있다.

다른 캐쉬 영역(3825)은 다른 데이타 프로세싱 동작을 위해 DRAM 데이타 전송을 향상시킨다. 일반 캐쉬(3460)는 SPU(3710)에 의해 일반 목적의 메모리 액세스를 위한 전통적인 캐쉬로 동작한다. 예를 들면, 일반 캐쉬(3460)는 일반 컨트롤과 데이타 액세스 동작을 위해 사용되는 일반 목적 랜덤 메모리 액세스를 위해 사용될 수 있다.

CCB 캐쉬(3450)에서 캐쉬 라인 대체는 소프트웨어 커맨드에 의해 배타적으로 컨트롤된다. 이는 하드웨어가 누가 마지막으로 캐쉬 라인 위치를 점거했는가에 기초하여 캐쉬의 컨텐트를 컨트롤하는 전통적인 캐쉬 동작과 상반된다. 소프트웨어로 CCB 캐쉬 영역(3450)을 제어하는 것은 캐쉬 라인이 외부 DRAM(3791B)로부터 로드되거나 갱신되기 전에 캐쉬가 하나 이상의 SPU(3710)에 의해 어떤 중간 프로세싱을 필요로 하는 캐쉬 라인을 너무나 이른 때에 다시 로드하는 것을 막아준다.

스트리밍 캐쉬(3470)는 스트리밍 패킷 데이타를 프로세싱하기 위해 주로 사용된다. 스트리밍 캐쉬(3470)는 스트리밍 패킷 전송이 일반 캐쉬(3460)에 있는 모든 엔트리를 대체하지 못하게 한다. 스트리밍 캐쉬(3470)는 SPU가 아직 스트리밍 캐쉬(3470)에 위치하는 동안 하나 이상의 SPU(3710)가 데이타를 읽을 필요가 있을 수 있으므로 FIFO(First-In-First-Out) 메모리 대신 캐쉬로서 구현된다. 만일 FIFO가 사용된다면, 스트리밍 데이타는 그것이 외부 DRAM(3791A)에 로드된 후에만 읽혀질 수 있을 것이다. 스트리밍 캐쉬(3470)는 다른 패킷 스트림을 포함할 수 있는 복수의 버퍼를 포함한다. 이는 다른 SPU(3710)가 스트리밍 캐쉬(3470)에 위치할 때에 다른 패킷 스트림을 액세스하도록 허용한다.

MCPU(3771)는 ARM(3814)으로부터 명령문 액세스를 위해 주로 사용된다. MCPU(3771)는 ARM(3814)과 외부 DRAM(3791A) 간의 버스터 모드(burst mode) 액세스의 효율을 향상시킨다. ARM(3814)는 일실시예에서 32 비트 길이인 내부 캐쉬(3815)를 포함한다. MCPU(3771)는 특별히 32 버스트(burst) 비트 전송을 다루도록 지시된 다. MCPU(3771)는 ARM(3814)로부터 복수의 32 비트 버스트(burst)를 버퍼링하고 캐쉬 라인이 몇몇 데이타의 문턱량에 도달하는 때에 외부 DRAM 3791A로 급속히 퍼져간다.

일실시예에서, 각각의 캐쉬 영역(3825)은 외부 DRAM 3791A 와 3719B에 서로 다르게 관련된 영역에 물리적으로 맵핑된다. 이는 독립된 MCPU(3771)가 ARM(3814)와 외부 DRAM 간에 명령 전송으로부터 다른 캐쉬 영역에서 행해지는 데이타 전송에 의해 영향을 받는 것을 피하게 해준다. 예를 들면, SPU(3710)는 ARM(3814)에 의해 사용되는 명령 공간에 영향을 주는 것 없이 캐쉬 영역 3460, 3450 및 3470을 통해 데이타를 로드할 수 있다.

S- Code

도 31은 어떻게 개별 SPU(3410)에 의해 다른 캐쉬 영역(3825)으로 메모리 액세스가 시작되는지 좀더 자세하게 보여준다. 단순화를 위해, 도 31에 오직 일반 케쉬(3460), CCB 캐쉬(3450) 및 스트리밍 캐쉬(3470) 만이 도시된다.

마이크로 명령(3900), 바꿔부르면 SPU 코드(S-Code)는, 직접 실행 파서(도 1)로부터 SPU 서브시스템(3710)에 보내진다. 마이크로 명령의 예가 도 32A에 좀더 자세히 도시되어 있다. 마이크로 명령(3900)은 개별 SPU(3410)에 어떤 캐쉬 영역(3825)이 데이타 액세스를 위해 사용될 지를 나타내는 타겟 필드(3914)를 포함할 수 있다. 예를 들면, 도 32a의 캐쉬 영역 필드(3914)는 SPU(3410)가 CCB 캐쉬(3450)를 사용할 것을 지시한다. 타겟 필드(3914)는 또한 SPU(3410)가 MCPU 인터페이스(3771)(도 30), 재순환 버퍼(3160)(도 23) 혹은 출력 버퍼(3750)(도 28)를 액세스할 것을 지시하는 데 사용될 수 있다.

도 31을 다시 참조하면, 각각의 캐쉬 영역(3825)은 SPU 서브시스템(3710)에 관련된 큐 세트를 가진다. 각각의 SPU(3410)는 다른 캐쉬 영역(3825)으로 순서대로 액세스를 제공하는 큐(3902)에 대한 데이타 액세스 요청을 보낸다. 큐(3902)는 또한 다른 SPU(3410)가 동시에 다른 캐쉬 영역으로 메모리 액세스를 행하고 시작하도록 허용한다.

도 32b는 SPU(3410)와 캐쉬 영역(3825) 간에 보내진 캐쉬 요청(3904)의 예를 보여준다. 캐쉬 요청(3904)은 어드레스와 모든 관련 데이타를 포함한다. 더불어, 캐쉬 요청(3904)은 어떤 SPU(3410)가 요청(3904)과 관련되는지를 식별하는 SPU 태그(3906)를 포함한다. SPU 태그(3906)는 캐쉬 영역(3825)에 어떤 SPU(3410)를 요청된 데이타를 되돌려 보낼 것인지를 말해준다.

아비트래이션( Arbitration )

도 30을 다시 참조하면, 흥미로운 것은 일실시예에서 다른 데이타 캐쉬 영역(3825)으로부터 언제 데이타가 외부 DRAM(3791A)로의 액세스를 얻는지를 판단하는 라운드 로빈 아비트래이션을 사용하는 DRAM 아비터(3828)이다. 라운드 로빈 아비트래이션 프레임에서 메인 DRAM 아비터(3828)는 어떤 캐쉬 영역(3825)이 외부 DRAM(3791A)에 요청된 액세스를 가지는지를 체크하면서 이미 결정된 순서로 돌아간다. 만일 특정 캐쉬 영역(3825)이 메모리 액세스 요청을 하면, 관련된 라운드 로빈 기간 동안 외부 DRAM(3791A)으로의 액세스가 허가된다. 아비터(3828)는 메모리 액세스 요청을 위한 라운드 로빈 순서에서 다음 캐쉬 영역(3825)을 체크한다. 만일 다음 캐쉬 영역(3825)이 메모리 액세스 요청을 가지고 있지 않다면, 아비터(3828)는 라운드 로빈 순서로 다음 캐쉬 영역(3825)을 체크한다. 이 프로세스는 각각의 캐쉬 영역(3825)이 라운드 로빈 순서로 서비스되면서 계속된다.

CCB 캐쉬(3450)와 외부 DRAM(3791A) 간의 액세스는 큰 대역폭을 사용할 수 있다. CCB DRAM 컨트롤러(3826)는 CCB 캐쉬(3450)와 독립된 외부 CCB DRAM(3791B) 간의 CCB 전송을 위해 배타적으로 사용될 수 있다. 두 개의 다른 버스 3834와 3836이 두 개의 다른 DRAM 3791A 및 3791B 각각으로의 액세스를 위해 사용될 수 있다. 다른 캐쉬 영역 3460, 3470, 3430, 3440 및 3771에 의한 외부 메모리 액세스는 버스(3834)를 통해 메인 DRAM 아비터에 의해 중재(arbitrate)된다. 만일 CCB 캐쉬(3450)가 독립된 CCB 컨트롤러(3826)를 통해 외부 DRAM에 연결되지 않느다면, 메인 DRAM 컨트롤러(3828)는 모든 캐쉬 영역(3825)을 위해 외부 DRAM(3791A)로의 모든 액세스를 중재한다.

다른 실시예에서는 외부 DRAM(3791A) 및 외부 CCB DRAM(3791B)으로의 액세스가 번갈아 포개진다. 이는 CCB 캐쉬(3450) 및 다른 캐쉬 영역(3825)이 외부 DRAM 3791A와 외부 CCB DRAM 3791B 양쪽 모두로의 액세스를 행할 수 있다는 것을 의미한다. 이는 두 개의 메모리 뱅크 3791A가 동시에 액세스 되는 것을 허용한다. 예를 들면, CCB 캐쉬(3450)는 외부 메모리 3791A로부터 읽기 동작을 수행할 수 있고 동시에 외부 메모리 3791B에 쓰기 동작을 수행할 수 있다.

일반 캐쉬

도 33은 일반 캐쉬(3460)의 상세한 예를 보여준다. 일반 캐쉬(3460)는 SPU(3410) 중 하나로부터 물리적 어드레스(3910)를 수신한다(도 31). 캐쉬 라인(3918)은 물리적 어드레스(3910)로부터의 저 순위 어드레스 공간(LOA)(3916)에 따라 액세스된다.

캐쉬 라인(3918)은 일례에서, 상대적으로 작을 수 있고 혹은 다른 캐쉬 영역(3825)에서 사용되는 캐쉬 라인보다 다른 크기를 가진다. 예를 들면, 캐쉬 라인(3918)은 스트리밍 캐쉬(3470) 및 CCB 캐쉬(3450)에서 사용되는 캐쉬 라인의 크기보다 훨씬 작을 것이다. 이는 다른 캐쉬 영역(3825)에 의해 프로세스되는 다른 종류의 데이타에 대한 좀더 주문화된 메모리 액세스를 제공한다. 예를 들면 캐쉬 라인(3918)은 일반 컨트롤 데이타 프로세싱을 위해 오직 16 바이트 길이일 것이다. 반면에, 스트리밍 캐쉬(3470)를 위한 캐쉬 라인은 좀더 큰 데이타 블럭을 전송하기 위해 64 바이트처럼 좀더 큰 캐쉬 라인을 가질 수 있다.

각각의 캐쉬 라인(3918)은 캐쉬 라인의 데이타가 유효한지를 나타내는 관련 유효 플래그(valid flag)를 가질 것이다. 캐쉬 라인(3918)은 또한 관련된 고 순위 어드레스(HOA : High Order Address)를 가진다. 일반 캐쉬(3460)는 물리적 어드레스(3910)를 가지고 그 다음 LOA(Low Order Address)와 관련된 캐쉬 라인(3918)에 대한 HOA(3922)와 유효 플래그(3920)를 체크한다. 만일 유효 플래그(3920)가 유효 캐쉬 엔트리를 나타내고 HOA(3922)가 물리적 어드레스(3910)에 대해 HOA(3914)와 매치된다면, 캐쉬 라인(3918)의 컨텐트를 요청하는 SPU(3410)로 읽혀진다. 만일 플래그 필드(3920)가 무효한 엔트리를 나타내면, 캐쉬 라인(3918)의 컨텐트는 외부 DRAM(3791A)에 있는 대응 어드레스에 의해 덮어 써진다(도 30).

만일 플래그 필드(3920)가 유효한 캐쉬 엔트리를 나타내지만, HOA(3922)가 물리적 어드레스(3910)에서의 HOA(3914)와 매치된다면, 캐쉬 라인(3918)의 엔트리 중 하나는 외부 DRAM(3891A)으로 자동적으로 로드되고 물리적 어드레스(3910)와 관련된 외부 DRAM(3791A)의 컨텐트는 LOA(3916)와 관련된 캐쉬 라인(3918)로 로드된다.

콘텍스트 컨트롤 블록( CCB ) 캐쉬

도 34는 좀더 상세하게 콘텍스트 컨트롤 블럭(CCB) 캐쉬(3450)를 보여준다. CCB(3450)는 복수의 버퍼(3940)와 결합 태그(3942)를 포함한다. 전통적인 4-way 결합 캐쉬에 반해, CCB(3450)는 본질적으로 32-way 결합 캐쉬같이 동작한다. 복수 CCB 버퍼(3940)와 결합 태그(3942)는 SPU(3410)를 통해 보내지는 일련의 소프트웨어 커맨드에 의해 컨트롤된다. 소프트웨어 커맨드(3946)는 CCB 캐쉬(3450)와 외부 DRAM(3791A 혹은 3791B) 간의 데이타 전송을 컨트롤하는데 사용되는 일련의 캐쉬/DRAM 명령(3946)을 포함한다. 일련의 SPU/캐쉬 커맨드(3948)는 SPU(3410)와 CCB 캐쉬(3450) 간의 데이타 전송을 컨트롤하는데 사용된다. 소프트웨어 명령(3946)은 ALLOCATE, LOAD, COMMIT AND DROP 동작을 포함한다. 소프트웨어 명령(3948)은 READ 와 WRITE 동작을 포함한다.

도 35는 SPU(3410)와 CCB 캐쉬(3450) 간에 보내진 CCB 커맨드(3954)의 몇가지 예를 보여준다. 이 소프트웨어 커맨드(3944) 모두는 SPU(3410)를 통해 CCB 캐쉬(3450)으로 언제라도 보내어 질 수 있다.

도 34와 35를 참조하면, SPU(3410) 중의 하나는 ALLOCATE 커맨드(3954A)를 CCB 버퍼(3940) 중의 하나에 최초로 할당하기 위해 CCB 캐쉬(3450)에 보낸다. ALLOCATE 커맨드(3954A)는 특정 메모리 어드레스 혹은 CCB를 포함하는 DRAM(3791)에 있는 물리적 어드레스와 관련된 CCB 태그(3956)를 포함한다. CCB 캐쉬(3450) 내의 컨트롤러(3950)는 각각의 버퍼(3940)와 관련된 어드레스 혹은 태그와 수신된 CCB 어드레스의 병렬 매치를 수행한다. 각각의 버퍼(3940)와 관련된 어드레스들은 관련된 태그 필드(39420)에 있다.

만일 어드레스/태그(3956)가 태그 필드(3942)의 어떤 곳에도 포함되어 있지 않다면, 컨트롤러(3950)는 사용되지 않은 버퍼(3940) 중 하나를 특정 CCB 태그(3956)에 할당한다. 만일 어드레스가 태그 필드(3942) 중 하나에 이미 존재한다면, 컨트롤러(3950)는 특정 CCB 태그(3956)와 이미 관련된 버퍼(3940)를 사용한다.

컨트롤러(3950)는 CCB 버퍼(3940)가 성공적으로 할당되었는지를 나타내는 응답(3954B)을 요청 SPU(3410)에 되돌려 보낸다. 만일 버퍼(3940)가 성공적으로 할당되었다면, 컨트롤러(3950)는 새로이 할당된 버퍼(3940)로 CCB 태그(3956)로 사용하는 모든 SPU로부터 모든 CCB 커맨드에 맵핑한다.

SPU(3410)가 특정 메모리 어드레스에 대해 현재 외부 DRAM(3791)에 있는 데이타에 관심이 없을 경우가 있다. 예를 들면, 외부 DRAM(3791)에 있는 데이타가 중첩되어 써질 때이다. 전통적인 캐쉬 구조에서는, 현재 캐쉬에 포함되지 않은 모든 특정 어드레스의 컨텐트는 메인 메모리부터 캐쉬 메모리로 자동적으로 로드된다. 하지만, ALLOCATE 커맨드(3946)는 DRAM(3791)으로부터 데이타를 일단 읽어야 할 필요없이 버퍼(3940) 중의 하나를 단순히 할당한다. 그리하여, 버퍼(3940)는 버 퍼(3940)에 있는 데이타를 외부 DRAM(3791)으로 쓰거나 읽을 필요없이 중간 데이타 프로세싱을 위한 스크래치 패드(scratch pad)로 사용될 수 있다.

LOAD와 COMMIT 소프트웨어 커맨드(3946)는 캐쉬 버퍼(3940) 중의 하나와 외부 DRAM(3791) 간의 데이타 전송을 완결하는데 필요한다. 예를 들면, LOAD 커맨드(3956C)는 외부 DRAM(3791)로부터 CCB 캐쉬(3450) 내의 관련 버퍼(3940)로 특정 CCB 태그(3956)와 관련된 CCB를 로드하기 위해 SPU(3410)로부터 컨트롤러(3950)로 보내진다. 컨트롤러(3950)는 CCB 태그(3956)를 물리적 DRAM 어드레스로 변환하고 물리적 DRAM 어드레스와 관련된 DRAM(3791)으로부터 CCB를 펫치할 것이다.

COMMIT 커맨드(3956C)는 버퍼(3940)의 컨텐트를 CCB 태그(3956)와 관련된 DRAM(3791)에 있는 물리적 어드레스로 쓴다. COMMIT 커맨드(3956C)는 또한 컨트롤러(3950)로 하여금 다른 CCB로의 할당에 사용되지 않도록 버퍼(3940)를 할당 해제한다. 하지만, 다른 SPU(3410)는 동일한 CCB 태그(3956)에 대한 버퍼 할당을 나중에 요청할 수 있다. 컨트롤러(3950)는 만일 CCB가 아직 버퍼(3940) 중에 하나에 존재한다면 버퍼(3940)에 현재 지정된 존재하는 CCB를 사용한다.

DROP 커맨드(3944)는 컨트롤러(3950)에게 특정 CCB 태그(3956)와 관련된 특정 버퍼(3940)의 컨텐트를 버리도록 알린다. 컨트롤러(3950)는 외부 DRAM(3791)으로 버퍼 컨텐트를 로딩하는 일 없이 CCB 캐쉬(3450)에 있는 버퍼(3940)를 단순히 할당 해제함으로써 CCB를 버린다.

READ 및 WRITE 명령(3948)은 CCB 캐쉬(3450)와 SPU(3410) 간에 CCB 데이타 전송에 사용된다. READ 및 WRITE 명령은 버퍼(3940)가 미리 할당되었을 때 SPU(3410)와 CCB 캐쉬(3450) 간에 데이타 전송만을 허용한다.

만일 사용가능한 버퍼(3940)가 현재 사용 중이면, SPU(3410) 중의 하나는 현재 ALLOCATE 커맨드가 CCB 캐쉬(3450)에 의해 서비스될 수 있기 전에 현재 사용되는 버퍼(3940) 중의 하나를 COMMIT 해야할 것이다. 컨트롤러(3950)는 어떤 버퍼(3940)가 서로 다른 CCB 어드레스에 지정되었는지 끊임없이 정보를 추적한다. SPU(3410)는 현재 할당된 버퍼(3940)의 숫자를 계속 카운트하기만 하면 된다. 만일 카운트 숫자가 사용가능한 버퍼(3940)의 전체 수에 이르면, SPU(3410) 중의 하나는 버퍼(3940) 중의 하나를 풀어주기 위해 COMMIT 혹은 DROP 명령을 내어 줄 것이다. 한 실시예에서, SPU(3410)의 버퍼(3940)보다 적어도 두 배 숫자의 버퍼가 있다. 이는 모든 SPU(3410)가 동시에 두 개의 사용가능한 버퍼를 가지는 것을 가능하게 한다.

CCB 캐쉬(3450)에서의 동작이 소프트웨어 컨트롤 하에서 이루어지므로, SPU(3410)들은 버퍼(3940)가 언제 풀려 놓여지는지 그리고 언제 외부 메모리(3791)로 데이타를 전송할 것이지를 컨트롤한다. 더불어 CCB를 위해 초기에 버퍼(3940)를 할당하는 하나의 SPU는 LOAD 커맨드를 내어 놓는 SPU(3410)와 다르고 혹은 COMMIT 혹은 DROP 커맨드를 내어 놓는 것에 의해 버퍼(3940)를 궁극적으로 풀어 주는 SPU(3410)와도 다르다.

커맨드(3944)들은 CCB 캐쉬(3450)와 DRAM(3791) 간의 완벽한 데이타 전송의 소프트웨어 컨트롤을 허용한다. 이는 이는 패킷 데이타가 하나 이상의 SPU(3410)에 의해 프로세스될 때와 패킷 프로세싱 중 특정 CCB 가 더 이상 DRAM(3791)으로 로드 되거나 이로부터 읽혀질 필요가 없다는 것이 판단되는 때에 상당한 장점을 가진다. 예를 들면, SPU(3410) 중 하나는 패킷 프로세싱 중 패킷인 틀린 체크섬 값을 가진다는 것을 판단할 수 있다. 패킷은 패킷을 DRAM(3791)로 로딩하는 것 없이 CCB 버퍼(3940)로부터 DROPPED 될 수 있다.

한 실시예에서 버퍼(3940)는 캐쉬 라인으로 구현된다. 그러므로, 오직 하나의 캐쉬 라인이 외부 DRAM 메모리(3791)로 다시 씌여질 필요가 있다. 한 실시예에서는, 캐쉬 라인은 512 바이트이고 워드는 64 바이트 길이이다. 컨트롤러(3950)는 어떤 캐쉬 라인이 변경되었는지를 인식할 수 있고 COMMIT 커맨드 동안 단지 버퍼(3940)에서 변경된 캐쉬 라인에 다시 쓰게 된다.

도 36은 TCP 세션을 프로세싱할 때 어떻게 CCB가 사용되는 지의 예를 보여준다. 시맨틱 프로세서(3100)(도 23)는 어떤 종류의 데이타를 프로세싱하기 위해 사용될 수 있다. 하지만, TCP 패킷(3960)은 설명의 목적 상 도시된다. 이 예에서 패킷(3960)은 이더넷 헤더(3962), IP 헤더(3964), IP 소스 어드레스(3966), IP 목적지 어드레스(3968), TCP 헤더(3970), TCP 소스 포트 어드레스(3972), TCP 목적지 포트 어드레스(3974) 및 패이로드(3976)를 포함한다.

직접 실행 파서(3180)는 하나 이상의 SPU(3410)로 하여금 IP 헤더(3964)로부터 소스 어드레스(3966) 및 목적지 어드레스(3968)를 얻도록 그리고 TCP 헤더(3970)으로부터 TCP 소스 포트 어드레스(3972) 및 TCP 목적지 포트 어드레스를 얻도록 명령한다. 이 어드레스들은 입력 버퍼(3140)에 위치할 것이다(도 23).

SPU(3410)는 네 개의 어드레스 값 3966, 3968, 3972 및 3974를 AMCD(3430)에 있는 CCB 검색 테이블(3978)로 보낸다. 검색 테이블(3978)은 IP 소스 어드레스 필드(3980)의 어레이, IP 목적지 어드레스 필드(3982), TCP 소스 포트 어드레스 필드(3984) 및 TCP 목적지 포트 어드레스 필드(3986)를 포함한다.

AMCD(3430)는 네 개의 어드레스 값 3966, 3968, 3972 및 3974를 CCB 검색 테이블(3978)에 있는 네 개의 엔트리와 매치하려고 한다. 만약 매치가 없다면, SPU(3410)는 패킷(3960)과 관련된 TCP 세션에 대해 새로운 CCB 태그(3979)를 할당할 것이고 네 개의 어드레스 값은 테이블(3978)로 씌여질 것이다. 매치가 발견되면, AMCD(3430)는 어드레스의 매칭을 위해 CCB 태그(3979)를 되돌려 준다.

만일 CCB 태그(3979)가 되돌아 오면, SPU(3410)는 패킷의 후속 프로세싱을 위해 되돌아온 CCB 태그(3979)를 사용한다. 예를 들면, SPU(3410)는 패킷(3960)으로부터의 특정 헤더 정보를 CCB 캐쉬(3450) 내에 위치한 CCB로 로드할 것이다. 더불어, SPU(3410)는 패킷(3960)으로부터 패이로드 데이타를 스트리밍 캐쉬(3470)로 전송할 것이다(도 30).

도 37은 CCB(3990)에 포함될 몇몇의 컨트롤 정보를 보여준다. CCB(3990)는 세션 ID(3994)와 더불어 CCB 태그(3992)를 포함할 것이다. 세션 ID(3994)는 TCP 세션을 위해 소스 및 목적지 어드레스를 포함할 것이다. CCB(3990)는 또한 패킷 패이로드 데이타를 담고 있는 외부 메모리(3791) 내의 위치를 식별하는 링크된 리스트-포인터(3996)를 포함할 것이다. CCB(3990)는 또한 TCP 시퀀스 넘버(3990) 및 승인(ACK) 넘버(4000)를 포함할 수 있다. CCB(3990)는 TCP 세션을 프로세스하기 위해 필요한 다른 모든 파라미터를 포함할 수 있다. 예를 들면, CCB(3990)는 수신 윈도 우 필드(4002), 전송 윈도우 필드(4004) 및 타이머 필드(4006)를 포함할 수 있다.

모든 TCP 컨트롤 필드는 동일한 관련 CCB(3990)에 위치한다. 이는 SPU(3410)가 CCB 캐쉬(3450)에 있는 동일한 CCB 버퍼(3940)로부터 같은 TCP 세션에 대한 모든 관련 CCB(3990)를 빠르게 액세스하도록 허용한다. 더욱이, CCB 캐쉬(3450)는 소프트웨어에 의해 컨트롤되기 때문에, SPU(3410)는 모든 필요한 프로세싱이 모든 서로 다른 SPU(3410)에 의해 완결될 때까지 CCB 캐쉬(3450) 내의 CCB(3990)을 보존할 수 있다.

서로 다른 OSI 레이어와 관련된 CCB(3990)에 있을 수 있다. 예를 들면, SCSI 세션과 관련되어 할당된 CCB(3990) 및 SCSI 세션 내에 TCP 세션과 관련되고 이 세션을 위해 할당된 다른 CCB(3990)이 있을 수 있다.

도 38은 언제 SPU(3410)가 버퍼(3940)에 있는 CCB 컨텐트를 프로세싱하는 것을 끝마치는지 그리고 언제 버퍼(3940)가 다른 SPU에 의해 액세스를 위해 풀려서 사용 가능한지를 나타내도록 CCB 캐쉬(3450)에서 플래그(4112)가 사용되는 지를 보여준다.

IP 패킷(4100)은 프로세싱 시스템(3100)에 의해 수신된다(도 23). IP 패킷(4100)은 IP 헤더(4102), TCP 헤더(4104) 및 iSCSI 헤더(4106)를 포함하는 헤더 섹션을 갖는다. IP 패킷(4100)은 또한 패킷 데이타를 포함하는 패이로드(4108)를 포함한다. 파서(3180)(도 23)는 SPU(3410)로 하여금 다른 IP 헤더(4102) 내의 정보, TCP 헤더(4104), iSCSI 헤더(4106) 및 패이로드(4108)에 있는 데이타를 프로세스하도록 명령한다. 예를 들면, 첫번째 SPU #1은 IP 헤더 정보(4102)를 프로세스하 고, SPU #2는 TCP 헤더 정보(4104)를 프로세스하고, SPU #3은 iSCSI 헤더 정보(4106)를 프로세스한다. 다른 SPU #N은 패킷 패이로드(1108)를 스트리밍 캐쉬(3470)에 있는 버퍼(4114)로 로드하도록 지시할 것이다. 물론 SPU(3410)의 어떤 조합도 IP 패킷(4100)에 있는 어떤 헤더와 페이로드 정보를 프로세스할 수 있다.

IP 패킷(4100)에 있는 모든 헤더 정보는 동일한 CCB(4110)과 관련될 수 있다. SPU 1-3은 CCB 캐쉬(3450)를 통해 CCB(4110)를 저장하고 액세스한다. CCB(4110)는 또한 완결 비트 마스크(completion bit mask, 4112)를 포함한다. SPU(3410)는 작업이 완결된 때에 완결 마스크(4112)의 비트를 논리적으로 OR 시킨다. 예를 들면, SPU #1은 IP 헤더(4102)의 프로세싱이 CCB(4110)에서 완결되는 때에 완결 비트 마스크(4112)에서 첫번째 비트를 세트할 것이다. SPU #2는 TCP 헤더에 대한 프로세싱이 완결되는 때에 완결 비트 마스크(4112)에 있는 두번째 비트를 세트할 것이다. 완결 비트 마스크(4112) 내의 모든 비트가 세트되면 이는 IP 패킷(4110) 상의 SPU 프로세싱이 완결되었다는 것을 나타낸다.

그러므로, 패이로드(4108)에 대한 프로세싱이 완결된 때에, SPU #N은 완결 마스크(4112)를 체크한다. 만일 마스크(4112) 내의 모든 비트가 세트되면, SPU #N은 예를 들어 CCB 캐쉬(3450)로 하여금 CCB(4110)를 포함하는 캐쉬 라인의 컨텐트를 외부 DRAM 메모리(3791)로 COMMIT 하도록 지시하는 CCB 캐쉬(3450)(도 34)로 COMMIT 커맨드를 보낸다.

스트리밍 캐쉬

도 39는 스트리밍 캐쉬를 좀더 상세하게 보여준다. 실시예에서, 스트리밍 캐 쉬(3470)는 DRAM(3791)로부터 데이타를 전송하고 수신하는데 사용되는 복수의 버퍼(4200)를 포함한다. 일 예에서 버퍼(4200)는 256 바이트 길이이고 각각의 캐쉬 라인은 태그 필드(4202), VSD 필드(4204) 및 버퍼의 64 바이트 일부를 포함한다. 그리하여, 4개의 캐쉬 라인이 각각의 버퍼(4200)와 관련된다. 구현 예에서 스트리밍 캐쉬(3470)는 각각의 SPU(3410)에 대해 두 개의 버퍼(4200)를 포함한다.

VSD 필드(4204)는 유효/무효(valid/invalid)로서 캐쉬 라인을 나타내는 "유효(Valid)" 값, 오염된(dirty) 혹은 깨끗한(clear) 캐쉬 라인인지를 나타내는 Status(S) 값, 읽기(READ), 쓰기(WRITE) 혹은 병합 없음 조건(NO MERGE CONDITION)을 나타내는 Direction(D) 값을 포함한다. 특별히 흥미있는 것 중의 하나는 캐쉬 컨트롤러(4206)에 의해 수행되는 프리-펫치(pre-fetch) 동작이다. 물리적 어드레스(4218)는 DRAM(3791)으로부터 읽기(READ)를 요청하는 SPU(3410) 중의 하나로부터 컨트롤러(4206)에 보내진다. 컨트롤러(4206)는 물리적 어드레스와 캐쉬 라인(4210)과 같은 캐쉬 라인 중의 하나를 관련시킨다. 스트리밍 캐쉬 컨트롤러(4206)는 버퍼(4200) 내의 동일한 FIFO 순서 바이트와 관련된 3개의 다른 64 바이트 캐쉬 라인 4212, 4214 및 4216에 대한 프리-펫치(pre-fetch, 4217)를 자동적으로 수행한다.

프리-펫치(pre-fetch, 4217)의 중요한 측면은 태그 필드(4202)가 다른 버퍼(4200)와 관련되는 방법에 있다. 태크 필드(4202)는 특정 버퍼(4200)를 식별하기 위해 컨트롤러(4206)에 의해 사용된다. 태그 필드(4202)와 관련된 물리적 어드레스(4218) 부분은 컨트롤러(4206)에 의해 버퍼(4200)가 주위의 물리적 어드레스 위치를 포함하지 않도록 선택된다. 예를 들면, 컨트롤러(4206)는 태크 필드(4202)와 관련되기 위해 물리적 어드레스(4218)의 중간 순서 비트(4220)를 사용할 것이다. 이는 3 개의 주변 캐쉬 라인(4212, 4214 및 4216)의 프리-펫치(4217)가 캐쉬 라인(4210)과 관련된 스트리밍 데이타 동작과 충돌하는 것을 피하도록 해준다.

예를 들면, SPU(3410) 중의 하나는 패킷 데이타가 DRAM 메모리(3791)로부터 특정 버퍼(4200)와 관련되는 첫번째 캐쉬 라인(4210)으로 로드되어야 할 것을 요구하는 관련된 물리적 어드레스(4218)를 갖는 스트리밍 캐쉬로 커맨드를 전송할 것이다. 버퍼(4200)는 물리적 어드레스(4218)의 일부와 관련되는 태그 값(4202)을 갖는다. 컨트롤러(4206)는 동일한 버퍼(4200)와 관련된 캐쉬 라인 4212, 4214 및 4216을 로드하기 위한 프리-펫치 동작(1217)을 수행하려고 할 것이다. 하지만, 프리-펫치(4217)는 버퍼(4200)가 이미 SPU(3410)에 의해 사용되고 있기 때문에 스톨(stall)된다. 더군다나, 프리-펫치(pre-fetch) 동작(4217)이 완결되도록 허가되었을 때, 이들은 다른 SPU 커맨드에 의거해 이미 로드된 버퍼(4200)에 캐쉬 라인을 덮어 쓸 수 있다.

물리적 어드레스(4218)의 중간 순서 비트(4220)으로부터 태그 값(4202)을 얻음으로써, 각각의 일련의 256 바이트 물리적 어드레스 경계는 다른 메모리 버퍼(4200)에 위치할 수 있을 것이고, 그럼으로 인해 프리-펫치 동작 동안 충돌을 피할 것이다.

AMCD

도 40은 도 28의 AMCD(3430)의 예시적 실시예의 기능적 블럭도를 나타낸다. SPU 클러스터(4012)는 ARM(4014)이 SPU 클러스터(4012)에서 SPU(3710)를 통해 AMCD(3430)로 통신하는 동안 AMCD(3430)에 직접 통신한다. AMCD(3430)는 SPU(3410)를 위한 메모리 검색 설비를 제공한다. 한 예로, SPU(3410)는 예를 들면 외부 DRAM(3791, 도 28) 내에서와 같이 메모리 내에서 앞서 저장된 엔트리가 어디에 저장되었는지를 판단한다. AMCD(3430) 내의 검색 설비는 네트워크 시스템이 어디 있던 간에 어디에 데이타가 저장되었는지를 검색하며 외부 DRAM(3791)에 제한되지 않는다.

시스템이 논-러닝(non-learning) 모드에 있는 경우, SPU(3410)는 자기 자신의 메모리 맵핑 테이블을 보존하고, SPU는 엔트리 부가, 삭제 및 수정을 통해 그 테이블을 관리한다. 시스템이 러닝(learning) 모드에 있을 때, SPU(3410)는 엔트리를 부가하는 동안 TCAM 메모리를 탐색하거나 혹은 엔트리를 삭제하는 동안 TCAM 메모리를 탐색하는 커맨드를 수행함으로서 테이블을 유지한다. 키 값은 어느 한 모드에서 이러한 다른 종류의 탐색을 수행하는데 있어 SPU(3410)에 의해 사용된다.

도 40의 AMCD(3430)는 일련의 검색 인터페이스(LUIFs)(4062)를 포함한다. 실시예에서, AMCD(3430)내에 8 개의 LUIF(4062)가 있다. LUIF 예에 대한 상세한 설명이 이루어질 터인데, 일련의 64 비트 레지스터(4066)를 포함한다. 레지스터(4066)는 메모리 검색을 구현하기 위한 데이타와 커맨드에 대한 메모리를 제공하고, 검색 결과는 또한 레지스터(4066)를 통해 되돌려진다. 실시예에서, 검색 커맨드를 위한 한 개의 64 비트 레지스터와 데이타 저장을 위한 7 개의 64 비트 레지스터가 있다. 모든 레지스터가 사용되어야 할 필요가 있는 것은 아니다. 본 발명의 실시예에서, SPU 클러스터(4012) 및 LUIF(4062) 간의 통신 인터페이스는 64 비트 길이인데, 이 는 LUIF(4062)에 64 비트 레지스터를 포함하기 편리하도록 해 준다. 예시적 커맨드 구조는 도 41에 나타나 있는데, 이것의 컨텐트는 이하에서 설명될 것이다.

설계된 시스템에서 한정된 LUIF(4062)가 있기 때문에, 그리고 LUIF는 한 번에 한 개 이상의 SPU(3410)에 의해 액세스 될 수 없기 때문에, SPU(3410)로 프리(free) LUIF를 할당하는 메커니즘이 있게 된다. 프리 리스트(free list, 4050)는 LUIF(4062)의 사용을 관리한다. SPU(3410)가 LUIF(4062)를 액세스하기를 원할 때, SPU는 어떤 LUIF(4062)가 사용되고 있는 지를 판단하기 위해 프리 리스트(4050)를 읽는다. 프리 리스트(4050)를 읽은 후에, 다음 사용 가능한 프리(free) LUIF의 어드레스가 LUIF(4062)가 사용될 수 있다는 것을 나타내는 값과 함께 리턴된다. 만일 LUIF(4062)에 대해 리턴된 값이 유효하면, SPU(3410)는 그 LUIF를 안전하게 컨트롤할 수 있다. 그 다음 엔트리가 프리 리스트(4050)에서 만들어지고 첫번째 SPU가 LUIF를 풀어 줄 때까지 특정 LUIF는 다른 어떤 SPU(3410)에 의해서도 사용될 수 없다. 첫번째 SPU(3410)가 탐색을 끝마치고 탐색 결과를 되돌려 받은 후, SPU는 사용된 LUIF 식별자를 프리 리스트(4050) 상에 올려 놓고, LUIF는 다른 SPU(3410)에 의해 다시 사용 가능하게 된다. 만일 프리 리스트(4050)에 프리 LUIF(4062)가 없을 때에는, 요청 SPU(3410)에게 프리 LUIF가 없다는 것이 통보되고 SPU는 나중에 프리 LUIF(4062)를 나중에 얻기를 시도하도록 강제한다. 프리 리스트(4050)는 SPU(3410)가 프로세스되어야 할 다른 SPU 요청을 기다리는 동안 인덱스 로딩을 시작할 것을 허락하는 파이프라인 기능을 제공한다.

선택된 LUIF는 아래에서 설명하는 바와 같이 아비터(4068)에게 검색 커맨드 와 데이타를 보낸다. 아비터(4068)는 어떤 특정 LUIF(4062)가 특정 TCAM 컨트롤러를 액세스하는지를 선택한다. 설명된 실시예에서, 외부 TCAM 컨트롤러(1072) 및 내부 TCAM 컨트롤러(4076)가 있다. 외부 TCAM 컨트롤러(4072)는 외부 TCAM에 연결되는데, 외부 TCAM은 다시 외부 SRAM(4092)에 연결된다. 유사하게, 내부 TCAM 컨트롤러(4076)는 내부 TCAM(4096)에 연결되는데, 이는 다시 내부 SRAM(4086)에 연결된다.

전형적으로, 오직 하나의 TCAM, 즉, 내부 TCAM(4096) 혹은 외부 TCAM(4082) 중 하나만이 전체 시간 동안 시스템에서 능동 상태일 것이다. 다른 말로 하면, 만일 시스템이 외부 TCAM 및 SRAM 4082, 4092를 포함하면, AMCD(3430)는 이 외부 메모리와 통신한다. 유사하게, 만일 시스템이 외부 TCAM과 SRAM 메모리 4082, 4092를 포함하지 않는다면, AMCD(3430)는 오직 내부 TCAM 및 내부 SRAM(4086)과만 통신한다. 아래와 같이, 외부 메모리가 있는냐에 따라 오직 하나의 TCAM 컨트롤러(4076 또는 4072)만이 사용될 것이다. AMCD(3430)에 의해 사용되지 않는 특정 컨트롤러(4072, 4076)는 셋업 프로세스에서 턴-오프 될 것이다. 실시예에서, 셋업 커맨드는 외부 TCAM(4082)가 있는지를 나타내는 시스템 초기화 시 AMCD(3430)로 보내진다. 만일 외부 TCAM(1082)가 있다면, 내부 TCAM 컨트롤러(4076)는 턴-오프되고, 외부 TCAM 컨트롤러(4072)가 사용된다. 반대로, 만일 외부 TCAM(4082)가 존재하지 않는다면, 외부 TCAM 컨트롤러는 턴-오프되고, 내부 TCAM 컨트롤러(4076)가 사용된다. 비록 단순성을 위해 오직 하나의 TCAM 컨트롤러, 즉, 4076 이나 4072 만을 사용하는 것이 바람직하지만, AMCD(3430)는 TCAM 컨트롤러 4076 및 4072 양쪽 모두가 구현될 수 있다.

예시적 실시예에서, 내부 SRAM(4086)처럼 내부 TCAM(4096)은 512 엔트리를 포함한다. 다른 실시예에서는, 외부 TCAM(4082)는 매칭되는 외부 SRAM(4092)에서의 엔트리 수와 더불어 64k 엔트리부터 256k 엔트리를 포함한다(엔트리는 72 비트이고 72 비트 보다 더 긴 탐색을 생성하기 위해 복수 엔트리가 합해질 수 있다). SRAM(4086, 4092)은 전형적으로는 20 비트 길이임에 반해 TCAM(4082, 4086)는 훨씬더 길다. 내부 TCAM(4096)은 예를 들면, 164 비트 길이일 수 있는데, 그에 반해 외부 TCAM(4082)는 72와 448 비트 길이 사이의 범위에 있을 수 있다.

SPU(3710)가 검색을 실행하는 때에, 위에서 설명한 바와 같이 SPU는 패킷 데이타로부터 키를 생성한다. SPU(3410)는 LUIF(4062) 중의 하나를 남겨두고 그 다음 커맨드와 데이타를 LUIF(4062)의 레지스터(4066)로 데이타를 로드한다. 커맨드와 데이타가 로드되는 때에, TCAM 4096 혹은 4082 중 하나에서 탐색이 시작된다. 레지스터(4066)로부터의 커맨드는 아비터(4068)로 넘겨지는데, 아비터는 데이타를 적절한 TCAM 4096, 4082에 보내준다. 예를 들어 외부 TCAM(4082)이 존재하고 사용중이라고 가정하자. TCAM 커맨드를 위해, SPU(3410)에 의해 보내진 데이타는 외부 TCAM 컨트롤러(4072)에 제시되는데, 외부 TCAM 컨트롤러는 그 데이타를 외부 TCAM(4082)에 제시한다. 외부 TCAM(4082)이 키 데이타의 매치를 찾는 때에, 대응되는 데이타는 외부 SRAM(4092)로부터 꺼내진다. 몇몇 실시예에서, SRAM(4092)는 TCAM에 저장된 키 값에 의해 인데스된 원하는 데이타를 포함하는 메모리 위치를 가리키는 포인터를 저장한다. SRAM(4092)으로부터의 포인터는 원래의 요청 SPU(3410)에 의해 사 용되는 원래의 LUIF(4062)의 레지스터(4066)를 통해, 요청하는 SPU(3410)로 리턴된다. SPU(3410)가 포인터 데이타를 받은 후에, SPU는 다른 SPU(3410)에 의해 사용되도록 프리 리스트(4050)로 어드레스를 돌려 놓음으로써 LUIF(4062)를 풀어 준다. LUIF(4062)는 이러한 방법으로, DRAM(3791) 혹은 시스템에 있는 어떤 메모리 상에라도 탐색, 쓰기, 읽기 혹은 표준 유지보수 동작을 위해 사용될 수 있다.

이러한 방법을 사용하여, TCAM 4082와 4096이 CCB DRAM(3791B)에서의 빠른 검색을 위해 사용된다(도 30). TCAM 4082 및 4096은 또한 많은 수의 세션이 동시에 IPv6를 위한 CCB에 대해 검색되는데 필요한 경우의 애플리케이션에서 사용될 수 있다. TCAM 4082 및 4096은 다른 IP 세션을 위해 포트 어드레스를 검색하는데 필요한 정적 루트 테이블을 구현하기 위해 사용될 수도 있다.

일련의 설정 레지스터 테이블(configuration register table)(4040)이 메모리 검색을 행하는데 있어 SPU(3410)에 의해 보내진 키 값들과 연결되어 사용된다. 실시예에서, 16 개의 테이블 엔트리가 있는데, 각각은 4 비트의 구별자, 0000-1111에 의해 인덱스 된다. 예를 들면, 설정 테이블(4040)에 저장된 데이타는 요청된 검색에서 키 크기를 포함할 수 있다. 64, 72, 128, 144, 164, 192, 256, 288, 320, 384 및 448 등의 다양한 크기의 키가 사용된다. 특정 키 크기 및 키 데이타가 탐색될 장소 및 다른 다양한 데이타가 설정 테이블(4040)에 저장된다. 도 41을 참조하면, 비트 위치 19:16에 테이블 식별자 번호가 나타나는데, 이는 설정 테이블(4040)에서 어떤 값이 사용될지를 나타낸다.

도 42는 아비터(4068)의 예를 보여준다. 아비터(4068)는 각각의 LUIF(4062) 및 내부와 외부 TCAM 컨트롤러(4076, 4072) 양쪽에 연결된 선택 MUX(4067)에 연결된다. 앞에서 설명한 바와 같이, 본 발명의 실시예에서, 오직 하나의 TCAM 컨트롤러(4076 혹은 4072)가 한 시점에서 능동 상태가 되는데, 이 컨트롤러는 시작 시점에서 선택 MUX(4067)에 보내진 신호에 의해 컨트롤된다. 이 실시예에서, 아비터(4068)는 출력 신호가 내부(4076)에 보내지는지 혹은 외부 TCAM 컨트롤러(4072)에 보내지는지 구별하지 않는다. 대신에, 아비터(4068)는 출력 신호를 선택 MUX(4067)로 단순히 보내고, MUX는 MUX로의 셋업 값의 상태 입력에 기초하여 적절한 TCAM 컨트롤러(4076, 4072)로 검색 요청 방향을 잡는다.

아비터(4068)의 기능은 도 42의 LUIF-1 에서 LUIF-8까지 표시가 붙은 LUIF(4062) 중 어떤 것이 선택된 TCAM 컨트롤러(4076 혹은 4072)에 의해 다음 번에 서비스될지를 선택하는 것이다. 가장 단순한 형태로의 아비터(4068)는 단순한 라운드 로빈 아비터로 구현될 수 있는데, 이 때 각각의 LUIF(4062)는 연속으로 선택된다. 좀더 복잡한 시스템에서는, 아비터(4068)는 아래에서 설명되는 바와 같이 어떤 LUIF(4062)가 다음에 선택되어야 하는지를 설명하는 우선 순위(priority) 값을 지정하기 위해 지나간 히스토리를 사용한다.

좀더 지능적인 아비터(4068)에서, 우선 순위 시스템은 어떤 LUIF(4062)가 가장 최근에 사용되었는지를 나타내고, 이를 어떤 LUIF(4062)를 다음 검색 동작을 위해 선택할 것인지의 결정에 고려 사항으로 넣는다. 도 43은 지능적인 아비터(4068) 예에서의 아비트래이션(arbitration) 예를 보여준다. Time A에서 각각의 우선 순위(priority) 값들은 이미 값 "0"으로 초기화되어 있고 LUIF-2 및 LUIF-7 양쪽은 동작 계류(operation pendint) 상태이다. 아비터(4068)가 한 시점에서 오직 하나의 LUIF를 선택하기 때문에, LUIF-3은 임의로 선택되는데 이는 모든 LUIF가 동작 계류 상태이고 같은 우선 순위를 갖기 때문인데, 이 경우는 "0" 이다. 일단 LUIF-3이 선택되면, 그것의 우선 순위는 1로 세트된다. Time B에서는 LUIF-3은 새로운 동작 계류 상태를 가지고, 반면에 LUIF-7은 아직 실행되지 못한 동작을 가진다. 아비터(4068)는 이 경우에 LUIF-7을 선택하는데, 이는 아비터가 LUIF-3 보다 더 높은 우선 순위를 가지기 때문이다. 이는 각각의 LUIF(4062) 들에 의한 공정한 사용 및 어떤 LUIF도 검색 시간을 독점하지 않는다는 것을 보장해준다.

Time C에서, LUIF-1 및 LUIF-3은 동작 계류(operation pending) 중이고, 아비터(4068)는 비록 LUIF-3 에서의 동작이 더 길게 계류 중임에도 불구하고 LUIF-1이 더 높은 순위를 갖기 때문에 LUIF-1을 선택한다. 최종적으로, Time D에서는 오직 LUIF-3만이 동작 계류 중이고 아비터(4068)는 LUIF-3을 선택하고 우선 순위를 "2"까지로 옮긴다.

이러한 방법으로, 아비터(4068)는 지능적인 라운드 로빈 아비트래이션을 구현한다. 다른 말로 하면, 일단 특정 LUIF(4062)가 선택되면, 이 LUIF는 라인의 마지막으로 옮겨가고 동작 계류 중인 모든 다른 LUIF는 특정 LUIF가 다시 선택되기 전에 서비스된다. 이는 각각의 LUIF(4062)가 그 검색에 사용하는 시간을 동등하게 하고, 어떤 특정 LUIF도 모든 검색 대역을 독점하지 못하도록 보장한다.

위에서 상술된 시스템은 전용 프로세서 시스템, 마이크로 컨트롤러, 프로그래머블 논리 장치 혹은 일부 혹은 전체 동작을 수행하는 마이크로 프로세서를 사용 할 수 있다. 위에서 설명된 몇몇 동작은 소프트웨어로 구현될 수 있을 것이고 다른 동작은 하드웨어로 구현될 수 있을 것이다.

당업자는 본 발명의 범위 내에서 다른 기능 분리(partition)가 가능하다는 것을 인식할 것이다. 더욱이 어떤 기능이 보통의 집적 회로 상에 구현되는지 혹은 구현되지 않는지는 애플리케이션마다 다를 것이다.

마지막으로, 비록 본 명세서는 여러 군데서 일, 한, 다른, 몇몇 실시예라고 지칭하고 있으나, 이는 그러한 참조가 동일한 실시예를 뜻한다거나 혹은 특징이 단일 실시예에만 적용된다는 것을 의미하는 것은 아니다.

Claims (14)

1. 저장 서버로서,

   데이타 동작을 위해 클라이언트 요청을 수신하기 위한 데이타그램 인터페이스;

   하나 이상의 데이타 저장 장치를 액세스하기 위한 저장 인터페이스; 및

   저장된 문법에 기초하여 상기 저장 인터페이스를 통해 상기 하나 이상의 데이타 저장 장치와 응답 데이타 동작을 처리하기 위해 수신된 클라이언트 요청을 파싱할 수 있는 성능을 가진 시맨틱 프로세서(semantic processor)를 포함하는 것을 특징으로 하는 저장 서버.
2. 제1항에 있어서, 상기 시맨틱 프로세서는 상기 데이타그램 인터페이스에서 수신된 데이타그램으로부터 심볼을 파스(parse)하기 위한 직접 실행 파서와 상기 직접 실행 파서에 의한 지시대로 데이타 동작을 수행하기 위한 다수의 시맨틱 코드 실행 엔진을 포함하는 것을 특징으로 하는 저장 서버.
3. 제1항에 있어서, 상기 상기 데이타그램 인터페이스에서 수신된 데이타그램으로부터 심볼을 파스하기 위한 직접 실행 파서와 상기 파스된 데이타그램에서 데이타 동작을 수행하기 위한 마이크로프로세서를 포함하는 것을 특징으로 하는 저장 서버.
4. 제1항에 있어서, 상기 시맨틱 프로세서는 스택 심볼에 의거하여 상기 데이타그램 인터페이스에서 수신된 데이타그램으로부터 심볼을 파스하기 위해 파서 스택(parser stack)을 가진 직접 실행 파서와 상기 직접 실행 파서에 의해 지시대로 데이타 동작을 수행하기 위한 하나 이상의 시맨틱 코드 실행 엔진을 포함하되, 상기 시맨틱 코드 실행 엔진은 상기 파서 스택의 컨텐트를 수정함으로써 상기 직접 실행 파서 동작을 변경할 수 있는 것을 특징으로 하는 저장 서버.
5. 제1항에 있어서, 상기 하나 이상의 데이타 저장 장치는 인클로져(enclosure)를 갖는 디스크 드라이브이고, 상기 데이타그램 인터페이스, 저장 인터페이스 및 시맨틱 프로세서는 상기 디스크 드라이브 인클로져에 패키지화되어 있는 것을 특징으로 하는 저장 서버.
6. 제1항에 있어서, 상기 저장 인터페이스는 제 2 데이타그램 인터페이스이고 하나 이상의 데이타 저장 장치는 상기 제 2 데이타그램 인터페이스에 의해 원격으로 액세스되며, 또한 상기 저장 서버는 상기 저장 서버에 의해 수신된 클라이언트 요청을 담당하기 위해 하나 이상의 데이타 저장 장치의 클라이언트로서 동작할 수 있는 것을 특징으로 하는 저장 서버.
7. 제1항에 있어서,

   데이타 동작을 위해 클라이언트 요청을 수신하기 위한 제 2 데이타그램 인터페이스; 및

   상기 시맨틱 프로세서가 상기 두 개의 데이타그램 인터페이스로부터의 파싱 데이타그램 심볼들 간을 스위치할 수 있도록 허용하기 위한 파서 소스 선택자를 더 포함하는 것을 특징으로 하는 저장 서버.
8. 제1항에 있어서,

   상기 저장된 문법의 적어도 일부를 수용하기 위한 재설정 가능(reconfigurable) 메모리를 더 포함하되, 상기 저장 서버는 적어도 두 개의 서로 다른 저장 서버 프로토콜 세트를 갖는 저장 서버로 기능할 수 있도록 재설정 가능한 것을 특징으로 하는 저장 서버.
9. 버퍼에서 시맨틱하게(semantically) 데이타를 파싱함에 의해 디지털 데이타의 처리를 제어하도록 구성된 직접 실행 파서;

   상기 직접 실행 파서에 의해 촉구될 때 데이타 동작을 행하도록 구성된 시맨틱 프로세싱 유닛; 및

   시맨티 프로세싱 유닛에 의해 지시되었을 때 상기 디지털 데이타를 처리하도록 구성된 메모리 서브 시스템을 포함하는 것을 특징으로 하는 장치.
10. 제9항에 있어서, 상기 메모리 서브 시스템은 메모리와 상기 시맨틱 프로세싱 유닛 간에 연결된 다수의 메모리 캐쉬를 포함하는 것을 특징으로 하는 장치.
11. 제9항에 있어서, 상기 메모리 서브 시스템은 상기 시맨틱 프로세싱 유닛에 의해 지시된 때에 디지털 데이타 상에 암호 동작을 수행하기 위해 암호 회로를 포함하는 것을 특징으로 하는 장치.
12. 제9항에 있어서, 상기 메모리 서브 시스템은 상기 시맨틱 프로세싱 유닛에 의해 지시된 때에 검색(look-up) 기능을 수행하기 위해 탐색(search) 엔진을 포함하는 것을 특징으로 하는 장치.
13. 제9항에 있어서, 상기 버퍼는 외부 네트워크로부터 상기 직접 실행 파서에 의해 파싱되어야 할 데이타를 수신하는 것을 특징으로 하는 장치.
14. 제9항에 있어서, 상기 버퍼는 상기 시맨틱 프로세싱 유닛으로부터 상기 직접 실행 파서에 의해 파싱되어야 할 데이타를 수신하는 것을 특징으로 하는 장치.

Images