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: 
Highlighted
1,767 Views
Registered: ‎02-09-2010

CPRI clock domain crossing? Failing contraint.

Jump to solution

We are designing a board with a xc7z030ffg676-2 and a CPRI bloc.

I have now an inter-clock failing timing constraint on the 32 bit IQ_Rx data:
- from source clock Ucpri_block/Ucpri_slave/U0/cpri_block_i/gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtxe2_i/TXOUTCLK
- to destination clock IQ_clk.

I have defined my IQ_clk as clk_out from the core.

According to CPRI v8.8 PG056 (October 4, 2017) :
- page 32: clk_out is the "System clock", "Used for all datapath logic in the core and to clock the I/Q,
frame and synchronization, HDLC and vendor-specific interfaces. The
same clock should be used to clock client logic attached to these
interfaces."
-page 35: the clock domain of iq_rx is "System Clock" (which tells essentialy the same)

So why can I get an inter-clock failing contraint?

Thank you

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
2,330 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

thanks tcachat@metraware.com

 

I can see the failure path now. I can confirm the issue isn't related to CPRI. I will try to explain here, but probably it's better to discuss it in the Design Tools -> Timing Analysis board

 

Firstly I highlighted the worst timing path in pink and IQ-clk in green.

 

As you can see the source is from the rising edge of clock net, destination is driven by the clock. I don't think it should be analysed as inter clock domain.

timingfail.JPG

 

I also highlighted the below source clock in yellow.

Ucpri_block/Ucpri_slave/U0/cpri_block_i/gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtxe2_i/TXOUTCLK

 

timing_source.JPG

 

As you can see in the image, the green clock is driven by TXOUTCLK through BUFG, MMCM, so the constraint should be propagated by TXOUTCLK. You shouldn't add clock constraint to IQ_CLK.

 

Please remove constraint [get_ports IQ_CLK_OUT_P], in CPRI_SmartIP_timing.xdc, the problem should be resolved.

16 Replies
Scholar austin
Scholar
1,742 Views
Registered: ‎02-27-2008

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

Do you have a constraint for this path?

 

Vivado requires a constraint for this path.  The timing wizard (analyzer) could help you.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
1,727 Views
Registered: ‎02-09-2010

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

Thank you


For now I have written the following constraints:

create_clock -period 3.255 -name IQ_clk [get_nets IQ_clk]
set_input_delay -clock IQ_clk -min 0.500 [get_ports {IQ_TX_P[*]}]
set_input_delay -clock IQ_clk -max 2.000 [get_ports {IQ_TX_P[*]}]
set_output_delay -clock IQ_clk -min 1.000 [get_ports {IQ_RX_P[*]}]
set_output_delay -clock IQ_clk -max 2.000 [get_ports {IQ_RX_P[*]}]
(Tx and Rx are seen from the CPRI side, so Tx is here an input on the 32 bit data path)

I will check the Constraints Wizard (I did not try it before). It seems I should also write the constraints for the negative side. Surprinsigly I have now a failing constraint on an intra-Clock path on the same clock and data. I have to check.

0 Kudos
1,721 Views
Registered: ‎02-09-2010

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

Sorry, my design is far from being complete, and my constraint are not well written.

 

Apparently with

"create_clock -name IQ_clk -period 3.255 [get_ports IQ_CLK_OUT_P]" I get an inter-clock failing constraint as above, but with

"create_clock -period 3.255 -name IQ_clk [get_nets IQ_clk]" I get an intra-clock failing constraint.

 

I will try to correct the constraints and come back.

0 Kudos
Xilinx Employee
Xilinx Employee
1,706 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

tcachat@metraware.com  How do you drive the clk pin of CPRI? Please take a look at Figure 2-2 of PG056, the CPRI system clock should be driven by TXOUTCLK through a MMCM.

 

In your vivado project, can you highlight CPRI IP, and then right click -> Open IP example design, and then see how it is connected in example design?

0 Kudos
1,695 Views
Registered: ‎02-09-2010

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

Indeed my starting point was the example design(s). To be more precise I have two CPRI cores, one slave and one master, and they share some common resources because there is only one GTX bloc in the xc7z030ffg676-2.

 

I have generated the slave CPRI with "shared logic in the core", and the master CPRI with "shared logic in the example design".

So I have a generated file "cpri_slave_support.vhd" with a component "cpri_slave_clocking". See attached. It seems that the MMCM receives the TXOUTCLK and drives the "core_clk_i" signal, connected to "clk_in" of the "cpri_slave_block".

 

Does it mean that my IQ_clk should be TXOUTCLK?

 

