Rill的专栏

引言计算机体系结构的研究和学习中，理论是一方面，这方面有很多很优秀的教材，比如J&P的两本经典，国内也有很多关于体系结构的书籍可供参考。此外，理论联系实际也是不可或缺的，但是关于实用CPU的具体实现的源码分析方面的书籍就寥寥无几了。这可能跟从事这方面的研发人员的数量有限有关。参与的人少，又加剧了参考资料的稀疏，形成了一个不好的循环。这使我想起了linux kernel的研究。按理说，l

引言之前关于openrisc的内容，几乎都是基于opencores官方的ordb2a那个开发板的，但是，实际情况是有那个本子的人很少，所以目前我在做一个与之类似的板子，并且很快就会跟大家见面，这是后话。在新做的板子出来之前，本小节我们先在xilinx ml501板子上跑一下openrisc和orpmon。1，实验准备1>熟悉开发板ML501是xilinx比较老的一款FPGA开发板，在最开始，如果对

引言前一段时间，我们分别在eCos和linux上实现了ORPSoC中的sd卡控制器的基本操作。在eCos上实现了完整的，支持文件系统的driver，在linux上，也实现了基本的IO操作，但是还没有实现基于文件系统的操作，本小节就解决这个问题。关于之前我们所做的工作，请参考：OpenRisc-30-SD card controller模块分析与验证：http://blog.youkuaiyun.com/ril

引言之前，我们分析or1200的控制通路中的sprs模块和except模块，本小节，我们就分析一下or1200控制通路的最后一个模块，就是freeze模块。1，整体分析freeze模块，顾名思义，就是根据各个流水阶段的反馈信号，负责产生控制整条流水线各个阶段的暂停信号，如取指阶段的genpc_freeze和if_freeze信号，解码阶段的id_freeze信号，执行阶段的ex_freeze信号，

引言为CPU提供足够的，稳定的指令流和数据流是计算机体系结构设计中两个永恒的话题。为了给CPU提供指令流，需要设计分支预测机构，为了给CPU提供数据流，就需要设计cache了。其实，无论是insn还是data，都需要访问存储器，所以从这个角度来说，cache需要承担更重要的角色。本小节我们就分析一下or1200的cache部分的实现。1，cache产生原因还是那句话，研究一

引言“不如意事常八九，可与语人无二三”，人嘛，没有一帆风顺，一定有这样或那样的异常状况出现。对CPU来说，也是这样，如果一个CPU只能顺序执行，不能处理异常情况，那么这个CPU也就没什么存在的意义了。本小节，我们就分析一下or1200的异常处理系统。1，异常1>异常的概念这里假定中断是异常的一种类型。说到异常，大家可能并不陌生，linux里面有异常处理上下文的机制，之前我们在分析MMU模块时有TL

引言之前，我们在分析or1200的WB模块时（http://blog.youkuaiyun.com/rill_zhen/article/details/10220619），介绍了OpenRISC的GPRS（general purpose register set）。除了GPRS之外，大多数的CPU还有SPRS（special purpose register set）。在分析完or1200的数据通路之后，从本

引言之前，我们在eCos下对ORPSoC的SD卡控制器进行了测试，这次我们将进行一次基于linux的测试和验证。关于基于eCos下的SD card controller测试请参考：http://blog.youkuaiyun.com/rill_zhen/article/details/9365477和http://blog.youkuaiyun.com/rill_zhen/article/deta

引言“善妖善老，善始善终”，说的是无论什么事情要从有头有尾，别三分钟热度。对于or1200的流水线来说，MA阶段是最后一个阶段，也是整条流水线的收尾阶段，负责战场的清扫工作。比如，把运算指令的运算结果要写到寄存器里，把从内存读来的数据写到寄存器里，如果在前面的流水阶段出现了异常，WB阶段还要负责把异常指令的地址存到寄存器里。总之呢，就是写回寄存器。本小节，我们就分析一下or1200五级流水线最后一

引言“茶壶里倒饺子--有口说不出“，说的是肚子里很多东西，却无法说出。其实在计算机体系结构里，也存在这个问题，这就是memory wall（存储墙）的问题。说到底，计算机的作用就是根据人们输入一堆东西，然后输出处理结果，所以，输入输出部分，就显得格外重要。CPU本身的计算能力再强，一直得不到足够的输入，或者无法将大量的结算结果输出出来，也是无济于事。流水线中的MA阶段，就是CPU和外部交流的主要窗

