UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor gpetrowitsch
Visitor
770 Views
Registered: ‎04-09-2018

Extremely odd behavior of the simulator

Jump to solution

Hi,

 

I'm facing an extremely odd behavior of the Vivado simulator in behavioral simulation.

I'm having a clocked process but outputs of this process change, even if there are no edges on the clock.

 

In essence the code looks like this (simplified):

 

 

    always_ff @(posedge sync_clk or negedge rst_n)
    begin
        if (~rst_n) begin
            c_cnt <= 0;
            c_sync_detected <= 0;
        end else begin
		if (start == 1) begin
                    // start pattern found
		    c_cnt <= 2;
		    c_sync_detected <= 1;
		end
		if (done == 1) begin
                    // detection done
		    c_sync_detected <= 0;
		end
            if (c_sync_detected == 1) begin
                // manage the token bit counter
                if (c_cnt == TOKEN_LENGTH-1)
                    c_cnt <= 0; // reinitialize token bit counter
                else
                    c_cnt <= c_cnt + 1;
            end
        end
    end

 But the waveforms of the related signals look like this:

 

strange-sim-beh.png

 

The signals c_cnt and c_sync_detected should change at the yellow arrows only (if they change), as there's the rising edge of the sync_clk, but they should never change at the red arrows. Apart from this, the counter c_cnt should either be initialized with the value 2 or 0 or it should count up in increments of 1, but not in increments of 2, as we see at the yellow arrows.

 

I see similarly odd problems at other points in my design, like a state machine changing state although none of the conditions would allow it. This design simulated OK some weeks ago, but now I see these very odd things, after some changes.

 

I know similar problems from Cadence ncsim, which usually could be solved by deleting the compile snapshot and re-compiling everything. I already deleted my sim and cache subdirectories, but the problems remain.

 

Any idea, what I can do?

 

I'm using Vivado 2017.4

 

Thanks and regards,

Gerhard

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor gpetrowitsch
Visitor
904 Views
Registered: ‎04-09-2018

Re: Extremely odd behavior of the simulator

Jump to solution

I finally found out, what's going wrong:

 

The sync_clk is generated through a somewhat complicated circuitry, which obviously generates zero-delay glitches on it.

When I route the sync_clk over a

 

    assign #1ns clean_sync_clk = sync_clk;

 

and only use this clean_sync_clk instead of the sync_clk, the odd behavior is gone.

 

At the moment I don't understand, how the zero-delay glitches are generated. The sync_clk is created essentially by 2 signals, let's call them sig_1 and sig_2. Now sig_1 is created out of an always_ff process that triggers on the negative edge of the source clock, while sig_2 is created out of an always_ff process, that triggers on the positive edge of the same source clock.

Finally sync_clk is generated by an assign statement:

 

assign sync_clk = (sig_1 == 1) ? (sig_2 == 0) ? 1 : 0 : 0;

 

After this statement, the sync_clk contains the zero-delay glitches, which are not displayed in the simulator waveform tool.

View solution in original post

3 Replies
Scholar dpaul24
Scholar
757 Views
Registered: ‎08-07-2014

Re: Extremely odd behavior of the simulator

Jump to solution

@gpetrowitsch,

 

Yes as per the code, changes should occur at the rising edge.

But the 1st thing that strikes me is the non-50% duty-cycle clock.

What is the pulse width of sync_clk?

 

There is an old thread discussing that short pulse widths might case a problem.

https://forums.xilinx.com/t5/Timing-Analysis/Is-the-duty-cycle-of-a-clock-important-enough/td-p/204043

 

But I don't know how relevant is this for seris7 FPGAs.

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Visitor gpetrowitsch
Visitor
742 Views
Registered: ‎04-09-2018

Re: Extremely odd behavior of the simulator

Jump to solution

@dpaul24

 

Thanks for looking into this. The width of the high pulse is 14ns at a period of 325ns, but as this is a behavioral simulation, pulse widths shouldn't matter (unless shorter than the timing resolution). My timescale directive says "1ns / 1ps", so this must work.

 

Anyway, neither should the signals toggle where there's no edge nor should the counter be incremented in steps of 2.

 

0 Kudos
Highlighted
Visitor gpetrowitsch
Visitor
905 Views
Registered: ‎04-09-2018

Re: Extremely odd behavior of the simulator

Jump to solution

I finally found out, what's going wrong:

 

The sync_clk is generated through a somewhat complicated circuitry, which obviously generates zero-delay glitches on it.

When I route the sync_clk over a

 

    assign #1ns clean_sync_clk = sync_clk;

 

and only use this clean_sync_clk instead of the sync_clk, the odd behavior is gone.

 

At the moment I don't understand, how the zero-delay glitches are generated. The sync_clk is created essentially by 2 signals, let's call them sig_1 and sig_2. Now sig_1 is created out of an always_ff process that triggers on the negative edge of the source clock, while sig_2 is created out of an always_ff process, that triggers on the positive edge of the same source clock.

Finally sync_clk is generated by an assign statement:

 

assign sync_clk = (sig_1 == 1) ? (sig_2 == 0) ? 1 : 0 : 0;

 

After this statement, the sync_clk contains the zero-delay glitches, which are not displayed in the simulator waveform tool.

View solution in original post