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

Question

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

LaytonZhang opened this issue 5 years ago · 43 comments

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.

Answer 1 · 2020-03-01T14:36:26.000Z

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?

Answer 2 · 2020-03-01T14:42:13.000Z

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.

Answer 3 · 2020-03-01T14:49:16.000Z

当您按下重新配置按钮时，绿色的“完成” 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.

Answer 4 · 2020-03-01T16:44:26.000Z

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?

Answer 5 · 2020-03-02T02:05:53.000Z

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.

Answer 6 · 2020-03-02T03:10:56.000Z

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

Answer 7 · 2020-03-02T08:21:27.000Z

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

Answer 8 · 2020-03-02T08:39:15.000Z

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.

Answer 9 · 2020-03-02T09:44:53.000Z

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?

Answer 10 · 2020-03-02T09:56:12.000Z

Did you use the load command in gdb also?

Answer 11 · 2020-03-02T10:03:44.000Z

Did you use the load command in gdb also?

No, I did't

Answer 12 · 2020-03-02T10:05:20.000Z

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

Answer 13 · 2020-03-02T10:19:21.000Z

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

Answer 14 · 2020-03-02T10:22:57.000Z

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.

Answer 15 · 2020-03-02T10:28:17.000Z

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

Answer 16 · 2020-03-02T10:28:43.000Z

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

vivado 2018.3
ubuntu 16.04.3

Answer 17 · 2020-03-02T10:31:40.000Z

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

Answer 18 · 2020-03-02T10:33:33.000Z

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.

Answer 19 · 2020-03-02T10:35:39.000Z

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

Answer 20 · 2020-03-02T10:44:19.000Z

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

Answer 21 · 2020-03-02T11:16:59.000Z

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

Answer 22 · 2020-03-02T11:18:43.000Z

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

Answer 23 · 2020-03-02T11:31:19.000Z

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

Answer 24 · 2020-03-02T11:34:05.000Z

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

OK,thank you very much.

Answer 25 · 2020-03-03T04:01:41.000Z

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

Answer 26 · 2020-03-03T04:10:22.000Z

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.

Answer 27 · 2020-03-03T09:04:14.000Z

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.

Answer 28 · 2020-03-03T10:12:55.000Z

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

Answer 29 · 2020-03-03T10:29:07.000Z

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

Answer 30 · 2020-03-03T10:29:38.000Z

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

Answer 31 · 2020-03-03T10:45:18.000Z

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

Answer 32 · 2020-03-03T10:58:34.000Z

Timing Report

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

Answer 33 · 2020-03-03T11:08:08.000Z

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

Answer 34 · 2020-03-03T11:11:04.000Z

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

Answer 35 · 2020-03-03T11:12:44.000Z

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.

Answer 36 · 2020-03-03T11:17:34.000Z

I used USB directly instead of DC to power the board

Answer 37 · 2020-03-03T11:22:47.000Z

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

Answer 38 · 2020-03-03T11:30:57.000Z

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.

Answer 39 · 2020-03-03T11:36:59.000Z

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

Answer 40 · 2020-03-03T11:49:02.000Z

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.

Answer 41 · 2020-03-03T11:57:24.000Z

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

Answer 42 · 2020-03-23T03:19:39.000Z

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?

Answer 43 · 2020-03-23T06:55:51.000Z

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 ***@***.***> 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.