引言之前，我们分析了or1200流水线的整体结构，也分析了流水线中IF级，EX级，本小节我们来分析ID（insn decode）级的一些细节。1，基础or1200的pipeline的ID阶段包含一个模块，就是ctrl模块，其对应的文件是or1200_ctrl.v。ID，就是instruction decode，顾名思义，其主要任务就是对从IF阶段取得的指令进行解析，产生各种

引言我们在前面分析了ORPSoC，or1200_top，和or1200_cpu的整体架构，在最近，我们也分析了or1200的pipeline（流水线）中的两级，EX级和IF级。但是，我们还没有从宏观的角度，整体的了解一下or1200的流水线结构，本小节就做这件事情。1，流水线1>概述关于流水线的概念，历史，划分等等这些内容，在很多文献里都提到过，而且我们之前也介绍过，这

引言“喂饱饥饿的CPU”，是计算机体系结构设计者时刻要考虑的问题。要解决这个问题，方法大体可分为两部分，第一就是利用principle of locality而引进的cache技术，缩短取指时间，第二就是采用各种转移预测技术，提高取指正确的概率。只有cache，没有好的转移预测，取指时间再短，每次提前取的指令都是错的，不行。只有转移预测，没有cache，即使每次取得指令都对，但是每次取

引言前面我们简单分析了ORPSoC的整体结构，or1200_top的整体结构，or1200_cpu的整体结构。并对ORPSoC的启动过程，ORPSoC的debug子系统，clock子系统进行了介绍。本小节，我们一起来分析一下ORPSoC的存储器组织（memory hierarchy）。1，背景知识在分析ORPSoC的memory hierarchy之前，我们有必要先了解

引言之前，曾经在orpsoc的平台上，测试验证过其sd card controller的linux的驱动，但是并不是很完美，经过努力，终于在eCos下完成了其全部功能的验证，包括驱动层验证，文件系统的挂载，应用层的创建文件，打开文件，复制文件，源文件与复制文件的比较等，此外，还有创建目录，切换目录等操作。本小节就分享一下整个验证过程。关于基于orpsoc+linux下的sd card

1.OpenRISC 1200 soft processorIntroductionThe OpenRISC 1200 (OR1200) is a synthesizable CPU core maintained by developers at OpenCores.org. The OR1200 design is an open source implementation of the Op

引言or1200的调试，是玩OpenRISC绕不过去的话题，无论是硬件上的调试，软件程序的烧写，调试，还是仿真时的调试，都需要相关的调试系统的支持。鉴于debug系统的重要性，Opencores官方也开发了一个调试系统-advance debug system，这个系统包含硬件和软件的所有组件，请参考：http://opencores.org/project,adv_debug_sys通过下载和阅

引言调试OpenRISC，需要软件和硬件的协同工作才能实现，其中硬件又包括JTAG cable，JTAG TAP和debug interface三部分，软件也包括JTAG cable的驱动，RSP server和GDB三部分。本小节就从整体出发，简单介绍一下OpenRISC的调试系统。1，调试系统分类如果软件和硬件各个子部分以不同组合方式组合在一起，就会出现不同的调试系统，但一般有三种不同的组合方

引言之前我们写过OR的裸机程序，写过基于OR的linux设备驱动程序，也反汇编过OR的机器码。本小节，我们将通过一个简单的实验，对OR的汇编（指令集）做一个简单的梳理和测试。1，基本思想要想了解OR的指令集，其实只要查查OpenRISC architecture manual就可以了，但是不是最好的熟悉方式，也没有必要将其所有指令集记下来。我认为，通过一个实际的工程或者例子，从中了解OR的指令集是

引言前面，我们介绍过对裸机程序进行RTL仿真，那些裸机程序规模比较小，只有几KB大小。另外，我们也已经实现了针对O_board的SoC进行了RTL仿真（http://blog.youkuaiyun.com/rill_zhen/article/details/21190757），本小节，我们将实现在ML501平台上对linux进行RTL仿真。1，DDR2仿真模型的修改针对ML501的ORPSoC工程中，默认配置

