bluespec / flute Goto Github PK

ISA_Decls.bsv has a RoundMode enumerated type that appears to have a similar function but be different than the one in FloatingPoint.bsv. Due to some unknown priority effect this apparently has not been causing build failures, but the up-to-date BSC falls over due to the confusion. Things appear to build ok RoundMode in ISA_Decls is simply deleted.

There are several references to tightly-coupled memory in the code, but the Near_Mem_TCM interface doesn't seem to actually exist. The testbed SoC reserves a memory region for TCM, but doesn't populate it in the routing map. It would be a good idea to either remove the references to this or provide the missing implementation.

I am from the Columbia team in SSITH and trying to build and run from the Verilog sources (out of the box).

$ cd builds/RV32IMU_verilator/
$ make simulator                                            
Makefile:7: ../Resources/Include_RV32IMU.mk: No such file or directory                          
make: *** No rule to make target `../Resources/Include_RV32IMU.mk'.  Stop.

The configuration file build/Resources/Include_RV32IMU.mk seems to be missing. Did I skip any step?

Thank you!

Hi there!

How do you collect coverage numbers for your test set / testbench environment? I had a brief look at your testbench, but I'm sadly not familiar with Bluespec Verilog and didn't quite know where to go.

I'm working on my own core at the moment, and I can't find anyone who reports (or possibly even collects) things like coverage numbers for their verification.

Cheers,
Ben

The compilation and simulation of the Test_PLIC.bsv fails

To reproduce issue: run the makefile in src_Core/PLIC

Compilation Fix:
Axi4_Wr_Data in this line should not have wid field

Simulation Fix (after the above fix): the following line

vrg_irqs [5] <= True;

should be:

vrg_irqs [4] <= True;

Explanation: vrg_irq[i] is connected to source_ip[i+1].

Hello! I'm not sure if I missed a dependency somewhere (or needed to do anything else to get things working), but I'm trying to run make test and make simulation in the respective pre-built /builds/RV64... directories and getting a couple of different errors.

I'm currently on M1 Mac OS Ventura.

1. I tried running make simulation in the iverilog directories, but it seems like it was still expecting verilator / bsc to be installed, so I installed Verilator but now it seems to be failing with :

%Error-NEEDTIMINGOPT: Verilog_RTL/mkPLIC_16_2_7.v:25483:4: Use --timing or --no-timing to specify how delays should be handled
                                                         : ... note: In instance 'mkTop_HW_Side.soc_top.core.plic'
25483 |    #0;
      |    ^
                      Verilog_RTL/mkCore.v:2314:1: ... note: In file included from 'mkCore.v'
                      Verilog_RTL/mkSoC_Top.v:1127:1: ... note: In file included from 'mkSoC_Top.v'
                      Verilog_RTL/mkTop_HW_Side_edited.v:227:1: ... note: In file included from 'mkTop_HW_Side_edited.v'
%Error: Exiting due to too many errors encountered; --error-limit=50

I'm not sure if I missed anything there.

2. When I run make test , I get an error saying :

elf_to_hex.c:15:10: fatal error: 'gelf.h' file not found
#include <gelf.h>
         ^~~~~~~~
1 error generated.
make[1]: *** [elf_to_hex] Error 1

I tried fixing the path to my compiler, but it didn't seem to have any effect. I'm not sure the best way to debug this and tried with clang/gcc/g++.

Sorry for the amount of questions, and thank you for any guidance!

hi,
I am very new to RISC-v and bluespec. Currently, I am trying to add more IP in the existing flute core. Before this, I want to verify that the uart IP which is already available here can make a successful communication with the flute core through the AXI4 bus.
Can anyone give me any advice on this issue?
Thank you

Hello

There are a few things I would like to ask

The SOC module contains the memory_controller
Within the code document it says that it is capable of driving Real DRAM, BRAMS.

But the controller has a length of 353 of output(to_raw_mem_request) which I have no idea to port this to a specific DRAM device.

*I am currently using Vivado HLS design, and wants to test it on real Xilinx FPGAs

Thanks

Hi, I hope you are well. I am facing the following error while regenerating the verilog files in the src_SSITH_P2 folder with make compile command:

compiling ../src_Core/Near_Mem_VM_WB_L1_L2/Cache.bsv
Error: "../src_Core/Near_Mem_VM_WB_L1_L2/Cache.bsv", line 479, column 32: (T0080)
  Type error at the use of the following function:
    Meta

  The expected return type of the function:
    Cache::Meta

  The return type according to the use:
    Meta#(b__, a__)

Error: "../src_Core/Near_Mem_VM_WB_L1_L2/Cache.bsv", line 645, column 46: (T0080)
  Type error at the use of the following function:
    Meta

  The expected return type of the function:
    Cache::Meta

  The return type according to the use:
    Meta#(b__, a__)

Error: "../src_Core/Near_Mem_VM_WB_L1_L2/Cache.bsv", line 716, column 49: (T0080)
  Type error at the use of the following function:
    Meta

  The expected return type of the function:
    Cache::Meta

  The return type according to the use:
    Meta#(b__, a__)

Error: "../src_Core/Near_Mem_VM_WB_L1_L2/Cache.bsv", line 855, column 27: (T0007)
  Unbound type constructor `Meta_$Meta'
