블러그

항상 까먹어서 백업용으로 남기는 글

opencode models | grep -i {model명}

예시) minimax coding plan이라는 provider, 모델 명까지 찾음

대소문자 구분 없이 찾기 가능(Windows/Linux 모두 ok)

단 opencode models 명령은 현재 연결한 provider에 대해서만 나옴

Q. 위의 provider/model 찾는 이유?

A. oh-my-opencode.json 파일 수정용

직접 지정해서 사용

단순 취미로 OpenAI의 AI agent인 codex를 사용중인데, 카카오발 GPT Pro 1개월치를 사용해 구현함.

간단한 FreeRTOS를 이용해 Machine level kernel만을 사용

- 환경 -

Rocky linux 8.10 (이외 Linux라면 어떤 환경이던 상관 X)

Dependency: Codex, Verilator 4.028, riscv toolchain(crosscompiler)

codex 사용 방법은 따로 설명하지는 않는다. npm으로 설치하면 된다.

프로젝트 환경을 만들고 codex를 켜 준다.

$ codex

현재 환경을 신뢰한다.

Pro 요금제가 적용 중이기에, GPT-5.4 high fast를 사용한다.

프롬포트 환경 설정 등은 진행하지 않았다.

> RV64I 프로세서를 Verilog로 구현하고 해당 프로세서를 Verilator로 돌린 실행 파일 위에 freeRTOS 를 업로드해서 동작시키는 프로젝트를 진행한다.

에이전트가 질문에 따른 세부적인 경로를 제안해 준다.

기본 RV64I 코어 뿐만 아니라, 일부 CSR 및 인터럽트, I/O peripheral, SW level (RTOS)이 뭐가 필요하고 어떻게 해야 하는지에 대해 말해주고 있다.

일단 간단한 싱글 사이클 기본 코어를 구현한다.

> 현재 폴더는 빈 폴더이다. 먼저 기본 RV64I 코어를 구현한다.

해당 명령을 주니 계획을 세우기 시작했다.

먼저 RV64I unprivileged 구현을 시도한다.

다음으로 IMEM 및 DMEM interface와 간단한 testbench 생성을 시도한다.

[첫 번째 생성 파일 - Makefile]

VERILATOR ?= verilator
VERILATOR_FLAGS := -Wall -Wno-fatal -Wno-DECLFILENAME -Wno-UNUSED -Isrc

.PHONY: lint sim clean

lint:
	$(VERILATOR) --lint-only $(VERILATOR_FLAGS) src/rv64i_core.sv tb/tb_rv64i_core.sv

sim:
	$(VERILATOR) --cc --exe $(VERILATOR_FLAGS) --top-module tb_rv64i_core -o Vtb_rv64i_core src/rv64i_core.sv tb/tb_rv64i_core.sv sim/main.cpp
	$(MAKE) -C obj_dir -f Vtb_rv64i_core.mk
	./obj_dir/Vtb_rv64i_core

clean:
	rm -rf obj_dir

[두 번째 생성 파일 - rv64i_core.sv] : Verilog로 생성하라고 했지만 Systemverilog로 생성을 함

내용이 길어 따로 붙여넣기에 애로사항이 있어 파일 첨부로 대체

[세 번째 생성 파일 - tb_rv64i_core.sv] : 테스트벤치 파일.

[네 번째 생성 파일 - cpp 시뮬레이션 파일]

#include <cstdlib>
#include <iostream>

#include <verilated.h>

#include "Vtb_rv64i_core.h"

int main(int argc, char** argv) {
    Verilated::commandArgs(argc, argv);

    auto* top = new Vtb_rv64i_core;
    top->clk = 0;
    top->rst_n = 0;

    for (int cycle = 0; cycle < 128 && !top->done; ++cycle) {
        if (cycle == 4) {
            top->rst_n = 1;
        }

        top->clk = 0;
        top->eval();

        top->clk = 1;
        top->eval();
    }

    const int rc = top->failed ? EXIT_FAILURE : EXIT_SUCCESS;
    top->final();
    delete top;

    return rc;
}

전형적인 Verilator tb 포맷이다.

파일 생성 후 자동 lint 체크와 시뮬레이션을 진행한다.

코어 파일을 보면 single cycle에서 흔히 볼 수 있는 간단한 구조로 짜여 있다.

애초에 간단하게 하려고 했으니 뭐..

이후는 기존 계획대로 추천해주는 CSR 구현을 하도록 한다.

> CSR 관련 사항을 구현한다.

이것도 자동으로 계획 수정을 진행한다.

Zicsr extension 중 RTOS 실행에 필요한 machine level CSR 일부를 선택해 사용한다.

이외 트랩 처리 로직 등을 추가로 구현해 실제 OS에 필요한 부분들을 채운다.

트랩 처리를 위해서는 기본 코어의 변경 사항이 필요하기에, 코어 변경을 시도한다.

이후 해당 로직의 검증을 위해 testbench도 변경 사항을 적용한다.

변경 적용 후  lint check, sim check를 통해 유효성 검증을 수행한다.

이후 구현해야 할 모듈들에 대해 언급한다.

우린 Machine mode만 사용할 것이기 때문에 CSR에 user / hypervisor 등은 필요하지 않다.

하지만 I/O를 위한 UART, Interrupt는 필요하다. 따라서 해당 부분을 먼저 만든다.

mtime의 경우 uptime 측정을 위해 있을 것으로 예상되긴 하지만, 일단 보류한다.

> 다음 I/O 부분을 구현한다.

I/O 부분을 구현한다고 하니 인터럽트는 빠지고 I/O 부분을 먼저 구현한다고 알아들은 것 같다.

코어를 감싸는 SoC 부분을 새로 생성하고, 해당 파일 내부에 코어와 I/O 유닛을 넣고 MMIO로 동작하게 만들었다.

하면서 Makefile과 cpp 파일도 변경 사항이 생겼다.

[Makefile]

VERILATOR ?= verilator
VERILATOR_FLAGS := -Wall -Wno-fatal -Wno-DECLFILENAME -Wno-UNUSED -Isrc

.PHONY: lint lint-core lint-soc sim sim-core sim-soc clean

lint: lint-core lint-soc

lint-core:
	$(VERILATOR) --lint-only $(VERILATOR_FLAGS) src/rv64i_core.sv tb/tb_rv64i_core.sv

lint-soc:
	$(VERILATOR) --lint-only $(VERILATOR_FLAGS) src/rv64i_core.sv src/rv64i_soc.sv tb/tb_rv64i_soc.sv

sim: sim-core sim-soc

sim-core:
	$(VERILATOR) --cc --exe $(VERILATOR_FLAGS) --top-module tb_rv64i_core -o Vtb_rv64i_core src/rv64i_core.sv tb/tb_rv64i_core.sv sim/main.cpp
	$(MAKE) -C obj_dir -f Vtb_rv64i_core.mk
	./obj_dir/Vtb_rv64i_core

sim-soc:
	$(VERILATOR) --cc --exe $(VERILATOR_FLAGS) --top-module tb_rv64i_soc -o Vtb_rv64i_soc src/rv64i_core.sv src/rv64i_soc.sv tb/tb_rv64i_soc.sv sim/main_soc.cpp
	$(MAKE) -C obj_dir -f Vtb_rv64i_soc.mk
	./obj_dir/Vtb_rv64i_soc

clean:
	rm -rf obj_dir

코어 simulation 뿐만 아니라 SoC sim이 생성되었다.

[main_soc.cpp]

#include <cstdlib>

#include <verilated.h>

#include "Vtb_rv64i_soc.h"

int main(int argc, char** argv) {
    Verilated::commandArgs(argc, argv);

    auto* top = new Vtb_rv64i_soc;
    top->clk = 0;
    top->rst_n = 0;

    for (int cycle = 0; cycle < 256 && !top->done; ++cycle) {
        if (cycle == 4) {
            top->rst_n = 1;
        }

        top->clk = 0;
        top->eval();

        top->clk = 1;
        top->eval();
    }

    const int rc = top->failed ? EXIT_FAILURE : EXIT_SUCCESS;
    top->final();
    delete top;

    return rc;
}

SoC 용으로 따로 작성된 파일이 생성되었다.

또한 코어 파일의 halt 조건이 변경됐다.

이외 플래그 정리도 생겼기에 새로 파일을 추가한다.

이제 인터럽트를 붙인다.

mtime / mtimecmp도 인터럽트 시스템에 포함된다고 봐야 할 것 같으니 한번에 저 3개를 만드는게 좋을 것 같다.

> 다음으로 mtime, mtimecmp, trap 인터럽트를 구현한다.

다음 자동으로 할 일을 찾아서 수행한다.

코어 및 soc 파일의 수정을 진행한다.

늘어난 기능에 맞춰 Makefile과 tb_rv64i_timer.sv, main_timer.cpp가 추가되었다.

파일을 계속 첨부하기보다 완성본을 마지막에 올리는게 나을 것 같아 나중에 한 번에 올리도록 변경한다..

스스로 오류 수정을 진행했다.

이 정도면 코어 부분은 다 완료 된 것으로 볼 수 있다.

다음은 freeRTOS의 커널 부분 실행을 위해 Bare-metal 환경에서도 동작하도록 링커 스크립트 작성, FreeRTOS 가져와서 변형, RISC-V 크로스컴파일러 컴파일 등을 해야 할 것이다. 실행 자체는 시뮬레이션에 linux 내에서 하기 때문에 riscv64-linux- .. 툴체인을 사용한다.

이번에는 GPT의 마지막 핸들러 작성이 맞다라고 나온 저 문장에 동의를 해도 제대로 수행하는지 궁금해져서 "그래" 한마디를 쳐 보도록 한다.

> 그래

에이전트의 메모리가 제대로 동작하고, 컨텍스트 내부 데이터를 읽어(?) 데이터 확인을 하기에 보통 이전 프롬포트 결과나 답변의 결과 연계성은 최근 들어서는 굉장히 좋아진 것 같다.

아무튼 구현해 봐라 한 마디로 시작을 시켜본다.

> 구현 해 봐라

펌웨어 구현을 위해 툴체인이 있는지 먼저 파악을 한다.

먼저 crt0.S 파일을 만들어서 C 런타임 시작 코드를 생성한다.

내가 돌리려는 환경 자체가 bare-metal 환경이니 뭐 당연하다 볼 수 있다.

이후 링커까지 생성해서 링킹도 완료해 준다.

실제로 돌아갈 main 파일도 생성한다.

#include "platform.h"

#define DEMO_TICK_INTERVAL 100ULL
#define DEMO_TICK_TARGET   3ULL

int main(void) {
    platform_uart_puts("BOOT\n");
    platform_gpio_write(0);

    platform_timer_write(0);
    platform_timer_set_compare(DEMO_TICK_INTERVAL);
    platform_enable_timer_interrupt();
    platform_enable_global_interrupts();

    while (g_timer_ticks < DEMO_TICK_TARGET) {
    }

    platform_disable_global_interrupts();
    platform_disable_timer_interrupt();

    platform_gpio_write((uint32_t)g_timer_ticks);
    platform_uart_puts("DONE\n");
    platform_sim_halt(1);

    return 0;
}

시작할 때 BOOT 키워드를 주고 특정 틱에 도달할 시 꺼지는 것 같이 보인다.

위의 플랫폼 파일은 C와 하드웨어를 직접 이어주기 위한 ADDR 정의 등이 포함되어 있다.

trap이랑 trap entry도 각각 .c, .S로 구현을 한다.

펌웨어용으로 soc sv 파일을 다시 불러서 처리도 추가했다.

이후 lint check, 시뮬레이션도 자동으로 진행해 오류 탐지를 수행한다.

