ZipCPU / arrowzip

A ZipCPU based demonstration of the MAX1000 FPGA board
21 stars 5 forks source link

RTC working ? #4

Closed NeuerUser closed 5 years ago

NeuerUser commented 5 years ago

Hi Dan

Just a short question: Is it possible that the rtclight module is not really working?

I do have the regs CLOCK, ALARM, TIMER, STOPWATCH, but none of them counts in any case. I can set the regs, but they don't seem to change at all.

But maybe I am missing something...

ZipCPU commented 5 years ago

I just checked that they were working in simulation the other day, but yeah, I see your point, nothing seems to be changing now. Further, the clock divider register, used to set the clock speed, isn't named. If I read from that register (it's 4-bytes after the alarm data), I see that the clock divider (ckspeed in rtclight.v) is set to zero. It's not supposed to be set at zero, so ... I might need to peel this onion back a step or two.

Perhaps Quartus doesn't like a register with initial but no always block?

ZipCPU commented 5 years ago

Fixed! Clock, timer, and stopwatch all work now. Alarm should work, although I haven't tested it. You can also read the "CKSPEED" register to see the fractional clock divider. (You'll need to adjust the OPT_FIXED_SPEED parameter if you want to adjust the clock speed.)

NeuerUser commented 5 years ago

Sorry to come back again, but I think the stopwatch functionality is broken. The src code says "write 1" to the reg to start and "0" to stop. "2" clears. However, currently it seems that just every write to it just toggles the running state. So writing "0" also starts, when it is not running, and stops, when it is. Nothing clears the stopwatch.

ZipCPU commented 5 years ago

Fixed!

NeuerUser commented 5 years ago

Hi Dan

Sorry to be a pain in the a.., but the stopwatch now stops with every read. So, clearing works, starting and stopping works, but every read also stops the watch.

ZipCPU commented 5 years ago

Fixed again! Try it now.

NeuerUser commented 5 years ago

Hi Dan

Not sure, if I'm doing something wrong. I typically make clean, then pull the latest commits and make the project again (as always, I need to restart make two times in order to have it finish, because of verilator warnings->errors). I then add the qsf and qpf files from quartus and any missing verilog files (e.g. altera_gpio_lite.v). Then compile with quartus and program to the MAX1000.

Anyway, the result is that there is no change to the stopwatch bug. I cannot even see a commit that would fix the bug?!

(But I also have other issues with hello.c and memtest.c, but I will open a new issue for that, in case it is not because of some errornous workflow I am using.)

ZipCPU commented 5 years ago

So ... I took another look at the stopwatch. It's still not working, but I can see what's wrong this time. I'll post a patch as soon as I test my fix. This newer bug shouldn't be a "no change" issue, however. It's something you haven't seen before, so if you are seeing "no change" than my best guess is that you haven't updated the design.

I've had no end of trouble with Quartus not updating the SVF file. It seems like I need to re-open the "program device" dialog every time I want to program the device in order to get the most recent build onto the device.

Check the VERSION and BUILDTIME registers with wbregs. The version should be 20170307 and the build time 00170606 (or later). This would explain your other problems too.

NeuerUser commented 5 years ago

Hi Dan

$ ./wbregs version
00800014 ( VERSION) : [....] 20190307
$ ./wbregs buildtime
00800000 (BUILDTIME) : [..(@] 00172840
$ ./wbregs stopwatch
00a00048 (STOPWATCH) : [...p] 00000000
$ ./wbregs stopwatch 2; ./wbregs stopwatch 1; sleep 2; ./wbregs stopwatch; sleep 3; ./wbregs stopwatch
00a00048 (STOPWATCH)-> 00000002
00a00048 (STOPWATCH)-> 00000001
00a00048 (STOPWATCH) : [....] 80000202
00a00048 (STOPWATCH) : [....] 00000202

Looks as if I have a newer design on it. But still every read stops the stopwatch.

Maybe something is wrong with my workflow. As I mentioned:

Maybe I should open a new issue and post there my full workflow. Maybe I should also upload my changed repo (with the extra files), so you could try to check it out and build from Quartus.

ZipCPU commented 5 years ago

No, now your symptoms are matching mine. That's the fix I'm testing now. The fix seems to work, so look forward to a post shortly. (I'll write it here too.)

ZipCPU commented 5 years ago

How's this?

$ ./wbregs stopwatch 1 ; sleep 2 ; ./wbregs stopwatch; sleep 3; ./wbregs stopwatch 
00a00048 (STOPWATCH)-> 00000001
00a00048 (STOPWATCH) : [....] 80000201
00a00048 (STOPWATCH) : [....] 80000502
$ 

Note that the last two digits are 10ths of seconds, so 0x201 says that 2.01 seconds have passed.

Changes are now posted. I also double checked memtest and it works, as does hello (now--I had to fix a bug in the ZipCPU stubs for the C-library, check out the syscalls.c in sw/zlib if you are interested).

Dan

NeuerUser commented 5 years ago

Yes, looks good also on my board now. Thanks!