Demo Project about vicuna HOT 9 CLOSED

Which version of Vivado are you using? What errors did you encounter?

The differential clock is optional. The default setting in demo_top.sv is to use a single-ended clock (parameter DIFF_CLK set to 0), in which case only the port sys_clk_pi is used as clock pin and sys_clk_ni is ignored (either leave it unconnected or simply tie it to 1'b0).

The unit tests in the test/ directory are very short test programs that modify some values in memory but do not generate any output. These test programs are built by invoking the Makefile in the sw/ directory. This Makefile accepts a program name and the name of object files as variables, so you may, for instance, use it to build a program called test.c with following command (from the directory where test.c is located):

make -f /path/to/vicuna/sw/Makefile PROG=test OBJ=test.o

This command will generate an executable and also a *.vmem file for your program. You can then use this *.vmem file to initialize the memory of the demo project by using the path to that file as the parameter value of RAM_FPATH in demo_top.sv.

from vicuna.

Thank you @michael-platzer for your kind answers about clock section I get it now thank you... actually I use Vivado 2019.2 and when I want to open .tcl files I go to tools section of my vivado then when I hit Run Tcl Script my vivado suddenly crashes and it closes... I think it is my software problem not your .tcl file surely.
About the demo project so I understand I can have a .vmem file by runing make -f /path/to/vicuna/sw/Makefile PROG=test OBJ=test.o but actually I thought by applying this to for example vadd_8.s I can see a output in demo project. Besides since gcc doesn't support auto vectorization someone should write in intrinsic level to have vector code as output which is hard. That would be really nice if you add just one test.c program as a simple test for demo project to see the outputs (like what Ibex does with led.c file in here https://github.com/lowRISC/ibex/tree/master/examples/sw/led)... but anyway, consider having this test program that generates output what the tera term or putty or .... will show as the output? So I start this programs I set baud rate to 19200 of your project and then what? Will it show the content of the memory? I really struggle understanding this part...

from vicuna.

Nothing is transmitted over UART unless your program explicitly transmits something. The test programs don't use UART, so you would not see anything when executing those on an FPGA. I have expanded the README in the demo directory with instructions and a short demo program which uses a UART library to send data over UART.

The default baud rate for UART is 115200, which can now be adjusted via the parameter UART_BAUD_RATE in demo_top.sv.

The demo program can then be expanded with code using the vector instructions, either via inline assembly or by using the vector extension intrinsics.

from vicuna.

God bless you @michael-platzer ... I hope after understanding the topic I could contribute as well...

from vicuna.

Hi @michael-platzer I have to ask this since I couldn't get the output from demo project after all your help :((
I build the project for Ibex core and for demo_top I have this:
module demo_top #( parameter RAM_FPATH = "C:\Users\dell\Desktop\Shabake_Asli\Vicuna\SelfDownload\Tests\test.mem", parameter int unsigned RAM_SIZE = 262144, parameter bit DIFF_CLK = 1'b0, parameter real SYSCLK_PER = 10.0, parameter int unsigned PLL_MUL = 10, parameter int unsigned PLL_DIV = 20, parameter int unsigned UART_BAUD_RATE = 115200 )
For vector processor since the default settings did not fit on my FPGA I changed it to this:
vproc_top #( .VREG_W ( 128 ), .VMEM_W ( 32 ), .VMUL_W ( 64 ), .RAM_TYPE ( vproc_pkg::RAM_XLNX_RAM32M ), .MUL_TYPE ( vproc_pkg::MUL_XLNX_DSP48E1 ) )
It is also in demo_top...
After I compiled the test program "Hello World" I added this .mem file to the project with the address given in demo_top parameters as you can see... but after Implementation and generating .bit I still cannot see anything... Here is my .xdc file:
## Clock signal set_property -dict { PACKAGE_PIN E3 IOSTANDARD LVCMOS33 } [get_ports { sys_clk_pi }]; #IO_L12P_T1_MRCC_35 Sch=clk100mhz create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports {sys_clk_pi}]; ##Switches set_property -dict { PACKAGE_PIN V10 IOSTANDARD LVCMOS33 } [get_ports { sys_rst_ni }]; #IO_L21P_T3_DQS_14 Sch=sw[15] ##USB-RS232 Interface set_property -dict { PACKAGE_PIN C4 IOSTANDARD LVCMOS33 } [get_ports { uart_tx_o }]; #IO_L7P_T1_AD6P_35 Sch=uart_txd_in set_property -dict { PACKAGE_PIN D4 IOSTANDARD LVCMOS33 } [get_ports { uart_rx_i }]; #IO_L11N_T1_SRCC_35 Sch=uart_rxd_out #set_property -dict { PACKAGE_PIN D3 IOSTANDARD LVCMOS33 } [get_ports { UART_CTS }]; #IO_L12N_T1_MRCC_35 Sch=uart_cts #set_property -dict { PACKAGE_PIN E5 IOSTANDARD LVCMOS33 } [get_ports { UART_RTS }]; #IO_L5N_T0_AD13N_35 Sch=uart_rts
And for tera term:

I really don't know what have I done wrong...

from vicuna.

Please verify and confirm the following:

1. That the memory initialization file is indeed the one generated by make -f /path/to/vicuna/sw/Makefile PROG=test OBJ=test.o. The file extension should be *.vmem, not *.mem. Vivado should show a critical warning during synthesis if the file cannot be processed.
2. That the reset signal is high (otherwise the system is in constant reset). I see that you are using a switch for the reset port (pin V10). The Nexys 4 DDR has a dedicated CPU reset connected to pin C12 that is normally high. Please consider using the CPU reset instead of the switch.
3. That the UART pins are connected correctly. Digilent uses a confusing naming scheme for the UART pins, with TX denoting the line that transmits data from the host PC to the board and RX the line receiving data from the board. It seems that you need to swap the UART pins in your XDC file, since according to the documentation of the Nexys 4 DDR C4 is an input pin (hence the receiving pin which should be connected to uart_rx_i) and D4 is an output pin (which should be connected to uart_tx_o).

from vicuna.

Thank you @michael-platzer I actually suspected the uart pins and I considered swapping the pins, but after changing the baud rate from 115200 to 9600 it is now working... A bit wired that apparently the baud rate was the problem but anyway it is working so thank god...
I have learned a lot from you in this couple of days and I really appreciate it.

from vicuna.

Glad to hear that it is working now, although it should work with either baud rate. Just for clarification: did you swap the UART pins or not?

from vicuna.

Thank you @michael-platzer , yes I did swap the pins... As you said the naming was confusing....

from vicuna.