lowRISC / lowrisc-chip

The root repo for lowRISC project and FPGA demos.
http://www.lowrisc.org/
Other
596 stars 148 forks source link

Ariane-v0.7-VGA is always black (Nexys A7 100T) (nexys-ddr4-rocket) #166

Open LaytonZhang opened 4 years ago

LaytonZhang commented 4 years ago

Hi, I have finish all the steps following https://www.cl.cam.ac.uk/~jrrk2/docs/xilinx/. After the command ''make nexys4_ddr_rocket_cfgmem'' ,

Mfg ID : 1 Memory Type : 20 Memory Capacity : 18 Device ID 1 : 0 Device ID 2 : 0 Performing Erase Operation... Erase Operation successful. Performing Program and Verify Operations...

Program/Verify Operation successful. INFO: [Labtoolstcl 44-377] Flash programming completed successfully program_hw_cfgmem: Time (s): cpu = 00:00:00.92 ; elapsed = 00:05:28 . Memory (MB): peak = 2208.875 ; gain = 31.000 ; free physical = 3284 ; free virtual = 20889

endgroup

INFO: [Common 17-206] Exiting Vivado at Sun Mar 1 21:11:36 2020... make[1]: Leaving directory '/home/layton/lowrisc-chip-ariane-v0.7/fpga'

After I insert the SD-card, set all the SW to '0' and PROG , my VGA is alway black.

jrrk commented 4 years ago

How very strange, does the green ‘done’ LED come on when you press the reconfigure button? Have you tried the pre-made binaries in the release area of the website?

LaytonZhang commented 4 years ago

How very strange, does the green ‘done’ LED come on when you press the reconfigure button? Have you tried the pre-made binaries in the release area of the website?

Yes, It turns green. Before I build the project, I tried the pre-made binaries and It did not work in the same way. VGA is not really black, it is lighted, but has nothing showing on it. Last week I had ever tried version v0.6 and it works well.

LaytonZhang commented 4 years ago

当您按下重新配置按钮时,绿色的“完成” LED会亮得多么奇怪?您是否在网站的发布区域中尝试了预制的二进制文件?

v0.6 when I reset the cpu, the led will be lighted colorfully. whether v0.7 is same as it? When I pressed PROG , nothing happened with ' Done ' turned green.

jrrk commented 4 years ago

Have you tried the ‘make debug’ target. This would establish if the CPU is working. You can load in a program with gdb and test the operation that way. The bi-colour LEDs are not used by default in this release. What was the behaviour with the pre-made v0.7 target?

LaytonZhang commented 4 years ago

Have you tried the ‘make debug’ target. This would establish if the CPU is working. You can load in a program with gdb and test the operation that way. The bi-colour LEDs are not used by default in this release. What was the behaviour with the pre-made v0.7 target?

layton@layton-X542UQR:~/lowrisc-chip-ariane-v0.7$ make debug make -C lowrisc-quickstart debug make[1]: Entering directory '/home/layton/lowrisc-chip-ariane-v0.7/lowrisc-quickstart' ../buildroot-2019.11.1-lowrisc/mainfs/host/bin/openocd -f openocd-nexys4ddr.cfg Open On-Chip Debugger 0.10.0+dev-07125-g37e845d (2020-03-01-17:07) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling" Info : clock speed 10000 kHz Info : JTAG tap: riscv.cpu tap/device found: 0x13631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x1) Info : datacount=2 progbufsize=16 Info : Disabling abstract command reads from CSRs. Info : Examined RISC-V core; found 1 harts Info : hart 0: XLEN=64, misa=0x800000000014112d Info : Listening on port 3333 for gdb connections Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections

Is it right?
I program the pre-made v0.7 again, rocket and araine, but they have the same problem.

LaytonZhang commented 4 years ago

Have you tried the ‘make debug’ target. This would establish if the CPU is working. You can load in a program with gdb and test the operation that way. The bi-colour LEDs are not used by default in this release. What was the behaviour with the pre-made v0.7 target?

make gdb (gdb) target extended-remote /dev/ttyUSB1 Remote debugging using /dev/ttyUSB1 Ignoring packet error, continuing... warning: unrecognized item "timeout" in "qSupported" response Ignoring packet error, continuing... Remote replied unexpectedly to 'vMustReplyEmpty': timeout

jrrk commented 4 years ago

The make debug output appears to be correct. The make gdb usage is not correct. You need to run make debug in one window and make gdb in another window, and then use 'target remote :3333' to launch remote debugging. You can find more details here

jrrk commented 4 years ago