혼자 또 여러가지 검사를 진행하고 다음으로 필요한 것들을 추천해 준다.

계속 진행하라고 답변을 보낸다.

> 계속 진행하라

다음은 실제 펌웨어 형태로 데모를 추가한다.

이를 위해 rtos_demo.c 파일을 추가한다.

이제 agent에게 실행되게 완료하는 과정을 주문한다.

실제 shell 데모처럼 동작하도록 확장한다

완료했다고 떠서 실행시켜 봤다.

시뮬레이션으로도 이런 RV64I 코어 기반 RTOS 돌아가는 것까지 확인하는 간단한 프로젝트를 진행해 봤다.

사실 혼자 힘으로 하면 펌웨어 맞추는 방향에서 시간 소모가 굉장히 오래 걸릴 것 같은데, FreeRTOS같은 경우 널리 알려져 있기도 하고 AI의 도움을 받으면 빠르게 틀린 부분도 잡아낼 수 있으니 이제 간단하게 할 수 있는 프로젝트 수준이 된 것 같다.

논문 A Complete Beginner Guide to the Number Theoretic Transform (NTT)을 바탕으로, 1회 공부해본 뒤 작성해 보는 글임.

대충 이렇다고 생각하면 될 것 같다.

NTT를 사용하는 이유는 뭘까? NTT 도메인 상에서는 pointwise multiplication을 통해 다항식 곱셈을 빠르게 수행할 수 있다는 장점이 있는데, 이는 링 Z_q/(x^n+-1) 상에서 일반 다항식 곱셈을 수행한 결과와 동일한 결과를, 더 빠르게 수행할 수 있다고 말할 수 있다. 시간복잡도는 O(n^2)와 O(n log n)으로 차이가 난다.

필요한 부분은 NTT를 빠르게 하는 방법에 대한 내용인데, 이는 FFT 적용된 NTT 알고리즘인 Cooley-Tukey(CT) 및 Gentleman-Sande(GS) 알고리즘을 사용해 NTT를 빠르게 수행한다.

CT 및 GS 알고리즘 모두 분할정복법을 사용하기 때문에 우리가 흔히 볼 수 있는 Butterfly 형태가 나타나게 된다. 흔히 분할정복법이라 하면 tree 형태로 나뉘는 것을 생각하면 되겠다.

논문을 보게 되면 n차 단위근(root of unity), 2n차 단위근 이런 값들이 나오고 사용 방법도 나오니 한 번 보면 이해가 빠를 것 같다.

우리가 알고 싶은 것은 결국 논문의 내용 중

해당 내용이라고 볼 수 있는데 NTT(a)의 j번째 원소(벡터)의 값을 구하는 방법을 나타낸 것이다.

이를 코드로 나타낸 내용은 다음과 같이 사용된다.

이때의 zeta 값은 위의 수식의 psi^(2j+1)에 해당된다고 생각하고 넘어가자.

복잡해 보이지만 이는 위의 버터플라이 모양을 반복 적용한 모양이 된다. 이를 그림으로 그리게 되면 다음과 같은 모양이 나오게 된다.

오른쪽 위의 라운드가 거듭될수록 변수가 바뀌는 순서를 기록했다. len이 0이 될 때 까지 반복되며, 이는 2**7 == 128 즉 (7+1)회 NTT가 반복되는 것을 알 수 있다.

INTT의 경우에는

zeta의 위치가 이렇게 달라진다.

+ 가장 마지막에 scaling factor(n^(-1))도 기존 INTT처럼 곱해주는게 남아있다.

또한 분할정복법을 사용하기 때문에 NTT의 반대 수순으로 연산이 진행된다. (len이 1부터 점점 늘어서 128까지)

그림은 생략한다(NTT의 정 반대 모양에, 곱해지는 값 및 순서만 달라짐)

3번에서 이어서 간다.

Instruction Fetch

CV32E40P의 IF 단계는, 외부 버스 인터페이스가 한 사이클에 한 번씩 fetch 요청을 처리할 수 있다면 한 사이클에 하나의 명령어를 ID 단계로 공급할 수 있다.

만약 압축 명령어(C extension)를 실행하는 경우, ID 단계에서 평균적으로 명령어 1개당 32비트 fetch 요청이 1개 보다 적게 필요하다.

최적의 성능 및 타이밍을 위해 Prefetch buffer 가 사용된다.

이 Prefetch buffer는 외부 버스 인터페이스를 통해 외부 명령어 메모리 또는 명령어 캐시 등에서 명령어를 가져온다.

Prefetch buffer는 32비트 정렬된 Prefetch 동작을 수행하고, 가져온 명령어 워드를 FIFO 구조로 저장한다.

이 FIFO의 엔트리 개수는 로컬 파라미터(DEPTH, default : 2, cv32e40p_prefetch_buffer.sv 에서 정의)에 따라 달라진다.

이러한 (추측하는) Prefetch buffer 로 인해, CV32E40P는 코드 영역 바깥까지 DEPTH 워드만큼 명령어를 미리 fetch 할 수 있다. 따라서, 실제 코드 영역 밖을 미리 읽음으로써 의도치 않은 read side-effect 가 발생하지 않도록 주의해야 한다.

표 64는 명령어를 가져올 때 사용되는 신호들에 대해 설명한다.

또한 버스 연결된 인터페이스에는 쓰기 신호가 없기 때문에 Ld/St unit보다 더 단순하다.

Misaligned Accesses

외부적으로 IF 인터페이스는 항상 32비트 정렬된 명령어 fetch 만 수행한다.

만약 instruction fetch 주소가 워드 정렬되지 않았다면(즉, misaligned fetch 라면)

두 번의 워드 정렬 fetch로 해당 명령어를 읽어온다.

코어 내부적으로는, 워드 정렬과 하프워드 정렬 주소 모두를 처리할 수 있어서 Compress instruction도 지원 가능하다. 

내부적으로는 instruction address의 LSB는 무시된다.

--> 32비트 명령어는 항상 4바이트 단위 정렬, 16비트 압축 명령어는 항상 2바이트 단위로 정렬됨. 따라서, 어떤 명령어가 오던 간에 내부에서는 [0]번 비트가 항상 0이기 때문에 무시된다는 것.

ex) 외부 fetch:

1) 주소가 0x1002(하프워드 정렬)이면(32비트 명령어를 읽어야 하는 상황)

2) 0x1000, 0x1004 두 번의 워드 정렬 fetch 를 해서 명령어를 조합

내부 처리:

1) 0x1000 / 0x1002 모두 처리 가능

2) 내부에서는 LSB 무시(0x1000, 0x1002 --> 내부적으로 같은 fetch 처리)

Protocol

CV32E40P 명령어 fetch 인터페이스는 아래의 OBI(Open bus interface) 신호들을 지원하지 않는다.

- we

- be

- wdata

- auser

- wuser

- aid

- rready

- err

- ruser

- rid

이 신호들은 OBI specification 에 정의된 옵션 신호이며, CV32E40P에서는 해당 신호들이 사용되지 않고, OBI specification에 따라 tie-off(상수값 고정)된 상태로 간주된다.

트랜잭션 순서(Transactions Ordering)에 대해 설명하자면,

CV32E40P의 명령어 fetch 인터페이스는 최대 DEPTH개까지 미처리(Outstanding) 트랜잭션을 생성할 수 있다. OBI 명세에 따르면, 마스터 입장에서는 항상 순차적(in-order)로 링크가 유지되어야 한다.

하지만 fetch 인터페이스는 트랜잭션 ID(aid)를 생성하지 않으므로, 인터커넥트(버스 중계기 등)에서 응답이 요청 순서와 동일하게 되돌아오도록 자체적으로 추가 정보를 이용해 순서를 맞춰줘야 한다.

아래는 프로토콜의 타이밍도 예제이다.

그림. 6

CC 2에서 request 가 high 상태 & grant 도 high ==> 요청이 즉시 수락됨

CC 3일 때 rvalid가 high 상태 ==> 그 시점의 데이터들이 전송됨(instr_rdata_i)

연속적인 파이프라인 동작을 보여줌. (요청마다 곧바로 응답)

그림. 7

CC 2에서 request가 high 상태 & grant 도 high ==> 요청 즉시 수락

하지만 rvalid는 high로 뜨지 않았기 때문에 데이터가 나가지는 않음

CC 4에서 request가 low 되고, request가 일단 종료.

CC 5에서 rvalid가 high, 처음의 트랜잭션이 처리됨.

CC 6에서 새로운 request가 들어옴과 동시에 처음에 있었던 트랜잭션이 모두 완료

.. 반복

메모리 병목이 존재하면 Outstanding transactions 가 늘어난다는 것을 볼 수 있음.

Load / Store Unit (LSU)

코어의 LSU는 데이터 메모리 접근을 담당한다.

LSU는 워드, 하프워드, 바이트 단위의 Ld / St 명령을 모두 지원한다.

CV32E40P의 데이터 인터페이스는 최대 2개의 outstanding(미완료) 트랜잭션까지 발생시킬 수 있다.

추가적인 outstanding 요청을 허용하는 FIFO 버퍼는 없다.

다음 표는 LSU에서 사용되는 신호들이다.

Misaligned Accesses

LSU는 주소 정렬 예외를 발생시키지 않는다.

즉, 비정렬되었더라도 예외 없이 연산을 수행한다.

만약, Load/Store 대상 데이터가 워드 경계를 넘는 경우, 해당 명령어는 두 번의 버스 트랜잭션으로 나뉘어 수행된다.

하나의 load/store 명령어가 두 번의 버스 트랜잭션이 필요한 경우:

1) 워드 접근인데 주소가 워드 정렬이 아닌 경우

2) 하프워드 접근인데, 주소가 워드 경계를 넘는 경우

두 경우 모두, 낮은 주소에 대한 전송을 먼저 수행한 뒤, 그 다음에 높은 주소에 대한 전송을 진행한다.

Protocol

CV32E40P 데이터 인터페이스는 다음의 OBI 신호들을 구현하지 않는다:

- auser

- wuser

- aid

- rready

- err

- ruser

- rid

이 신호들은 OBI specification에 따라 연결 해제(tied off) 된 것으로 간주할 수 있다.

트랜잭션 순서
앞서 언급했던 것 처럼, 데이터 인터페이스는 최대 2개의 미처리 트랜잭션(outstanding transaction)을 생성할 수 있다.
OBI specification 에서는 마스터 관점에서 링크가 항상 순서대로(in-order) 동작해야 한다고 규정한다.
따라서 데이터 인터페이스가 트랜잭션 ID(aid)를 생성하지 않으므로, 인터커넥트(infrastructure)가 자체적으로 추가 정보를 부가하여 응답이 전송 순서와 동일하게 도착하도록 보장해야 한다.

LSU가 메모리와 통신할 때 사용하는 OBI 프로토콜의 동작 방식은 다음과 같다:

1) LSU가 유효한 주소를 data_addr_o에 출력하고, 제어 정보는 data_we_o, data_be_o로 제공하며, data_req_o를 High 로 설정한다.

2) 메모리는 요청을 처리할 준비가 되면 data_gnt_i 를 High 로 올린다. 이 타이밍은 요청이 오기 전일 수도 있고, 후일 수도 있다. (언제나 high면 지속적인 데이터 처리가 가능하다.)

3) 요청이 승인(grant)된 이후에는, LSU가 그 다음 클럭 사이클에 주소 신호를 변경해도 상관없다. 

왜냐하면, 메모리가 이미 해당 정보를 내부적으로 처리 및 저장했다고 가정하기 때문이다.

