PCI BUS 이야기 -kelp-

 PCI 에 대해서 쉽게(?) 설명해 놓은 글..

 PCI 드라이버 개발 전 읽어보니 좋음.

PCI 버스 이야기(0) : 버스 상식

PCI BUS 이야기(0) : 프로그래머가 알아야 할 BUS 상식 ** 시작에 앞서 이 글은 PCI BUS의 소프트웨어적인 측면에 대해 알고 싶은 사람들을 대상으로 쓰여졌습니다. 또한 모든 내용은 PC를 기준으로 작성되었으며 embedded linux 와 직접적인 관련을 맺는다고 볼 수는 없습니다. 그리고 언제나 그렇듯이 이 글에 있는 내용이 모두 참이라고 확신할 수는 없습니다. 당연히 저작권은 holelee < holelee 골뱅이 netian 점 com >에게 있습니다. [ 혹시 이런 허술 한 내용이라도 프린트하고 싶으면 장당 10원씩 송금하기 바랍니다. 당연히 dstribution도 허가를 받아야 하고 어쩌구 저쩌구 크크.. 프린트는 농담이었습 니다. ] 잘못된 점이나 설명이 미진하다고 생각되는 부분이 있으면 알려주기 바랍니다. ** BUS에 대한 짤막한 이야기 A라는 사람이 B라는 사람과 전화 통화를 하고 싶어서 두 사람이 사는 집을 연 결하는 전화선을 하나 설치했다고 생각합니다. 그런데 A는 C라는 사람과도 통 화하고 싶어서 자신의 집에 전화기를 한 대 더 설치하고 C의 집과 자신의 집 사이에 다시 전화선을 설치합니다. 그런 상황에서 A는 또 다시 D와도 통화하 고 싶어서 똑같이 전화를 추가하고 전화선을 설치합니다. 이런 연결을 point- to-point 연결이라고 할 수 있습니다. 계속 이런 point-to-point 연결이 반복 되면 A의 집에는 전화선이 엄청 몰려 들 것이고 A의 집은 각 전화선에 연결되 는 전화기로 가득 차게 됩니다. 이런 상황에서 B도 D와 통화하고 싶으면 서로 전화선을 연결하게 되고, …. 실제로 생각해 보면 A는 B, C, D, … 와 동시에 통화하고 싶은 것이 아니기 때 문에 전화기와 전화선을 위와 같은 방법으로 연결하면 심한 자원의 낭비를 초 래합니다. 자원을 낭비하지 않으면서 원하는 바를 어느 정도 달성하기 위해서 는 A의 집에는 전화기가 한 대 설치되고 그 전화기에서 나온 전화선은 B, C, D 의 집으로 차례대로 연결하면 됩니다. 즉, 동일한 전화선 한 가닥을 A, B, C, D, … 가 공유하는 것입니다. 이렇게 공유하게 되면 A는 B, C, D와 동시에 통 화할 수 없게 되고 B와 D가 서로 이야기할 때도 A는 전화를 걸지 못하게 되지 만 시간적 여유를 가지고 조금만 기다리면 원하는 사람과 통화를 할 수 있습니 다. 물리적인 자원의 소비를 많이 줄이는 대신 시간을 조금 더 소비할 가능성 이 생기는 것입니다. [ 그림으로 설명하면 간단한 것인데, KELP 게시판이 그림 을 지원하지 않으므로 말로 설명하려고 하니 비유를 하게 되었습니다. 그런데 비유가 초등학생 수준이라서 조금 어울리지 않지만 적절한 비유를 찾기가 어려 워서… 이해해주길 바랍니다. ] 컴퓨터에서도 동일한 개념이 적용됩니다. CPU와 Graphic Card, Sound Card, Ethernet Card, IDE device 등을 연결하는데 모두 point-to-point 연결을 사용 할 수는 없습니다. 역시 어떠한 전기적 신호가 지나는 선을 모두 공유하게 되 는데 이것을 BUS라고 부릅니다. 이렇게 공유된 전기선을 이용하여 정보를 전달 하기 위해서는 그 전기선에 연결된 모든 device가 어떤 약속을 따라야 합니 다. 이러한 약속은 전기선의 개수와 종류에서부터 그 위에 실리는 전기적인 신 호에 대한 것, 그리고 기계적인 부분(예를 들면 슬롯)에 대한 것까지로 이 약 속들이 어떠한 BUS를 규정짓는다고 할 수 있습니다. (비교) BUS와 다른 개념으로 Port라는 개념이 있습니다. 현재 대부분의 PC에 는 Graphic Card를 연결할 수 있는 AGP(Accelerated Graphic Port 의 약자로 추정)라고 하는 슬롯이 달려 있습니다. Port는 보통 point-to-point 연결을 의 미합니다. 따라서 공유되지 않습니다. AGP 슬롯이 여러 개 달려 있는 PC를 본 적이 있습니까? 그러고 보니 Serial도 Port내요. 가끔 하나의 UART에 여러 개 의 장비를 물리길 원하는 사람들이 질문을 하는데 부가적인 방법이 있을 수는 있겠지만, Serial Port 자체로는 불가능합니다. 그런데 USB는 Universal Serial Bus의 약자이기는 하지만 엄밀히 말하면 BUS라고 부르기에는 적합하지 않습니다. ** BUS의 동작 CPU가 BUS에 달려 있는 device에 전달하고 싶은 것은 단 두 가지 입니다. Address를 주고 device의 내용을 읽고 싶다고 하는 요청하는 것(Read)과 Address와 data를 주고 device에 내용을 적고 싶다고 요청하는 일(Write)입니 다. 이 Address와 Data가 BUS에 실려서 옮겨지는 내용이 되는 겁니다. 그런데 BUS에는 많은 device가 달려 있는데 CPU가 어떤 device에게 요청을 보내는지 알 수 있어야 해당 device가 그것에 대한 반응을 할 수 있습니다. 이것을 해결 하기 위해 device내부에는 address decoder가 있습니다. BUS에 address 0x0010 이 실리면 device1이 반응을 하고 address 0x0020이 실리면 device2가 반응을 하는 식입니다. 각 device는 BUS에 실리는 address를 살피고 있다가 자신을 지 칭하는 address라면 자신이 반응을 하고 아니면 무시하게 됩니다. (비교) StrongARM의 ChipSelect 신호도 Address의 일부라고 생각할 수 있고, 각 device는 CS 신호를 decoding하는 address decoder를 가지고 있는 것 같이 동작하므로 비슷하게 이해할 수 있습니다. 그런데 Read/Write 요청을 CPU만 하는 것이 아니고 다른 device도 할 수 있는 경우도 있습니다. 한 Read/Write 요청에 대해서 요청을 하는 device를 보통 Master라고 부르고, 반대로 Read/Write 요청을 받는 device를 Slave라고 부릅 니다. Device에 따라서 Master로만 동작할 수도, Master/Slave로 동작하는 수 도, Slave로만 동작할 수도 있습니다. CPU는 Master로만 동작하는 device입니 다. 어떤 BUS에 Master가 여러 개가 존재하게 되면 Master 끼리 서로 BUS를 사용하 고자 할 때 문제가 생깁니다. 위의 전화 예제에서 모두 공유된 전화선을 사용 할 때, B는 D와 통화하고 싶어하고, A는 C와 통화하고 싶어하면 둘 중에 하나 는 통화를 못하게 되고 기다려야 하는 상황이 발생하는 겁니다. 이럴 때 해결 하는 방법은 여러 가지가 있으나 일반적인 컴퓨터 시스템에서는 Arbiter[스타 크래프트 생각하는 분들도 있을 듯.]를 사용하여 해결하는 법을 주로 사용합니 다. 예를 들어 초등학교 교실에서 선생님이 칠판에서 설명하는 와중에 “….하 는 것이 뭐죠?”라고 물어보면 학생들이 서로 손을 들고 발표하려고 합니다. 그 때 선생님은 한 명을 지적하고 발표를 할 수 있도록 하겠죠. 이 선생님 같 은 역할을 하는 것이 Arbiter입니다.[이 비유도…] Master는 BUS를 사용하고 싶을 때 Arbiter에게 신호를 보내어 자신이 BUS를 사용하고 싶다는 요청을 하 고 기다립니다.(이 연결을 Master와 Arbiter 사이의 point-to-point 연결이어 야 합니다.) Arbiter는 여러 개의 Master에서 온 요청 신호를 보고 한 Master 에게 요청을 허가한 다는 신호를 보내고 다른 Master에게는 신호를 보내지 않 습니다. 그럼 허가를 받은 Master는 BUS를 마음껏 사용하고 다시 Arbiter에게 자신이 BUS를 다 사용했다고 보고하면 Arbiter는 다시 새로 BUS를 점유할 Master를 선정해 허가 신호를 내주는 식으로 동작합니다. (참고) BUS위에 전송되는 신호 중에 interrupt도 있습니다. Interrupt는 당연 히 point-to-point 연결을 하는 것이 원칙입니다. 추후에 PCI BUS 설명할 때 설명하겠습니다. 가끔은 서로 다른 규약의 BUS를 연결하거나 동일한 규약의 BUS 여러 개를 연결 해야 할 필요가 있는 경우가 있습니다. 이런 경우 두 개의 BUS를 연결하는 장 치를 보통 Bridge라고 부릅니다. Bridge가 하는 일에는 Address/Data의 변환 이 필요하기도 하고, Bridge가 그 일을 수행해 줍니다. ** 프로그래머가 생각하는 BUS 하드웨어(Chip 또는 보드) 설계자는 설계하고자 하는 하드웨어에서 사용하는 BUS의 세부적인 내용을 거의 모두 알고 있어야 제대로 설계를 할 수 있습니 다. 하지만 프로그래머는 어떤 device가 어떤 BUS에 붙어(전기적, 물리적으 로) 있다는 가정하에서 출발하고, Device를 BUS에 전기적, 물리적으로 붙이는 일은 전적으로 하드웨어 설계자의 일이므로[일반적으로 이런 환상적인 경우는 없죠.], 프로그래머는 BUS의 세부적인 모든 것을 알 필요가 없습니다. 프로그래머가 device와 BUS에 대해 꼭 알아야 하는 것은 “소프트웨어에서 어 떤 address를 접근해야 device를 제어할 수 있는가?”입니다. 즉, CPU의 physical address와 device의 영역 사이의 mapping이 프로그래머의 관심사입니 다. 거기에 한가지를 더하면 device가 발생시키는 interrupt가 IRQ 몇 번인지 정도입니다. Address mapping과 IRQ만 알면 대부분의 device를 제어하는 데 부 족함이 없고 어떤 device가 잘 붙어 있다라고 하면 address mapping과 interrupt의 연결이 잘 되어있는 것을 의미합니다. 프로그래머는 그것을 알아 내기 위해서 하드웨어 설계자에게 물어볼 수도 있고, 아니면 보드 schematic 과 매뉴얼을 뒤져 보고 알아낼 수 있는 능력이 있으면 됩니다. Address mapping과 interrupt를 제일 중요하기는 하지만 우리가 알아보고자 하 는 PCI BUS의 경우는 좀 더 많이 알아야 할 것이 있습니다. 그 것이 이 글이 쓰여진 이유입니다. ** 글을 마치며 이런 글을 적을 때 어려워하는 것 중에 하나는 글을 전체적으로 어떻게 시작하 고 어떻게 끝내야 하는지 결정하는 일입니다. 짧게 쓰는 글이 아닌 이상, 생각 의 흐름이 자연스럽게 흘러갈 수 있도록 작성되어야 한다는 생각입니다. 그리 고 전체적으로 그냥 부담 없이 한번 읽는 것으로 이해가 모두 될 수 있게 적으 려고 노력합니다. 아무튼 글의 전체적인 구성을 결정하는 일은 글을 읽는 사람 들의 수준이 어느 정도일까를 예상하는 것에서부터 시작합니다. 글 전체의 제 목이 “PCI BUS 이야기”인데 글을 읽을 사람들을 고수들로 한정하면, “Specification을 읽으면 다 나옵니다.”란 단 한 줄의 글이 되던지, Specification에는 나오지 않고 실제 응용에서 나올 수 있는 꼼수 등에 관한 글이 될 것입니다. 능력상 그런 글을 적을 만큼 고수도 아니므로 주로 초보자 들을 독자층으로 하는 글을 적게 됩니다. 초보자들도 어떤 초보자냐에 따라서 글의 난이도가 다시 결정 되어야 합니다. 그런데 이번 BUS 상식에 관련된 글은 좀 난이도 조절을 실패한 듯한 느낌이 듭 니다. 독자들의 수준을 너무 낮게 잡았다는 생각이 듭니다. 글이 어느 정도 길 기는 한데 글의 내용의 수준은 너무 낮아서 오히려 읽는 사람들이 무시당한 듯 한 느낌 – “이런 허술한 글을 내가 모를 줄 알고, 흥?” 정도 – 을 가지지 않 았을까 두렵습니다. “PCI BUS 이야기”의 시작은 ISA BUS의 문제점을 설명하 면서 시작하는 것이 좋았을 것이라는 생각이 듭니다. 그래서 이 글이 0번째 글 로 정해졌습니다. 다음 글이 진정한 첫 번째 글이 될 듯 합니다. 다음 글에는 ISA BUS의 문제점 및 그 해결 방안 모색에 관련된 내용이 될 것입니다. 그럼, 프린트는 장당 10원씩 송금하는 것 잊지 마시고…

