Synthesis simulation mismatch, when targeted for xc6slx9-2tqg144 using XILINX ISE 14.7

[proteus-cpi]

Hi Clifford

1. Tried targeting the picorv32 to spartan6 board (papilio pro). Unfortunately the port didn't run on the target. On further investigation, noticed that while behavioral simulation worked, none of the post- translate, post-map or post-place and route simulations did not work as well. Seems to generate some trap after a few cycles! The result seems to be the same for both FAST_MEMRY=0 and 1!

   Any pointers to debug this?

2. Is there a GDB stub or as such that can be used to debug the firmware for example using a serial port?

[cliffordwolf]

Ad 1.) Can you synthesize with keep_hierarchy and post any of the post synthesis netlists for PicoRV32?

Ad 2.) Not yet. I've done some preliminary work in this direction, but don't hold your breath..

[proteus-cpi]

I can see the problem from the netgen output (system_synthesis.v) @ about #32448 ! Though XST correctly infers the memory to RAMB16BWER, it connects the wrong address lines! @ line #32552

.ADDRA({\mem_la_addr[10] , \mem_la_addr[9] , \mem_la_addr[8] , \mem_la_addr[7] , \mem_la_addr[6] , \mem_la_addr[5] , \mem_la_addr[4] , \mem_la_addr[3] , \mem_la_addr[2] , \NLW_Mram_memory1_ADDRA[4]_UNCONNECTED , \NLW_Mram_memory1_ADDRA[3]_UNCONNECTED , \NLW_Mram_memory1_ADDRA[2]_UNCONNECTED , \NLW_Mram_memory1_ADDRA[1]_UNCONNECTED , \NLW_Mram_memory1_ADDRA[0]_UNCONNECTED }),

For some reason it is not connecting lowest 5 lines to un-connected signals instead of the mem_la_addr lines! Apparently an XST issue?!

Is there way to retain the RAM inference, but still correct the connection problem?

system_synthesis.v.zip system.v.zip

[cliffordwolf]

No, that looks right. The memory is 32 (36 with parity) bits wide, so the lower 5 bits address bits are unused. (mem_la_addr[0] and mem_la_addr[1] are always zero because all memory access is aligned to 32 bits.)

Could you please synthesize with keep_hierarchy, as I asked before, and post any of the post synthesis netlists for PicoRV32?

Also: What test-bench are you using? Are you waiting for the Xilinx GLBL to finish (100 ns delay)?

[proteus-cpi]

Yup. Figured that out only later. :(

Attached, in the zip archive (sorry github didn't allow uploading ngc file), are :

1. picorv32.ngc : synthesized after selecting picorv32 as top module
2. system.ngc : synthesized with "system" as top module
3. The testbench
4. firmware.hex

Are you waiting for the Xilinx GLBL to finish (100 ns delay)?

Yes, the testbench already had the 100ns delay before resetn is de-asserted, in the initial block.

What I observed (from running the post-translate simulation in isim) was that the first instruction fetched after reset seems to be "00000000"; though examining memory in the simulator shows INIT_00 : 10000737...00004137.

And execution traps, apparently on decoding "000"!

picorv32_files.zip

[cliffordwolf]

What I observed (from running the post-translate simulation in isim) was that the first instruction fetched after reset seems to be "00000000"; though examining memory in the simulator shows INIT_00 : 10000737...00004137.

Yes, I can confirm that. The synthesis problem is with the system module, not with PicoRV32. Here is a screenshot of a simulation that is using the behavioral model from system.v you provided earlier and the picorv32 core from system.ngc (it prints BABABABA.... to the console):

Here is the same simulation with system from system.ngc:

The memory content looks fine, and so does the behavior of the PicoRV32 CPU core, but the memory ENA input never goes high and so the memory is not read. (Of course WEA should then be zero in the cycles ENA is high, otherwise the memory will be written in addition to being read.)

According to the HDL code in system.v, the memory should be read all the time and thus ENA should never be in a low state.. This clearly is an ISE/XST bug.

Because of that PicoRV32 read all-zeros as instructions, which it cannot handle itself. It tries to deligate it via PCPI, but of course this runs into a timeout and then the processor goes into its trap state.

I'm now closing this issue because I think there is nothing I can do here. You can try variations of the HDL code in system.v, including setting FAST_MEMORY = 0 and see if that somehow works around the XST bug. I've reported a few XST bugs in the last couple of years, but Xilinx support deemed them all "non critical" and thus none of them got fixed..

Feel free to re-open this issue if you think there is anything else I can do to help.

[proteus-cpi]

Thanks cliff.

Am going to try with zed board. Already tried with ISE, with same result! Am going to give a shot with Vivado shortly.

Meanwhile looking forward to the gdbstub stuff. Was looking to the MilkyMist LM32 stub and flterm to see if it can be hacked so that picorv32 running on icarus or verilator could be debugged without hardware. But not still very clear about the picorv32 microarchitecture, so looks quite tough.

Thanks for looking into the issue.