4) 요청이 승인된 뒤, 메모리는 data_rvalid_i 를 High로 올려서 data_rdata_i가 유효함을 알린다. 이는 요청 승인 후 한 사이클 이상 지연될 수 있다.

5) 주의점 : data_rvalid_i는 write 트랜잭션의 경우에도 응답(response) 단계가 끝났음을 알리기 위해 High로 올라가야 하며, 이때 data_rdata_i의 값은 의미 없다.(don't care)

6) 만약 여러개의 승인된 요청이 미처리(outstanding) 상태라면, 메모리가 요청을 순서대로 유지한다고 가정하며, 각각의 요청에 대해 발행한 순서대로 data_rvalid_i가 high가 된다.

다음은 프로토콜의 타이밍도 예제이다.

Post-Incrementing Load / Store Instructions

COREV_PULP == 1인 경우에만 해당된다 (PULP Custom Extension)

Post-incrementing load/store 명령어는 데이터 메모리에서 로드 또는 스토어 연산을 수행하면서, 동시에 베이스 주소를 지정된 오프셋만큼 증가시킨다.

메모리 접근 시에는 오프셋이 적용되지 않은 베이스 주소를 사용한다.

해당 명령어를 사용하면, 일반적인 루프에서 자주 나타나는 규칙적인 데이터 접근 패턴의 코드에서 필요한 명령어 수를 줄일 수 있다. 이러한 명령어는 메모리 접근 명령어에 주소 증가 기능을 내장시켜 별도의 포인터 연산 명령어가 필요 없게 해 준다.

이를 하드웨어 루프 확장과 결합하면, 루프 오버헤드를 크게 줄일 수 있다.

예시)

int sum = 0;
int* ptr = arr;
for (int i = 0; i < 8; i++) {
    sum += *ptr;   // 메모리 읽기
    ptr++;         // 포인터 증가
}

해당 경우 어셈블리 변환 시 로드 + 포인터 증가가 항상 쌍으로 들어감

# pseudo-assembly
sum = 0
ptr = arr
for i = 0 to 7:
    sum += LD_POSTINC ptr, 4  # ptr이 가리키는 4바이트(load) 읽고, ptr을 4 증가

포인터 처리가 간단해지는 것을 볼 수 있음.

lp.setup loop_label, 8       # 하드웨어 루프 8회 세팅
loop_label:
  LD_POSTINC ptr, 4, reg     # reg = *ptr, ptr += 4
  add sum, sum, reg

하드웨어 루프와 같이 동작시에는 다음과 같이 사용됨(어셈블리)

Register file

소스 파일 : rtl/cv32e40p_register_file_ff.sv

CV32E40P는 31개의 32-bit 너비의 레지스터가 x1-x31로 규정되어 있다.

x0은 소위 zero 레지스터로, 다른 회로를 포함하지 않고 읽기만 가능하다.

우리가 사용하는 코어의 레지스터 파일은 3R2W 레지스터 파일(3 Read port, 2 Write port)이다.

레지스터파일은 ID 단계에서 읽어진다. 그리고 WB 단계에서 쓰여진다. (근데 아까 ALU 같은 연산은 EX 단계에서 바로 레지스터 파일로 쓰여진다고 적혀있긴 했다)

Floating point register file

옵션 FPU가 인스턴스화된 경우, ZFINX가 설정되어 있지 않다면, 레지스터 파일은 f0~f31까지의 추가적인 32개 부동소수점 레지스터 뱅크가 확장된다(ZFINX가 설정되었다면 일반 범용 레지스터를 쓸 것이다 .아마도)

이 레지스터들은 기존 레지스터 파일 위에 쌓이는 형태로 구현되며, 한 사이클에 최대 3개의 오퍼랜드만 읽을 수 있다는 제한을 제외하면 동시에 접근이 가능하다(일반 레지스터파일과 동일하다)

각 오퍼랜드의 주소에는 어떤 레지스터파일(정수/부동소수점)에서 읽을 지를 나타내는 선택 신호가 추가되고, 이 신호는 FP 명령어가 디코딩될 때 명령어 디코더가 생성한다.

이 추가 신호를 통해 해당 operand가 정수 레지스터파일에 있는지, FP 레지스터파일에 있는지 결정된다.

포워딩 경로와 Write-back 로직은 정수/부동소수점 연산 모두에서 공유하며, 별도로 복제되지 않는다.

Sleep unit

소스 파일 : rtl/cv32e40p_sleep_unit.sv

Sleep unit은 내부적으로 clock gate 를 포함하고, 이를 제어한다.

이 clock gate는 입력 클럭 clk_i를 차단하거나 전달해서, CV32E40P 내부의 다른 모듈에서 사용할 gated clock을 생성한다.

즉, clk_i를 직접 사용하는 곳은 sleep unit이 유일하며, 나머지 모든 모듈은 sleep unit에서 생성된 gated clock만 사용한다.

--> sleep unit이 clock을 제어하는 가장 핵심적인 역할을 함.

Sleep unit의 클럭 게이팅 동작은 다음 신호들의 영향을 받는다.

1) rst_ni : 리셋 신호

2) fetch_enable_i : 명령어 가져오기 활성화 신호

3) wfi 명령어 (단, COREV_CLUSTER = 0)

4) cv.elw 명령어 (단, COREV_CLUSTER = 1)

5) pulp_clock_en_i (단, COREV_CLUSTER = 1)

다음은 Sleep unit 인터페이스 표다.

Extension을 보통 끄고 사용할거고 클러스터 형태로 만들지 않고 일반 FPGA에서 동작시킬 것이므로 

일단 COREV_CLUSTER == 0인 기준으로 봐야 되겠다.

Startup behavior

CV32E40P가 부팅될 때, clk_i는 내부적으로 게이팅되어 차단된다.(이 때 core_sleep_o = 0으로 표시)

- rst_ni(리셋 신호)가 활성화(=0, active low) 되어 있는 동안 clk_i는 게이팅되어 꺼진다.

- rst_ni가 비활성화(=1) 된 후에도, fetch_enable_i가 1이 될 때 까지는 clk_i는 계속 게이팅되어 꺼져 있다.

- fetch_enable_i가 최초로 1로 올라가면, 그 이후에 fetch_enable_i 신호는 다음번 리셋이 걸릴 때 까지 무시된다.

WFI

클러스터를 0으로 사용하면 되는 옵션이다.

wfi 명령어는 특정 조건에서 슬립 모드에 진입하여, 로컬에서 활성화된 인터럽트가 pending(미결정) 상태가 될 때 까지 대기하는 데 사용될 수 있다. wfi의 동작은 mstatus의 글로벌 인터럽트 비트에 영향을 받지 않는다.

아래 조건 중 하나라도 해당되면 wfi는 슬립 모드에 들어가지 않고 일반 nop처럼 실행된다:

1) debug_req_i = 1이거나 디버그 요청이 pending인 경우

2) 코어가 디버그 모드에 있는 경우

3) 코어가 싱글 스테핑(디버깅) 중인 경우

4) 코어가 트리거 매치 (디버깅)가 발생한 경우

5) COREV_CLUSTER = 1인 경우

--> 근데 위에서 디버그 내용 넘어갔는데..

만약 wfi로 인해 슬립 모드에 진입하면, core_sleep_o가 1로 설정되고 clk_i는 내부적으로 게이팅되어 차단된다. 이 상황에서는 clk_i를 외부에서도 차단할 수 있다.

슬립 모드에서 깨어나는 조건은 다음과 같다:

1) 로컬에서 활성화된 인터럽트가 pending 상태가 됨.

2) 디버그 요청이 pending 상태가 됨.

3) 코어가 디버그 모드에 진입

이 중 하나라도 발생하면, core_sleep_o는 0으로 설정되고 clk_i는 내부적으로 더 이상 게이팅되지 않으며, 외부에서도 clk_i를 차단하면 안 되고, 그리고 명령어 실행이 계속된다.

만약 위와 같은  깨어나는 조건이 wfi 명령어와 동시에 발생하면, 깬 상태가 우선권을 가진다(슬립 모드에 진입하지 않는다)

PULP Cluster Extension

넘어간다.

그 외 Core versions and RTL Freeze Rules / Glossary 는 구현에 있어서는 그냥 한번 슥 보고 넘어가면 될 정도인 것 같다~

2번 파일에서 이어서 본다.

Performance Counters

CV32E40P는 RISC-V Privileged Specification 버전 1.11의 3.1.11절에 따라 성능 카운터를 구현한다.

성능 카운터는 CSR 내에 위치하며, CSRRW(I)(CSR Read/Write, (Immediate)) 및 CSRRS/C(I)(CSR Read and Set/Clear, (Immediate) 명령어를 통해 접근 가능하다.

CV32E40P는 다음과 같은 카운터를 지원한다:

1) 클럭 사이클 카운터(mcycle(h))

2) 완료된 명령어 카운터(minstret(h))

3) 매개변수로 지정 가능한 이벤트 카운터(mhpmcounter3(h) ~ mhpmcounter31(h)) 및 각각에 대응되는 이벤트 선택 레지스터(mhpmevent3 ~ mhpmevent31)

4) 각 카운터별로 개별적으로 활성화/비활성화할 수 있는 mcountinhibit CSR

여기서 mcycle(h)와 minstret(h)는 항상 사용 가능하다.

모든 카운터는 64비트 너비를 가진다.

이벤트 카운터의 개수는 파라미터 NUM_MHPMCOUNTERS에 의해 결정되며, 값의 범위는 0~29(기본값 1)이다.

구현되지 않은 카운터를 읽으면 항상 0이 반환된다.

Event Selector

다음은 이벤트들이다.

이벤트 선택 CSR(mhpmevent3 ~ mhpmevent31)는 각각의 이벤트 카운터 mhpmcounter3(h) ~ mhpmcounter31(h)가 어떤 이벤트를 카운트할 지 정의한다.

이벤트 선택 CSR의 특정 비트가 1로 선택되어 있으면, 해당 ID를 가진 이벤트가 해당 카운터에서 카운트 된다는 의미이다.

이벤트 선택 CSR의 값이 0이면, 해당 카운터는 어떤 이벤트도 카운트하지 않는다.

Controlling the counters from SW

리셋 후에는 모든 사용 가능한 카운터가 비활성화되어 있어, 최소 전력 소모 상태를 유지한다.

각 카운터는 mcountinhibit CSR(addr : 0x320)의 해당 비트를 덮어써서 개별적으로 활성화 또는 비활성화할 수 있다.(RISC-V Privileged Specification 3.1.13절)

특히,

1) mcycle(h)를 켜거나 끄려면 비트 0,

2) minstret(h)의 경우 비트 2,

3) mhpmcounterX(h)(이벤트 카운터)는 비트 X를 설정해야 한다.

모든 카운터의 하위 32비트는 base레지스터로, 상위 32비트는 h-레지스터로 접근할 수 있다. 이 레지스터를 읽는 동작은 별도의 동작이다(읽어도 값이 지워지지 않음)

Parameterization at synthesis time

mcycle(h)와 minstret(h) 카운터는 항상 사용 가능하며 64비트 너비를 가진다.

이벤트 카운터 mhpmcounterX(h)의 개수는 NUM_MHPMCOUNTERS 파라미터로 제어할 수 있다. 기본값은 1이다.

NUM_MHPMCOUNTERS를 1 증가시킬 때마다 다음 자원이 추가로 필요하다:

1) 64개의 플립플롭 : mhpmcounterX 용

2) 15개의 플립플롭 : mhpmeventX 용

3) 1개의 플립플롭 : mcountinhibit[X] 용

4) Adder 및 이벤트 활성화 로직

Time Registers(time(h))

사용자 모드(unprivileged mode)의 time(h) 레지스터는 미구현이다.

