---
title: "셀 이름이 같아도 다른 회로를 가리키는 설계 데이터"
author: "브레이브브라우저쓰자"
published_at: "2026-10-25T05:56:02.708Z"
updated_at: "2026-10-06T02:16:27.844Z"
tags: ["opendb 일관성"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EC%85%80-%EC%9D%B4%EB%A6%84%EC%9D%B4-%EA%B0%99%EC%95%84%EB%8F%84-%EB%8B%A4%EB%A5%B8-%ED%9A%8C%EB%A1%9C%EB%A5%BC-%EA%B0%80%EB%A6%AC%ED%82%A4%EB%8A%94-%EC%84%A4%EA%B3%84-%EB%8D%B0%EC%9D%B4%ED%84%B0"
ai_assisted: true
---

# 셀 이름이 같아도 다른 회로를 가리키는 설계 데이터

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%EC%85%80-%EC%9D%B4%EB%A6%84%EC%9D%B4-%EA%B0%99%EC%95%84%EB%8F%84-%EB%8B%A4%EB%A5%B8-%ED%9A%8C%EB%A1%9C%EB%A5%BC-%EA%B0%80%EB%A6%AC%ED%82%A4%EB%8A%94-%EC%84%A4%EA%B3%84-%EB%8D%B0%EC%9D%B4%ED%84%B0)

배치 도구에는 새 버퍼가 있고 타이밍 보고서에도 이름이 나온다. 그런데 내보낸 배선 데이터에서는 기존 드라이버가 목적지에 직접 연결되어 있다면, 어느 결과를 믿어야 할까? OpenDB 일관성의 핵심은 여러 단계가 같은 셀·핀·연결과 물리 상태를 가리키도록 유지하는 데 있다. 데이터베이스를 하나 사용한다는 사실만으로 모든 결과가 자동으로 최신이 되지는 않는다.

## 셀 이름보다 객체 사이의 관계가 중요하다

OpenDB는 물리 설계용 데이터베이스다. 라이브러리의 셀 정의를 나타내는 master, 실제 배치된 instance, 핀과 net, 배선 등의 객체를 저장한다. 이름은 객체를 찾는 단서지만 회로의 의미는 어떤 핀이 어느 net에 연결되어 있는지에 담겨 있다. 같은 이름 목록을 가졌어도 연결 관계가 다르면 다른 설계다.

