Code Monkey home page Code Monkey logo

nutshell's Introduction

NutShell (果壳)

NutShell is a processor developed by the OSCPU (Open Source Chip Project by University) team.

Currently it supports riscv64/32.

See here for the documents.

See the History and Naming section for naming issue.

Compile chisel code

Run programs by simulation

You can either use our ready-to-run image for simulation or build image yourself.

To use ready-to run image (recommended) :

  • Run make emu to launch simulation. Default image is linux kernel.
  • Run make IMAGE=yourimage.bin emu to specify your image file. We have provided some in ./ready-to-run.

To build image yourself:

  • Set a new environment variable NEMU_HOME to the absolute path of the NEMU project.
  • Set a new environment variable NUTSHELL_HOME to the absolute path of the NutShell project.
  • Clone the AM project.
  • Set a new environment variable AM_HOME to the absolute path of the AM project.
  • Run the application in the AM project by make ARCH=riscv64-nutshell run.
cd nexus-am/apps/microbench
make ARCH=riscv64-nutshell mainargs=test run

Run on FPGA

Sub-directories Overview

fpga
├── board              # supported FPGA boards and files to build a Vivado project
├── boot               # PS boot flow of zynq and zynqmp
├── lib                # HDL sources shared by different boards
├── Makefile
├── Makefile.check
└── NutShell.tcl       # wrapper of NutShell core in the Vivado project

Build a Vivado project

  • Install Vivado 2019.1, and source the setting of Vivado and SDK
  • Run the following command to build a Vivado project
cd fpga
make PRJ=myproject BOARD=pynq STANDALONE=true

Change pynq to the target board you want. Supported boards are listed under board/. The project will be created under board/pynq/build/myproject-pynq. Please note that STANDALONE mode is only used in pynq board.

  • Open the project with Vivado and generate bitstream.

Prepare SD card

Refer to the instructions of fpga/boot/README.md.

NOTE: Remember to put the bitstream into BOOT.BIN, since the guide is going to boot everything from SD card.

Set your board to SD boot mode

Please refer to the user guide of your board.

  • zedboard
  • zcu102
  • sidewinder
  • ultraZ (currently not avaliable to the public)
  • axu3cg (currently not avaliable to the public)

Boot linux in PS

Just insert the SD card into the board, open a serial terminal and powerup the board.

Boot NutShell (the RISC-V subsystem)

To boot the RISC-V subsystem

  • Send fpga/resource/ddr-loader/ddr-loader.c to PS. This can be achieved by either copying the file to SD card, or by sending the file with scp if you have your board connected to your host by network.
  • Compile the loader by gcc on PS.
gcc -O2 -o ddr-loader ddr-loader.c
  • Send the RISC-V program (bin file, should start at 0x80000000) to PS.
  • Open minicom on PS to connect to the UART of NutShell. Note that you can connect to PS via ssh and use tmux to get multiple terminals.
minicom -D /dev/ttyUL1
  • Use the loader to load the program to NutShell memory and start running NutShell.
./ddr-loader $(YOUR_BOARD) bin-file
  • To shutdown the board, first run poweroff in PS.

History and Naming

Is NutShell developed from scratch?

No. NutShell is originally based on the NOOP project, an educational RV32 SoC designed by Nanjing University (NJU). At 2019/08/27, the OSCPU team decided to start a new project based on a fork of NOOP.

Why was there only one contributor in this repo before 2019/08/27?

NOOP was maintained by sashimi-yzh on behalf of NJU before 2019/08/27.

What is the different between NutShell and NOOP?

Undergraduate students in the OSCPU team planned to enhance the educational SoC to a fully functional RV64 SoC, on behalf of University of Chinese Academy of Sciences (UCAS, **科学院大学). The goal was to boot Linux + Debian and tapeout the chip. Students have put a lot of effort into achieving such a goal.

Where can I find the original NOOP repo?

NOOP is designed as a programming assignment for educational purpose. It is still unstable and may be redesigned every year. Therefore there is no official release for NOOP yet.

But here are some reference implementations:

  • Code in this NutShell repo before 2019/08/27 can be considered as NOOP designed in 2019.
  • Here is an implementation of NOOP designed by students in NJU at 2018. This is the CPU design which won the 2nd prize in LoongsonCup18. It is designed with Chisel, too. But note that the ISA is mips32, since the contest is held by Loongson. Also the implementation is very different from the one above.

Why can I still find the name NOOP in the code as well as the commit logs after 2019/08/27?

During the development, the OSCPU team has not yet thought of a good name for the SoC. Before this repo is available to the public, they finally decide to name the SoC NutShell. In Chinese, NutShell (果壳) and the nickname of UCAS (国科大) are similar in pronunciation. The name NutShell is welcomed by every student in UCAS.

I found a name Argo in the code as well as the commit logs. What is it?

Argo is the name of a dual-issued OoO core designed by AugustusWillisWang. AugustusWillisWang is one of the students who develop NutShell. Argo is designed based on NutShell, and they share the same SoC architecture.

I found a name COOSCA in the commit logs. What is it?

COOSCA is an internal name of the SoC. Students in the team want a better name, so there comes NutShell. The name COOSCA should be rarely presented in the repo.

nutshell's People

Contributors

augustuswilliswang avatar bohan-hu avatar channingyoung avatar chenguokai avatar donlon avatar klin02 avatar lemover avatar linjuanz avatar ljwljwljwljw avatar ngc7331 avatar poemonsense avatar sashimi-yzh avatar sequencer avatar wakafa1 avatar wonicon avatar xuyb1999 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nutshell's Issues

关于执行bootgen命令生成BOOT.BIN文件出现的错误

你好!

我根据文件standalone.md进行操作来生成BOOT.BIN,在更改完设备树路径并且根据要求创建了system_top_wrapper.hdf和system_top_wrapper.bit的软连接后
再次执行命令make bootgen PRJ=myprj BOARD=pynq STANDALONE=true
但是出现如下错误:

cd boot && hsi -nolog -nojournal -notrace -source mk.tcl -tclargs myproject-pynq true

****** hsi v2019.1.3 (64-bit)
**** SW Build 2644227 on Wed Sep 4 09:44:18 MDT 2019
** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.

start_gui
invalid command name "common::start_gui"
source mk.tcl -notrace
CRITICAL WARNING: [Board 49-71] The board_part definition was not found for tul.com.tw:pynq-z2:part0:1.0. The project's board_part property was not set, but the project's part property was set to xc7z020clg400-1. Valid board_part values can be retrieved with the 'get_board_parts' Tcl command. Check if board.repoPaths parameter is set and the board_part is installed from the tcl app store.
INFO: [Hsi 55-1698] elapsed time for repository loading 0 seconds
WARNING: not supported pl_clk:
WARNING: not supported pl_clk:
INFO: [Common 17-206] Exiting hsi at Fri Sep 9 03:51:55 2022...

错误提示not supported pl_plk;但是成功生成了BOOT.BIN
请问这是因为fsbl-loader编译时的问题还是其他原因呢?

之后将BOOT.BIN和RV_BOOT.BIN放入SD卡中上板启动串口打印信息如下
boot.jpg
卡在了fsbl-loader.c的main函数中的最后一步

xil_printf("Reset RISC-V core.\r\n");
/* release RISC-V reset signal */
gpio_base[0] = 0x1;

while(1);

return XST_SUCCESS;

请问这里复位不成功是什么原因呢?

还请指导一下!
感谢!

关于使用nemu仿真RV_BOOT.bin的报错

您好,最近在进行nemu仿真运行RV_BOOT.bin是遇到了如下问题:
我参考了 OpenXiangShan/NEMU#22 的中的问题解决办法,但考虑到nutshell这边fork的nemu和xiangshan的nemu在makefile上有较大改动。所以还是创建了这个issues,感谢您的帮助。

我的操作如下:

nemu clone from https://github.com/OSCPU/nemu
export ISA=riscv64

然后在/OSCPU/nemu根目录下make -j
最后生成/OSCPU/nemu/build
执行:
./build/riscv64-nemu-interpreter ../NutShell/fpga/boot/pynq/RV_BOOT.bin
得到报错如下:

