dcp files are missing

[Eric9908]

Hello, I am very interested in this project, but this FPGA project seems to be missing three dcp files, and the wcfg file cannot be opened. At the same time, what exactly do I need to do to run this project? My environment is also vivado23.2, but after updating the IP core, it cannot be integrated. Can you explain it in detail? Looking forward to your answers

[mathis-s]

Thanks for the report! Seems like Vivado projects aren't a great fit for git... Nothing special should be required to open the project though, I was also just using Vivado. I've gone ahead and pushed the DCP files to a new branch. Let me know if that fixes it or if there's any other issues.

[Eric9908]

Sorry, it seems I didn't express myself clearly. The missing dcp files are Top.dcp and two TopWrapper.dcp, which causes me to run synthesis and implementation to fail. I tried the new branch of the project, and it seemed that more errors were reported.

ERROR: [VRFC 10-2063] Module <axi_clock_converter_v2_1_28_axi_clock_converter> not found while processing module instance <inst> [E:/Projects/VivadoProject/SoomRV-Arty_new/SoomRV-Arty.ip_user_files/bd/axi_map/ip/axi_map_auto_cc_0/sim/axi_map_auto_cc_0.v:312]
ERROR: [VRFC 10-2063] Module <axi_protocol_converter_v2_1_29_axi_protocol_converter> not found while processing module instance <inst> [E:/Projects/VivadoProject/SoomRV-Arty_new/SoomRV-Arty.ip_user_files/bd/axi_map/ip/axi_map_auto_pc_0/sim/axi_map_auto_pc_0.v:244]
ERROR: [VRFC 10-2063] Module <axi_data_fifo_v2_1_28_axi_data_fifo> not found while processing module instance <inst> [E:/Projects/VivadoProject/SoomRV-Arty_new/SoomRV-Arty.ip_user_files/bd/axi_map/ip/axi_map_s00_data_fifo_0/sim/axi_map_s00_data_fifo_0.v:304]
ERROR: [VRFC 10-2063] Module <axi_crossbar_v2_1_30_axi_crossbar> not found while processing module instance <inst> [E:/Projects/VivadoProject/SoomRV-Arty_new/SoomRV-Arty.ip_user_files/bd/axi_map/ip/axi_map_xbar_0/sim/axi_map_xbar_0.v:298]
ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design unit(s) in library work failed.

[mathis-s]

I see! I only have TopWrapper.dcp locally though, not sure about Top.dcp. Anyways, I just pushed TopWrapper.dcp. With that build now works for me with a freshly cloned repo. Let me know if it does for you too!

[Eric9908]

Thank you very much for your patient answer. I can now complete the synthesis and implementation, but I found several problems with setup time timing violations. Since Soc is imported in the form of an edif file, not an SV file, the readability is relatively low. Bad, I don't know how to solve the critical path timing problem now. I would like to ask if there are also the following timing violations. If so, was it put on the board without solving the timing problem? Another question is, why not consider adding it directly to the VIVADO project in the form of SV, but use yosys and sv2v to convert it to edif?I tried to use the source code to create a VIVADO project. The assert in the source code cannot be synthesized in VIVADO.

[mathis-s]

For now, these timing violations are to be expected. All of this is very experimental anyways, and this runs totally fine in typical conditions.

The current critical path is the tag-check (and following issue of dependent ops depending on match or not) for load instructions. To fix this path, we could increase load latency by a cycle. I am however planning to implement speculative issue for load-dependent ops anyways. That will also fix this critical path, which is why I'm not too concerned about it right now.

To find critical paths in the EDIF with Vivado, you have to look at the output signals of the start and end flip flops of the path. Flip flop output signals have un-mangled names, so this way you can (at least) find the Verilog name of the start and end registers of the path. Sadly this does not work for combinatorial signals, but usually you can still figure out the path.

I do synthesis with Yosys mostly because that's what I originally designed SoomRV with in the OpenMPW shuttles. I did also try with Vivado but ran into the same sort of issues that you did. Assertions you can just remove, but I think there were some other issues as well. Perhaps, if the SystemVerilog files don't work, try using the sv2v output in synth/SoC.v? Let me know how it goes!

[Eric9908]

Thanks for the reply. I am a newbie, but I roughly understand what you mean. I will try to use the sv2v converted file to create a vivado project to verify whether it is feasible. But I encountered some problems: 1.SoomRV was running on my virtual machine before, and the environment was Ubuntu22.04, GCC11.4, Verilator5.018. Now I have been failing to transplant my project to the server. The server environment is Ubuntu22.04, GCC11.4, Verilator5.018. The problems encountered during the period are the same as Fix the linkage issue during the generation of VTop #14 under the SoomRV issue section. I don't know how to solve this link problem, have you encountered it? Or can you tell me about your environment?

2. If I want to conduct other benchmark tests on the processor, such as coremark test, how do I do it? Is it similar to dhry? Do I modify coremark's source code and escape it into assembly language or something else?

[mathis-s]

I'm on Manjaro with GCC 13.2.1 and Verilator 5.016. In this case it seems like there is an issue with libdl, but you are linking libdl with -ldl. Perhaps there's a version mismatch between riscv-isa-sim and the current version of libdl? Maybe just try deleting riscv-isa-sim, and re-run make setup.

To run Coremark or other benchmarks, there are two options. You can boot Linux, where Coremark is preinstalled, so you can just run coremark. That takes a while though. You can also run Coremark without Linux (bare metal), that requires some porting though. I have actually done that a while ago, will push it to the SoomRV repo for you in the next few days!

[Eric9908]

Thanks for the reply. I have solved this link problem: it should be because the version of my riscv32-unknown-linux-gnu-gcc is 13.2.0, but the version of my gcc is 11.4.0. The two versions are slightly different.. This caused a problem with the compiled link library when executing make setup. When I used the 13.2.0 version of gcc and the 13.2.0 version of riscv32-unknown-linux-gnu-gcc at the same time, the problem was solved. I have tried make linux, and the compilation took a long, long time. When I logged in, it was very laggy. It seems that my coremark test was not successful. . . Thank you again for your patience.