Error: "../src_Core/Near_Mem_VM_WB_L1_L2/Cache.bsv", line 1035, column 49: (T0080)
  Type error at the use of the following function:
    Meta

  The expected return type of the function:
    Cache::Meta

  The return type according to the use:
    Meta#(b__, a__)

Error: "../src_Core/Near_Mem_VM_WB_L1_L2/Cache.bsv", line 1111, column 18: (T0007)
  Unbound type constructor 'Meta_$Meta'
make: *** [Makefile:118: compile] Error 1

I also renegerated the verilog files in the builds/RV64ACDIMSU_Flute_verilator but I had no problems. Looks like it only happens for the SSITH folder.

Hi, I hope you are well.

I am trying to deploy the Flute on a Zynq UltraScale+ ZCU102 board. I noticed on the Makefile that the JTAG is built based on the XCVU9P board. Hence, I modified the JtagTap.bsv to include my board specifications:

`elsif XILINX_XCZU9EG
typedef 12 IR_LENGTH;

`elsif XILINX_XCZU9EG

Bit#(IR_LENGTH) ir_dtmcs = 'b100100100010;    // USER3
                        // 'b100100000010;    USER1

Bit#(IR_LENGTH) ir_dmi = 'b100100000011; // USER 2
`endif

I am wondering if I need to do any other modification in order to correctly generate the Jtag Verilog files to be used with OpenOCD.

Thank you.

I have already looked at www.bluespec.com and your forum http://forum.bluespec.com/viewtopic.php?t=651&sid=d5e77b8d702f34485d0167e06d877261. I also sent an email to [email protected] but I got no useful response. Can you give me a link to download the bsc?

Thanks!

Hello, when I use make compile in various build directories, it results in:

Error: "../../src_Core/CPU/CPU.bsv", line 319, column 37: (T0020)
  Type error at:
    rg_pc_reported

  Expected type:
    ISA_Decls::WordXL

  Inferred type:
    Bit#(64)

It looks like there was a recent change to that part:
bbee1f3#diff-466f63b34521ac100a07ab1b0d97102bb96e2ba7658806fc0ad558b9ef49adf1

Could it be the reason?

压根也没有mkBRVF_Core.v这个文件

Flute currently bans the compressed hint encodings: at least C.NOP with nzimm != 0 and c.ADDI with nzimm == 0. I'm not sure if this is based on a past version of the spec that reserved these, but the current version seems pretty clear that they should be legal.

I believe deleting the following two lines would fix these cases, but I'm not sure if there are more:

can the current version of flute be tested using GaloisInc/BESSPIN-GFE ?

I have followed the instruction to generate the bit stream successfully , but openocd has the following issue

Error: DMI operation didn't complete in 2 seconds. The target is either really slow or broken. You could increase the timeout with riscv set_command_timeout_sec.

Any advice is helpfull.

Thank you