이 레지스터에 접근하면 illegal instruction trap 이 발생한다.

따라서 소프트웨어 trap 핸들러를 구현해 이러한 CSR 접근을 감지하고, 플랫폼에서 구현되어 있다면 mtime 레지스터로 변환해 접근하는 것이 권장된다.

Control and Status Registers

CV32E40P는 RISC-V privileged specification에서 명시된 모든 CSR를 구현하지 않았고, PULP 시스템에 필요한 레지스터만 제한적으로 구현하였다.

이렇게 설계한 이유는 코어의 면적을 최대한 작게 유지하고, 명확하게 필요한 기능 외의 오버헤드를 방지하기 위함이다.

CSR Map

다음 표는 구현된 모든 CSR을 나열한다. 표 2개의 열에 대한 추가 설명이다:

1) Privilege 열은 CSR에 접근할 수 있는 권한 수준을 나타낸다. 첫 글자는 해당 CSR에 접근하는 데 필요한 최소 권한 수준을 의미한다.

현재 코어가 동작 중인 권한 수준보다 더 높은 권한이 요구되는 CSR에 접근을 시도하면 illegal instruction 예외가 발생한다. 

2) 나머지 글자는 해당 권한 수준(또는 그보다 높은 권한)에서의 CSR Read/Write 동작을 설명한다:

2-1) RW: 읽기-쓰기 CSR.

CSR 명령어(csrrw 등)로 임의의 값을 쓸 수 있으며, 이후 읽기 시 동일한 값이 반환된다.(단, 코어의 동작에 의해 값이 바뀌는 경우는 예외)

2-2) RO: 읽기 전용 CSR.

CSR 명령어로 쓰기를 시도하면 illegal instruction 예외가 발생한다.

3) RW CSR의 WLRL 필드(Write-Legal-Read-Legal)에는 지원하지 않는 값을 써도 예외가 발생하지 않는다.

WLRL : CSR 내의 특정 비트필드에 대해 합법적인 값만 쓸 수 있고, 읽을 때는 그 값이정상적으로 보장되어 읽힌다는 의미.

하지만 지원하지 않는 값을 쓰더라도 예외가 발생하지 않음

4) Description 열에는 특정 파라미터의 값에 따라 구현 여부가 달라지는 CSR에 대해 별도 코멘트가 기재되어 있다.

표 58에 명시된 파라미터가 설정되지 않은 경우, 해당 CSR은 구현되지 않는다.

별도의 파라미터 언급이 없는 CSR은 항상 구현된다.

5) 구현되지 않은 CSR을 읽거나 쓰면 illegal instruction 예외가 발생한다.

다음은 표 58이다.

CSR Descriptions

위에서 나열한 각 CSR에 대한 상세 정의이다.

Mode 열은 표 58에 명시된 권한 수준(또는 그보다 높은 권한)에서 각 비트필드의 접근 모드 동작을 정의한다:

1) RO : 읽기 전용 필드., CSR 쓰기 명령의 영향을 받지 않음

이 필드는 고정 값을 반환하거나, 코어의 동작에 따라 결정된 값을 반환한다.

2) RW : 읽기/쓰기 필드.

CSR 쓰기로 저장된 값을 보관하며, 이후 읽기 시 이전에 쓴 값 또는 코어 동작에 의해 결정된 값을 반환한다.

Detailed Description of CSRs

Control and Status Registers — CORE-V CV32E40P User Manual v1.8.3 documentation

각 CSR 레지스터의 설명은 해당 페이지 내에서 추가 확인하자.

나는 CSR 사용하는 코어가 필요한건 아니라 일단 넘어간다.

Exceptions and Interrupts

CV32E40P는 인터럽트 및 예외에 대한 트랩 핸들링을 Privileged Specification에 따라 구현한다.

irq_i[31:16] 인터럽트는 커스텀 확장 이다.

인터럽트나 예외 핸들러로 진입 시, 코어는 현재 프로그램 카운터를 mepc CSR에 저장하고, mstatus.MIE 값을 mstatus.MPIE로 백업한다.

모든 예외 발생 시 코어는 mtvec CSR에 설정된 벡터 테이블의 베이스 주소로 점프한다.

인터럽트는 mtvec.MODE의 값에 따라 direct 모드 또는 vectored 모드로 처리된다.

1) Direct 모드 : mtvec CSR에 설정된 베이스 주소로 점프

2) Vectored 모드 : 베이스 주소 + (인터럽트 ID * 4)로 점프

MRET 명령 실행 시, 코어는 이전에 mepc CSR에 저장된 프로그램 카운터로 복귀하며, mstatus.MPIE의 값을 mstatus.MIE로 복원한다.

벡터 테이블의 베이스 주소는 256바이트(0x100)단위로 정렬되어야 하며,

mtvec CSR에 값을 써서 설정할 수 있다. 자세한 내용은 위의 CSR section을 참고.

코어는 boot_addr_i로 지정된 주소에서 명령어를 들고오기 시작한다.

부팅 주소는 instruction fetch unit 까지의 경로를 최소화하기 위해 레지스터로 전달된다고 가정한다.

Interrupt Interface

다음 표는 인터럽트 인터페이스에 관한 내용이다.

Interrupts

irq_i[31:0] 인터럽트는 mstatus, mie, mip CSR을 통해 제어된다.

CV32E40P는 RISC-V Basic(CLINT) 인터럽트 아키텍처의 커스텀 확장에 따라 mie 및 mip의 상위 16비트(irq_i[31:16])를 커스텀 인터럽트에 사용한다. 리셋 후에는 모든 인터럽트가 비활성화된다. 인터럽트를 활성화하려면 mstatus CSR의 글로벌 인터럽트 활성화(MIE) 비트와 mie CSR의 해당 개별 인터럽트 활성화 비트를 모두 설정해야 한다.

여러 인터럽트가 동시에 발생하면, RISC-V Privileged Specification section 3.1.9에 정의된 고정 우선순위에 따라 처리된다. 가장 높은 우선순위는 가장 높은 ID의 인터럽트(irq_i[31])에 부여되고, Machine Timer Interrupt는 가장 낮은 우선순위를 가진다. 따라서 인터럽트 우선순위는 다음과 같이 높음에서 낮음 순으로 정렬된다: irq_i[31], irq_i[30], ..., irq_i[16], irq_i[11], irq_i[3], irq_i[7].

모든 인터럽트 라인은 level-sensitive 방식이다. 외부 소스에서 인터럽트를 클리어하는 방법은 2가지가 있다:

1) 소프트웨어 기반 매커니즘 : 인터럽트 핸들러가 처리 완료를 인터럽트 소스에 신호(예: 메모리 맵 레지스터를 통해)로 전달하면, 해당 인터럽트 라인이 deassert 된다.

Digital logic에서 assert와 deassert란?

2) 하드웨어 기반 매커니즘 : irq_ack_o 및 irq_id_o[4:0] 신호를 사용해 외부 인터럽트 컨트롤러가 인터럽트 소스를 클리어한다. irq_ack_o는 1 클럭 사이클 동안 펄스를 발생시키며, 이 때 irq_id_o[4:0]은 처리된 인터럽트의 인덱스를 반영한다.

디버그 모드에서는 mstatus.MIE 및 mie CSR의 내용과 상관없이 모든 인터럽트가 무시된다.

Exceptions

CV32E40P는 다음 예외처리 트리거를 발생시킬 수 있다.

불법 명령 예외와 M-모드(machine mode) ECALL 명령 예외는 비활성화할 수 없으며, 항상 활성화되어 있다.

코어는 RISC-V 특권 및 비특권 명세에서 구현된 ISA 기준으로 명시적으로 illegal 하다고 정의된 명령이나, specification에 정의되지 않은 모든 명령에 대해 illegal instruction exception을 발생시킨다.

단, 해당 명령어 인코딩이 특정 파라미터 설정에 따라 CV32E40P의 커스텀 명령어로 구성된 경우는 예외이다.

(예: PULP Custon Extension)

CV32E40P를 예로 들면, 파라미터 FPU가 0으로 설정된 경우에는 Floating point 관련 instruction의 경우 모두 불법 명령 예외를 발생시킨다. 동일하게, COREV_PULP와 CORE_CLUSTER 파라미터가 모두 0으로 설정되어 있을 때는 모든 PULP 확장에 대해서도 같은 규칙이 적용된다. (자세한 내용은 Core Integration에 있다고 한다)

Nested Interrupt / Exception Handling

CV32E40P는 소프트웨어적으로 중첩 인터럽트/예외 처리를 지원한다.

하드웨어는 인터럽트/예외 핸들러로 진입할 때 자동으로 인터럽트를 비활성화한다.

이는, 만약 인터럽트나 예외 처리 도중(소프트웨어가 mepc와 mstatus CSR를 저장하기 전에) 또 다른 인터럽트나 예외가 발생할 경우 해당 CSR값이 덮어써지는 것을 방지하기 위함이다.

필요하다면, 소프트웨어에서 핸들러 내에서 mstatus.MIE를 1로 설정하여 명시적으로 인터럽트를 활성화할 수 있다.

단, 이 동작은 반드시 mepc와 mstatus 값을 저장한 이후에 해야 한다.

중첩 인터럽트의 최대 개수에 제한은 없다.

참고로, mstatus.MIE를 1로 설정하여 인터럽트를 활성화하면, 현재 핸들러가 처리 중일 때 더 낮은 우선순위의 인터럽트에도 인터럽트가 발생할 수 있다.

오직 더 높은 우선순위의 인터럽트만 허용하려면, 핸들러에서 mie 값을 적절히 설정해야 한다.

아래는 소프트웨어적으로 중첩 인터럽트 처리를 수행하는 방법을 나타낸 의사 코드 예시다.

isr_handle_nested_interrupts(id) {
  // Save mpec and mstatus to stack
  mepc_bak = mepc;
  mstatus_bak = mstatus;

  // Save mie to stack (optional)
  mie_bak = mie;

  // Keep lower-priority interrupts disabled (optional)
  mie = mie & ~((1 << (id + 1)) - 1);

  // Re-enable interrupts
  mstatus.MIE = 1;

  // Handle interrupt
  // This code block can be interrupted by other interrupts.
  // ...

  // Restore mstatus (this disables interrupts) and mepc
  mstatus = mstatus_bak;
  mepc = mepc_bak;

  // Restore mie (optional)
  mie = mie_bak;
}

하드웨어에서의 인터럽트/예외 중첩은 지원되지 않는다.

Debug & Trigger

디버그 및 트리거 — CORE-V CV32E40P 사용자 매뉴얼 v1.8.3 documentation

디버그는 따로 다루지 않고 넘어간다.

Pipeline Details

CV32E40P는 4단계 파이프라인되어 있고, in-order로 명령을 처리한다:

1) Instruction Fetch

메모리에서 명령어를 정렬된 Prefetch buffer 를 통해 가져온다.

명령어 측 메모리 시스템이 허용하는 한, 사이클당 1개의 명령어를 가져올 수 있다.

Prefetch Buffer는 32비트 데이터 2개를 저장할 수 있다.

IF 단계에서는 RVC(Compressed) 명령어를 RV32I 기본 명령어로 미리 디코딩한다. (이후 Instruction Fetch section 에서 다룬다)

2) Instruction Decode

가져온 명령어를 디코딩하고 필요한 레지스터 파일 읽기를 수행한다.

점프 명령은 ID 단계에서 처리된다.

3) Execute

명령어를 실제로 실행한다.

EX 단계에서는 ALU, Multiplier, Divider가 포함된다.

분기(Branch)는 EX 단계에서 처리된다.

