I'm trying to run the "make verify-io_ports-rtl", and I see the following error. I can locate the directory mgmt_core_wrapper, but I don't see it. Any help to fix this would be appreciated.

how did you setup caravel_user_project? make setup should install this automatically

Yes, I used the quickstart.rst to install caravel. Not sure about the missing directory. And, yes, I'm installing it with make install_mcw now. Thanks!

It's not required, but IMO if you don't have a testbench that checks your design in the caravel context then you shouldn't tapeout.

I'm trying to run the testbench, and it says no .hex needed by .vpp. What am I missing?

The makefiles assume your test files will be named the same as your directory

I have the same name for both directory and the files in it. I have only my Verilog files my_alu_xor.v and my_alu_xor_tb.v. I don't have c files.

the c gets compiled to hex and that's used to configure the cpu

I don't have a c file. Should I have to create one? or what could be other alternatives?

copy the one from io_ports and adapt it

Sure, do I need to modify anything or can I use the same io_ports.c?

totally depends on what your design is doing

Yes, I use io_in and io_out

what file are you dumping vcd to?

I'm not sure about this whole process. I just copied the io_ports.c to my testbench directory and ran the command "make verify-my_alu_xor-rtl"

@User You can change $dumpfile command in my_alu_xor_tb.v $dumpfile("io_ports.vcd"); To $dumpfile("my_alu_xor.vcd");

@User I'd like to try explaining the process of making a test case. The idea is that you can define a couple of tests for the later SoC+your component. Each test goes into a subdirectory of the "rtl/dv" Caravel project directory. Such a test consist of: • One verilog file that describes how the simulated SoC is embedded into a test environment. This is the "<name>_tb.v" file. It makes sense to start from an existing one (for various reasons) • One .c source code file with code that is executed on the SoC. It is compiled to a binary (the .hex file) that will be the assumed content of a simulated Flash memory chip that gets connected to the simulated SoC. • One Makefile that you can just copy from an existing test. The idea is that in your .c file, you write a program that triggers behaviour that you then observe with code in the _tb.v file which should yield a violation in case incorrect behavior is seen. The existing examples for the caravel user project give you an idea of how to do this. There are examples for testing IO, which are useful for testing GPIO pins. If all your project does is to perform computation without doing anything with the IO ports directly, then you probably have the tests in your C code that either pass or fail, and then you need to forward this information to the test bench somehow. There are multiple ways for doing so, and in https://github.com/progirep/temporal_runtime_monitor_for_caravel/tree/master/verilog/dv/complex_monitor I have an example (adapted from the examples that come with the example user project). The idea is to configure some GPIO pins of the SoC, and output some special integers representing "Success" or "Fail" to the test bench.

Thanks, @User . I will do that