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 jon.w
Observer
395 Views
Registered: ‎12-13-2018

Spartan 6, constraining a BUFGMUX output

Jump to solution

Hello,

I'm working on a Spartan 6 project using ISE 14.7.

 

In my project, I will be recovering a source synchronous clock.  The FPGA will generate a 1x and 2x clock from this recovered clock.  Depending on the frequency of this clock I select either the 1x or 2x clock through a BUFGMUX to be used for clocking the output data and for forwarding to the next device.  The output of the BUFGMUX is intended to be as fast as the fastest 1x clock (i.e., I'll only be selecting the 2x clock if the input frequency is 1/2 maximum design frequency).

 

The part I'm having trouble with is constraining the output of the BUFGMUX.   I specify the input clock frequency over the entire expected range.  The tools derive constraints for everything else and the 2x clock derived constraints fail to meet timing.  Is there anyway to write a constraint to say that I only expect the output of the BUFGMUX to be a certain frequency (equivalent to the input clock range)?  I've tried constraining the inputs to the BUFGMUX with priorities, I've tried some FROM-TO constraints, but I can't seem to get it dialed in.

 

Any help would be greatly appreciated.

Thanks,

Jon

0 Kudos
1 Solution

Accepted Solutions
Observer jon.w
Observer
270 Views
Registered: ‎12-13-2018

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

I ended up resolving this issue through slightly adjusting my DCM inputs.  Rather than using the BUFGMUX and passing the 2x clock to the input of the DCM, I do the BUFGMUXing on the output side after the 2x clock is generated.

Since I was getting component switching limit errors rather than timing errors, it seemed I couldn't write constraints that made the tools happy (other than lying about the maximum input frequency).  For example, a FROM TO didn't work I suspect because I was still theoretically switching faster than the DCM input would allow.

I didn't really try out Vivian's advice; while I trust that would work, a lot of different constraints are derived from the input deserialization and clock recovery and I wasn't confident in my abilities to define them individually.

For now, everything seems to be ok.  Thank you very much for your help!!

Jon

View solution in original post

10 Replies
Observer jon.w
Observer
374 Views
Registered: ‎12-13-2018

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

A bit more info:

The failure I'm getting is a "component switching limit" issue as I'm routing the output of the BUFGMUX to a DCM.  My maximum input clock is 150MHz and the theoretical maximum 2x clock is 300MHz, although I will not be selecting the 2x clock when the frequency is that high.  The DCM doesn't like a 300MHz input frequency (max is 280MHz per datasheet).

The input clocks to the BUFGMUX are called pclk_unbuf and pclk_x2 for the 1x and 2x clocks respectively.  The output of the BUFGMUX is poclk_int.  The timing specs for pclk_unbuf and pclk_x2 are derived from input clock characteristics (I'm using the xapp1064 deserialization using PLL).  The static timing analysis seems to always "lookahead" for pclk_x2 and say the DCM limits are exceeded even though the BUFGMUX is in the path.

I tried constraining the output of the BUFGMUX to 150MHz...that worked as far as generating a constraint for poclk_int, but I still get a component switching limit error for pclk_x2.

I then tried adding a constraint to say that pclk_x2 is 150MHz...that generated a constraint for pclk_x2 but then a new clock constraint, pclk_x2_0 was derived from the input clock (source synchronous interface) and showed a component switching limit error.

The only thing that I've been able to do is say the input clock is 75MHz, but that's not really accurate as I could receive 150MHz and will be using the 1x pclk_unbuf in that case.  Also all the front-end deserialization logic will be using a 1x clock up to 150MHz.

Any thoughts or ideas are greatly appreciated.

Thanks!

Jon

0 Kudos
Scholar drjohnsmith
Scholar
368 Views
Registered: ‎07-09-2009

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution
do you want to post your constraints please
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Observer jon.w
Observer
362 Views
Registered: ‎12-13-2018

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

Here's what I have currently:

######################
# Timing Constraints #
######################
# system clock
NET "CLK" TNM_NET = SYSCLK;
TIMESPEC TS_SYSCLK = PERIOD "SYSCLK" 48 MHZ HIGH 50%;

#Created by Constraints Editor (xc6slx9-csg324-3n) - 2019/05/20
NET "inst_ch_des_clk/inst_clk_rec/feedback" TNM_NET = inst_ch_des_clk/inst_clk_rec/feedback;
TIMESPEC TS_inst_ch_des_clk_inst_clk_rec_feedback = PERIOD "inst_ch_des_clk/inst_clk_rec/feedback" 1050 MHZ HIGH 50%;
NET "inst_ch_des_clk/inst_clk_rec/P_clk" TNM_NET = inst_ch_des_clk/inst_clk_rec/P_clk;
TIMESPEC TS_inst_ch_des_clk_inst_clk_rec_P_clk = PERIOD "inst_ch_des_clk/inst_clk_rec/P_clk" 150 MHZ HIGH 50%;

# Try specifying pclk_x2 as only 150MHz (pclk_x2_0 was then derived by the tools)
#NET "pclk_x2" TNM = pclk_x2;
#TIMESPEC TS_pclk_x2 = PERIOD "pclk_x2" 150 MHZ;

# Try to define BUFGMUX output as 150MHz (still got error for pclk_x2)
#NET "inst_data_out/poclk_int" TNM_NET = poclk_int;
#TIMESPEC TS_poclk_int = PERIOD "poclk_int" 150 MHZ;

Thanks,

Jon

0 Kudos
Scholar drjohnsmith
Scholar
355 Views
Registered: ‎07-09-2009

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution
do you want to double check this bit
sorry , not going to be around for a few days, may be some one else can pick up

# system clock
NET "CLK" TNM_NET = SYSCLK;
TIMESPEC TS_SYSCLK = PERIOD "SYSCLK" 48 MHZ HIGH 50%;

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Observer jon.w
Observer
347 Views
Registered: ‎12-13-2018

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

Sorry, that is a different clock which I use for other logic, unrelated to the constraint issue.

0 Kudos
Xilinx Employee
Xilinx Employee
330 Views
Registered: ‎05-14-2008

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

Is the input clock "inst_ch_des_clk/inst_clk_rec/P_clk" only driving the DCM and no other loads?

If this is the case, you can use the following method:

1. Remove the period constraint for "inst_ch_des_clk/inst_clk_rec/P_clk". This can prevent the tool from automatically deriving the constraints to the DCM outputs.

2. Add period constraints for the DCM output manually instead of auto-deriving. If I understand you correctly, the 1x and 2x output clock are both 150MHz.

NET "pclk_x1" TNM_NET = pclk_x1;
TIMESPEC TS_pclk_x1 = PERIOD "pclk_x1" 150 MHZ;
NET "pclk_x2" TNM_NET = pclk_x2;
TIMESPEC TS_pclk_x2 = PERIOD "pclk_x2" 150 MHZ;

 In this way, only 150MHz period constraint can be propagated through the BUFGMUX and you won't have the component switching limit timing error.

Hope this helps.

Vivian

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

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

P_clk (or more precisely other clocks derived from P_clk), does drive other loads.  I not quite sure if I can remove that constraint and then constrain each derived clock individually as I'm relying on some phase relationships throughout the design.  I'll give it a try when I get a chance.

Thanks for the responses!

Jon

0 Kudos
Xilinx Employee
Xilinx Employee
290 Views
Registered: ‎05-14-2008

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

You can copy and revise the auto-derived period constraints for the DCM output clocks, instead of manually calculate the phase relationship.

The auto-derived period constraints can be found in the timing report.

Say if the auto-derived constraints are like this:

NET "inst_ch_des_clk/inst_clk_rec/P_clk" TNM_NET = inst_ch_des_clk/inst_clk_rec/P_clk;
TIMESPEC TS_inst_ch_des_clk_inst_clk_rec_P_clk = PERIOD "inst_ch_des_clk/inst_clk_rec/P_clk" 150 MHZ HIGH 50%;
NET "dcm_clkout1" TNM_NET = dcm_clkout1;
TIMESPEC TS_dcm_clkout1 = PERIOD "dcm_clkout1" TS_inst_ch_des_clk_inst_clk_rec_P_clk PHASE + 1.67 ns;
NET "dcm_clkout2" TNM_NET = dcm_clkout2;
TIMESPEC TS_dcm_clkout2 = PERIOD "dcm_clkout2" TS_inst_ch_des_clk_inst_clk_rec_P_clk PHASE + 3.33 ns;

Then you can re-write the constraints for the DCM output clocks like this:

 NET "dcm_clkout1" TNM_NET = dcm_clkout1;

TIMESPEC TS_dcm_clkout1 = PERIOD "dcm_clkout1" 150MHz;
NET "dcm_clkout2" TNM_NET = dcm_clkout2;
TIMESPEC TS_dcm_clkout2 = PERIOD "dcm_clkout2" TS_dcm_clkout1 PHASE + 1.67 ns;

-vivian

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

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

I ended up resolving this issue through slightly adjusting my DCM inputs.  Rather than using the BUFGMUX and passing the 2x clock to the input of the DCM, I do the BUFGMUXing on the output side after the 2x clock is generated.

Since I was getting component switching limit errors rather than timing errors, it seemed I couldn't write constraints that made the tools happy (other than lying about the maximum input frequency).  For example, a FROM TO didn't work I suspect because I was still theoretically switching faster than the DCM input would allow.

I didn't really try out Vivian's advice; while I trust that would work, a lot of different constraints are derived from the input deserialization and clock recovery and I wasn't confident in my abilities to define them individually.

For now, everything seems to be ok.  Thank you very much for your help!!

Jon

View solution in original post

Xilinx Employee
Xilinx Employee
226 Views
Registered: ‎05-14-2008

Re: Spartan 6, constraining a BUFGMUX output

Jump to solution

Please accept your own answer as solution to close this thread.

-vivian

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