Run Hello world example on VC707 board

[Mina2411]

Hello, Thanks for this great work, I appreciate the whole work. It is extremely beneficial. Actually,I removed the constraint file of KC705 board, and I used the constraint file of VC707 board, and I did the matching between them. Fortunately, the bit stream is written successfully and uploaded on the board. However, I need to test the processor on the board, so I chose the simple hello world example using the UART module, but I don't know what should I do to test hello world on the board. I know that I need a compiler to produce HEX file format for the C program and then put the path for the generated HEX file somewhere in the code (I think in the sram module), so Kindly can you tell me the steps to test the hello world example because I am not able to get this point from the repository. Thank you in advance, Mina

[sergeykhbr]

If you properly ported KC705 target on VC707 you should see UART1 output generated by 'bootrom_tests' example (115200 baudrate). By default, HEX-files _bootrom_testshi/lo.hex are used to initialize internal ROM of the SoC (see configuration parameter CFG_BOOTROM_FILE in file sv\prj\impl\kc705\config_target_pkg.sv). These files were pre-built and committed so you do not need to compile them manually. Check this output before experiment with the "Hello, World!" example.

You have several options:

1. Universal approach quite standard for any board 1.1. Configure and compile 'openocd' to debug board via JTAG interface. Enable desired interface during configuration (jlink or whatever JTAG-debugger you are going to use). You also can find pre-built openocd binaries for Linux and Windows. 1.2. Compile helloworld in a usual way to get ELF-file (you do not need HEX-files in this case) 1.3. Change first line argument remote_bitbang in the openocd configuration file _openocd_gdb_cfg\bitbanggdb.cfg

   // jlink is an example
   adapter driver jlink

   1.4. Start and connect to VC707 via JTAG openocd -f bitbang_gdb.cfg. Take into account that JTAG TAP module is a part of the system (SystemVerilog files) so you can assign TCK, TMS, TDI, TDO and TRST signals on any convenient for you GPIOs. 1.5. Use load_image /bin/helloworld and resume commands to load image into RAM and start the execution. (See openocd script description or telnet connection to port 4444). Or use gdb to connect to openocd and all functionality provided by gdb.

2. Second option is to generate HEX-files to initialize ROM instead bootrom_tests 2.1. Compile 'examples/elf2rawx' utility 2.2. Copy elf2rawx binary file into folder with your gcc binaries or modify PATH environment variable so that 'make' could find it. 2.3. Compile helloworld you should get hex-files 2.4. Modify parameter CFG_BOOTROM_FILE in config_target_pkg.sv.

Most probably you do not need to build Hello World to check your bit stream file you should see UART output as following:

HARTID . . . . .0
HARTS. . . . . .1
PLIC_IRQS  . . .73
HWID . . . . . .0x20221101
FWID . . . . . .0x20220116
PLIC . . . . . .PASS
MTIMER . . . . .PASS
SWIRQ. . . . . .PASS
L2.Coherence . .Disabled
PMP. . . . . . .PASS
MMU.MPRV . . . .PASS
HW_FPU . . . . .testing
Testing FADD
Testing FMUL
...

[Mina2411]

Hello again, Thank you for your reply, and I will try to follow these steps to get any output.However, I need to understand the pipelined stages, and the signals going in and out from each stage, but this is difficult from the VHDL code, so do you have any inspiration diagram that you followed while you are writing your design; I mean by diagram something like that for instance.

Thank you in advance, Mina

[sergeykhbr]

Sorry, I do not have the diagrams like that

[Mina2411]

Hello again, I need to make sure of a certain point, If I want to see the Uart display from bootrom_tests, I should place the path of bootrom_tests_hi_hex in the rom_inferred vhdl file, is that correct or I need anything else? Thanks, Mina

[sergeykhbr]

Hi, current version of SoC for FPGA (KC705) is placed in folder sv (System Verilog) to build bitstream file:

cd sv\prj\impl\kc705
make

Vivado should be in your PATH directory. I suppose 'make' could be also run from Vivado command console. You do not need to change anything all paths in the project are project relative. vhdl is an obsolete version do not use it. It will be overwiten in the future.

[Mina2411]

