小白wujian100_open仿真踩坑記——我是如何踩坑的，又是如何出坑的

在這篇文章中，我将同時跑兩個仿真，開兩個終端，一左一右地對比，展示我是如何踩進那些坑裡（公開處刑⚠），又是如何爬出來的。話不多說，咱們開始。

仿真過程

• 準備一個Linux系統

這裡我是用虛拟機軟體跑的Linux系統，虛拟機軟體用的是VMware Workstation 15 Pro，跑的系統是Ubuntu18.04。其實準備虛拟機的過程也是有不少坑的（對于小白來說），比如之前裝的虛拟機之前還用的好好的，可是現在突然就打不開了；再比如虛拟機和Window系統的共享檔案夾的設定問題等等。不過這裡主要說的是仿真的事情，虛拟機的事情先按下不表。

• 建立工程目錄

進入Linux系統，我這裡是以普通使用者（而不是root使用者）的身份進入系統的。打開終端，依照官方的提示（這裡給出wujian100的官方GitHub連結），建立工程目錄。注意了，就是在這裡，出現了“萬 坑 之 源”，開幕雷擊啊簡直是。注意看下面兩個終端建立工程目錄時所用指令的不同，這是後面一個令人抓狂的報錯的根源。

左邊終端：llh@ubuntu:~$ sudo mkdir Project1

右邊終端：llh@ubuntu:~$ mkdir Project2

• 下載下傳官方源碼

進入工程目錄，下載下傳官方源碼。

左邊終端：

llh@ubuntu:~$ cd Project1
llh@ubuntu:~/Project1$ sudo git clone https://github.com/T-head-Semi/wujian100_open.git           

右邊終端:

llh@ubuntu:~$ cd Project2
llh@ubuntu:~/Project2$ git clone https://github.com/T-head-Semi/wujian100_open.git           

• 建立工具鍊目錄

建立工具鍊目錄，這裡注意工具鍊目錄的名稱和目錄結構要和官方的保持一緻（見官方GitHub），因為後面編譯和仿真用的腳本都是根據那個目錄結構和名稱來寫的，不一緻的話後面會出錯（當然如果你自己會改腳本的話可以随意）。

llh@ubuntu:~/Project1$ sudo mkdir riscv_toolchain           

右邊終端：

llh@ubuntu:~/Project2$ mkdir riscv_toolchain           

• 下載下傳安裝官方交叉編譯工具鍊

到平頭哥的官網下載下傳工具鍊。這裡要注意，如果你是在Windows系統下下載下傳的工具鍊，那麼最好不要在Windows系統下解壓，否則後續仿真有可能會出現錯誤（這個我也沒具體考證過，我看群友的文章好像有這麼說的，本着不給自己找麻煩的原則，就認為它是真的吧[手動滑稽]）。我是在Windows下下載下傳到主機與虛拟機的共享檔案夾裡，然後再在虛拟機裡解壓，然後再把對應版本的工具鍊安裝到工具鍊目錄下的。

解壓下載下傳完的工具包

llh@ubuntu:~/Project1$ cd /mnt/hgfs/Shared/     #進入共享檔案夾/mnt/hgfs/Shared/

llh@ubuntu:/mnt/hgfs/Shared$ sudo unzip T-Head\ Tools\ package.zip           

檢視解壓完的工具包

llh@ubuntu:/mnt/hgfs/Shared$ ll           

這裡我們暫時隻用到RISC-V工具鍊，是以我們進入’T-Head RISC-V Toolchain-V1.2.2’目錄，并檢視都有哪些檔案。

這裡有4個版本的工具鍊，那該選哪個呢？讓我們看看Readme.txt。

llh@ubuntu:/mnt/hgfs/Shared/T-Head RISC-V Toolchain-V1.2.2$ cat Readme.txt           

注意了，這裡出現了第二個坑。我當時看了Readme，作為一個小白，我不知道“linux平台BareMetal應用程式”是啥（後來我百度了一下，說是啥裸機的意思，BareMetal可以在虛拟機和實體機間切換。具體是個什麼東西，我現在也不太清楚），于是我選了“riscv64-linux-x86_64-*.tar.gz”這個版本（名字上帶linux嘛，我當然是滋瓷它啊）。結果證明，不是這個版本。。。因為後面因為環境變量的問題出現了“xxx command not found”的報錯，我從報錯資訊中知道後面的編譯腳本用的不是這個版本的工具，報錯的指令名字跟我安裝的那個版本的工具裡的指令根本就對不上！後來我安裝了“riscv64-elf-x86_64-*.tar.gz”版本的工具（就是BareMetal對應的那版），發現指令名字正好對上了。是以應該安裝“riscv64-elf-x86_64-*.tar.gz”這個版本的工具（我現在也不太清楚為什麼選擇這個版本，我猜可能是因為工程師之前是在啥“BareMetal平台”上編譯的吧）。

安裝工具鍊

好的現在我們安裝工具鍊吧。