공식 문서는 LEF·DEF의 구조를 기반으로 하는 모델과 바이너리 저장·복원을 설명한다. 배선은 net에 속한 `dbWire`로 저장하고 encoder·decoder를 사용해 형상을 다룬다. 셀 위치나 연결 정보와 배선 형상은 서로 연관되지만 같은 필드가 아니다. [OpenDB의 데이터 모델 설명](https://openroad.readthedocs.io/en/latest/main/src/odb/README.html)

## 버퍼 객체만 만들면 회로가 바뀌지 않는다

원래 net N이 드라이버 `A/Z`와 부하 `B/A`, `C/A`를 연결한다고 하자. C 앞에 BUF를 넣으려면 목표 연결은 다음과 같다.

```text
N  = {A/Z, B/A, BUF/A}
N2 = {BUF/Z, C/A}
```

데이터베이스에 BUF instance와 N2 이름만 추가한 뒤 C/A가 계속 N에 연결되어 있다면 목표 회로가 아니다. 반대로 C/A를 N에서 떼어 놓고 N2에 붙이지 않았다면 떠 있는 핀이 된다. 완성된 변경은 객체의 존재뿐 아니라 핀의 소속 net까지 포함한다.

OpenDB의 실제 `dbITerm` API는 핀을 net에 연결하거나 기존 연결을 끊는 동작을 제공한다. 실제 계층 구조를 사용하는 설계에서는 flat net과 계층의 연결 관계를 일관되게 다루는 상위 API도 고려해야 한다. 이 글의 작은 예제는 평탄한 연결 집합이다. [db.h의 dbITerm 연결 API](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/odb/include/odb/db.h)

검토할 때는 변경 전후 instance·master·핀·net의 관계를 묶어 비교하면 좋다. 예제의 기대 상태와 각 핀의 실제 소속을 비교하면 BUF/A와 BUF/Z가 잘못 같은 net에 붙거나, C/A가 이전 net에 남는 오류를 찾을 수 있다. 단순히 instance 수가 하나 늘고 net 수가 하나 늘었다는 검사로는 이런 관계 오류가 드러나지 않는다.

## 좌표 숫자가 같아도 물리 길이는 다를 수 있다

Import와 export에서는 단위도 관계의 일부다. DEF의 좌표는 DBU라는 정수 단위를 사용하며 micron당 DBU 수를 명시한다. 예를 들어 1μm에 2000DBU를 쓰는 데이터에서 40DBU는 0.02μm, 즉 20nm다. 1000DBU를 쓰는 데이터에서는 같은 정수 40이 40nm다.

두 파일의 정수 좌표만 같다고 같은 길이를 보존했다고 판단하면 두 배의 오차가 생길 수 있다. OpenROAD의 Database Math 설명은 1000 또는 2000DBU/μm와 정수 좌표의 의미를 다루고, OpenDB block API에는 micron당 DBU 수와 길이 변환 함수가 있다. 따라서 실제 저장 단위를 조회해 변환해야 한다. [Database Math의 단위 설명](https://openroad.readthedocs.io/en/latest/contrib/DatabaseMath.html), [OpenDB block의 단위 API](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/odb/include/odb/db.h)

방향과 원점도 함께 비교한다. Instance가 반전되면 master 안의 핀 위치를 그대로 전체 좌표에 더해서는 안 된다. 이름·소속 net이 맞아도 핀의 실제 물리 위치가 어긋나면 router가 연결해야 할 지점이 달라진다. 각 단계에서 사용할 좌표계와 단위 변환의 계약을 정해야 한다.

## 저장된 상태와 도구의 계산 결과를 구분한다

OpenDB는 저장·복원 뒤에도 객체 식별자를 보존한다고 설명한다. 복원 이전의 메모리 포인터를 새 세션에서 그대로 사용하는 대신 보존된 객체 식별자를 활용하라는 지침이다. 그렇다고 객체 번호 하나를 서로 무관한 모든 데이터베이스의 전역 식별자로 해석할 수는 없다. 해당 저장 상태와 객체 종류·소유 관계 안에서 사용해야 한다. [OpenDB의 객체 식별자 설명](https://openroad.readthedocs.io/en/latest/main/src/odb/README.html#c)

더 중요한 한계도 있다. Router와 extractor 등은 작업에 맞춘 별도의 내부 자료구조를 만들 수 있다. 데이터베이스의 핀 위치를 바꿨다고 이전 routing graph나 추출 기생 성분이 모두 자동 갱신되었다고 가정하면 안 된다. 도구가 지원하는 변경 알림과 갱신 절차를 따라 오래된 결과를 다시 만들거나 무효화해야 한다.

또한 물리 데이터베이스가 회로의 논리 동등성이나 타이밍 만족을 증명하지는 않는다. OpenDB 문서 자체도 논리 함수 표현과 고수준 합성 정보에 한계가 있다고 설명한다. 원하는 핀 집합이 저장되었다는 검증과 그 회로가 의도한 기능을 수행한다는 검증은 목적이 다르다.

OpenDB 일관성을 지킨다는 것은 하나의 파일에 모든 정보를 모았다는 뜻보다 구체적이다. 객체 관계, 물리 좌표와 단위, 파생된 배선·기생 성분·분석 결과가 같은 변경 상태를 가리키게 하는 것이다. 이 기준으로 단계의 입력과 출력을 비교하면, 이름은 맞지만 서로 다른 회로를 분석하던 문제를 찾아낼 수 있다.