| 1: |
thread의 정확한 의미는 무엇인가요? |
| A: |
thread란 연속적인 요청을 의미하는 것으로 항상 순서를 유지하고 있습니다. 즉, thread는 요청의 전달, 실행 또는 응답의 순서가 정해져 있어 결코 바뀌지 않는 것입니다. |
|
| 2: |
thread는 왜 사용하나요? |
| A: |
thread를 사용하면 코어자체 내에서 가능한 코어 고유의 동시성(concurrency)을 나타낼 수 있으며, 이는 일반적으로 성능 저하를 막기 위해 실행되는 것입니다. thread가 없으면 동시 발생하는 여러 개의 연속된 요청을 교대로 할당하거나, 하나의 시퀀스 내에서 다중 시간 분할을 해야 합니다. 어떤 요청에 지연이 발생하면 그 뒤의 요청 모두에 영향을 미치게 되므로 동시에 발생하는 모든 시퀀스에 영향을 주게 됩니다. 각 요청들이 각각의 thread에 할당되어 이름이 붙여짐으로써, 목표가 되는 코어는 그 실행 순서를 자유롭게 바꾸어 이를 최적화할 수 있습니다.
OCP에서 코어가 가진 최소 thread 수는 1 입니다. 모든 요청은 thread와 연관되어 있지만, 최초의 코어는 먼저 생성되었다고 생각되는 다른 요청보다 우선순위가 높은 요청을 해결하기 위해 목표 코어를 필요로 하는 경우도 있습니다. 단, 하나의 thread 내에서는 모든 요청과 그 응답이 순서대로 실행되어야 합니다.
그러므로 하나의 thread 내에서는 우선순위가 높은 요청이라 하여도, 선행하는 모든 요청들이 처리된 후 해당 요청을 처리하기 시작합니다. 우선되는 요청을 위해 thread를 예약해 두어 두 번째 thread의 순서를 유지함과 동시에, 전부터 있었던 요청이나 우선순위가 낮은 요청이 실행되기 전에 우선되는 요청을 실행할 수 있도록 합니다.
다른 예로는 다중 뱅크 DRAM 컨트롤러(Controller) 구성이 있는데 각각의 DRAM 뱅크는 유일하게 연관된 thread가 존재 합니다. 이러한 경우 논리적으로는 모든 뱅크를 동시에 활성화시킬 수 있게 되므로, DRAM 컨트롤러는 DRAM 접속에 대한 동시성을 대폭 향상시킬 수 있습니다. |
|
| 3: |
하나의 코어가 소유할 수 있는 최대 thread 수는 얼마인가요? |
| A: |
OCP 구조에서는 코어가 소유할 수 있는 thread 수에 제한이 없습니다. 단, 실제로는 다른 요소로 인해 제한이 발생하는데, 마스터 코어는 동시에 하나의 명령만 내릴 수 있습니다. 그러므로 여러 개의 thread가 활성화될 경우, 내부에서 조정 기능(arbitration)을 수행하여 OCP 상에 존재할 하나의 thread를 선택하여야 합니다. IP 코어의 성능은 thread 수가 증가함에 따라 저하됩니다. 유사하게, 슬레이브는 종종 thread와 관련된 저장(storage) 비용을 발생시킬 것입니다. 따라서 게이트 수는 thread 수를 적정하게 유지시키는 원인을 제공할 것입니다. |
|
| 4: |
여러 개의 thread가 필요한 이유는 무엇인가요?
|
| A: |
여러 개의 thread는 주로 복수의, 관련성이 없는 처리를 동시에 실행하기 위해 주로 사용됩니다. 전형적인 예로는 송신과 수신 양방향 흐름을 가진 Ethernet MAC을 들 수 있는데, 여기서의 각 흐름은 각각의 유일한 thread에 의존하게 됩니다. |
|
| 5: |
MThreadID 신호의 (phase를 기준으로 한) 타이밍이란 무엇인가요? |
| A: |
데이터 handshaking이 가능하지 않을 때의 쓰기 요청과 관련된 phase 수는 하나입니다. 여기에서는 쓰기 명령이 유효화 될 때에 thread ID 신호가 유효하게 됩니다(요청 그룹에 MThreadID 신호가 포함됨). 데이터 handshaking이 가능하게 되면, 쓰기 데이터가 유효화 될 때 datathreadID 신호도 유효하게 됩니다(데이터 handshake 그룹 내에 MDataThreadID 신호가 포함됨).
읽기 전송에서는, 읽기 명령이 유효화 될 때 thread ID 신호가 유효하게 됩니다(이 경우도 요청 그룹 내에 MThreadID 신호가 포함됨). 슬레이브가 데이터를 돌려보내게 되면, 읽기 데이터가 유효화 될 때 thread ID 신호가 유효하게 됩니다(응답 그룹 내에 SThreadID 신호가 포함됨). |
|
| 6: |
마스터 / 슬레이브를 리셋(reset) 하면 실행 중인 thread에 어떤 영향을 주나요? |
| A: |
리셋은 항상 모든 진행 중인 마스터의 OCP 요구 및 슬레이브의 OCP응답을 취소 또는 종료시켜야 합니다. 그렇지 않으면, 리셋 전에 송신된 명령에 응답하여 리셋 후에 슬레이브가 데이터를 보내게 되어, 리셋을 시켜도 시스템 상태가 제대로 초기화되지 않기 때문입니다. 또한, OCP 사양은 적어도 16 클럭 주기 동안에 리셋을 활성화할 것을 요구하고 있는데, 이는 마스터와 슬레이브 양쪽이 내부적으로 안정된 상태에 도달할 수 있도록 하기 위함입니다. |
|
| 7: |
코어는 어떤 방식으로 우선 처리를 실행하나요? |
| A: |
여러 개의 thread가 있는 경우, 일반적인 전송은 어떤 하나의 thread를 사용하나 우선순위가 높은 요청은 별도의 thread를 사용할 수 있습니다. 하나의 thread에서는 요청이 순서대로 처리되나, 별도의 thread에서 나온 요청에는 이 순서가 적용되지 않습니다. 별도의 다른thread에서 나온 요청은 순서를 바꾸어 처리할 수 있고, 처리 우선순위를 설정할 수도 있습니다. |
|
| 8: |
OCP상의 Connection ID는 무엇에 사용하는 건가요? |
| A: |
A: Connection ID는 thread와 매우 유사하나, 다루는 대상의 범위가 국부적이지 않고 포괄적입니다. Connection ID에 의해 시스템 시작 코어와 목적 코어간 전송에 대한 식별이 가능해 집니다. 목표가 되는 코어가 수신하는 thread 정보는 국부적인 OCP 접속을 위한 정보이지만, Connection ID는 중간의 전송을 유지 시켜준다는 점에 주의해야 합니다. |
|
| 9: |
thread와 연결(Connection)의 차이는 무엇인가요? |
| A: |
thread는 OCP 인터페이스와 연관이 있습니다. 코어 C와 연결된 코어 B에 코어 A가 연결되어 있는 경우, 코어 B에서 C를 중계하는 요청들을 수행하는 동안 코어 C는 코어 A의 OCP thread정보를 수신하지 않습니다. 단지, 코어 B와 코어 C사이의 OCP 접속 연결로부터의 코어 정보만을 얻을 수 있습니다.
OCP 신호들 중 하나인 Connection은 코어 A가 요청의 발신지를 명확히 식별할 수 있도록 전체적인 식별자를 붙이는 기능을 제공합니다. 아주 많은 시작점과 목적지로 구성되는 SoC 설계에서 Connection ID 는 매우 중요한 의미를 갖게 됩니다. 이를 통해 OCP 시작 코어는 OCP 인터페이스 전송의 중개와 관련된 요청에 대해 식별 정보를 할당할 수 있기 때문입니다. |
|
| 10: |
하나의 슬레이브를 복수의 마스터에 연결시킬 수 있나요? 만약 불가능하다면 메모리 공유는 어떤 방식으로 이루어지나요? OCP를 point-to-point 방식으로 연결한 상태에서 여러 개의 프로세서를 메모리 컨트롤러에 연결시키기 위한 프로토콜이 OCP에 있나요? |
| A: |
MicroNetwork는 다음 두 가지를 실행합니다. 여러 개의 슬레이브를 마스터에 연결시키고, 여러 개의 마스터를 특정 슬레이브에 연결시킵니다. 후자의 경우는 여러 개의 마스터가 단일 OCP point-to-point 접속 방식으로 하나의 슬레이브를 공유할 수 있게 합니다. 이는 기존의 컴퓨터 버스 기능과 매우 흡사합니다. 이 MicroNetwork는 OCP를 사용하여 시스템 내의 마스터와 슬레이브 각 코어에 인터페이스를 연결합니다.
다중 포트 SRAM 메모리와 같이 슬레이브가 여러 개의 OCP 인터페이스를 가진 경우에는 전혀 문제가 없습니다.
OCP 인터페이스 표준은 기존의 버스 프로토콜과 달리, thread 기능을 선택 사항으로 두었습니다. thread 기능을 통해 태그를 붙인 전송이 가능해지고, 이 태그를 바탕으로 각각을 처리할 수 있도록 하였습니다. 이를 통해 서로 다른 마스터가 보내는 데이터 흐름을 슬레이브 코어에서 인식할 수 있고, 개별 데이터 흐름에 대해 각각 QoS(Quality of Service)를 실현할 수 있습니다. 대부분의 경우, 하부시스템의 타이밍 제약(예를 들면 DRAM 컨트롤러 제약)에 맞추어 전송 순서를 변경함으로써 성능을 향상시킬 수 있습니다. |
|
| 11: |
태깅이란 무엇입니까? |
| A: |
일반적으로 OCP 슬레이브는 OCP 마스터에서 발행된 요청과 같은 순서로
OCP 마스터에서 생성된 요청에 응답을 반환합니다. 그러나 OCP
슬레이브가 OCP 마스터에 응답을 반환해야 하는 시기를 결정해야 하는
경우도 있습니다. 태그를 사용하여 OCP 슬레이브의 응답을 트리거한 원래
요청에 응답을 직접 연결할 수 있습니다. 일반적으로 태그를 사용하면
전반적인 시스템 성능이 향상됩니다. |
|
| 12: |
태그와 threads의 차이점은 무엇입니까? |
| A: |
태그는 순서가 바뀐 응답을 제공하는 데 있어 threads보다 "쓸모 없게”
생각될 수 있습니다. 특히 여러 개의 threads는 개별 thread에 대해
독립된 흐름 제어를 제공하는데 반해 태그는 모든 태그에 대해 단일 공유
흐름 제어를 사용합니다. 또한 서로 다른 thread의 트랜잭션에는 순서
규칙이 없는 반면 태그로 처리된 트랜잭션은 순서를 변경할 수 없습니다.
마지막으로 개별 thread에는 독립적인 버퍼링이 필요하지만 태그의 경우
모든 태그 간에 흐름 제어가 공유되기 때문에 버퍼링이 필요하지 않습니다. |
|
| 13: |
threads와 함께 사용할 수 있는 흐름 제어의 종류는 무엇이 있습니까? |
| A: |
코어가 한 thread에서 요청을 처리하면서 다른 thread에서도 요청을
처리하도록 하기 위해 여러 개의 “thread busy” 흐름 제어 신호가
제공됩니다. 슬레이브는 SThreadBusy 신호를 사용하여 특정 thread에
대해 더 이상의 요청을 생성할 수 없음을 마스터에게 알릴 수 있습니다.
비슷한 방식으로 마스터는 MThreadBusy 신호를 사용하여 특정
thread에 대해 더 이상의 응답을 발행할 수 없음을 슬레이브에 알릴 수
있습니다. 또한 슬레이브는 SDataThreadBusy 신호를 사용하여 특정
thread에 대해 더 이상의 데이터 handshake 단계를 수락할 수 없음을
알릴 수 있습니다. |
|
| 14: |
여러 개의 threads가 사용될 때 블로킹을 방지하는 방법은 무엇입니까? |
| A: |
서로 다른 “thread busy” 신호에는 OCP 프로토콜의 관점에서 단계별
시간 설정 요구 사항이 없으므로 마스터와 슬레이브 간의 힌트로만 처리될
수 있습니다. 블로킹이 발생하지 않도록 하려면 이러한 각각의 “thread
busy” 신호에 대한 구성 매개 변수를 사용하여 마스터 또는 슬레이브가
정확한 “thread busy” 의미를 따르게 해야 합니다. |
|
|
