不少同學很好奇在SOC環境里面C代碼是怎么執行的？

是通過DPI實現SV和C的交互，然后用 SV的task將C的數據轉成對應的總線數據下發到各個外設？

DPI 調用例子

是在verilog里面調用PLI獲取C里面的內容？

PLI調用例子

還是通過TLM1.0 或者TLM2.0 完成C和verilog 的交互？

TLM2.0 使用例子

實際上，以上三種都不是！

在SOC驗證環境中，需要仿真一顆芯片真實的工作狀態。通過上面三種手段驗證不到CPU boot的過程，CPU處理 interrupt的過程，芯片進出低功耗的過程。

在SOC環境中怎么模擬芯片的工作過程呢？

下面是一個典型的RISCV CPU。在這個系統中，CPU會通過指令總線獲取執行的程序指令，然后通過數據總線訪問存儲的數據和外設等。

在下面的這個系統中，我們將RISCV的指令總線和數據總線作為兩個master 掛在AHB總線上，將程序指令存儲在SRAM中，當SOC啟動時，會通過指令總線訪問SRAM獲取指令信息。

CPU中拿到指令后會進行解碼，然后通過執行單元執行解碼的指令，如果需要用到外部的存儲數據，則會通過數據總線訪問SRAM獲取存儲的數據內容。如果解碼內容配置外設寄存器，則通過數據總線訪問外設，對外設進行配置等等。

這里需要注意的是程序代碼放在SRAM里面，一些數據內容也是分在SRAM中，假如中間不作分割，那么指令和數據會混在一起，導致RISCV在執行程序的時候會跑飛。所以我們在后面編譯指令的時候，需要對memory空間進行分割。

通過上面的描述，我們大概清楚了CPU是怎么工作起來的，但是這個和我們的C程序有什么關系呢？

CPU執行的是機器碼指令，這些指令是由一個個特定數據和擺放的格式決定的。

下面是32bit RISCV的部分指令格式。

在這里R，I S，B U，J分別代表6種不同的指令。

R-formatfor register-register arithmetic/logical operations

I-formatfor register-immediate arith/logical operations and loads

S-formatfor stores

B-formatfor branches

U-formatfor 20-bit upper immediate instructions

J-formatfor jumps

R是寄存器類型指令， I是立即數類型指令，S是存儲類指令，B是分支類指令，U是高20bit立即數指令，J是跳轉指令。

我們以簡單的立即數加法運算為例，比如我想做一個 a0= s0+16 這樣一個立即數加法運算，偽代碼就是 add a0，s0，16 。這個案例中我們用的是立即數類型的指令。

根據上述表格，該指令格式為

funct3，opcode又是什么呢？通過查詢 riscv 手冊可以查到以下結果。

這個立即數加法最終編譯成機器碼 0x01048513

將這個機器放在地址0x29a 的位置。

我們把這些機器碼放在SRAM里面，CPU看到拿到 0x01048513 就可以解碼出來這是一個a0=s0+16的立即數操作。

到這里，我們大概知道底層的CPU是怎么執行的，現在要解決的問題是如何將C編譯成機器碼。

下面這個圖是C語言編譯成機器碼的過程。

C語言首先編譯成匯編語言，再由匯編語言編譯成機器指令，最后通過鏈接形成目標機器指令。

我們以SOC3.0的環境為例子，看看這個過程怎么執行的。

首先我們看SOC3.0的環境里面都有哪些文件。

crt0.S

"crt"代表"C runtime"（零表示"一切的開始"）。

crt0是一組執行啟動例程，編譯到程序中，在調用程序的主函數之前執行任何必要的初始化工作——它是一個基本的運行時庫/運行時系統。crt0的工作取決于程序的語言、編譯器、操作系統和C標準庫的實現。

在SOC3.0里面crt0.S 是匯編語言寫的。

這段代碼做什么事情呢？

異常處理程序:

default_exc_handler 是一個通用的異常處理程序，似乎被設置為各種異常的處理程序，比如外部中斷、非法指令和系統調用 (ecall)。

還有其他異常向量的占位符（nop指令），表明它們可能以類似的方式處理。

復位處理程序:

reset_handler 將所有寄存器設置為零，并通過加載堆棧起始地址來初始化堆棧。

清除BSS段:

它通過用零填充來清除BSS（由符號開始的塊）段。通常這樣做是為了確保所有未初始化的全局和靜態變量都以零值開始。

跳轉到主函數:

最后，它跳轉到 main 函數，并將 argc 和 argv 設置為零。

注意我們C 代碼的main 函數的命名不是天生就是這么命名的，是在這里給定的。

異常向量:

.vectors 部分定義了異常向量。它似乎對各種異常使用默認的異常處理程序，還有一個重置向量指向 reset_handler。

2. C函數

以spi1_test test為例子

common.c ，這里定義了一些打印字符串和讀寫寄存器的函數。

spi1_test.c ，這里實現對spi1這個IP的配置及自我檢查。

3. 鏈接文件link.ld

我們在上文說了，在SRAM里面如果不對程序存儲空間和數據存儲空間進行分割，那么CPU執行的時候很可能跑飛。為了組織內存分配，需要一個鏈接文件進行配置。

link.ld是一個鏈接腳本（linker script），用于指導鏈接器如何組織程序在內存中的布局。具體來說，它包含了以下關鍵信息：

內存布局:

內存被劃分為兩個區域：rom（48 kB）和stack（16 kB）。

rom從地址0x00000000開始，stack從地址0x0000C000開始。

堆棧信息:

_min_stack設置為0x2000（8 kB），表示要保留的最小堆棧空間。

_stack_len是stack區域的長度。

_stack_start是堆棧的起始地址。

各個段:

.vectors 段包含中斷向量，位于rom的開頭。

.text 段包含程序代碼。構造函數和析構函數列表用于處理C++。

.rodata 段包含只讀數據。

.shbss 段在rom中對齊并放置。

.data 段包含已初始化的數據。

.bss 段包含未初始化的數據。

.stack 段確保堆棧有足夠的空間。

特殊段（NOLOAD）:

.stack 段標記為 NOLOAD，意味著它不會加載到最終的二進制文件中。它只是為堆棧保留空間。

.stab 和 .stabstr 段也被定義，但標記為 NOLOAD，表明它們是調試信息。

有了上面這些文件，我們看看Makefile 怎么將spi1_test.c 編譯成機器碼的。

第一步，通過riscv提供的工具鏈將C和匯編.S的文件編譯成目標文件。

??--->

第二步，將生成的.o目標文件鏈接成elf文件

ELF（Executable and Linkable Format）是一種用于可執行文件、目標文件、共享庫和核心轉儲文件的標準文件格式。它是一種二進制文件格式，設計用于在多種操作系統上支持可執行文件和可重定位代碼的交互性。

第三步，用elf文件生成 二進制文件(機器碼) .bin文件

到這里我們已經產生了機器碼的文件.bin,按理說CPU拿這個文件就可以執行了。但是在我們環境里面，我們需要將機器碼放到verilog 的sram memory里面去。所以我們還做了第四步。

第四步，將.bin 文件轉換為一個包含二進制數據的Verilog內存初始化文件。

通過上面四步，我們實現了C到機器碼的轉換。

我們將生成的spi1_test.vmem 放到SOC環境中，sram的memory 通過readm 讀進這些機器碼。然后通過仿真，就可以模擬SOC執行的過程。

按理說到里面我們應該結束今天的文章，但是當我們回頭看看我們環境似乎還缺些什么。

沒錯那就是機器碼的反標，當我們debug cpu的時候，cpu記錄當前執行的指令和指令行數，我們通過這些信息可以定位具體在操作哪條機器碼，但是我們怎么樣才知道當前的機器碼對應是C代碼里面的拿哪段內容呢？

這就需要機器碼的反標，在我們SOC3.0的環境里面，我們通過下面指令完成機器碼到C的反標。

我們看看效果。

非常方便。

以上是我們文章的所有內容，上述所列案例在我們SOC3.0里面都有，歡迎感興趣的小伙伴咨詢。

關于 SOC3.0，小伙伴們可以點這里。

SOC3.0有哪些東西？

或者直接聯系梨果。

審核編輯：劉清