小白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

点击查看原文