You can also try the command:

make nexys4_ddr_rocket_new

This will recompile the boot loader and create a patched bitstream, it should take less than 5 minutes the first time through. You should also examine the serial port output (if any) as output by the command:

microcom -p /dev/ttyUSB?

where ? is a computer dependent number.

LaytonZhang commented 4 years ago

You can also try the command:

make nexys4_ddr_rocket_new

This will recompile the boot loader and create a patched bitstream, it should take less than 5 minutes the first time through. You should also examine the serial port output (if any) as output by the command:

microcom -p /dev/ttyUSB?

where ? is a computer dependent number.

I rebuild it using 'make nexys4_ddr_rocket_new' , and make debug , make gdb. Info : Listening on port 3333 for gdb connections Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : accepting 'gdb' connection on tcp/3333 Info : Disabling abstract command writes to CSRs.

Then I find the program can't run even if I set the breakpoint at the beginning of the main(). LIke this (gdb) c Continuing.

At the same time, the serial port has no information. How strange! Maybe CPU is not working?

jrrk commented 4 years ago

Did you use the load command in gdb also?

LaytonZhang commented 4 years ago

Did you use the load command in gdb also?

No, I did't

LaytonZhang commented 4 years ago

I'm a newbie, now I'm in junior year. I am learning RISC-V,Please trouble you

jrrk commented 4 years ago

OK, I have added more detail to the documentation to get you going if possible. The correct usage of gdb is:

target remote :3333 load break main cont

LaytonZhang commented 4 years ago

OK, I have added more detail to the documentation to get you going if possible. The correct usage of gdb is:

target remote :3333 load break main cont

Thanks a lot. I will have a try. And learn knowledge about GDB. After that, if I have problem, I will ask for your help.

jrrk commented 4 years ago

By the way, what version of Vivado are you using ?

LaytonZhang commented 4 years ago

By the way, what version of Vivado are you using ?

vivado 2018.3 ubuntu 16.04.3

LaytonZhang commented 4 years ago

Will it cause any problem? If yes, maybe i should install vivado2018.1 and retry

jrrk commented 4 years ago

It should be OK, but the one we use by default is 2018.2. If you are looking for other ideas to try, a different version of Vivado might be of interest. This is because each version has different versions of the intellectual property blocks as well as a change to the synthesis engine.

LaytonZhang commented 4 years ago

Ok, if I can't sovel the problem, I will try 2018.2

jrrk commented 4 years ago

What kind of VGA monitor are you using? Does it have a menu button that allows you to view the incoming vertical and horizontal frequency ? It should say "analogue input" 1024x768 @60Hz

LaytonZhang commented 4 years ago

1400 *900 @60hz I think it works, because it displays rightly when running lowrisc v0.6

LaytonZhang commented 4 years ago

When I input command 'load', the debug terminal shows:

Info : accepting 'gdb' connection on tcp/3333 Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001002). Increase the timeout with riscv set_command_timeout_sec. Error: Abstract command ended in error 'busy' (abstractcs=0x10001102) Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001102). Increase the timeout with riscv set_command_timeout_sec. Error: Abstract command ended in error 'busy' (abstractcs=0x10001102) Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001102). Increase the timeout with riscv set_command_timeout_sec. Error: Abstract command ended in error 'busy' (abstractcs=0x10001102) Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001102). Increase the timeout with riscv set_command_timeout_sec. Warn : negative acknowledgment, but no packet pending

jrrk commented 4 years ago

It's not working. I think your best option is to install Vivado 2018.2, rm -rf fpga/work-fpga and re-build.

LaytonZhang commented 4 years ago

没用 我认为您最好的选择是安装Vivado 2018.2,rm -rf fpga / work-fpga并重新构建。

OK,thank you very much.

LaytonZhang commented 4 years ago

It's not working. I think your best option is to install Vivado 2018.2, rm -rf fpga/work-fpga and re-build.

I uninstall VIVADO 18.3 today, and using vivado 18.2 rebuild the project. However, I get the same result.