여러 사이클이 필요한 명령어(Multicycle)는 완료될 때 까지 EX단계를 정지(stall) 시킨다.

ALU, 곱셈기, 나눗셈기 명령어는 EX 단계에서 바로 레지스터 파일에 결과를 기록한다.

로드-스토어 유닛(LSU)의 주소 생성도 EX 단계에 포함된다.

FPU(Floating Point unit)도 FPU_LAT가 0 사이클이거나 1 사이클 초과일 때, EX 단계의 ALU/Mult/Div 레지스터 파일 쓰기 포트를 통해 결과를 기록한다.

FPU_LAT가 1을 초과할 경우, FPU의 쓰기 우선순위가 가장 높아져 충돌 시 EX 단계를 정지시킨다.

단, FPU가 ALU/Mult/Div보다 항상 우선인 것은 아니고 예외가 몇 가지 있다.

예외는 다음과 같다:

1) EX에 다중 사이클 MULH가 있는 경우

2) EX에 정렬되지 않은 LOAD/STORE가 있는 경우

3) EX에 Post-Increment Ld/St가 있는 경우

위 3가지 예외 상황에서는 EX가 stall 되지 않고, FPU 결과는 기억되어 충돌이 해소되는 즉시 레지스터 파일(FPU CSR 포함)에 기록된다.

4) WriteBack

LSU의 결과(Load 결과)를 레지스터 파일에 기록한다.

FPU 결과도 FPU_*_LAT 가 1사이클일 때는 WB 단계에서 기록된다.

이 때 레지스터파일의 LSU 쓰기 포트를 재사용하며, 충돌 시에는 LSU가 FPU보다 우선권을 가진다.

Hazards

ID-EX 사이에는 포워딩 경로가 존재한다. 

이로 인해 Write-through 방식의 레지스터파일이 필요하지 않으며, 해당 연산의 결과를 바로 다음 명령에서 사용할 경우에도 사이클 패널티 없이 즉시 사용 가능하다.

0사이클 레이턴시의 FPU 명령도 마찬가지다.

하지만, 다음과 같은 상황에서 1사이클 패널티가 발생한다:

1) 로드 데이터 해저드 : load 명령 바로 다음 명령이 그 결과를 사용할 때

2) Jalr 데이터 해저드 : jalr 명령이 바로 직전 명령 결과에 의존할 때

3) FPU 데이터 해저드 : (FPU_*_LAT = 1) FPU 명령(단, FDIV, FSQRT 제외) 바로 다음 명령이 그 결과를 사용할 때

아래 상황에서는 1사이클 초과 패널티가 발생한다:

1) FPU 데이터 해저드 : (FPU_*_LAT > 1) FPU 명령(단, FDIV, FSQRT 제외) 바로 다음 명령이 그 결과를 사용할 때, FPU_*_LAT 만큼의 사이클 패널티 발생

2) FDIV/FSQRT 데이터 해저드 : FDIV/FSQRT 명령 바로 다음 명령이 그 결과를 사용할 때

이러한 사이클 패널티는 컴파일러가 데이터 해저드를 유발하는 명령 사이에 다른 명령을 삽입하여 숨길 수 있다.

Single- and Multi-Cycle Instructions

표 63은 명령어 타입별 사이클 수를 보여준다.

일부 명령어는 실행 시간이 가변적이며, 이 경우 범위로 표시된다.

예를 들어 1..32는 해당 명령어가 최소 1사이클, 최대 32사이클이 소요됨을 의미한다.

표에 명시된 사이클 수는 명령어 측 인터페이스(instruction-side interface)와 데이터 측 메모리 인터페이스(data-side memory interface)에 정지(stall)가 전혀 없는 경우를 가정한 값이다.

1번 파일에서 이어서 본다.

CORE-V Instruction Set Custom Extensions

CV32E40P는 다음과 같은 CORE-V ISA X 커스텀 확장을 지원하며, COREV_PULP == 1로 설정 시 활성화 가능하다.

• Post-Increment Load & Store(후위 증가 로드 및 스토어) : 툴체인에서 -march=rv32i*_xcvmem 옵션으로 활성
• Hardware Loop 확장 : 툴체인에서 -march=rv32i*xcvhwlp 옵션으로 활성
• ALU 확장(3가지 서브 확장으로 구성)
  • 비트 조작 명령어(bit manipulation) : -march=rv32i*xcvbitmanip
  • 기타 ALU 명령어(miscellaneous ALU) : -march=rv32i*_xcvalu
  • 즉시 분기 명령어(immediate branch) : -march=rv32i*xcvbi
• Multiply-Accumulate(곱셈-누산) 확장 : -march=rv32i*_xcvmac 옵션으로 활성
• SIMD(Single Instruction Multiple Data) 확장 : -march=rv32i*_xcvsimd 옵션으로 활성

추가로 event load 명령어(cv.elw)는 COREV_CLUSTER == 1로 설정 시 지원, -march=rv32i*xcvelw 옵션으로 활성

명시되지 않은 경우, 모든 operand 는 signed 취급, immediate 값은 sign-extension(부호 확장) 됨.

이런 명령어를 사용하려면 반드시 CORE-V GCC 또는 Clang/LLVM 컴파일러로 소프트웨어 빌드가 필요. (커스텀 툴체인)

Pseudo instructions

여기에서는 일부 CORE-V 의사 명령어에 대한 문서도 포함된다. 의사 명령은 기본 명령과 유사하지만, 실제로는 기본 명령어를 생성하지 않고 어셈블러에 제어 정보를 제공하는 명령어로, 어셈블러에서 구현된다. (예시 : mv x1 x1 --> addi x1 x1 zero)

이로 인해 프로그래밍할 때 프로그래머의 의도가 더 명확하게 드러나므로, 코딩이 더 쉬워진다.

예를 들어, 16b * 16b 곱셈 의사 명령어가 있다. 이는 나중에 명령어를 설명할 때 나온다.

Post-Increment Load & Store Instructions and Register-Register Load & Store Instructions

후위 증가 load 및 store 명령어는 메모리 접근과 동시에 접근에 사용된 주소를 증가시키는 동작을 수행한다.

이는 후위 증가(i++) 방식으로, 메모리 접근에는 증가 전의 기본 주소가 사용되며, 증가된 주소 값이 레지스터 파일에 다시 저장된다.

이 명령어에는 immediate 값을 오프셋으로 사용하는 버전과,

레지스터를 오프셋으로 사용하는 버전이 있다.

기본 주소(base address)는 항상 레지스터에서 가져온다. 이러한 커스텀 post-increment load & store 명령어와 register-register load & store 명령어는 COREV_PULP == 1로 설정된 경우에만 지원된다.

Load 명령

같은 레지스터가 주소와 목적지 동일하게 사용되는 경우, (rd == rs1) 증가된 주소값보다 로드된 데이터가 해당 레지스터에 우선적으로 기록된다.

Store 명령

Load Encoding

Store Encoding

Event Load Instruction

event load 명령어(cv.elw)는 COREV_CLUSTER == 1인 경우에만 지원된다

event load 명령어는 1 워드(32b) 로드를 수행하며,

PULP Cluster Extension에서 설명(나중에 나온다)과 같이 CV32E40P를 sleep 상태로 진입시키는 동작을 유발할 수 있다.

Encoding

Hardware Loops

루프 본문에 진입하기 전에 반드시 루프를 세팅해야 한다.

이를 위한 2가지 방법이 있다:

1) 루프의 시작 주소, 종료 주소, 반복 횟수를 각각 따로 설정하는 long 명령

2) 모든 설정을 한 번에 처리하는 short 명령

숏 명령은 루프에 포함되는 명령어 개수(루프 길이) 제한이 있으며, 루프는 반드시 setup 명령어 바로 다음 명령어에서 시작해야 한다.

시작/종료 주소 제약 때문에 주소의 하위 2비트는 0으로 고정된다.

cv.start 와 cv.end 명령어를 사용할 때 rs1의 하위 2비트는 무시된다.

하드웨어 루프 명령어 및 관련 CSR은 COREV_PULP == 1로 설정된 경우에만 지원된다.

하드웨어 루프 제약에 대한 자세한 내용은 앞서 나온 CORE-V Hardware Loop feature 를 참고하자.

아래 표에서, 어셈블리에서 L은 0또는 1로 표기된다.

또한, uimmL = unsigned immediate for Load /

uimmS = unsigned immediate for Store

Encoding

ALU

CV32E40P는 고급 ALU 연산을 지원해 기본 명령어 집합에 지정된 여러 명령어들을 단일 명령어로 수행할 수 있게 하여 코어의 효율성을 높인다. 예를 들어, 8비트 및 16비트 피연산자에 대한 zero/sign extension, 간단한 비트 조작/카운팅 명령어, min/max/avg 명령이 그에 포함된다. ALU는 또한 saturating(포화), clipping(클리핑), normalization(정규화) 연산을 지원하여 고정소수점 연산을 더 효율적으로 만든다.

커스텀 ALU 확장은 COREV_PULP == 1일 때만 지원된다.

ALU에 대한 커스텀 확장 기능들은 여러 하위 그룹으로 나뉜다:

1) 비트 조작 명령어 : 단일 비트 혹은 워드 내 비트 그룹을 다루는 데 유용함. 따로 Document 참고

2) 일반 ALU 명령어 : 자주 사용되는 시퀀스를 하나의 명령어로 결합하여 해당 시퀀스를 사용하는 작은 커널의 성능을 향상시킨다. General ALU operation Document 참고

3) 즉시값(상수) 분기 명령어 : 분기 여부를 결정하기 전에 레지스터와 Immediate 값을 비교하는 데 사용된다. Immediate Branching operations Document 참고

Extract, Insert, Clear, Set 명령어는 다음과 같은 의미를 가짐.

Extract : ls3+1 or rs2[9:5]+1 비트 만큼을 위치 ls2 또는 rs2[4:0]에서 추출해 부호 확장

Insert : ls3+1 or rs2[9:5]+1 비트 만큼을 위치 ls2 또는 rs2[4:0]에 삽입.

Clear : ls3+1 or rs2[9:5]+1 비트 만큼을 위치 ls2 또는 rs2[4:0]에서 0으로 만듦.

Set : ls3+1 or rs2[9:5]+1 비트 만큼을 위치 ls2 또는 rs2[4:0]에서 1로 만듦.

Bit Reverse Instruction

이 장에서는 cv.bitrev 명령어를 비트 조작 관점에서 설명하며, FFT에서의 응용은 다루지 않는다.

비트 반전 명령어는 1비트, 2비트, 3비트 단위로 그룹을 지정해 비트를 반전시킨다.

비트 그룹의 크기는 ls3 값에 따라 다음과 같이 설정된다:

0 : 1비트 단위 반전(ex: 32비트 전체를 Reverse)

1 : 2비트 단위 반전(ex: [1,0], [3,2], ... 식으로 짝을 이뤄 각 짝을 뒤집음)

2 : 3비트 단위 반전(ex: [2,1,0], [5,4,3], ... 식으로 세 비트씩 묶어 뒤집음)

반전할 비트의 개수는 ls2 값으로 제어.

ls2 값만큼 입력 값을 왼쪽으로 시프트해 입력값의 상위 ls2 비트는 버려지고, 하위 32- ls2 비트만 반전.

예시)

cv.bitrev x18, x20, 0, 4 (groups of 1 bit; radix-2)

in:    0xC64A5933 11000110010010100101100100110011
shift: 0x64A59330 01100100101001011001001100110000
out:   0x0CC9A526 00001100110010011010010100100110