Hello again, I have used the sv version of the riscv, and I have a question in the constraint file. I found a lot of lines similar to that one, "set_property LOC PHASER_OUT_PHY_X1Y3 [get_cells -hier -filter {NAME =~ */ddr_phy_4lanes_2.u_ddr_phy_4lanes/ddr_byte_lane_D.ddr_byte_lane_D/phaser_out}]" Kindly, I want to know what these lines mean "I think it is related to routing of nets", as this is the first time I saw such lines in a constraint file, so that I can match these lines to the constraint file of VC707 board, as I am having a lot of routing errors when I use the constraint file of VC707 board, and also I would like to know where can I get this routing information, as I was searching in the user guide, and I found nothing there. Thanks, Mina

[sergeykhbr]

You need to generate DDR controller using Vivado IP generator for your board. And then integrate it into the project.

You also have another option - remove entirely DDR controller from the project and nullify AXI/APB interfaces connected to Bus Controller. In this case _bootromtests will works as usual from the internal SRAM/ROM but you won't get the chance to enjoy porting Linux.

[Mina2411]

Hello, Thank you, That solution worked for me, but if I want to run programs on the processor without waiting to re-synthesize each modification I will make, so the best way is to build the debugger in the repository "something like a GUI", or there is another way to go through.Also, is this simulator or debugger contains a compiler as well, or I need to find a compiler to generate the hex files. Thanks, Mina

[sergeykhbr]

To debug FPGA board use the standard RISC-V development toolchain: gcc, openocd + gdb. You can build it or find and download binaries in the Internet. It will allow to load application into internal SRAM and execute them.

Debugger in this repository should be used for the verification purpose:

• debug functional simulation
• debug SystemC simulation (full analog of the RTL simulation)
• debug RTL if you know howto to use DPI and your simulator supports this feature.

I'm using own version of the HEX generator (elf2rawx) because in some specific ASIC cases ROM couldn't be implemented as a single block and I need several HEX-files to initialize all ROM blocks. Probably you can find standard utility for that elf2hex or objdump.

[Mina2411]

Hello, I will try to get the gcc compiler, but is the riscv processor is 32 or 64 bits, as when I was exploring the boot_rom_tests, I saw that the instructions is 32 bits (8 HEX each), but the boot rom file consists of 64 bits instructions, so this will help me to download the gcc version I think. Thanks, Mina

[sergeykhbr]

This repository implements 64-bits CPU. Memory width isn't determined by the CPU, it could be 8-bits or 256-bits and perfectly work with the 32 and 64-bits CPUs. It directly affects CPU throuput/latency/performance either as many other configuration parameters of the CPU, System Bus and Caches. Parameter CFG_LOG2_SYSBUS_DATA_BYTES specify system bus width

[mito200]

Hello Serge, I can not find the original C file from which the bootrom tests hex file is generated . I need it to nullify the Dram function or test in it . I really appreciate your help . Thanks in advance.

[mito200]

Moreover, Kindly can you please tell me if there is any method to open the gui for the sv project rather than running the make command in the kc705 directory ( like opening the vhdl project from the xpr file for example)

[sergeykhbr]

1. All source files of the bootrom_tests are here: https://github.com/sergeykhbr/riscv_vhdl/tree/master/examples/bootrom_tests/src

2. No. The bitstream file is generated from console. You can create project file manually by adding all files from the 'sv' sub-folder plus top-level and constrain files from the 'kc705' sub-folder.

[Mina2411]

Hello again, Kindly,I need to make sure of a certain point,if I have a program, and I want to test it on the processor, I would place the path of the hex file of the program in the config_target_pkg.sv, this is what I understand, but I can't find the link between the rom_inferred_2x32 which is the module where the hex files are read (then this module is port mapped in rom_tech.sv file) and the pipeline stages, so the program instructions will go through the pipeline. so could you please clarify the module or the part where this files are linked together? Thanks, Mina

[sergeykhbr]

Sorry, I don't understand why you expect link between ROM and "pipeline". ROM is an independent module with the AXI interface. There're a lot of things between "pipeline" and ROM: Bus Interfaces, L2 coherent bridge, L1 bridge.

[mito200]

Hello Serge again, Can you tell me please which compiler have you used or send me a link to it? Thank you

[sergeykhbr]

Try this one: https://www.embecosm.com/resources/tool-chain-downloads/#riscv-stable

I'm using 7.7.1 (to track performance changes) and 10.1.0

[mito200]

ok will give it a tryy

[mito200]

If you properly ported KC705 target on VC707 you should see UART1 output generated by 'bootrom_tests' example (115200 baudrate). By default, HEX-files _bootrom_testshi/lo.hex are used to initialize internal ROM of the SoC (see configuration parameter CFG_BOOTROM_FILE in file _sv\prj\impl\kc705\config_targetpkg.sv). These files were pre-built and committed so you do not need to compile them manually. Check this output before experiment with the "Hello, World!" example.