llh@ubuntu:/mnt/hgfs/Shared/T-Head RISC-V Toolchain-V1.2.2$ cd ~/Project1/riscv_toolchain/     #回到工具鍊安裝目錄
llh@ubuntu:~/Project1/riscv_toolchain$ sudo tar -zxf /mnt/hgfs/Shared/T-Head\ RISC-V\ Toolchain-V1.2.2/riscv64-elf-x86_64-20190731.tar.gz           

llh@ubuntu:~/Project2$ cd riscv_toolchain/
llh@ubuntu:~/Project2/riscv_toolchain$ tar -zxf /mnt/hgfs/Shared/T-Head\ RISC-V\ Toolchain-V1.2.2/riscv64-elf-x86_64-20190731.tar.gz           

然後檢視一下解壓安裝後的檔案。

好的現在我們安裝成功了。

• 安裝開源EDA工具

現在我們要安裝兩款開源的EDA工具，一款是iverilog，用于RTL檔案的編譯和仿真，另一款是gtkwave，用于檢視仿真波形。

安裝指令：sudo apt-get install iverilog verilator gtkwave

這個因為我之前已經安裝過了，我就不再安裝了。

• 準備開始仿真

好了，工具已經準備好了，我們現在開始準備仿真。

設定工具路徑和環境變量

因為要修改setup.csh這個檔案設定路徑和環境變量，是以對于Project1裡的工程（即左終端對應的工程），由于它是提權創立的，為了友善修改檔案，要修改一下Project1工程的setup.csh的權限，讓它對普通使用者可寫。

左終端輸入：

llh@ubuntu:~/Project1/riscv_toolchain$ cd ../wujian100_open/tools/     #進入/Project1/wujian100_open/tools/目錄
llh@ubuntu:~/Project1/wujian100_open/tools$ sudo chmod 777 setup.csh           

然後用Ubuntu自帶的文本編輯器修改setup.csh，儲存。

因為Ubuntu18.04預設用的shell是bshell，而腳本是用的是cshell腳本的文法，是以要修改一下setup腳本。

同樣也因為是用的是bshell，是以要把.csh檔案改為.sh檔案。

llh@ubuntu:~/Project1/wujian100_open/tools$ sudo cp setup.csh setup.sh           

同樣需要修改的還有“Srec2vmem.py”這個python腳本，因為Ubuntu18.04預設安裝的是python3，python3和python2有很多不相容的地方，是以要修改Srec2vmem.py裡的執行環境，這個的修改比較簡單，隻是把第一行的“#!/usr/bin/env python”改成“#!/usr/bin/env python3”就行，是以直接用“vi”指令打開修改儲存就行了。

llh@ubuntu:~/Project1/wujian100_open/tools$ sudo vi Srec2vmem.py           

然後修改儲存即可。

同樣地，對于Project2裡的工程（即右終端對應的工程），同樣需要修改這兩個腳本檔案。我這裡就不再修改了，因為在Project1工程裡已經修改過了這兩個腳本檔案，就直接把Project1工程的“setup.sh”“Srec2vmem.py”這兩個腳本文複制到Project2工程裡吧。

右終端輸入：

llh@ubuntu:~/Project2/riscv_toolchain$ cd ../wujian100_open/tools/
llh@ubuntu:~/Project2/wujian100_open/tools$ cp ~/Project1/wujian100_open/tools/setup.sh ./
llh@ubuntu:~/Project2/wujian100_open/tools$ cp -f ~/Project1/wujian100_open/tools/Srec2vmem.py ./
llh@ubuntu:~/Project2/wujian100_open/tools$ ll           

好的現在我們腳本檔案已經修改好了，我們要執行“setup.sh”這個腳本檔案，設定環境變量。

llh@ubuntu:~/Project1/wujian100_open/tools$ source setup.sh           

llh@ubuntu:~/Project2/wujian100_open/tools$ source setup.sh           

• 開始仿真

好了，現在都準備好了，我們開始仿真吧。

llh@ubuntu:~/Project1/wujian100_open/tools$ cd ../workdir/     #進入工作目錄
llh@ubuntu:~/Project1/wujian100_open/workdir$ sudo ../tools/run_case -sim_tool iverilog ../case/timer/timer_test.c     #啟動仿真           

我們看看執行結果如何。

好的，出現了一個錯誤“ make:/bin/riscv64-unknown-elf-gcc: Command not found”， make的時候找不到“/bin/riscv64-unknown-elf-gcc”這個指令，什麼原因我們等會兒再說，我們先啟動Project2工程的仿真。

llh@ubuntu:~/Project2/wujian100_open/tools$ cd ../workdir/
llh@ubuntu:~/Project2/wujian100_open/workdir$ ../tools/run_case -sim_tool iverilog ../case/timer/timer_test.c           

仿真成功跑通！“唰～”的一下，行雲流水般暢快～

兩者的結果對比一下

結果分析