PCI 버스 이야기(1) : ISA BUS의 문제점및 해결

[ Original Size 837 * 676 ] PCI BUS 이야기(1) : ISA BUS의 문제점 및 해결 ** 시작에 앞서 이 글은 PCI BUS의 소프트웨어적인 측면에 대해 알고 싶은 사람들을 대상으로 쓰여졌습니다. 또한 모든 내용은 PC를 기준으로 작성되었으며 embedded linux 와 직접적인 관련을 맺는다고 볼 수는 없습니다. 그리고 언제나 그렇듯이 이 글에 있는 내용이 모두 참이라고 확신할 수는 없습니다. 당연히 저작권은 holelee < holelee 골뱅이 netian 점 com >에게 있습니다. [ 혹시 이런 허술 한 내용이라도 프린트하고 싶으면 장당 10원씩 송금하기 바랍니다. 당연히 distribution도 허가를 받아야 하고 어쩌구 저쩌구 크크.. 프린트는 농담이었 습니다. ] ** PC 우선 이 글에서 말하는 PC는 개인용 컴퓨터라는 일반적인 뜻이 아니라, x86 CPU기반의 IBM PC 호환 플랫폼을 이야기 합니다. PC가 지금과 같이 대중화된 이유 중에 하나는 많은 third-party vendor가 존재한다는 점입니다. 하드웨어/ 소프트웨어 표준이 있고 그에 해당하는 각종 하드웨어/소프트웨어를 수 많은 회사들이 제공하였습니다. 하드웨어의 측면만 보면 표준화된 BUS와 slot이 있 었고, 그 BUS에 장착할 많은 하드웨어를 다양한 회사에서 제공하였습니다. 그 런 하드웨어로 사용자는 PC를 통해 다양한 활용을 할 수 있었습니다. 간단한 예로 TV 카드를 PC에 장착하여 TV 시청을 할 수도 있고, Sound 카드와 MIDI 장 치를 연결하여 음악을 작곡하거나 하는 일에 사용할 수도 있습니다. PC의 탄생에서부터 확장 카드를 부착할 수 있는 많은 BUS들이 있었습니다. 가 장 오래된 ISA 8bit BUS부터 시작하여 ISA 16bit BUS, EISA, MCA, VESA Local BUS, PCI 등을 꼽아 볼 수 있습니다. 현재 PC 환경에서는 PCI BUS만 지원하고 간혹 옛날 주변 기기의 이용을 위해서 ISA BUS가 있는 시스템이 있습니다. 그 리고 PCI BUS의 대역폭이 모자란 부분도 있어서 PCI BUS보다 좋은 차세대 BUS 에 대한 논의가 활발히 진행 중입니다. 현재 PC 환경하에서 PCI BUS와 ISA BUS가 존재하는 위치에 대해서 잠시 알아보 겠습니다. 우선 Pentium계열 PC의 CPU은 CPU BUS에 연결되어 있고 CPU BUS는 일명 “North Bridge”라고 불리우는 bridge chip에 의해 PCI BUS로 연결됩니 다. North bridge에는 PCI BUS뿐 아니라 Memory와 AGP Port가 연결되어 있습니 다. North bridge에서 출발한 PCI BUS에는 mainboard상에 있는 slot들이 모두 연결되어 있고 “South Bridge”라는 bridge chip도 연결되어 있습니다. 이 South Bridge 내부에는 PCI BUS에 직접 연결되는 IDE controller나 USB controller등의 PCI device들이 존재하고, ISA BUS와 연결해 주는 ISA BUS bridge가 존재합니다. [그림 참조] 물론 mainboard 상에 이미 납땜되어 나오 는 On Board PCI device들도 직접 PCI BUS에 물려 있습니다. CPU가 Read operation을 위해서 CPU BUS에 address(CPU의 physical address) 를 전하면 North Bridge는 그 address가 Memory를 가리키는지 아니면 AGP Port 혹은 PCI BUS에 해당하는지 판단합니다. Address가 PCI BUS에 해당하는 영역이 라면 그 address를 변환하여 PCI BUS address로 바꾸고 그 address를 PCI BUS 에 전하게 됩니다. PCI BUS address가 PCI BUS에 전해지면 그 address가 해당 하는 device는 응답을 하고 data를 PCI BUS에 싣게 됩니다. 그 data는 다시 North Bridge를 통해서 CPU로 돌아갑니다. Write operation은 생략합니다. (참고) Pentium3 계열 CPU의 physical address는 32bit보다 큽니다.(36bit였 던 것으로 기억하는데 확실치는 않습니다. 32bit CPU의 physical address가 32bit보다 클 수 있는 이유는 MMU 때문입니다.) 그런데 일반 PC에서 사용되는 PCI BUS는 32bit BUS라서 address가 32bit로 제한됩니다. 따라서 중간에 CPU BUS에 실린 address(CPU의 physical address)와 PCI BUS의 address의 변환이 이루어 져야 합니다. 그리고 CPU BUS의 data 폭은 64bit인데 PCI BUS의 데이 터 폭은 32bit이므로 그 변환도 North bridge에서 이루어지게 됩니다. 연결하 는 두 BUS의 전기적 신호 맞추기 뿐 아니라, Address 변환과 Data 변환(?)도 Bridge의 중요한 일 중에 하나입니다. 사실 North Bridge와 South Bridge를 사용하는 구성은 Pentium때부터 시작되었 습니다. 하지만 최근 Pentium3 계열 PC와 Pentium4 계열 PC의 경우 North Bridge와 South Bridge 구조를 벗어나 MCH(Memory Control Hub)와 ICH(I/O Control Hub)를 이용한 구조로 바뀌면서 ISA BUS가 사라졌습니다.[그림 참조] 여전히, ISA BUS를 굳이 사용하겠다면, 여기에 PCI-ISA Bridge Device를 따로 장착하면 되지만 ISA BUS의 필요성이 극히 낮기 때문에 그런 예를 찾아보기는 힘듭니다. ** ISA BUS PCI BUS를 이야기하기 전에 ISA BUS의 문제에 대해서 먼저 알아보도록 하겠습 니다. 약 3년 전부터 PC의 mainboard에서 ISA BUS slot이 사라지고 있지만, 약 20여년간 PC에서 장수했던 BUS가 ISA입니다. ISA BUS slot과 장착하는 확 장 카드의 모양을 모르는 분들은 없을 것으로 생각합니다. 우리는 프로그래머이므로 ISA BUS에서 주목해야 하는 부분은 역시 address mapping과 IRQ입니다.(PCI BUS 이야기(0) 참조) X86계열 CPU는 I/O region address과 memory region address가 따로 있는, 소위 I/O mapped I/O를 사용하 는 CPU입니다. X86 CPU에서 I/O region address는 16bit로 나타내어지고 따라 서 address 영역의 크기는 64KB(2^16Byte)가 됩니다. Linux kernel source에 서 inb(), outb(), inw(), outw(), inl(), outl()등의 함수를 이용하여 access 하는 것이 이 I/O region입니다. ISA BUS slot에 장착되는 확장 카드는 대부 분 이 I/O region을 사용하였습니다. PC의 사용자가 ISA BUS slot에 어떤 확장 카드를 장착하여 사용할 수 있게 만 들려면 당연히 I/O region의 어떤 address가 이 확장 카드와 mapping이 되어 야 하고 IRQ도 역시 주어져야 합니다. 예를 들면 Sound 카드 SoundBlaster(ISA 용)는 보통 address 영역 0x0220~0x022F를 사용하고 IRQ 5번을 사용했습니다. BUS는 공유된 전기선이므로 CPU가 ISA BUS에 0x0220의 address로 Read를 요청 하면 ISA BUS에 달려있는 장치들 중에 SoundBlaster만 응답을 하고 나머지 장 치들은 무시해야 제대로 된 동작이 가능하게 됩니다. 그렇게 하려면 우선 프로 그래머는 address를 알아야 하고 확장카드, 즉 device도 자신의 address가 얼 마인지 알고 있어야 합니다. ISA BUS slot에 장착되는 확장 카드들은 이 address가 hardwired address decoder에 의해 결정되었습니다. 즉, SoundBlaster는 제작할 때 이미 0x0220과 IRQ5로 하드웨어로 정해졌다는 말입 니다. 그런데 문제가 있는데, 확장 카드에 부여되는 address는 어떤 표준에 따라서 유일하게 주어지는 것이 아니라 확장 카드 회사가 마음대로 정할 수 있었습니 다.(실제로는 Network card는 address 영역 A, Sound card는 address영역 B등 에서 골라서 사용한다는 약간의 guideline이 있었습니다.) 만약 다른 회사에 서 만든 A라는 카드도 0x0220을 사용하면 카드A와 SoundBlaster는 동시에 한 PC에 장착될 수 없게 됩니다. 이렇게 사용하는 address 영역이 겹치는 경우를 전문용어(?)로 address가 쫑이 났다고 하는데 동일 address에 응답하는 장치 가 두 개이므로 제대로 된 data가 BUS에 실릴 수 없으므로 CPU가 제대로 data 를 읽을 수 없게 됩니다. 그런데 I/O region 64KB는 상당히 작은 공간이라서 그런 문제가 발생할 가능성이 매우 컸습니다. 또한 SoundBlaster 카드 두 장 을 동시에 한 PC에 장착하는 것도 불가능합니다. Address 문제뿐 아니라 IRQ에 서도 동일한 문제가 생기게 됩니다. 이 문제를 해결하기 위해서 많은 확장 카드는 점퍼와 같은 하드웨어적인 설정 방법을 사용하였습니다. 예를 들어 SoundBlaster는 점퍼 설정에 따라 0x0220~0x022F, 0x0240~0x024F, 0x0260~0x026F까지의 address 영역 중에 하나 를 선택할 수 있었고, IRQ는 5, 7, 9, 10 중에 하나를 선택할 수 있었습니다. 카드를 설치하기 위해서는 PC에 이미 사용중인 확장카드들이 사용하는 IRQ와 address 영역을 모두 파악하고 address와 IRQ가 겹치지 않도록 점퍼설정을 잘 해주어야 했습니다. 설혹 잘 설치되었다고 해도 프로그래머는 해당 device가 점유할 수 있는 address영역과 IRQ를 모두 찾아보도록 프로그래밍을 해야 하 는 번거러움이 남게 됩니다.(실제 linux kernel도 이러한 방법을 사용합니다. 대다수의 DOS 게임은 더 무식하게 address와 IRQ를 사용자에게 직접 물어봤습 니다. 게임을 하기 위해서도 address와 IRQ와 같은 지식이 필요했으니, 참 멋 지이이인 시스템이었습니다.) ISA BUS에서 이러한 문제를 해결하기 위해서 PnP(Plug & Play)방법이 있었습니 다만 잘 알지 못할 뿐 아니라, 지금은 이미 PCI BUS로 대세가 넘어간 시대이므 로 ISA PnP에 대해서 자세한 내용은 굳이 알 필요가 없으므로 설명하지 않겠습 니다. 대신 이 것을 어떻게 해결할 수 있을까를 직접 생각해 보도록 하겠습니 다. ** 각 vendor의 입장 차이 문제 해결에 앞서 이 문제가 대두된 이유를 알아볼 필요가 있습니다. 근본적 인 이유는 PC에 각종 하드웨어와 소프트웨어를 제공하는 회사가 매우 많기 때 문일 겁니다. PC의 모든 하드웨어와 소프트웨어를 한 회사에서 공급하면 그 회 사 내부에서 모든 것을 조정하면 되므로, 큰 문제가 생기지 않았을 겁니다. 수 많은 회사를 임의대로 다음과 네 가지로 나누어 생각해 보도록 하겠습니다. (1) 확장 카드 제작자 (2) OS 제작자/driver 제작자 (3) Mainboard 제작자/ROM BIOS 프로그래머 (4) 기타 우리들의 논의와 하등 관련이 없는 회사. 어떤 확장 카드 하나를 만들어 PC에 장착한다는 가정하에, 각 회사나 제작자들 의 입장을 정리해 보도록 하겠습니다. * 확장 카드 제작자 확장 카드 제작자는 자신이 만드는 확장 카드에 대한 모든 내용을 알고 있습니 다. (1) 확장 카드가 하는 address 영역의 크기(이하 MYSIZE라고 하겠습니다.)를 알고 있습니다. 즉, 프로그래밍이 가능한 레지스터가 총 몇 개고, 확장 카드내 부에 CPU가 직접 접근 가능한 영역이 얼마나 있는지 알고 있습니다. (2) 확장 카드가 interrupt 사용하는지 사용하지 않는지 여부를 알고 있습니 다. 확장 카드 제작자는 제작된 확장 카드가 설치될 PC에 대해서 아는 바가 전혀 없습니다. 뭐 알 필요가 없으면 관계가 없지만 확장 카드를 제조하기 위해서 알아야 하는 내용인데도 알 수 없는 정보가 다음과 같습니다. (1) 사용자의 PC에서 확장 카드가 사용할 수 있는 address 영역을 모릅니다. 확장 카드에 address decoder가 제대로 동작하려면 하드웨어는 address를 알 고 있어야 합니다만, 확장 카드를 만드는 시점에서는 사용 가능 address를 알 방법은 없습니다. (2) 마찬가지로 사용자의 PC에서 확장 카드가 사용할 수 있는 IRQ를 모릅니다. * OS 제작자/driver 제작자 OS 제작자 및 driver 제작자가 알고 싶은 내용은 다음과 같습니다. (1) 사용자의 PC에 어떤 확장 카드들이 장착되었는지 알고 싶습니다. (2) 장착된 확장 카드들이 어떤 address를 사용하고 어떤 IRQ를 사용하는지 알 고 싶습니다. * Mainboard 제작자와 ROM BIOS 제작자 Mainboard 제작자와 ROM BIOS 프로그래머는 동일인(또는 동일 회사)으로 봐도 무방하고 그 들은 자신이 만든 Mainboard에 대한 모든 내용을 알고 있습니다. (1) Mainboard에 달려있는 여러 개의 slot이 몇 개이고 각 slot에서 나온 전 기 신호들이 어떤 형식으로 다른 칩 및 CPU에 연결되는지 알고 있습니다. (2) Mainboard의 각 slot에 전기적 신호를 직접 보낼 수 있는 하드웨어가 무엇 인지 알고 있고 그것을 ROM BIOS로 프로그래밍할 수도 있습니다.. ** 해결 방법 사실 문제의 직접적인 원인은 hardwired address decoder와 역시 Hardware적으 로 결정된 IRQ에 있다고 할 수 있습니다. 확장 카드 제작자는 확장 카드를 만 들기 전에 쫑이 나지 않는 address와 IRQ를 알고 싶은데, 사용자의 PC 환경에 대해서 아는 바가 전혀 없으므로 카드 제조를 할 수가 없습니다. 그래서 우선 address decoder를 programmable하게 바꾸고 IRQ는 mainboard가 알아서 하도 록 만들어서 해결해 보도록 합니다. * programmable address decoder MYADDR이라는 이름의 register가 각 확장카드에 존재하며 각 확장 카드의 address decoder 하드웨어는 “MYADDR~MYADDR+MYSIZE”에 해당하는 address영 역에 대해서 응답하도록 합니다. 예를 들면 Soundblaster를 만드는 데 0x0220~0x022F에 응답하는 hardwired address decoder를 사용하지 말고, MYADDR=0이면 0x0000~0x000F에 응답하도록 하고, MYADDR=0x220이면 0x0220~0x022F에 응답하도록 하드웨어를 만듭니다. 이렇게 되면 확장 카드 제 작자는 확장 카드의 address decoder를 하드웨어로 꾸밀 때 어떠한 다른 정보 도 필요 없이 꾸밀 수 있습니다. 실제 address decoding 기능이 다른 확장 카 드와 겹치거나 하는 것에 대한 모든 책임은 MYADDR라는 레지스터에 값을 기록 하는 다른 누군가에게 전가 됩니다. * IRQ 확장 카드 제작자는 확장 카드를 만들 때 IRQ 번호를 직접 결정하지 않고, 단 순히 slot에 있는 하나의 약속된 핀으로 interrupt 전기적 신호를 보내도록 합 니다. 그 전기적 신호가 어떻게 interrupt controller에 연결되는지는 mainboard 제작자가 관여합니다. 이런 해결 방법으로 우선 확장 카드 제작자는 원하는 확장 카드를 address 쫑 이나 IRQ 쫑 걱정 없이 만들 수 있습니다. 그 다음 OS와 driver 제작자는 사용 자의 PC에 어떤 확장 카드들이 설치되어 있는지 정확하게 알고 싶으므로 그것 을 위해 ID라는 것을 만듭니다. * ID 모든 종류의 확장 카드는 유일하게 할당되는 ID를 가지고 있도록 합니다. 물 론 그 ID값을 CPU가 소프트웨어적으로 읽을 수 있어야 합니다. 즉 read-only register에 어떤 유일한 값이 들어 있는 것입니다. 그 ID를 읽어 보면 이 것 이 어느 회사에서 만들어진 어떤 확장 카드라는 것을 알 수 있습니다. 이제 어느 정도 해결되었습니다. 하지만 여기서 곰곰히 생각해보면 또 다른 문 제가 있습니다. 우리는 확장 카드의 address와 IRQ의 할당 문제를 해결하려고 했는데 그것의 해결책이 MYADDR과 ID와 같은 register를 읽고 쓰는 것이라면 대체 MYADDR과 ID와 같은 register는 어떤 address로 접근을 해야 할까요? Address문제를 해결하려는데 다른 address 문제가 생겨버린 셈이니 별로 해결 된 것 같지 않습니다. 이 때 mainboard 제작자의 힘이 나옵니다. 위에서 언급 한대로 mainboard 제작자는 mainboard에 달려있는 슬롯이 몇 개인지 알고 있 고, 각 슬롯에 인가되는 전기적 신호를 모두 제어할 수 있는 하드웨어(보통의 PC라면 North Bridge에 해당)에 대해 모든 것을 알고 있습니다. 이제 수수께끼 는 그만하고 정리해 보도록 하겠습니다. * 정리 확장 카드 제작자는 확장 카드를 만들 때 다음과 같은 내용이 들어있는 독립적 인 register를 만들고 그 register로의 접근을 특정 전기적 신호를 통해서 가 능하도록 합니다.(즉 이 방법은 평소 CPU가 확장 카드를 접근하는 전기적 신 호 패턴과 구별됩니다.) (1) ID(read-only) (2) MYSIZE(read-only) (3) MYADDR(read/write) (4) MYIRQ(read/write) mainboard에 Power가 인가되면 ROM BIOS가 수행되고, ROM BIOS는 각 slot에 특 정 전기적 신호로 접근하여 MYSIZE를 읽어 옵니다. 그런 후에 CPU의 address space 중 MYSIZE만큼을 할당하여 MYADDR에 적습니다. 또한 각 slot에서 나온 interrupt signal이 어떻게 interrupt controller로 routing되고 있는 지 알 고 있으므로 각 slot에 해당하는 IRQ를 mainboard 제작자는 알고 있습니다. 그 값을 MYIRQ라는 register에 적습니다. 그 다음 위의 register를 접근할 수 있는 software interface(보통 BIOS call)를 설치하고 OS를 loading합니다. OS는 제어권을 받으면 ROM BIOS에서 제공하는 software interface를 통해 다 시 BUS에 달려있는 확장 카드에 접근하여 위의 네 register값을 읽어옵니다. ID를 통해 어떤 확장 카드인지 알아내게 되고, 그에 해당하는 driver를 호출 합니다. driver는 MYADDR과 MYIRQ의 값을 이용하여 하드웨어에 접근하여 하드 웨어를 동작시킵니다. (ROM BIOS가 할 수 있는 하드웨어 제어를 통해 각 slot에 접근하여 MYADDR과 MYIRQ를 적어 주는 일을 OS가 할 수 없는 이유는 당연히 mainboard에 달려 있 는 하드웨어를 알 수 없기 때문입니다.) 이렇게 하면 모두 해결할 수 있습니다. Address 쫑 문제와 IRQ 쫑 문제도 ROM BIOS가 잘 해결하였고, 사용자가 PC에 특정 확장 카드를 장착한 후에 Power만 키면 OS가 알아서 driver를 수행하여 그 카드를 동작시킵니다. (물론 OS 출시 후에 나온 확장 카드라면 driver를 따로 설치해야 합니다.) (참고) 사실 PC에서 위와 같은 vendor가 여럿이어서 나타나는 문제는 확장 카 드뿐 아니라 다른 여러 군데에서 비슷하게 나타나고 비슷한 방법으로 해결합니 다. 예를 들어 PC에 설치된 RAM의 크기가 얼마인지 알고 싶은 것은 OS입니다. 실제로 RAM Module 각각에는 사이즈 정보가 들어 있는 작은 ROM이 있고, Module이 몇 개 설치되었는지는 ROM BIOS 프로그래밍 실행되면서 detect할 수 밖에 없습니다. ROM BIOS가 실행되면서 각 Module에 달려 있는 Serial ROM에 접근하여 시스템 전체에 설치된 RAM의 크기를 알아내고, 그것을 OS에 알려줄 수 있는 software interface를 설치하고, OS는 그 interface를 사용하여 RAM 의 크기를 알아냅니다. ** 이번 글 마무리 이번 글에서는 ISA BUS에 존재하는 문제점에 대해서 살펴보았고, 그 문제점을 해결할 수 있는 한가지 방법을 모색해 보았습니다. 이 방법은 실제 PCI BUS에 서 사용하는 방법을 간략화한 것입니다. 다음 글부터는 실제 PCI BUS에 대해 서 알아보도록 하겠습니다. ** 잡설 PCI버스 이야기(0)에 예상치 않게 많은 리플이 달려서 당황했습니다. 많은 분 들이 제게 힘을 주시려고 하셨는데 솔직히 기쁘기도 하지만 부담이 큽니다. 그 런데 아직도 전체적인 글의 구성이 어떤 식으로 될 지 모르겠습니다. 물론 맨 마지막은 Samsung ARM Chip에 있는 PCI Bridge의 프로그래밍 방법에 대한 이야 기로 끝날 것이지만 나머지 부분을 어떻게 구성해야 하는지 잘 모르겠습니다. 서로 cross reference되는 부분들이 있어서 어떤 순서로 진해되어야 하는지 상 당히 어렵습니다. 제 이해 수준이 떨어져서 그런 것 같은데, 뭐 힘 되는 대로 써 놓고 피드백이 오면 수정하는 식으로 해야 하지 않을까 생각이 듭니다. 이 번 글도 좀 두서가 없는 것 같은데, 혹 이해가 안되는 부분이 있으면 알려 주 시기 바랍니다. 알려 주신 부분들을 모아서, 모든 글의 진행이 끝난 후에 글 을 수정하여 올려 드리도록 하겠습니다. 두서 없는 글이라도 올리는 이유는 계속 혼자 요리 조리 고쳐봐도 글의 완성도 가 높아지지 않는다는 생각이 들었기 때문입니다. 우선 저질러 놓고 나중에 수 습하는 것이 좋을 것 같아서…이해해 주시기 바랍니다. 괜히 시작한 것 같다 는 후회도 약간 듭니다. 쿨럭…