address (0xe000002c) is out of bound {???} [0x00000000, 0x00000000] at pc = 0x000000008000266a
$0: 0x0000000000000000 ra: 0x0000000080001c0c sp: 0x000000008000bc30 gp: 0x0000000000000000 
tp: 0x0000000000000000 t0: 0x0000000000000009 t1: 0x0000000080006c78 t2: 0x0000000000000025 
s0: 0x000000008000bc41 s1: 0x0000000000000000 a0: 0x0000000000000062 a1: 0x0000000000000100 
a2: 0x00000000800071f4 a3: 0x000000008000bd78 a4: 0x00000000e0000000 a5: 0x00000000e0000000 
a6: 0x0000000000000000 a7: 0x000000000000000c s2: 0x0000000000000000 s3: 0x0000000000000000 
s4: 0x0000000000000000 s5: 0x0000000000000000 s6: 0x0000000000000000 s7: 0x0000000000000000 
s8: 0x0000000000000000 s9: 0x0000000000000000 s10: 0x0000000000000000 s11: 0x0000000000000000 
t3: 0x00000000800071f4 t4: 0x000000008000bc40 t5: 0x0000000000000015 t6: 0xffffffffffffffff 
pc: 0x000000008000266a mstatus: 0x0000000000000000 mcause: 0x0000000000000000 mepc: 0x0000000000000000
                       sstatus: 0x0000000000000000 scause: 0x0000000000000000 sepc: 0x0000000000000000
