support history

왜 눈물을 흘리시나요? 캐시코히어런스

xilinx 2022. 1. 8. 23:50

어느날 전화를 받았습니다. Zynq의 PL (Programmable Logic) AXI Master를 설계해서 데이터를 DDR 메모리에 썼는데, 프로세서로 읽어보면 안읽힌다고.
얘기를 들어보니, ASIC 개발용으로 FPGA에 몇가지 로직을 설계하고 있었고, 그중 설계된 마스터가 제대로 동작하는지 알아보기 검증하던 도중, 쓴 데이터가 제대로 안읽히는 것이죠.
한 이틀 정동 고생하고 나서도 해결이 안되, 저에게 전화를 한 것입니다.

가만들어보니 DDR 메모리에 쓰는 것은 고객이 만든 마스터이고 , 읽는 것은 Zynq의 A9 프로세서로 읽는 것이니 두개의 마스터가 각각 읽고, 쓰는 상황이더군요.

하여간 만나서 상황을 보니, customer master가 메모리에 데이터를 쓰고, uboot가 A9에서 해당 메모리 값을 읽어보고 있었습니다.

당근 제대로 값이 안읽히겠죠.

아마 uboot는 특정 메모리를 억세스 한다고 했지만, 실제 억세스하는 공간은 캐시 메모리이고, DDR 메모리에 실제로 억세스하고 있지 않는 상황이죠.

uboot에서는 캐시를 invalidate 하는 명령이 있어, 실행하고 읽어보니, 제대로 된 값을 읽었습니다.

이때 저의 이 희한한 명령 하나에 원하던 동작이 되는 것을 확인한 고객은 눈물을 흘리더군요.

맘 고생이 심했지만, 이렇게 간단히 해결되다니^^

이 문제가 바로 캐시 코히어런스 입니다.

현재 캐시에 있는 내용을 버리고, 새롭게 DDR에서 데이터를 읽어서 캐시를 채우고 읽도록 하는 명령어가 cache invalidation 입니다.

반대로 çache에 있는 내용을 DDR에 실제 가져다 놓는 명령이 있는 그것이 바로 cache flush입니다.

만약 프로세서가 쓰고, 커스텀 마스터가 DDR 에서 읽는다면 어떻게 되었을까요?

개쓰레기 값이 읽히겠죠

왜냐면 프로세서는 캐시에다 데이터를 쓰고, 실제 DDR 메모리에는 안가져다 놓습니다. 사실 프로세서는 자기가 캐시에 썼는지, DDR에 썼는지 모르죠.

이경우엔 프로세서가 쓰고, cache flush 하고 커스텀 마스터가 DDR에서 데이터를 읽으면 되겠죠.

하여간 캐시 코히어런스는 당해봐야 그 매운 맛을 안답니다.