10-18-2012 09:17 AM - edited 10-18-2012 09:23 AM
I have been playing with video generation on this board using Verilog in the Xilinx ISE. I have some composite video output running rather nicely from the board, so I'm quite pleased with myself so far...
In order to make my test pattern (marginally) more interesting, I wanted to display something sensitive to the push buttons, but they're not doing what I would expect. In the top level module, I have declared them as input wires. The outputs are registers: 1-bit nsync and 2-bit video_out.
In the clocked portion of my module, I decided to just xor the buttons into the video data, something like this:
always@(posedge clock or negedge resetn) begin if(!resetn) // reset code else begin // Lots of counters to generate video timing and sync values, and 2-bit video signal output, then: nsync <= ~next_sync; video_out <= next_video_data ^ buttons[1:0]; end end
I have also added them to the .ucf file:
NET "buttons"LOC = K3; NET "buttons"LOC = H5; NET "buttons" LOC = L3;
The design report says that is has connected the expected number of input and output pads, which is a good sign. However, the value of buttons[1:0] appears to be 2'b11, and the video comes out uniformly inverted, no matter how hamfistedly I mash the touchpads.
First question: are the touchpad inputs active-high or active-low?
Second question: Am I missing something here? Do I need to declare the buttons in any sensitivity lists so that their state is sampled correctly, or assign them to internal wires?
Solved! Go to Solution.
10-29-2012 09:18 PM
The touchpads are active high. K3 and H5 are the correct pin locations for the first 2 push buttons.
Did you try the default FPGA design for the board? Do the buttons work with it? Have you tried using ChipScope to see if you are getting the correct values on the Input wires?
11-30-2012 05:07 AM
First, apologies for not getting back to you for a month.
Thanks for the tip - I restored the default image and it detects all four push buttons fine, so it's not a hardware fault and I don't need a firmware upgrade.
There must be something wrong, however, as my design connects nreset (active low) to the RESET push button (EF4) so I would expect it to stay in reset indefinitely, and it doesn't. Also in my design, the outputs on LED0..2 are mirrored from EF1..EF3 and they are always 110, so I suspect I'm just hooking them up to the wrong inputs somehow.
I will dig further. Thanks again.
11-30-2012 09:19 AM - edited 11-30-2012 09:43 AM
Some more information. I have created a very simple new test project, which contains this verilog code:
module test( clock, buttons, leds ); input clock; input [3:0] buttons; output [3:0] leds; wire clock; wire buttons; reg leds; always @ (posedge clock) begin: COUNT leds[3:0] <= buttons[3:0]; end endmodule
I would expect this to just mirror the pushbutton inputs to the LEDs. Instead, it appears to sample the pushbutton inputs once, and display those forever. Even odder, pressing the blue "reset" button keeps the pushbutton inputs from last time.
I am beginning to suspect that this is nothing to do with the FPGA, but is the PSOC doing something odd. The values come from the capsense inputs on the PSOC, and they seem to be sampled only when the PSOC is reset.
The previous test with the default bitfile shows that the inputs do work with that file, so it has to be a configuration problem of some sort.
[Edit - I added a little counter to flash LED3, to check that it's being clocked properly, and it is.]
11-30-2012 10:22 AM - edited 11-30-2012 10:27 AM
Even more information: It's definitely the PSOC, with the collusion of the Linux programming utility astriaekipro.
I found a post on the old Google groups that describes something similar, here:
After being programmed by astriaekipro, the PSOC seems to be in a mode where the capsense inputs aren't being read properly. Connecting to it via astriaekipro's terminal mode, even though nothing is being transmitted on the FPGA's UART connection, seems to be enough to get it working. Another way is to cycle the power.
As a workaround, this isn't terribly convenient. But at least it has saved my sanity, and I now know it's not my code that's wrong.
[Edit: ...and it looks like this is fixed in the latest firmware revision, which is something I should have tried first. Hey ho. Thanks for the help.]
12-03-2012 01:16 AM
Yes, that was it. Simply upgrading the firmware from 1.01 to 1.1 did the trick. Of course, now the buttons work, it has revealed a bunch of bugs in my design, but that's another story!