KR102312648B1

KR102312648B1 - 채널 통신 프로토콜, 그것을 지원하는 메모리 모듈, 및 시스템

Info

Publication number: KR102312648B1
Application number: KR1020160027108A
Authority: KR
Inventors: 이안 스와브릭; 마이클 베커맨; 크레이그 핸손; 치젱 창
Original assignee: 삼성전자주식회사
Priority date: 2015-05-07
Filing date: 2016-03-07
Publication date: 2021-10-15
Also published as: KR20160131870A; CN106126447B; TWI699649B; TW201640358A; US20160328156A1; US10025747B2; CN106126447A

Abstract

본 발명의 실시 예에 따른 채널 통신 프로토콜 방법은 스토리지 장치가 호스트에 의해 지원되는 I/O(Input/Output) 인터페이스에 결합되었는지 판별(Detect)하는 단계; 판별 결과에 반응하여, 데이터 패턴들의 제 1 시퀀스를 I/O 인터페이스를 사용하여 스토리지 장치에 쓰도록 호스트에 명령하는 단계; 스토리지 장치 내의 주소화(Addressable) 스토리지 내에 쓰여진 데이터 패턴의 커맨드 데이터 포함 부분을 저장하는 단계; 스토리지 장치에서, I/O 인터페이스를 통해 호스트로부터 컨트롤 비트 패턴을 수신하는 단계; 그리고 컨트롤 비트 패턴을 통해 제공된 암호화된 I/O 커맨드를 해독하기 위해 주소화 스토리지 내의 하나 또는 하나 이상의 커맨드 데이터 포함 부분을 사용하는 단계를 포함할 수 있다. 제 1 시퀀스 내의 데이터 패턴은 커맨드 데이터 각각의 암호화된 버전을 포함하고, 제 1 시퀀스 내의 데이터 패턴은 제 1 시퀀스 내의 다음 데이터 패턴이 스토리지 장치에 쓰이기 전에 미리 정해진 횟수 동안 쓰이고, 컨트롤 비트 패턴은 암호화된 I/O 커맨드를 포함할 수 있다.

Description

채널 통신 프로토콜, 그것을 지원하는 메모리 모듈, 및 시스템{CHANNEL COMMUNICATION PROTOCOL, MEMORY MODULE AND SYSTEM SUPPORTING THE SAME}

본 발명은 메모리에 관한 것으로, 보다 구체적으로는 다양한 암호화 방식의 작업을 수행할 할 수 있는 I/O(Input/Output) 채널의 통신 프로토콜 및 이를 지원하는 메모리 모듈과 시스템에 관한 것이다.

컴퓨팅 시스템은 다양한 타입의 버스들을 통해 중앙 처리 장치(CPU: Central Processing Unit) 또는 메모리 컨트롤러와 통신하는 다양한 타입의 반도체 메모리를 사용한다. 이러한 메모리들은 불휘발성 메모리 혹은 휘발성 메모리들을 포함할 수 있다. 휘발성 스토리지는 하나 이상의 디램(DRAM) 모듈들과 같은 랜덤 액세스 메모리(RAM: Random Access Memory)에 의해 구성될 수 있다. 한편, 불휘발성 스토리지는 SSD(Solid State Drive), USB(Universal Serial Bus) 혹은 SD(Secure Digital) 혹은 마이크로 SD(MicroSD)에 장착된 플래시 메모리들, 등에 의해 구성될 수 있다. 다양한 타입의 버스들은 컴퓨팅 시스템의 마더보드(Motherboard)의 일부일 수 있다. 또한, 다양한 타입의 버스들은 커맨드, 어드레스, 데이터, 상태 데이터와 같은 시스템 전반의 관련 정보를 전달할 수 있는 물리적 연결들을 메모리 각각에 제공한다.

일반적으로, 각각의 I/O 버스들은 다른 데이터 밴드위스를 지원한다. 예를 들어, 중앙 처리 장치와 시스템 메모리(예를 들면, 디램 모듈)를 연결하는 시스템 메모리 I/O 버스 혹은 메인 메모리 버스는 다른 I/O 버스(예를 들면, 확장 버스)의 밴드위스에 비하여 현저히 높은 데이터 밴드위스를 지원할 수 있다. 디램 모듈과 통신을 제공하는 이러한 시스템 버스는 '디램 버스', '디램 인터페이스', '디램 메모리 인터페이스', 또는 '디램 채널'과 같은 용어들로 상호 교환 가능하게 사용된다. 컴퓨팅 시스템에는 다양한 타입의 다른 I/O 버스들이 존재한다. 예를 들어, 이러한 I/O 버스들은 PCI(Peripheral Component Interconnect) 버스, PCIe 혹은 PCI-E(PCI Express), USB 버스, SATA(Serial Advanced Technology Attachment) 버스 등을 포함할 수 있다. 일반적으로, 불휘발성 스토리지 장치들은 각각의 I/O 버스들과 연결될 수 있다. 예를 들어, USB 드라이브(Drive)는 USB 버스와 연결되고, SSD 드라이브는 SATA 버스와 연결될 수 있다.

각각의 통신 버스(시스템 메모리 버스 혹은 다른 I/O 버스)는 특정 타입의 통신 프로토콜을 지원하는 인터페이스를 제공한다. 이러한 통신 프로토콜은 상술한 통신 버스 및 통신 버스와 연결된 메모리들을 위해서만 정의되고 표준화된다. 예를 들어, JEDEC(Joint Electron Device Engineering Council Solid State Technology Association)은 독립적인 반도체 엔지니어링 거래 조직이며 표준화 조직이다. JEDEC에서는 DDR2, DDR3, DDR4와 같은 디램 제품군의 공개 표준을 제정하고 채택한다. 이러한 표준들은 메모리 핀 배치, 메모리 버스 인터페이스 구성 등을 구체화한다. 예를 들면, 메모리 버스 인터페이스 구성은 각각의 디램 인터페이스(예를 들어, 메모리 리셋 및 초기화 절차, 다양한 메모리 동작에 대한 요구 타이밍, 다양한 메모리 커맨드와 상태 데이터, 각각의 메모리 읽기 및 쓰기 모드 등)에 대한 통신 프로토콜, 어드레스와 데이터 버스 배치 등을 포함한다. 표준화의 장점 중의 하나는 제 3 자인 각각의 판매사들에 의해 표준을 따르도록 제조된 메모리 모듈들은 어떠한 컴퓨팅 시스템에서도 사용될 수 있다는 것이다. 이는 컴퓨팅 시스템의 해당 메모리 버스들이 각각의 표준 프로토콜을 지원하도록 디자인되기 때문이다. 하지만, 한편으로는 표준화된 메모리 인터페이스들은 하나의 타입의 통신 버스를 위해 디자인된 메모리 모듈이 다른 타입의 통신 버스와 연결되거나 설치될 수 없도록 만든다. 예를 들어, USB 버스와 동작하도록 디자인된 USB 메모리 장치는 SATA 버스와 연결될 수 없을 것이다. 이는 다른 메모리 장치 혹은 통신 버스 등도 마찬가지이다.

본 발명의 목적은, 불 휘발성 램 모듈과 호환되기 위한 채널 통신 프로토콜 방법 및 그것을 지원하는 메모리 모듈 및 시스템을 제공하는데 있다.

본 발명의 다른 실시 예에 따른 채널 통신 프로토콜 방법은 스토리지 장치가 호스트에 의해 지원되는 I/O 인터페이스에 결합되고, I/O 인터페이스를 통해 동작하도록 구성하는 단계; 스토리지 장치에서, I/O 인터페이스를 통해 호스트로부터 복수의 버퍼 중 하나의 버퍼의 메모리 맵(Memory-Mapped) 버퍼 어드레스 및 데이터의 메모리 페이지의 암호화 버전을 수신하는 단계; 수신된 데이터의 암호화된 버전을 메모리 맵 버퍼 어드레스를 갖는 버퍼 내에 저장하는 단계; 메모리 맵 버퍼 어드레스에 저장된 내용을 읽기 위한 명령을 호스트로부터 수신하는 단계; 그리고 명령의 수신에 반응하여, 수신된 데이터의 저장된 암호화된 버전을 I/O 인터페이스를 통하여 호스트에 제공하는 단계를 포함할 수 있다. 스토리지 장치는 호스트로부터 제공된 데이터를 스토리지 장치 내의 복수의 버퍼 내에 저장하도록 구성될 수 있다.

본 발명의 다른 실시 예에 따른 메모리 모듈은 제 1 스토리지 부, 인터페이스 유닛, 제 2 스토리지 부, 컨트롤 유닛을 포함할 수 있다. 제 1 스토리지 부는 정보를 저장하기 위한 복수의 메모리 유닛을 포함할 수 있다. 인터페이스 유닛은 메모리 모듈이 호스트에 의해 지원되는 I/O 인터페이스를 통해 동작 가능하고 I/O 인터페이스에 결합되도록 구성될 수 있다. 컨트롤 유닛은 제 1 및 제 2 스토리지 부, 인터페이스 유닛과 결합될 수 있다. 메모리 모듈이 I/O 인터페이스에 결합되는 경우, 컨트롤 유닛은 I/O 인터페이스를 통해 데이터 패턴들의 제 1 시퀀스를 호스트로부터 제공받고, 제공된 제 1 데이터 패턴의 데이터 패턴의 커맨드 데이터 포함 부분을 제 2 스토리지 부 내에 저장하고, I/O 인터페이스를 통해 호스트로부터 컨트롤 비트 패턴을 수신하고, 컨트롤 비트 패턴을 통해 제공된 암호화된 I/O 커맨드를 해독하기 위해 제 2 스토리지 부 내의 하나 또는 하나 이상의 커맨드 데이터 포함 부분들을 사용하도록 구성될 수 있다. 제 1 시퀀스 내의 데이터 패턴은 커맨드 데이터 각각의 암호화된 버전을 포함하고, 제 1 시퀀스 내의 데이터 패턴은 제 1 시퀀스 내의 다음 데이터 패턴이 수신되기 전에 미리 정해진 횟수 동안 호스트로부터 제공될 수 있다. 컨트롤 비트 패턴은 암호화된 I/O 커맨드를 포함할 수 있다.

본 발명의 다른 실시 예에 따른 시스템은 I/O 인터페이스, 프로세서, 스토리지 장치, 장치 드라이버를 포함할 수 있다. I/O 인터페이스는 전송 포멧의 전기적 정보의 통신을 지원할 수 있다. 프로세서는 I/O 인터페이스와 결합되고, I/O 인터페이스를 통해 전기적 정보의 통신을 지원할 수 있다. 스토리지 장치는 I/O 인터페이스와 호환될 수 있다. 장치 드라이버는 스토리지 장치와 연관될 수 있다. 장치 드라이버는 프로그램 명령들을 포함할 수 있다. 프로그램 명령들이 프로세서에 의해 실행 되는 경우, 프로그램 명령들에 의해 프로세서는 스토리지 장치가 I/O 인터페이스에 결합되었는지 판별하고, I/O 인터페이스를 사용하여 데이터 패턴들의 제 1 시퀀스를 스토리지 장치에 쓰도록 할 수 있다. 제 1 시퀀스 내의 데이터 패턴은 커맨드 데이터 각각의 암호화된 버전을 포함하고, 제 1 시퀀스 내의 데이터 패턴은 제 1 시퀀스 내의 다음 데이터 패턴이 스토리지 장치에 쓰이기 전에 미리 정해진 횟수 동안 쓰일 수 있다. 장치 드라이버를 통해 스토리지 장치는 스토리지 장치 내의 주소화(Addressable) 스토리지 내에 데이터 패턴의 커맨드 데이터 포함 부분을 저장하고, I/O 인터페이스를 통해 프로세서로부터 컨트롤 비트 패턴을 수신하고, 컨트롤 비트 패턴을 통해 제공된 암호화된 I/O 커맨드를 해독하기 위해 주소화(Addressable) 스토리지 내의 하나 또는 하나 이상의 커맨드 데이터 포함 부분을 사용할 수 있다. 컨트롤 비트 패턴은 상기 암호화된 I/O 커맨드를 포함할 수 있다.

본 발명의 실시 예에 따르면, 채널에서 사용된 암호화 또는 데이터 보호 방법과 관계 없이, 호스트가 인식 가능한 형태로 불 휘발성 메모리 장치와 호스트 간의 통신을 할 수 있다. 즉, 채널에서 사용된 암호화 또는 데이터 보호 방법을 역으로 분석할 필요가 없다. 따라서, 시스템의 통신 속도 및 적응성이 향상된다.

본 발명의 실시 예들은 제한적인 방법으로서가 아니라 예로서 도시되었으며, 첨부 도면에서 유사한 참조 번호는 유사한 요소를 참조한다.
도 1은 본 발명의 실시 예에 따른 시스템 레이아웃의 일부를 단순화하여 보여주는 블록도이다.
도 2는 본 발명의 다른 실시 예에 따른 도 1에 도시된 시스템을 보여주는 블록도이다.
도 3은 본 발명의 실시 예에 따라 스토리지 디바이스가 디램 인터페이스를 통해 호스트로부터 제공받은 암호화된 커맨드를 해독하는 방법에 대한 통신 프로토콜을 예시적으로 보여주는 순서도이다.
도 4는 본 발명의 실시 예에 따라 스토리지 디바이스가 디램 인터페이스를 통해 메모리 동작과 관련된 상태 데이터를 호스트에 제공하기 위한 통신 프로토콜을 예시적으로 보여주는 순서도이다.
도 5는 본 발명의 실시 예에 따른 프로토콜의 트레이닝 과정 동안의 컨트롤 데이터 및 상태 데이터를 위한 레지스터 기반의 스토리지 구성을 보여주는 그림이다.
도 6은 본 발명의 실시 예에 따른 도 2에 도시된 스토리지 장치 내의 CAM의 구조를 단순화하여 보여주는 블록도이다.
도 7은 본 발명의 실시 예에 따라 도 1 및 도 2에 도시된 스토리지 장치 내에 유저 데이터가 저장되는 방법을 예시적으로 보여주는 순서도이다.
도 8은 본 발명의 실시 예에 따라 도 1 및 도 2에 도시된 스토레지 장치 내의 불휘발성 메모리가 유저 데이터를 저장하기 위해 적합한 어드레스 매핑 및 세트 연관성을 이용하여 조직화되는 방법을 보여주는 그림이다.
도 9는 본 발명의 실시 예에 따른 도 1에 도시된 시스템의 전체적인 레이아웃을 보여주는 블록도이다.

이하에서는 본 발명을 설명하기 위한 구체적이고 세부적인 사항들이 설명될 것이다. 하지만, 이 기술 분야에 정통한 사람은 여기에 기재된 내용에 따라 본 발명의 다른 이점들 및 성능을 쉽게 이해할 수 있을 것이다. 또한, 잘 알려진 기능들 및 구조들에 대한 설명들은 명확성 및 간결성을 위하여 생략된다. 더욱이, 설명되는 본 발명의 기술 사항들은 디램 메모리 인터페이스와 연결할 수 있는 어떠한 반도체 기반의 스토리지 시스템에도 적용될 수 있다. 스토리지 시스템은 불휘발성 메모리 혹은 휘발성 메모리와 불휘발성 메모리를 구비한 하이브리드 형태의 구성을 포함할 수 있다.

본 명세서에서 어떤 구성이 특정 요소들을 포함한다는 언급이 있는 경우, 또는 어떤 과정이 특정 단계들을 포함한다는 언급이 있는 경우는, 그 외 다른 요소 또는 다른 단계들이 더 포함될 수 있음을 의미한다. 즉, 본 명세서에서 사용되는 용어들은 특정 실시 형태를 설명하기 위한 것일 뿐이고, 본 발명의 개념을 한정하기 위한 것이 아니다. 나아가, 발명의 이해를 돕기 위해 설명한 예시들은 그것의 상보적인 실시 예도 포함한다. 또한, 이하에서 기술되는 단수의 용어는 그것의 복수의 형태를 포함할 수 있고, 복수의 용어 또한 그것의 단수의 형태를 포함할 수 있다.

본 명세서에서 사용된 '결합된', '연결된', '전기적으로 연결된' 등의 표현은 이 기술 분야의 일반적인 방법으로 전기적으로 연결된 모든 형태를 포함한다. 또한, 첫 번째 구성이 다른 구성 혹은 구성들과 통신하고 있는 상태는 첫 번째 구성이 다른 구성과 다양한 형태의 정보(어드레스, 데이터, 컨트롤, 상태 데이터)를 전기적인 방법에 의해 무선 혹은 유선상으로 교환하는 모든 형태를 포함한다. 나아가, 이하의 설명에서 상세한 구성들 및 구조들과 같은 세부적인 사항들은 단순히 본 발명의 실시 예들의 전반적인 이해를 돕기 위하여 제공되며 이에 한정되는 것이 아니다.

본 명세서에서 사용되는 용어들은 본 발명이 속하는 기술 분야의 통상의 기술자들이 일반적으로 이해하는 의미를 갖는다. 보편적으로 사용되는 용어들은 본 명세서의 맥락에 따라 일관적인 의미로 해석되어야 한다. 또한 본 명세서에서 사용되는 용어들은, 그 의미가 명확히 정의된 경우가 아니라면, 지나치게 이상적이거나 형식적인 의미로 해석되지 않아야 한다.

상술한 바와 같이, 중앙 처리 장치와 시스템 메모리(예를 들면, 디램 모듈)를 연결하는 시스템 메모리 버스 혹은 메인 메모리 버스는 다른 I/O 버스의 밴드위스에 비하여 현저히 높은 데이터 밴드위스를 지원할 수 있다. 게다가, 낮은 데이터 밴드위스로 동작하는 I/O 버스들은 훨씬 높은 속도의 동작할 수 있는 I/O 스토리지 장치가 높은 밴드위스의 통신을 지원하는 데 있어 장애가 되는 경우가 많다. 일 예로서, 불 휘발성 스토리지 장치이며, 블록 단위를 기초로 동작하는 스토리지 장치인 SSD 스토리지 장치가 있다. SSD 스토리지 장치는 더 높은 밴드위스로 동작 가능한 I/O 장치이다. 따라서, SSD 스토리지 장치를 다른 느린 I/O 버스가 아닌 더 빠른 시스템 메모리 버스에 연결하는 것이 바람직할 것이다. 결과적으로, I/O 기능 및 성능(처리량 및 레이턴시)이 현저히 개선될 수 있다.

하지만, 상술한 바와 같이, 표준화된 메모리 인터페이스들은 하나의 타입의 통신 버스를 위해 디자인된 메모리 모듈이 다른 타입의 통신 버스와 연결되거나 설치될 수 없도록 만든다. 이러한 제한을 극복하기 위한 하나의 예로서, SATA 기반의 SSD 드라이브의 물리적 연결은 JEDEC의 표준화된 DIMM(Dual In-line Memory Module) 폼 펙터(Form Factor)를 따르는 DDR 메모리 채널 연결을 지원하도록 변형되어 디램 메모리 채널에 장착될 수 있다.

이러한 변형은 SSD 드라이브를 표준 DIMM 메모리 슬랏(Slot)에 장착하거나 호환되도록 하여 일반적인 디램 모듈로서 사용되도록 할 수 있다. 하지만, 이는 SSD 드라이브가 JEDEC 표준의 디램 인터페이스 통신 프로토콜을 기반으로 동작하도록 만들기에는 충분하지 않다.

이것이 불가능한 이유 중에 하나는 디램 채널 DIMM의 폼 팩터를 갖는 SSD(이하, 'DIMM 기반 SSD'라 칭함)는 호스트의 디램 메모리 맵에는 존재하지 않는 블록 기반의 스토리지 장치이기 때문이다. 비록 호스트가 DIMM 기반 SSD를 RDIMM(Registered DIMM), UDIMM(Unregistered DIMM), LRDIMM(Load Reduced DIMM), 혹은 다른 형태의 DIMM으로 인식(Recognize)한다고 하더라도, DIMM 기반 SSD는 여전히 호스트가 사용하는 디램 채널 통신 프로토콜을 지원(Comprehend)할 수 있어야 한다. 따라서, DIMM 기반 SSD는 호스트로부터 제공되는 디램 인터페이스에서 정의된 전송 형태의 데이터(컨트롤 데이터 혹은 유저 데이터)를 해석(Understand)해야 한다. 또한, DIMM 기반 SSD는 이에 반응하여 디램 인터페이스에서 정의된 전송 형태의 응답(예를 들어, 상태 데이터)을 생성하여, 호스트와 완전히 기능적으로 양방향 통신이 가능한 링크를 형성해야 한다. 이와 관련하여, DIMM 기반 SSD가 물리적으로 이러한 다른 타입의 I/O 채널에 장착되도록 호환되더라도, DIMM 기반 SSD는 '표준화되지 않은 용도의 스토리지 장치'로 간주될 수 있다. 이는 다른 타입의 I/O 채널(예를 들어, 디램 채널)을 사용하는 방식은 표준화되지 않았기 때문이다. 따라서, DIMM 기반 SSD와 같은 '표준화되지 않은 용도의 스토리지 장치'는 일반적으로 SATA 버스 혹은 PCIe와 같은 한가지 타입의 I/O 채널만을 사용하도록 표준화되어 왔을 것이다. 반면에, 디램 채널과 같은 다른 타입의 I/O 채널을 사용하는 방식은 표준화되지 않아 왔을 것이다.

