nand2mario / nestang

NESTang is an FPGA Nintendo Entertainment System implemented with Sipeed Tang Primer 25K, Nano 20K and Primer 20K boards
https://nand2mario.github.io/nestang
GNU General Public License v3.0
326 stars 36 forks source link

[Migration to softcore] Some issues bringing up the uC #60

Closed fjpolo closed 3 months ago

fjpolo commented 3 months ago

@nand2mario, so I've been checking Design notes for SNESTang, Adding a Softcore to SNESTang - part 1 and Adding a Softcore to SNESTang - part 2 and trying to adapt src/iosys and firmware to Nano20k here: fjpolo/TangNano20k_Softcore.

So far the idea was to have a simple while(1) to blink LED[0] every second. For that I just added the while(1) before the proper code in firmware.c's main(). I also added #define reg_led (*(volatile uint32_t*)0x02000060) in picorv32.h and led_reg = mem_valid && (mem_addr == 32'h 0200_0060); in iosys.v, where I also added output [1:0] led and assign led = led; to connect it to the board in nestang_top.sv.

I tried to add some control logic for the RV RAM, but probably I am missing something there, it might be that iosys is loading the .bin into 0x000000 and that's the NES' RAM. Or it can be that MemoryController is incorrect.

It could also be that Flash's not configured/working correctly, since I tried assign led[0] = flash_loaded; in iosys.v and led[0] stays low. I guess the configuration for Flash pins is correct:

image

Would you mind taking a quick look at the branch to see if you see something there?

fjpolo commented 3 months ago

I'll actually try to bring up the softcore + Memory in here: fjpolo/TangNano20k_softcoreStandalone

nand2mario commented 3 months ago

I've got the softcore running on the iosys branch. It requires the latest firmware from the snestang repo. You can use the 0.9-test1 and firmware-0.9-test1 tags for a working version. The main clock is about 21.477Mhz.

fjpolo commented 3 months ago

Seems that's not synthesizable for the nano: ERROR (RP0006) : The number(27548(26308 LUTs, 886 ALUs, 0 ROM16s, 59 SSRAMs)) of logic in the design exceeds the resource limit(20736) of current device

Same for Primer: ERROR (RP0006) : The number(27563(26335 LUTs, 886 ALUs, 0 ROM16s, 57 SSRAMs)) of logic in the design exceeds the resource limit(23040) of current device

Maybe a missing define? Missing configuration? Not all changes pushed to iosys branch?

nand2mario commented 3 months ago

Forgot to mention the current branch is only for primer 25k. I am traveling and will sort out the build issues once I got home in two days.

Regarding the LUT issue. Are you using Gowin IDE >1.9.9? 1.9.9.1 disabled SSRAM for some unknown reason. I am sticking with 1.9.9 for now.

fjpolo commented 3 months ago

I'm on v1.9.9: image

I did try to synthesize for Primer also, and got the same error, but will try again later just in case

Edit: this is the Primer project: image

radiance28 commented 3 months ago

image

I just checked to compile branch iosys on GoWin1.99 (64bit) (no beta) and everything worked for Primer25k.

image

image

image

nand2mario commented 3 months ago

Right. The commercial version (1.9.9) works, while the EDU version (1.9.9-beta4) produces the "numbe rof logic exceeded" error.

fjpolo commented 3 months ago

Ahh that makes more sense, just downloaded v1.9.9 and installed it. Required a licence and I'm waiting for GOWIN, so I'll update when I get it.

Edit: I can confirm now that using normal IDE v1.9.9 Primer synthesises :)

Now, since I don't own one, I also tried Nano (I know you said it only supports Primer) and there's an error but the IDE doesn't show me exactly where it is:

ERROR (PA2122) : Not support 'mem_mem_0_0_s'(DPB) WRITE_MODE0 = 2'b10, please change write mode WRITE_MODE0 = 2'b00 or 2'b01.

A search on WRITE_MODE0 takes me to gowin_dpb_menu.v line 58:

defparam dpb_inst_0.WRITE_MODE0 = 2'b00;

where WRITE_MODE0 is defined as 2'b00 and not as 2'b10 as the error says. I gues it might be realted to DPB dpb_inst_0() instantiation

nand2mario commented 3 months ago

These should all be fixed as part of v0.9.

The dual-port memory issue was due to an unsupported write mode (read-before-write) for GW2A.