You have several options:

1. Universal approach quite standard for any board
   1.1. Configure and compile _'openocd'_ to debug board via JTAG interface. Enable desired interface during configuration (jlink or whatever JTAG-debugger you are going to use). You also can find pre-built openocd binaries for Linux and Windows.
   1.2. Compile helloworld in a usual way to get ELF-file (you do not need HEX-files in this case)
   1.3. Change first line argument **remote_bitbang** in the openocd configuration file _openocd_gdb_cfg\bitbang_gdb.cfg_

// jlink is an example
adapter driver jlink

1.4. Start and connect to VC707 via JTAG _openocd -f bitbanggdb.cfg. Take into account that JTAG TAP module is a part of the system (SystemVerilog files) so you can assign TCK, TMS, TDI, TDO and TRST signals on any convenient for you GPIOs. 1.5. Use _load_image /bin/helloworld_ and resume commands to load image into RAM and start the execution. (See openocd script description or telnet connection to port 4444). Or use gdb to connect to openocd and all functionality provided by gdb.

2. Second option is to generate HEX-files to initialize ROM instead bootrom_tests
   2.1. Compile 'examples/elf2rawx' utility
   2.2. Copy _elf2rawx_ binary file into folder with your gcc binaries or modify PATH environment variable so that _'make'_ could find it.
   2.3. Compile helloworld you should get hex-files
   2.4. Modify parameter CFG_BOOTROM_FILE in _config_target_pkg.sv_.

Most probably you do not need to build Hello World to check your bit stream file you should see UART output as following:

HARTID . . . . .0
HARTS. . . . . .1
PLIC_IRQS  . . .73
HWID . . . . . .0x20221101
FWID . . . . . .0x20220116
PLIC . . . . . .PASS
MTIMER . . . . .PASS
SWIRQ. . . . . .PASS
L2.Coherence . .Disabled
PMP. . . . . . .PASS
MMU.MPRV . . . .PASS
HW_FPU . . . . .testing
Testing FADD
Testing FMUL
...

Okay I am stuck now in option 2 here, I have compiled the elf2ravw sources and have the elf file and then added it to the same directory where all gcc binaries like gcc-unknown-elf-gcc are in so now can you tell me what is the next step as I can not understand it from this comment

[sergeykhbr]

Use the following to generate helloworld.hex:

elf2rawx helloworld.elf -h -f 65536 -l 8 -o helloworld.hex

or the following to generate _hi.hex and _lo.hex

elf2rawx helloworld.elf -h -f 65536 -l 8 -o helloworld_hi.hex -o helloworld_lo.hex

File sv\rtl\techmap\mem\rom_inferred_2x32.sv uses hi/lo files to initialize two 'rom_inferred_32' modules each 32-bits width.

[Mina2411]

Hello again, I have tried many options to compile helloworld and produce the hex file, but the problem is that the stack pointer is not initialized correctly, so the program can't be started because the Dram block is nullified, so I am having only the internal memory. I have also tried different gcc compilers and different versions, but the same problem appears, and I can't link between elf2rawx and helloworld to generate the correct hex file due to linker problems may be the compiler isn't compatible with this riscv or missing libaries and packages, so please if you have the hex file for helloworld that is running on this riscv send it, so we can use it. we are only trying to test the processor to perform some work on it in the near future, but we are stuck in this initial step, so if you can help us to proceed, we will be thankful because we must test this simple helloworld example before doing any additional steps. Thanks, Mina

[sergeykhbr]

Definitely you need the startup file (assembler) that will properly initialize CPU/CPUs depending of the configuration before user application entry point will be called. Absolutely sure that it requires some experience of working with bare metal to link newlib or whatever compiler is used with the standard printf, malloc or C++ functions. These tutorials are a bit out of this project.

Generally I suggest do not modify hardware (fpga porting) and software (bootrom_tests) at the same time. If the _bootromtests successfully starts on your FPGA it should be trivial to modify it and print "Hello World". Other examples (except riscv_tests) could be obsolete and it is out of my scope to provide ready-to-use out-of-the-box SDK. Current implementation is complied with the RISC-V specifications and the standard approach for any RISC-V board (actually for any architecture) should be used.

[sergeykhbr]

Makefile of the helloworld example was updated and HEX-files committed to run this application in the same way as the default bootrom_tests example (just change parameter CFG_BOOTROM_FILE_HEX).