Swap pattern:
A B C D E F G H . . . . . . . . . . . . . . . . . . . . . . . .
0 1 1 0 0 1 0 0 1 0 1 0 0 1 0 1 1 0 0 1 0 0 1 1 0 0 1 1 0 0 0 0
. . . . . . . . . . . . . . . . . . . . . . . . H G F E D C B A
0 0 0 0 1 1 0 0 1 1 0 0 1 0 0 1 1 0 1 0 0 1 0 1 0 0 1 0 0 1 1 0

시프트하고 반전된 값이 나온다. (ls3 = 0)

Bit Manipulation operations

Bit Manipulation Encoding

General ALU operations

COREV_PULP에서 사용하는 ALU Extension 명령어들이다.

인코딩은 R type과 동일하게 동작한다.

다른 인코딩은 하나밖에 없다.

Immediate Branching operations

얘는 I type과 다르게 Immediate 이 난장판이다.

B-type과 닮았다.

Imm : {ins[31], ins[7], ins[30:25], ins[11:8]}

Multiply-Accumulate

곱 누산기 및 16비트 곱셈에 대한 확장도 지원한다.

곱셈 후 결과 시프트 옵션도 제공한다.

물론 COREV_PULP == 1일 때만 지원된다.

MAC : rs1 + (rs2 * rs3)

16b * 16b Multiplication Operations

16b * 16b Multiplication pseudo-instructions

16b * 16b MAC operations

32b * 32b MAC operations

Encoding(16b)

Encoding(32b)

SIMD

SIMD는 여러 서브워드(8b, 16b) 요소에 대해 동시에 연산을 수행한다.

이것 또한 COREV_PULP == 1일 때 지원된다.

예시 : 32비트 데이터를 4개의 8비트로 나눠 한번에 4개의 덧셈/곱셈 수행 등등..

2가지 방식으로 명령어가 사용됨.

1) 8비트(.b)

2) 16비트(.h)

모든 연산 결과는 원래 RISC-V Arithmetic 연산과 동일하게 지정된 비트폭으로 마스킹되어 저장됨. 즉, overflow 없음

오퍼랜드 동작 모드 3가지

1) 벡터-벡터

rs1, rs2 모두 벡터 취급

cv.add.h x3, x2, x1

x3[31:16] = x2[31:16] + x1[31:16]

x3[15:0] = x2[15:0] + x1[15:0]

2)벡터-스칼라(레지스터)

rs1 : 벡터, rs2 : 스칼라로 취급

rs2의 LSB가 전체 벡터에 복제되어 연산

cv.add.sc.h x3, x2, x1

x3[31:16] = x2[31:16] + x1[15:0]

x3[15:0] = x2[15:0] + x1[15:0]

3) 벡터-스칼라(상수값)

rs1 : 벡터, Imm(6비트 값)

Imm6 값이 확장(extension)되어 전체 벡터에 복제

cv.add.sci.h x3, x2, -22(0xFFEA)

x3[31:16] = x2[31:16] + 0xFFEA

x3[15:0] = x2[15:0] + 0xFFEA

SIMD 비트 조작 명령에서 Imm6은 항상 Zext 됨

실제 바이트나 워드에 매핑되는 인덱스 범위:

16비트 연산시 : i = 0 [15:0], i = 1 [31:16]

8비트 연산시 : i = 0 [7:0], i = 1 [15:8], i = 2 [23:16], i = 3 [31:24]

Imm6의 각 비트는 l5, l4, ..., l0로 사용

SIMD ALU 연산

SIMD Bit Manipulation operations

SIMD 점 곱 연산

SIMD Shuffle & Pack 연산

SIMD ALU 인코딩

[25:20]이 Imm6 필드로 사용됨(자세한건 링크 참고 CORE-V Instruction Set Custom Extensions — CORE-V CV32E40P User Manual v1.8.3 documentation)

SIMD 비교 연산

SIMD 비교는 선택 모드에 따라 개별 바이트 또는 하프워드 단위로 수행됨.

만약 비교 결과가 참이라면, 해당 바이트/하프워드의 모든 비트가 1로 세팅됨.

만약 비교 결과가 거짓이라면, 모든 비트가 0으로 설정됨.

기본 모드(.sc, .sci가 없는 경우)에서는 첫 번째 operand의 최하위 바이트/하프워드와 두 번째 operand의 최하위 바이트/하프워드를 비교하고, 그 다음 바이트/하프워드끼리 순차적으로 비교한다.

모드가 스칼라 복제(.sc)로 설정된경우, 두 번째 operand의 최하위 바이트/하프워드만을 항상 비교에 사용하므로 벡터 비교 대신 스칼라 비교가 수행된다.

상수 스칼라 복제 모드(.sci)에서는 명령어에 주어진 상수값이 비교에 사용된다.

SIMD 비교 인코딩

25:20은 Imm6으로도 사용된다.

SIMD Complex-number operations

SIMD 복소수 연산은 Packed-SIMD 확장을 이용해 복소수를 표현하는 추가 명령어다. 이 확장은 오직 하프워드 단위(16비트)만을 사용하며, 오직 레지스터 operand 만 지원한다.

복소수 C = {Re, Im}은 두 개의 16비트 signed로 이루어진 벡터로 표현된다.

C[0]은 실수부[15:0], C[1]은 허수부[31:16] 이다.

이러한 연산에는 -j로 회전하는 복소수 뺄셈, 켤레 복소수 연산, 복소수 곱셈, 복소수 덧셈/뺄셈이 포함된다.

복소수 곱셈은 두 개의 명령어로 분리되어 수행된다. 하나는 실수부 계산, 다른 하나는 허수부 계산이다.

다른 SIMD 명령어와 마찬가지로 플래그가 설정되지 않고 CSR 레지스터도 변경되지 않는다.

Overflow 나 carry가 발생하지 않으며 모든 연산 결과는 16비트 단위 마스킹되어 저장된다.

SIMD Complex-number Encoding

RISC-V 코어 공부를 위해 공식 Document, User manual를 공부해 본다.

현 시점(2025/05/20) 버전은 v1.8.3이 최신 버전이다.

OpenHW Group CV32E40P User Manual — CORE-V CV32E40P User Manual v1.8.3 documentation

Introduction

CV32E40P(전 RI5CY)는 4단계 파이프라인이 적용된 in-order RISC-V 코어다. 

특징은 다음과 같다.

1. ISA(Instruction set architecture)가 일반적인 RISC-V ISA(RV32IMC)가 아닌 추가적인 Extension을 제공한다.

1.1 하드웨어 루프(하드웨어 내에서 루프 명령(for, while 등) 최적화 블록 2개 제공)

1.2 Post-increment load / store instruction --> 이건 아직 뭔지 잘 모르겠다.

1.3 additional ALU instructions : 기존 RV32I의 ISA가 아닌 다른 작업을 ALU에서 수행할 수 있는 듯 하다.

1.4 SIMD instruction(Single instruction, multiple data) 지원 : 코어 내부에서 SIMD가 어떻게 동작하는지 잘 모르기 때문에 차근 차근 보면서 익혀야 할 듯 하다.

그 외에 코어 내부는 다음과 같은 구조를 가지고 있다고 한다.

Bus Interface

모든 코어에서 마찬가지로, 코어와 다른 periphreal들을 연결하기 위해 버스가 필요하다. 자주 사용되는 버스는 아무래도 AMBA AXI, AHB와 같은 고성능 버스들이 있을 텐데, 특이하게도 OBI(Open bus interface)를 사용한다. 이는 Instruction Fetch와 Load-store unit에서 사용된다고 한다. 짧게 짚고 넘어가면, 포트도 굉장히 적고, 작동 방식도 간단하다.

req 신호 전송 --> req, gnt 모두 high일 경우 주소 송/수신 동작(Address channel, A channel)

rvalid 신호 전송 --> rvalid, rready 모두 high일 경우 데이터 송/수신 동작(Response channel, R channel)

결론은, 주소를 보내는 채널, 데이터를 보내는 채널이 따로 관리된다.

req, rvalid와 같은 Trigger들의 역할이 중요하다.

Standard Compliance

CV32E40P는 RISC-V 표준을 준수한다. User-level ISA(I, C, M, ...), Privileged(CSR, ...), 그리고 뭔지는 모르겠지만 External Debug support 또한 지원한다고 한다.

아래 그림의 확장(Extension)은 해당 버전 내용을 지원한다는 의미이다. 연산은 C, M, F가 있고 그 외의 제어에 관련된 부분은 Zi 가 앞에 붙은 부분을 참고하자. 아래의 custom ISA Extension은 PULP 사의 커스텀 instruction들을 적용했다 라는 뜻이다. Base 코어가 필요한 경우에는 해당 Extension들은 끈 상태로 사용해도 무방하다. 물론 Floating point unit 포함이다.

아래는 잡다한 이야기이므로 다음 챕터로 넘어가겠다.

Core Integration

코드 리뷰를 하며 진행되는 내용인 듯 하다.

"cv32e40p_top" 내부에 cv32e40p_core이 인스턴스화 되어 있고, fpnew_top(floating point unit) 또한 top 구조 안에 인스턴스화 되어 있다. 쉽게 F 확장을 켜고 끌 수 있는 구조로 이루어져 있다.

Top 파일에서 사용하는 파라미터는 다음과 같다.

Interfaces

Top 파일에서 사용되는 I/O 신호들이다.

Clock Gating Cell

CV32E40P 칩은 클럭 셀을 필요로 한다. 이 셀은 보통 target technology(40nm, 28nm 등등)에 맞게 선택되기 때문에 RTL 디자인은 제공되지 않는다. 시뮬레이션 전용 버전은 cv32e40p_sim_clock_gate.sv 파일로 제공된다. 이 파일은 cv32e40p_clock_gate라 불리는 모듈을 포함하는데, 다음 포트들을 포함한다.

• clk_i : 클럭 입력
• en_i : 클럭 활성화 입력
• scan_cg_en_i : 클럭 게이트 활성화 입력(클럭을 강제 활성화)
• clk_o : 클럭 출력

CV32E40P에는 클럭 게이팅 셀이 cv32e40p_sleep_unit.sv, cv32e40p_top.sv에 사용된다.

또한 cv32e40p_sim_clock_gate.sv 파일은 합성용으로 만든 것이 아니므로 적절하게 만들어서 사용을 하라고 한다.

Synthesis guidelines

CV32E40P는 완전히 합성 가능하다. 주로 ASIC 디자인으로 설계되었지만 FPGA 또한 지원한다.

모든 코어 파일은 rtl 폴더의 rtl/include에 있다.

FPU 관련 파일은 rtl/vendor/pulp_platform_common_cells, rtl/vendor/pulp_platform_fpnew, rtl/vendor/pulp_platform_fpu_div_sqrt, rtl_vendor_opene906에 존재한다.

cv32e40p_fpu_manifest.flist 는 모든 요구되는 파일의 목록이다.

사용자는 이용하는 공정의 클럭 게이팅 셀 기능을 선언해 사용해야 한다. 기본 제공된 파일은 시뮬레이션을 위한 용도일 뿐이다.

Synthesis constraints 예제는 constraints/cv32e40p_core.sdc 파일에 선언되어 있다.

ASIC Synthesis

CV32E40P는 ASIC 합성을 지원한다. 전체 설계는 완전히 동기적이고 상승 엣지에 트리거되는 FF(Flip-Flop)이다.

OBI 인터페이스를 통해 32KB의 메모리가 연결되었고, 100Mhz로 합성되었다. DFT(Design for test) 스캔 체인이 구현되었고, 클럭 트리 합성(CTS)까지 포함한 백엔드 구현이 되어 있다. 그러나 메모리 BIST(Built in self test)는 삽입되지 않았고, DFT를 위한 스캔 압축은 적용되지 않았다.