문제는 디램 채널과 같은 I/O 채널에서 데이터 통신을 위해 시스템 내에서 암호화가 수행되는 경우에 발생할 수 있다. 간결하고 쉽게 설명하기 위해 처음에 기술하였듯이, 여기서 '암호화'라는 용어는 다양한 데이터 보호/코딩 방법(Scheme)들을 나타내기 위한 상위 용어로서 사용되었다. 예를 들어, 이러한 데이터 보호/코딩 방법은 스크램블링(Scrambling), 비트/바이트 스위즐링/스틸링(예를 들어, 프로세싱 속도 또는 스토리지 속도를 향상시키기 위한 데이터의 재구성 혹은 재정렬), 오류 정정 코드(ECC: Error Correction Code) 기반의 코딩, 데이터 인터리빙(Interleaving) 등을 포함할 수 있다. 암호화는 호스트, 호스트 플랫폼 기반의 메모리 컨트롤러, 혹은 호스트 내의 다른 프로세싱 블록에 의해 수행될 수 있다. 단일 시스템이 이러한 코딩 방식들을 모두 수행할 필요가 없음은 잘 이해될 것이다. 혹은, 이러한 시스템은 여기서 언급된 방법 외의 데이터 보호 방법을 수행할 수 있다. 또한, 여기서 '암호화', '암호화된 데이터' 혹은 비슷한 의미를 갖는 어떠한 다른 용어들도 암호화된 데이터(예를 들어, 컨트롤/커맨드 데이터, 상태 데이터, 그리고 유저 데이터 등)를 나타내는 상위 용어로서 사용될 수 있다. 암호화된 데이터는 상술한 데이터 보호/코딩 방법 중 적어도 하나를 사용하여 암호화될 수 있다. 또한, 암호화된 데이터는 I/O 채널(예를 들어, 디램 채널)을 통하여 해당 I/O 채널의 표준화된(혹은 정의된) 전송 형태에 의해 통신할 수 있다.

암호화가 표준화된 I/O 채널(예를 들어, 디램 채널)에서 이루어진 경우, 해당 I/O 채널에 결합되었지만 표준화되지 않은 스토리지 장치(예를 들어, 상술한 DIMM 기반 SSD)는 이에 기반이 되는 암호화 방법을 알아야(Aware) 한다. 이는 제공된 커맨드 및 유저 데이터를 해독하고, 호스트(혹은 호스트 메모리 컨트롤러)에 의해 수행된 것과 정확히 동일한 형태로 상태 데이터를 암호화하여 호스트에 제공하기 위함이다. 하지만, 암호화 알고리즘을 역으로 분석(Reverse Engineering)하는 것은 어렵다. 더욱이, 암호화 알고리즘을 안다고 해도, 알고리즘의 실행은 컴퓨터 판매사/플랫폼 등에 따라 달라질 수 있다. 예를 들어, 일부 플랫폼들은 스크램블러(Scrambler)의 부팅 시간에 생성되는 랜덤 시드(Random seed)를 사용할 수 있다. 플랫폼들이 이러한 방식(부팅할 때마다 랜덤화되는 방식)을 지원하지 않는다면, 해당 랜덤화된 스크램블링 방식은 역으로 분석되기 어려울 것이다. 따라서, 하나의 예로서 DIMM 기반 SSD을 사용하는 경우, 각각의 컴퓨터 판매사/플랫폼들에 의해 구현되는 디램 채널 암호화 방식들을 모두 지원하도록 DIMM 기반 SSD를 제공하는 것이 불가능함은 명확하다.

따라서, 표준화된 I/O 채널에 '표준화되지 않은 용도의 스토리지 장치(예를 들어, SSD 폼 팩터를 갖는 디램 메모리 채널 DIMM)'를 구현하는 방법을 개발하는 것이 바람직할 것이다. 이는 표준화된 해당 I/O 채널에 대한 호스트 플랫폼의 메모리 컨트롤러에 의해 수행된 암호화 방법(혹은, 알고리즘)을 알거나 역으로 분석할 필요가 없다. 하나의 예로서 DIMM 기반 SSD을 사용하는 경우, DIMM 기반 SSD는 표준 디램들과 다르기 때문에, 호스트가 컨트롤 정보를 DIMM 기반 SSD에 제공하고 해당 SSD로부터 상태 데이터를 제공 받도록 하는 것이 더 바람직함은 명확하다. 이는 DDR 채널에서 사용된 암호화 또는 데이터 보호 방법과 관계 없이 호스트가 인식 가능한 형태로 수행되어야 할 것이다.

특정한 실시 예들에서, 본 명세서는 호스트에 의해 수행된 암호화 방법(혹은, 알고리즘)을 역으로 분석할 필요 없이, 호스트 시스템과 DDR 폼 펙터를 갖는 SSD 간의 통신을 가능하게 하는 프로토콜을 제안한다. 따라서, 본 명세서에서 설명될 프로토콜은 다양한 형태의 스크램블링, 오류 정정 코드, 혹은 다른 형태의 데이터 보호 방식 등에 대하여 다룰 것이다. 그러므로, 이러한 프로토콜은 어떠한 형태의 암호화된 I/O 인터페이스에도 적용될 수 있을 것이다. 예를 들어, 이러한 I/O 인터페이스는 DIMM 기반 스토리지 장치가 DDR 채널에 장착되어 호스트와 정보를 교환할 필요가 있는 어떠한 어플리케이션도 포함할 수 있다.

이하에서는 본 발명의 일 실시 예에 따른 통신 프로토콜에 대하여 간략히 설명될 것이다. 이는 도 3 내지 도 8에서 자세히 설명될 것이다. 여기에서, DIMM 기반 SSD는 단순히 본 명세서의 기술 사상들을 간결하고 쉽게 설명하기 위하여 하나의 예로서 사용되었으며, 본 명세서의 기술 사상들은 이에 한정되는 것이 아니다. 즉, 본 명세서의 기술 사상들의 내용은 어떠한 형태의 어플리케이션에도 적용된다. 이러한 어플리케이션은 해당 I/O 인터페이스에 표준화 되지 않았지만 표준화된 I/O 인터페이스를 통해 호스트와 스토리지 장치 간의 링크를 형성할 수 있는 I/O 스토리지 장치와 호스트 간의 암호화된 통신을 수행하는 어플리케이션들을 포함할 수 있다. 따라서, 본 명세서의 내용은 '표준화되지 않은 용도의 스토리지 장치'가 암호화가 수행된 표준화된 I/O 통신 채널을 통해 동작 하고 이에 결합이 가능하도록 한다. 예를 들어, PCIe 기반 SSD 드라이브는 PICe 인터페이스와 연결된 경우에 '표준화된 스토리지 장치'로 볼 수 있을 것이다. 하지만, 이러한 SSD 드라이브는 다른 형태의 I/O 인터페이스(예를 들어, JEDEC에서 정의된 디램 인터페이스)와 연결된 경우에는 '표준화되지 않은 용도의 스토리지 장치'가 될 것이다. 이러한 경우에, 표준 DIMM 슬롯을 사용하는 디램 채널에 장착 가능하도록 SSD 드라이브의 물리적 연결을 변형하는 것 외에도, DIMM 기반 SSD가 호스트와 통신하도록 만드는 것 또한 바람직할 것이다. 이 경우, DIMM 기반 SSD가 호스트에 의해 수행된 암호화 방법(혹은, 스크램블링 알고리즘)에 대해 알거나 역으로 분석할 필요가 없도록 해야 할 것이다.

본 명세서는 표준화된 I/O 채널을 통한 '표준화되지 않은 용도의 스토리지 장치'와 호스트 간의 이러한 암호화된 통신이 가능하도록 하는 하나의 예시적인 방법을 제안한다. 여기서, 디램 인터페이스 혹은 디램 채널(예를 들어 도 1에 도시된 디램 메모리 인터페이스(16))는 표준화된 I/O 인터페이스(또는 I/O 채널)의 하나의 예로서 사용된다. 또한, 이러한 디램 인터페이스를 통해 교환되는 암호화된 디램 커맨드들은 '표준화되지 않은 용도의 스토리지 장치'에 의해 사용되는 암호화된 I/O 커맨드들의 하나의 예로서 사용된다. 이러한 암호화된 I/O 커맨드들은 '표준화되지 않은 용도의 스토리지 장치(예를 들어, 도 1에 도시된 스토리지 장치(18)'가 호스트(예를 들어, 도 1에 도시된 호스트)와 통신이 가능하도록 해석(Interpret)이 필요할 것이다. 이는 본 명세서에 기술된 각각의 내용들을 통하여 설명될 것이다. 설명의 편의를 위하여, '표준화되지 않은 용도의 스토리지 장치들' 및 그것들의 각각의 표준화된 I/O 인터페이스에 의해 실행될 수 있는 모든 형태들이 기술되지는 않을 것이다. 하지만, 이하에서 DIMM 기반 SSD를 예로서 기술될 자세한 내용들은 여전히 이러한 다양한 형태들에 적용될 수 있다. 따라서, 여기서 일반적인 용어인 I/O 인터페이스, I/O 채널, I/O 커맨드 대신에 자주 사용되는 특정한 용어들(예를 들어, 디램 인터페이스, 디램 채널, 디램 커맨드)은 본 발명의 적용 가능성을 한정하는 것이 아니다. 즉, 본 발명은 표준화된 디램 채널에 연결된 DIMM 기반 SSD에만 적용 가능한 것에만 한정하여 해석되지 말아야 한다. 대신에, 필요한 경우 일부 변경을 통하여, 도 1 내지 도 9에 도시된 실시 예들에 따른 통신 프로토콜과 데이터 스토리지의 구성은 다른 타입의 I/O 스토리지 장치들 및 표준화된 I/O 인터페이스에도 역시 적용될 수 있다.

DIMM 기반 SSD들과의 데이터 교환의 형태는 (i)컨트롤/상태 데이터 (ii)유저 데이터의 두 가지 카테고리로 구분될 수 있다. 호스트 기반의 암호화가 있는 경우, 컨트롤 데이터는 암호화되어야 하고 디램 메모리 채널 기반의 SSD에 의해 지원되어야 한다. 반면에, 호스트가 암호화 할 수 있도록, 상태 데이터는 SSD에 의하여 적합한 암호화 포멧 내에서 생성되어야 할 것이다. 특정한 실시 예들에서, 호스트는 컨트롤/상태 데이터를 전송할 수 있도록: (i) 커맨드 기술자(Descripter) 혹은 값(Value)을 DIMM 기반 SSD 내의 하나 혹은 복수의 레지스터에 쓰고, (ii) 상태 지표(Status Indicator)를 하나 혹은 복수의 레지스터로부터 읽어올 것이다. 특정한 실시 예들에서, 유저 데이터는 직접 SSD 내의 플레시 메모리에 저장될 수 있다. 예를 들어, 유저 데이터는 스크램블링 혹은 오류 정정 코드와 같은 호스트에 의해 제공된 어떠한 형태의 암호화들도 포함할 수 있다. 이는 유저 데이터는 호스트에 의한 암호화에 대해 어떠한 변경을 가하지 않은 준 완성 상태로 SSD 내에 저장되기 때문이다. 유저 데이터는 이후 호스트에 의해 메모리 읽기 동작이 수행될 때마다, 변경되지 않는 상태로 다시 읽혀질 수 있다. 결과적으로, 이러한 변경되지 않은 데이터는 호스트에 의해 쉽게 인식(Recognize)되고, 각각의 호스트의 암호화 알고리즘에 따라 해독된다.

특정 실시 예들에서, 좀 더 일반적으로, 알려진 값의 트레이닝 과정에 대한 프로토콜을 보내고 관련된 커맨드/상태 데이터(호스트로부터 제공된 포멧에 의해)를 DIMM 기반 SSD의 CAM/레지스터 내에 저장함으로써, 컨트롤/상태 데이터는 DIMM 기반 SSD 드라이브에 쓰일 수 있다. 트레이닝 이후에 제공될 컨트롤 데이터를 해석하기 위하여, DIMM 기반 SSD는 컨트롤 데이터의 일부로서 호스트로부터 현재 제공된 암호화된 커맨드의 의미를 판단하기 위해 이전에 트레이닝된 값들과 제공된 데이터에 대한 CAM 룩업(Lookup)을 이용할 수 있다. 또한, SSD는 레지스터 인덱스 룩업을 이용하여 SSD의 레지스터들 중 하나에 저장된 적합한 상태 데이터를 검색하여 이를 호스트에 제공할 수 있다. 일 실시 예에서, DIMM 기반 SSD 내에서 완전한 커맨드 기술어(Descriptor)를 생성하기 위해, 트레이닝 과정 동안 복수의 컨트롤 데이터 시퀀스들(Sequences)은 호스트로부터 전송될 수 있다. 다른 실시 예에서, 복수의 상태 데이터 시퀀스들은 역시 트레이닝 과정 동안 전송될 수 있다.

SSD 내에서 블록 기반의 데이터 저장 방법은 기존의 DDR 채널 디램 내의 메모리 뱅크 선택 기반의 저장 방법과 완전히 다르다. 따라서, 유저 데이터는 일부 다른 방법을 이용하여 DIMM 기반 SSD에 쓰이거나 읽혀질 수 있다. 일 실시 예에서, 주어진 LBA(Logical Block Address)에 대한 읽기 및 쓰기는 디램 메모리 채널 SSD 내의 동일한 물리적 주소 공간에 대하여 수행되어야 할 것이다. 이는 호스트 메모리 컨트롤러의 데이터 스크램블링 알고리즘의 주소 성분 때문이다. 이는 LBA를 특정한 물리적으로 주소화된 버퍼들과 연관시키고, 주어진 버퍼를 통해서만 해당 LBA를 쓰거나 읽음으로써 수행될 수 있다. 반면에 호스트 메모리 컨트롤러가 스크램블링 방법에 주소 종속성을 가하지 않는 경우에는, 유저 데이터는 DIMM 기반 SSD 내의 아무 버퍼 주소로부터 읽혀지거나 쓰일 수 있다.

도 1은 본 발명의 실시 예에 따른 시스템 레이아웃의 일부를 단순화하여 보여주는 블록도이다. 도 1을 참조하면, 시스템(10)은 디램 메모리 인터페이스(16)과 같은 I/O 인터페이스를 통해 프로세서 혹은 호스트(14)와 연결되고 통신하는 시스템 메모리 유닛(12)를 포함할 수 있다. 시스템(10)은 컴퓨터 시스템(데스크 탑 혹은 랩탑), 테블릿 PC, 모바일 장치, 비디오 게임 장치나 콘솔, 혹은 디램 메모리 인터페이스(16)와 같은 I/O 인터페이스를 포함하는 다른 어떠한 형태의 컴퓨팅 또는 프로세싱 장치일 수 있다. 다양한 실시 예들에서, 시스템(10)은 랙 마운트(Rack-Mount)가 가능한 서버 시스템, 자립형(Standalone) 시스템, 혹은 다른 어떠한 형태의 폼 펙터를 가질 수 있다. 일부 실시 예들에서, 시스템(10)은 서버 시스템 보다는 클라이언트 시스템으로서 구성될 수 있다.

여기서, '시스템 메모리'는 디램 메모리 인터페이스(16)를 통해 호스트(14)와 통신하는 메모리 모듈을 나타내는 용어로서 사용된다. 따라서, 시스템 메모리 모듈은 I/O 버스(예를 들어, USB 버스, SATA 버스, PCIe 버스 등)를 통해 호스트(14)와 연결된 다른 I/O 메모리 장치/모듈(예를 들어, USB 드라이브, 하드 드라이브, SATA 드라이브 등)과 구별될 것이다. 하지만, '시스템 메모리' 라는 용어는 시스템 메모리가 물리적으로 다른 비 시스템(Non-system) I/O 메모리에 비하여 호스트(14)에 가깝게 위치한다는 것을 반드시 암시하는 것은 아니다. 설명과 도안의 편의를 위하여, 시스템 메모리 및 다른 I/O 메모리들을 호스트(14)에 연결하는 다양한 버스 브릿지들 또는 버스 컨트롤러들은 도 1 및 다른 도면에 도시되지 않았다. 하지만 시스템 메모리 유닛(12)과 호스트(14) 사이에 컨트롤 유닛들(예를 들어, 버스 브릿지들이나 버스 아비터(Arbiter))이 추가될 수 있다는 것은 이해될 것이다. 일 실시 예로서, 도 1을 참조하면, 시스템 메모리 유닛(12)은 스토리지 장치(18) 및 하나 또는 복수의 디램 메모리 모듈(20)을 포함할 수 있다. 디램 메모리 모듈(20)에 대한 메모리 타입, 디램 메모리 모듈의 수, 디램 모듈 각각에 포함된 메모리 칩의 수, 칩당 메모리 뱅크의 수와 칩 내의 내부 메모리 뱅크의 구성, 또는 각각의 칩에 대한 스토리지 용량과 같은 상세한 사항들은 본 발명과 상관이 없기 때문에 기술되지 않는다. 특정한 실시 예들에서, 본 명세서의 기술 사항은 스토리지 장치(18) 내부에 적용되거나 스토리지 장치(18)와 관련하여 적용될 것이다. 따라서, 스토리지 장치(18)는 도 2를 참조하여 자세히 설명될 것이다.

여기서 사용된 '스토리지 장치'는 일반적으로 DDR 디램과 같은 기존 디램 모듈에 사용되는 디램 버스 기반의 표준 DIMM 메모리 슬롯에 장착될 수 있는 핀 구성 또는 물리적 연결을 갖는 모든 형태의 반도체 메모리 장치들을 나타내는 용어이다. 예를 들어, 본 명세서의 각각의 실시 예들에서 설명된 것과 같이, 스토리지 장치(18)는 상술한 디램 메모리 채널 DIMM 폼 펙터를 갖는 SSD(DIMM 기반 SSD 또는 DDR 폼 펙터를 갖는 SSD), DIMM 폼 펙터를 갖는 모든 블록 기반의 스토리지 장치, 디램 메모리 인터페이스(16)를 통하여 동작하는 스토리지 장치 등을 포함할 수 있다.

특정 실시 예들에서, 스토리지 장치(18)는 오직 불 휘발성 스토리지 장치만을 포함할 수 있다. 이 경우에 스토리지 장치(18)는 주로 플레시 메모리나 플레시 기반의 스토리지 유닛, MRAM(Magnetic RAM), 스핀전달토크 MRAM (Spin-Transfer Torque MRAM), Phase-Change Random Access Memory (PRAM 또는 PCRAM), Resistive Random Access Memory (RRAM 또는 ReRAM), Conductive-Bridging RAM (CBRAM) 등의 불 휘발성 메모리 유닛을 포함할 수 있다. 다른 실시 예들에서는, 스토리지 장치(18)는 불 휘발성 혹은 휘발성의 하이브리드 스토리지일 수 있다. 이 경우, 스토리지 장치(18)는 휘발성 메모리와 불 휘발성 메모리 유닛을 모두 포함할 수 있다. 플레시 메모리와 디램을 포함하는 불 휘발성 DIMM(NVDIMM: Non-Volatile DIMM)은 이러한 하이브리드 스토리지 장치의 예이다.

다른 실시 예에서, 스토리지 장치(18)는 기존의 DDR2/DDR3/DDR4 디램 모듈, 또는 디램 기반의 3-DS(Three Dimensional Stack) 메모리 모듈일 수 있다. 예를 들어, 디램 기반의 3-DS 메모리 모듈은 HBM(High Bandwidth Memory) 모듈, 또는 HMC(Hybrid Memory Cube) 메모리 모듈일 수 있다. 다른 실시 예들에서, 스토리지 장치(18)를 구성하는 메모리 모듈의 타입은 어떠한 타입도 관계가 없다. 이는 본 발명에 따른 프로토콜은 호스트(14)에 의해 지원되는 디램 메모리 인터페이스(16)을 통해 장착 가능하고 동작 가능한 모든 메모리 모듈에 적용될 것이기 때문이다.

일 실시 예에서, 오직 스토리지 장치(18)가 시스템 메모리 유닛(12)에 의해 구성될 수 있다. 이 경우에 추가적인 디램 메모리 모듈(20)은 없을 수 있다. 다른 실시 예에서, 스토리지 장치(18)는 하나 이상의 메모리 모듈을 포함할 수 있다. 이 경우, 모든 메모리 모듈은 호스트(14)의 제어에 의해 동작할 수 있고, 모두 동일한 타입으로 구성되거나 다른 타입들로 구성될 수 있다. 또한, 도 1, 도 2 또는 도 9에 시스템(10)의 일부로서 도시된 유닛들은 자체적으로 다른 구성들을 포함할 수 있음은 이해될 수 있을 것이다. 하지만, 이러한 구성들은 본 발명과 관계가 없기 때문에 본 명세서에 도시되지 않았다.

