Binary Counter v12.0 reset (SCLR) not working

[rnp]

Hello everybody,

I am having a problem with the  binary counter v12.0 reset SCLR signal, when implementing the Xilinx University Programme, Lab9 Project 3.1, 2015x (1).

Environment:

• OS: Linux (Arch Linux)
• Xilinx Vivado 2018.3
• Digilent Basys3 develoment board
• Verilog HDL

Problem description:

The project works as expected (counts up to 5 minutes, 0,1 second resolution), the exception is the counter reset  button (BTNC, U18) is pressed it only stops the counting, when released, the counter is not reset, instead it keeps counting where it stopped.

I am using the Vivado IP Catalog for generating the clock signal and the 4 binary counters(2) used on each 7-Segiment display digit. The Verilog code and constraint file are attached.

The binary counter configuration:

• Implementing using: Fabric
• Output width: 4 [3:0]
• Increment Value (Hex): 1
• Restrict Count (Hex): 4, 5, 9, 9 (7seg from  left ro right)
• Count Mode: UP
• Clock Enable (CE): Checked
• Synchronous Clear(SCLR): Checked
• Init Value:(Hex): 0
• Synchronous Controls and Clock Enable(CE) Priority: Sync Overrides CE
• Latency Configuration: Manual, 1
• Feedback Latency Configuration: Manual, 0

 

I suspect I am overseeing/forgetting somewhere a simple detail. Any help/clarification is appreciated.

 

Cheers,

Rafael.

(1) https://www.xilinx.com/support/documentation/university/Vivado-Teaching/HDL-Design/2015x/Verilog/docs-pdf/lab9.pdf

(2) https://www.xilinx.com/support/documentation/ip_documentation/counter_binary/v12_0/pg121-c-counter-binary.pdf

lab9_3_1.v Basys-3-Master.xdc

[jpeyron]

Hi @rnp,

Welcome to the Digilent Forums!

Looking at your lab9_3_1.v code I believe you need to add 

if (reset)
            counter <= 0;

to this always block

always @(posedge clk_out1)
       begin
        if (counter2 < `ssd_refresh)
            counter2 <= counter2 + 1;
        else begin
            counter2 <= 0;
            tmp_clk2 = ~tmp_clk2;
        end
    end

best regards,

Jon

 

[rnp]

Hello @jpeyron,

Thanks for your quick reply. Unfortunately your suggestion did not have the expected result. It resets the clock for the 7seg displays, the binary counters are not reset.

After reading the documentation of the binary counter (from the IP Catalog, see reference 2 from my first post), I understood that when when SCLR (reset signal) is asserted for more than on clock period, all the counters would be reset.

4 binary counters outputs (Q[3:0]) would be set to zero, which is not the case. For the same binary counters, the CE signal works as expected, it interrupts the counting process.
Well, in theory it is simple, but in practice it appears I forgot something or I am doing something wrong.


Cheers,

Rafael.

[rnp]

Hi @jpeyron,

I was able to find the root cause. By using the following code for both clocks (10Hz and 500Hz)

       if (reset)
               counter2 <= 0;
        else begin
            if (enable) begin
                if (counter2 < `ssd_refresh)
                    counter2 <= counter2 + 1;
                else begin
                    counter2 <= 0;
                    tmp_clk2 = ~tmp_clk2;
                end
            end
        end

when the reset button is pressed (BTNC), there is no clock ticking, therefore the SCLR (reset) in the binary counters is not triggered. When the reset button is released, the binary counters continue where they stopped, as if the reset never happened.

By removing the first if,  as shown below, the reset works:

        if (enable) begin
            if (counter2 < `ssd_refresh)
                counter2 <= counter2 + 1;
            else begin
                counter2 <= 0;
                tmp_clk2 = ~tmp_clk2;
            end
        end

I was able to catch it, after simulating the binary counter and observe that the SCLR works as expected.

 

I hope this issue described here may useful saving someone else's time.

 

Cheers,

Rafael.

[jpeyron]

Hi @rnp,

Glad to hear you were able to get the reset working. Thank you for sharing what your did to find the issue and the changes that you made to your HDL.

best regards,

Jon