0

I have been working on a program for class which acts as a stopwatch, but I've been having troubles where it doesn't work. (Only one digit, the first that would be shown on the four digit display is ever used, and it is always at 0.) After putting the whole program through a simulation, and seeing it work correctly there, I can only come to the conclusion that the clock is never changing.

As I see it, these are the relevant parts of my code, but feel free to ask for more.

From the top module:

module stopwatch(
    [...]
    input clk,
    [...]
    );

From the User Constraint File:

 ## Clock signal
 NET "clk"   LOC = "E3" | IOSTANDARD = "LVCMOS33";                  #Bank = 35, Pin name = IO_L12P_T1_MRCC_35,                  Sch name = CLK100MHZ
 #NET "clk" TNM_NET = sys_clk_pin;
 #TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 100 MHz HIGH 50%; 

I have four synthesis warnings.

 WARNING:HDLCompiler:413 - "C:\<REDACTED>\counter2bit.v" Line 31: Result of 3-bit expression is truncated to fit in 2-bit target.
 WARNING:HDLCompiler:462 - "C:\<REDACTED>\clock_divider_true.v" Line 42: if-condition does not match any sensitivity list edge
 WARNING:HDLCompiler:413 - "C:\<REDACTED>\count_10.v" Line 37: Result of 5-bit expression is truncated to fit in 4-bit target.
 WARNING:Xst:2677 - Node <decimal_counter/count3/En_next> of sequential type is unconnected in block <stopwatch>.

In counter2bit.v, the truncation is intentional, so long as it's shaving off the MSB; I don't want the third bit anyway. The if condition doesn't match any sensitivity list edge by design; I don't want it updating when that variable does. The truncated 5-bit expression should never happen because it resets when it updates and the value is 4'd9. count3 is the last block in the counter, and I am not planning on using the En_next to enable another counter.

Smurfton
  • 103
  • 5
  • To be clear, [...] denotes parts that were cut for space. – Smurfton May 03 '15 at 22:21
  • It may sound stupid, but do you have a LVCMOS33 compatible oscillator connected to the pin? – Nils Pipenbrinck May 03 '15 at 22:25
  • @NilsPipenbrinck I don't actually know what that means. I'm using a Nexys4, made by Digilent, and the provided generic user constraint file for the Nexys4, if that helps. Any way for me to find out? – Smurfton May 03 '15 at 22:27
  • just checked your board. Yes you have a oscillator at pin E3.. – Nils Pipenbrinck May 03 '15 at 22:32
  • "The if condition doesn't match any sensitivity list edge by design; I don't want it updating when that variable does". This is probably your problem right there: your statement makes no sense when trying to write hardware. – Alain Jun 19 '15 at 21:09

1 Answers1

2

What you should do is make a bit of really simple test code to blink an LED at around 1 Hz. If that works, then the clock is working. This code can be incredibly simple:

module test(input wire clk, output led)

reg [31:0] cnt = 50000000;
reg led = 0;

always @(posedge clk) begin
    if (cnt > 0) begin
        cnt <= cnt - 1;
    end else begin
        cnt <= 50000000;
        led <= ~led;
    end
end

endmodule

If you can get that to blink and LED, then there must be some other issue with your code.

Also, you should really make sure to specify the clock frequency in the UCF file to make sure that the tools will optimize your design correctly for the required clock frequency.

alex.forencich
  • 40,694
  • 1
  • 68
  • 109
  • Ah, yes, that does work. Any idea where to point me, since I know for a fact that it works in simulation? – Smurfton May 04 '15 at 02:39
  • 2
    Did you check for any odd synthesis warnings? – alex.forencich May 04 '15 at 02:53
  • I put all of the warnings in the question just now. I don't think there's anything weird there. – Smurfton May 04 '15 at 19:21
  • 1
    Well, I see two warnings there that are suspicious. You should never have any sensitivity list warnings. It is possible that whatever triggered this warning is causing a discrepancy between simulation and synthesis. Also, any warnings about things that are not connected deserve a second look. It is possible that some important piece of logic was optimized out. This is could well be a result of whatever the synthesizer did when it produced the first warning. – alex.forencich May 05 '15 at 01:50