728x90
http://control.cntc.ac.kr/cpu/ezboard/ezboard.cgi?db=qa13_arm&action=read&page=12&num=277&dbf=200503170000&depth=0http://control.cntc.ac.kr<출처: 윤교수의 마이크로 프로세서 월드 게시판>
처음 마이크로 프로세서를 대했던 때가 생각납니다.
책으로만 배우며 "bus" 라는 개념조차 확실히 파악하지 못하고 있던 때였는데
interrupt 와 DMA 를 같은 장에서 설명하고 있었습니다. 책의 1/3쯤 되는 곳에
있었는데 이를 이해 못하고 그 다음으로 넘어가기가 꺼려졌습니다.
interrupt 는 어찌 어찌 이해했으나 DMA 는 결국 확실히 이해하지 못하고 넘어
가야 했습니다. Z80 이나 6800 등의 소자도 DMA 를 가능하게 하기 위해 필요한
준비를 하고 있었으나, 실제로 사용할 기회는 거의 없었습니다. 8088 에 붙였던
적이 있었던 듯한데 기억이 확실하지 않습니다.
PC 에서는 disk access 등 고속의 연속적인 data 전송이 필요하므로 DMA가
필수이지만 embedded system 에서는 별로 사용할 기회가 없는 것 같습니다.
ethernet 등을 사용한다면 있는게 좋겠지요.
이번에 video data 를 system memory 로 읽어 들여야 했으므로 DMA 사용이
필수적이었습니다.
decoding 된 영상신호는 일초당 27MByte 를 연속으로 읽어 들여야 합니다.
S3C2440 에는 이 기능이 내장되어 있으나 사정상 S3C2410 을 사용했습니다.
DMA 는 I/O 와 memory 간에 고속이며 연속적인 data 이동을 효율적으로
해주는 h/w 수단입니다. s/w 의 부담이 많이 줄어 들지요.
DMA controller (DMAC) 라는 것이 이런 일을 해줍니다.
과거에는 controller 를 별도로 외부에 달아 주었으나 지금은 주로 내장한 것을
사용하는 것 같습니다.
초기의 DMA 는 이렇게 동작했습니다.
1. CPU 가 DMAC 를, 어떤 사건이 생기면, 어느 번지로 부터, 어느 번지로,
몇 회의 전송을 할 것인지를 설정합니다.
2. DMAC 는 해당 사건이 생기면 CPU 에 bus 사용권을 요구(request)합니다.
CPU 는 bus 동작을 멈추고 address 및 data bus 를 float 시켜 준 후
그 사실을 DMAC 에게 알려 줍니다 (acknowledge).
3. DMAC 는 스스로 bus 를 장악하고 data 를 "직접(direct)" 전송합니다.
I/O 에서 읽어 memory 에 써 넣는 경우라면, I/O 에는 read 신호를, memory
에는 address 및 write 신호를 공급하여 한방에 data 를 전송하는 겁니다.
4. bus 사용을 끝낸 DMAC 는 bus 를 float 시킨 후 request 를 중단합니다.
CPU 는 acknowledge 를 중단하고 원상으로 돌아갑니다.
5. 이러한 절차를 미리 설정된 횟수만큼 수행하고 나면 DMAC 는 CPU 에
별도로 준비된 interrupt request 를 행하여 끝난 사실을 알려 줍니다.
interrupt 에서는 수행하던 명령을 완료한 후에 service 에 들어 가지만 DMA는
명령과 관계없이 수행하던 bus cycle 이 완료되면 바로 acknowledge 된다는
점이 다릅니다.
위의 3 번항이 의미하는 것은 h/w 가 특별히 설계되어야 한다는 뜻이어서
상당히 번거롭습니다. 한 쪽에는 read 신호를, 다른 쪽에는 write 신호를 공급
해야하기 때문이죠. 물론 chip select 도 양측에 동시에 공급해야 합니다.
이를 해결하기 위하여 다소 효율이 떨어지는 방법이 사용되기 시작했습니다.
"direct"가 아니고 2 cycle 로 해결하는 겁니다. DMAC 가 한쪽에서 읽은 다음,
다른 쪽에 쓰는 겁니다.
이렇게 하면 h/w 를 특별히 설계하지 않아도 그대로 적용할 수 있습니다.
또한 좀 더 다양한 형태의 전송이 가능하게 되기도 합니다.
memory-to-memory 의 전송도 DMA 로 가능해졌습니다. 프로그램으로
loop 돌아가며 하나씩 옮기는 것보다 훨씬 빠릅니다.
I/O-to-I/O 도 물론 가능합니다. 또, 32bit bus 에서 한번에 읽은 data 를
8 bit 의 주변장치에 4 회에 걸쳐 나누어 전송할 수도 있게 됩니다.
매 전송마다 읽거나 쓰는 주소를 일정하게, 또는 증가, 또는 감소하도록 할 수
도 있습니다.
이번 266MHz (1:2:4)로 수행되는 S3C2410A 의 경우, nDREQ 에는
RS-flipflop (RSFF)을 사용했습니다.
사건(video clock)이 발생하면 RSFF 를 clear 하여 request 를 합니다.
nDACK 는 약 25nS 후에 low 로 되었고, 75nS~400nS 후에 nRD (DMA read)
신호가 나옵니다.
일정하지 않은 이유는 함께 작동하고 있는 LCD controller 의 DMA 와 충돌이
있기 때문일 겁니다.
nRD 신호로 RSFF 을 set 시켜 request 를 끝냈습니다. nDACK 는 사용하지
않았습니다.
LCD controller 가 enable 된 상태로, 8bit data 를 4 개 모아 32bit 로 만들 때
마다 1 회씩 DMA 를 행하는 것으로는 속도가 많이 모자랐습니다.
32bit data 4 개를 모아 일거에 DMA 처리하는 방법 (burst)을 사용하니 속도
문제가 해결되었습니다.
4 회의 burst read 후 SDRAM 에 4 회에 걸쳐 write 를 하는데, SDRAM 의
burst write 기능을 사용하지 않고 그냥 4회를 각각 쓰는 것으로 보였습니다.
write 가 끝나면 nDACK 가 high로 되어 DMA cycle 하나가 끝납니다.
DMAC 가 CPU 에 내장되어 있는 관계로 bus 관리가 용이하기 때문인지
nDACK 가 assert 되어 있는 동안에도 program 이 행하는 read/write cycle
이 중간에 끼어 드는 것이 관측되었습니다. 즉, bus 를 완전히 DMAC 에 내
주는 것은 아닌 것 같습니다.
아마 refresh cycle 도 중간에 끼어 들 수 있을 겁니다.
처음 마이크로 프로세서를 대했던 때가 생각납니다.
책으로만 배우며 "bus" 라는 개념조차 확실히 파악하지 못하고 있던 때였는데
interrupt 와 DMA 를 같은 장에서 설명하고 있었습니다. 책의 1/3쯤 되는 곳에
있었는데 이를 이해 못하고 그 다음으로 넘어가기가 꺼려졌습니다.
interrupt 는 어찌 어찌 이해했으나 DMA 는 결국 확실히 이해하지 못하고 넘어
가야 했습니다. Z80 이나 6800 등의 소자도 DMA 를 가능하게 하기 위해 필요한
준비를 하고 있었으나, 실제로 사용할 기회는 거의 없었습니다. 8088 에 붙였던
적이 있었던 듯한데 기억이 확실하지 않습니다.
PC 에서는 disk access 등 고속의 연속적인 data 전송이 필요하므로 DMA가
필수이지만 embedded system 에서는 별로 사용할 기회가 없는 것 같습니다.
ethernet 등을 사용한다면 있는게 좋겠지요.
이번에 video data 를 system memory 로 읽어 들여야 했으므로 DMA 사용이
필수적이었습니다.
decoding 된 영상신호는 일초당 27MByte 를 연속으로 읽어 들여야 합니다.
S3C2440 에는 이 기능이 내장되어 있으나 사정상 S3C2410 을 사용했습니다.
DMA 는 I/O 와 memory 간에 고속이며 연속적인 data 이동을 효율적으로
해주는 h/w 수단입니다. s/w 의 부담이 많이 줄어 들지요.
DMA controller (DMAC) 라는 것이 이런 일을 해줍니다.
과거에는 controller 를 별도로 외부에 달아 주었으나 지금은 주로 내장한 것을
사용하는 것 같습니다.
초기의 DMA 는 이렇게 동작했습니다.
1. CPU 가 DMAC 를, 어떤 사건이 생기면, 어느 번지로 부터, 어느 번지로,
몇 회의 전송을 할 것인지를 설정합니다.
2. DMAC 는 해당 사건이 생기면 CPU 에 bus 사용권을 요구(request)합니다.
CPU 는 bus 동작을 멈추고 address 및 data bus 를 float 시켜 준 후
그 사실을 DMAC 에게 알려 줍니다 (acknowledge).
3. DMAC 는 스스로 bus 를 장악하고 data 를 "직접(direct)" 전송합니다.
I/O 에서 읽어 memory 에 써 넣는 경우라면, I/O 에는 read 신호를, memory
에는 address 및 write 신호를 공급하여 한방에 data 를 전송하는 겁니다.
4. bus 사용을 끝낸 DMAC 는 bus 를 float 시킨 후 request 를 중단합니다.
CPU 는 acknowledge 를 중단하고 원상으로 돌아갑니다.
5. 이러한 절차를 미리 설정된 횟수만큼 수행하고 나면 DMAC 는 CPU 에
별도로 준비된 interrupt request 를 행하여 끝난 사실을 알려 줍니다.
interrupt 에서는 수행하던 명령을 완료한 후에 service 에 들어 가지만 DMA는
명령과 관계없이 수행하던 bus cycle 이 완료되면 바로 acknowledge 된다는
점이 다릅니다.
위의 3 번항이 의미하는 것은 h/w 가 특별히 설계되어야 한다는 뜻이어서
상당히 번거롭습니다. 한 쪽에는 read 신호를, 다른 쪽에는 write 신호를 공급
해야하기 때문이죠. 물론 chip select 도 양측에 동시에 공급해야 합니다.
이를 해결하기 위하여 다소 효율이 떨어지는 방법이 사용되기 시작했습니다.
"direct"가 아니고 2 cycle 로 해결하는 겁니다. DMAC 가 한쪽에서 읽은 다음,
다른 쪽에 쓰는 겁니다.
이렇게 하면 h/w 를 특별히 설계하지 않아도 그대로 적용할 수 있습니다.
또한 좀 더 다양한 형태의 전송이 가능하게 되기도 합니다.
memory-to-memory 의 전송도 DMA 로 가능해졌습니다. 프로그램으로
loop 돌아가며 하나씩 옮기는 것보다 훨씬 빠릅니다.
I/O-to-I/O 도 물론 가능합니다. 또, 32bit bus 에서 한번에 읽은 data 를
8 bit 의 주변장치에 4 회에 걸쳐 나누어 전송할 수도 있게 됩니다.
매 전송마다 읽거나 쓰는 주소를 일정하게, 또는 증가, 또는 감소하도록 할 수
도 있습니다.
이번 266MHz (1:2:4)로 수행되는 S3C2410A 의 경우, nDREQ 에는
RS-flipflop (RSFF)을 사용했습니다.
사건(video clock)이 발생하면 RSFF 를 clear 하여 request 를 합니다.
nDACK 는 약 25nS 후에 low 로 되었고, 75nS~400nS 후에 nRD (DMA read)
신호가 나옵니다.
일정하지 않은 이유는 함께 작동하고 있는 LCD controller 의 DMA 와 충돌이
있기 때문일 겁니다.
nRD 신호로 RSFF 을 set 시켜 request 를 끝냈습니다. nDACK 는 사용하지
않았습니다.
LCD controller 가 enable 된 상태로, 8bit data 를 4 개 모아 32bit 로 만들 때
마다 1 회씩 DMA 를 행하는 것으로는 속도가 많이 모자랐습니다.
32bit data 4 개를 모아 일거에 DMA 처리하는 방법 (burst)을 사용하니 속도
문제가 해결되었습니다.
4 회의 burst read 후 SDRAM 에 4 회에 걸쳐 write 를 하는데, SDRAM 의
burst write 기능을 사용하지 않고 그냥 4회를 각각 쓰는 것으로 보였습니다.
write 가 끝나면 nDACK 가 high로 되어 DMA cycle 하나가 끝납니다.
DMAC 가 CPU 에 내장되어 있는 관계로 bus 관리가 용이하기 때문인지
nDACK 가 assert 되어 있는 동안에도 program 이 행하는 read/write cycle
이 중간에 끼어 드는 것이 관측되었습니다. 즉, bus 를 완전히 DMAC 에 내
주는 것은 아닌 것 같습니다.
아마 refresh cycle 도 중간에 끼어 들 수 있을 겁니다.
728x90
