前言本来应该做收集功能覆盖率，但是感觉难度有点高，还是先做一下 Toffee 的官方的 example，快速熟悉一下。 Adder 模块这个例子是一个加法器，它是一个组合电路： 12345678910111213module Adder #( parameter WIDTH = 64) ( input [WIDTH-1:0] io_a, input [WIDTH-1:0] i

前言由于 chiplab 在配置的时候需要将工具一一准备好，还有某些库比如随机测试，还需要自己下载。比较麻烦，于是我将一个配置好的环境打包成 docker 镜像，这样可以很方便得就能立即使用。 docker 镜像制作首先在 chiplab 中写一个简单的 Dockerfile: 1234567891011121314151617181920212223242526272829303132FROM

练习0: 冒烟测试这个练习是第二章 的练习，我改成异步的了： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556from SyncFIFO import *import asyncio #创建test_reset_dut 函数作为的测试用

问题在官方教程中有这样一个事例： 1234567891011121314151617181920212223242526272829303132333435363738394041# test_with_toffee.pyfrom RandomGenerator import DUTRandomGeneratorimport randomfrom toffee import start_clock

前言从 7月1号 到现在在 FPGA 启动 linux_kernel 已经过了 23 天了，虽然中间考试和休息占了 5 天左右，这也说明在 chiplab 中启动 linux_kernel 和在 FPGA 上启动 linux_kernel 有很大的跨度以及很多的工作量。事实上，工作量主要集中在 debug 上，下面细说一下常见的 bug 以及 cacop 的实现细节。 cacop没错，想要使用双

vivado 内存占用过多在综合 cache 的时候，发现内存直接占用过多，导致综合失败，仔细研究了下代码发现是这个引起的： 12345678910111213141516171819reg [149:0] cache_line_0[255:0];reg [149:0] cache_line_1[255:0];reg [149:0] cache_line_2[255:0];reg [149:0]

前言由于原来的路由器连接的设备过多就会导致内网中所有连接这个路由器的的设备自动失去网络连接，只有通过重启设备解决，很影响效率。于是我买了一个中国移动定制的路由器，型号是 WTC181。 操作流程货收到了后，由于这个路由器是 WAN/LAN 混合，导致我从原来的路由器拉出来的 LAN 插到 WTC181 上的 WAN/LAN 混合口后，并没有自动构建一个新的内网环境。 然后我打开

前言cache 的设计如果能配合良好的 debug 系统，那么就不是太难。由于 icache 只是 dcache 的一个子集功能，因此只要设计好了 dcache，icache 自然就能正常运作。笔者设计好 cache 并成功启动 linux_kernel 后，认为 cache 设计可以问分为两个部分：可缓存的访问和不可缓存的访问，用信号 uncache_en 来指明，这个信号由访存单元和访问 ca

问题在 sc.w 执行后，我发现一切都很合规，但是 REF 跳进了一个 pc = 0x00204000 的指令，然而 DUT 还在若无其事的执行 sc.w 的下一条指令。这让我意识到了，可能是 sc.w 遇到了异常，REF 给出了正确的响应，然而 DUT 无动于衷。 分析过程pc = 0x00204000 是什么异常的处理入口呢？ 因为我是在启动 linux，因此必须对这个地址

前言OpenLA500 的 dcache 是一个简单的 cache，实现了 《CPU 设计实战》中 有关cache 的所有需求，因此它值得研究和学习。 体系结构cache 是内存的一部分内容拷贝，因此 CPU 访存的时候首先访问 cache，若命中就返回，若未命中就会 refill 然后返回（数据或者 write 的 OK 信息）。 cache 的三种映射方式中，组相联是最好的，它结合了全相联和直