외부의 호스트(14)와 시스템 메모리 유닛(12) 사이에 연결된 시스템 메모리 버스 혹은 디램 메모리 인터페이스(16)는 시스템 메모리 유닛(12)과 호스트(14) 간의 데이터 전송을 위해 넓고, 고속의 로컬 I/O 버스일 수 있다. 특정 실시 예들에서, 디램 버스 혹은 디램 메모리 인터페이스(16)는 시그널링(Signaling) 채널일 수 있다. 시그널링 채널은 각각의 호스트(14)에 의해 제공되는 JEDEC에 의해 규정된 디램 채널 통신 프로토콜에 따라 호스트(14)와 시스템 메모리 유닛(12) 간의 컨트롤, 상태, 유저 데이터를 전송한다. 특정 실시 예에서, 트레이닝 단계 혹은 이후의 단계 동안, 디램 메모리 인터페이스(16)의 데이터 버스의 일부는 스토리지 장치(18)와 호스트(14) 간에 커맨드, 상태, 유저 정보를 교환하기 위해 사용될 것이다. 이는 이하에서 자세히 설명될 것이다.

도 2는 본 발명의 다른 실시 예에 따른 도 1에 도시된 시스템을 보여주는 블록도이다. 일 실시 예로서, 스토리지 장치(18)는 도 2에 도시된 구성들보다 적거나 많은 구성들을 포함할 수 있다. 하지만, 참조의 편의를 위하여, 그 이상의 일부 구성들 각각은 도 2에 도시되거나 도 2를 참조하여 설명될 것이다. 도 2를 참조하면, 호스트(14)는 메모리 컨트롤러(24)와 통신하는 CPU(22)를 포함할 수 있다. 일 실시 예에서, CPU는 일반적인 용도의 마이크로 프로세서일 수 있다. 여기서, '프로세서'와 'CPU'는 설명의 편의를 위해 상호 교환 가능한 용어로서 사용될 수 있다. 하지만, CPU(22) 대신 혹은 CPU(22)에 추가하여, 프로세서/호스트(14)는 마이크로 컨트롤러, DSP(Digital Signal Processor), GPU(Graphics Processing Unit), ASIC(Application Specific Integrated Circuit) 프로세서, FPGA(Field Programmable Gate Array) 등의 모든 타입의 프로세서들을 포함할 수 있다는 것은 쉽게 이해될 것이다.

일 실시 예에서, 프로세서/호스트(14)는 또한 하나 이상의 CPU를 포함할 수 있다. 호스트(14)는 특정한 ISA(Instruction Set Architecture)에 따라 명령을 수행하거나 데이터를 처리할 수 있다. 예를 들어, 상술한 ISA는 x86 ISA(32-bit 혹은 64-bit versions), PowerPC® ISA, 또는 RISC (Reduced Instruction Set Computer) ISA에 기반한 MIPS (Microprocessor without Interlocked Pipeline Stages) ISA등을 포함할 수 있다. 일 실시 예에서, 호스트(14)는 프로세서 또는 CPU의 기능에 추가적인 기능을 갖는 SOC(System on Chip)일 수 있다. 예를 들어, 이 경우에 메모리 컨트롤러의 기능은 SOC에 집적될 수 있다. 또는, 특정 실시 예들에서, 메모리 컨트롤러는 CPU(22)와 함께 집적될 수 있다.

일반적으로, 메모리 컨트롤러(24)는 호스트(14)와 시스템 메모리 유닛(12) 간의 데이터 교환을 제어할 수 있다. 이 경우, 특정 실시 예에서, 스토리지 장치(18)과 호스트(14) 간에 발생하는 모든 데이터와 컨트롤 정보의 교환은 메모리 컨트롤러(24)에 의해 제어되거나 메모리 컨트롤러(24)를 거쳐간다. 일 실시 예에서, 메모리 컨트롤러(24)는 디램 메모리 인터페이스(16)을 통해 스토리지 장치(18)에 제공되는 데이터를 암호화할 수 있다. 예를 들어, 이러한 암호화 방식은 스크램블링, 비트/바이트 스위즐링/스틸링(Swizzling/Steering), 오류 정정 코드, 그리고 시스템(10)에서 수행되는 다른 데이터 보호/코딩 방법 등을 포함할 수 있다. 이와 유사하게, 메모리 컨트롤러(24)는 또한 스토리지 장치(18)로부터 제공된 데이터를 해독하여, 이후 추가적인 프로세싱을 위해 해독된 데이터를 CPU(22)에 전송할 수 있다. 다른 실시 예들에서, 메모리 컨트롤러(24)는 단순히 메모리 선택, CPU에 의해 암호화된 데이터를 스토리지 장치(18)에 전송하는 작업, 스토리지 장치(18)로부터 암호화된 데이터를 수신하는 작업, 메모리 매핑, 혹은 CPU가 시스템 메모리 유닛(12) 내의 다양한 메모리 모듈들과 통신이 가능하도록 만드는 컨트롤 동작들을 제어할 수 있다. 이 경우, 이러한 암호화 및 해독화는 CPU(22)에 의하여 수행될 수 있다.

도 2를 참조하면, 호스트(14)는 OS(26)(Operating System)과 관련된 프로그램 코드를 구동하거나 저장할 수 있다. OS(26)는 Microsoft® Windows® 기반의 OS, Apple® Mac OS® 혹은 OS X® 기반의 OS, Linux®와 같은 오픈 소스 기반의 OS일 수 있다. OS 소프트웨어(26)의 스토리지, 수행, 타입, 제어에 대한 자세한 설명은 본 발명과 관계가 없기 때문에 본 명세서에 기술되지 않았다.

일 실시 예에서, 스토리지 장치(18)와 호스트(14) 간의 상호 작용은 스토리지 장치(18)와 연관된 소프트웨어 또는 장치 드라이버 어플리케이션(28) 어플리케이션을 통해 이루어질 것이다. 장치 드라이버 어플리케이션(28)은 OS(26)에 의해 제어되고, CPU(22)에 의해 실행될 수 있다. 일 실시 예에서, CPU(22)에 의한 장치 장치 드라이버 어플리케이션(28)의 실행 시, 호스트(14)는 도 3, 4, 7을 참조하여 설명될 다양한 방법과 단계들을 수행할 수 있다. 따라서, 본 명세서에 기술된 내용과 관련된 통신 프로토콜은 호스트(14)에 의한 장치 드라이버 어플리케이션(28)의 실행을 통해 구현될 수 있다. 일 실시 예에서, 장치 드라이버 어플리케이션(28)은 OS 소프트웨어(26)의 일부로서 제공될 수 있다. 일 실시 예에서, 장치 드라이버 어플리케이션(28)는 스토리지 장치(18)의 제조사/개발사의 웹사트와 같은 외부의 소스로부터 다운로드될 수 있다. 다른 실시 예에서, 장치 드라이버 어플리케이션(28)은 시스템 BIOS(Basic Input Output System)의 일부일 수 있다. 다른 실시 예에서, 장치 드라이버 어플리케이션(28)는 스토리지 장치(18) 자체에 의해 호스트(14)에 제공될 수 있다. 예를 들어, 이는 파워-업(Power-up) 하는 경우나 시스템(10)이 BIOS를 통해 부팅되는 경우와 같이 스토리지 장치(18)가 시스템(10)에 처음 인스톨되는 경우일 수 있다. 이 경우에, 장치 드라이버 어플리케이션(28)는 스토리지 장치(18)에 제공/저장될 수 있다.

도 2에 개념적으로 도시된 것과 같이, 스토리지 장치(18)가 처음 인스톨되는 경우, API(Application Programming Interface)는 디램 메모리 인터페이스(16)를 통해 호스트(14)에 제공될 수 있다. 스토리지 장치(18)의 메모리 동작들을 제어하기 위해 장치 드라이버 어플리케이션(28)를 실행하는 것과 같이, 호스트(14)는 장치 트레이닝 과정(이하에서 설명됨)을 시작하기 위해서 API를 사용할 수 있다. 일 실시 예에서, 이러한 트레이닝 및 다른 동작들은 스토리지 장치(18) 내의 미리 정의된 하나 또는 복수의 스토리지 위치에 대한 읽기, 쓰기 동작을 통해 수행될 수 있다. 이는 이하에서 설명될 것이다. 일 실시 예에서, 예를 들어, API는 이러한 두 가지 미리 정의된 스토리지 위치로서 컨트롤 레지스터와 상태 레지스터를 노출할 수 있다. 도 2를 참조하면, 어떠한 경우에도 스토리지 장치(18)는 적어도 장치 드라이버(30, 점선의 블록으로 표시됨)의 일부를 포함할 수 있다. 이는 호스트 기반의 장치 드라이버 어플리케이션(28)를 통한 호스트(14)와 스토리지 장치의 통신 및 상호 작용을 가능하게 하기 위함이다.

스토리지 장치(18)는 호스트 인터페이스 유닛(32)를 포함할 수 있다. 호스트 인터페이스 유닛(32)는 전기적 인터페이스에 스토리지 장치(18)와 호스트(14) 간의 데이터 전송/이동을 가능하게 하는 높은 스피드와 넓은 밴드위스의 디램 메모리 인터페이스(16)을 제공한다. 특정 실시 예들에서, 스토리지 장치(18)와 호스트(14) 사이의 기본 어드레싱(Addressing) 및 핸드쉐이킹(Handshaking)은 장치 드라이버 어플리케이션(28) 및/또는 장치 드라이버(30)의 동작 제어를 받는 호스트 인터페이스 유닛(32)을 이용한 하드웨어 내에서 수행될 것이다. 상술한 바와 같이, 스토리지 장치(18)가 DIMM 폼 펙터를 갖더라도, 호스트 인터페이스 유닛(32)는 기존의 디램 모듈 내의 인터페이스 유닛과 다르게 동작할 것이다. 이는 스토리지 장치는 복수의 메모리 뱅크를 갖는 일반적인 디램 모듈과 다른 블록 기반의 불 휘발성 메모리 장치이기 때문이다. 하지만, 특정 실시 예들에서, 스토리지 장치(18)가 일반적으로 블록 기반의 스토리지 장치라 해도, 메모리 뱅크 기반의 구성을 갖는 스토리지 장치(18)는 고안될 수 있다. 이는 도 8을 참조하여 설명될 것이다. 다른 타입의 I/O 스토리지 장치들 역시 유사하게 구성될 수 있다.

일 실시 예에서, 스토리지 장치(18)가 불 휘발성 메모리인 경우, 호스트(14)로부터 제공된 데이터는 불 휘발성/플레시 메모리 유닛(34)에 저장될 것이다. 이 경우, 불 휘발성/플레시 메모리 유닛(34)은 복수의 플레시 메모리 유닛들을 포함할 수 있다. 일 실시 예에서, 상술한 바와 같이, 스토리지 장치(18)는 선택적으로 하이브리드 스토리지 모델을 지원할 수 있다. 하이브리드 스토리지 모델은 휘발성 및 불휘발성 스토리지를 지원한다. 이 경우, 스토리지 장치(18)는 디램 메모리 유닛(36)들을 또한 포함할 수 있다. 하지만, 디램 메모리 유닛(36)이 존재하더라도, 스토리지 장치(18)는 여전히 도 1에 도시된 디램 메모리 모듈(20)과 같은 일반적인 디램 모듈이 아닐 것이다. 스토리지 장치(18) 내의 추가적인 반도체 스토리지 구성들은 CAM(38), RBU(40)(Register and Buffer Unit)와 같은 주소화 가능한(Addressable) 스토리지를 포함할 수 있다.

일 실시 예에서, CAM(38)은 SRAM(Static RAM)일 수 있다. CAM(38)의 추가적인 구동에 대한 세부 사항들은 도 6을 참조하여 설명될 것이다. 특정 실시 예들에서, CAM(38)은 내용 저장과 검색 기능을 갖는 다른 타입의 주소화 가능한(Addressable) 스토리지에 의해 대체될 수 있다. RBU(40)는 하나 또는 복수의 컨트롤 레지스터(42), 하나 또는 복수의 상태 레지스터(44), 그리고 다른 타입의 레지스터들/버퍼들(46)를 포함할 수 있다. 본 명세서에서는 컨트롤 레지스터(42) 및 상태 레지스터(44)를 위주로 설명될 것이다. 따라서, 여기서 레지스터들/버퍼들(46)에 대한 추가적인 내용은 설명되지 않을 것이다. 하지만, 스토리지 장치(18)의 동작 동안, 레지스터들/버퍼들(46)이 스크래치패드 (Scratchpad) 메모리와 같은 다양한 변수 또는 기능의 추가적인 런타임(Run-time) 스토리지를 제공할 수 있음은 이해될 것이다. 일 실시 예에서, 레지스터들/버퍼들(46) 내의 스토리지 버퍼들은 도 8에서 설명될 불 휘발성/플레시 메모리 유닛(34)의 버퍼 구성과 다를 수 있다.

도 2를 참조하면, 스토리지 장치(18)는 장치 컨트롤러(48) 또한 포함할 수 있다. 이는 스토리지 장치(18) 내의 다양한 구성들의 동작 제어를 위함이다. 장치 컨트롤러(48)는 RBU(40) 내의 버퍼들 및 레지스터들에 읽기 및 쓰기 동작을 제어하기 위한 버퍼 매니저(50), 불 휘발성/플레시 메모리 유닛(34)에 읽기 및 쓰기 동작을 제어하기 위한 NVM(Non-Volatile Memory) 컨트롤러(52)를 포함할 수 있다. 일 실시 예에서, NVM 컨트롤러(52)는 플래시 메모리 인터페이스(미도시) 제공할 수 있다. 플래시 메모리 인터페이스(미도시)는 불 휘발성/플레시 메모리 유닛(34) 내의 하나 또는 복수의 플래시 메모리 유닛들을 제어하기 위한 컨트롤 버스들, 내부 어드레스 버스들, 데이터 버스들을 포함한다. 일 실시 예에서, 장치 컨트롤러(48) 내의 프로세싱 유닛(54)은 버퍼 매니저(50)와 NVM 컨트롤러(52)의 동작을 제어하고, 스토리지 장치(18) 내의 다른 회로 구성들(예를 들어, CAM(38) 및 호스트 인터페이스 유닛(32)) 및 장치 컨트롤러(48)의 전반적인 동작을 제어하기 위한 펌 웨어 레벨의 소프트웨어를 실행한다.

일 실시 예에서, 장치 컨트롤러(48)는 하드웨어, 펌 웨어 및/또는 소프트웨어의 조합으로 구현된다. 따라서, 스토리지 장치(18)의 특정한 기능들은 실행 시에 프로그램이 가능할 수 있다. 도 2에 도시되지 않았지만, 장치 컨트롤러(48)은 스토리지 장치(18)을 위한 펌웨어를 저장하기 위해 EEROM(Electrically Erasable Programmable Read Only Memory)을 포함할 수 있다. 일 실시 예에서, EEPROM은 장치 드라이버(30)의 적어도 일정 부분을 저장할 수 있다. 다른 실시 예에서, 장치 컨트롤러(48)는 내장 RAM(미도시)를 포함할 수 있다. 내장 RAM(미도시)는 스크래치 값을 저장하거나 프로그램이 실행되는 동안 프로세싱 유닛(54)을 위한 스크래치패드/버퍼 메모리로서 기능한다. 디램 메모리 유닛(36)과 같은 디램 메모리 구성들이 스토리지 장치(18) 내에 존재하는 경우에는, 장치 컨트롤러(48)는 디램 컨트롤러(미도시)를 포함할 수 있을 것이다. 디램 컨트롤러(미도시)는 하나 또는 복수의 디램 메모리 유닛들을 제어하기 위한 컨트롤 인터페이스, 내부 어드레신, 데이터 버스를 포함할 수 있다.

도 3은 본 발명의 실시 예에 따라 스토리지 디바이스가 디램 인터페이스를 통해 호스트로부터 제공받은 암호화된 커맨드를 해독하는 방법에 대한 통신 프로토콜을 예시적으로 보여주는 순서도이다. JEDEC에서 정의된 디램 채널 커맨드의 일부 예들은 메모리 읽기 커맨드, 메모리 쓰기 커맨드, 노 오퍼레이션(No-Operation) 커맨드, 버스트 터미네이트(Burst Terminate) 커맨드, 로우 액티브 커맨드 등을 포함한다. 도 3에 도시된 방법에 의하면, 스토리지 장치(18)는 호스트에 의해 수행된 암호화 방법(혹은, 알고리즘)을 역으로 분석할 필요 없이, 디램 메모리 인터페이스(16)을 통해 호스트(14)로부터 제공된 암호화된 커맨드들을 이해할 수 있다. 도 3에 도시된 순서도(58) 및 도 4에 도시된 순서도(72, 후술됨)는 본 발명의 특정 실시 예에 따른 통신 프로토콜을 대략적으로 보여준다. 프로토콜에 대한 세부 내용은 도 5 및 도 6을 참조하여 설명될 것이다. 일 실시 예에서, 도 3 및 도 4에 도시된 순서도(58, 72)의 단계들은 스토리지 장치(18) 및 호스트(14)의 조합에 의해 수행될 수 있다. 이 경우, 스토리지 장치(18) 및 호스트(14)는 호스트(14)에 의해 실행되는 장치 드라이버 어플리케이션(28)에 의해 동작을 제어 받을 것이다.

반면에, 다른 실시 예에서, 도 3 및 도 4의 모든 단계들은 스토리지 장치(18)에 의해 실행될 수 있다. 이는 장치 드라이버 어플리케이션(28)가 스토리지 장치(18)와 연관성이 있고, 장치 드라이버 어플리케이션(28)에 의해 스토리지 장치(18)의 동작이 제어받기 때문이다. 특정 실시 예들에서, 어떠한 경우에도, 본 발명의 기술 사상에 따른 통신 프로토콜 또는 구체적인 방법의 단계들을 수행하기 위한 시스템(10)의 구체적인 구성들에 대한 설명이 필요하지 않을 것이다. 따라서, 이하에서 이에 대한 설명은 생략될 수 있다.

참조 번호(28)는 단지 드라이버 소프트웨어가 CPU(22)에 의해 실행되는 경우에 장치 드라이버(30)가 스토리지 장치(18)와 연관되고, CPU(22) 및/또는 메모리 컨트롤러(24)의 특정 동작과 마찬가지로 스토리지 장치(18)의 동작을 제어하는 것을 나타내기 위해 도 3 내지 9에서 사용되었다. 특정 실시 예들에서, 스토리지 장치(18) 상에 있는 장치 드라이버의 상호부가 있거나(예를 들어, 도 2에 도시된 장치 드라이버(30)), 또는 본 명세서의 내용에 따른 통신 프로토콜을 총괄적으로 구현하기 위해 장치 드라이버(30)가 호스트 상에 있는 장치 드라이버 어플리케이션(28)과 통신/교환하는 경우에도, 참조 번호(28)은 설명의 간결성을 위해 이러한 장치 드라이버 어플리케이션(28)의 조합을 나타내기 위해 사용된다.

도 3, 4, 7에 도시된 순서도나 다른 도면의 설명 내에 사용된 '블록'이란 용어는 '블록 기반의 스토리지', '블록 기반의 스토리지 장치' 등에 사용된 '블록'과 혼동되지 말아야 한다. '블록 기반의 스토리지', '블록 기반의 스토리지 장치' 등에 사용된 '블록'은 특정 분야에서 사용되는 용어이고, 본 명세서에 도시된 그림들에 대한 설명의 문맥 상에 사용된 이와 관련이 없는 '블록'이란 용어와 상호 교환되어 사용되지 않는다. '블록 기반의 스토리지', '블록 기반의 스토리지 장치' 등에 사용된 '블록'은 본 명세서에 기술된 내용의 문맥으로부터 명확히 구분될 것이다.

도 3을 참조하면, 60 단계에서, 장치 드라이버 어플리케이션(28)의 동작 제어 하에 호스트(14) 또는 장치 드라이버 어플리케이션(28)는 호스트(14)의 지원에 의해 스토리지 장치(18)가 표준화된 I/O 인터페이스(예를 들어, 디램 메모리 인터페이스(16))에 장착되었는지를 감지할 것이다. 예를 들어, 이러한 감지는 시스템(10)의 파워-업(Power-up) 시간 동안 혹은 시스템(10)이 부팅되는 때에 디램 채널 DIMM 슬롯에 장착된 스토리지 장치(18)와 함께 발생할 수 있다. 일 실시 예에서, 62 단계에서, 스토리지 장치(18)는 DIMM 기반 SSD일 수 있다. 예를 들어, 프로토콜 트레이닝은 60 단계에서의 감지에 반응하여 시작될 수 있다.