引言要利用ORPSoC进行开发，最直接的方式当然是直接用FPGA开发板进行调试，当往往很多时候，直接在FPGA板子上运行的时候会出现问题。这时候，对ORPSoC进行仿真就是非常必要的了，通过仿真，可以尽快的锁定问题，解决问题。本小节就以ORPSoC针对ML501开发板为例，解决这个问题。1，通用版本的RTL仿真在opencores提供的ubuntu镜像里面，对于通用的版本（ORPSoC除了通用版本

引言simulator，顾名思义，就是用来模拟硬件系统的，所以越接近实际情况越好。我们在实际下板测试时，启动linux之后，经常会访问主机上的文件。比如我们写完一个设备的driver，生成ko文件之后，最方便的加载方式就是用板子挂载主机上的nfs来实现对ko文件的访问（http://blog.youkuaiyun.com/rill_zhen/article/details/8700937）。那么，在用or1k

引言前一段时间，我们对vga_enh模块进行了单独的仿真（http://blog.youkuaiyun.com/rill_zhen/article/details/8911727），初步确认了这个模块是没有问题的。那么，到底这个模块能不能正常work呢？本小节就解决这个问题。1，实验步骤本小节，我们将vga_enh模块添加到ORPSoC，进行RTL仿真，并在ML501开发板上进行验证。大体过程如下：1>修改R

引言网络上关于openrisc的资料很多，除了官网之外，还有很多有价值的资料值得借鉴，但是，这些资料比较分散，查找起来很是不易，为了能方便自己，也方便别人，本小节就把我遇到的不错的网址或者资料list了一下。如果哪位还有不错的资料，可以写到评论里面，我会及时的更新本文档，方便更多人查找。国内我们有一个qq群，可以参与讨论，相互学习与交流：27750552

引言“书上学来终觉浅，绝知此事要躬行”，“百闻不如一练”。无论是研究什么东西，学习和观摩是一回事，动手操作又是另外一回事。玩OpenRISC也是这样，只分析RTL，做一下仿真，对其感觉只能停留在‘纸上’，要想进一步加深对OpenRISC的理解，加深对CPU设计技术的掌握。除了分析RTL和仿真之外，还需要做很多基于OpenRISC的实验或者实际的项目才行。要做实验就需要对应的开发板，目前国内的FPG

引言之前我们在PC上构建了ORPSoC的仿真环境，通过仿真环境，我们可以观察任何模块的工作波形，极大的方便了问题定位和错误分析。但是，“是骡子是马，拉出来溜溜”，只能看看仿真波形显然还不过瘾，我们还需要用FPGA板子跑一边才行。但要想在板子上运行和调试软件，最方便最直接的方式就是用gdb将程序load到内存，进行调试运行。本小节就以ML501板子为例来说明OpenRISC调试系统的构建过程。 1，

引言前面我们已经实现从SPI Flash启动orpmon和u-boot，并利用orpmon和u-boot的tftp服务最终启动了linux。看似大功告成，其实不然。由于SPI Flash的容量有限（2MB），无法从SPI Flash直接启动linux，如果想启动linux的话必须先启动bootloader，这就要求linux的启动过程需要人为的参与，而这是我们不想看到的。那如何才能上电直接启动li

引言“知其然，还要知其所以然”，在搭建好ORPSoC的仿真环境和调试环境之后，我们有必要对仿真和调试系统中扮演重要角色的jtag_tap模块和adv_dbg_if模块进行进一步的分析，以了解其工作机制。本小节就来分析advanced debug system中的tap_top模块。1，from SPI to JTAG在分析JTAG的具体实现之前，我们先了解一下JTAGF的基本知识。A、JTAG协议

引言之前我也写了一个相关的blog,今天看到这篇，感觉也挺好的，故转载如下： 去年7月份毕业从桂林来到广州这边工作后，唏嘘万分，由于小弟我在学校是专业打酱油的料，所以来到公司后一直没有机会做些酱油级别以上的事情，所以平时除后勤阿姨聊聊天，在公司“搬搬砖”，等等之外，为了消磨上班时候无聊的时间，逼迫自己找点事情做做咯，至少在公司可以先混吃混学。        怪自己还在学校的时候不用

