Help with signal generation using spartan 3E board

[sanyi1987]

Hi, I'd like to create a circuit that can ouput a pulse signal of determined high level period.
I created the following code and synthesized it, but after programming my spartan 3E board with it, I got no sognal at the desired output.
Can anyone tell me what I'm missing?...thanks.

module test_sig_gen(sigout, clk, enable, reset);

input enable, reset, clk;
output sigout;


reg [31:0] out;
parameter n = 500000;
reg cmp;
reg [31:0] y;


initial begin
cmp = 0;
y = 32'b0;
out = 32'b0;
end


always @ (posedge clk)
if (reset) begin
out <= 32'b0;
end
else if (enable) begin
out <= out + 1;
end


always @ (posedge clk)
if (out == n) begin
y <= y+1;
end
else if (out != n) begin
y <= y;
end


always @ (posedge clk)
if (y == 0) begin
cmp <= 1;
end
else if (y != 0) begin
cmp <= 0;
end


assign sigout = cmp;


endmodule


After assigning the "enable" input to a switch, the "reset" input to a pushbutton, the "clk" input to the clk input described in the spartan 3e IO sheet and the "sigout" output to some random ouput port, and programming the FPGA with the code, I checked the output with an oscilloscope for the desired signal...nothing appeared. Please share your thoughts. Thank you.

P.S. Verilog is new teritory for me and I don't have a lot of esperience with it, so please give specific advice

 

[jrwebsterco]

You could be having more practical issues, and not so much Verilog coding errors - a few quick observations ...
-> You don't mention if you observed cmp being stuck at 0 or at 1
-> You don't describe how you are testing the device, such as if the clock is running during and after configuration, or what the clk freq is, and whether you made sure the synthesis tool was aware of the clk period for timing-closure (e.g. setup/hold) concerns.
(e.g. a 32-bit wide adder could have a slow carry-propagation path if it was synthesized to a ripple architecture)
If clk is too fast, you might not be meeting timing or maybe you missed triggering on cmp since it was so quick; if too slow then maybe you did not wait long enough to see the expected activity.
-> Mechanical switches are notorious for generating nasty glitches (aka "mechanical bounce") before finally settling out.
Glitches on enable or reset-release could be messing up the out register again due to timing violations (glitches are not synchronous to clk).
Thus, it is possible that out gets corrupted to be larger than 500000, and now you have to wait up to 8x the expected delay before it will rollover back to 500000 again.
-> Double-check that you are using requisite internal pull-down options in your UCF on switch I/Os if they require it.
-> Try reducing the width of out & y (why so much wider than needed?), and maybe bring some of these other signals/bits out of the device so you can observe them for debug.
(e.g. bring out the MSb of out to sanity-check that it is toggling at a divided-by-power-of-2 clk freq)