예제 실습: "Verilog RTL에서 GDS 레이아웃 까지"[4/4]
Project_6502 예제의 합성 후 Co-Simulation 실시 방법
SystemC/C++로 작성된 높은 시스템 수준의 검증 환경(테스트 벤치)을 구축하여 합성 가능한 6502 CPU의 RTL Verilog 설계를 검증했다.
이 검증 환경은 RTL 설계물이 합성을 통해 더 낮은 수준으로 전환된 후 추출된 네트 리스트 Verilog의 검증에 동일하게 적용 한다. 추상화 수준의 전이 과정에서 발생할 어떤 오류, 설계도구의 오류는 물론 인간 간여 오류에도 충분히 대처하기 위함이다. 특히 합성부터 후반부 작업단계에서 오픈 소스 도구의 사용 이라는 불안을 덜어낼 수 있다는 점에서 그 필요성과 중요성이 있다.
목차
2. 윈도우즈와 리눅스 파일 시스템 교차 접근 방법
3. 합성 후 표준 셀 네트 리스트 파일 생성
3-1. RTL Verilog 파일의 심볼릭 링크
3-2. 합성에서 레이아웃 까지 자동화
3-3. 후 검증
3-4. 클럭 버퍼 처리
-----------------------------------------------------------------------------------------
1. 원 설계물의 항상성 유지
검증을 마친 RTL의 설계물을 전자회로로 전환되는 과정은 합성, 자동배치, 자동배선 등 자동화 변환 도구(design automation tools)에 전적으로 의존하게 된다. 이에 자동화 도구의 신뢰성이 매우 중요하다. 더블어 자동화 도구를 사용하면서 최적화를 위해 또는 도구의 사용조건에 따라 원 설계물에 수정이 가해질 수 있다. 아주 작은 수정이더라도 간과해서는 않되며 끊임없이 검증 되어야 한다. 이에 지켜야 할 기준으로 테스트 환경의 변경은 허용되지 않아야 함은 물론이며 원 설계물이 임의로 복사 편집되지 않도록 관리 되어야 한다.
설계과정에서 생산성 높은 도구의 사용은 설계시간의 단축 뿐만 아니라 재귀적 반복으로 인한 작업자의 피로도 상승에 따른 오류 개입을 피할 매우 중요한 요소다. 윈도우즈의 문서 편집기는 리눅스의 그것보다 매우 직관적며 편이성 또한 높다. SystemC와 C++ 언어를 이용한 테스트 벤치의 제작도구로 사용할 Visual Studio의 생산성(특히 소프트웨어 디버깅)이 매우 높다.
우리가 정립할 설계과정(design flow)에서 C++ 컴파일러 Visual Studio와 HDL 시뮬레이터 QuestaSim은 윈도우즈 체제에서 운용되며 합성 및 배치배선 도구들은 리눅스 체제에서 운용된다. 서로 다른 운영체제의 설계 파일들을 상호 교차접근하기 위해서 파일 시스템이 고려되어야 한다. 다행히 WSL(Windows Subsystem for Linux)는 윈도우즈와 리눅스사이의 응용 소프트웨어 수준에서 자유로운 파일 탐색을 허용한다. 파일경로 분리자(delimiter)의 상이함을 제외하면 실볼릭 링크(symbolic link)와 바로가기(short-cut)를 통해 두 운영체제의 파일 시스템 사이에 상호 교차접근이 가능하다.
2. 윈도우즈와 리눅스 파일 시스템 교차 접근 방법
윈도우즈와 리눅스의 파일 체계는 호환성이 없다. 하지만 WSL을 통해 설치된 리눅스와 윈도우즈 사이에 파일의 상호 접근이 허용된다. 윈도우즈는 WSL의 리눅스 디스크를 네트워크 소켓으로 접근 할 수 있다. 파일 경로는 아래와 같다.
\\wsl.localhost\Ubuntu-20.04
윈도우즈 응용 프로그램 수준에서 리눅스 파일 접근이 가능하여 윈도우즈 파일 탐색기(Explorer)로 접근 할 수 있다.
따라서 윈도우즈의 바로가기(short-cut)로 리눅스 파일을 지정 열람이 가능하다.
리눅스 파일 시스템에도 윈도우즈의 '바로가기'에 해당하는 리눅스의 기능이 있다. 심볼릭 링크(symbolic link)다. 심볼릭 링크를 만드는 명령은 아래와 같다.
$ ln -s <source file path/name> <target file name>
WSL으로 설치된 리눅스에서 윈도우즈의 파일을 심볼릭 링크 할 수 있다. 예를 들어 다음과 같다. 윈도우즈 파일을,
D:\home\Project_6502\Apple2_Co-Sim\Arlet_Verilog-6502_1_Async\ALU.v
리눅스 로컬 폴더의 ALU.v 로 심볼릭 링크 하면 아래와 같다.
리눅스의 입장에서 윈도우즈의 하드디스크는 /mnt 에 장착(mount)되어 있다. 운영체제는 모든 자원(디스크와 파일 뿐만 아니라 입출력 장치들 모두)을 파일의 개념으로 관리한다는 점도 기억해 두자. 위의 예는 윈도우즈 하드디스크 D: 가 /mnt/d 에 장착 되어 있다는 뜻이다.
윈도우즈와 리눅스의 가장 큰 외형상 차이는 경로명 분리자(delimiter)다. 리눅스는 슬러쉬 '/', 윈도우즈는 백-슬러쉬 '\' 다. 상호 교차 링크를 걸 때 이 차이가 귀찮다. 한때 이 문제를 고치려 했으나 윈도우즈가 예전 DOS 시절부터 사용하던 커맨드 라인에 대한 호환성을 유지해야 하므로 어쩔수 없다고 하니 참고 써야한다.
3. 합성 후 표준 셀 네트 리스트 파일 생성
Yosys는 오픈 소스 Verilog 합성(synthesis) 도구다. 이 합성기를 거쳐 생성된 표준 셀(standard cell) 네트리스트를 Verilog로 추출하여 앞서 RTL 검증에 사용했던 테스트 환경에 적용하여 합성기의 기능을 확인하자. 이 과정을 네트 시뮬레이션 혹은 합성 후 시뮬레이션(Post-Synthesis)이라고 한다. 표준 셀의 모델은 목표 반도체 공정에서 제공하는 PDK에 포함되어 있다. 합성 후 네트리스트의 시뮬레이션에 RTL 검증에 사용했던 것과 동일한 테스트 환경을 적용함으로써 오픈 소스 합성기의 신뢰성을 담보할 수 있을 것이다. 합성 후 표준 셀 네트리스트 생성 절차는 아래와 같다.
3-1. RTL Verilog 파일의 심볼릭 링크
합성을 위한 준비는 리눅스 작업 폴더에 RTL Verilog 파일을 심볼릭 링크 시킨다. 합성할 파일들을 넣어둘 source 폴더 를 만든다.
$ ln -s /mnt/d/Verilog-6502_1_Async/ALU.v ALU.v
$ ln -s /mnt/d/Verilog-6502_1_Async/cpu.v cpu.v
3-2. 합성에서 레이아웃 까지 자동화
오픈 소스 툴 qflow 에서 합성을 실시한다. 공정을 osu050 (0.5u 2Poly/3Metal)으로 놓았다. 리눅스의 합성도구는 심볼릭 링크한 윈도우즈 파일을 중단 없이 읽어 들인다.
배선을 원할히 하기 위해 다소 느슨한 density=0.3 로 놓고 배치를 실시한다.
배선이 완료되면 이어서 DRC, LVS, GDS 생성까지 진행 시킨다.
최종적으로 표준 셀까지 모두 합쳐진 레이아웃을 얻는다.
3-3. 후 검증
합성에서 레이아웃을 얻을 때까지 과정은 자동화 툴의 몫이다. 최적의 결과를 얻기 위한 옵션 조정 외 설계자가 간여할 여지는 없다. 설계 자동화 도구도 응용 소프트웨어인 만큼 무조건 신뢰하기 전에 그 결과물을 검증할 필요가 있다. 아울러 설계의 최종 결과물은 전자회로라는 점을 감안 하여 논리적 기능 뿐만 아니라 물리적 특성도 검토되어야 한다. 회로의 시간지연으로 인한 글리치 발생과 클럭과의 셋업 오류는 매우 중요하게 다뤄져야 한다.
자동화 단계를 거칠 때 마다 작업 결과를 검증하기 위한 목적의 네트리스트를 Verilog 파일로 생성한다. 이를 RTL 설계 검증의 테스트 벤치에 동일하게 적용하여 오픈 소스 자동화 툴의 신뢰도를 확인 해 보기로 한다. 합성과 배치배선이 완료되면 synthesis 폴더에 다수의 베릴로그 파일이 존재한다. 그중 합성과 최적화에서 얻어진 cpu.v 와 배선 후 얻은 cpu_postroute.v 를 가지고 시뮬레이션을 실시한다.
합성과 자동 배치배선의 결과로 얻어진 Verilog 파일은 읽기가 가능한 보통의 문서다. 표준 셀라이브러리들을 하위 모듈로 둔 계층화된 구조적 모델이다. 표준 셀 하위 모듈을 부품으로 두고 상호 연결만으로 표현되어 있다. 이를 HDL 시뮬레이션 하려면 하위 모듈들의 행동을 표현한 Verilog가 제공되어야 하는데 공정의 PDK에 포함되어 있다. 위에서 사용한 자동화 도구 qflow의 공정별 PDK를 모아둔 곳은 /usr/local/share/qflow/tech/ 다. 예제의 합성에 사용한 공정은 osu050이다. 합성 후 검증에 필요한 Verilog 파일은 아래와 같다.
검증은 RTL C-Simulation의 테스트 벤치를 그대로 사용한다.
QuestaSim의 do 스크립트에서 Verilog 부분만 수정하면 아래와 같다.
# MTI simulation scrips for
# Arlet's Verilog-6502
# Vendor: GoodKook
# Associated Filename: compile_syn.do
# Purpose: SystemC testbench
# Revision History: 23 Jul 2023
#*************************************************
onbreak {resume}
# create library
if [file exists work] {
vdel -all
}
vlib work
vlog -reportprogress 300 -work work \
#sccom -reportprogress -g -work work ../sc_mem.cpp \
sccom -reportprogress -g -work work ../sc_mem.cpp \
sccom -reportprogress -g -work work ../sc_CPU6502.cpp \
sccom -reportprogress -g -work work ../Apple2.cpp \
sccom -link -lcomdlg32
------------------------------------------------------------------------------
합성후 생성된 cpu.v 에 수정 사항이 있다.
output [15:0] AB,
input [7:0] DI,
output [7:0] DO,
input IRQ,
input NMI,
input RDY,
output WE,
input clk,
input reset
);
시뮬레이션 스크립트는 RTL 때와 다를바 없다.
# MTI compile scrips
# Vendor: GoodKook
# Associated Filename: simulate.do
# Purpose: SystemC testbench
# Revision History: 24 Jul 2023
#***********************************************
vsim -voptargs=+acc work.sc_main -t ps
단, 시간 해상도 지정이 피코 초(-t ps, pico-second)다. 표준 셀 라이브러리의 Verilog 모델에 지간 지연을 포함하고 있다. 보통 RTL 시뮬레이션의 시간 해상도는 나노 초(ns, nano-secod)이나 물리적 특성을 다루는 후반부 시뮬레이션에서는 게이트 통과 지연을 반영한 글리치(glitch)를 표현 하므로 해상도는 이보다 세밀한 피코-초(ps, pico-second)다.
디지털 회로의 물리적인 시간지연을 감안 하지 않고 논리적 행동만을 다룰때 펑셔널 시뮬레이션(functional simulation) 또는 전단 시뮬레이션(Pre-Simulation)이라 한다. 합성 이후 실제 공정의 물리적 정보를 포함하기 시작한 후반 시뮬레이션을 타이밍 시뮬레이션(Timing Simulation), 또는 포스트 시뮬레이션(Post-Simulation)이라 한다.
3-4. 클럭 버퍼 처리
6502 CPU를 검증하기 위한 입출력 장치 구동 소프트웨어 "Apple2_Screen"을 먼저 실행 시킨다. 이어 Verilog 타이밍 시뮬레이션을 진행하자.
run 30 us
안타깝게도 오류를 일으킨다.
원인은 셋업(set-up)과 홀드(hold) 바이얼레이션(violation)이다. 틀어진 클럭(clock skew)으로 인해 디지털 회로 플립-플롭이 오동작 했음을 의미한다. QuestaSim의 데이터 플로우(data-flow) 기능은 오류가 처음 시작된 위치를 추적하는데 도움을 준다.
클럭 신호는 칩 전체에 분포한 플립-플롭 회로들을 작동시킨다. 매우 강력한 구동 능력을 가져야 하므로 특별히 취급 되어야 한다. 큰 구동을 위해 CLKBUF1 이라는 구동 셀(driver cell)이 추가 되어 있으나 그 능력이 모자란 것으로 보인다. 합성기는 클럭 신호에 11개의 클럭 버퍼 CLKBUF1을 삽입하였다. PDK의 셀 라이브러리의 타이밍 모델에 다르면 이 버퍼는 만만치 않은 지연을 가지고 있다.
input A ;
output Y ;
buf (Y, A);
specify
// delay parameters
specparam
tpllh$A$Y = 0.25:0.25:0.25,
tphhl$A$Y = 0.26:0.26:0.26;
// path delays
(A *> Y) = (tpllh$A$Y, tphhl$A$Y);
endspecify
endmodule
이 문제는 추후 해결 하기로 하고 먼저 합성의 기능적 문제만을 따져보기 위해 네트리스트 cpu.v 를 수정하자. QuestaSim의 Dataflow을 통해 찾아낸 클럭 버퍼의 인스턴스 이름은 CLKBUF1_insertXX이었다. 11개의 버퍼를 코멘트 처리하고,
2336: //.Y(clk_bF$buf0)
2337: //);
2338: //
..........................
2378: //
2379: //CLKBUF1 CLKBUF1_insert25 (
2380: //.A(clk),
2381: //.Y(clk_bF$buf9)
2382: //);
2383: //
2384: //CLKBUF1 CLKBUF1_insert24 (
2385: //.A(clk),
2386: //.Y(clk_bF$buf10)
2387: //);
2388:
시간 지연이 없는 버퍼로 대체해 넣는다.
수정된 cpu.v 를 재 컴파일 하여 시뮬레이션을 수행하면 펑션 시뮬레이션과 동일하게 작동 되는 모습을 볼 수 있다.
파형을 관찰 하면 표준 셀의 통과 지연이 반영되고 있는 모습을 볼 수 있다. 클럭 구동의 문제가 있지만 오픈 소스 합성기 yosys 는 기능상 문제없다. cpu_postroute.v 에 대하여 동일한 시뮬레이션을 진행하여 자동 배치배선 기능을 확인해보자.
--------------------------------------------------
[참고]
1. Digital System에서 Setup/Hold, http://www.internex.co.kr/insiter.php?design_file=notice_v.php&article_num=13&PB_1247810668=3
2. 16 Ways to Fix Setup and Hold Time Violations, https://www.edn.com/ways-to-solve-the-setup-and-hold-time-violation-in-digital-logic/
---------------------------------------------------------------------
[이전] Project_6502 예제의 기능적 Co-Simulation 실시 방법
[처음] SystemC 및 SDL2 라이브러리 빌드 하는 방법
댓글 없음:
댓글 쓰기