引言前面，我们已经实现用or32-elf-gdb将vmlinux烧到ML501上的DDR2SDRAM，并成功启动了linux，如有疑问请参考（http://blog.youkuaiyun.com/rill_zhen/article/details/17142327）。采用gdb的方式适合在调试和开发过程中，由于在项目开发调试过程中，需要频繁的修改和调试代码，所以使用gdb无疑是最好的方式。但是，采用gdb直接

引言之前我们在ML501上构建了仿真调试=系统，并成功运行了orpmon，但是这些还不够，我们还要运行OS才行。本小节基于前面的工作，启动linux。1，资源准备1>ORPSoC针对ML501的ORPSoC的RTL工程采用（http://blog.youkuaiyun.com/rill_zhen/article/details/17011957）构建的ise工程。2>linux采用（http://openco

引言在前面我们阐述了OpenRISC 的调试系统的集中不同的实现方案，本小节我们着重介绍一下其中的Advanced Debug System。为了在不同的阶段进行不同层次的调试，模拟和仿真，opencores也开发了相应的debug系统（advancedebug system，http://opencores.org/project,adv_debug_sys），其中既包含目标硬件模块也包含软件模

引言computer（计算机），顾名思义，就是用来compute（计算）的。计算机体系结构在上世纪五六十年代的时候，主要就是研究如何设计运算部件，就是想办法用最少的元器件（那时元器件很贵），最快的速度，完成加减乘除。。。。。。等等这些运算。后来发现运算已经足够快了，快到已经无法提供足够的运算指令和运算的操作数了，人们才开始研究如何给运算部件提供足够的指令和数据，这就产生了cache啊，分支预测

引言MMU（memory management unit），无论对于computer architecture designer还是OS designer，都是至关重要的部分，设计和使用的好坏，对性能影响比较大。MMU，我觉得是硬件和软件配合最密切的部分之一，对于RISC CPU而言，更是这样。前面，我们对or1200的整体memory hierarchy做了简单分析，了解了cache

引言之前，我们简单分析了ORPSoC的clock子系统，debug子系统，对FPGA的上电，复位，配置，初始化，用户模式等FPGA准备过程有了初步了解。此外对ORPSoC的启动过程，包括程序的烧写，上电之后的load等过程也有了初步了解。为了避免犯一叶障目，盲人摸象，本小节就对ORPSoC的整体架构做一个分析，力图能在宏观上把握ORPSoC的整体设计。关于debug子系统：

最近在弄openrisc，之前有人在弄，并且写了一篇master thesis，我已经上传了：http://download.youkuaiyun.com/detail/rill_zhen/5303401下面的内容应该就是根据论文中的指导完成的，但是，不是我完成的，所以转载如下：    接上一篇（原创）基于or1200最小sopc系统搭建（二）--QuartuII工程及DE2平台下

OpenRisc-21-添加自己的IP core到ORSoC并测试引言我之前写过一篇类似文章：http://blog.youkuaiyun.com/rill_zhen/article/details/8700937那篇算是一个比较详细的概述吧，那篇文章把精力主要集中在driver部分，提到ip core的编码时，一笔带过。这次进一步细化，写一个真的可以work的ip core，加到现有的O

引言之前写了一个wishbone接口的slave，work的很好。但是要想实现一个功能完成的ipcore，必然要有master接口。这次就写一个ipcore（mycore），既包含slave，又包含master。一个具有类似DMA功能的ip core。 另：本小节中省略了一些virtualbox下的操作细节，请参考上一篇文章：http://blog.youkuaiyun.com/r

这篇blog介绍I2C的学习了，首先要在我们的or1200_soc上添加进来I2C Controller，到opencores社区上面找到i2c_latest.tar.gz这个工程包。        解压得到如下文件目录：        注意啦，这里的i2c_top.v的顶层文件需要自己编写，因为需要在工程的更顶层将i2c_master_top.v里的输入输出信号组织成三态信号

每周开始上班那一天都特别累，当然，我的宗旨是不上班一定要比上班累~年轻人嘛，多出去走走，所以我现在的工作很轻松，每天想着每周工作两天就够了。        好了，休息五天的第一次，公司没安排事情做就自己瞎搞咯，找后勤阿姨们吹吹水，调杯咖啡喝，上网看看新闻，基本上第一天上午我就是这样浪费的，现在下午的第一天，对了，最近研发新招来了三个研究生，两个是我们学校的师兄，但是对不起也要说一句了，真的好屌