Closed sy2002 closed 4 years ago
P.S. We could also move this to V1.7 because I can live with the old HyperRAM driver in V1.6. But just in case that there is an semi-easy fix, because this keyboard thing seems to be a looming damokles sword, I put it on V1.6.
Since I don't have a MEGA65 myself, this is indeed "blind fixing" :-)
Anyway, looking at the file hw/MEGA65/keyboard.vhd
and the process map_mega65_to_qnice
my first attempt would be to change the reset from asynchronous to synchronous. Remember to change the sensitivity list, so only the clock signal appears. This should at least take care of the warning. Whether it fixes the problem, well, we can hope so ...
If that doesn't help, then our new ILA could be of help!
Thank you: Your hint about the asynch. to synch. reset was golden. This fixed it.
@MJoergen I had a super strange effect: Paul fixed the HyperRAM driver (see commit f2fb7bc), just a few lines of code, and when I synthesized it, the MEGA65 keyboard did not work any more. When I rolled it back (see commit 44a59fe) everything started to work perfectly again. HyperRAM is unrelated to keyboard. And it were just a few lines of code from Paul, as you can see in the commits.
I guess the reason is the same why we had trouble with the keyboard on the Nexys: As you were magically able to fix the problem on Nexys, maybe you can also have a look at this? I know, this is kind of "blind" fixing - I will also try it when I am back from my vacation, but any help is highly appreciated.
This is a warning that I (always) got and (always) ignored, beause things worked fine. Maybe this is the completely wrong road but here it is:
[DRC REQP-1840] RAMB18 async control check: The RAMB18E1 kbd/ff_spec_code_reg has an input control pin kbd/ff_spec_code_reg/ENARDEN (net: kbd/ff_ascii_key0) which is driven by a register (mmio_controller/FSM_onehot_global_state_reg[0]) that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default.
The strange thing is (similar to the effect we had a while ago on Nexys): It worked perfectly. All the time. Then I updated an HyperRAM driver that has nothing to do with the keyboard and then the keyboard broke...
The keyboard driver of the MEGA65 is described here and my wrapper is https://github.com/sy2002/QNICE-FPGA/blob/develop/vhdl/hw/MEGA65/keyboard.vhd