PCI 버스 이야기(2) : PCI BUS의 특징

PCI BUS 이야기(2) : PCI BUS의 특징 ** 시작에 앞서 이 글은 PCI BUS의 소프트웨어적인 측면에 대해 알고 싶은 사람들을 대상으로 쓰여졌습니다. 또한 모든 내용은 PC를 기준으로 작성되었으며 embedded linux 와 직접적인 관련을 맺는다고 볼 수는 없습니다. 그리고 언제나 그렇듯이 이 글에 있는 내용이 모두 참이라고 확신할 수는 없습니다. 당연히 저작권은 holelee < holelee 골뱅이 netian 점 com >에게 있습니다. [ 혹시 이런 허술 한 내용이라도 프린트하고 싶으면 장당 10원씩 송금하기 바랍니다. 당연히 distribution도 허가를 받아야 하고 어쩌구 저쩌구 크크.. 프린트는 농담이었 습니다. ] ** PCI BUS의 소개 PCI BUS의 탄생 및 역사 나부랭이는 인터넷에서 직접 찾아 보길 바랍니다. (직 접 나부랭이를 찾아서 알려드리면 좋겠지만, 개인적으로 별로 중요하게 여기 지 않는 부분이므로 무시합니다.) ** PCI BUS의 특징 PCI BUS가 다른 BUS와 구별되는 특징을 알아볼 필요가 있습니다. “PCI BUS 이 야기(0)”에서 알아본 것처럼 BUS는 전기 신호에 대한 약속 및 그 사용에 대 한 약속이므로 결국 그 약속이 다른 BUS와 구분됩니다. 하지만 그 약속 하나하 나를 모두 알아볼 수는 없으므로 상식적으로 알아야 하는 부분에 대해서 대략 적으로 알아 보겠습니다. (1) PCI BUS는 local BUS입니다. “local bus”는 CPU에 거의 직접적으로 붙어있고, 빠른 속도로 동작하는 주 변장치를 위해 design된 bus를 말합니다. ISA BUS가 아직도 시장의 주류일 때, Graphic card및 IDE 장치를 위해 좀더 빠른 속도로 동작하는 BUS의 필요성 이 대두되었습니다. 그런데 ISA BUS를 계속 확장해 봐도 하위 호환성 (backward compatibility) 때문에 한계에 다다르게 됩니다. ISA BUS보다 좀 더 CPU와 가까운 곳에 붙어있고 좀더 빠른 속도로 동작하는 버스의 필요성이 생겼는데 그 때 등장하게 된 개념이 “local bus”입니다. Vesa-Local BUS라 는 것이 잠시 등장했었으나 곧 PCI Local BUS로 통일되었습니다.(역사 나부랭 이를 약간 지껄였네요.) 현재는 ISA BUS가 시장에서 사라지고 있고 bus topology가 PCI BUS가 도입되었던 시기와 변했으므로 “local bus”라는 의미 는 퇴색하였습니다. 따라서 현재는 PCI BUS는 단순히 확장카드를 장착할 수 있 는 BUS로 보면 됩니다. (2) PCI BUS는 synchronous bus이고 clock의 속도는 33Mhz(또는 66Mhz)까지 지 원합니다. Synchronous라는 말을 모르는 사람은 없을 것입니다. Clock에 동기 (synchronization)되어 작동한다는 말입니다. PCI BUS의 경우 clock의 속도를 최고 33Mhz(또는 66Mhz)까지 지원하게 됩니다. 실제 지금 사용되는 대부분의 PC의 경우 PCI BUS의 clock으로 33Mhz를 사용합니다. 하지만 옛날 Pentium 프 로세서가 막 나왔을 때에는 메인보드의 점퍼 셋팅에 따라서 PCI BUS의 clock 이 25Mhz, 30Mhz, 33Mhz 등의 값을 가질 수 있었습니다. 따라서 확장 카드를 만들 때 33Mhz까지 동작하도록 만들어야 하고, PCI BUS의 clock을 이용하여 시 간을 측정하거나 하면 안됩니다. 예를 들어 Sound card를 만들 때 audio의 sampling 주파수(예를 들어 44.1Khz)를 만들 때 PCI BUS의 clock을 이용해서 만들면 안됩니다. 지금은 대부분의 경우 33Mhz로 동작한다고 가정해도 무방하 지만, 사용자의 overclock등의 이유로 33Mhz보다 높거나 낮은 clock을 가질 수 도 있기 때문입니다. 66Mhz의 clock을 가지는 PCI BUS도 존재합니다. 이것은 완전히 확장 슬롯의 모 양이 다릅니다. 보통 PC에서는 사용되지 않고 Server에서 사용되는 경우가 있 습니다. (3) PCI BUS는 32bit(또는 64bit)의 버스 폭을 가집니다. PCI BUS를 통해서 전달되는 data의 버스 폭은 32bit(또는 64bit)입니다. 또한 address의 크기도 역시 32bit(또는 64bit)입니다. 현재 PC에서 주로 사용되고 있는 PCI BUS의 경우 32bit 버스 폭을 가집니다. 64bit 버스 폭을 가지는 경우 는 역시 확장 슬롯의 모양이 완전히 다르고 66Mhz의 경우와 마찬가지로 주로 Server에서 사용됩니다. 일반적으로 PC에 사용되는 PCI BUS의 경우 33Mhz로 동작하고 32bit buswidth 를 가지게 되므로 132MB/sec(32bit*33Mhz = 4Byte*33Mhz)의 대역폭(bandwidth) 를 가집니다. 가장 대역폭이 높은 66Mhz로 동작하고 64bit buswidth를 가지는 경우는 528MB/sec(64bit*66Mhz = 8Byte*66Mhz)의 대역폭을 가집니다. (32bit@66Mhz, 64bit@33Mhz의 조합도 가능합니다.) 132MB/sec(32bit@33Mhz)의 경우 PCI BUS가 처음 도입될 때는 상당히 큰 대역폭 이었는지 모르지만 현재는 많이 부족합니다. Graphic Card의 경우 이미 AGP라 고 하는 고속의 전용 포트를 이용하고 있습니다.(이 녀석도 2X, 4X, 8X 이라 고 계속 두 배씩 대역폭이 증가하고 있습니다.) Gigabit ethernet을 지원하는 NIC(Network Interface Card)의 경우에도 132MB/sec라는 대역폭이 부족하여 64bit 또는 66Mhz PCI BUS를 사용하도록 설계하고 있습니다. 또한 IDE Controller도 UDMA-133이나 SATA(Serial ATA)의 경우 132MB/sec로는 서비스할 수 없고, SCSI도 마찬가지입니다. 따라서 이제 32bit@33Mhz의 PCI BUS는 한계 에 와 있는 상황에서 64bit@66Mhz의 PCI BUS를 사용하거나 새로운 BUS의 도입 이 필요한 상황입니다. (4) PCI BUS는 processor independent합니다. PCI BUS의 약속에는 CPU에 대한 어떠한 제약도 들어 있지 않습니다. BUS 내부 의 32bit word data를 encoding하는 방법은 little-endian을 사용한다는 것이 약간 x86에 편향되었다고 말할 수 있습니다. 그러나 CPU가 꼭 little-endian이 어야 할 필요는 없고, CPU가 big-endian이면 CPU-to-PCI Bridge(CPU와 PCI 사 이를 연결하는 Bridge로 PC에서는 North Bridge라고 부릅니다. PCI 버스 이야 기(1)에 있는 그림 참조)가 그 사이의 변환에 대한 책임을 지면 됩니다. 또 x86과 관계가 있을 수 있는 것이 I/O access와 Memory access를 구분(즉, I/O mapped I/O를 사용)한다는 점입니다만 역시 다른 processor에서 사용하는데 큰 문제가 되지 않습니다. 이미 x86 이외의 다른 CPU도 PCI 버스를 많이 사용하고 있습니다. 예를 들어 Mac(PowerPC)에서도 PCI를 사용하고 있고, SUN Sparc에서도 PCI를 사용하는 경 우를 본 적이 있습니다. x86 PC용으로 설계된 PCI 확장카드를 하드웨어 수정 없이 그냥 가져다 사용할 수 있으므로, 전용 BUS를 사용하는 것 보다 시스템 구성에 유리하기 때문에 사용하는 것이라 추측됩니다. (5) PCI BUS는 multi-master BUS입니다. 이미 “PCI 버스 이야기(0)”에서 알아본 바와 같이, Read/Write를 요청하는 device를 Master라고 하고, 그 요청을 받는 device가 Slave가 됩니다. Slave 는 Read 요청을 받으면 해당 address에서 data를 읽어서 BUS에 data를 실어 주 어 Master가 읽어 갈 수 있도록 하고, Write 요청을 받으면 Master가 BUS에 실 은 data를 읽어 실제 저장공간(memory 혹은 register)에 저장하게 됩니다. PCI BUS는 Master가 여러 개 존재할 수 있는 BUS입니다. Master와 Slave의 구분은 특정 device에 따라서 구분되는 것이 아니라 하나의 Read/Write 요청의 주체와 객체로 구분이 됩니다. 어떤 Read/Write 요청에서 는 Master였던 device가 다른 Read/Write 요청에서는 Slave로 동작할 수도 있 습니다. PC의 PCI BUS에서 Master로 동작할 수 있는 device가 무엇인지 생각해 봅니 다. 당연히 CPU가 BUS에 물려있는 device에 제어 하기 위해 Read/Write 요청 을 할 수 있어야 합니다. 따라서 CPU는 Master로 동작할 수 있습니다. 하지만 CPU는 직접 PCI BUS에 부착되어 있지 않으므로 정확하게는 CPU-to-PCI Bridge 가 PCI BUS의 Master로 동작할 수 있다고 말하는 것이 올바른 표현입니다. 이 렇게 CPU가 device 제어를 하기 위해 사용하는 read/write 요청에서 CPU-to- PCI Bridge가 Master로 동작하고 해당 device가 Slave로 동작하게 됩니다. Master로 동작할 수 있는 다른 device는 어떤 것이 있을까요? 현재 이 글을 쓰 는데 사용하는 PC의 경우, IDE Controller(South bridge 내부), Sound Card, Ethernet controller 등이 PCI BUS에 붙어있고 Master로 동작할 수 있습니다. 그렇다면 Ethernet controller가 Master인 read/write 요청은 무엇이고, 그 때 slave는 어떤 device일까요? 즉, Ethernet controller는 PCI BUS에 붙어있 는 다른 장치 중에 어떤 장치와 어떤 내용을 이야기하고 싶어할까요? Ethernet controller가 자기 자신의 필요에 따라서 Sound Card에 data를 보내 거나 아니면 Sound Card에서 data를 읽어올 필요가 있을까요? 혹 필요가 있다 면, network을 통해서 날라온 데이터를 직접 Sound Card로 보내 play하는 internet 방송국 application을 효율적으로 구현하기 위해서라는 궁색한 이유 를 생각해 볼 수 있습니다.(궁색하다고 표현한 이유는 network를 통해서 날아 온 데이터 중에 직접 재생 가능한 음악 자료가 몇 퍼센트나 차지하고 있는지 생각해 보면 알 수 있습니다.) 그렇다면 Ethernet controller가 원하는 대화 상대는 누구일까요? 짜잔~ 정답은 CPU-to-PCI Bridge 입니다. CPU-to-PCI Bridge에 직접 달려 있는 경우도 있고 아니면 또 다른 버스에 연결되어 달려 있는 경우도 있지만 PCI BUS 쪽에서 보면 시스템의 main memory는 CPU-to-PCI Bridge에 달려 있는 것으로 보입니다.(PCI 버스 이야기(1)에 있는 그림 참조) Ethernet controller가 원하는 대화 상대는 실제로 main memory이고 그것과 연 결 되어 있는 device가 CPU-to-PCI Bridge 입니다. Ethernet controller는 main memory에서 data를 직접 읽어서(read 요청) ethernet을 통해서 전송하 고, ethernet을 통해서 받은 packet을 main memory에 저장(write 요청)합니 다. 이 read/write 요청의 master는 ethernet controller이고 slave는 CPU-to- PCI Bridge입니다. 일종의 DMA(Direct Memory Access)라고 볼 수 있습니다. 이 렇게 확장 카드가 PCI BUS의 Master로 동작이 가능한 경우 “bus mastering을 지원한다.”라고 말합니다. 현재 출시되고 있는 거의 모든 PCI Ethernet controller와 Sound card는 bus mastering을 지원합니다. 광고문을 잘 찾아보 면 “bus mastering”이라는 말을 찾을 수 있을 겁니다. 당연히 CPU가 직접 data를 옮겨 주지 않으므로 CPU의 연산 능력을 낭비하지 않게 됩니다. (참고) 사실 Ethernet controller가 packet을 받으면 PCI BUS에 붙어 있는 Graphic Card에 있는 Video RAM으로 전송하도록 프로그래밍할 수도 있습니다. 일반적으로 Sound Card에는 RAM과 같은 커다란 버퍼가 없으니 불가능할 지라 도 Graphic Card는 가능합니다. 하지만 그렇게 프로그래밍해서 얻을 수 있는 것은 없습니다. 이렇게 확장 카드 사이의 통신에서 큰 의미를 가지는 경우는 거의 없으나, 한가지 예외를 생각해 볼 수 있습니다. 현재 시중에 나와 있는 PCI TV Card의 경우 TV를 수신한 내용을 bus mastering을 통해서 그래픽 화면 에 overlay를 수행합니다. 이때 TV 수신 내용이 system memory에 저장되었다 가 다시 Graphic Card로 보내 지는지(TV Card의 bus mastering과 Graphic card 의 bus mastering 두 번으로 이루어짐) 아니면 직접 Graphic Card로 보내지도 록 되어 있지는 알 수 없습니다만, Graphic Card로 직접 보내면 훨씬 효율적 일 수 있습니다. Master가 여럿이 있는 BUS는 어떤 device가 Master로서 BUS를 사용하는데 있어 서 어떠한 규칙이 있어야 합니다. BUS라는 하나뿐인 자원을 여러 개의 device 가 동시에 경쟁적으로 점유하려고 하는 경우가 있기 때문입니다. PCI BUS는 상 당히 간단한 arbiter를 이용하여 문제를 해결합니다. 일명 request & grant 방 법인데, 어떤 device가 Master로서 BUS를 이용하고 싶다면 request 신호를 발 생시키고 기다립니다. arbiter는 여러 개의 device에서 들어온 각 request 신 호를 보고 단 하나의 device를 선택하고 그 device에게 grant 신호를 보내줍니 다. Grant 신호를 받는 device는 Master로 BUS를 이용하면 됩니다. 뭐 말이야 그럴싸한 request & grant 방법이지, 사실 초등학교에서 아이들 여럿이 손들 면 선생님이 그걸 보고 한 아이를 지목하는 것과 똑 같은 방법입니다. Master 가 손을 들고(request), arbiter가 지목하고(grant), … (6) PCI BUS는 auto configuration을 지원합니다. Auto configuration이라고 하니 말이 좀 어려운데 보통 하는 말로 “Plug & Play”라고 이해하면 됩니다. PCI BUS의 Plug & Play를 설명 하기 위해서 이 글이 쓰여진 것이므로 당연히 PCI BUS는 Plug & Play를 지원합니다. (7) 기타 기타 나부랭이는 관심 있으면 직접 찾아 보길 바랍니다.(직접 찾아 보았는데 위에 언급된 6가지 보다 더 중요하다고 생각이 드는 것이 있으면 연락 주길 바 랍니다.) ** 이번 글 마무리 이번 글은 가볍게 상식적으로 알아두면 좋은 PCI BUS의 특징에 대해서 살펴보 았습니다. 다음 글에서는 재미는 없지만, 전기신호에 대한 약속을 알아보도록 하겠습니다. 추후의 논의를 위해서 전기 신호 몇 가지는 알아두어야 할 것들 이 있고 몇 가지 timing diagram도 알아두면 좋을 것 같은데, 어디까지 이야기 할 지는 미정입니다. ** 잡설 저번 글을 올리고 나서 개인적인 사정도 있고, 회사 일도 바빠지고 해서 경황 이 없었습니다. 사실 시간이 별로 흐른 것 같지 않은데 벌써 한 달이 넘게 흘 렀더군요. 별로 기대할 만한 내용은 아니지만 그래도 저의 글을 기다렸던 분 이 있었다면 죄송하다는 말씀 드리고 싶습니다. 다음 글도 빨리 올려 드린다 는 말씀은 드리기 어렵습니다. 하지만 노력해서 올리도록 하겠습니다. 글 중에 잘못되었거나 이해가 안 되는 부분이 있으면 꼭 메일 주시기 바랍니 다. 모든 글을 다 적고 나서 잘못된 부분 등을 수정하고 보완해서 다시 올리도 록 하겠습니다. [출처] PCI BUS 이야기 -kelp-|작성자 아이언