64 단계에서, 프로토콜 트레이닝의 일부로서, 장치 드라이버 어플리케이션(28)는 일련의 데이터 패턴들을 스토리지 장치(18)에 쓰도록 I/O 인터페이스(예를 들어, 디램 메모리 인터페이스(16))를 통해 호스트(14)에 명령할 수 있다. 특정한 실시 예들에서, 이에 따라, 호스트(14) 혹은 구체적으로는 메모리 컨트롤러(24)는 디램 메모리 인터페이스(16)에 대한 JEDEC에서 정의된 전송 포멧의 형태로 데이터 패턴들을 스토리지 장치(18)에 전송할 수 있다. 호스트(14)가 암호화를 수행하는 경우, 일련의 데이터 패턴은 각각의 암호화된 버전의 커맨드 데이터를 포함할 수 있다. 본 명세서의 통신 프로토콜에서, 64 단계의 일련의 데이터 패턴은 스토리지 장치(18)에 다음 데이터 패턴이 쓰이기 전에 미리 결정된 횟수 동안(예를 들어, 네 번) 다시 쓰일 수 있다. 예를 들어, 이는 메모리 컨트롤러(24)에 의해 수행될 수 있다. 스토리지 장치(18) 내의 장치 컨트롤러(48) 커맨드 데이터를 저장할 수 있다. 66 단계에서 설명된 바와 같이, 커맨드 데이터는 스토리지 장치(18) 내의 주소화가 가능한 스토리지(예를 들어, CAM(38)) 내의 일련의 쓰여진 데이터 패턴의 일부를 포함한다. 예를 들어, 이는 장치 드라이버 어플리케이션(28)에 의해 수행될 수 있다. 따라서, CAM(38)에 저장된 부분을 포함하는 커맨드 데이터는 해당 I/O 커맨드의 암호화된 버전을 포함할 수 있다. 예를 들어, I/O 커맨드는 호스트(14) 내의 메모리 컨트롤러(24)에 의해 발행된 디램 커맨드일 수 있다. 후술되는 바와 같이, 장치 컨트롤러(48) 내의 펌 웨어는 해당 메모리 동작을 CAM(38)에 저장된 각각의 암호화된 커맨드와 연관시킬 것이다.

특정 실시 예들에서, 64 단계 및 66 단계의 트레이닝은 호스트로부터 제공된 일련의 데이터 패턴 내의 각각의 데이터 패턴을 위해 수행될 것이다. 트레이닝 이후, 스토리지 장치(18) 내의 장치 컨트롤러(48)는 호스트 인터페이스 유닛(32)를 통해 (예를 들어) 호스트(14) 내의 메모리 컨트롤러(24)를 통해 컨트롤 비트 패턴을 제공받는다. 68 단계에서, 이러한 컨트롤 비트 패턴은 디램 메모리 인터페이스(16)와 같은 I/O 인터페이스를 통해 런 타임 때 제공받는다. 제공된 컨트롤 비트 패턴은 장치 컨트롤러(48)가 수행하기 위해서 해독이 필요한 암호화된 I/O 커맨드(예를 들어, 디램 커맨드)를 포함할 수 있다.

이러한 해독은 70 단계에서 기술된 것과 같이 수행될 수 있다. 즉, 장치 컨트롤러(48)는 미리 저장된 커맨드 데이터를 이용할 수 있다. 미리 저장된 커맨드 데이터는 68 단계에의 컨트롤 비트 패턴을 통해 제공된 I/O 커맨드(예를 들어, 디램 커맨드)를 해독하기 위해 주소화가 가능한 스토리지(예를 들어, CAM(38))의 일부를 포함할 수 있다. 이 경우, CAM 룩업 기반의 해독은 장치 컨트롤러(48)가 제공된 I/O 커맨드(예를 들어, 디램 커맨드)를 확인하고, 수행 하도록 한다.

도 4는 본 발명의 실시 예에 따라 스토리지 디바이스가 디램 인터페이스를 통해 메모리 동작과 관련된 상태 데이터를 호스트에 제공하기 위한 통신 프로토콜을 예시적으로 보여주는 순서도이다. 도 4를 참조하면, 도 4의 방법은 도 3의 68 단계에서 제공된 암호화된 I/O 커맨드(예를 들어 디램 커맨드)에 응답하여 수행되는 메모리 동작을 위해 적절한 상태 데이터를 호스트(14)에 제공하기 위해 스토리지 장치(18)가 트레이닝을 수행하는 것과 관련된다. 이러한 면에서 순서도(72)는 도 3의 순서도(58)를 보완할 수 있다. 호스트 기반의 CPU(22) 또는 메모리 컨트롤러(24)가 디램 메모리 인터페이스(16)를 통해 전송되는 메모리 커맨드의 암호화를 수행하는 경우, CPU(22) 또는 메모리 컨트롤러(24)는 스토리지 장치(18)로부터 제공되는 해당 상태 데이터를 이해해야 하고, 이후 이를 처리해야 한다. 따라서, 스토리지 장치(18)가 호스트(14)에 호스트(14)에 의해 인식되는 암호화 포멧의 형태로 상태 데이터를 제공하도록 하는 것이 바람직하다. 특정 실시 예들에서, 이것은 도 4에 도시된 프로토콜 트레이닝을 이용하여 수행될 것이다.

도 3의 60 단계에서 상술된 바와 같이, 장치 드라이버 어플리케이션(28)의 동작 제어 하에 호스트(14) 또는 장치 드라이버 어플리케이션(28)는 호스트(14)의 지원에 의해 스토리지 장치(18)가 표준화된 I/O 인터페이스(예를 들어, 디램 메모리 인터페이스(16))에 장착되었는지를 감지할 것이다. 이러한 감지를 기초로, 장치 드라이버 어플리케이션(28)는 프로토콜 트레이닝을 시작할 것이다. 74 단계에서, 프로토콜 트레이닝의 일부로서, 장치 드라이버 어플리케이션(28)는 호스트(14)에 I/O 인터페이스(예를 들어, 디램 인터페이스)를 통해 일련의 데이터 패턴들을 스토리지 장치(18)에 쓰도록 명령할 것이다. 특정한 실시 예들에서, 이에 따라, 호스트(14) 혹은 구체적으로는 메모리 컨트롤러(24)는 디램 메모리 인터페이스(16)에 대한 JEDEC에서 정의된 전송 포멧의 형태로 데이터 패턴들을 스토리지 장치(18)에 전송할 수 있다. 호스트(14)가 암호화를 수행하는 경우, 일련의 데이터 패턴은 각각의 암호화된 버전의 커맨드 데이터를 포함할 수 있다. 본 명세서의 통신 프로토콜에서, 74 단계의 일련의 데이터 패턴은 스토리지 장치(18)에 다음 데이터 패턴이 쓰이기 전에 미리 결정된 횟수 동안(예를 들어, 네 번) 다시 쓰일 수 있다.

일 실시 예로서, 75 단계에서, 스토리지 장치(18)는 DIMM 기반 SSD일 수 있다. 스토리지 장치(18) 내의 장치 컨트롤러(48)는 예시적으로 장치 드라이버 어플리케이션(28)에 의해 상태 데이터를 저장할 수 있다. 77 단계에서 설명된 바와 같이, 상태 데이터는 스토리지 장치(18) 내의 레지스터 내의 일련의 데이터 패턴의 부분을 포함할 수 있다. 이러한 후술되는 바와 같이 상태 레지스터(44) 혹은 다른 타입의 레지스터들/버퍼들(46)일 것이다. 특정 실시 예들에서, 이에 따라, 각각의 상태 데이터는 그것의 호스트에 의해 암호화 버전으로 저장된다. 즉, 이는 어떠한 역으로 분석하는 방법이나 호스트(14)에 의해 수행되는 특정 암호화 방법의 변형 없이 수행될 수 있다.

77 단계에서, 장치 컨트롤러(48) 내의 펌 웨어는 해당 디램 커맨드와 레지스터에 저장된 각각의 암호화된 상태 데이터들을 연관시킬 것이다. 특정 실시 예들에서, 74 단계 및 77 단계의 트레이닝은 호스트(14)로부터 제공된 일련의 데이터 패턴들 내의 각각의 데이터 패턴을 위해 수행될 것이다. 79 단계에서, 74 단계 및 77 단계의 트레이닝 이후, 스토리지 장치(18) 내의 장치 컨트롤러(48)는 호스트 인터페이스 유닛(32)를 통해 (예를 들어) 호스트(14) 내의 메모리 컨트롤러(24)를 통해 컨트롤 비트 패턴을 제공받는다. 이러한 커맨드는 런 타임에 디램 메모리 인터페이스(16)를 통해 제공될 것이다. 도 3의 실시 예에 따른 방법에서 설명된 바와 같이, 주소화가 가능한 스토리지(예를 들어, CAM(38))을 이용하여, 제공된 암호화된 커맨드는 장치 컨트롤러(48)에 의해 해독될 것이다. 79 단계에서, 결과적으로, 장치 컨트롤러(48)는 제공된 디램 커맨드의 해독된 버전과 연관된 메모리 동작(예를 들어, 메모리 읽기 동작, 메모리 쓰기 동작 등)을 수행할 것이다.

일 실시 예에서, 77 단계에서 저장된 부분들을 포함하는 상태 데이터가 저장된 레지스터에 접근하기 위하여, 장치 컨트롤러(48)는 버퍼 매니저(50)를 사용할 수 있다. 이는 도 4의 81 단계에 기술되었다. 83 단계에서, 메모리 동작의 결과에 기초하여(예를 들어, '성공적인', '실패한', '수행된', '수행되지 않은', '지연 중인' 등), 장치 컨트롤러(48)는 해당 상태 데이터의 부분을 레지스터로부터 검색할 것이다. 일 실시 예에서, 예를 들어, 버퍼 매니저(50)는 장치 컨트롤러(48)에 의해 적합한 상태 데이터 부분을 검색하기 위한 레지스터 인덱스 룩업을 사용하도록 구성될 것이다. 85 단계에서, 이 후, 79 단계에서 제공된 암호화된 I/O 커맨드(예를 들어, 디램 커맨드)에 응답하여, 장치 컨트롤러(48)는 검색된 상태 데이터 부분을 호스트(14) 혹은 호스트(14) 내의 메모리 컨트롤러(24)에 제공하기 위해 호스트 인터페이스 유닛(32)을 사용할 것이다. 검색된 상태 데이터는 그것의 호스트에 의해 제공된 암호화 버전으로부터 변경되지 않았기 때문에, 메모리 컨트롤러(24)는 쉽게 그것의 암호화 포멧을 인식하고, 해독 및 프로세싱을 수행할 것이다.

도 3 및 도 4는 본 발명에 따른 스토리지 장치(18)가 이후의 메모리 커맨드를 해독하고 호스트가 인식 가능한 암호화 포멧으로 관계된 상태 정보를 생성하기 위해, 암호화된 버전의 컨트롤 및 상태 정보를 호스트로부터(14) 제공받기 위한 통신 프로토콜의 일부로서 트레이닝되는 방법을 간략히 보여준다. 이 트레이닝은 호스트(14)가 스토리지 자치(18)에 컨트롤 정보를 전송하고, 표준화된 디램 메모리 인터페이스(16)와 같은 표준화된 I/O 인터페이스를 통해 스토리지 장치(18)로부터 상태 정보를 제공받을 수 있도록 한다. 프로토콜 트레이닝은 스토리지 장치(18)가 호스트(14)에 의해 전송된 암호화된 메모리 커맨드를 실행하기 위해 호스트(14)로부터 제공된 컨트롤 데이터를 해독하고, 호스트(14)에 메모리 커맨드의 실행 상태를 보고하기 위한 해당 상태 전보를 생성하도록 할 수 있게 한다. 도 3 및 도 4에서 간략히 상술된 바와 같이, 암호화된 메모리 커맨드들은 도 3의 도시된 순서도(58)에 도시된 CAM 기반의 룩업 방법을 이용하여 해독될 수 있다. 반면에, 상태 데이터는 도 4의 순서도(72)에 도시된 레지스터 검색 방법을 이용하여 호스트가 인식 가능한 암호화 방법에 의해 생성될 수 있다. 따라서, 스토리지 장치(18)의 트레이닝에 기초하여, 호스트(14)와 스토리지 장치(18) 사이의 통신은 디램 채널의 특정한 컨트롤 상태 데이터 포멧을 이용하여 표준화된 디램 메모리 인터페이스(16)를 통해 가능할 것이다.

도 5 및 도 6의 프로토콜 트레이닝을 설명하기 전에, 추가적인 상세한 구현 방법에 대해 간략히 설명될 것이다. 상술한 바와 같이, 일 실시 예에서, 스토리지 장치(18)은 블록 기반의 장치인 디램 메모리 채널의 DIMM 폼 펙터를 갖는 SSD일 수 있다. 따라서, 디램 메모리 인터페이스(16) 상의 디램 슬롯(미도시)에 장착됨에도 불구하고, 스토리지 장치(18)는 호스트(14)의 디램 메모리 맵에 나타나지 않을 수 있다. 하지만, 예를 들어 장치 드라이버 어플리케이션(28)를 위해, 이는 물리적으로 스토리지 장치(18)의 일부(예를 들어, RBU(40) 내의 레지스터들/버퍼들(46))에 주소를 할당하는 것이 가능할 수 있다. 따라서, 장치 드라이버 어플리케이션(28)은 RBU(40) 내의 컨트롤/상태/데이터 레지스터 및/또는 버퍼들에 읽기 및 쓰기 동작을 수행하기 위해 스토리지 장치(18)에 액세스 하기 위한 요청을 번역할 수 있다. 특정한 실시 예들에서, 장치 드라이버 어플리케이션(28)는 이러한 요청들을 OS(26) 또는 시스템 BIOS로부터 제공받을 것이다. 하지만, 메모리 컨트롤러(24)의 구현(칩 셀렉트와 관련된 구체적인 디램 메모리 채널의 매핑, 뱅크 선택, 그리고 로우/컬럼 어드레싱 등)은 RBU(40)내의 레지스터들/버퍼들(46)에 물리적으로 주소를 지정하는 것을 복잡하게 만들 것이다. 하지만, 장치 컨트롤러(48) 내의 펌 웨어는 스토리지 장치(18)이 설치된 곳에 관련된 메모리 컨트롤러(24)의 메모리 채널의 매핑, 뱅크 선택, 그리고 로우/컬럼 어드레싱을 발견할 수 있다. 예를 들어, 이는 시스템 부팅 시간에 수행되는 메모리 테스트 중에 시스템 BIOS와의 상호 작용을 통해 수행될 수 있다. 이후, 장치 컨트롤러(48)는 검색된 어드레스들을 다시 매핑(Re-map)할 수 있다. 이에, 스토리지 장치(18)의 내부 메모리는 장치 드라이버 어플리케이션(28)에 의해 보이는 것과 같이 근접한 어드레스 지역으로 조직화 될 수 있다. 예를 들어, 내부 메모리는 RBU(40) 내의 레지스터들/버퍼들(46), 불 휘발성/플레시 메모리 유닛(34), 그리고 존재 하는 경우에는 디램 메모리 유닛(36)일 수 있다. 따라서, 일반적인 디램 채널의 구체적인 신호들(예를 들어, 칩 선택, 뱅크 선택, 그리고 로우/컬럼 어드레스 스트로브 신호 등)은 스토리지 장치(18) 내의 적합한 메모리 영역(불 휘발성 및 휘발성 메모리 영역)으로 어드레스를 할당 하거나 매핑하기 위해 ‘에일리어스(Aliase)‘될 수 있다. 따라서, 후술되는 바와 같이, 메모리 컨트롤러(24) 의 스토리지 장치(18)에 대해 발견된 어드레스 공간에 대한 어드레스 매핑 및 재 매핑을 발견하는 과정은 프로토콜 트레이닝 과정의 시작 전에 수행된다고 가정한다.

스토리지 장치(18)를 수용하기 위해 BIOS가 변하는 불가능하거나 선호되지 않는 시스템들을 위해, 발견 부트 로더(Boot Loader) 어플리케이션은 스토리지 장치(18)와 동작하기 위한 장치 드라이버 어플리케이션(28)와 OS(26)를 올바르게 구현하기 위해 호스트(14)에 설치될 수 있다. 일 실시 예에서, 발견 부트 로더 명령들은 BIOS 명령들 후에 그리고 기존의 부트 로더 명령들 전에 수행될 것이다. 발견 부트 로더는 메모리 컨트롤러(24)가 유효 메모리 장치로서 스토리지 장치(18)를 올바르게 인식하기 위해, 시스템 발견 프로세스를 수행할 것이다. 이러한 발견 절차의 역할은 스토리지 장치(18)가 메모리 컨트롤러(24)의 메모리 맵에 맞는 곳을 결정하고, 이러한 매핑이 스토리지 장치(18)를 동작하기 위해 장치 드라이버 어플리케이션(28)에 의해 사용될 수 있는지 여부를 결정하는 것일 수 있다. 발견 부트 로더는 메모리 맵을 이해하기 위해 OS(26)에 의해 사용되는 메모리 맵 테이블들을 변경할 수 있다. 이는 OS(26)에 특정 메모리 공간이 스토리지 장치(18)에 대해 예약 되있음을 알리기 위함이다. 발견 부트 로더가 이러한 동작을 완료하고 BIOS 맵 테이블들에 대한 적합한 변경을 완료한 때, 기존의 부트 로더는 시작될 것이다. 일 실시 예에서, BIOS는 메모리 맵 정보를 OS(26)와 장치 드라이버 어플리케이션(28)에 통신하기 위해 ACPI(Advanced Configuration and Power Interface)와 같은 방법을 이용할 것이다.

특정 실시 예들에서, 도 3 및 도 4에서 도시되고 도 5 및 도 6에서 자세히 설명된 바와 같이, 호스트(14)와 연결(Linking)된 디램 메모리 인터페이스(16) 및 스토리지 장치(18)가 트레이닝된 후, 그리고 상술된 바와 같이, 호스트(14)의 장치 드라이버 어플리케이션(28)에 의해 보이는 것과 같은 스토리지 장치 기반의 물리적 어드레스 영역에 대한 논리적 어드레스 공간(예를 들면, OS(26)에 의해 사용됨)에 대한 매핑이 결정된 후에, 컨트롤/상태 프로토콜 트레이닝은 시작될 것이다. 특정 실시 예들에서, 디램 메모리 인터페이스(16)의 트레이닝은 (i) JEDEC에서 정의된 DDR4의 트레이닝 (ii) 디램 인터페이스에 대해 확장 메모리 PHY(Physical Layer)에 대한 트레이닝을 포함할 수 있다. 일 실시 예에서, 시스템 BIOS는 이러한 트레이닝 및 호스트(14)와 스토리지 장치(18) 간의 DDR 데이터 패스/채널의 계산을 수행할 것이다.

본 발명에 따른 컨트롤/상태 프로토콜 트레이닝을 위한 스토리지 장치(18)를 준비하기 위해, 특정한 부가적인 디자인 고려사항들이 적용될 수 있다. 예를 들어, 불 휘발성 스토리지의 스토리지 장치(18) 상의 필요한 ‘핸드쉐이킹(Handshake)’ 파라미터들(후술함) 및 매핑 정보가 있을 수 있다. 또한, 시스템(10) 내의 스토리지 장치(18)에 있는 장치 드라이버 어플리케이션(28), 시스템 BIOS의 초기화, 부트 로더는 측파대(Side-band) 통신 방법(예를 들어, POST(Power-On Self-Test) 또는 SPD(Serial Presence Detec) 동안의 호스트(14)로부터 DIMM SMBus(System Management Bus)로의 통신)을 이용하여 수행될 것이다. 일 실시 예에서, BIOS, 부트 로더, 또는 장치 드라이버 어플리케이션(28)는 다음의 컨트롤/상태 프로토콜 트레이닝을 위한 스토리지 장치(18)를 준비하기 위해 장치 컨트롤러(48) 내에 프로그램 가능한 로직을 구현할 수 있다.

장치 감지, 초기화, 그리고 어드레스 공간 매핑의 선행된 절차들은 스토리지 장치(18)가 처음으로 디램 메모리 인터페이스(16)에 장착된 것으로 발견되는 경우에 수행될 것이다. 추가적인 절차적 상세 사항들은 2014년 8월 21에 발행된 미국 특허 US 2014/0237176(Takefman et al.)로부터 얻어질 수 있다.

특정 실시 예들에서, 장치 컨트롤러(48)은 메모리 컨트롤러(24)로부터의 특정 순서에 의해 프로토콜 트레이닝 데이터(컨트롤 및 상태 데이터)를 예측하기 위한 하드웨어/펌웨어의 형태로 선행되어 설정될 수 있다. 또한, 장치 컨트롤러(48)는 호스트(14)가 미리 결정된 횟수(후술함)로 각각의 프로토콜 트레이닝 데이터를 반복하여 전송하는 것을 예측하기 위해 선행되어 구현될 수 있다. 이러한 선행 구현(Pre-Configuration)은 어떤 순서에 의해서 인지와 호스트(14)로부터 예측되는 것을 위해 장치 컨트롤러(48)가 준비하는 스테이트 머신 기반의 구현일 수 있다. 장치 컨트롤러(48)는 또한 I/O 커맨드/상태 정보의 타입 및 프로토콜 트레이닝 단계 중에 호스트(14)에 의해 보내질 I/O 커맨드 상태 정보(예를 들어, 디램 커맨드/상태 정보)를 알도록 만들어질 수 있기 때문에, 이러한 선행 구현은 장치 컨트롤러(48)가 트레이닝 단계 중에 내부적으로 각각의 제공된 암호화된 커맨드 및 상태 정보를 해석하도록 한다. 예를 들어, 만약 하드웨어의 선행 구현이 메모리 읽기 커맨드가 트레이닝 단계의 처음에 호스트(14)로부터 제공된 첫 번째 커맨드가 될 것이라고 나타내는 경우에, 장치 컨트롤러(48)는 하드웨어/펌웨어의 형태로 구현될 수 있다. 이는 적합한 내부 메모리 패치 동작을 트레이닝 단계 중에 CAM(38)과 같은 주소화가 가능한 스토리지 내에 저장된 암호화된 버전의 메모리 읽기 커맨드에 할당하여 이 커맨드를 해석하기 위함이다.

