cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jt94093
Adventurer
Adventurer
12,306 Views
Registered: ‎07-26-2013

timing violation at BUFGCTRL in Kintex7 PCIe core example design

Jump to solution

Hello,

 

I am running Vivado 2014.1 to implement this PCIe core and its associated example design in a Kintex7:

 

7 Series Integrated Block for PCI Express

3.0 (Rev. 1)

 

I am getting a small setup time violation at the input of a BUFGCTRL in the pipe clock module of the example design (see attached text file). The S1 input of the BUFGCTRL is driven by a flop that is clocked by the rising edge of the BUFGCTRL output and the I1 clock input of the BUFGCTRL is driven by a 250MHz clock from an MMCM (see attached schematic pdf). The timing analysis indicates that the setup requirement for S1 is relative to the falling edge of clock input I1, although I have not been able to find any corroboration of this in the datasheet or BUFGCTRL documentation. The MMCM output that drives the other clock input is 125MHz, and the same timing analysis is performed with respect to the S0 input using that frequency (which meets timing due to being much slower).

 

My question is what to make of this violation and what to do to resolve it.

 

 

I looked through the IP files and did not find any constraints that appear to be relevant to this path.

 

I thought this might warrant a false path or clock group constraint, but the MMCM outputs and BUFGCTRL output are closely related. I would expect the timing relationships among these signals to be deterministic which leads me to believe that I should be able to satisfy the timing for this path (though a half-cycle @250MHz is asking a lot).

 

The BUFGCTRL documentation states that timing violations at the S0/S1 inputs will not glitch the output but might delay it by once cycle. Perhaps this is not an issue for the PCIe application and I can ignore it with a false path instead of trying to optimize the place/route.

 

Thanks,

Jason

 

 

 

0 Kudos
1 Solution

Accepted Solutions
graces
Moderator
Moderator
20,239 Views
Registered: ‎07-16-2008

Hi Jason,

 

Yes, from the clocking user guide,

"A violation in the Setup/Hold time of the CE pins causes a glitch at the clock output. On the other hand, using the S pins allows the user to switch between the two clock inputs without regard to Setup/Hold times. As a result, using S to switch clocks will not result in a glitch."

 

There does exist a setup/hold spec on S pin. Please refer to Kintex-7 Data Sheet, Table 33.

From Note 1,

"The other global clock setup and hold times are optional; only needing to be satisfied if device operation requires simulation matches on a cycle-for-cycle basis when switching between clocks."

 

So I think the path can be set as false path.

 

-----------------------------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs.
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

5 Replies
graces
Moderator
Moderator
20,240 Views
Registered: ‎07-16-2008

Hi Jason,

 

Yes, from the clocking user guide,

"A violation in the Setup/Hold time of the CE pins causes a glitch at the clock output. On the other hand, using the S pins allows the user to switch between the two clock inputs without regard to Setup/Hold times. As a result, using S to switch clocks will not result in a glitch."

 

There does exist a setup/hold spec on S pin. Please refer to Kintex-7 Data Sheet, Table 33.

From Note 1,

"The other global clock setup and hold times are optional; only needing to be satisfied if device operation requires simulation matches on a cycle-for-cycle basis when switching between clocks."

 

So I think the path can be set as false path.

 

-----------------------------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs.
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

jt94093
Adventurer
Adventurer
12,266 Views
Registered: ‎07-26-2013

Ok will do. Thank you for the quick response.

0 Kudos
pfile
Visitor
Visitor
12,053 Views
Registered: ‎05-23-2014

i see this violation as well... does it mean that there was an .xdc created during core generation that needs to be applied to the target design (after fixing up hierarchies...)?

 

thanks,

 

rob

 

0 Kudos
viviany
Xilinx Employee
Xilinx Employee
12,043 Views
Registered: ‎05-14-2008

@pfile wrote:

i see this violation as well... does it mean that there was an .xdc created during core generation that needs to be applied to the target design (after fixing up hierarchies...)?

 

thanks,

 

rob

 


No, there is nothing to do with the IP XDC. You just need to add a set_false_path constraint in your user XDC for the path from the register/C to BUFGCTRL/S1 or S0

 

-Vivian

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

OK, thanks. i have put the set_false_path constraint in the XDC and all seems fine. both S1 and S0 seem to be hooked up so i have included both endpoints.

 

rob

 

0 Kudos