jbush001 / NyuziProcessor

GPGPU microprocessor architecture

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

run_fpga command does not work properly for me

ergintr opened this issue · comments

Hey sir,
I synthesized the project from terminal and programmed it via quartus gui(could not do it via terminal), after that when I try ./run_fpga for different tests I just get yellow and white colors with no motion. The tests I have done are :

  • NyuziProcessor/software/apps/colorbars/run_fpga : I just get a full yellow screen on monitor
  • NyuziProcessor/software/apps/rotozoom/run_fpga : I get the steady image below with no motion
    WhatsApp Image 2021-12-24 at 15 20 07

*NyuziProcessor/software/apps/plasma/run_fpga : I get the steady image below with no motion
WhatsApp Image 2021-12-24 at 15 20 07(1)

  • Another problem is I have faced is that when I run ./run_verilator from software/apps directories to see vga_r, vga_b, vga_g values(as suggested in NyuziProcessor/hardware/testbench/soc_tb.sv : line 234) , they are always zero in gtkwave window.
    Is there any suggestion about how to resolve these problems ?
    Thank you.

When running in the testbench, the VGA signals aren't going to show anything interesting. That module is usually disabled, and, when it is not, the simulation doesn't run long enough to display interesting data, as will spend many cycles in the vblank (that module exists just to debug the memory transactions).

As for the other issues: these are very strange. To start out, have you made any changes to the code (could you do a quick 'git diff' to check)? Which version of the Quartus tools are you using?

Thanks for reply,
I use QUARTUS Lite 20.1 version. I have made the following changes :

Ah, thanks.

  1. The graphics seem to only be yellow and white, which suggests the R and G lines aren't connected properly (stuck at 1), with only the B line connected. I'd suggest checking the pin configuration.
  2. I don't believe the current SDRAM controller will work correctly if configured for 16 bits, as it doesn't handle the bus width and SDRAM width being different. This was a quick and dirty controller to bring up on my board, so it was hard coded as such. I'm a bit surprised this configuration works at all. If you can find another SDRAM module with an AXI interface (for example, I think Quartus may have one in their library), that might be easier, otherwise this would need a bit more logic to latch the upper and lower half words before putting them into the load_fifo (and likewise for stores).

Closing, as this is an unsupported configuration.

Thank you, for your help Sir.

Sorry there wasn't a better answer.