트레이닝 후에, 런 타임 때 암호화된 커맨드가 호스트(14)로부터 제공되고 메모리 읽기 커맨드로서 해독될 때, 장치 컨트롤러(48)는 간단하게 프로토콜 트레이닝 단계 중에 미리 내부적으로 할당된 커맨드 특정 메모리 패치 동작을 수행할 수 있다. 예를 들어, 메모리 패치 동작은 어드레스 번역, 내부 불 휘발성/플레시 메모리 유닛(34)내의 특정 메모리 유닛에의 접근, 접근한 메모리 유닛으로부터 저장된 내용의 검색 등을 포함할 수 있다. 이러한 식으로, 제공된 커맨드는 암호화 알고리즘을 역으로 해석할 필요 없이 수행될 수 있다. 프로토콜 트레이닝 단계 중에 호스트(14)로부터 제공된 각각의 암호화된 커맨드 및 상태 정보는 비슷하게 처리 될 수 있다. 결과적으로, 프로토콜 트레이닝의 결론에서, 디램 메모리 인터페이스(16)를 통해 수행된 통신의 호스트 특정의 암호화에도 불구하고, 스토리지 장치(18)는 디램 메모리 인터페이스(16)를 통해 호스트(14)와의 통신을 준비한다.

스토리지 장치(18)이 SSD와 같은 블록 기반의 불 휘발성 메모리인 경우에, 특히 특정 디램 채널 커맨드 혹은 상태 정보가 유일하게 기존 디램 기반의 DIMM에만 적용 가능한 경우에, 트레이닝 단계 중에 특정 디램 채널 커맨드 혹은 상태 정보를 이러한 블록 기반 스토리지 장치에 전송할 필요가 없을 수 있다. 일 실시 예로서, 이러한 경우, JEDEC에서 정의된 디램 채널 특정의 컨트롤/상태 정보의 집합은 트레이닝 단계 중에 스토리지 장치(18)에 제공되고, 후에 런 타임 중에 교환될 수 있다.

도 5는 본 발명의 실시 예에 따른 프로토콜의 트레이닝 과정 동안의 컨트롤 데이터 및 상태 데이터를 위한 레지스터 기반의 스토리지 구성을 보여주는 그림이다. 도 5를 참조하면, 도 2의 RBU(40) 내의 다양한 레지스터들은 컨트롤 레지스터(42), 상태 레지스터(44), 그리고 복수의 다른 레지스터들/버퍼들(46)을 포함할 수 있다. 특정 실시 예에서, 상술된 바와 같이, 장치 드라이버 어플리케이션(28)과 스토리지 장치(18) 간의 '핸드쉐이킹'은 프로토콜 트레이닝 모드에 대해 장치가 준비하도록 만들 수 있다. 예를 들어, DIMM 기반의 SSD와 같은 I/O 스토리지 장치의 경우, '핸드쉐이킹'은 장치 드라이버 어플리케이션(28)이 트레이닝 과정 중에 SSD를 '글로벌 구성' 모드에 위치시키도록 할 수 있다. 일 실시 예에서, RBU(40) 내의 각각의 레지스터는 64 바이트의 디램 버스트(ECC가 없는 경우)를 저장할 수 있고, 도 5에 도시된 것과 같이 이와 관련된 오프셋 어드레스를 가질 수 있다. 예를 들어, 장치 컨트롤러(48) 내의 버퍼 매니저(50)는 내부적으로 16 진법의 오프셋 어드레스 '0x0'을 컨트롤 레지스터(42)에 연관시키고, 오프셋 어드레스 '0x40'을 상태 레지스터(44)에 연관시키는 등의 동작을 할 수 있다. 하지만, 하지만, ECC가 시스템(10)에 존재하는 경우, ECC의 해당 8 바이트(8 비트의 원래 데이터 당 ECC의 1비트)에 의해 수반된 64 바이트의 원래의(Raw) 데이터인 호스트 ECC 데이터를 수용하기 위해, 각각의 레지스터는 최대 72 바이트를 수신하고 저장하도록 설정될 수 있다. 예를 들어, 도 5의 64 바이트 레지스터 스토리지 구성 내의 컨트롤 레지스터(42)인 경우, 버퍼 매니저(50)은 컨트롤 레지스터(42)에 원래의 컨트롤 데이터의 64 바이트를 저장하도록 구현될 수 있다. 반면, 예를 들어 '0x80', '0xC0', '0x100' 등의 오프셋 어드레스를 갖는 레지스터와 같이, ECC 데이터의 8 바이트는 RBU(40) 내의 다른 레지스터들/버퍼들(46)의 어떠한 레지스터 내에도 저장될 수 있다. 이러한 경우, '컨트롤 레지스터'라는 용어는 ECC 부분을 저장하는 레지스터와 마찬가지로 총괄적으로 컨트롤 레지스터(42)를 나타낼 수 있다. 트레이닝 동안, 상태 데이터의 72 바이트는 마찬가지로 유사하게 저장될 수 있다. 따라서, 특정 실시 예들에서, ECC 데이터는 매핑될 필요가 없을 수 있다.

특정 실시 예들에서, 레지스터 특정의 오프셋 어드레스들은 드라이버 장치 핸드쉐이킹 중에 장치 컨트롤러(48)에 의해 장치 드라이버 어플리케이션(28)로 전달될 수 있다. 또한, 스토리지 장치(18) 자체는 그것과 연관된 기초 어드레스를 가질 수 있다. 예를 들면, 이는 호스트(14)의 BIOS 내에서 생성된 메모리 맵 안에 있을 수 있다. 일 실시 예에서, 메모리 컨트롤러(24)는 장치 드라이버 어플리케이션(28)에 의해 RBU(40) 내의 특정 레지스터에 접근하기 위해 기초 어드레스와 함께 오프셋 어드레스를 사용하도록 작동 가능하도록 구성될 수 있다. 따라서, 프로토콜 트레이닝의 첫 번째 단계는 적어도 하나의 컨트롤 레지스터(42)를 셋업/설립하고, 메모리 어드레스(스토리지 장치(18)의 기초 어드레스 + 0x0)를 그것에 연관시키고, 또한 적어도 하나의 상태 레지스터(44)를 셋업하고 해당 메모리 어드레스(스토리지 장치(18)의 기초 어드레스 + 0x40)를 그것과 연관시켜 남은 프로토콜 트레이닝 중에 DIMM 기반의 스토리지 장치(18)와 호스트(14) 사이에 통신이 발생할 수 있도록 하는 것일 수 있다. 이후, 프로토콜 트레이닝 과정 중에, 장치 드라이버 어플리케이션(28)는 메모리 컨트롤러(24)가 복수의 컨트롤/상태 비트 패턴들을 컨트롤/상태 레지스터와 연관된 메모리 어드레스에 쓰도록 명령할 수 있다. 이는 후술될 것이다. 예를 들어, 이는 장치 드라이버 어플리케이션(28)를 운영하는 OS(26)의 CPU의 실행을 통하여 이루어 질 수 있다.

일반적으로 디램 메모리 인터페이스(16)의 어드레스/커맨드 버스를 통해 전송되는 메모리 커맨드들 및 다른 컨트롤 신호들은 스토리지 장치(18)에 의해 인식될 수 없을 수 있다. 이는 스토리지 장치(18)는 도 1의 디램 메모리 모듈(20)과 같이 기존의 디램 모듈이 아니기 때문이다. 따라서, 특정 실시 예들에서, 프로토콜 트에니이 및 이후의 런 타임 동안에, 디램 메모리 인터페이스(16)의 데이터 버스 부분은 메모리 컨트롤러(24)에 의해 이러한 이진(Binary) 형태의 신호들을 스토리지 장치(18)로 전송하도록 사용될 수 있다. 하지만, 기존의 디램 채널 통신에서, 데이터는 보통 디램 버스트(예를 들어, 64 바이트의 디램 버스트, 혹은 ECC인 경우에는 72 바이트)로서 데이터 버스 상에 전송된다. 따라서, 프로토콜 트레이닝 동안 각각의 데이터(컨트롤 혹은 상태) 쓰기 동작은 메모리 컨트롤러(24)에 의해 64 바이트의 디램 버스트로서 전송된다. 하지만, 일반적으로, 64 바이트의 버스트 중에 오직 첫 번째 바이트만이 실제 커맨드 혹은 상태 정보를 포함할 수 있다. 예를 들어, 다른 바이트들은 컨트롤/상태 쓰기 동작을 위한 64 바이트의 버스트를 생성하기 위해 메모리 컨트롤러(24)에 의해 불필요하게 더해진 더미 데이터 혹은 무관한 데이터 비트들을 포함할 수 있다. 예를 들어, 이는 암호화 방법에 의해 요구될 수 있다. 따라서, 스크램블링(Scrambling), 비트/바이트 스위즐링/스틸링(Swizzling/Steering), 데이터 인터리빙, ECC 혹은 다른 어떠한 타입의 암호화 방법의 레벨에 따라 호스트(14)로부터 제공된 64 바이트 중 한 바이트만큼 작은 부분은 컨트롤/상태 레지스터에서 유용한 부분일 수 있다. 이는 도 5에 도시된 각각의 레지스터내의 스토리지 공간의 한 바이트를 통칭하여 나타내기 위하여 상징적으로 동일한 참조 번호 '88'을 이용하여 도시되었다. 하지만, 특정 실시 예들에서, 데이터 버스트 내의 한 바이트 이상은 원래(Raw)의 커맨드/상태 정보를 전달하기 위해 사용될 수 있다.

컨트롤 또는 상태 데이터를 포함하는 각각의 디램 버스트는 여기서 '데이터 패턴'으로서 나타낼 수 있다. 컨트롤 데이터의 문맥에서, 각각의 데이터 패턴은 '컨트롤 비트 패턴'으로서 나타낼 수 있다. 이는 각각의 디램 커맨드에 대한 암호화된 버전을 포함할 수 있다. 후술하는 바와 같이, 스토리지 장치(18) 내의 장치 컨트롤러(48)는 런 타임에서 이후의 룩업을 위한 주소화가 가능한 스토리지(예를 들어, CAM(38)) 내에 저장된 제공된 컨트롤 비트 패턴의 '커맨드 데이터의 포함 부분'을 선택할 수 있다. 따라서, 비록 '컨트롤 데이터'와 '커맨드 데이터'는 여기서 일반적으로 상호 교환 가능한 용어로 사용되었지만, 두 용어들은 단지 디램 커맨드 데이터(암호화 되거나 암호화 되지 않은 데이터)가 실제로 호스트(14)로부터 제공된 전체 컨트롤 데이터 패턴의 일부분을을 구성할 수 있다는 것을 나타내기 위하여 때때로 구분되었다. 유사하게, 상태 데이터 트레이닝의 문맥상에서, 호스트(14)로부터 제공된 각각의 데이터는 암호화된 버전의 각각의 상태 데이터를 포함할 수 있다. 장치 컨트롤러(48)는 이후 적합한 런 타임에서 이후의 룩업을 위한 RBU(40) 내의 레지스터 내에 있는 '상태 데이터 포함 부분'을 선택하고 저장할 수 있다.

컨트롤 프로토콜 트레이닝 과정을 참조하면, 관련된 JEDEC에서 정의되거나 표준화된 디램 커맨드들은 커맨드 당 유일한 8-비트 데이터 패턴을 이용하여 전송될 수 있다. 따라서, 트레이닝 과정 중의 첫 번째 단계는 장치 드라이버 어플리케이션(28)를 위해 메모리 컨트롤러(24) 또는 CPU(22)가 순서대로 커맨드 데이터의 단일 바이트(0에서 255 범위의 값)를 오프셋 어드레스 '0x0'을 갖는 컨트롤 레지스터(42)에 쓰는 것이 가능하도록 구성하는 것이다. 후술하는 바와 같이, 이러한 단일 바이트는 64 바이트(ECC가 없는 경우) 또는 72 바이트(ECC가 있는 경우) 디램 버스트를 이용하여 전송될 수 있다. 도 5의 실시 예에서, 동일한 컨트롤 레지스터(42)는 각각의 연속적으로 제공된 컨트롤 비트 패턴을 저장하기 위해 사용되고/주소를 할당받을 수 있다. 특정 실시 예들에서, 각각의 바이트 값은 미리 정해진 횟수로 반복되어 쓰일 수 있다. 일 실시 예에서, 미리 정해진 숫자는 장치 드라이버 어플리케이션(28)를 통해 유저가 프로그램 가능할 수 있다. 예를 들어, 일 실시 예에서, 커맨드 데이터의 각각의 바이트는 다음의 순서(0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, ......, 254, 254, 254, 254, 255, 255, 255, 255)로 네 번씩 순서대로 쓰일 수 있다. 일 실시 예에서, 컨트롤 레지스터(42) 이외에도, 모든 컨트롤 비트 패턴들이 동일 컨트롤 레지스터(42)에 주소를 할당 받은 경우에도, RBU(40) 내의 레지스터들/버퍼들(46) 내의 레지스터들은 내부적으로 버퍼 매니저(50)에 의해 동일한 컨트롤 비트 패턴의 반복된 전송을 저장하기 위해 사용될 수 있다. 상술된 바와 같이, 암호화가 호스트(14)에 의해 수행되는 경우, 각각의 원래의 커맨드 바이트는 ECC와 함께 첨부되거나 스크램블(또는 비트/바이트 스위즐/스티어링)될 수 있다. 이후, 각각의 원래의 커맨드 바이트는 메모리 컨트롤러(24)에 의해 컨트롤 비트 패턴으로서 반복적으로 스토리지 장치(18)로 전송될 수 있다. 컨트롤 비트 패턴은 64 바이트(ECC가 없는 경우) 혹은 72 바이트(ECC가 있는 경우) 디램 버스트일 수 있다. 예를 들어, 해당 컨트롤 비트 패턴의 형태를 갖는 각각의 커맨드 바이트 값은 드물게 발생하는 비트 에러로부터 보호하기 위하여 네 번 전송될 수 있다. 따라서, 동일한 컨트롤 비트 패턴의 반복된 전송은 데이터 무결성(Integrity)의 확인을 제공할 수 있다. 만약, 네 번의 컨트롤 비트 패턴들이 동일하지 않다면, 장치 컨트롤러(48)는 각각의 비트 포지션에 대해 네 번 중에 세 번의 매칭 패턴을 찾을 수 있다. 반면에, 만약 비트 포지션이 두 개의 논리 '1' 및 두 개의 논리 '0'을 포함한다면, 장치 컨트롤러(48)는 에러 상태를 장치 드라이버 어플리케이션(28)에 보고할 수 있다. 에러 상태는 디램 메모리 인터페이스(16)과 같은 I/O 채널이 사용 불가능하거나 I/O 채널이 다시 트레이닝되어야 할 수 있다는 것을 의미할 수 있다.

암호화가 존재하는 경우, 각각의 컨트롤 비트 패턴은 암호화된 버전의 해당 커맨드 패턴 바이트를 포함한다. 하지만, 암호화(예를 들어, 스크램블링(Scrambling), 비트/바이트 스위즐링/스틸링, 데이터 인터리빙 등) 때문에, 제공된 컨트롤 비트 패턴 내의 커맨드 데이터 포함 부분은 한 바이트 이상의 길이를 가질 수 있다. 예를 들어, 메모리 컨트롤러(24)에 의해 수행되는 스크램블링 단위(Granularity)는 구현에 특화될 수 있고, 64 바이트(또는 72 바이트)의 컨트롤 비트 패턴보다 작거나 큰 섹션(Section)을 통해 커맨드 데이터 비트들을 분산시키는 결과를 가져올 수 있다. 따라서, 컨트롤 비트 패턴을 제공받으면, 장치 컨트롤러(48) 내의 로직은 컨트롤 비트 패턴 내의 커맨드 데이터 포함 부분을 결정해야 할 필요가 있을 수 있다.

특정 실시 예들에서, 예상되는 커맨드 데이터와 예상 순서에 대한 지식을 기초로, 장치 컨트롤러(48)는 각각의 컨트롤 비트 패턴(메모리 컨트롤러(24)에 의해 전송된 연속된 형태의 컨트롤 비트 패턴) 내의 암호화된 버전의 커맨드 데이터의 비트 포지션에 대한 통계적인 분산을 평가할 수 있다. 또한, 예를 들어 스크램블링이 있는 경우, 장치 컨트롤러(48)는 선택적으로 분포의 임의성(Randomness) 레벨을 추정할 수 있다. 평가 및 추정을 기초로, 장치 컨트롤러(48)는 평가된 비트 포지션 내의 커맨드 데이터 비트들을 식별 할 수 있다. 이러한 식별된 커맨드 비트들을 포함하는 데이터 부분은 각각의 컨트롤 비트 패턴의 커맨드 데이터 포함 부분으로서 간주될 수 있다. 특정 실시 예들에서, 식별된 데이터 비트들을 포함하는 커맨드 데이터 포함 부분만이 CAM(38)에 저장될 수 있다. 이는 도 6을 참조하여 설명될 것이다. 따라서, CAM(38)에 저장된 비트의 수는 메모리 컨트롤러(24)에 의해 수행된 스크램블링 레벨에 의존할 수 있다.

커맨드 데이터 포함 부분은 컨트롤 프로토콜 트레이닝 과정 중에 스토리지 장치(18) 혹은 구체적으로는 도 2 및 도 7의 실시 예에서 CAM(38) 내에 저장된 '트레이닝된 값'으로 간주될 수 있다. 특정 실시 예들에서, 상술된 바와 같이, 각각의 컨트롤 비트 패턴의 디램 버스트에 대한 트레이닝된 값은 스트램블링 및 다른 암호화 레벨에 따라 다음의 비트의 수 중 하나를 포함할 수 있다. ECC가 없는 경우 64 비트, 또는 ECC가 있는 경우 72 비트, ECC가 없는 경우 128 비트, 또는 ECC가 있는 경우 144 비트, 또는 ECC가 없는 경우 256 비트, 또는 ECC가 있는 경우 288 비트 등. 호스트(14)로부터 제공된 각각의 컨트롤 비트 패턴과 연관된 트레이닝된 값은 CAM(38) 내에 저장될 수 있다.

상태 프로토콜 트레이닝에 대한 동일한 과정이 반복될 수 있으므로, 상태 프로토콜 트레이닝에 대해서는 간략히 설명될 것이다. 상태 데이터를 포함하는 트레이닝 데이터 패턴들은 오프셋 어드레스 '0x40'을 갖는 상태 레지스터(44)에 쓰일 수 있다. 각각의 데이터 패턴은 미리 정해진 횟수(예를 들어, 컨트롤 비트 패턴의 경우 네 번) 동안 반복될 수 있다. 상술된 바와 같이, 동일한 데이터 패턴의 반복된 전송에 대한 미리 정해진 횟수는 예를 들어 장치 드라이버 어플리케이션(28)를 통해 유저가 프로그램 가능할 수 있다. 상태 프로토콜 트레이닝의 경우, 포착된 값 또는 상태 데이터 포함 부분들은 컨트롤 프로토콜 트레이닝과 관련하여 포착된 값과 다를 수 있다. 이는 트레이닝 순서(0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, ......, 254, 254, 254, 254, 255, 255, 255, 255)가 두 경우에 동일한 경우에도 마찬가지이다. 데이터 스크램블링은 어드레스 종속성을 갖고 컨트롤 및 상태 레지스터들은 이와 연관된 다른 메모리 주소들을 갖기 때문에, 이 값들은 다를 수 있다. 또한, ECC가 존재하는 경우, ECC는 스토리지 장치(18)에 전송되는 상태 데이터 패턴 내에 추가적인 차이점을 발생시킨다. 따라서, 데이터 포획 단계를 각각의 컨트롤 레지스터(42) 및 상태 레지스터(44)에 대하여 분리하여 수행하는 것이 바람직할 것이다. 다시 말해, 컨트롤 프로토콜 트레이닝은 상태 프로토콜 트레이닝과 분리되어 수행되어야 할 것이다.

일 실시 예에서, 상태 레지스터는 RBU(40) 내의 레지스터(44) 및 내부적으로 버퍼 매니저(50)에 의해 엑세스되는 다른 레지스터들을 포함할 수 있다. 특정 실시 예들에서, 모든 상태 데이터 포함 부분들은 단일 상태 레지스터(44)에 저장될 수 있다. 단일 상태 레지스터(44)는 256 엔트리들, 64 비트(ECC가 없는 경우) 혹은 72 비트(ECC가 있는 경우) 혹은 그 이상을 갖는 각각의 엔트리를 저장하도록 구성될 수 있다. 또는, 다른 실시 예들에서, 상태 레지스터(44)는 단순하게 디램 버스트 기반의 상태 데이터 패턴(64 바이트 혹은 72 바이트)를 수신할 수 있다. 상태 데이터 포함 부분들은 RBU(40) 내의 하나 또는 레지스터들/버퍼들(46) 내의 복수의 다른 레지스터들 내에 저장될 수 있다. 버퍼 매니저(50)는 내부적으로 RBU(40) 내의 다양한 레지스터들에 엑세스하는 것을 관리하고 필요한 경우에 레지스터에 저장된 내용의 검색을 수행할 수 있다.