information on the 'debug terminal' Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling" Info : clock speed 10000 kHz Info : JTAG tap: riscv.cpu tap/device found: 0x13631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x1) Info : datacount=2 progbufsize=16 Info : Disabling abstract command reads from CSRs. Info : Examined RISC-V core; found 1 harts Info : hart 0: XLEN=64, misa=0x800000000014112d Info : Listening on port 3333 for gdb connections Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : accepting 'gdb' connection on tcp/3333 Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001002). Increase the timeout with riscv set_command_timeout_sec. Error: Abstract command ended in error 'busy' (abstractcs=0x10001102) Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001102). Increase the timeout with riscv set_command_timeout_sec. Error: Abstract command ended in error 'busy' (abstractcs=0x10001102) Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001102). Increase the timeout with riscv set_command_timeout_sec. Error: Abstract command ended in error 'busy' (abstractcs=0x10001102) Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001102). Increase the timeout with riscv set_command_timeout_sec. Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Error: Abstract command ended in error 'busy' (abstractcs=0x10001102) Error: Timed out after 2s waiting for busy to go low (abstractcs=0x10001102). Increase the timeout with riscv set_command_timeout_sec. Warn : negative acknowledgment, but no packet pending Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1497). Workaround: increase "set remotetimeout" in GDB

information on GDB terminal: Remote debugging using :3333 0x0000000000010040 in ?? () (gdb) load Loading section .text.init, size 0x13d lma 0x87fe0000 Loading section .text, size 0x5e38 lma 0x87fe0200 Ignoring packet error, continuing... Load failed

LaytonZhang commented 4 years ago

I think if the pre-made binaries works , I should get the correct result if I program it using vivado. But it is doesn't work.

jrrk commented 4 years ago

This is a profound mystery, these images were tested on the Nexys4-DDR board. I don't have an example of the newer Nexys A7-100T, to all accounts it is just a rename with the option of two different sized FPGAs. Without a complete transcript of your session, it is difficult to comment further. I presume when you reinstalled Vivado, you ticked the SDK option. You should also check out the fpga/reports directory to see if any errors were reported. Finally it might be worth trying a different board if you have access to one.

jrrk commented 4 years ago

Also, check what release you are using for pre-made images, you should use these ones

LaytonZhang commented 4 years ago

Thank you. I got right release, and ticked sdk when install 2018.2. Besides, I checked the report and found slack < 0.

LaytonZhang commented 4 years ago

Thank you. I got right release, and ticked sdk when install 2018.2. Besides, I checked the report and found slack < 0.

jrrk commented 4 years ago

Slack was -0.764ns on my build. More negative numbers are worse, so just checking for a number < 0 is not sufficient.

LaytonZhang commented 4 years ago

Timing Report

Slack (VIOLATED) : -1.278ns (required time - arrival time)

LaytonZhang commented 4 years ago

it's really strange. I think slack(-1.278 ns) shouldn't result in CPU's not working

LaytonZhang commented 4 years ago

Will the hardware cause such problems? Such as SD card?

jrrk commented 4 years ago

Perhaps, perhaps not. Your board could have a lower power voltage or slower chip than my one. The surprising thing is that running the exact same setup I have should give such a different result. This would explain why the pre-made images don't work. If you could borrow another board to try this would help solve the mystery.

LaytonZhang commented 4 years ago

I used USB directly instead of DC to power the board

LaytonZhang commented 4 years ago

I've troubled you these days, you are such a good person. I have been so grateful for your help

jrrk commented 4 years ago

I develop using USB supply from the PC also. However some PCs cannot supply enough current from the USB to power this board properly. A separate power supply might help, it depends how motivated you are to update to the latest release. It's my job to support and encourage adoption of this new release, however it comes to an end this Friday 6th March. After that only very limited support for queries will be available.

LaytonZhang commented 4 years ago

Oh, I'm so lucky. I will try my best to finish it and Give you feedback these days

jrrk commented 4 years ago

The SD-Card is not used at this early stage in booting. There should be definitely be some text output on the screen before the SD-Card is accessed.

LaytonZhang commented 4 years ago

Therefore, reason causing this strange problem should be borad and supply. I will continue to solve this problem.

LaytonZhang commented 4 years ago

Hi, I get a new Nexys a7 and sucessfully run the linux. Now I want to add some new peripheral. How should I generate a vivado project? If there is a similar tcl script like make_project.tcl in v0.6?

jrrk commented 4 years ago

Probably best to close this issue and open a new one for posterity. The new flow doesn’t use .xpr files. You can customise your peripherals by adding to:

https://github.com/lowRISC/ariane/blob/ariane-v0.7/fpga/src/ariane_peripherals_xilinx.sv

and modifying the width of the arrays in the AXI demux module. You might need to add new pinout constraints also.

Sent from my iPhone

On 23 Mar 2020, at 03:20, zlt323 notifications@github.com wrote:

 Hi, I get a new Nexys a7 and sucessfully run the linux. Now I want to add some new peripheral. How should I generate a vivado project? If there is a similar tcl script like make_project.tcl in v0.6?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.