Tang Nano 9K issue with FF

[VadimChuskov]

Hi! I'm experiencing some strange behavior with my Tang Nano 9K

Required: press the button to make the LED light up
Fact: the LED lights up only after the second press

After a long search and debugging with a logic analyzer, I got it working. It turned out that to fix it you just need to add a line "assign debugPin1 = s1Out;" Why?

Code: [Select]

module main (
    input bit clk,
    input bit btn1,
    output bit led1,
    output bit debugPin1
);

bit s1Out;// = 1'b0;
debounce key1Debounce(
    .clk,
    .in(btn1),
    .out(s1Out)
);

initial begin
    led1 = 1'b1;
end

//assign debugPin1 = s1Out;  // <-------- Fix

always_ff @(posedge s1Out) begin
    led1 <= 1'b0;
end
    
endmodule

debounce:

Code: [Select]

module debounce #(
    parameter CLK_F = 27000000)
(
    input bit clk,
    input bit in,
    output bit out
);

localparam deadPeriodTicks = int'(CLK_F/100) - 1;

bit debouncedIn, debouncedInShifted;

bit [$clog2((deadPeriodTicks)):0] cnt = 1'b0;

assign out = debouncedIn & ~debouncedInShifted;

always_ff @(posedge clk)
begin
    if (~in && ~&cnt) 
        cnt <= cnt + 1'b1;
    else
        if (in && |cnt) 
            cnt <= cnt - 1'b1;

    if (~|cnt) 
        debouncedIn <= 1'b0;
    else 
        if (&cnt) 
            debouncedIn <= 1'b1;

    debouncedInShifted <= debouncedIn;
end
    
endmodule

cst-file

Code: [Select]

IO_LOC "debugPin1" 70;
IO_PORT "debugPin1" IO_TYPE=LVCMOS33 PULL_MODE=NONE DRIVE=8 BANK_VCCIO=3.3;
IO_LOC "led1" 10;
IO_PORT "led1" PULL_MODE=UP DRIVE=8 BANK_VCCIO=1.8;
IO_LOC "btn1" 4;
IO_PORT "btn1" PULL_MODE=UP HYSTERESIS=NONE BANK_VCCIO=1.8;
IO_LOC "clk" 52;
IO_PORT "clk" IO_TYPE=LVCMOS33 PULL_MODE=UP BANK_VCCIO=3.3;

[rtv]

"assign debugPin1 = s1Out;" -> Fix didn't work with gowin ide V1.9.10.02

Try adding "CLOCK_LOC "s1Out" LOCAL_CLOCK;" to the cst file and it should work.

But my limited experience with gowin ide is that clocks generated by combinatorial logic will fail and should be avoided.

[VadimChuskov]

IDE 1.9.9

Yesterday I accidentally came across a video from a conference where the speaker was talking about the same problem. It turned out that the problem is in 'glitch-free' mode of DCS. Disabling this mode, for example, as below, solves the problem.

Code: [Select]

module main (
    input bit clk,
    input bit btn1,
    output bit led1,
    output bit debugPin1
);

bit s1Out;// = 1'b0;
debounce key1Debounce(
    .clk,
    .in(btn1),
    .out(s1Out)
);

/////////////////////////////////////
//   Fix
/////////////////////////////////////
bit s1OutGlitchless;

Gowin_DCS dcs(
        .clkout(s1OutGlitchless), //output clkout
        .clksel(3'b0001), //input [3:0] clksel
        .clk0(s1Out) //input clk0
    );
/////////////////////////////////////

initial begin
    led1 = 1'b1;
end

always_ff @(posedge s1OutGlitchless) begin
    led1 <= 1'b0;
end

    
endmodule

[Rainwater]

Should this section

Code: [Select]

debounce key1Debounce(
    .clk,
    .in(btn1),
    .out(s1Out)
);

Be defined like so

Code: [Select]

debounce key1Debounce(
    .clk(clk),    //edit here
    .in(btn1),
    .out(s1Out)
);

It looks as tho your debounce module has no driving clock.

[VadimChuskov]

Should this section
Be defined like so

No. Verilog implicitly connects a port to a signal with the same name. If you don't declare the signal, Verilog implicitly creates a wire for you with the same name as the port.

Although, it depends on the version of Verilog. I use System Verilog

[asmi]

It looks as tho your debounce module has no driving clock.

The code is correct if it's interpreted as SystemVerilog. SV allows to omit adding wire name if it's name is the same as a port name. This is super useful in testbenches where it typically is the case.