또한, 클럭 게이팅 셀에서 설명된 바와 같이 이용 공정에 맞춘 구현이 제공되었다.

다음 표는 COREV_CLUSTER가 항상 0인 조건 하에서, 다양한 상위 파라미터 설정에 대해 CV32E40P의 크기를 NAND 게이트를 기준으로 환산한 kGE(kilo gate equivalent) 단위로 나타낸 것이다.

FPGA Synthesis

Vivado와 Quartus Prime Pro를 통해 합성에 성공했다.

Quartus에서는 systemverilog 파일 중 몇개가 파싱이 되지 않는다.

또한 외부 클럭을 임의로 지정해 줘야 한다.

Synthesizing with the FPU

기본적으로 FPU의 파이프라인은 완전히 조합 논리 회로로 구성되어 있다. (FPU_*_LAT = 0인 경우)

이 경우, FPU 명령어의 레이턴시는 일반적인 ALU 연산과 동일하다.(FDIV, FSQRT 등의 다중 연산을 제외한다면)

그러나 FPU 연산은 ALU연산보다 훨씬 복잡하기 때문에, FPU가 활성화된 경우 도달 가능한 최대 주파수는 ALU만 사용하는 경우보다 훨씬 낮아진다.

이러한 구조는 낮은 클럭 속도를 사용하는 시스템에서는 문제가 없을 수 있지만, 빠른 클럭 속도를 가져야 하는 경우에는 FPU에 몇 개의 파이프라인 레지스터를 삽입할 지 결정할 수 있다. 이는 FPU_*_LAT 라는 CV32E40P 파라미터를 조정해 목표 주파수에 맞춰 설정함으로 가능하다.

단, 파이프라인 레지스터를 추가하게 되면 FPU 명령어의 레이턴시가 증가하게 되어, 부동소수점 연산을 많이 사용하는 애플리케이션에서는 성능 저하가 발생할 수 있다.

이러한 파이프라인 레지스터는 모두 FPU 파이프라인의 끝단에 추가되며, 모든 연산자는 그 앞에 위치한다. 최적의 주파수를 달성하려면 구현 툴에서 자동 리타이밍(auto retiming) 명령을 사용하는 것이 필수다. 예를 들어, Design compiler 에서는 다음 명령어로 설정할 수 있다:

set_optimize_registers true -designs [get_object_name [get_designs “*cv32e40p_fp_wrapper*”]]

FPU

RV32F 확장은 부동소수점 지원 ISA이다. 이는 IEEE-754 단일 정밀도 부동소수점을 준수하며 cv32e40p_top의 파라미터 FPU를 1로 설정함으로 사용할 수 있다. 이는 디코더를 활성화함과 동시에 FPU 유닛을 즉시 인스턴스화한다. FPU는 Openhw group의 cvfpu 유닛을 사용하였으며 github page는 다음과 같다: https://github.com/openhwgroup/cvfpu

CVFPU Parameters

CVFPU IP의 파라미터에 대해 알아본다.

FP Register File

32개의 부동소수점 레지스터, f0-f31이 따로 인스턴스화됨. 기본 동작은 파라미터 ZFINX = 1로 함에 따라 바꿀 수 있는데, 이 경우 전용 레지스터 파일은 포함되지 않고 범용목적 레지스터 파일이 부동소수점 피연산자를 저장하는데 사용된다.

( ZFINX = 1 : 범용 GPR 사용, ZFINX = 0 : f0-f31 사용)

FP CSR

부동소수점 확장을 사용할 때 표준은 부동소수점 상태 및 제어 레지스터(fcsr)의 존재를 명시한다. 이 레지스터는 마지막으로 리셋된 이후 발생한 예외와 현재의 반올림 모드를 포함한다.

부동소수점 누적 예외(fflags)와 부동소수점 동적 반올림 모드(frm)는 직접 접근할 수도 있고, fcsr를 통해서도 접근 가능하다.

fcsr는 fflags, frm이 두 레지스터에 매핑되어 있음.