[src/monitor/cpu-exec.c,35,monitor_statistic] total guest instructions = 96815
riscv64-nemu-interpreter: src/device/io/map.c:21: check_bound: Assertion `map != ((void *)0) && addr <= map->high && addr >= map->low' failed.
已放弃 (核心已转储)

image

Debug打印的第一条IFU: pc = xxx, instr = xxx的数据是哪来的?

我这里的做法:修改了"main/scala/nutcore/frontend/Frontend.scala",把Debug改为printf:

110 class Frontend_inorder(implicit val p: NutCoreConfig) extends NutCoreModule with HasFrontendIO {
...
140   printf("------------------------ FRONTEND3:------------------------\n")
141   printf("flush = %b, ifu:(%d,%d), idu:(%d,%d)\n",
142     ifu.io.flushVec.asUInt, ifu.io.out.valid, ifu.io.out.ready, idu.io.in(0).valid, idu.io.in(0).ready)
143   printf("IFU: pc = 0x%x, instr = 0x%x\n", ifu.io.out.bits.pc, ifu.io.out.bits.instr)
144   printf("IDU1: pc = 0x%x, instr = 0x%x, pnpc = 0x%x\n", idu.io.in(0).bits.pc, idu.io.in(0).bits.instr, idu.io.in(0).bits.pnpc)

随后得到开机的第一批debug信息:

   1 ------------------------ FRONTEND3:------------------------
   2 flush = 0000, ifu:(0,1), idu:(0,1)
   3 **IFU: pc = 0x51cb89cba7, instr = 0xad62dbc3ceb8b73c**
   4 IDU1: pc = 0x3c0a28a0de, instr = 0xfc555d40d290bd26, pnpc = 0x70007f5151
   5 [IFUPC] pc:0080000000 pcUpdate:0 npc:0080000004 RedValid:0 RedTarget:7c636df2b9 LJL:0 LJTarget:0cdb22fc6e LJ:0 snpc:0080000004 bpValid:0 pnpn:0000000000
   6 [IFI] pc=0080000000 user=200400000020080000000 0 0 8
   7 [IFO] pc=51cb89cba7 inst=ad62dbc3ceb8b73c
   8 redirect to 0228654571

我想知道这个第一条IFU: pc = xxx, instr = xxx的数据是哪来的?我核对了microbench的bin中并没有这些指令啊。

我之所以这么问,是因为我把ram.v改写了,把microbench.v的内容写死在那个文件:
./difftest/src/test/vsrc/common/ram.v:

  17 /*import "DPI-C" function void ram_write_helper
  18 (
  19   input  longint    wIdx,
  20   input  longint    wdata,
  21   input  longint    wmask,
  22   input  bit        wen
  23 );
  24
  25 import "DPI-C" function longint ram_read_helper
  26 (
  27   input  bit        en,
  28   input  longint    rIdx
  29 );*/
  30 `define RAMWIDTH 64
  31
  32 module RAMHelper(
  33   input         clk,
  34   input         en,
  35   input  [`RAMWIDTH-1:0] rIdx,
  36   output reg [`RAMWIDTH-1:0] rdata,
  37   input  [`RAMWIDTH-1:0] wIdx,
  38   input  [`RAMWIDTH-1:0] wdata,
  39   input  [`RAMWIDTH-1:0] wmask,
  40   input reset,
  41   input         wen
  42 );
  43
  44   reg [`RAMWIDTH-1:0] ram [3399:0];
  45   always @(posedge clk) begin
  46     //ram_helper(rIdx, rdata, wIdx, wdata, wmask, wen);
  47     rdata <= ram[rIdx[11:0]];
  48     $display("%d, %0h", rIdx[11:0], ram[rIdx[11:0]]);
  49     if (reset) begin
  50 ram[0] <= 64'h0000f11700000413;
  51 ram[1] <= 64'h640040efffc10113;
  52 ram[2] <= 64'h01213823fd010113;
  53 ram[3] <= 64'h0141302301313423;
  54 ram[4] <= 64'h0281302302113423;

……

3446 ram[3396] <= 64'h0000000000000000;
3447 ram[3397] <= 64'h0;
3448 ram[3398] <= 64'h0;
3449 ram[3399] <= 64'h0;
3450 end
3451 else begin
3452 if (wen == 1'b1) begin
3453 ram[wIdx[11:0]] <= (ram[wIdx[11:0]] & ~wmask) | (wdata & wmask);
3454 end
3455 end
3456 end
3457
3458 endmodule

如此跑出的开机第一批debug信息不同:
左边是我改过ram.v的,右边是没改过ram.v的
https://s4.ax1x.com/2022/01/19/7D6jZ4.png

     1 ------------------------ FRONTEND3:------------------------                                   |     1 ------------------------ FRONTEND3:------------------------
     2 flush = 0000, ifu:(0,1), idu:(0,1)                                                            |     2 flush = 0000, ifu:(0,1), idu:(0,1)
     3 IFU: pc = 0x3fb9243dff, instr = 0x3323d33598a69ff9                                            |     3 IFU: pc = 0x51cb89cba7, instr = 0xad62dbc3ceb8b73c
     4 IDU1: pc = 0x1cc6f1bdf1, instr = 0x000000006faa5caa, pnpc = 0x1cc6f1bdf5                      |     4 IDU1: pc = 0x3c0a28a0de, instr = 0xfc555d40d290bd26, pnpc = 0x70007f5151
     5 [IFUPC] pc:0080000000 pcUpdate:0 npc:0080000004 RedValid:0 RedTarget:6245a270ca LJL:0 LJTarget|     5 [IFUPC] pc:0080000000 pcUpdate:0 npc:0080000004 RedValid:0 RedTarget:7c636df2b9 LJL:0 LJTarget
     6 [IFI] pc=0080000000 user=200400000020080000000 0 0 8                                          |     6 [IFI] pc=0080000000 user=200400000020080000000 0 0 8
     7 [IFO] pc=3fb9243dff inst=3323d33598a69ff9                                                     |     7 [IFO] pc=51cb89cba7 inst=ad62dbc3ceb8b73c
     8 redirect to 06e90ab70c                                                                        |     8 redirect to 0228654571
     9 ------------------------ FRONTEND3:------------------------                                   |     9 ------------------------ FRONTEND3:------------------------
    10 flush = 0000, ifu:(0,1), idu:(0,1)                                                            |    10 flush = 0000, ifu:(0,1), idu:(0,1)
    11 IFU: pc = 0x3fb9243dff, instr = 0x3323d33598a69ff9                                            |    11 IFU: pc = 0x51cb89cba7, instr = 0xad62dbc3ceb8b73c
    12 IDU1: pc = 0x1cc6f1bdf1, instr = 0x000000006faa5caa, pnpc = 0x1cc6f1bdf5                      |    12 IDU1: pc = 0x3c0a28a0de, instr = 0xfc555d40d290bd26, pnpc = 0x70007f5151
    13 [IFUPC] pc:0080000000 pcUpdate:0 npc:0080000004 RedValid:0 RedTarget:6245a270ca LJL:0 LJTarget|    13 [IFUPC] pc:0080000000 pcUpdate:0 npc:0080000004 RedValid:0 RedTarget:7c636df2b9 LJL:0 LJTarget
    14 [IFI] pc=0080000000 user=200400000020080000000 0 0 8                                          |    14 [IFI] pc=0080000000 user=200400000020080000000 0 0 8
    15 [IFO] pc=3fb9243dff inst=3323d33598a69ff9                                                     |    15 [IFO] pc=51cb89cba7 inst=ad62dbc3ceb8b73c
    16 redirect to 06e90ab70c                                                                        |    16 redirect to 0228654571

谢谢!

Is the project dead?

Hi,
Has the project been cancelled?
Because it shows that the latest commit was on 19 july.
Thanks

make emu 如何知道正确性

make emu 进行仿真,最后命令行一直在输出如下:

/ # root
-/bin/ash: root: not found
/ # root
-/bin/ash: root: not found
/ # root
-/bin/ash: root: not found
/ # root
-/bin/ash: root: not found
/ # root
-/bin/ash: root: not found
/ # root
-/bin/ash: root: not found
/ # root

请问这是正确的吗,如何知道仿真结果是否正确,不人为终止该仿真会一直进行下去吗

如何生成适合于自定义板卡的RV_BOOT.bin文件

在使用nutshell加载risc-v子系统时,需要加载bin文件,用了ready-to-run里面的linux.bin,在minicom中只显示了bbl loader何frequency,换了香山里面的ready-to-run 里面的linux.bin,能打印hello。RISC-V World! 之后又打印了一堆寄存器地址,最后停留在kernel panic not syncing:Attempted to kill init exitcode=0x00000004。
在查阅之前的issues,看到您之前回复其他人 “你好,这边建议使用我们预编好的内核镜像,在 NutShell/fpga/boot/pynq/RV_BOOT.bin;如果想要自行生成,Linux 配置请使用 riscv-linux/arch/riscv/configs/fpga_defconfig,其中一些选项需要根据实际情况酌情修改;riscv-pk 方面,请在 riscv-pk/dts 中使用合适的设备树,然后 make 即可,最终在 riscv-pk/build 目录下会得到 bbl.bin 文件,即为我们想要的 RV_BOOT.bin(名字默认的意思是后续的流程会直接使用“RV_BOOT.bin”文件名,因此需要手动将 bbl.bin 重命名为 RV_BOOT.bin)”
在riscv-linux/arch/riscv/configs/中没有fpga_defconfig 只有defconfig,在riscv-pk repo中也没有dts,在生成bbl.bin中设备树怎么用,有没有资料参考一下 ,用于生成自定义fpga板卡的RV_BOOT.bin

Something wrong when running on FPGA

I have downloaded this project and installed mill. I also run make and get the verilog file build/TopMain.v.

But when I try to run on FPGA, there is something wrong.

cd fpga
make PRJ=myproject BOARD=axu3cg 

# log 
make -C .. BOARD=axu3cg
make[1]: Entering directory '/home/hezf/Documents/chisel_test/nutShell'
make[1]: Nothing to be done for 'verilog'.
make[1]: Leaving directory '/home/hezf/Documents/chisel_test/nutShell'
vivado -nolog -nojournal -notrace -mode batch -source board/axu3cg/mk.tcl -tclargs myproject-axu3cg false

****** Vivado v2018.2 (64-bit)
  **** SW Build 2258646 on Thu Jun 14 20:02:38 MDT 2018
  **** IP Build 2256618 on Thu Jun 14 22:10:49 MDT 2018
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.

source board/axu3cg/mk.tcl -notrace
INFO: [BD_TCL-3] Currently there is no design <nutshell> in project, so creating one...
Wrote  : </home/hezf/Documents/chisel_test/nutShell/fpga/board/axu3cg/build/myproject-axu3cg/myproject-axu3cg.srcs/sources_1/bd/nutshell/nutshell.bd> 
create_bd_design: Time (s): cpu = 00:00:04 ; elapsed = 00:00:07 . Memory (MB): peak = 1254.473 ; gain = 35.852 ; free physical = 8239 ; free virtual = 15436
INFO: [BD_TCL-4] Making design <nutshell> as current_bd_design.
INFO: [BD_TCL-5] Currently the variable <design_name> is equal to "nutshell".
INFO: [BD_TCL-6] Checking if the following IPs exist in the project's IP catalog:  
xilinx.com:ip:axi_protocol_converter:2.1 xilinx.com:ip:system_ila:1.1 xilinx.com:ip:util_vector_logic:2.0  .
INFO: [BD_TCL-6] Checking if the following modules exist in the project's sources:  
NutShell  .
INFO: [IP_Flow 19-5151] The Range '63:0' is present in all ports of the interface 'io_mmio_req_bits'. It is assumed that this is meant to declare an array of interface. If this is not the desired behaviour, switch of this feature by disabling the parameter 'ips.enableInterfaceArrayInference'.
INFO: [IP_Flow 19-5151] The Range '63:0' is present in all ports of the interface 'io_mmio_resp_bits'. It is assumed that this is meant to declare an array of interface. If this is not the desired behaviour, switch of this feature by disabling the parameter 'ips.enableInterfaceArrayInference'.
INFO: [IP_Flow 19-5107] Inferred bus interface 'io_frontend' of definition 'xilinx.com:interface:aximm:1.0' (from Xilinx Repository).
WARNING: [IP_Flow 19-4747] Not inferring AXIMM interface 'io_mem' due to missing master read-channel signals RREADY.
INFO: [IP_Flow 19-5107] Inferred bus interface 'reset' of definition 'xilinx.com:signal:reset:1.0' (from Xilinx Repository).
INFO: [IP_Flow 19-5107] Inferred bus interface 'clock' of definition 'xilinx.com:signal:clock:1.0' (from Xilinx Repository).
INFO: [IP_Flow 19-4728] Bus Interface 'clock': Added interface parameter 'ASSOCIATED_BUSIF' with value 'io_frontend'.
INFO: [IP_Flow 19-4728] Bus Interface 'clock': Added interface parameter 'ASSOCIATED_RESET' with value 'reset'.
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1704] No user IP repositories specified
INFO: [Device 21-403] Loading part xczu3cg-sfvc784-1-e
create_bd_cell: Time (s): cpu = 00:00:15 ; elapsed = 00:00:24 . Memory (MB): peak = 2257.492 ; gain = 530.430 ; free physical = 7419 ; free virtual = 14763
WARNING: [BD 5-232] No interface pins matched 'get_bd_intf_pins NutShell_0/io_mem'
ERROR: [BD 5-106] Arguments to the connect_bd_intf_net command cannot be empty.
ERROR: [Common 17-39] 'connect_bd_intf_net' failed due to earlier errors.

    while executing
"connect_bd_intf_net -intf_net NutShell_0_io_mem [get_bd_intf_pins NutShell_0/io_mem] [get_bd_intf_pins axi_interconnect_2/S00_AXI]"
    (procedure "create_root_design" line 91)
    invoked from within
"create_root_design """
    (file "board/axu3cg/../../NutShell.tcl" line 400)

    while executing
"source ${tcl_file}"
    (procedure "add_bd" line 2)
    invoked from within
"add_bd ${fpga_dir}/NutShell.tcl"
    invoked from within
"if {${standalone} == "true"} {
  add_bd ${bd_dir}/standalone.tcl
  make_wrapper -files [get_files *system_top.bd] -top
  add_files -norecurse -fileset..."
    (file "board/axu3cg/../common.tcl" line 55)

    while executing
"source ${script_dir}/../common.tcl"
    (file "board/axu3cg/mk.tcl" line 21)
INFO: [Common 17-206] Exiting Vivado at Mon Dec 27 22:26:38 2021...
Makefile:19: recipe for target 'board/axu3cg/build/myproject-axu3cg/myproject-axu3cg.xpr' failed
make: *** [board/axu3cg/build/myproject-axu3cg/myproject-axu3cg.xpr] Error 1

Although come across this error , I find .xpr in fpga/board/axu3cg/build/myproject-axu3cg/, But when open this project with vivado, nutshell.bd is empty. What is next step?

Is there any more details about running on fpga? Thanks very much.

make emu error

***** What happened *****
$ make emu
mkdir -p build
mill chiselModule.test.runMain top.TopMain -td build --output-file NutShellSimTop.v BOARD=sim CORE=seq
Preparing Java 14-ea runtime; this may take a minute or two ...
Compiling ~/OSCPU/NutShell.git/build.sc
build.sc:5: value repositories is not a member of mill.Module with mill.scalalib.ZincWorkerModule
def repositories() = super.repositories ++ Seq(
^
build.sc:5: T.sources definitions must have 0 parameter lists
def repositories() = super.repositories ++ Seq(
^
build.sc:4: illegal inheritance;
self-type build.this.CustomZincWorkerModule.type does not conform to mill.scalalib.ZincWorkerModule's selftype mill.scalalib.ZincWorkerModule with mill.scalalib.CoursierModule
object CustomZincWorkerModule extends ZincWorkerModule {
^
Compilation Failed

**** Software environment *****
$ java --version
openjdk 14-ea 2020-03-17
OpenJDK Runtime Environment (build 14-ea+18-Ubuntu-1)
OpenJDK 64-Bit Server VM (build 14-ea+18-Ubuntu-1, mixed mode, sharing)

$ mill --version
Mill Build Tool version 0.8.0
Java version: 14-ea, vendor: Private Build, runtime: /usr/lib/jvm/java-14-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "Linux", version: 5.0.0-38-generic, arch: amd64

$ verilator --version
Verilator 4.016 2019-06-16 rev UNKNOWN_REV

$ gcc --version
gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Can not boot RISC-V subsystem on axu3eg Board ?

I sucessfully build system_top.bit file for axu3eg Board and use petalinux to boot linux in arm core.
Then I follow the step in README.md-Boot NutShell.

gcc -O2 -o ddr-loader ddr-loader.c
./ddr-loader axu3cg linux.bin # in ready-to-run folder

The output shows:

Welcome to minicom 2.7.1

OPTIONS: I18n
Compiled on Aug 13 2017, 15:25:34.
Port /dev/ttyUL1, 08:17:02

Press CTRL-A Z for help on special keys

bbl loader
freq-mhz = 500
CLINT: set frequency to 500 MHz

if use ./ddr-loader zcu102 linux.bin, it shows 'Segmentation fault (core dumped)'.

xilinx@pynq:/home/nutshell$ sudo ./ddr-loader zcu102 linux.bin
board = zcu102, ddr_size = 0x80000000, ddr_base = 0x800000000
mapping paddr 0x800000000 to vaddr 0x7f3d748000
mapping paddr 0x[  231.709977] Bad mode in Error handler detected on CPU2, code 0xbf000000 -- SError
[  231.722988] Internal error: Oops - bad mode: 0 [#1] SMP
[  231.728202] Modules linked in: icfc(O) uio_pdrv_genirq
[  231.733336] CPU: 2 PID: 3480 Comm: ddr-loader Tainted: G           O    4.14.0-xilinx-v2018.3 #1
[  231.742107] Hardware name: xlnx,zynqmp (DT)
[  231.746275] task: ffffffc87b15a600 task.stack: ffffff800e560000
[  231.752177] PC is at 0x7fbd811f90
[  231.755474] LR is at 0x55692e9da8
[  231.758773] pc : [<0000007fbd811f90>] lr : [<00000055692e9da8>] pstate: 60000000
70010[0 0 02 3t1o. 7v6a6d1d5r0 ]0 xs7pf b:d 80e0c0000000
 fldoaa76ac0
2ing linux.bin [t o  2o3f1f.s7e7t2 4=0 00]x 0x
 9: 0000007fda276ac0 x28: 0000000000000000
[  231.780472] x27: 0000000000000000 x26: 0000000000000000
[  231.785768] x25: 0000007fda277e03 x24: 00000055692fac30
[  231.791071] x23: 0000000000000000 x22: 0000007fda276c58
[  231.796374] x21: 00000055692fa000 x20: 00000055692fac90
[  231.801678] x19: 00000055692fb028 x18: 0000007fda276977
[  231.806982] x17: 0000007fbd811f90 x16: 00000055692faf88
[  231.812285] x15: 0000000000000010 x14: 0000000000000000
[  231.817588] x13: 0000000000000000 x12: 0000000000000020
[  231.822883] x11: 0000007fda276978 x10: 0000000000000000
[  231.828178] x9 : 00000000ffffffff x8 : 0000000000000040
[  231.833473] x7 : 000000000000000a x6 : 000000000000000a
[  231.838768] x5 : 000000557cc58282 x4 : 0000000000000022
[  231.844063] x3 : 0000000000000000 x2 : 7f70de81dbc25800
[  231.849358] x1 : 0000007fbd8ec000 x0 : 00000000000003e8
[  231.854662] Process ddr-loader (pid: 3480, stack limit = 0xffffff800e560000)
[  231.861694] ---[ end trace 2843468e7585934a ]---
Segmentation fault (core dumped)

CPU hangs up when accessing memory just below MMIO address space

I'm using the following settings on my FPGA board:

object MyFPGASettings {
  def apply() = Map(
    "NrExtIntr" -> 3,
    "ResetVector" -> 0x10000000L,
    "MMIOBase" -> 0x0000000080000000L,
    "MMIOSize" -> 0x0000000080000000L
  )
}

This makes 0x80000000-0xffffffff MMIO address space and I can use 0x40000000-0x7fffffff as memory address space.

However, when I try to access memory at 0x7fffffc0, the system hangs up . I wonder if this memory access will trigger Prefetcher to prefetch memory at 0x80000000 (but actually in MMIO address space) and thus hang up the entire system?

Run on FPGA 在使用vivado generate bitstream 时报错

vivado 版本是2019.1
执行

cd fpga
make PRJ=myproject BOARD=pynq STANDALONE=true

成功构建vivado,但是在打开工程generate bitstream时出现下面的错误

SynthesisOut-of-Context Module Runsnutshellnutshell_NutShell_0_0_synth_1[Synth 8-439] module 'array_ext' not found ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":24646]
[Synth 8-6156] failed synthesizing module 'array' ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":24632]
[Synth 8-6156] failed synthesizing module 'SRAMTemplate' ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":16]
[Synth 8-6156] failed synthesizing module 'BPU_inorder' ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":146]
[Synth 8-6156] failed synthesizing module 'IFU_inorder' ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":424]
[Synth 8-6156] failed synthesizing module 'Frontend_inorder' ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":2453]
[Synth 8-6156] failed synthesizing module 'NutCore' ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":14128]
[Synth 8-6156] failed synthesizing module 'NutShell' ["C:/home/dujiaming/Desktop/xs-env/NutShell/build/TopMain.v":22014]
[Synth 8-6156] failed synthesizing module 'nutshell_NutShell_0_0' ["C:/home/dujiaming/Desktop/xs-env/NutShell/fpga/board/axu3cg/build/myproject-axu3cg/myproject-axu3cg.srcs/sources_1/bd/nutshell/ip/nutshell_NutShell_0_0/synth/nutshell_NutShell_0_0.v":58]
[Common 17-69] Command failed: Synthesis failed - please see the console or run log file for details

尝试把BOARD改为axu3cg,出现同样的错误。
请问这个错误出现的原因可能是哪一部分的问题?

I want Nutshell link in difftest,but it make some mistakes.

hi,I want Nutshell link in difftest,but it make some mistakes.
~/Downloads/NutShell$ ./build/emu -b 0 -e 0 -i ../nexus-am/apps/microbench/build/microbench-riscv64-nutshell.bin
Emu compiled at Feb 6 2022, 18:12:45 The image is ../nexus-am/apps/microbench/build/microbenc-riscv64-nutshell.bin Using simulated 8192MB RAM Cound not mmap 0x200000000 bytes emu: /home/jimswei/Downloads/NutShell/difftest/src/test/csrc/common/ram.cpp:134: void init_ram(const char*): Assertion 0' failed.
Aborted (core dumped)
~/Downloads/NutShell/debug$ make cpu cat: cpu.log: No such file or directory
make -C /home/jimswei/Downloads/nexus-am/tests/cputest ARCH=riscv64-noop LOG_BEGIN=0 LOG_END=0 ALL=dummy run
make[1]: Entering directory '/home/jimswei/Downloads/nexus-am/tests/cputest'
/home/jimswei/Downloads/nexus-am/Makefile.check:16: *** Invalid ARCH. Supported: riscv64-nutshell. Stop.
make[1]: Leaving directory '/home/jimswei/Downloads/nexus-am/tests/cputest'
make: *** [Makefile:25: cpu] Error 2
`
but it is right in https://www.bilibili.com/video/BV1PU4y1V7X3?p=9

关于mem的地址分配

您好,
关于内存接口的地址范围存在一些疑问:

1、请问现在的nutshell是否有对mem访存地址范围的限制(32位宽,4GB之内)?
2、可以生成多个mem接口吗?
3、在src/main/scala/top/Settings.scala中我看到有MemMapRegionBits的设置,是否指em的地址范围必须是2^n对齐的,同时需要是一段连续的内存地址空间?如果设计需要用两端不连续的地址范围,应该如何设置呢

祝好!

如何跑单个测试

marobench 里面包含好多个测试程序,能否写一段程序并进行测试呢?

difftest.cpp:40: void init_difftest(rtlreg_t*): Assertion `handle' failed.

Hi mates,

While I run the simulation by 'make emu', I met 2 issues:

make[1]: Leaving directory '/NutShell/build/emu-compile'
Using seed = 7348
The image is ready-to-run/linux.bin
[warning] sdcard img not found
emu: /NutShell/src/test/csrc/difftest.cpp:40: void init_difftest(rtlreg_t*): Assertion `handle' failed.
make: *** [Makefile:100: emu] Aborted

As above shown, there is a warning that image files were not found, this issue has been solved after I modified the sdcard.cpp in folder $NUTSHELL_HOME/src/test/csrc/.
But, the 2nd issue still couldn't be solved, in Makefile, default REF_SO has been setup correctly, why assertion 'handle' still failed?

Thanks!

Bootgen error for pynq board

I follow the step in /fpga/boot/standalone.md and want to get BOOT.BIN for pynq-z2 .
Generate verilog for pynq first and create a project in Vivado

make verilog BOARD=pynq
cd $(NUTSHELL_HOME)/fpga
make PRJ=myprj BOARD=pynq STANDALONE=true vivado

Bitstream and hdf file has been generated successfully.
But after linking ps.hdf and fpga.bit, there is something wrong when make bootgen PRJ=myprj BOARD=pynq STANDALONE=true

hezf@thuos:~/Documents/chisel_test/NutShell/fpga$ make bootgen PRJ=m3 BOARD=pynq STANDALONE=true
cd boot && hsi -nolog -nojournal -notrace -source mk.tcl -tclargs m3-pynq true

****** hsi v2019.1.3 (64-bit)
  **** SW Build 2644227 on Wed Sep  4 09:44:18 MDT 2019
    ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.

start_gui
invalid command name "common::start_gui"
source mk.tcl -notrace
CRITICAL WARNING: [Board 49-71] The board_part definition was not found for tul.com.tw:pynq-z2:part0:1.0. The project's board_part property was not set, but the project's part property was set to xc7z020clg400-1. Valid board_part values can be retrieved with the 'get_board_parts' Tcl command. Check if board.repoPaths parameter is set and the board_part is installed from the tcl app store.
INFO: [Hsi 55-1698] elapsed time for repository loading 0 seconds
open_hw_design: Time (s): cpu = 00:00:05 ; elapsed = 00:00:05 . Memory (MB): peak = 864.000 ; gain = 194.016 ; free physical = 10376 ; free virtual = 14046
invalid command name "hsi::utils::get_rp_rm_for_drv"
ERROR: [Hsi 55-1545] Problem running tcl command ::sw_device_tree::generate : invalid command name "hsi::utils::get_rp_rm_for_drv"
    while executing
"hsi::utils::get_rp_rm_for_drv $drv_handle"
    (procedure "set_drv_def_dts" line 14)
    invoked from within
"set_drv_def_dts $drv_handle"
    (procedure "gen_peripheral_nodes" line 54)
    invoked from within
"gen_peripheral_nodes $drv_handle "create_node_only""
    ("foreach" body line 3)
    invoked from within
"foreach drv_handle [get_drivers] {
        # generate the default properties
        gen_peripheral_nodes $drv_handle "create_node_only"
        gen_r..."
    (procedure "::sw_device_tree::generate" line 3)
    invoked from within
"::sw_device_tree::generate device_tree"
ERROR: [Hsi 55-1442] Error(s) while running TCL procedure generate()
ERROR: [Common 17-39] 'generate_target' failed due to earlier errors.

    while executing
"generate_target -dir ${build_dir}/dts"
    (file "mk.tcl" line 77)
hsi% quit
INFO: [Common 17-206] Exiting hsi at Fri Dec 31 22:00:56 2021...

Why ‘genrate_target’ failed? The pynq-z2 is also in board_files, why 'CRITICAL WARNING'?

Where is the ‘device-tree-xlnx’ for pynq?

Thanks a lot and happy new year!

在本项目目录ready-to-run下的microbench.bin中的代码段运行指令不明确

我们使用了您项目下的microbench.bin结合difftest对我们的riscv处理器进行了测试。在测试过程中发现处理器执行到了pc:0x80004638,这个地址对应的指令是0005006b。我使用了gcc工具链进行反汇编并没有确定这条指令的具体功能,在官方文档中也未能确认到合适的指令。所以想请问您是否知晓这条指令的具体内容及执行逻辑。感谢您的解答。

如何去除difftest和nemu直接跑linux.bin或者microbench.bin?

我make emu能过,但是我做了一些改动,把microbench.bin的内容写入了ram.v里面,想试图直接从RAM里面启动microbench或者linux(有点类似RISC_SPM的玩法)。但是发现make emu依赖了difftest和nemu(CPPFLAGS=-DREF_SO=\"./ready-to-run/riscv64-nemu-interpreter-so\")。

求问有什么方法绕过difftest和nemu吗?

询问: BOOT.BIN文件中的u-boot.elf 对PYNQ的启动是否没有影响?

您好!

我们希望移植PYNQ版本的NutShell设计到Kintex平台, 需要把PNYQ里面PS部分的外设移植到Kintex上:

  • PS_DDR: 我们改为使用Xilinx MIG;
  • SDCard: 我们借助其他开源Riscv以及开源SDController, 可以挂载SD卡, 并读取文件到DDR中;
  • PS_UART: 我们改为使用Xilinx的AXI UARTLite IP;

软件环境部分:

  • PYNQ中, 对NutShell的复位操作在FSBL中实现: 我们现在打算先用VIO来直接操作;
  • SDcard内 RV_BOOT.bin文件copy到DDR中, 再FSBL中实现: 我们现在使用开源RiscV/SDController来实现;
  • UARTLite : 我们打算重编DTS/Linux_image;

我们注意到, PYNQ的BOOT.bin中, 含有u-boot.elf, 从README的介绍来看, u-boot是用于PS侧, 打通SDcard/以太网,
可以用于更新 dts/linux image文件;

如果我们不打算使用u-boot的功能, 那么生成BOOT.BIN时, 是否可以不包含u-boot.elf文件? 或者 用空文件来替代??

望您指点一二;

谢谢

Will you maintain NutShell all the time?

你好,请问你们会一直更新这个项目么,还是学生毕业之后就停止维护了?我之前也从事过RISC-V CPU的设计工作,如果一直有人来更新的话,我希望有机会能和维护人认识一下,也许可以加个微信/qq交流一下想法?

where is Noop ?

Is Noop a open source project?
If it is, where is it?
I cannot find any repo about it, could you please show me the url of Noop repo to me?
Thanks!

如何用nexus-am编译出可以在nutshell-pynq上运行的裸机程序

我将nexus-am中的物理起始地址以及uartlite mmio地址改为pynq setting中的0x60000000和0xe0000000,并把/fpga/resource/fsbl-loader.c中的文件名改成了所需文件名。将重新生成的BOOT.BIN和所需.bin文件放入sd卡中,但是fpga没有任何输出。想请问还需要对nexus-am代码做什么改动?

Is it possible to use Virtual memory?

Hi,
I'm trying to run NutShell ooo.

While I see the chisel source, I can find the TLB and virtual memory is implemented.
But I could not find how to enable the implemented logic.
So whenever I compile the CPU, It seems it is built with no virtual memory.

I already checked that EnableVirtualMemory is true.
I'm using tag release-211228.

Is it possible to build CPU with virtual memory enabled?

构建工程出现问题

请问,我已经安装了mill,可是仍然出现下述的构建问题

image

是因为版本不对应吗?我的版本是0.9.3

image

Ready signal depends on valid signal in cache?

Hi NutShell team,

I'm trying to connect NutShell (commit hash: 913675fe5b6819b9c5cd6defa24ff80f6876ee8e) with a customized memory system with AXI4 interface that ready signals may depend on valid signals, but coming up with a combinational loop as follows.

NutShellSimTop.soc.io_frontend_b_valid
... (My AXI4 memory module)
NutShellSimTop.soc.io_frontend_b_ready   @[NutShellSim.scala 81:26]
NutShellSimTop.soc.axi2sb.io_in_b_ready  @[NutShell.scala 62:16]
NutShellSimTop.soc.axi2sb._T_41  @[ToAXI4.scala 128:96]
NutShellSimTop.soc.axi2sb._T_42  @[ToAXI4.scala 128:73]
NutShellSimTop.soc.axi2sb.io_out_resp_ready      @[ToAXI4.scala 128:18]
NutShellSimTop.soc.nutcore.io_frontend_resp_ready        @[NutShell.scala 63:23]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1.io_in_3_resp_ready    @[NutCore.scala 165:23]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1._GEN_44       @[Crossbar.scala 116:13]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1._io_in_inflightSrc__resp_ready        @[Crossbar.scala 116:13 Crossbar.scala 116:13 Crossbar.scala 116:13 Crossbar.scala 116:13]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1.io_out_resp_ready     @[Crossbar.scala 116:13]
NutShellSimTop.soc.nutcore.Cache_1.io_in_resp_ready      @[Cache.scala 684:17]
NutShellSimTop.soc.nutcore.Cache_1.s3.io_out_ready       @[Cache.scala 499:14]
NutShellSimTop.soc.nutcore.Cache_1.s3._T_189     @[Cache.scala 337:35]
NutShellSimTop.soc.nutcore.Cache_1.s3.respToL1Fire       @[Cache.scala 337:51]
NutShellSimTop.soc.nutcore.Cache_1.s3._T_303     @[Cache.scala 433:178]
NutShellSimTop.soc.nutcore.Cache_1.s3._T_305     @[Cache.scala 433:194]
NutShellSimTop.soc.nutcore.Cache_1.s3._T_306     @[Cache.scala 433:161]
NutShellSimTop.soc.nutcore.Cache_1.s3._T_315     @[Cache.scala 432:37]
NutShellSimTop.soc.nutcore.Cache_1.s3._T_316     @[Cache.scala 432:31]
NutShellSimTop.soc.nutcore.Cache_1.s3.io_out_valid       @[Cache.scala 432:16]
NutShellSimTop.soc.nutcore.Cache_1._T_16         @[Cache.scala 505:43]
NutShellSimTop.soc.nutcore.Cache_1._T_18         @[Cache.scala 505:26]
NutShellSimTop.soc.nutcore.Cache_1.io_in_resp_valid      @[Cache.scala 499:14 Cache.scala 505:20]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1.io_out_resp_valid     @[Cache.scala 684:17]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1._io_in_inflightSrc_resp_valid         @[Crossbar.scala 115:13]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1._GEN_3        @[Crossbar.scala 115:13]
NutShellSimTop.soc.nutcore.SimpleBusCrossbarNto1_1.io_in_3_resp_valid    @[Crossbar.scala 113:26 Crossbar.scala 115:13]
NutShellSimTop.soc.nutcore.io_frontend_resp_valid        @[NutCore.scala 165:23]
NutShellSimTop.soc.axi2sb.io_out_resp_valid      @[NutShell.scala 63:23]
NutShellSimTop.soc.axi2sb._T_56  @[ToAXI4.scala 134:27]
NutShellSimTop.soc.axi2sb.io_in_b_valid  @[ToAXI4.scala 134:15]
NutShellSimTop.soc.io_frontend_b_valid   @[NutShell.scala 62:16]

In CacheStage3 module, io.out.valid depends on respToL1Fire, while respToL1Fire depends on io.out.ready. Does it break the AXI specs that valid should not depend on ready?

Thanks!

New transient execution attack on NutShell.

Hi,
Currently, I'm running a tool to find transient execution vulnerabilities in an open-source CPU.
While running it on NutShell, I found a new sort of transient execution vulnerability in NutShell.

While transient execution vulnerabilities are not considered a lot (and fixed) in today's open-source CPUs,
At least, I think it would be meaningful for the CPU developers, and software developers on top of that to know which transient execution attacks are possible on their CPU.

The attached PoC is a Spectre type attack. To be specific, the attack is based on two points: 1) port contention on division unit, and 2) variable latency of division operation depending on input value. When a victim contains an instruction sequence as follow,

... /* delayed computation which outputs a1 (e.g., memory, multiply) */
(1) div a0, a0, a1       /* instruction using division unit */
(2) beq a0, a2, 1f       /* misspeculated branch depending on a0 */
    lw t0, [secret]
(3) remuw t0, t0, a3     /* instruction using division unit */
...

If the dependency of instruction (3) is resolved earlier than instruction (1), it can be dispatched earlier than (1), even if it is a transient instruction. Then, (1) can only be dispatched after the computation of (3) completes. Since the misspeculated branch (2) depends on (1), the branch is resolved only when (1) finishes. However, since the completion time of (3) depends on the secret, the branch resolution time finally depends on the secret. Thus, the attacker can reconstruct the secret by measuring the branch resolution time.

I attach the PoC file below, and the attack can be reproduced as follow:

unzip poc.zip
cd poc
cp nutshell.patch $NUTSHELL_HOME/
cp nemu.patch $NEMU_HOME/
cp nexus-am.patch $AM_HOME/
cp -r birgus $AM_HOME/apps

/* patch */
cd $NUTSHELL_HOME; patch -p1 < nutshell.patch
cd $NEMU_HOME; patch -p1 < nemu.patch
cd $AM_HOME; patch -p1 < nexus-am.patch

/* build poc */
cd $AM_HOME/apps/birgus; make ARCH=riscv64-nutshell


/* build cpu */
cd $NUTSHELL_HOME; make ./build/emu
/* run poc */
./build/emu -i $AM_HOME/apps/birgus/build/birgus-riscv64-nutshell.bin -b 0 -e 0 

poc.zip

ram.cpp模型中的ram,当前周期读出rdata,不太现实吧?

在ram.cpp中,用ram_read_helper读出了ram的数据,然后当周期就返回给ram.v的输出rdata。这个有点不太现实了吧。如果我改写成非阻塞赋值,写在always块中,延迟一个周期回数据给rdata,跑出来的结果就不对了:

 31 module RAMHelper(
 32   input         clk,
 33   input         en,
 34   input  [63:0] rIdx,
 35   output reg [63:0] rdata,
 36   input  [63:0] wIdx,
 37   input  [63:0] wdata,
 38   input  [63:0] wmask,
 39   input         reset,
 40   input         wen
 41 );
 42   reg [63:0] rdata_this;
 43   assign rdata_this = ram_read_helper(en, rIdx);
 44   always @(posedge clk) begin
 45     ram_write_helper(wIdx, wdata, wmask, wen && en);
 46     rdata <= rdata_this;
 47   end
 48
 49 endmodule

请问本设计上FPGA板或者要进行ASIC设计时,ram改如何处理?是不是有参数可以调节ram的实际延迟周期数?

make emu时emu: NutShell/src/test/csrc/difftest.cpp:40: void init_difftest(rtlreg_t*): Assertion `handle' failed.

根据文档安装依赖后,make emu会报出如下信息

CPPFLAGS=-DREF_SO=\\\"./ready-to-run/riscv64-nemu-interpreter-so\\\" make -C ./build/emu-compile/ -f /home/rv/riscv/NutShell/build/emu-compile/VNutShellSimTop.mk
make[1]: Entering directory '/home/rv/riscv/NutShell/build/emu-compile'
make[1]: Nothing to be done for 'default'.
make[1]: Leaving directory '/home/rv/riscv/NutShell/build/emu-compile'
Using seed = 2523
The image is ready-to-run/linux.bin
[warning] sdcard img not found
emu: /home/rv/riscv/NutShell/src/test/csrc/difftest.cpp:40: void init_difftest(rtlreg_t*): Assertion `handle' failed.
make: *** [Makefile:102: emu] Aborted (core dumped)

A problem with the address of the pynq board

I looked at the .tcl file related to pynq in the Nutshell repository (NutShell/fpga/board/pynq/bd/standalone.tcl), and found that the address assigned to the front interface is 0x60000000+0x20000000, and the mem interface is 0x10000000+0x10000000. After reset, the pc is set to 0x60000000, which is also the starting address of the front interface (NutShell/src/main/scala/top/Settings.scala).

As far as I know, the front interface and the Mem interface should actually be the same memory space, so why the address range of the front bus is larger than that of the Mem bus, and where is the address translation done?

Looking forward to the reply from the designers of the open source community. Best regards!

difftest scala消失了。这个在香山里面有。建议提交代码前clean一下,或者删掉 difftest库。

difftest:
https://github.com/OpenXiangShan/difftest
香山里面自己有diff代码,果壳没有对应的代码上传。

报错信息
[info] compiling 77 Scala sources to /home/bigdot/git2/NutShell/out/chiselModule /compile.dest/classes ...
[error] /home/bigdot/git2/NutShell/src/main/scala/device/AXI4UART.scala:24:8: no t found: object difftest
[error] import difftest._
[error] ^
[error] /home/bigdot/git2/NutShell/src/main/scala/device/AXI4UART.scala:26:67: n ot found: type UARTIO
[error] class AXI4UART extends AXI4SlaveModule(new AXI4Lite, _extra = new UARTIO

Unable to synthesize the design in Vivado 2021.2

Hi, I'm compling the design into Verilog with command make PRJ=myproject BOARD=pynq STANDALONE=true and with default settings. However, the compiled code contains some depth-1 array in the EmbeddedTLBMD module, and when I synthesize the code with Vivado 2021.2, it says [Synth 8-2913] Unsupported Dual Port Block-RAM template for tlbmd_3_reg and reasons to cause this error contains Write port has constant address. and Only 1 word in RAM . These are both true. Array tlbmd_0 to tlbmd_3 does have only one element and address input is constant (beacuse the entry count of the ITLB declared in NutCore.scala is only 4, so depth of the array = TotalEntry / Ways = 1).

A simple way to fix this problem is by manually adding a platform-specific attribute ram_style to these signals repectively, and set the values to registers, as follows, so the arrays can be implemented with registers. (I don't know if the line contains the attribute can be added without users' intervention (by Chisel comilers))

  (* ram_style = "registers" *) 
  reg [120:0] tlbmd_0 [0:0];

The ram_style attribute is also abled to be set using elaberation-time constrains, however an additional XDC file is required in this situation. I'm not sure which is the most appropiate approach to solve the problem.

The following is EmbeddedTLBMD module in the generated code, and only the array tlbmd_0 to tlbmd_3 are related to the issue.

module EmbeddedTLBMD(
  input          clock,
  input          reset,
  output [120:0] io_tlbmd_0,
  output [120:0] io_tlbmd_1,
  output [120:0] io_tlbmd_2,
  output [120:0] io_tlbmd_3,
  input          io_write_wen,
  input  [3:0]   io_write_waymask,
  input  [120:0] io_write_wdata,
  output         io_ready
);
`ifdef RANDOMIZE_MEM_INIT
  // ......
`endif // RANDOMIZE_REG_INIT
  reg [120:0] tlbmd_0 [0:0]; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_0_MPORT_en; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_0_MPORT_addr; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_0_MPORT_data; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_0_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_0_MPORT_1_addr; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_0_MPORT_1_mask; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_0_MPORT_1_en; // @[EmbeddedTLB.scala 51:18]
  reg [120:0] tlbmd_1 [0:0]; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_1_MPORT_en; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_1_MPORT_addr; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_1_MPORT_data; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_1_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_1_MPORT_1_addr; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_1_MPORT_1_mask; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_1_MPORT_1_en; // @[EmbeddedTLB.scala 51:18]
  reg [120:0] tlbmd_2 [0:0]; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_2_MPORT_en; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_2_MPORT_addr; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_2_MPORT_data; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_2_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
  wire [0:0] tlbmd_2_MPORT_1_addr; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_2_MPORT_1_mask; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_2_MPORT_1_en; // @[EmbeddedTLB.scala 51:18]
  reg [120:0] tlbmd_3 [0:0]; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_3_MPORT_en; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_3_MPORT_addr; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_3_MPORT_data; // @[EmbeddedTLB.scala 51:18]
  wire [120:0] tlbmd_3_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
  wire [0:0] tlbmd_3_MPORT_1_addr; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_3_MPORT_1_mask; // @[EmbeddedTLB.scala 51:18]
  wire  tlbmd_3_MPORT_1_en; // @[EmbeddedTLB.scala 51:18]
  reg  resetState; // @[EmbeddedTLB.scala 55:27]
  wire  _GEN_1 = resetState ? 1'h0 : resetState; // @[EmbeddedTLB.scala 57:22 55:27 57:35]
  wire [3:0] waymask = resetState ? 4'hf : io_write_waymask; // @[EmbeddedTLB.scala 66:20]
  assign tlbmd_0_MPORT_en = 1'h1;
  assign tlbmd_0_MPORT_addr = 1'h0;
  assign tlbmd_0_MPORT_data = tlbmd_0[tlbmd_0_MPORT_addr]; // @[EmbeddedTLB.scala 51:18]
  assign tlbmd_0_MPORT_1_data = resetState ? 121'h0 : io_write_wdata;
  assign tlbmd_0_MPORT_1_addr = 1'h0;
  assign tlbmd_0_MPORT_1_mask = waymask[0];
  assign tlbmd_0_MPORT_1_en = resetState | io_write_wen;
  assign tlbmd_1_MPORT_en = 1'h1;
  assign tlbmd_1_MPORT_addr = 1'h0;
  assign tlbmd_1_MPORT_data = tlbmd_1[tlbmd_1_MPORT_addr]; // @[EmbeddedTLB.scala 51:18]
  assign tlbmd_1_MPORT_1_data = resetState ? 121'h0 : io_write_wdata;
  assign tlbmd_1_MPORT_1_addr = 1'h0;
  assign tlbmd_1_MPORT_1_mask = waymask[1];
  assign tlbmd_1_MPORT_1_en = resetState | io_write_wen;
  assign tlbmd_2_MPORT_en = 1'h1;
  assign tlbmd_2_MPORT_addr = 1'h0;
  assign tlbmd_2_MPORT_data = tlbmd_2[tlbmd_2_MPORT_addr]; // @[EmbeddedTLB.scala 51:18]
  assign tlbmd_2_MPORT_1_data = resetState ? 121'h0 : io_write_wdata;
  assign tlbmd_2_MPORT_1_addr = 1'h0;
  assign tlbmd_2_MPORT_1_mask = waymask[2];
  assign tlbmd_2_MPORT_1_en = resetState | io_write_wen;
  assign tlbmd_3_MPORT_en = 1'h1;
  assign tlbmd_3_MPORT_addr = 1'h0;
  assign tlbmd_3_MPORT_data = tlbmd_3[tlbmd_3_MPORT_addr]; // @[EmbeddedTLB.scala 51:18]
  assign tlbmd_3_MPORT_1_data = resetState ? 121'h0 : io_write_wdata;
  assign tlbmd_3_MPORT_1_addr = 1'h0;
  assign tlbmd_3_MPORT_1_mask = waymask[3];
  assign tlbmd_3_MPORT_1_en = resetState | io_write_wen;
  assign io_tlbmd_0 = tlbmd_0_MPORT_data; // @[EmbeddedTLB.scala 52:12]
  assign io_tlbmd_1 = tlbmd_1_MPORT_data; // @[EmbeddedTLB.scala 52:12]
  assign io_tlbmd_2 = tlbmd_2_MPORT_data; // @[EmbeddedTLB.scala 52:12]
  assign io_tlbmd_3 = tlbmd_3_MPORT_data; // @[EmbeddedTLB.scala 52:12]
  assign io_ready = ~resetState; // @[EmbeddedTLB.scala 72:15]
`ifdef RANDOMIZE_GARBAGE_ASSIGN
  // ......
`endif // SYNTHESIS
  always @(posedge clock) begin
    if (tlbmd_0_MPORT_1_en & tlbmd_0_MPORT_1_mask) begin
      tlbmd_0[tlbmd_0_MPORT_1_addr] <= tlbmd_0_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
    end
    if (tlbmd_1_MPORT_1_en & tlbmd_1_MPORT_1_mask) begin
      tlbmd_1[tlbmd_1_MPORT_1_addr] <= tlbmd_1_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
    end
    if (tlbmd_2_MPORT_1_en & tlbmd_2_MPORT_1_mask) begin
      tlbmd_2[tlbmd_2_MPORT_1_addr] <= tlbmd_2_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
    end
    if (tlbmd_3_MPORT_1_en & tlbmd_3_MPORT_1_mask) begin
      tlbmd_3[tlbmd_3_MPORT_1_addr] <= tlbmd_3_MPORT_1_data; // @[EmbeddedTLB.scala 51:18]
    end
    resetState <= reset | _GEN_1; // @[EmbeddedTLB.scala 55:{27,27}]
  end

endmodule

Unable to compile the project if TLBs are disabled

When I set HasDTLB and HasITLB to false in Settings.scala, the project could not be compiled. The output of make command is

NutShell $ make PRJ=myproject BOARD=pynq STANDALONE=true
mkdir -p build
mill chiselModule.runMain top.TopMain -td build --output-file TopMain.v --infer-rw NutShellFPGATop --repl-seq-mem -c:NutShellFPGATop:-o:build/TopMain.v.conf BOARD=pynq CORE=inorder
[63/74] chiselModule.compile
[info] compiling 77 Scala sources to /home/lighthouse/rv/NutShell/out/chiselModule/compile.dest/classes ...
[warn] 2105 feature warnings; re-run with -feature for details
[warn] one warning found
[info] done compiling
[74/74] chiselModule.runMain
====== Settings = (pynq, inorder) ======
EnableDebug = true
EnableILA = true
EnableMultiIssue = false
EnableOutOfOrderExec = false
EnableRVC = true
FPGAPlatform = true
HasDTLB = false
HasDcache = true
HasITLB = false
HasIcache = true
HasL2cache = true
HasPrefetch = true
IsRV32 = false
MMIOBase = 0xe0000000
MMIOSize = 0x20000000
MemMapBase = 0x10000000
MemMapRegionBits = 28
MmodeOnly = true
NrExtIntr = 3
ResetVector = 0x60000000
[deprecated] class utils.FlushableQueueIO (1 calls): Unable to automatically infer cloneType on class utils.FlushableQueueIO. cloneType is now implemented by the Chisel compiler plugin so please ensure you are using it in your build. If you cannot use the compiler plugin or you are using it and you still see this message, please file an issue and let us know. For those not using the plugin, here is the 'runtime reflection' cloneType error message: constructor has parameters (entries) that are not both immutable and accessible. Either make all parameters immutable and accessible (vals) so cloneType can be inferred, or define a custom cloneType method.
[warn] There were 1 deprecated function(s) used. These may stop compiling in a future release - you are encouraged to fix these issues.
[warn] Line numbers for deprecations reported by Chisel may be inaccurate; enable scalac compiler deprecation warnings via either of the following methods:
[warn]   In the sbt interactive console, enter:
[warn]     set scalacOptions in ThisBuild ++= Seq("-unchecked", "-deprecation")
[warn]   or, in your build.sbt, add the line:
[warn]     scalacOptions := Seq("-unchecked", "-deprecation")
Exception in thread "main" firrtl.passes.PassExceptions:
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake]  Reference io is not fully initialized.
   : io.mem.req.bits.size <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake]  Reference io is not fully initialized.
   : io.mem.req.bits.wdata <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake]  Reference io is not fully initialized.
   : io.mem.req.bits.cmd <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake]  Reference io is not fully initialized.
   : io.mem.resp.ready <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake]  Reference io is not fully initialized.
   : io.mem.req.bits.addr <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake]  Reference io is not fully initialized.
   : io.mem.req.bits.wmask <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake]  Reference io is not fully initialized.
   : io.mem.req.valid <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake_1]  Reference io is not fully initialized.
   : io.mem.req.bits.size <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake_1]  Reference io is not fully initialized.
   : io.mem.req.bits.wdata <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake_1]  Reference io is not fully initialized.
   : io.mem.req.bits.cmd <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake_1]  Reference io is not fully initialized.
   : io.mem.resp.ready <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake_1]  Reference io is not fully initialized.
   : io.mem.req.bits.addr <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake_1]  Reference io is not fully initialized.
   : io.mem.req.bits.wmask <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module EmbeddedTLB_fake_1]  Reference io is not fully initialized.
   : io.mem.req.valid <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake_1 is not fully initialized.
   : EmbeddedTLB_fake_1.io.mem.resp.bits.cmd <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake is not fully initialized.
   : EmbeddedTLB_fake.io.mem.req.ready <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake is not fully initialized.
   : EmbeddedTLB_fake.io.mem.resp.valid <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake_1 is not fully initialized.
   : EmbeddedTLB_fake_1.io.mem.resp.valid <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake_1 is not fully initialized.
   : EmbeddedTLB_fake_1.io.mem.resp.bits.rdata <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake is not fully initialized.
   : EmbeddedTLB_fake.io.mem.resp.bits.rdata <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake is not fully initialized.
   : EmbeddedTLB_fake.io.mem.resp.bits.cmd <= VOID
firrtl.passes.CheckInitialization$RefNotInitializedException:  @[EmbeddedTLB.scala 428:23] : [module NutCore]  Reference EmbeddedTLB_fake_1 is not fully initialized.
   : EmbeddedTLB_fake_1.io.mem.req.ready <= VOID
firrtl.passes.PassException: 22 errors detected!
1 targets failed
chiselModule.runMain subprocess failed
make: *** [Makefile:24: build/TopMain.v] Error 1

Running make with CORE=embedded (make PRJ=myproject BOARD=pynq CORE=embedded STANDALONE=true) produces the same error. Could you give some help on it?

Is the NutShell core out-of-order?

As the title, is the nutshell core out-of-order machine?

I found lots of commit messages containing the key word, 'out of order',
but I could not found any official information describing the feature.

Thanks in advance.

关于更新Debian11出现ttyPS0的报错

你好,

之前尝试用bbl+Linux+Debian11(SD卡文件系统,使用pynq板卡)的方式来测试启动,运行到最后时可以通过ssh进到系统中,但串口本身不再显示login的提示,并且启动log中有ttyPS0相关的报错:
74646dae54a8fcf65f30e0e1eb5c4ff

后面我们尝试用这种办法,暂时解决了ttyPS0报错和无法login的问题(但不太稳定,有时会报出其他概率性错误),仅供参考:

_

sudo chroot ./ /bin/bash

cp /lib/systemd/system/[email protected] /lib/systemd/system/[email protected]
ln -s /lib/systemd/system/[email protected] /etc/systemd/system/getty.target.wants/

vim lib/systemd/system/[email protected]
#将“%i.device”改为“%i”,保存并退出

vim etc/securetty
#第一行输入/dev/ttyPS0,保存并退出

针对Debian更新到11版本后出现的问题,如果你们找到更好的解决方法,请随时联络 谢谢!

Nutshell接入difftest出现的错误

你好!
我在参考OSCPU/ysyx#8 中接入difftest框架时出现了问题,按照步骤修改,在运行指令 mill -i __.test.runMain top.TopMain -td ./build 构建 SimTop.v 时出现问题,报错如下:
image
请问您知道是哪里出错了吗?

关于nutshell fpga工程的一些问题和记录

包含一些关于nutshell fpga工程的问题,以及和创作者进行交流的部分记录

问题1:

问:Settings.scale中的DefaultSetting包含了一些配置参数,这些参数可以任意配置吗?
答:参数是可配的,但没有做复杂的参数检查,不合理的参数配置导致的行为是未定义的。目前支持的三种类型的参数配置是顺序,乱序和小核。

问题2:

问:我看了一下整个nutshell中没有设计jtag,我们如何对nutshell进行程序下载和调试呢?
答:以pynq那个fpga工程为例,在工程中包含一个zynq的arm核,需要在arm核中运行bootloader,将生成的risc-v的二进制文件加载到内存中的特定位置。
问:那么在不用TLB的情况下(小核),我需要将软件程序加载到ddr的什么位置?假如说ddr的大小只有2G,我需要给ddr分配什么样的地址?如果我的resetvector是0x8000_0000,那么我的ddr的base可以设计为0x8000_0000,是这样吗?
答:

问题3:

问:所有chisel源码产生的.v文件主要就是TopMain.v吗?如果我需要自己用block design设计SoC,只需要将TopMain.v作为rtl module加入到block design中去吗?
答:是

问题4:

问:在pynq这个工程中rv_system模块下的NutShell_0模块包含了两个子模块,TOP和system_top_NutShell_0_0,这两个模块最后都例化了nutshell,这两个模块分别的作用是什么?
1.png
答:

问题5:

问:在pynq这个工程中,rv_system这个module的io_frontend接口内部包含了两个axi_protocol_convert,将axi转换为axi light再转换回axi,这样做的目的是什么?
2.png
答:

问题6:

问:在pynq这个工程中,nutshell core的复位来自于arm core的gpio信号,这样设计是出于什么目的?
答:FPGA上调试用的。
问:另外,如何通过arm core来完成nutshell的复位?接受外部的按键中断后进行gpio置为吗?
答:

问题7:

问: 我没有看到pynq工程中有时钟或者物理约束,这个约束需要怎么处理?
答:

问题8:

问:目前有没有针对nutshell的ide开发环境?
答:需要自行搭建rv架构的开发环境。

能否提供Golden的TopMain.v文件? Vivado BD创建失败, 因为NutShell模块的port不被识别为io_mem AXI口

您好!
能否提供正确的TopMain.v文件,供参考? 我使用0.6.3的mill创建了TopMain.v文件, 在fpga目录下, 使用pynq板卡, 创建vivado工程时,得到错误:
########## Vivado ERROR LOG ########
WARNING: [BD 5-232] No interface pins matched 'get_bd_intf_pins NutShell_0/io_mem'
ERROR: [BD 5-106] Arguments to the connect_bd_intf_net command cannot be empty.
ERROR: [Common 17-39] 'connect_bd_intf_net' failed due to earlier errors.

while executing

"connect_bd_intf_net -intf_net NutShell_0_io_mem [get_bd_intf_pins io_mem] [get_bd_intf_pins NutShell_0/io_mem]"
(procedure "create_hier_cell_rv_system" line 84)
invoked from within
"create_hier_cell_rv_system [current_bd_instance .] rv_system"
(procedure "create_root_design" line 61)
invoked from within
"create_root_design """
(file "board/pynq/bd/standalone.tcl" line 1359)

while executing

"source ${tcl_file}"
(procedure "add_bd" line 2)
invoked from within
"add_bd ${bd_dir}/standalone.tcl"
invoked from within
"if {${standalone} == "true"} {
add_bd ${bd_dir}/standalone.tcl
make_wrapper -files [get_files *system_top.bd] -top
add_files -norecurse -fileset..."
(file "board/pynq/../common.tcl" line 55)

while executing

"source ${script_dir}/../common.tcl"
(file "board/pynq/mk.tcl" line 17)

原因是io_mem_* 接口不被识别为 BD的AXI interface;
image
可以通过修改TopMain.v, 添加vivado AXI interface的描述, workaround这个问题, 但是 io_mmio_req_bits_cmd信号不是AXI标准信号, 该如何修改?
image

还请指导一下!

感谢
Ping

谢谢!
Ping

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.