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: 
Observer hotak
Observer
244 Views
Registered: ‎06-13-2018

why is negative the clock path skew ?

Can you explain why the clock path skew is negative?

I want to know it.

I want not to have negative slack and  to know the reason of the negative clock path skew.

Can I change the negative clock path skew to positive clock path skew?

If you want to have my design source, I will attach it.

Thanks.  

 

partial source code as follows.

moduel top;
 
~~~~~~~~~~~~~~~ 
 
always @(posedge clk)
 begin
 if(en)
  begin
 ~~~~~~~~~~~~~~~~
    en15  <= (cout0 & cout1 & cout2 & cout4 & cout5) & (cout6 & cout7 & cout8 & cout9 & cout10) & (cout11 & cout12 & cout13 & cout14);
   end
 end
 
~~~~~~~~~~~~~~~~~~~
  BCD U15
      (         .clk(clk),
.rst(rst),
.en(en15),
.cin(cout14),
                .cout(cout),
.bcd(bcd15)
  );
 
~~~~~~~~~~~~~~~~~~~
endmodule
 
module BCD
 
 (
   input clk,rst,en,cin,
   output cout,
   output [3:0] bcd
 );
 
 
reg cin_d;
 
wire [2:0] n;
wire clrn;
 
and G1 (n[0],en,bcd[0]);
and G2 (n[1],n[0],bcd[1]);
and G3 (n[2],n[1],bcd[2]);
wire co;
 
reg bcd_c;
 
always @(posedge clk)
 bcd_c <= bcd[3]&~bcd[2]&~bcd[1]&~bcd[0];
 
 
assign clrn = ~(rst | (cin_d&co));
assign co =  en & bcd_c;
assign cout = bcd_c;
 
always @(posedge clk)
  cin_d <= cin;
 
jkff_s U1 (.j(en)  ,.k(en),.clk(clk),.clrn(clrn),.prn(1'b1),.q(bcd[0]));
jkff_s U2 (.j(n[0]),.k(n[0]),.clk(clk),.clrn(clrn),.prn(1'b1),.q(bcd[1]));
jkff_s U3 (.j(n[1]),.k(n[1]),.clk(clk),.clrn(clrn),.prn(1'b1),.q(bcd[2]));
jkff_s U4 (.j(n[2]),.k(n[2]),.clk(clk),.clrn(clrn),.prn(1'b1),.q(bcd[3]));
 
endmodule

 

schematic.JPG
Timing Report.JPG
0 Kudos
3 Replies
Xilinx Employee
Xilinx Employee
165 Views
Registered: ‎05-14-2008

Re: why is negative the clock path skew ?

The clock skew is Destination (DCD) - Source (SCD).

If the SCD is larger than DCD, you get a negative clock skew. It is not absolute value.

There are formula details in your screenshot for the clock skew calculation.

You can refer to UG949 about the timing violation root causes and correspoinding solutions.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Xilinx Employee
Xilinx Employee
161 Views
Registered: ‎05-22-2018

Re: why is negative the clock path skew ?

Hi @hotak ,

Also check the below AR# for how clock skew affects the setup/hold calculation:

https://www.xilinx.com/support/answers/17224.html

Thanks,

Raj

0 Kudos
Guide avrumw
Guide
71 Views
Registered: ‎01-23-2009

Re: why is negative the clock path skew ?

More specifically, this is an output path of the FPGA.

The source clock starts at a "clock" object outside the FPGA (defined with a create_clock), comes in through an IBUF, and some other clocking (we can't tell what since you didn't post the complete schematic or report), but either a regional clock buffer like a BUFIO/BUFR, or a global clock buffer (BUFG) with or without an MMCM between the IBUF and the BUFG. The clock then fans out on a dedicated clock network before ultimately reaching the startpoint of the static timing path - the FDRE that drives the startpoint. This is the source clock delay (SCD).

The endpoint is an output port. The only timing associated with it is the set_output_delay on the output port (which appears to be 0) and is relative to the same clock defined on the input port (the same create_clock -name clk). Thus the clock "clk" goes "directly" to the endpoint, which is the set_output_delay command - thus it has no destination clock delay (DCD). Since the clock skew is DCD-SCD, and the DCD is 0, the clock skew is negative. This is true for all paths that leave the FPGA.

Ultimately, though, what this is telling you is that you cannot synchronously get through the FPGA in 5ns (i.e at 200MHz). What you are effectively asking for is for a 5ns maximum delay from the time the clock arrives at the clock pin of the FPGA until the output appears on the output pin of the FPGA. This is too fast - this must go through (I will assume BUFG clocking)

  • An IBUFG
  • A dedicated connection to the BUFG
  • The BUFG
  • The global clock network
    • this is quite long - depending on device and speed grade this can be 3ns
  • The FDRE's clock to output
  • The OBUF
    • This can be even longer - depending on the IO_STANDARD, DRIVE and SLEW_RATE of the output buffer, this can even by more than 8ns. Even with the fastest combinations its still upwards of 3ns

So you add all this together and it clearly cannot be done in 5ns, which is what you are asking for with your (presumably) create_clock -period 5 and set_output_delay 0.

Avrum

0 Kudos