ETRI 0.5um CMOS Std-Cell DK 예제: CPU 6502 [5]
III. 6502 CPU 검증
---------------------------------------------
III. 6502 CPU 기능적 검증
6502 CPU 하드웨어의 기능적 검증의 방법으로 그 CPU를 채택한 컴퓨터의 시뮬레이터를 구성하고 실제 응용 프로그램을 실행 시켜본다. 몇가지 명령의 시험 조합으로는 부족하다. 실제 운용될 소프트웨어가 동원되어야 한다. Apple-1의 기본 모니터 프로그램 뿐만 아니라 어셈블러와 C 컴파일러를 활용한 테스트 프로그램을 작성하여 실행시켜본다. 1977년 발매되었던 애플소프트 베이직을 작동 시켜 더욱 심도있는 검증이 되도록 한다. 언어 변환기 베릴레이터와 QuestaSim 상용 HDL 시뮬레이터를 각각 사용하여 6502 CPU의 RTL 기능 검증용 Apple-1 시뮬레이터를 구성하고 비교한다. 오픈-소스 베릴로그에서 C++ 언어변환 도구 베릴레이터의 유효성 따져본다.
III-1. 모니터 프로그램
앞에서 6502 CPU를 채택한 컴퓨터 Apple-1의 하드웨어(시뮬레이터) 마련했다. 컴퓨터가 일을 하려면 소프트웨어가 필요하다. 전원 인가시 컴퓨터의 표준 입출력 장치를 준비(initialize I/O devices)시키고 명령을 받이 처리할 명령줄 해석기(command-line interpreter)가 대기하고 있어야 한다. 이런 기초 소프트웨어를 모니터 프로그램(monitor program)이라고 한다. 운용해야할 주변장치가 극히 제한되어 있어서 굳이 운영체제(operating system)라고 하지 않는다. 운영체제를 띄울 요량도 없기에 BIOS(Basic Input/Output System)라고 할 수도 없었다. 45년전(1976년)의 컴퓨터 Apple-1의 모니터 프로그램은 단 256바이트 크기로 명령줄 처리도 단순했지만 '혁신적'이라는 찬사와 함께 무려 $666.66 에 발매됐다. 당시 광고를 보면 "비싼 텔레 타이프 필요없다(Don't need an expensive teletype)" (타자식 인쇄기는 스크린장 치로 대체됐다), "스위치나 전구(LED)는 없어도 된다(No more switches, No more lights)" (LED 표시등과 토글 스위치는 키보드로 대체됐다.)면서 화면을 보면서 키보드로 프로그램을 입력할 수 있다고 광고했다. Apple-1 컴퓨터가 혁신적일 수 있었던 이유는 대화형 운용을 가능케 한 모니터 프로그램 덕이다. 이 단순한 모니터 프로그램을 작성한 사람이 바로 스티브 워즈니악[바로가기] 이다.
III-2. Apple-1 시뮬레이터 빌드
명령줄에서 리눅스의 GNU C++컴파일러를 사용하여 Apple-1 시뮬레이터(=시스템 수준 테스트 벤치)를 빌드 하려면 다소 복잡한 옵션을 써야 한다. 매번 이 옵션들을 기억하기도 어렵다. 소프트웨어 개발에 편집기(text editor)와 컴파일러(debugger) 그리고 디버거(debugger)까지 모두 갖춘 통합 개발 환경[바로가기] IDE (ntegrated development environment)[바로가기]이 진작부터 활용되어 생산성을 높이고 있다. 언어기반의 반도체 설계가 널리 확산되면서 IDE의 활용이 늘었다. 순차적인 구문뿐만 아니라 병렬성(parallelism), 데이터 흐름(data flow), 상태 머쉰(state machine), 재사용 모듈(parameterized reusable module) 블럭단위 편집기 같은 하드웨어적인 특성을 반영한 그래픽 기반 GUI (graphic user interface)의 통합 환경이 상용화 되고있다[주]. 특히 FPGA[바로가기] 공급사들의 개발 환경이 잘 마련되어 있다.
[이미지출처] Getting Started with ActiveHDL[link]
시스템 반도체 설계는 매우 넓은 범위(깊이와 폭 모두)의 추상성을 다뤄야 하는 만큼 통합 개발 환경의 채택은 설계 생산성에 큰 도움이 된다. 하지만 지나치게 특정 공정 지향적이 되어 융통성이 거의 없다. 사용자 편의 위주로 구성되어 내부 작동 흐름을 파악하기 어렵기 때문에 도구 제공자의 설계 방법론에 의존하게된다. 도구 뿐만 아니라 도구의 사용법 조차 자동화 되므로 문제에 대한 대응이 곤란하다. 설계 오류인지 도구의 한계 인지 구분하기 어렵다. 무엇보다도 공부가 않된다. 직관적인 그래픽 사용자 인터페이스 환경을 굳이 배척할 필요는 없다. 하지만 상용 도구들은 매우 고가 인데다 동시사용 가능한 라이센스에 제한을 받는다. 대규모 설계의 중간 단계에서 중소규모 설계와 검증에 오픈-소스 도구들이 활용 될 수 있다[참고].
[참고] OpenROAD: Toward a Self-Driving, Open-Source Digital Layout Implementation Tool Chain [link]
오픈-소스 도구를 사용하여 설계 도구의 구입에 비용을 들이고 싶지 않을 뿐만 아니라 도구의 운용을 유연하게 갖기 위해 명령줄 기반의 설계 플로우를 따른다. 오픈-소스 도구들이 저마다 개별적으로 개발 되는 탓에 통합 환경을 구축하기도 쉽지 않다. Make[주]는 컴퓨터 운영체제가 도입된 이래 유구히 사용되어온 개발 도구다. 문자 기반의 자동화 도구로 불편할 수 있으나 폭넓은 융통성을 제공한다. 화려한 모습의 통합된 자동화 도구들도 결국은 명령줄 실행으로 진행된다.
주] GNU Make 강좌, https://doc.kldp.org/KoreanDoc/html/GNU-Make/GNU-Make.html#toc1
simulation/Makefile
본 예제의 Apple-1 컴퓨터의 빌드와 실행을 수행하는 메이크(make) 유틸리티용 Makefile 을 제공하였다.
Make 를 실행하기 전에 먼저 베릴레이터를 비롯한 오픈 소스 도구들의 실행을 위한 환경 변수들을 설정한다. 주로 컴파일러를 도구들의 실행 경로를 정의해 놓았다. 디자인 킷[바로가기]에 제공한 cad_env 를 열어 오픈-소스 도구들이 설치된 폴더와 일치하는지 확인해 보자. 디자인 킷[바로가기]의 오픈-소스 도구들이 기본설정으로 설치되었다면 변경할 필요 없다.
Make 로 Apple-1 시뮬레이터를 빌드한다.
⦗OSS CAD Suite⦘ $ make
기본 빌드 타깃은 베릴레이터를 이용한 언어변환 방법의 빌드다.
베릴레이터에 의해 베릴로그에서 변환된 C++ 소스 파일과 g++ 컴파일러로 컴파일된 실행 파일 Vcpu가 obj_dir에 있다.
키보드 프로세스와 디스플레이 프로세스 파일도 컴파일 된다.
III-3. Apple-1 시뮬레이터 실행
Apple-1 시뮬레이터를 띄우기 전에 외부장치인 키보드 및 디스플레이 프로세스를 실행 시켜야 한다. 두 외부장치 프로세스는 시뮬레이터와 통신할 FIFO 를 생성하고 시뮬레이터와 연결을 기다린다. 외부장치는 별도의 커맨드 터미널을 열어 실행 시키거나 X-터미널 xterm을 통해 연다.
$ xterm -T "Apple-1 Display" ./a1_display &
$ xterm -T "Apple-1 Keyboard" ./a1_keyboard &
이어서 Apple-1 시뮬레이터를 실행한다.
$ xterm -T "Apple-1 Computer" ./obj_dir/Vcpu &
외부장치와 시뮬레이터가 FIFO 를 통해 연결 됨으로써 Apple-1 컴퓨터가 가동되는 모습을 보게 될 것이다.
디스플레이 장치 프로세스 터미널에 '\' 가 표시되고 있는데 이는 워즈니악 모니터 프로그램이 작동하여 입력을 대기하는 프롬프트 표시다. 전설적인 Apple-1의 모니터 프로그램이 변형 없이 시뮬레이터에서 작동되었다는 뜻이다. 모니터 프로그램은 메모리 모델이 사례화될 때 크래스 구성자가 실행되면서 모니터 "wosmon.bin"을 메모리에 적제한다. 모니터가 적제될 주소는 0xFF00 이다. 6502 CPU의 리셋 벡터[주]의 주소는 $FFFC 이므로 롬 메모리는 최상위 페이지 주소에 위치해야 한다.
주] 전원을 인가했을 때 처음 시작될 프로그램의 번지를 파워 온 리셋 벡터(Power-On reset vector)라고한다.
어셈블리어로 작성된 워즈니악 모니터 프로그램의 소스 리스트가 예제에 첨부되어 있으므로 살펴두면 응용 프로그램 작성에 도움이 될 것이다[주].
주] simulation/Apple-1/wozmon/wozmon.lst
Apple-1 메모리에 응용 프로그램을 적재하는 방법
Apple-1 메모리에 응용 프로그램을 적재하는 방법으로 메모리 모델의 소속 함수로 제공하였다.
// Filename: sc_mem.h
{
int ReadHEX(char* Hex_Filename);
int ReadBIN(char* BIN_Filename, int nOffset);
int ReadKEY_Seq(char* Keyboard_Filename, int nLines);
clk("clk"), AB("AB"), DI("DI"), DO("DO"), WE("WE")
{
SC_THREAD(mem_Thread);
sensitive << clk;
}
};
메모리 모델의 소속 함수로 메모리 적제용 유틸리티 함수들은 다음과 같다.
int ReadHEX(char* Hex_Filename);
16진수로 표현된 인텔 HEX 형식 파일[바로가기]을 읽어서 메모리에 적제한다. 이 양식에는 메모리 주소가 표현되어 있으므로 따로 적제할 위치를 지정할 필요 없다.
int ReadBIN(char* BIN_Filename, int nOffset);
주소정보가 없는 2진수 바이너리 파일을 메모리에 적재할 때 사용한다. 적제할 위치를 Offset으로 지정할 수 있다. 만일 위치를 0으로 놓으면 바이너리 파일 내의 적재 주소를 참조한다. C 컴파일러를 사용하여 응용 프로그램을 생성한 경우 4바이트의 적재정보(EXE_HDR)를 담고 있다. 바이너리 파일의 첫 두 바이트는 적재 주소이며 나머지 두 바이트는 길이다.
int ReadKEY_Seq(char* Keyboard_Filename, int nLines);
키보드 입력을 배치 형식으로 처리한다.
Apple-1의 작동 메뉴얼(Apple-1 Operation Manual[바로가기])에 모니터 프로그램의 사용예가 설명 설명되어 있다[Apple-1 Replica]. Apple-1 시뮬레이터의 작동을 확인 할 수 있다. 'HELLO WORLD'를 찍어보자. 어셈블리 소스는 아래와 같다.
org $0000
jsr start
jsr $FF00
org $0280
start:
ldx #$C
loop:
lda message,x
jsr $FFEF
dex
bne loop
jsr $FF00
message db "\r\nDLROW OLLEH",0
end start
리셋 벡터 $0000에 프로그램의 시작번지 $0280 로 서브루틴 분기했다. 6502용 어셈블러는 예제 배포판의 simulation/Apple-1/assembler/as65 다. 어셈블러 Makefile 은 아래와 같다. 실행 코드의 파일명은 program.hex 다.
$(AS65) -l -m -oprogram.hex -s2 hello_world.a65
$(RM) hello_world.lst hello_world.o hello_world.s
어셈블 한 기계 코드를 메모리에 적제하고 실행시킨다.
6502 CPU는 잘 작동한다.
6502 C 컴파일러
6502는 나름 C 언어를 고려해 만들어진 CPU다. 표준 C 언어로 컴파일 된 기계코드를 실행 하기 위해 스택 포인터를 운용하도록 설계되었다. 6502 용 C 컴파일러는 고전 컴퓨터 애호가들에 의해 오픈-소스로 꾸준히 개발되어왔다. 깃허브를 통해 C-컴파일러의 소스를 입수할 수 있으나 타깃 컴퓨터로 Apple-1은 빠져 있다. 다행히 Apple-1 애호가들은 패치를 만들어 냈다[바로가기]. 패치를 적용하여 6502 C 컴파일러를 빌드하는 방법은 아래와 같다.
6502 Build C-Compiler How-To
1. Go to https://github.com/mrdudz/cc65-old
2. Download cc65-2.13.2.tar.bz2
3. Extract compressed archive into working folder,
$ pwd
~/CPU_6502/simulation/Apple-1
$ tar xvf cc65-2.13.2.tar.bz2
4. Apply 'Apple-1' patch
5. Build cc65 compiler for Apple-1
6. Install cc65 tool-chain into Apple-1's software working folder,
Apple-1 용 C-컴파일러까지 설치된 6502 CPU 예제의 폴더구조는 다음과 같다.
+-- log
+-- source: RTL Verilog
+-- layout: P&R results
+-- simulation: C++ Tectbench
| +-- Apple-1: Firmware working folder
6502 C-컴파일러를 사용하기 위해 설정해 주어야 할 환경 변수는 다음과 같다.
$ export LD65_LIB=$PWD/cc65/lib/cc65/lib
$ export LD65_OBJ=$PWD/cc65/lib/cc65/obj
$ export PATH=$PATH:$PWD/cc65/bin
이제 C 컴파일러로 "Hello World"를 찍어보자. C 프로그램은 다음과 같다. 문자열 출력 표준함수를 시험할 겸 printf()와 putchsr() 두가지 방법으로 출력한다.
위의 C 프로그램을 컴파일 하기 위한 6502 C 컴파일러용 Makefile 이다.
PLATFORM = APPLE1CC65_HOME = ../../cc65-2.13.3/lib/cc65
CC65_HOME = ../../cc65-2.13.3/lib/cc65
CA65_INC = ../../cc65-2.13.3/lib/cc65/asminc
CC65_INC = ../../cc65-2.13.3/lib/cc65/include
LD65_CFG = ../../cc65-2.13.3/lib/cc65/cfg
LD65_LIB = ../../cc65-2.13.3/lib/cc65/lib
LD65_OBJ = ../../cc65-2.13.3/lib/cc65/obj
EXEC_PATH = ../../cc65-2.13.3/bin
all: cc65
program.bin: hello_world.o
$(EXEC_PATH)/ld65 -L$(LD65_LIB) \
-o program.bin hello_world.o apple1.lib
hello_world.o: hello_world.s
$(EXEC_PATH)/ca65 -t none --listing hello_world.s
$(EXEC_PATH)/cc65 -T -O --static-locals \
copy: program.bin
cp program.bin ../..
$(RM) hello_world.lst hello_world.o hello_world.s
C 컴파일러의 출력은 적재정보(EXE_HDR)가 들어있는 2진 파일이다. 첫 두바이트는 적재될 주소, 이어진 코드의 두 바이트는 길이다.
Apple-1 시뮬레이터(6502 CPU의 시스템 수준 테스트 벤치)에서 돌려보자. 메모리 $D018 번지를 읽기 접근하면 2진 파일을 적재한다. 메모리 모델의 sc_mem.cpp에서 0xD018 번지 읽기 부분에 구현되어 있다.
좀더 검증, Applesoft BASIC
좀더 검증이 필요하다면 BASIC 인터프리터를 실행해 볼 수도 있다. Apple-1이 발매되었을 때 C 컴파일러 같은 개발 도구는 없었다. 6502 명령표[바로가기]를 봐가며 손으로 직접 기계어를 작성했다. '대화형 컴퓨터"라는 구호만 가지고 '혁신'을 만들 수는 없다. Apple-1이 널리 보급되려면 자연어에 가까운 고수준의 프로그래밍 언어를 갖춰야 했는데 애플소프트 베이직(Applesoft BASIC)이다[바로가기]. 마이크로소프트사의 BASIC을 Apple-1용으로 개발 되었다. 1977년(47년전이다!)에 발매된 상용 앱개발용 소프트웨어다. Apple-1 시뮬레이터에 애플소프트 베이직을 적재하고 베이직 프로그램을 실행 시켜 봤다.
디자인 킷의 CPU 6502 예제 묶음(tar) 파일에 더 많은 응용 프로그램 예제들이 있으니 틈틈이 즐겨보기 바란다.
CPU를 설계 했다면 이정도 수준에서 검증을 해줘야 한다.
III-4. HDL 과 SystemC의 병행 시뮬레이션(Co-Simulation)
앞의 6502 CPU의 RTL 검증은 베릴로그에서 변환된 C++를 SystemC 테스트 벤치에 물려 GNU C++로 빌드한 Apple-1 시뮬레이터에서 응용 프로그램을 실행하는 방법으로 이뤄졌다. 언어 변환에 사용된 오픈-소스 도구 베릴레이터 Verilator[바로가기]는 이미 여러 설계 프로젝트에서 유용하게 쓰였다고 하지만 의문을 갖지 않을 수 없다. 비록 Apple-1 시뮬레이터에서 응용 프로그램을 실행 시켜 작동을 확인 할 수 있었다고 하지만 베릴로그 설계를 직접 검증 했다고 확신하기에 이르다. 이에 업계 표준의 HDL 시뮬레이터 QuestaSim(구 ModelSim)[바로가기]에서 동일한 시스템 수준 테스트 벤치로 베릴로그와 SystemC/C++의 병행 시뮬레이션(Co-Simulation) 방법으로 6502 CPU의 베릴로그 설계를 검증해 본다.
주] QuestaSim은 매우 고가의 시뮬레이션 도구다. 인텔의 FPGA 도구와 함께 무료사용이 가능하다. FPGA 버젼이라고 하지만 모든 기능을 제한없이 사용가능 하다. 무료 라이센스를 신청하면 1년짜리를 받을 수 있다. QuestaSim 인텔 FPGA 스타터 버젼 설치 및 라이센스 받기[바로가기]
주] QuestaSim을 리눅스 운영체제에서 사용 할 수 있다. 라이센스는 컴퓨터의 네트워크 어댑터 MAC 주소로 발급된다. 만일 마이크로소프트 윈도우즈의 WSL2로 리눅스를 사용할 경우 MAC 주소가 유동 배정된다. QuestaSim을 사용하려면 라이센스를 발급 받은 MAC 주소로 변경 해 주어야 한다.
xx:xx:xx:xx:xx:xx는 라이센스를 발급받은 MAC 주소다.
QuestaSim 의 SystemC
QuestaSim은 기존의 HDL(베릴로그, VHDL 그리고 SystemVerilog)는 물론 SystemC도 컴파일과 실행이 가능한 통합된 시뮬레이션 환경을 갖추고 있다. 그렇더라도 시뮬레이션 엔진이 통합되어 있는 것은 아니다. HDL의 하위 함수로 C/C++ 코드를 연결 하는 PLI/VPI나 DIP-C와는 다르게 SystemC를 동등한 하드웨어(또는 시스템) 모델링 언어로 받아들인다. 다만 C++ 언어의 특성(구문과 실행 방식)에서 오는 차이를 모두 수용할 수 없기에 언어 씌우개(wrapper)를 써야 하며 별도의 시뮬레이션 엔진(SystemC의 배포판에 포함되어 있다)을 가동 한다. SystemC를 지원하기 위해 GNU C/C++ 컴파일러를 내장하고 있다. SystemC 모듈이 컴파일 되면 동적 객체(shared-object, 또는 dynamic-linking library)로 생성되어 HDL 시뮬레이터와 실행중(run-time) 링크된다.
simulation/mti_sim/compile_fun.do
QuestaSim용 컴파일 스크립트는 아래와 같다. 베릴로그에 대해서는 기존의 QuestaSim 컴파일과 다를바 없다. SystemC의 C++ 코드 컴파일을 위해 sccom 명령이 사용되지만 실은 내장된 g++다. 명령줄 옵션와 스위치들도 g++와 동일하게 적용한다. C++ 코드의 컴파일 후 동적 실행 객체를 생성하기 위한 -link 옵션으로 sccom이 실행되는 것을 볼수 있다. SystemC 로 작성한 테스트 벤치 C++ 코드는 베릴레이터 언어 변환의 경우와 동일하다.
# MTI simulation scrips for SystemC Co-Simulation
# Vendor: GoodKook
# Associated Filename: compile.do
# Purpose: SystemC testbench
#**********************************************************
onbreak {resume}
# create library
if [file exists work] {
vdel -all
}
vlib work
# Verilog compile
vlog -reportprogress 300 -work work ../source/ALU.v
vlog -reportprogress 300 -work work ../source/cpu.v
sccom -work work ../simulation/sc_mem.cpp \
sccom -work work ../simulation/sc_main.cpp \
sccom -link
Makefile에 QuestaSim 용 타깃을 작성해 놓았으므로 이를 활용하여 빌드한다.
$ make mti_fun_build
키보드와 디스플레이 외부장치 실행 또한 앞선 베릴레이터 사용 언어변환 방식 Apple-1 시뮬레이터와 동일 하다. 다만 시뮬레이션의 주체가 SystenC 에서 QuestaSim으로 바뀌었다.
$ make mti_fun_run
QuestaSim을 GUI 없이 콘솔 환경으로 실행 했다. 시스템 수준의 시뮬레이션에서 파형을 볼 필요 없다. CPU와 응용 프로그램을 가동 하는데 그많은 클럭 파형을 봐서 뭘 하겠는가. 시스템 수준 시뮬레이션에서는 입출력을 감시하여 이상이 있을 경우 오류 표명(assertion)을 넣는 방법을 쓴다. 중요 지점에 조건문과 함께 printf()를 넣는 것이다.
Verilator vs. QuestaSim HDL simulator
애플소프트 베이직을 실행 시켜봤다. 동일한 결과를 보여준다. 베릴레이터 언어변환 방식 보다 실행 속도가 매우(!) 느리다. 실행속도는 HDL 시뮬레이터로 시스템 수준 검증을 실시할 경우 격는 최대 단점이다. 속도의 문제는 고속 프로토 타이핑(FPGA fast proto-typing), 에뮬레이션(FPGA emulation)같은 하드웨어 가속기(hardware accelerator)를 써서 극복하고 있다. 단, 매우 고가다.
베릴레이터를 이용한 Apple-1 시뮬레이터가 HDL 시뮬레이터에 비하여 빠른 속도를 보여준다. 대규모 설계의 각 부분단위에서 언어 변환기를 이용한 단계별 검증 전략이 효과적 일 수 있다. 오픈-소스 도구 베릴레이터의 유효함을 확인 했다.
* 베릴레이터는 RTL의 기능 수준 시뮬레이션의 한계를 가지고 있다. 게이트 수준 힙성 후 네트 시뮬레이션에 적합하지 않음을 보게될 것이다.
댓글 없음:
댓글 쓰기