만약 상술한 컨트롤 트레이닝 혹은 상태 트레이닝 중에 어떠한 하나의 트레이닝 단계가 실패하는 경우, 상대적으로 긴 시간(예를 들어, 10ms)을 기다리고 트레이닝은 재 시작하는 것이 바람직할 수 있다. 특정 실시 예들에서, 스토리지 장치(18)는 트레이닝 단계 중에 2ms 동안 어떠한 값도 수신하지 않는 경우에 중지되도록 구현될 수 있다. 그리고, 스토리지 장치(18)는 트레이닝이 다시 시작될 것이라고 추정할 수 있다.

컨트롤 및 상태 레지스터에 대한 프로토콜 트레이닝이 끝나면, 호스트 특정의 암호화 방법과 관계 없이, 표준화된 I/O 채널을 통해 통신하도록 호스트(14) 및 스토리지 장치(18)에 대한 메커니즘이 수행된다. 예를 들어, 런 타임에서, 장치 드라이버 어플리케이션(28)를 실행하는 호스트(14)는 커맨드 바이트를 컨트롤 데이터 패턴을 사용하는 디램 버스트를 스토리지 장치(18) 상의 오프셋 어드레스 '0x0'(컨트롤 레지스터(42)를 나타냄)에 쓸 수 있다. 일 실시 예에서, 장치 컨트롤러(48)는 먼저 수신된 컨트롤 데이터 패턴 내의 커맨드 데이터 포함 부분을 결정할 수 있다. 이후, 장치 컨트롤러(48)는 해독된 부분과 관련된 각각의 커맨드 바이트를 결정하기 위해 제공된 커맨드 데이터 포함 부분을 해독하기 위해 72 비트 의 암호화된 값(상술된 바와 같이, 저장된 커맨드 데이터 포함 부분을 위해 저장된 다른 어떠한 비트 사이즈)의 256 모두의 CAM(38) 룩업을 수행할 수 있다. 상술된 바와 같이, 장치 컨트롤러(48) 내의 펌 웨어는 커맨드 바이트와 커맨드를 수행하기 위해 필요한 관련된 메모리 동작들을 식별할 수 있다. CAM(38) 룩업은 도 6을 참조하여 설명될 것이다. 유사하게, 스토리지 장치(18)는 호스트(14)가 읽을 수 있는 적합한 상태 데이터 포함 부분을 쓰거나 생성할 수 있다. 예를 들어, 커맨드 실행 결과에 따라, 혹은 상태 정보 가 호스트(14)에 보고될 필요가 있는 경우에 런타임 중에 아무 때나, 커맨드 실행에 대한 메모리 동작의 결과에 기초하여 장치 컨트롤러(48)내의 펌 웨어는 커맨드 수행 결과를 보고하기 위해 적합한 상태 바이트를 결정할 수 있다. 이어, 호스트(14)에 다시 보고하기 위한 올바른 72 비트의 암호화된 값 혹은 상술된 바와 같이 저장된 상태 데이터 포함 부분을 위해 사용된 다른 어떠한 비트 사이즈을 식별/생성하기 위해, 장치 컨트롤러(48)는 상태 레지스터(44) 혹은 상태 프로토콜 트레이닝 과정 중에 저장된 상태 데이터 포함 부분이 저장된 다른 어떠한 레지스터에 대한 인덱스 룩업을 수행할 수 있다. 런 타임에서, 식별된 상태 데이터 포함 부분은 RBU(40) 내의 상태 레지스터(44) 혹은 상태 레지스터로 기능하는 다른 레지스터에 쓰일 수 있다. 식별된 값은 상태 트레이닝 과정 중에 메모리 컨트롤러(24)로부터 처음에 수신된 것과 같은 동일한 암호화 포멧으로 저장되기 때문에, 메모리 컨트롤러(24)는 올바르게 이를 해독(역스크램블링(De-Scramble, ECC 등)하고 상태 정보를 CPU(22)에 보고할 수 있다. 메모리 컨트롤러(24)는 장치 드라이버 어플리케이션(28)에 의해 스토리지 장치(18)에 의해 보고되는 상태 값을 검색하기 위해 적합한 레지스터를 읽도록 구현될 수 있다. 수신된 컨트롤 데이터 패턴을 해독하는데 필요한 두 데이터 값의 비교와의 대조적으로, 상태 데이터 생성은 이러한 비교를 요구하지 않는다. 따라서, 특정 실시 예들에서, 상태 데이터 포함 부분을 위한 어떠한 CAM 기반의 스토리지도 사용할 필요가 없을 수 있다.

일반적으로 디램 버스트의 한 바이트는 컨트롤 또는 상태 데이터를 포함할 수 있다. 따라서, 전체 256 데이터 패턴들은 컨트롤/상태 프로토콜 트레이닝 동안 사용될 수 있다. 관련 바이트는 디램 버스트 내의 첫 번째 바이트일 수 있다. 하지만, 이는 항상 동일하지 않다. 예를 들어, 다른 실시 예들에서, 디램 버스트 내의 하나 이상의 바이트는 컨트롤/상태 데이터를 전송하기 위해 필요할 수 있다. 따라서, 256 데이터 패턴 기반의 설명은 단순히 예시적인 것이다. 특정 실시 예들에서, 컨트롤 및 상태 프로토콜 트레이닝을 위한 데이터 패턴들의 전체 수는 256 보다 적거나 많을 수 있다. 또한, 컨트롤 프로토콜 트레이닝을 위한 데이터 패턴들의 전체 수는 상태 프로토콜 트레이닝에 대한 데이터 패턴들의 전체 수와 다를 수 있다. 추가적으로, 특정 실시 예들에서, 트레이닝 밴드위스를 증가시키기 위한 복수의 컨트롤 레지스터(42) 및 복수의 상태 레지스터(44)가 있을 수 있다. 예를 들어, 복수의 레지스터 구성에서, 트레이닝 데이터의 밴드위스를 증가시키기 위해 각각의 레지스터는 특정 세트 또는 컨트롤/상태 정보의 타입과 연관될 수 있다. 각각의 레지스터는 그 자체의 메모리 어드레스 또한 할당할 수 있다. 또한, 각각의 레지스터는 독립적으로 메모리 컨트롤러(24)에 의해 주소를 할당받을 수 있다.

도 6은 본 발명의 실시 예에 따른 도 2에 도시된 스토리지 장치 내의 CAM의 구조를 단순화하여 보여주는 블록도이다. 유저가 메모리 어드레스를 공급하고 메모리가 그 주소에 저장된 데이터 워드를 반환하는 RAM 또는 DRAM과 같은 표준 컴퓨터 메모리와 달리, CAM(38)은 유저가 데이터를 공급하고, 그 데이터 워드가 전체 메모리 내에 저장되어 있는지 여부를 보기 위하여 CAM(38)이 그것의 전체 메모리를 검색하도록 설계 된다. 만약 데이터 워드가 발견되면, CAM(38)은 데이터 워드가 발견된 CAM(38) 내의 하나 또는 복수의 스토리지 주소의 목록을 반환할 수 있다. 다른 실시 예들에서, CAM(38)은 또한 데이터 워드 또는 다른 관련 데이터 조각들을 반환할 수 있다. CAM(38)에 의해 반환된 스토리지 어드레스에 기초하여, 장치 컨트롤러(48)는 CAM(38) 내의 그 어드레스에 접근하고 해당 데이터를 검색할 수 있다. 따라서, 도 6의 실시 예에서, CAM(38)은 CAM 입력(90)으로서 검색될 내용(여기서는 커맨드 데이터 포함 부분)을 수신할 수 있다. 상술된 바와 같이, CAM 입력(90)은 런 타임에 호스트(14)로부터 수신된 컨트롤 데이터 패턴으로부터 추출된 커맨드 데이터 포함 부분일 수 있다. 수신된 입력은 CAM(38) 내의 검색 레지스터(92)내에 저장될 수 있다. 이어, CAM(38) 내의 로직 회로(미도시)들은 CAM에 저장된 내용(94) 상의 검색 동작(93)을 수행할 수 있다. CAM에 저장된 내용(94)이 저장된 곳은 컨트롤 프로토콜 트레이닝 과정 동안 생성된 트레이닝된 데이터를 대표하는 모든 커맨드 데이터 포함 부분들이 저장된 곳일 수 있다.

상술한 예시적인 컨트롤 프로토콜 트레이닝의 문맥에서, CAM에 저장된 내용(94)은 256 엔트리들, 64 비트(ECC가 없는 경우) 혹은 72 비트(ECC가 있는 경우)를 갖는 각각의 엔트리, 혹은 그 이상을 포함할 수 있다. 만약, 검색 레지스터(92)의 내용이 CAM에 저장된 내용(94) 내에 존재하는 어떠한 엔트리와 매칭되는 경우, CAM(38)은 CAM 출력(96)을 생성할 수 있다. CAM 출력(96)은 CAM에 저장된 내용(94)의 부분 내의 매칭되는 위치의 주소와 일치하는 내용을 제공할 수 있다. 상술한 바와 같이, 매칭되는 내용은 CAM 입력(90)과 매칭되는 컨트롤 프로토콜 과정 중에 저장된 커맨드 데이터 포함 부분일 것이다. 상술된 바와 같이, 해독된 부분과 관련된 각각의 커맨드 바이트를 결정하고 이후 커맨드를 실행하기 위해, CAM 출력(96)은 CAM 입력(90)에 대해 수신된 커맨드 데이터 포함 부분을 해독하기 위해 장치 컨트롤러(48)에 의해 사용될 수 있다. CAM 룩업은 단일 클록 사이클 내에 발생할 필요가 없을 수 있다. 또한, 적합한 데이터 구조에 대한 하드웨어 지원은 매칭된 내용의 검색으로부터 성능에 미치는 영향을 감소시킬 수 있다. 예를 들어, 적합한 데이터 구조는 컨트롤 프로토콜 트레이닝 이후 룩업의 시작 전에 CAM 내용을 트리 구조 내에 미리 조직화한 구조일 수 있다.

도 7은 본 발명의 실시 예에 따라 도 1 및 도 2에 도시된 스토리지 장치 내에 유저 데이터가 저장되는 방법을 예시적으로 보여주는 순서도이다. 도 7 및 도 8의 실시 예를 참조하면, 유저 데이터의 저장 및 검색은 도 3 내지 도 6에서 상술한 컨트롤/상태 데이터의 저장 및 검색과 다를 수 있다. 도 7의 순서도(100)는 암호화가 호스트(14)에 의해 수행될 때의 유저 데이터의 저장과 연관된다. 특정 실시 예들에서, 순서도(100)에 도시된 다양한 운영적인 측면들은 스토리지 장치(18)에 의해 수행될 수 있다. 예를 들어, 이는 장치 드라이버 어플리 케이션(28) 및 장치 드라이버(30)의 동작 제어 하에 스토리지 장치(18) 내의 장치 컨트롤러(48)에 의해 수행될 수 있다. 하지만, 설명의 편의를 위해, 특정 방법의 과정을 수행하는 개체/개체들의 구체적인 식별은 때로는 생략될 수 있다. 다시 도 7을 참조하면, 101 단계에서, 스토리지 장치(18)는 처음에 호스트(14)에 의해 지원되는 I/O 인터페이스(예를 들어, 디램 메모리 인터페이스(16))를 통해 동작하고 장착될 수 있도록 구현될 수 있다. 또한, 스토리지 장치(18)는 호스트(14)로부터 제공된 유저 데이터를 스토리지 장치(18) 내의 복수의 버퍼들 내에 저장하도록 구현될 수 있다. 도 8에 도시된 버퍼 구성은 후술될 것이다. 특정 실시 예들에서, 버퍼 구성은 복수의 동일한 사이즈의 버퍼들을 포함할 수 있다. 특정 실시 예들에서, 상술된 바와 같이, 스토리지 장치(18)는 도 7의 102 단계에서 언급된 바와 같이 DIMM 기반의 SSD일 수 있다. 104 단계에서, 예를 들어 메모리 쓰기 동작의 일부로서, 스토리지 장치(18)는 디램 메모리 인터페이스(16)과 같은 I/O 인터페이스를 통해 호스트(14)로부터 다음의 것들을 수신할 수 있다. (i)스토리지 장치(18) 내의 복수의 버퍼들 중 하나의 메모리 맵(Memory-Mapped) 버퍼 주소 (ii) 암호화된 버전의 유저 데이터의 메모리 페이지. 상술한 바와 같이, 스크램블링(Scrambling), 비트/바이트 스위즐링/스틸링(Swizzling/Steering), 그리고 다른 데이터 보호/코딩 방법 등은 호스트(14)로부터 수신된 암호화된 버전의 유저 데이터로서 존재할 수 있다.

특정 실시 예들에서, 각각의 데이터의 메모리 페이지는 4Kb의 크기를 가질 수 있다. 106 단계에서, 스토리지 장치(18)는 암호화된 버전의 수신된 유저 데이터를 메모리 맵 버퍼(Memory-Mapped) 어드레스(104 단계에서 호스트(14)로부터 수신된)를 갖는 버퍼에 저장할 수 있다. 따라서, 유저 데이터는 호스트 특정의 암호화 포멧을 변경하지 않고, 호스트(14)에 의해 수행된 어떠한 암호화를 포함하는 수신되었을 때와 같은 상태로 저장될 수 있다. 이후, 108 단계에서, 스토리지 장치(18)는 104 단계에서 저장된 것과 같이 동일한 메모리 맵 버퍼 어드레스에 저장된 내용을 읽기 위해 호스트(14)로부터 명령을 수신할 수 있다. 110 단계에서, 이에 응답하여, 스토리지 장치(18)는 적합한 버퍼(여기서는 106 단계에서 선택된 버퍼)에 엑세스하고, 104 및 105 단계에서 저장된 암호화된 버전의 이전에 수신된 유저 데이터를 디램 메모리 인터페이스(16)와 같은 I/O 인터페이스를 통해 호스트(14)에 제공할 수 있다. 106 단계에서, 검색된 데이터가 암호화 포멧에 대한 어떠한 변경이 없이 저장되었기 때문에, 메모리 컨트롤러(24)는 110 단계에서 메모리 컨트롤러(24)에 전송된 암호화된 데이터를 인식하고, 필요한 경우 이를 해독할 수 있을 것이다. 따라서, 스토리지 장치(18) 내에 저장된 유저 데이터 내의 호스트 특정의 암호화를 보존함으로써, 호스트(14)에 의해 수행된 특정한 암호화 방법과 관계 없이, 또한 스토리지 장치(18)에서 어떠한 역으로 분석하는 작업을 수행할 필요 없이, 효과적인 디램 채널 기반의 유저 데이터 통신(검색 및 저장) 매커니즘은 스토리지 장치(18)와 호스트(14) 사이에 형성될 수 있다.

도 8은 본 발명의 실시 예에 따라 도 1 및 도 2에 도시된 스토레지 장치 내의 불휘발성 메모리가 유저 데이터를 저장하기 위해 적합한 어드레스 매핑 및 세트 연관성을 이용하여 조직화되는 방법을 보여주는 그림이다. 설명의 간결성을 위해, 도 8의 설명에서 스토리지 장치(18)은 블록 기반의 스토리지 장치(예를 들어, DIMM 기반 SSD)로 가정한다. 도 8의 실시 예에서 설명된 스토리지 구성은 필요한 경우 적합한 변경을 통해 다른 타입의 스토리지 장치들에도 역시 적용될 수 있다. 도 8의 실시 예의 불 휘발성/플레시 메모리 유닛(34)은 각각 메모리 뱅크 0 및 1의 두 개의 메모리 뱅크들(115, 117)로 조직화된 것으로 도시되었다. 이에 의해, 물리적으로 불 휘발성/플레시 메모리 유닛(34)의 구성/구조/레이아웃을 변경하지 않고, 효과적으로 SSD의 블록 기반의 스토리지 구성은 메모리 뱅크 기반의 스토리지 구성(기존의 디램 모듈 내의 메모리 뱅크들과 유사하게)으로 변환될 수 있다. 다시 말해, 스토리지 장치(18) 및 불 휘발성/플레시 메모리 유닛(34)은 블록 기반으로 유지된다. 도 8의 메모리 뱅크 기반의 구성은 단지 스토리지 장치(18) 내의 불 휘발성/플레시 메모리 유닛(34)을 후술되는 바와 같이 유저 데이터의 스토리지 내의 적응성을 제공하기 위한 기존의 디램 모듈 기반의 스토리지 구성으로 정렬하기 위한 내부적인 매커니즘/방법이다. 이러한 내부적인 매커니즘/방법은 NVM 컨트롤러(52) 또는 장치 컨트롤러(48)의 제어에 의해 동작 가능하다.

메모리 컨트롤러(24)가 디램 메모리 인터페이스(16)을 통해 유저 데이터를 읽거나 쓰려고 하는 경우, 이러한 메모리 뱅크들(115, 117)은 스토리지 장치(18) 내의 메모리 맵 위치로서 제공될 수 있다. 도 8의 실시 예의 스토리지 장치(18)는 블록 기반의 SSD 이기 때문에, 각각의 메모리 맵 위치 또는 메모리 뱅크는 이와 관련된 I/O 버퍼들의 쌍을 가질 수 있다. 각각의 I/O 버퍼는 읽기 버퍼 및 쓰기 버퍼로서 기능하도록 구성될 수 있다. 스크램블링, ECC, 혹은 정확하게 동작하기 위한 다른 호스트 기반의 암호화 방법, 특히 스크램블링과 같은 암호화 방법이 주소 종속성을 갖는 경우를 위해, 이러한 버퍼 기반의 구성은 호스트(14)가 동일한 위치/버퍼 어드레스에 데이터를 읽거나 쓰도록 할 수 있다. 도 8을 참조하면, 각각의 메모리 뱅크(115, 117)는 두 개의 다른 동일한 사이즈를 갖는 물리적 버퍼들(버퍼 0 및 1)로 구성될 수 있다. 결과적으로 두 개의 메모리 뱅크(115, 117) 전체 및 네 개의 버퍼들(119, 120, 122, 123)은 도 8에 도시되었다. 각각의 버퍼들(119, 120, 122, 123)은 메모리 읽기 동작 중에 호스트(14)에 데이터를 보내기 위한 읽기 버퍼 및 메모리 쓰기 동작 중에 호스트로부터 데이터를 수신하기 위한 쓰기 버퍼로 기능할 수 있다.

도 8에 도시된 메모리 뱅크(115, 117)은 기본적으로 내부적으로 장치 컨트롤러(48) 또는 도 2의 NVM 컨트롤러(52)에 의해 제어되는 논리적 파티션들이다. 메모리 뱅크(115, 117)이 도 1의 디램 메모리 모듈(20) 내의 메모리 뱅크들(미도시)과 같이 디램 메모리 인터페이스(16)에 연결된 디램 메모리 뱅크인 것처럼, 이는 호스트의 메모리 컨트롤러(24)가 각각의 메모리 뱅크(115, 117)에 분리적으로 주소를 할당하도록 할 수 있다. 따라서, 도 8의 논리적 파티셔닝은 메모리 컨트롤러(24)가 불 휘발성/플레시 메모리 유닛(34)을 디램 메모리 모듈(20)과 같은 일반적인 DIMM 기반의 디램 모듈 내의 메모리 뱅크 기반의 스토리지 구성과 유사하게 취급하도록 할 수 있다.

또한, 상술한 구성을 통해 생성된 버퍼들(119, 120, 122, 123)은 도 2의 RBU(40) 내의 레지스터들/버퍼들(46)과 다를 수 있다. 예를 들어, 도 8의 실시 예에서, 각각의 버퍼들(119, 120, 122, 123)은 물리적으로 불 휘발성/플레시 메모리 유닛(34) 내의 복수의 플레시 메모리의 각각의 부분으로 구성될 수 있다. 추가적으로, SSD를 위한 필요한 블록 기반의 스토리지를 제공하기 위해, 각각의 버퍼들(119, 120, 122, 123) 내의 메모리 유닛들은 효과적으로 복수의 동일한 사이즈의 '블록들' 또는 '섹터들'(125~140)로 파티션될 수 있다. 도 8을 참조하면, 블록들(125~128)은 버퍼(119)와 연관되고, 블록들(129~132)는 버퍼(120)와 연결되고, 블록들(133~136)은 버퍼(122)와 연관되고, 블록들(137~140)은 버퍼(123)과 연관된다. 도 8의 실시 예에서, 각각의 블록은 메모리 컨트롤러(24)로부터 수신된 유저 데이터의 디램 메모리 패이지와 동일한 사이즈로 가정된다.

일 실시 예에서, 각각의 메모리 페이지는 4Kb의 사이즈를 가질 수 있다. 메모리 페이지 사이즈는 시스템(10) 내에서 미리 정의되고 고정될 수 있다. 하지만 이는 다른 시스템에서는 다를 수 있다. 따라서, 각각의 버퍼들(119, 120, 122, 123)은 유저 데이터를 위해서는 16Kb일 수 있고, 어떠한 ECC 비트들도 저장하도록 동작할 수 있다. 결과적으로, 모든 네 개의 버퍼들(119, 120, 122, 123)은 총 64Kb의 어드레스 공간(버퍼당 16Kb, 그리고 4개의 버퍼)을 거쳐, 호스트(14)의 OS(26) 및 메모리 컨트롤러(24)에 의해 메모리 매핑될 수 있다. 일 실시 예에서, 도 7의 104 단계에서 호스트의 메모리 컨트롤러(24)로부터 메모리 맵 버퍼 어드레스는 주어진 I/O 버퍼들과 연관된 메모리 뱅크를 식별할 수 있고, 또한 식별된 메모리 뱅크 내의 버퍼 자체를 식별할 수도 있다. 예를 들어, 만약 메모리 뱅크(115) 내의 버퍼에 호스트(14)에 의한 메모리 쓰기 동작이 수행 중인 경우, 호스트(14)로부터 메모리 맵 버퍼 어드레스는 버퍼(119)에 연관된 메모리 뱅크(115)를 식별한 어드레스 뿐 아니라, 버퍼(119)에 대한 오프셋 어드레스 '0x0'을 포함할 수 있다. 또한, 디램 채널 상의 스토리지 장치(18)를 식별하기 위해, 메모리 컨트롤러(24)에 의해 디램 메모리 인터페이스(16) 상에 전송된 이러한 메모리 맵 버퍼 어드레스는 DIMM 기반의 SSD를 위한 시스템 기반의 어드레스를 포함할 수 있다.

도 8의 실시 예에서, 버퍼 내의 각 블록은 해당 LBA(Logical Block Address)를 사용하여 접근 가능할 수 있고, 복수의 LBA들은 세트 연관성을 이용하여 각각의 해당 물리 블록에 할당 될 수 있다. 각각의 LBA는 블록/섹터 내의 데이터의 4Kb의 메모리 페이지에 연관될 수 있다. 예를 들어, 도 8을 참조하면, LBA0 내지 LBA3은 메모리 뱅크(115) 내의 오프셋 어드레스 '0x0'를 갖는 버퍼(119) 내의 블록 0 내지 3(125~128)에 할당될 수 있다. LBA4 내지 LBA7은 메모리 뱅크(115) 내의 오프셋 어드레스 '0x4000'를 갖는 버퍼(120) 내의 블록 4 내지 7(129~132)에 할당될 수 있다. LBA8 내지 LBA11은 메모리 뱅크(117) 내의 오프셋 어드레스 '0x8000'를 갖는 버퍼(122) 내의 블록 8 내지 1(133~136)에 할당될 수 있다. 그리고, LBA12 내지 LBA15는 메모리 뱅크(117) 내의 오프셋 어드레스 '0xC000'를 갖는 버퍼(123) 내의 블록 12 내지 15(137~140)에 할당될 수 있다.

세트 연관성은 복수의 다른 LBA들이 버퍼 내의 동일한 물리적 블록을 나타내도록 할 수 있다. 예를 들어, 도 8의 실시 예에서 총 16개의 블록들이 두 개의 메모리 뱅크(115, 117)로 분리 된 경우에, LBA는 세트 연관성을 위한 모듈로(Modulo) 16을 이용하여 특정 블록에 할당될 수 있다. 따라서, 도 8에 도시된 바와 같이, LBA 16은 버퍼(119) 내의 블록 0에 연관될 수 있다. 이는 16 modulo 16 = 0이기 때문이다. LBA 17은 버퍼(119) 내의 블록 1에 연관될 수 있다. 이는 17 modulo 16 = 1이기 때문이다. 다시 말해, 도 8에 도시된 바와 같이, 세트 연관성을 사용하여, 0, 16, 32, 48 등과 같은 LBA들은 버퍼(119) 내의 동일한 블록 0에 할당될 수 있다. 또한, 1, 17, 33, 49 등과 같은 LBA들은 버퍼(119) 내의 동일한 블록 1에 할당될 수 있다. 특정 실시 예들에서, 세트 연관성은 호스트(14)에 의해 사용된 암호화 방법(예를 들어, 스크램블링)이 주소 종속성을 가지는 경우에만 필요하다. 만약 호스트 스크램블링 방법이 주소 종속성을 갖지 않는 경우, 세트 연관성은 필요하지 않을 수 있다. 이러한 경우, 블록/섹터와 연관된 복수의 LBA 값들은 모듈로(Modulo) 16 동작을 따르지 않을 수 있다.

도 8의 실시 예에서, 읽기 및 쓰기 동작에 대한 다른 LBA들을 사용하여, 유저 데이터는 동일한 위치/버퍼로부터 읽히고 쓰일 수 있다. 하지만, 특정 실시 예들에서 세트 연관성의 관점에서, 각각의 특정 LBA는 LBA에 할당된 동일한 버퍼 어드레스로부터 읽히거나 쓰는 것이 여전히 필요할 수 있다. 상술한 바와 같이, 호스트(14)로부터의 유저 데이터는 메모리 컨트롤러(24)로부터 수신된 그대로 스토리지 장치(18) 상에 저장될 수 있다. 즉, 존재하는 경우에는 ECC를 포함하고 스크램블링된 형태일 수 있다. 스크램블링이 주소 종속성을 갖고 있다 해도, 데이터는 항상 동일한 물리적 메모리 버퍼의 위치로부터 다시 읽혀지기 때문에, 도 8의 실시 예를 참조하여 상술한 데이터 저장 방법은 동작할 것이다. 호스트(14)로부터 수신된 유저 데이터는 어떠한 변경 없이 저장되기 때문에, 이는 메모리 컨트롤러(24)가 검색된 데이터를 정확히 역 스크램블(De-scramble)할 수 있고 다시 읽혀진 데이터에 대한 ECC를 확인할 수 있다는 것을 보장한다.

호스트(14)로부터 수신된 유저 데이터 내의 추가적인 ECC 비트들은 도 8의 블록 기반 스토리지 구성 내의 데이터 블록의 정렬에 영향을 줄 수 있다. 또한 ECC 비트들은 스토리지 장치(18) (예를 들어, DIMM 기반 SSD)의 임의의 쓰기/읽기 성능에 영향을 줄 수 있다. 하지만, 특정 실시 예에서, 장치 컨트롤러(48) 또는 NVM 컨트롤러(52)는 임의의 읽기/쓰기 성능을 촉진하도록 버퍼 내의 다른 블록들을 거쳐 이러한 ECC 포함 데이터의 저장을 제어하도록 구성될 수 있다. 예를 들어, 장치 컨트롤러(48)는 런 타임에 펌 웨어 내에 혹은 장치 드라이버(30), 장치 드라이버 어플리케이션(28)을 통해 구성될 수 있다.

도 8의 실시 예에 도시된 메모리 구성은 8개의 뱅크(DDR3 디램들과 유사함)들을 커버하도록 확장되거나, 16 뱅크들(DDR4 디램들과 유사함) 혹은 다른 타입들이나 추후의 디램 메모리 뱅크 구성들 또는 스토리지 용량을 커버하도록 확장될 수 있다. 이는 스토리지 장치(18)가 기존 디램 모듈이 아님에도 불구하고, 메모리 컨트롤러(24)에 의한 디램 메모리 인터페이스(16) 상의 메모리 뱅크 기반의 어드레싱을 통해 유저 데이터의 저장/검색을 촉진하기 위함이다.

도 9는 본 발명의 실시 예에 따른 도 1에 도시된 시스템의 전체적인 레이아웃을 보여주는 블록도이다. 설명의 편의를 위해, 도 1 및 도 9에서는 공통적인 시스템 구성들/유닛들에 대해 동일한 참조 번호들이 사용되었다.

도 9를 참조하면, 주변 스토리지(144), 하나 또는 복수의 입력 장치(146), 하나 또는 복수의 출력 장치(147), 그리고 네트워크 인터페이스(149)과 마찬가지로, 호스트(14)는 디램 메모리 인터페이스(16)을 통해 시스템 메모리 유닛(12)과 연결된다. 특정 실시 예들에서, 시스템(10)은 도시된 하나 이상의 장치들 또는 유닛들을 포함할 수 있다. 예를 들어, 시스템(10)은 컴퓨터 시스템(데스크 탑 혹은 랩탑), 테블릿 PC, 모바일 장치, 비디오 게임 장치나 콘솔, M2M(Machine-to-Machine) 통신 유닛, 국적이 없는(Stateless) 씬(Thin) 클라이언트 시스템, 혹은 디램 메모리 인터페이스(16)와 같은 I/O 인터페이스를 포함하는 다른 어떠한 형태의 컴퓨팅 또는 프로세싱 장치일 수 있다. 다양한 실시 예들에서, 시스템(10)은 랙 마운트(Rack-Mount)가 가능한 서버 시스템, 자립형(Standalone) 시스템, 혹은 다른 어떠한 형태의 적합한 폼 펙터를 가질 수 있다. 일부 실시 예들에서, 시스템(10)은 서버 시스템 보다는 클라이언트 시스템으로서 구성될 수 있다.

특정 실시 예들에서, 호스트(14)는 하나 이상의 CPU들을 포함할 수 있다. 혹은, 분산 프로세싱 구성에서 시스템(10)은 하나 이상의 호스트(14)을 포함할 수 있다. 호스트(14)의 추가적인 상세 사항들은 도 1 및 도 2에서 상술되었다. 따라서, 이러한 상세 사항들은 설명의 편의를 위해 생략한다. 시스템(10)이 다중 프로세서 시스템인 경우, 하나 이상의 CPU 또는 프로세서의 예가 있을 수 있다. 상술한 바와 같이, 호스트(14)은 SOC(System on Chip)일 수 있다.

시스템 메모리 유닛(12)은 도 1 및 도 2의 스토리지 장치와 같이 적어도 하나의 DIMM 기반 스토리지 장치를 포함할 수 있다. 스토리지 장치(18)는 도 3 내지 도 8의 개별 실시 예와 같이 컨트롤/상태/유저 데이터의 저장 및 검색을 수행하기 위해 하드웨어 및/혹은 소프트웨어로 구현될 수 있다. 특정 실시 예들에서, 시스템 메모리 유닛(12)은 또한 도 1의 디램 메모리 모듈(20)과 같은 하나 또는 복수의 디램 모듈들을 포함할 수 있다. 스토리지 장치(18)를 구성할 수 있는 메모리 유닛의 다양한 예들은 도 1 및 도 2를 참조하여 앞서 설명되었다. 디램 메모리 모듈(20)은 기존의 DDR2/DDR3/DDR4 디램 모듈, 또는 디램 기반의 3-DS(Three Dimensional Stack) 메모리 모듈일 수 있다. 예를 들어, 디램 기반의 3-DS 메모리 모듈은 HBM(High Bandwidth Memory) 모듈, 또는 HMC(Hybrid Memory Cube) 메모리 모듈일 수 있다. 또한 다른 실시 예들에서, 시스템 메모리 유닛(12)은 단일 타입의 메모리와 달리 여러 타입의 반도체 메모리들을 포함할 수 있다.

다른 실시 예들에서, 주변 스토리지(144)는 자기(Magnetic), 광(Optical), 광자기(Magneto-optical), 또는 하드 드라이브와 같은 솔리드 스테이트 스토리지(Solid-State Storage Media), CD 혹은 DVD와 같은 광 디스크(Optical disk), 불 휘발성 RAM 장치 등에 대한 지원을 포함할 수 있다. 다른 실시 예들에서, 주변 스토리지(144)는 적합한 RAID(Redundant Array of Independent Disks) 구성 내에 있을 수 있는 디스트 어레이와 같은 복잡한 스토리지 장치/시스템들을 더 포함할 수 있다. 혹은 주변 스토리지(144)는 표준 SCSI(Small Computer System Interface), Fibre Channel 인터페이스, Firewire® (IEEE 1394) 인터페이스, 또는 다른 적합한 인터페이스를 통해 호스트(14)와 연결되는 SAN(Storage Area Networks)과 같은 복잡한 스토리지 장치/시스템들을 더 포함할 수 있다.

특정 실시 예들에서, 입력 장치(146)는 컴퓨터 키보드, 마우스 또는 다른 포인팅 장치, 터치 패드, 조이스틱, 또는 다른 타입의 데이터 입력 장치와 같은 표준 입력 장치들을 포함할 수 있다. 출력 장치(147)는 그래픽/디스플레이 장치, 컴퓨터 스크린, 오디오 스피커, 알람 시스템, CAD/CAM(Computer Aided Design/Computer Aided Machining) 시스템, 비디오 게임 스테이션, 또는 다른 타입의 데이터 출력 또는 프로세스 컨트롤 장치 등을 포함할 수 있다. 다른 실시 예들에서, 입력 장치(146) 및 출력 장치(147)는 I/O 또는 주변 잉ㄴ터페이스들을 통해 호스트(14)과 연결될 수 있다.

일 실시 예에서, 네트워크 인터페이스(149)는 시스템(10)을 네트워크(미도시)에 연결할 수 있도록 하여 호스트(14)과 통신할 수 있다. 네트워크 인터페이스(149)는 다른 적합한 장치들, 미디어, 및/또는 시스템(10)을 네트워크에 연결(무선 혹은 유선)하는 프로토콜 콘텐츠 등을 포함할 수 있다. 다른 실시 예들에서, 네트워크는 LANs(Local Area Networks), WANs(Wide Area Networks), 인터넷, 무슨 혹은 유선 이더넷(Ethernet), 텔레커뮤니케이션(Telecommunication) 네트워크, 혹은 다른 타입의 적합한 네트워크들을 포함할 수 있다.

시스템(10)은 도 9에 도시된 다양한 시스템 구성들에 전기적 전력을 공급하기 위한 내장 전력 공급 유닛(150)을 포함할 수 있다. 전력 공급 유닛(150)은 배터리를 받거나, AC 전원 콘센트에 연결될 수 있다. 일 실시 예에서, 전력 공급 유닛(150)은 태양 에너지를 전기적 전력으로 전환할 수 있다.

상술된 바와 같이, 설명의 편의를 위해, 특정한 구조, 인터페이스, 테크닉 등의 상세 설명들이 본 발명에 대한 충분한 이해를 제공하기 위해 기술되었다. 다만, 본 발명은 이에 한정되는 것이 아니다. 하지만, 본 발명의 기술 사항들은 이러한 특정 상세 설명들과 다른 분야의 실시 예들에도 실행될 수 있음은 명확하다. 그러므로 본 기술분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 다른 예들에서, 본 명세서에 불필요한 상세 설명을 생략하여 설명의 모호함을 줄이기 위해 잘 알려진 장치들, 회로들 방법들은 생략 되었다. 본 명세서에 기술된 모든 원리들, 특징들, 실시 예들의 기술 사항들, 구체적인 예들은 이들의 구조적 기능적 균등물들을 포함할 수 있다. 또한, 이러한 균등물들은 현재 알려진 균등물뿐 아니라 이후에 개발되는 균등물 또한 포함할 수 있다. 예를 들어, 이러한 균등물은 구조에 관계 없이 동일한 기능을 수행하기 위해 개발된 어떠한 요소들을 포함할 수 있다.

또한, 예를 들어, 도 1, 2, 5, 6, 8, 9의 블록도에 도시된 내용은 회로의 개념도 또는 기술의 원리를 구현하는 다른 기능적인 유닛들을 나타낼 수 있다는 것은 당업자에 의해 이해 될 수 있다. 유사하게, 예를 들어, 도 3, 4, 7의 순서도는 다양한 프로세스 또는 혁신적인 특징 등을 나타낼 수 있다는 것은 당업자에 의해 이해될 수 있다. 또한, 예를 들어, 이러한 다양한 프로세스 또는 혁신적인 특징 등은 호스트(14)와의 통신을 포함하는 동작 환경에서 장치 드라이버(28, 30)과 함께 스토리지 장치(18)에 의해 실질적으로 구현될 수 있음은 당업자에 의해 이해될 수 있다. 호스트(14)는 여기서 기술된 다양한 프로토콜 트레이닝 및 데이터 저장 방법들을 지원하도록 하드웨어 및/혹은 소프웨어로서 적합하게 구성될 수 있다. 특정 실시 예들에서, 예를 들어, 호스트(14)는 일반적인 용도의 프로세서, 특별한 목적의 프로세서, 기존의 프로세서, DSP(Digital Signal Processor), 복수의 마이크로 프로세서, 하나 또는 복수의 DSP 코어와 연관된 마이크로 프로세서, 마이크로 컨트롤러, ASIC(Application Specific Integrated Circuit) 프로세서, FPGA(Field Programmable Gate Array), 다른 스테이트 머신 등의 모든 타입의 프로세서들을 포함할 수 있다는 것은 쉽게 이해될 것이다.

특정 기술 사항이 소프트웨어 기반의 프로세싱을 요구하는 경우, 이러한 소프트웨어 또는 프로그램 코드는 컴퓨터 판독 가능한 데이터 스토리지 매체(미도시)에 있을 수 있다. 이러한 데이터 스토리지 매체는 주변 스토리지(144)의 부분이거나, 상술된 바와 같이, 호스트(14) 및 스토리지 장치(18)의 내부 메모리 부분일 수 있다. 호스트(14) 및/또는 스토리지 장치(18) 내의 장치 컨트롤러(48)는 소프트웨어 기반의 프로세싱을 처리하기 위해 이러한 매체에 저장된 관련 명령들을 수행할 수 있다. 예를 들어, 이러한 관련 명령들은 상술한 다양한 API 제공의 기능들, 프로토콜 트레이닝 및 상술한 이후의 디램 채널 기반의 컨트롤/상태/유저 데이터 통신을 유효하게 하기 위한 모든 보조 프로그램 코드를 포함할 수 있다. 컴퓨터 판독 가능한 데이터 스토리지 매체(미도시)는 컴퓨터 프로그램, 소프트웨어, 펌 웨어, 상술한 일반적 목적의 컴퓨터 또는 프로세서에 의해 수행되는 마이크로 코드 등을 포함하는 논 트랜지토리(Non-Transitory) 데이터 스토리지 매체 일 수 있다. 컴퓨터 판독 가능한 스토리지 매체의 예는 ROM(Read Only Memory), RAM(Random Access Memory), 디지털 레지스터, 캐시 메모리, 반도체 메모리 장치들, 내장 하드 디스크, 자기 테이프와 같은 자기 매체, 이동식 디스크, 광자기(Magneto-optical) 매체, CD-ROM 디스크 및 DVD(Digital Versatile Disks)와 같은 광 매체 등을 포함할 수 있다.

본 발명에 따른 통신 모델의 다른 실시 예들은 추가적인 구성들은 추가적인 기능을 제공하기 위해 추가된 구성일 수 있다. 이러한 추가적인 기능은 본 발명의 내용에 따른 해결책을 지원하기 위해 필요한 모든 기능 및/또는 상술한 모든 기능들을 포함할 수 있다. 비록 특징들 및 요소들이 특정 조합에 의해 상술되었지만, 다른 특징들과 요소들 없이, 또는 다양한 조합과 함께, 또는 다른 특징 등 없이, 각각의 특징 또는 요소들은 단독으로 사용될 수 있다. 상술된 바와 같이, 시스템(10)의 일부 구성들(예를 들어, 스토리지 장치(18) 및 호스트(14))의 기능들은 로직 회로와 같은 하드웨어를 사용하여 제공될 수 있다. 또는, 상술된 바와 같이, 이는 컴퓨터 판독 가능한 데이터 스토리지 매체 상에 저장된 코드화된 명령 또는 마이크로코드의 형태로 소프트웨어/펌 웨어를 실행할 수 있는 하드웨어를 통해 제공될 수 있다. 따라서, 이러한 기능들 및 도시된 기능적 블록들은 하드웨어적인 구현 및/또는 컴퓨터에 의해 구현, 그리고 머신에 의해 구현될 수 있다고 이해되어야 한다.

상술된 바에 따르면, 트레이닝 프로토콜은 호스트 플랫폼 메모리 컨트롤러에 의해 수행된 암호화 방법(혹은, 알고리즘)을 역으로 분석할 필요 없이, 호스트 시스템과 디램 메모리 채널 DIMM 폼 펙터 스토리지 장치(예를 들어, DDR 폼 펙터 기반의 SSD) 간의 통신이 가능하게 한다. 프로토콜은 다양한 형태의 스크램블링, 오류 정정 코드, 혹은 다른 형태의 데이터 보호 방식 등과 함께 동작할 것이다. 또한, 프로토콜은 표준화되지 않은 용도의 스토리지 장치(예를 들어, DIMM 기반 스토리지 장치)가 디램 채널과 같은 표준화된 I/O 인터페이스 또는 I/O 채널에 결합되고 호스트(14)와 정보를 교환할 필요가 있는 모든 어플리케이션이 일반적으로 적용될 수 있다.

이러한 프로토콜을 사용하여, DDR I/O 채널에서 사용된 암호화 또는 데이터 보호 방법과 관계 없이, 호스트(14)는 호스트가 인식 가능한 형태로 DIMM 기반 I/O 스토리지 장치 컨트롤러에게 정보를 송신하고 상태 정보를 수신할 수 있다. 프로토콜 트레이닝 단계 중에, 알려진 값의 프로토콜 트레이닝 시퀀스를 보내고 호스트(14)로부터 수신된 것과 같은 암호화 포멧으로 스토리지 장치(18) 내의 관련 커맨드/상태 정보를 저장함으로써, 컨트롤/상태 정보는 DIMM 기반 스토리지 장치에 쓰일 수 있다. 이러한 저장된 값은 이후 런 타임에서 호스트(14)로부터 수신된 암호화된 커맨드들을 실행하고, 상태 데이터를 호스트가 인식 가능한 암호화 포멧으로 보고하기 위해 사용된다. 메모리 뱅크 기반의 버퍼 구성은 호스트 특정의 암호화를 보존하기 위해 수신된 상태 그대로 저장되는 유저 데이터의 저장을 위해 기술되었다. 이는 디램 채널을 통해 메모리 컨트롤러(24)와 DIMM 기반 스토리지 장치 사이의 데이터 교환이 가능하도록 한다.

이상에서와 같이 도면과 명세서에서 실시 예가 개시되었다. 여기서 특정한 용어들이 사용되었으나, 이는 단지 본 발명을 설명하기 위한 목적에서 사용된 것이지 의미 한정이나 특허 청구범위에 기재된 본 발명의 범위를 제한하기 위하여 사용된 것은 아니다. 그러므로 본 기술분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 따라서 본 발명의 진정한 기술적 보호 범위는 첨부된 특허 청구범위의 기술적 사상에 의해 정해져야 할 것이다.

10 : 시스템 12 : 시스템 메모리 유닛
14 : 호스트 16 : 디램 메모리 인터페이스
18 : 스토리지 장치 20 : 디램 메모리 모듈
22 : CPU 24 : 메모리 컨트롤러
26 : OS 28 : 장치 드라이버 어플리케이션
30 : 장치 드라이버 32 : 호스트 인터페이스 유닛
34 : 불 휘발성/플레시 메모리 유닛 36 : 디램 메모리 유닛
38 : CAM 40 : RBU
42 : 컨트롤 레지스터 44 : 상태 레지스터
46 : 레지스터들/버퍼들 48 : 장치 컨트롤러
50 : 버퍼 매니저 52 : NVM 컨트롤러
54 : 프로세싱 유닛 92 : 검색 레지스터
94 : CAM 저장 내용 115, 117 : 뱅크
119~123 : 버퍼 125~140 : 블록
144 : 주변 스토리지 146 : 입력 장치
147 : 출력 장치 149 : 네트워크 인터페이스

Claims

스토리지 장치가 호스트에 의해 지원되는 I/O(Input/Output) 인터페이스에 결합되었는지 판별하는 단계;
상기 판별 결과에 반응하여, 데이터 패턴들의 제 1 시퀀스를 상기 I/O 인터페이스를 사용하여 상기 스토리지 장치에 쓰도록 상기 호스트에 명령하는 단계, 여기서 상기 제 1 시퀀스 내의 데이터 패턴은 I/O 커맨드의 각각의 커맨드 데이터 비트들의 암호화(encode)된 버전을 포함하고, 상기 제 1 시퀀스 내의 상기 데이터 패턴은 상기 제 1 시퀀스 내의 다음 데이터 패턴이 상기 스토리지 장치에 쓰여지기 전에 미리 정해진 횟수로 쓰이고, 상기 미리 정해진 횟수는 1보다 큼;
상기 스토리지 장치 내의 주소화(addressable) 스토리지 내에 상기 쓰여진 데이터 패턴의 커맨드 데이터 포함 부분을 저장하는 단계;
상기 스토리지 장치에서, 상기 I/O 인터페이스를 통해 상기 호스트로부터 컨트롤 비트 패턴을 수신하는 단계, 여기서 상기 컨트롤 비트 패턴은 암호화된 I/O 커맨드를 포함함; 그리고
상기 컨트롤 비트 패턴을 통해 수신된 상기 암호화된 I/O 커맨드를 해독(decode)하기 위해 상기 주소화 스토리지 내의 하나 이상의 커맨드 데이터 포함 부분을 사용하는 단계를 포함하는 방법.
제 1 항에 있어서,
상기 I/O 인터페이스는 DRAM(Dynamic Random Access Memory) 인터페이스이고, 상기 암호화된 I/O 커맨드는 암호화된 DRAM 커맨드이고, 그리고 상기 스토리지 장치는 상기 DRAM 인터페이스를 통해 동작하도록 구성된 방법.
제 1 항에 있어서,
데이터 패턴들의 상기 제 1 시퀀스를 쓰도록 상기 호스트에 명령하는 단계는:
상기 스토리지 장치 내에 컨트롤 레지스터를 설정하는 단계, 여기서 상기 컨트롤 레지스터는 적어도 상기 제 1 시퀀스 내의 상기 데이터 패턴의 상기 커맨드 데이터 포함 부분을 저장하도록 구성됨;
메모리 어드레스를 상기 컨트롤 레지스터에 연관시키는 단계; 및
상기 제 1 시퀀스 내의 상기 데이터 패턴을 상기 컨트롤 레지스터와 연관된 상기 메모리 어드레스에 쓰도록 상기 호스트에 명령하는 단계를 포함하는 방법.
제 1 항에 있어서,
상기 I/O 인터페이스를 사용하여 데이터 패턴들의 제 2 시퀀스를 상기 스토리지 장치에 쓰도록 상기 호스트에 더 명령하는 단계, 여기서 상기 제 2 시퀀스 내의 상기 데이터 패턴은 각 상태 데이터의 암호화된 버전을 포함하고, 상기 제 2 시퀀스 내의 상기 데이터 패턴은 상기 제 2 시퀀스 내의 다음 데이터 패턴이 상기 스토리지 장치에 쓰이기 전에 상기 미리 정해진 횟수로 쓰임;
상기 스토리지 장치 내의 레지스터에서의 상기 제 2 시퀀스 내의 데이터 패턴의 상태 데이터 포함 부분을 저장하는 단계;
상기 주소화 스토리지를 사용하여 상기 수신된 I/O 커맨드를 해독하는 단계;
상기 스토리지 장치 내의 상기 레지스터에 접근하는 단계;
동작의 결과에 기초하여, 상기 레지스터로부터 해당 상태 데이터 포함 부분을 검색하는 단계; 및
상기 수신된 I/O 커맨드에 대한 응답으로, 상기 검색된 상태 데이터 포함 부분을 상기 호스트에 제공하는 단계를 더 포함하는 방법.
제 4 항에 있어서,
상기 제 1 시퀀스 내의 상기 데이터 패턴 및 상기 제 2 시퀀스 내의 상기 데이터 패턴은 상기 스토리지 장치에 알려진 미리 정의된 순서대로 쓰이는 방법.
제 4 항에 있어서,
데이터 패턴들의 상기 제 2 시퀀스를 쓰도록 상기 호스트에 명령하는 단계는:
상기 스토리지 장치 내에 상태 레지스터를 설정하는 단계, 여기서 상기 상태 레지스터는 적어도 상기 제 2 시퀀스 내의 상기 데이터 패턴의 상기 상태 데이터 포함 부분을 저장하도록 구성됨;
메모리 어드레스를 상기 상태 레지스터에 연관시키는 단계; 및
상기 제 2 시퀀스 내의 상기 데이터 패턴을 상기 상태 레지스터와 연관된 상기 메모리 어드레스에 쓰도록 상기 호스트에 명령하는 단계를 포함하는 방법.
제 4 항에 있어서,
상기 제 1 및 제 2 시퀀스들 내의 상기 데이터 패턴들은 상기 I/O 인터페이스에 대해 정의된 전송 포멧들로 상기 호스트에 의해 상기 스토리지 장치에 전송되는 방법.
스토리지 장치가 호스트에 의해 지원되는 I/O(Input/Output) 인터페이스에 결합되고, 상기 I/O 인터페이스를 통해 동작하도록 상기 스토리지 장치를 구성하는 단계, 여기서 상기 스토리지 장치는 상기 호스트로부터 수신된 데이터를 상기 스토리지 장치 내의 복수의 버퍼들에 저장하도록 구성됨;
상기 스토리지 장치에서, 상기 I/O 인터페이스를 통해 상기 호스트로부터: 상기 복수의 버퍼들 중 하나의 버퍼의 메모리 맵(Memory-Mapped) 버퍼 어드레스, 및 데이터의 메모리 페이지의 암호화된 버전을 수신하는 단계;
상기 수신된 데이터의 메모리 페이지의 상기 암호화된 버전을 상기 메모리 맵 버퍼 어드레스를 갖는 상기 버퍼에 저장하는 단계;
상기 메모리 맵 버퍼 어드레스에 저장된 내용을 읽기 위해 명령을 상기 호스트로부터 수신하는 단계; 및
상기 명령을 수신한 것에 응답하여, 상기 수신된 데이터의 메모리 페이지의 상기 저장된 암호화된 버전을 상기 I/O 인터페이스를 통해 상기 호스트로 제공하는 단계를 포함하는 방법.
제 8 항에 있어서,
상기 구성하는 단계는:
상기 I/O 인터페이스에 결합되면, 메모리 커맨드들을 해독하기 위해 상기 호스트에 의해 사용된 제 1 암호화 방법과 관계 없이 상기 스토리지가 상기 I/O 인터페이스를 통해 상기 호스트로부터 수신된 상기 메모리 커맨드들을 실행할 수 있도록, 상기 호스트에 의해 암호화된 상기 메모리 커맨드들을 인식하도록 상기 스토리지 장치를 트레이닝하는 단계; 및
상기 호스트에 상태 정보의 암호화된 버전을 제공하도록 상기 스토리지 장치를 더 트레이닝하는 단계를 포함하고, 여기서 상기 상태 정보는 상기 I/O 인터페이스를 통해 전송되고 해당 메모리 커맨드의 실행과 연관되고, 상기 상태 정보의 상기 암호화된 버전은 상기 상태 정보를 처리하기 위해 상기 호스트에 의해 사용된 제 2 암호화 방법에 기초하는 방법.
제 8 항에 있어서,
상기 I/O 인터페이스는 DRAM(Dynamic Random Access Memory) 인터페이스이고,
상기 스토리지 장치를 구성하는 단계는:
각 버퍼를 복수의 블록들로 파티셔닝(partitioning)하는 단계, 여기서 각 블록은 해당 LBA(Logical Block Address)를 사용하여 접근 가능하고, 각 블록의 사이즈는 상기 호스트로부터 수신된 데이터의 상기 메모리 페이지의 사이즈와 동일함; 및
상기 복수의 버퍼들을 복수의 메모리 뱅크들로 조직화하는 단계를 포함하고, 여기서 각 메모리 뱅크는 동일한 수의 다른 버퍼들을 포함하고 그리고 상기 메모리 뱅크가 상기 DRAM 인터페이스와 연결된 DRAM 메모리 뱅크인 것처럼 상기 호스트에 의해 별도로 주소화되고, 그리고
상기 복수의 버퍼들 중 주어진 버퍼의 메모리 맵 버퍼 어드레스를 상기 호스트로부터 수신하는 단계는:
상기 주어진 버퍼와 연관된 메모리 뱅크를 식별하고 상기 식별된 메모리 뱅크 내의 상기 주어진 버퍼를 식별하는 메모리 맵 버퍼 어드레스를 수신하는 단계를 포함하는 방법.
제 10 항에 있어서,
복수의 LBA들 각각을 세트 연관성을 사용하여 상기 복수의 블록들 내의 각 블록에 할당하는 단계를 더 포함하는 방법.
정보를 저장하기 위한 복수의 메모리 유닛들을 포함하는 제 1 스토리지 부;
메모리 모듈이 호스트에 의해 지원되는 I/O(Input/Output) 인터페이스를 통해 동작 가능하고 상기 I/O 인터페이스에 결합되도록 구성되는 인터페이스 유닛;
제 2 스토리지 부; 및
상기 제 1 스토리지 부, 상기 인터페이스 유닛, 및 상기 제 2 스토리지 부와 연결되는 컨트롤 유닛을 포함하되,
상기 메모리 모듈이 상기 I/O 인터페이스에 결합되면, 상기 컨트롤 유닛은:
상기 I/O 인터페이스를 통해 데이터 패턴들의 제 1 시퀀스를 상기 호스트로부터 수신하고, 여기서 상기 제 1 시퀀스 내의 데이터 패턴은 I/O 커맨드의 각각의 커맨드 데이터 비트들의 암호화(encode)된 버전을 포함하고, 상기 제 1 시퀀스 내의 상기 데이터 패턴은 상기 제 1 시퀀스 내의 다음 데이터 패턴이 수신되기 전에 미리 정해진 횟수로 상기 호스트로부터 수신되고, 상기 미리 정해진 횟수는 1보다 큼;
쓰여진 데이터 패턴의 커맨드 데이터 포함 부분을 상기 제 2 스토리지 부 내에 저장하고;
상기 I/O 인터페이스를 통해 상기 호스트로부터 컨트롤 비트 패턴을 수신하고, 여기서 상기 컨트롤 비트 패턴은 암호화된 I/O 커맨드를 포함함; 그리고
상기 컨트롤 비트 패턴을 통해 수신된 상기 암호화된 I/O 커맨드를 해독하기 위해 상기 제 2 스토리지 부 내의 하나 이상의 커맨드 데이터 포함 부분들을 사용하도록 동작하는 메모리 모듈.
제 12 항에 있어서,
상기 메모리 모듈은:
DIMM(Dual In-line Memory Module) 폼 팩터(Form-Factor)를 갖는 SSD(Solid State Drive);
상기 DIMM 폼 팩터를 갖는 블록 기반의 스토리지 장치;
DRAM(Dynamic Random Access Memory) 인터페이스를 통해 동작하도록 구성되는 스토리지 장치; 및
상기 I/O 인터페이스를 통해 동작하도록 구성되는 스토리지 장치 중 하나인 메모리 모듈.
제 12 항에 있어서,
상기 컨트롤 유닛은:
상기 제 2 스토리지 부에 접근하고;
매칭 여부를 판별하기 위해 상기 수신된 I/O 커맨드의 비트 패턴을 상기 제 2 스토리지 부 내의 하나 이상의 커맨드 데이터 포함 부분들의 비트들과 비교하고;
상기 제 2 스토리지 부로부터 매칭되는 커맨드 데이터 포함 부분을 검색하고; 그리고
상기 검색된 커맨드 데이터 포함 부분을 상기 수신된 I/O 커맨드의 해독된 버전으로 사용하도록 더 동작하는 메모리 모듈.
제 12 항에 있어서,
상기 컨트롤 유닛에 연결된 상태 레지스터를 더 포함하되,
상기 컨트롤 유닛은:
상기 I/O 인터페이스를 통해 데이터 패턴들의 제 2 시퀀스를 상기 호스트로부터 수신하고, 여기서 상기 제 2 시퀀스 내의 데이터 패턴은 각 상태 데이터의 암호화된 버전을 포함하고, 상기 제 2 시퀀스 내의 상기 데이터 패턴은 상기 제 2 시퀀스 내의 다음 데이터 패턴이 수신되기 전에 상기 미리 정해진 횟수로 상기 호스트로부터 수신됨;
상기 상태 레지스터에서의 상기 제 2 시퀀스 내의 상기 데이터 패턴의 상태 데이터 포함 부분을 저장하고;
상기 제 2 스토리지 부를 사용하여 상기 수신된 I/O 커맨드를 해독하고;
상기 상태 레지스터에 접근하고;
동작의 결과에 기초하여, 상기 상태 레지스터로부터 해당 상태 데이터 포함 부분을 검색하고; 그리고
상기 수신된 I/O 커맨드에 대한 응답으로 상기 검색된 상태 데이터 포함 부분을 상기 호스트에 제공하도록 더 동작하는 메모리 모듈.
제 15 항에 있어서,
상기 제 1 또는 제 2 스토리지 부는 복수의 물리 버퍼들을 포함하고, 여기서 각 버퍼는 상기 복수의 메모리 유닛들의 각 부분으로 구성됨, 그리고
상기 컨트롤 유닛은:
상기 I/O 인터페이스를 통해 상기 호스트로부터: 상기 복수의 버퍼들 중 하나의 버퍼의 메모리 맵(Memory-Mapped) 버퍼 어드레스, 및 유저 데이터의 메모리 페이지의 암호화된 버전을 수신하고;
상기 수신된 유저 데이터의 상기 암호화된 버전을 상기 메모리 맵 버퍼 어드레스를 갖는 상기 버퍼 내에 저장하고;
상기 메모리 맵 버퍼 어드레스에 저장된 내용을 읽기 위해 명령을 상기 호스트로부터 수신하고, 그리고
상기 명령을 수신한 것에 응답하여, 상기 수신된 유저 데이터의 상기 저장된 암호화된 버전을 상기 I/O 인터페이스를 통해 상기 호스트로 제공하도록 더 동작하는 메모리 모듈.
제 16 항에 있어서,
상기 복수의 물리 버퍼들은 복수의 메모리 뱅크들로 조직화 되고, 각 메모리 뱅크는 다른 물리 버퍼들의 각각의 수를 포함하고 그리고 상기 호스트에 의해 별도로 주소화되고,
각 물리 버퍼는 복수의 블록들로 파티션되고, 각 블록은 해당 LBA(Logical Block Address)를 사용하여 접근 가능하고, 각 블록의 사이즈는 상기 호스트로부터 수신된 유저 데이터의 상기 메모리 페이지의 사이즈와 동일하고, 복수의 LBA들 각각은 세트 연관성을 사용하여 상기 복수의 블록들 내의 각 블록에 할당되고,
상기 복수의 버퍼들 중 주어진 버퍼의 상기 메모리 맵 버퍼 어드레스는 상기 주어진 버퍼와 연관된 메모리 뱅크를 식별하고 상기 식별된 메모리 뱅크 내의 상기 주어진 버퍼를 식별하는 메모리 모듈.
정의된 전송 포멧으로 전기적 정보의 통신을 지원하는 I/O(Input/Output) 인터페이스;
상기 I/O 인터페이스와 연결되고, 상기 I/O 인터페이스를 통해 전기적 정보의 통신을 지원하는 프로세서;
상기 I/O 인터페이스와 호환되는 스토리지 장치; 및
상기 스토리지 장치와 연관된 장치 드라이버를 포함하되,
상기 장치 드라이버는 프로그램 명령들을 포함하고, 상기 프로그램 명령들은, 상기 프로세서에 의해 실행되면, 상기 프로세서가:
상기 스토리지 장치가 상기 I/O 인터페이스에 결합되었는지 판별하고; 그리고
상기 I/O 인터페이스를 사용하여 데이터 패턴들의 제 1 시퀀스를 상기 스토리지 장치에 쓰게 하고, 여기서 상기 제 1 시퀀스 내의 데이터 패턴은 I/O 커맨드의 각각의 커맨드 데이터 비트들의 암호화(encode)된 버전을 포함하고, 상기 제 1 시퀀스 내의 상기 데이터 패턴은 상기 제 1 시퀀스 내의 다음 데이터 패턴이 상기 스토리지 장치에 쓰여지기 전에 미리 정해진 횟수로 쓰이고, 상기 미리 정해진 횟수는 1보다 크고,
상기 스토리지 장치는 상기 장치 드라이버를 통해 동작하여 상기 스토리지 장치가:
상기 스토리지 장치 내의 주소화 스토리지 내에 상기 데이터 패턴의 커맨드 데이터 포함 부분을 저장하고;
상기 I/O 인터페이스를 통해 상기 프로세서로부터 컨트롤 비트 패턴을 수신하고, 여기서 상기 컨트롤 비트 패턴은 암호화된 I/O 커맨드를 포함함; 그리고
상기 컨트롤 비트 패턴을 통해 수신된 상기 암호화된 I/O 커맨드를 해독하기 위해 상기 주소화 스토리지 내의 하나 이상의 커맨드 데이터 포함 부분들을 사용하게 하는 시스템.
제 18 항에 있어서,
상기 스토리지 장치는:
DIMM(Dual In-line Memory Module) 폼 팩터(Form-Factor)를 갖는 SSD(Solid State Drive);
상기 DIMM 폼 팩터를 갖는 블록 기반의 스토리지 장치;
DRAM(Dynamic Random Access Memory) 인터페이스를 통해 동작하도록 구성되는 스토리지 장치; 및
상기 I/O 인터페이스를 통해 동작하도록 구성되는 스토리지 장치 중 하나인 시스템.
제 18 항에 있어서,
상기 프로그램 명령들은, 상기 프로세서에 의해 실행되면, 상기 프로세서가:
상기 I/O 인터페이스를 사용하여 데이터 패턴들의 제 2 시퀀스를 상기 스토리지 장치에 더 쓰게 하고, 여기서 상기 제 2 시퀀스 내의 데이터 패턴은 각 상태 데이터의 암호화된 버전을 포함하고, 상기 제 2 시퀀스 내의 상기 데이터 패턴은 상기 제 2 시퀀스 내의 다음 데이터 패턴이 상기 스토리지 장치에 쓰이기 전에 상기 미리 정해진 횟수로 쓰이고, 그리고
상기 스토리지 장치는 상기 장치 드라이버를 통해 동작하여 상기 스토리지 장치가:
상기 스토리지 장치 내의 레지스터에 상기 제 2 시퀀스 내의 상기 데이터 패턴의 상태 데이터 포함 부분을 저장하고;
상기 수신된 I/O 커맨드를 해독하고;
상기 스토리지 장치 내의 상기 레지스터에 접근하고;
동작의 결과에 기초하여, 상기 레지스터로부터 해당 상태 데이터 포함 부분을 검색하고; 그리고
상기 수신된 I/O 커맨드에 대한 응답으로, 상기 검색된 상태 데이터 포함 부분을 상기 프로세서에 제공하게 하는 시스템.