(by the way I already have a post about my design:

https://forums.xilinx.com/t5/Networking-and-Connectivity/Two-CPRI-cores-in-the-same-GTX-xc7z030ffg676-2/td-p/820426)

0 Kudos
Xilinx Employee
Xilinx Employee
1,685 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

iq_data is at system clock domain.  it depends on which device family you are targeting at.

 

In Zynq-7000-based and 7 series-based designs an mixed-mode clock manager (MMCM) is used to generate the system clock. This is routed to the core layer through a BUFG. So the structure is TXOUTCLK -> MMCM-> BUFG -> iq_clk


In UltraScale architecture-based designs the clock divider settings are set by the transceiver rather than by an external MMCM. The transmitter output clock from the transceiver is routed to the core layer through a BUFG_GT.

 

------------------------------------------------------------

Answers your question? Accept as Solution!

Answers helpful?            Give Kudos

------------------------------------------------------------

0 Kudos
1,679 Views
Registered: ‎02-09-2010

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

We are targeting a Zynq-7000: xc7z030ffg676-2.

 

In the code generated by the IP, I could trace down my IQ_clk signal to cpri_slave_tx_clk_gen.vhd (attached), that contains an MMCME2_ADV and a BUFG, as expected. It seems that my IQ_clk is the correct one.

0 Kudos
Xilinx Employee
Xilinx Employee
1,646 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

tcachat@metraware.com

 

I have generated CPRI example design, and notice iq_rx is in RXOUTCLK domain It's a recovered clock, which should be driven to RX reference clock for CPRI slave IP.

 

I couldn't find a clock called IQ_CLK, can you upload dcp file, so I can double check your clock structure?

0 Kudos
1,637 Views
Registered: ‎02-09-2010

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

The name "IQ_clk" is from me: I have defined my IQ_clk as clk_out from the core (see my first post).

I have found several dcp files in the project. Attached are

  1. the one from <project_name>.runs\selectIO_IQoutput_synth_1\
  2. the one from <project_name>.cache\ip\2017.4\...
  3. the one from <project_name>.cache\ip\2017.4\...

 

You mean for the iq_rx data I have to use the RXOUTCLK, which is not what I understood from the documentation (see my first post). It seems I do not have access to RXOUTCLK on the CPRI slave IP, because it is only internal to the IP (because of "shared logic in the core"?).

0 Kudos
Xilinx Employee
Xilinx Employee
1,467 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

tcachat@metraware.com The dcp file from your last thread doesn't look correct, it only contains SelectI/O part, I don't see IQ_Clk in the dcp file. 

 

Can you upload the file from <project_name>.runs\impl_1\<project_name>_routed.dcp?

0 Kudos
1,462 Views
Registered: ‎02-09-2010

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

Dear xud,

I am sorry I missed some of the DCP files of my project. Attached is the dcp file you asked for. (I moved the project in between)

Thank you

0 Kudos
Xilinx Employee
Xilinx Employee
1,450 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

tcachat@metraware.com I have downloaded dcp, and ran timing summary.

 

Followings are the timing errors in inter-Clock Path, I sorted it based on slave values, but I couldn't find the mentioned path. Can you tell me which path is the one you are concerned?timing.JPG

0 Kudos
1,441 Views
Registered: ‎02-09-2010

CPRI clock domain crossing? Failing constraint.

Jump to solution

Dear xud,

I am sorry, my project has changed (mostly the constraints) and the timing errors has changed as well (more or less what I mentioned on 01-22-2018). Attached is the dcp file corresponding to my original post.

Thank you

0 Kudos
Xilinx Employee
Xilinx Employee
2,331 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing contraint.

Jump to solution

thanks tcachat@metraware.com

 

I can see the failure path now. I can confirm the issue isn't related to CPRI. I will try to explain here, but probably it's better to discuss it in the Design Tools -> Timing Analysis board

 

Firstly I highlighted the worst timing path in pink and IQ-clk in green.

 

As you can see the source is from the rising edge of clock net, destination is driven by the clock. I don't think it should be analysed as inter clock domain.

timingfail.JPG

 

I also highlighted the below source clock in yellow.

Ucpri_block/Ucpri_slave/U0/cpri_block_i/gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtxe2_i/TXOUTCLK

 

timing_source.JPG

 

As you can see in the image, the green clock is driven by TXOUTCLK through BUFG, MMCM, so the constraint should be propagated by TXOUTCLK. You shouldn't add clock constraint to IQ_CLK.

 

Please remove constraint [get_ports IQ_CLK_OUT_P], in CPRI_SmartIP_timing.xdc, the problem should be resolved.

1,427 Views
Registered: ‎02-09-2010

Re: CPRI clock domain crossing? Failing constraint.

Jump to solution

Thank you xud,

You are right, when I remove the constraints [get_ports IQ_CLK_OUT_P] and those related to IQ_clk I added, the design pass the timings, but I have several critical warnings "no_input_delay" and "no_output_delay".

I thought it would be useful to define the timing of the 32 bit IQ data with respect to the IQ_clk. As far as I understand, you mean the period of my IQ_clk is already known by the tool and should not be defined again, but using the "Edit Timing Constraints" I do not manage to find the name of this clock (output of the MMCM).

0 Kudos
Xilinx Employee
Xilinx Employee
1,421 Views
Registered: ‎08-02-2007

Re: CPRI clock domain crossing? Failing constraint.

Jump to solution

tcachat@metraware.com

 

Good to hear that removing period constraint solves the problem. If you are concerned about critical warnings "no_input_delay" and "no_output_delay", you can create a new thread in Timing Analysis board, so we can take a look it further.

 

A tip to judge whether to add period constraint or not : After you open Synthesized design, and then report_clock_summary, it has P for some clocks, which mean this clock is propagated by another clock.

 

The P clock doesn't need to have additional period constraint.

0 Kudos