[Calibre] Sliced DRC - 브레인스토밍

주로 IP 단위의 layout을 담당하고 있기 때문에 cadence 社의 innovus나 synopsys 社의 icc 툴에 대해선 거의 모른다. 하지만 최종 단계인 chip top level에서의 검증을 도와주는 경우가 많은데 어떤 수정이 있은 뒤 DRC 검증을 위해 몇 시간을 기다려달라는 얘기를 많이 듣게 된다.

최종 검증 때 혹은 그 이외의 상황에서도 정식 방법으로는 전체 검증을 다시 해야 하는 게 맞고, 그 절차는 바뀌면 안 된다.(골든 룰!) 하지만 DRC를 하나하나 해결해나가는 상황, 또 매우 적은 에러가 있으며 어떤 방식으로 그 에러가 해결되는지 시도해 봐야 하는 상황에서도 몇 시간씩 걸려서 결과를 보는 것은 비효율적이라 생각한다.

기존에도 이런 runtime 이슈로 몇 가지 시도를 해왔고, 다른 분들도 사용하고 있다.
   1. rule 파일의 #define, 혹은 파일 자체를 여러 그룹 군으로 나누어 검증하는 방법
   2. 비슷해 보이지만 DRC select check 와 같은 특정 rule만을 확인하는 방법
   3. DB의 이미 검증된 IP 혹은 standard cell을 제거하고 확인하는 방법

사용하고 있는 방법이란 것은 큰 문제 없다는 뜻이지만 그럼에도 runtime이 많이 줄지 않는 이유는 무엇일까? 이런저런 생각 중에 둘째가 레고 하는 것을 보고 문득 이런 생각을 해봤다. 끄적끄적

Sliced DRC (가칭)
- DB를 정해진 크기로 조각조각 잘라내어 각 영역별로 검증을 한다면? (lsf 이용 빠르게 구역별 확인)
- 영역별로 에러의 유무 혹은 개수를 count 하여 저장하고, 다음 확인 때는 에러가 있는 곳만 검증을 한다면? (일부 영역 skip)
- 구역별로 여러 인원이 나누어 수정한다면? (이 과정을 툴이 지원하는지는 모르겠다.)


물론 구역별로 검증하는 것의 문제점도 보인다. 하지만 runtime 관련된 큰 장점이 확인된다면 일부 상황, 혹은 과정 중에 적용해 볼 만하지 않을까?

나는 어떤 IP든 칩이든 성공적으로 만들어 낼 자신이 있고, 그 결과물의 성능적인 면이든 과정에서든 개선점을 찾아내고 전체적인 성공을 위해 노력하지만! 아쉽게도 아직 관리자는 아니다. 내가 이런 새로운 방식을 개발하더라도 적용 가능 여부는 알 수 없고, 강제할 수도 없다.

하지만 내가 관리자라면 현재 상황이 어때?라는 질문에 DRC 4000개 정도 남았어요.라는 대답보다는 엑셀 표에 각 구역별로 나뉘어 어떤 부분은 에러가 없고 (초록색) 어느 부분에서 에러가 집중돼 있고 (빨간색), 각 구역별로 전일 대비 어떤 변화가 있는지 한눈에 알아볼 수 있는 자료를 기대할 것 같다.