從我們的仿真過程來看，兩個工程的檔案内容是一模一樣的，差别在于在終端上執行大部分指令時，指令前面帶不帶“sudo”。也就是說Project1是用root權限創立的，而Project2是用普通使用者權限創立的，而這個差别會在執行“setup.sh”這個shell腳本來設定環境變量時埋下隐患，導緻最後編譯make時工具路徑設定出問題。

因為是無法找到指令，我們來看一下Makefile裡關于“/bin/riscv64-unknown-elf-gcc”的路徑部分是怎麼寫的吧。

可以看到，“/bin/riscv64-unknown-elf-gcc”的路徑由“TOOL_PATH”這個變量指定，而Makefile中并沒有指定“TOOL_PATH”的值，是以Makefile執行時會從系統的環境變量中取出“TOOL_PATH”這個變量的值。而“TOOL_PATH”這個環境變量我們明明在之前的“setup.sh”腳本中已經指定了的，按理說如果這個環境變量設定成功的話，它的值會傳遞到Makefile中的才對。我們echo一下“TOOL_PATH”這個環境變量看看。

我們看到，“TOOL_PATH”這個環境變量确實設定成功了，那問題就出現在環境變量傳遞到Makefile的過程中。現在回到我們一開始說的那個問題，兩個工程的檔案内容是一模一樣的，差别在于在終端上執行大部分指令時，指令前面帶不帶“sudo”。

回想之前在Project1工程（左終端）中，執行“setup.sh”腳本甚至環境變量時用的指令是：

llh@ubuntu:~/Project1/wujian100_open/tools$ source setup.sh           

用的是普通使用者身份執行，也就是用普通使用者身份設定的環境變量。

而我們啟動仿真時用的指令卻是：

llh@ubuntu:~/Project1/wujian100_open/tools$ cd ../workdir/     #進入工作目錄
llh@ubuntu:~/Project1/wujian100_open/workdir$ sudo ../tools/run_case -sim_tool iverilog ../case/timer/timer_test.c     #啟動仿真           

用的是root使用者權限執行，也就是用root使用者身份執行仿真（Makefile）。

是以，關鍵的原因在于：

root使用者和普通使用者的環境變量（echo $PATH）預設相同，但如果以普通使用者身份登入系統修改環境變量，root使用者的環境變量不受影響。這會導緻通過sudo執行程式（比如make）所能看到的環境變量和不使用sudo執行程式所看到的環境變量是不同的。——引用自[CSDN部落格：[Ubuntu]不同使用者下環境變量問題]( https://blog.csdn.net/LavenderSs/article/details/52719246?spm=a2oza.article_detail.0.0.619c180fRloKdA)

而Project2工程（右終端）因為一開始就是用普通使用者身份創立的，它後續的仿真過程并不涉及到使用者（權限）切換的問題，是以它最終成功跑通仿真。我一開始就是用Project1工程（左終端）的方式來仿真的，結果可想而知，先是報“command not found”的錯誤，我以為是環境變量沒有設定成功，然後就上網找各種各樣的的環境變量的設定方法，各種騷操作都來一遍，結果仍然是報這個錯，搞得我很崩潰，然後我一怒之下就用了最簡單粗暴的辦法——把工具鍊裡的指令全給複制到"/bin"目錄下（你不是找不着嗎，我直接塞你家門口！我讓你再找不着！！），結果“command not found”錯誤倒是不報了，但是又出現了新的錯誤。。。後來經群友指教，覺得問題的關鍵在“TOOL_PATH”這個變量上，然後再去查環境變量和Makefile變量的資料，然後最終查到了使用者身份（權限）的頭上。

以上，就是我的踩坑-出坑記。一個小白的懵逼日常。

呼～~人生的第一篇正經部落格，終終終終終終終終于寫完了，雖然磨磨蹭蹭寫了一大堆（水了一大堆），雖然整篇文章完全可以用最後引用的那個連結來概括……不過感覺還是挺爽的。

歡迎拍磚哦～～～ （溜

後記：關于markdown編寫的文章圖檔不顯示的問題

原來的文章發出去之後,發現文章裡的圖檔顯示不出來，隻顯示了類似于下面這樣子的連結：

後來查了一下，有說是因為引用的圖檔連結裡出現了某些奇怪的字元，導緻圖檔無法顯示。然後我把圖檔連結複制到浏覽器位址欄中通路，發現是可以通路到圖檔的，我又對比了一下浏覽器位址欄中的圖檔連結和文章裡的圖檔連結，發現是因為空格的問題。

文章裡的圖檔連結是：

https://cop-image-prod.oss-cn-hangzhou.aliyuncs.com/article/3722301684530774016/15754023480100/2019-12-04 03-42-24 的螢幕截圖.png

位址欄裡的圖檔連結是：

https://cop-image-prod.oss-cn-hangzhou.aliyuncs.com/article/3722301684530774016/15754023480100/2019-12-04%2003-42-24%20 的螢幕截圖.png

把連結裡的空格換成"%20"就行了。

原文作者：Lianglonghui

點選檢視原文