(fcsr(32b) = {fflags(5b), frm(3b), .. reserved}

FPU Sleeping mode

전력 소모를 줄이기 위해, FP 명령어가 실행되지 않는 경우에 FPU 클럭이 중단됨. 이는 분리된 클럭 게이팅 셀에서 신호를 보냄으로서 조절됨. 이 셀의 활성화 신호는 코어의 apu_req_o와 apu_busy_o 의 출력에 따라 결정됨(둘 다 0이면 클럭 자동 차단)

Remainder for programmers

Privileged Architecture 명세에서 언급한것처럼, FP 명령어를 사용하려면 mstatus.FS 필드를 initial로 설정해야 함.

만약 mstatus.FS가 OFF(리셋 시 기본값)인 경우, 부동소수점 상태(F 레지스터나 F CSR)를 읽거나 쓰려는 모든 명령은 불법 명령 예외를 발생시킴.

인터럽트 또는 컨텍스트 스위칭이 발생하면, mstatus.SD를 읽어 부동소수점 상태가 변경되었는지 확인해야 함.

이후 실행되는 프로그램(인터럽트 루틴 등)이 FP 명령을 사용할 예정이고, mstatus.SD = 1(FS = Dirty)면 전체 부동소수점 상태(F 레지스터와 F CSR)를 메모리에 저장하고, mstatus.FS를 clean으로 설정해야 함. 

중단된 프로그램으로 복귀할 때, mstatus.FS가 clean이면 전체 fp 상태를 복원해야 함.

• mstatus.FS = Off: 부동소수점 명령 → 예외 발생
• mstatus.FS = Initial 또는 Clean: FP 명령 사용 가능
• 컨텍스트 스위치 시 mstatus.SD = 1(Dirty): FP 상태 저장 필요
• 복귀 시 mstatus.FS = Clean: FP 상태 복원 필요

Verification

검증 환경(테스트벤치, 테스트케이스 ..)는 openhwgroup/core-v-verif: Functional verification project for the CORE-V family of RISC-V cores. 에 있다. 

OpenHW Group CORE-V Verification Strategy — CORE-V Verification Strategy documentation 를 보고 하는 것을 추천한다고 한다.

테스트 환경에 대한 이야기인데, 순정 코어는 이미 Verified 되었다는 가정 하에 본 챕터는 넘어간다.

CORE-V Hardware Loop feature

작은 루프들의 효율을 상승시키기 위해, CV32E40P는 하드웨어 루프를 지원한다. COREV_PULP 파라미터를 활성화함으로 사용 가능하다. 하드웨어 루프는 분기 오버헤드나 카운터 업데이트를 하지 않고 코드 조각을 여러번 반복시킬 수 있다. 하드웨어 루프는 루프의 첫 번째 명령어로 점프하는 0-stall 사이클을 포함한다.

하드웨어 루프는 첫 번째 주소로 정의되며(루프의 첫 번째 명령어를 가리킴), 그것의 마지막 주소(루프에서 마지막으로 실행되는 명령어 바로 다음 명령어를 가리킴), 그리고 카운터는 루프 바디의 마지막 명령어가 실행되면 매번 줄어든다.

CV32E40P는 두개의 하드웨어 루프 레지스터를 포함하며, nested(중첩된) 하드웨어 루프를 지원하며, CSR 주소에 매핑된 분리된 3개의 플립 플롭 값(시작 주소, 종료 주소, 카운터)을 저장할 수 있다. 루프 0은 높은 우선순위를 가리키고(내부 루프), 루프 1은 중첩된 루프를 의미한다(외부 루프).

Hardware loop constraints

다음의 제약 조건들은 모든 툴체인 컴파일러나 직접 작성된 어셈블리 코드에서  반드시 준수되어야 한다. 이 제약을 위반하더라도 하드웨어 예외 처리가 발생하지 않으며 동작이 정의되지 않는다.

프로그램을 검증용 레퍼런스 모델이나 가상 플랫폼 Instruction Set Simulator 에서 실행할 때 이러한 소프트웨어 예외를 가능한 한 빨리 감지하기 위해, 해당 모델/시뮬레이션 플랫폼은 하드웨어 루프 제약 위반에 대해 의미있는 메세지(오류)를 발생해야 한다.

이러한 제약 확인은 하드웨어 루프 본문에 포함된 각 명령어에 대해서만 수행될 수 있다.

즉, lp.startX <= PC <= lp.endX - 4 이고, lp.countX > 0 일때만 해당된다.

하드웨어 루프의 제약 조건:

• HWLoop의 starti, endi, setupi 및 setup 명령어 주소는 모두 32비트 정렬되어야 한다.(PC 기준 명령어)
• HWLoop 본문의 시작/종료 주소도 32비트 정렬되어야 한다.
• 종료 주소는 시작 주소보다 반드시 커야 한다.
• HWLoop #0(및 #1)의 카운터가 0이 아닐 때는 각각의 시작/종료 "주소"를 변경하면 안 된다.
• HWLoop의 종료 주소는 본문 내에서 마지막으로 실행되는 명령어 바로 다음 명령어를 가리켜야 한다.
• HWLoop 본문에는 최소 3개의 명령어가 포함되어야 한다.
• 두 개의 루프가 중첩된 경우에는 가장 안쪽(#0) 루프의 마지막 명령어와 가장 바깥쪽(#1) 루프의 마지막 명령어 사이에 최소 1개의 명령어가 있어야 한다. 다시 말해, 바깥쪽 루프의 종료 주소는 안쪽 루프의 종료 주소보다 최소 8바이트(명령어 2개) 이상 커야 한다.(HWLoop[1].endaddr >= HWLoop[0].endaddr + 8)
  아래 예시에서 첫 번째 "addi %[j], %[j], 2" 명령어는 위 제약 조건 때문에 추가된 것이다. 제약이 없었다면 "addi %[j], %[j], 4" 한 줄로 더 간단히 코드를 작성할 수 있지만, 제약을 지키기 위해 둘로 나누었다.
• HWLoop는 항상 루프 시작 위치에서 진입해야 하며, HWLoop 본문 내부로 점프해서 진입하면 안된다.
• HWLoop #0(또는 #1) 본문 내부에서 각각의 CSR은 수정해서는 안 된다.(외부에서만 Control and status register 변경 가능)
• HWLoop 본문 내에는 점프 또는 분기 명령어가 허용되지 않는다.
• HWLoop 본문 내에는 메모리 순서 명령어(fence, fence.i)가 허용되지 않는다.
• HWLoop 본문 내에는 특권 명령어(Privileged instruction)는 사용할 수 없지만, ebreak와 ecall은 예외로 허용된다.

이러한 제약 위반 시 하드웨어 예외를 발생시키지 않는 이유는, 제약 체크를 위해서 32비트 덧셈기/뺄셈기 등의 추가적인 자원이 필요하기 때문이며, 이러한 자원은 면적/전력 소모 면에서 비용이 크기 때문이다. 이런 상황은 원래 발생하지 않아야 하므로, CV32E40P의 면적과 전력 소모를 최소화하기 위한 아키텍쳐적 선택이다.

루프 종료 라벨(end-of-loop label)을 루프 본문의 마지막 명령어 다음 명령어에 지정하는 이유는, 컴파일러 최적화(basic block 관리)를 매우 단순화할 수 있기 때문이다.

하드웨어 루프를 사용하기 위해서는 컴파일러가 루프를 미리 cv.start/i, cv.,end/i, cv.count/i 또는 cv.setup/i 명령어로 설정해야 한다. 컴파일러는 어셈블리 없이도 가능한 경우 자동으로 HWLoop를 사용한다.

디버깅, 인터럽트, 컨텍스트 스위치 상황에서는 하드웨어 루프 레지스터들이 CSR의 커스텀 읽기 전용 주소 공간에 매핑된다. 이 값을 읽을 때는 csrr 명령어를 사용하고, 쓸 때는 레지스터 기반 하드웨어 루프 명령어를 사용해야 한다.

csrw 명령어로 하드웨어 루프 레지스터를 쓰려고 하면 illegal instruction exception이 발생한다. 이는 이후 csr 섹션에서 csr 하드웨어 루프 레지스터를 추가 설명한다.

아래는 배열 덧셈을 계산하는 중첩된 HWLoop 어셈블리 코드 예시이다.

asm volatile (
    "add %[i],x0, x0;"
    "add %[j],x0, x0;"
    ".balign 4;"
    "cv.starti 1, start1;"
    "cv.endi   1, end1;"
    "cv.count  1, %[N];"
    "any instructions here"
    ".balign 4;"
    "cv.starti 0, start0;"
    "cv.endi   0, end0;"
    "any instructions here"
    ".balign 4;"
    ".option norvc;"
    "start1:;"
    "    cv.count 0, %[N];"
    "    start0:;"
    "        addi %[i], %[i], 1;"
    "        addi %[i], %[i], 1;"
    "        addi %[i], %[i], 1;"
    "    end0:;"
    "    addi %[j], %[j], 2;"
    "    addi %[j], %[j], 2;"
    "end1:;"
    : [i] "+r" (i), [j] "+r" (j)
    : [N] "r" (10)
);

HWLoop 기능은 lp.countX > 0이 되는 즉시 활성화되므로, 예기치 않은 동작을 방지하려면 lp.startX 와 lp.endX를 반드시 lp.countX보다 먼저 설정해야 한다. 

루프 본문에 최대 30개의 명령어가 포함된 HWLoop의 경우, 세 개의 HWLoop CSR을 한 사이클에 모두 갱신하는 cv.setup 명령어를 사용하는 것이 항상 더 좋다.

HWLoop의 시작 시점에서 레지스터 %[i], %[j]는 0이다.

가장 안쪽 루프(start0 to end0 - 4까지)는 %[i]에 1을 3번 더하는 작업을 수행하며, 이 루프는 총 10 * 10 = 100번 실행된다.

가장 바깥쪽 루프(start1 to end1 - 4까지)는 안쪽 루프를 10번 반복 실행하며, 그 과정에서 %[j]에 2를 두번 더한다.(+4)

루프가 모두 끝난 뒤 레지스터 %[i] = 300, %[j] = 40 이다.

Hardware loops impact on application, exception handlers and debug program

Application and ebreak/ecall exception handlers

애플리케이션에서 ebreak 또는 ecall 명령어를 사용할 때, 이 명령어가 HWLoop의 마지막 명령어인 경우에는 해당 예외 핸들러에서 특별히 신경 써야 한다. 해당 핸들러에서는 MEPC(Machine exception program counter)와 lp.countX CSR의 업데이트를 반드시 처리해야 한다. 그렇지 않으면 HWLoop가 조기 종료될 수 있다.

핸들러 마지막(컨텍스트/CSR 복원 후)에는 다음 우선순위대로 스마트한 코드 조각이 추가되어야 한다:

1. MEPC = lp.end0 - 4 && lp.count0 > 1

MEPC를 lp.start0로 설정하고, lp.count0을 1 감소한다.

2. MEPC = lp.end0 - 4 && lp.count0 = 1

MEPC를 4 증가시키고, lp.count0을 1 감소한다.

3. MEPC = lpend1 - 4 && lp.count1 > 1

MEPC를 lp.start1로 설정하고, lpcount1을 1 감소한다.

4. MEPC = lp.end1 - 4 && lp.count1 = 1

MEPC를 4 증가시키고, lp.count1을 1 감소한다.

5. (lp.start0 <= MEPC < lp.end0 - 4) || (lp.start1 <= MEPC < lp.end1 - 4)

MEPC를 4 증가시킨다.

6. MEPC 위치의 명령어가 ecall 또는 ebreak

MEPC를 4 증가시킨다.

7. MEPC 위치의 명령어가 c.ebreak(compressed ebreak)인 경우

MEPC를 2 증가시킨다.

마지막 두 경우는 ebreak/ecall이 HWLoop 내부가 아닌 일반 상황에서 해당된다.

Interrupt handlers

HWLoop의 마지막 명령어에서 인터럽트가 발생하면, 해당 명령어의 실행은 취소되고 그 주소가 MEPC에 저장된다.

인터럽트 핸들러에서 복귀할 때, 해당 명령어의 실행이 다시 재개된다.

이 경우, MEPC와 lp.countX 업데이트에 대해 별도 특별한 처리는 필요 없다.(HWLoop CSRs 저장/복원 외에는)

인터럽트 핸들러 이후, 마지막 HWLoop 명령이 정상적으로 재실행되도록 설계되어 있기 때문이다.

illegal instruction exception handler

애플리케이션이 illegal 명령어 예외 핸들러 이후에 실행을 계속할지 여부에 따라 ebreak/ecall과 동일하기 MEPC/HWLoop CSRs 처리가 필요할 수 있다.

Debugger

디버그 모드 진입 시: ebreak 명령어로 디버그 모드에 진입하고, 이 ebreak가 HWLoop의 마지막 명령어 위치에 있을 경우에는 앞서 설명한 관리(MEPC, lp.countX 관리)와 동일하게 MEPC 대신 DPC(Debug Program Counter)에서 처리해야 한다.

디버거가 소프트웨어 브레이크포인트로 ebreak 사용 시: 디버거가 디버그 모드에서 소프트웨어 브레이크포인트로 ebreak를 HWLoop의 마지막 명령어 위치에 넣는 경우, 별도의 특별한 처리는 필요 없다. 소프트웨어 브레이크포인트가 실행되면 제어가 디버거로 넘어가며, 디버거가 각 상황을 관리한다. 예를 들어, 단일 명령 실행인 경우 원래 명령어를 다시 메모리에 넣고, 해당 명령어에 대해 Single step을 실행하면 PC와 lp.countX가 설계에 따라 올바르게 갱신된다. 이후 다시 ebreak를 브레이크포인트 위치에 덮어쓴다.

ecall을 시스템 콜 실행 목적으로 사용할 때: 디버거가 ecall 명령어를 시스템 콜 실행에 사용하고, 이를 HWLoop의 마지막 명령어 위치에 넣는 경우 디버거의 ecall 핸들러는 애플리케이션의 경우와 동일하게 앞서 설명한 처리를 수행해야 한다.

HWLoop CSR의 저장/복원

HWLoop 실행 중 동기/비동기 예외나 디버그 이벤트가 발생하면 HWLoop의 정상적인 실행이 중단된다.

예외 핸들러나 디버그 프로그램에서 HWLoop 기능을 사용할 수 있거나 또는 memmove, memcpy 등 HWLoop를 사용하는 함수를 호출할 수 있으므로 HWLoop 관련 CSR를 반드시 저장/복원해야 한다.

따라서 일반 레지스터들과 함께 HWLoop CSR(lp.startX, lp.endX, lp.countX 등)의 저장/복원 코드를 예외 핸들러나 디버그 프로그램에 추가해야 한다.

Chatgpt 열풍이 부는 가운데,

갑자기 혜성처럼 등장해 `오픈 소스`를 자칭하는 딥시크.

그리고 우리가 먼저 했다도르 수상 엑사원 3.5

웹 운영도 하지 않는 엑사원의 성능이 상당히 궁금해졌다. (할 수도 있는데 안 찾아봄)

한국어로 엑사원 3.5를 검색해 봤는데, 놀랍게도 기사만 2페이지 이상 나오고 깃허브 페이지 등은 방문률이 처참한지 검색 엔진이 저 뒤로 밀어버린 모양이다.

아무튼 영어로 EXAONE 3.5 검색해서 깃허브 페이지로 들어간다.

(허깅페이스 라는 곳도 있다고 하는데, AI를 주로 하는게 아니라 잘 모르겠다.)

GitHub - LG-AI-EXAONE/EXAONE-3.5: Official repository for EXAONE 3.5 built by LG AI Research

퀵스타트를 가져와 한 번 보도록 하자

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "LGAI-EXAONE/EXAONE-3.5-7.8B-Instruct"

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.bfloat16,
    trust_remote_code=True,
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(model_name)

# Choose your prompt
prompt = "Explain how wonderful you are"  # English example
prompt = "스스로를 자랑해 봐"       # Korean example

messages = [
    {"role": "system", "content": "You are EXAONE model from LG AI Research, a helpful assistant."},
    {"role": "user", "content": prompt}
]
input_ids = tokenizer.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_tensors="pt"
)

output = model.generate(
    input_ids.to("cuda"),
    eos_token_id=tokenizer.eos_token_id,
    max_new_tokens=128,
    do_sample=False,
)
print(tokenizer.decode(output[0]))

pretrained 모델을 다운받아 사용하는 형식일 것 같고, 

model name 의 매개변수는 3개 중에 선택 가능하다고 한다

뭐.. gpt api 를 쓸 때랑 크게 다르지 않다

근데 온디바이스 모델은 2.4B parameter를 감당 가능하다고 해도 IoT 임베디드 환경에서 쓸 모델은 없나,, 생각하게 된다

한 번 실행을 해 보자.

내 실행환경은 anaconda, Python 3.11.7, i7-12700, rtx 3070을 사용 중이다.

코드 중에 to("cuda")가 있는데 Nvidia 계열 gpu가 아닌 경우에 그냥 cpu로 맞춰주면 될 것 같다

(런타임은 얼마나 걸릴지 장담 못한다)

> 여러 패키지가 이미 설치된 환경이기 때문에 나는 단 2개의 종속 패키지들만 설치했다

> accelerate==0.26.0

> transformers==4.43.0

실행하게 되면 다운로드를 쭉 받는다 (모델 구조가 어떻게 되어 있는지는 모르겠지만 DNN 구조라 parameter가 많은 듯 하다)

로컬에서 돌리면 메모리를 상당 부분 차지한다.

메모리 32gb 이상 환경에서 돌리는 것이 권장되나 보다

내 환경에서는 첫 시작에 15분 30초가 소요되었다.(다운로드 포함)

이후 2번째 실행에서는 gpu를 열심히 갈궈서 2분 30초만에 실행이 완료되었다.

그래도 rtx3070인데.. 파라미터 2.4B 짜리로 교체해보자.

model_name 을 교체해 준다.

model_name = "LGAI-EXAONE/EXAONE-3.5-2.4B-Instruct"

그런데도 가중치 값에 추가적인 값들이 들어간 텐서 파일이 5기가를 차지한다

확실히 LLM이 용량 압박이 거세다

처음 실행은 못 찍었는데, 2분대로 걸렸다.(다운로드 포함)

이후 실행에서는 좀 쓸 만한 정도까지 된 듯 하다(15초 소요)

근데 다른 프롬포트 넣어서 하니까(한글) 50초까지도 소요되는 걸 보면 PC 성능 문젠가 싶기도 하고..

2.4B 모델은 챗봇으로 사용하기도 나쁘지 않은 듯 하다(RTX 3070, 32gb ram 급 PC 로컬에서)

양자화(Quantization)된 모델의 경우에도 속도는 상당히 빠를 것 같은데 그거까지 하고싶지는 않다

근데 깃허브 밑에 다 설명하니까 그냥 보고 하면 될 듯 함

흠......

지우는 방법(아나콘다)

여기 다 들어있으니까 알아서 삭제하면 된다

일반 파이썬이면 또 파이썬 캐시파일로 잡혀서 들어가는지는 모르겠는데 경로 따라 가면 있을 듯

맛보기 끝