USB Keyboard on Baysy3

[joemost]

Hi Everyone,

I am trying to use the keyboard input on a basys 3. I am new to this and trying to do this in verilog.. so there wasn't a ton of documentation. I tried to setup the keyboard with the board, but nothing seemed to lightup on the keyboard (Usually the caps lock key lights up so I figured it may or may not be an issue

 

However, the keyboard does not seem to respond..

I realized I have a USB Keyboard.. Is that a problem? I also attatched the code just in case.. but I can't find an issue in that

keyboard.v

[D@n]

@joemost,

Yes, a USB keyboard should work just fine with the Basys3.

I, personally, haven't tested the Basys3 with a USB keyboard, but I have tested it with the PS/2 mouse and so ... I know a little about it.  (Two keyboards just didn't fit on my desk as easily as two mice.)

Looking over the code you posted, though, I thought I might make some comments:

1. Many FPGA neophytes try to create a clock via the method you did with your DOWNCOUNTER, and then try to trigger off of that clocks positive edge.  You did not.  Well done!  Your code for dropping the sample rate was almost exactly like I would've done it.
2. You do, however, have a problem with metastability in your code.  It might not get you, but then again, it might.  To avoid this, take your two PS2 inputs and clock them twice before using them.  As in: always @(posedge CLK) begin r_ps2_dat <= PS2_DATA; ck_dat <= r_ps2_dat; end  You should do this with both the clock and data lines.  Without doing this, your code will work most of the time (the PS2 interface is slow), but it will experience random failures.  You should get in the habit of always clocking any asynchronous inputs (asynchronous to your CLK that is) like this twice upon arrival.
3. I was going to scold you for making your PS2_CLK and PS2_DATA lines inputs, rather than inouts, but the difference appears to be my background with the mouse protocol.  With mouse transfers, you need to do bidirectional communication, and hence you need to declare your inputs as inout. What you've got, though, looks good for the keyboard.
4. You didn't post your XDC file, so I can't tell if you 1) have the right wires, 2) that your internal names match your external names, and 3) that you placed PULLUPs on the wires.  This shouldn't be rocket science, though, most of that stuff is already in the master XDC ... you just need to uncomment it properly.
5. Can you tell if the clock line is ever getting pulled low?  if read is ever going high?  How many bits you are ever reading from the interface?  I guess my advice would be, in the absence of any better feedback, use your LED's and a counter for feedback.  You know, set an LED to the PS2 CLK and data values--that should tell you if either are ever getting stuck at zero.  Set another LED to the top bit of a counter that's reset everytime read goes high and see if pressing a key resets that counter, etc.

I guess the biggest critique I might have is ... do you have any debug infrastructure?  You know, scaffolding types of stuff that you'll pull down later?  Specifically, I'd wonder if your code 1) has a test bench, 2) has been proven to work off line using your test bench, and 3) if you have a means of "seeing" what is happening with your code.  In other words, when a transaction takes place, can you get a "trace" of what signals are toggling when/how?

Had you been working on a mouse protocol, I'd be able to help you personally a touch more: I have a mouse simulation that your code could be tested against, and I could just plug this code into that simulation and see if, where, and how your code works (or doesn't).

Oh, and just to please our Digilent hosts, I think I'm supposed to point you to a Digilent's solution to this problem--even though, were I in your shoes, I'd actually want some wise sage to point out the problems in my own design. 

Dan

[D@n]

@joemost,

Ok, I actually did find an error or two:

1. You don't clear TRIG_ARR in the case of a negative (or positive) edge.  You could place a line immediately after if (TRIGGER) begin that says TRIG_ARR <= 1'b0.  This line would then (possibly) get overridden by the logic that follows, but it would also certainly guarantee that a default value was always set.
2. You didn't gate the LED up or down with a detection.  Hence, if you receive an ARROW_UP, the led counter will be going up at such a fantastic rate of speed that you won't be able to watch it go.  You'll want to slow that down A LOT to get to human time.
3. You might also wish to add `default_nettype none to the top of your code.  It might help you catch synthesis problems that you can't see.  Should you do so, however, your "input" types will need to change to "input wire" types.
4. I see where you are setting COUNT to zero, and checking for it equalling 11 ... but what will happen if it ever gets into a state where COUNT = 12?  Just something to think about.

Dan