在SOC環(huán)境里面C代碼是怎么執行的？

不少同學(xué)很好奇在SOC環(huán)境里面C代碼是怎么執行的？

是通過(guò)DPI實(shí)現SV和C的交互，然后用 SV的task將C的數據轉成對應的總線(xiàn)數據下發(fā)到各個(gè)外設？

DPI 調用例子

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

PLI調用例子

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

TLM2.0 使用例子

實(shí)際上，以上三種都不是！

在SOC驗證環(huán)境中，需要仿真一顆芯片真實(shí)的工作狀態(tài)。通過(guò)上面三種手段驗證不到CPU boot的過(guò)程，CPU處理 interrupt的過(guò)程，芯片進(jìn)出低功耗的過(guò)程。

在SOC環(huán)境中怎么模擬芯片的工作過(guò)程呢？

下面是一個(gè)典型的RISCV CPU。在這個(gè)系統中，CPU會(huì )通過(guò)指令總線(xiàn)獲取執行的程序指令，然后通過(guò)數據總線(xiàn)訪(fǎng)問(wèn)存儲的數據和外設等。

在下面的這個(gè)系統中，我們將RISCV的指令總線(xiàn)和數據總線(xiàn)作為兩個(gè)master 掛在A(yíng)HB總線(xiàn)上，將程序指令存儲在SRAM中，當SOC啟動(dòng)時(shí)，會(huì )通過(guò)指令總線(xiàn)訪(fǎng)問(wèn)SRAM獲取指令信息。

CPU中拿到指令后會(huì )進(jìn)行解碼，然后通過(guò)執行單元執行解碼的指令，如果需要用到外部的存儲數據，則會(huì )通過(guò)數據總線(xiàn)訪(fǎng)問(wèn)SRAM獲取存儲的數據內容。如果解碼內容配置外設寄存器，則通過(guò)數據總線(xiàn)訪(fǎng)問(wèn)外設，對外設進(jìn)行配置等等。

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

通過(guò)上面的描述，我們大概清楚了CPU是怎么工作起來(lái)的，但是這個(gè)和我們的C程序有什么關(guān)系呢？

CPU執行的是機器碼指令，這些指令是由一個(gè)個(gè)特定數據和擺放的格式?jīng)Q定的。

下面是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是寄存器類(lèi)型指令， I是立即數類(lèi)型指令，S是存儲類(lèi)指令，B是分支類(lèi)指令，U是高20bit立即數指令，J是跳轉指令。

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

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

funct3，opcode又是什么呢？通過(guò)查詢(xún) riscv 手冊可以查到以下結果。

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

將這個(gè)機器放在地址0x29a 的位置。

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

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

下面這個(gè)圖是C語(yǔ)言編譯成機器碼的過(guò)程。

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

我們以SOC3.0的環(huán)境為例子，看看這個(gè)過(guò)程怎么執行的。

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

crt0.S

"crt"代表"C runtime"（零表示"一切的開(kāi)始"）。

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

在SOC3.0里面crt0.S 是匯編語(yǔ)言寫(xiě)的。

這段代碼做什么事情呢？

異常處理程序:

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

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

復位處理程序:

reset_handler 將所有寄存器設置為零，并通過(guò)加載堆棧起始地址來(lái)初始化堆棧。

清除BSS段:

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

跳轉到主函數:

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

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

異常向量:

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

2. C函數

以spi1_test test為例子

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

spi1_test.c ，這里實(shí)現對spi1這個(gè)IP的配置及自我檢查。

3. 鏈接文件link.ld

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

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

內存布局:

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

rom從地址0x00000000開(kāi)始，stack從地址0x0000C000開(kāi)始。

堆棧信息:

_min_stack設置為0x2000（8 kB），表示要保留的最小堆?？臻g。

_stack_len是stack區域的長(cháng)度。

_stack_start是堆棧的起始地址。

各個(gè)段:

.vectors 段包含中斷向量，位于rom的開(kāi)頭。

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

.rodata 段包含只讀數據。

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

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

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

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

特殊段（NOLOAD）:

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

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

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

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

??--->

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

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

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

到這里我們已經(jīng)產(chǎn)生了機器碼的文件.bin,按理說(shuō)CPU拿這個(gè)文件就可以執行了。但是在我們環(huán)境里面，我們需要將機器碼放到verilog 的sram memory里面去。所以我們還做了第四步。

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

通過(guò)上面四步，我們實(shí)現了C到機器碼的轉換。

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

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

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

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

我們看看效果。

非常方便。

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

關(guān)于 SOC3.0，小伙伴們可以點(diǎn)這里。

SOC3.0有哪些東西？

或者直接聯(lián)系梨果。

審核編輯：劉清