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
Observer cogansco
Observer
425 Views
Registered: ‎07-28-2015

pass data between two clocks, before & after BUFGMUX

Jump to solution

Hello, I have some data which is being latched by GTX received clock, at 80.5 MHz.  It is from fiber optic. If the signal is not available, I want to switch to using my own internal generated clock (from 125MHz) and generate alternative data.  I am using a BUFGMUX for this, and it is usually working as expected.

 

The BUFGMUX is muxing GTS805_CLK or INT805_CLK to EVR_CLK (output clock). 

 

wire GTS805_CLK; // Recovered RxClock from GTS fiber, 80.5 MHz
wire INT805_CLK; // Internal generated clock, 80.5 MHz
wire EVR_CLK; // BUFGMUX output clock (choice between GTS and internal clock)
// Clock multiplexer
BUFGMUX clockmux_inst (.I0(GTS805_CLK),.I1(INT805_CLK),.S(GTS_IS_PRESENT),.O(EVR_CLK));

For normal operation, data from the GTX fiber is initially generated and latched using GTS805_CLK, and I use the data also using the EVR_CLK.  It seems this sometimes gives me problems, where data is not passed successfully from GTS805_CLK domain to EVR_CLK domain.

 

I see two possible solutions:

1) Proper timing constraints to pass data between GTS805_CLK and EVR_CLK

or

2) Pass data through dual-clock FIFO to pass safely between GTS805_CLK and EVR_CLK

 

I'd prefer a timing constraint in .ucf file.  Currently, this is the only relevant timing constraint I have:

NET "EVR_CLK" TNM_NET = "TNM_CLK80M";
TIMESPEC "TS_CLK80M" = PERIOD "TNM_CLK80M" 80.5 MHz HIGH 50%;
NET "GTS805_CLK" TNM_NET = "GTS805_CLK";
0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
332 Views
Registered: ‎05-14-2008

Re: pass data between two clocks, before & after BUFGMUX

Jump to solution

I agree with avrum that you should have BUFG/BUFGMUX in parallel to overcome the hold issue. Anyway, you have GTS805_CLK clock driving sequential elements and you'll have a BUFG for this clock. You should have the this BUFG and the BUFGMUX in parallel rather than in series.

BUFG_parallel.png

Your revised constraints look good. The FROM-TO constraint will cover all paths from GTS805_CLK to EVR_CLK.

 

Another method is to define the EVR_CLK as a derived clock to GTS805_CLK. In this way, you do not need to add the FROM-TO constraint. The paths from GTS805_CLK to EVR_CLK will be automatically analyzed under the EVR_CLK period constraint because the two clocks are "related".

NET "GTS805_CLK" TNM_NET = "GTS805_CLK";
TIMESPEC "TS_GTS805" = PERIOD "GTS805_CLK" 80.5 MHz HIGH 50%;
NET "EVR_CLK" TNM_NET = "TNM_CLK80M";
TIMESPEC "TS_CLK80M" = PERIOD "TNM_CLK80M" TS_GTS805 HIGH 50%;

 

-vivian

 

6 Replies
Explorer
Explorer
390 Views
Registered: ‎07-17-2014

回复: pass data between two clocks, before & after BUFGMUX

Jump to solution

@cogansco

First of all, I think the second option is better, that is, the way of using buffer.
Secondly, when generating GTX-IP, you can choose elastic buffer and the source of RXOUTCLK.
Then you don't need to deal with the clock domain anymore.

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

Re: pass data between two clocks, before & after BUFGMUX

Jump to solution

The following concerns I see:

1. When you pass data from GTS805_CLK to EVR_CLK, does the EVR_CLK come from GTS805_CLK or INT805_CLK?

If EVR_CLK has two frequency possibilities, you should constrain it using the worst case, which is the higher frequency 125MHz.

 

2. You didn't add period constraint for GTS805_CLK?

NET "EVR_CLK" TNM_NET = "TNM_CLK80M";
TIMESPEC "TS_CLK80M" = PERIOD "TNM_CLK80M" 80.5 MHz HIGH 50%;
NET "GTS805_CLK" TNM_NET = "GTS805_CLK";

 

3. By default ISE treats two clocks as asynchronous. So by default, if you have two period constraints and you didn't specify them as related clock, ISE won't analyze any paths between them. You need to add a from-to constraint for the two clock domains.

 

-vivian

0 Kudos
Observer cogansco
Observer
367 Views
Registered: ‎07-28-2015

Re: pass data between two clocks, before & after BUFGMUX

Jump to solution

Thank you vivian.  It looks like I forgot the period constraint for GTS805_CLK.  I'll add it.

I only pass data from GTS805_CLK to EVR_CLK when the BUFGMUX is selecting GTS805_CLK as it's source.  So EVR_CLK is just a buffered copy of GTS805_CLK.

Does this FROM/TO constraint look sufficient to you?  This will capture all FF's clocked by one clock to the other?

 

NET "EVR_CLK" TNM_NET = "TNM_CLK80M";
TIMESPEC "TS_CLK80M" = PERIOD "TNM_CLK80M" 80.5 MHz HIGH 50%;
NET "GTS805_CLK" TNM_NET = "GTS805_CLK";
TIMESPEC "TS_GTS805" = PERIOD "GTS805_CLK" 80.5 MHz HIGH 50%;
TIMESPEC TS_CROSSEVRCLK = FROM "GTS805_CLK" TO "TNM_CLK80M" 12 ns;     # 1/80.5MHz = 12.4 ns

 

 

0 Kudos
Historian
Historian
355 Views
Registered: ‎01-23-2009

Re: pass data between two clocks, before & after BUFGMUX

Jump to solution

I am not entirely following what you are doing - a diagram would help.

 

Generally you do not try and have datapaths that go between "before clock buffer" and "after clock buffer" flip-flops. The clock buffer has a VERY large insertion delay (upwards of 2-3ns), and hence will always cause significant hold time problems.

 

The key in any system like this is to balance your clock buffers.

 

For example - what is generating the GTS805_CLK? - it is from the GTX, but if you are using it for logic, presumably it is already going through a clock buffer (a BUFG?). If so the paths you are looking at have one point going through one BUFG and the other going through two (a BUFG and a BUFGMUX). The solution is to put the BUFGMUX in parallel with the existing BUFG - the CLKRXOUT of the GTX drives the I input of the BUFG as well as the .I0 input of the BUFGMUX. Done this way, all points only go through one clock buffer, and the hold time problems go away.

 

Next, you should not need to define a "new" clock on the output of the BUFGMUX. It has been a long time since I dealt with the complexities of BUFGMUX and ISE's timing engine - it was pretty poor at it. But - certainly you should not be defining a "new" 80MHz clock on the output of the BUFGMUX - particularly one that is not "related" to the main 80MHz clock; the tools will not do any timing analysis between these two clocks... (at least I don't think so). If this is the case, you masked the serious hold problems that your previous architecture had (which could be why the design didn't work).

 

As for the 125MHz branch - architecturally you should have the same structure - a parallel BUFG and BUFGMUX so that you don't have hold time violations.

 

I don't remember the specifics (it has been a long time since I worked with ISE), but ISE was notoriously poor at dealing with stuff like this. You are talking about a GTX - GTX's didn't exist in Spartan-6, so is this a 7 series FPGA? If so (and this is a hard pill to swallow), I would very highly recommend you switch to Vivado. You are in territory that ISE was notoriously bad at - Vivado handles this stuff completely and correctly. You will be able to get far better answers to your questions if you are using Vivado. I know it is very hard to switch tools, but it is definitely worth it... (Of course if this is a Virtex-6, which also has GTX, then this is not an option).

 

Avrum

Observer cogansco
Observer
347 Views
Registered: ‎07-28-2015

Re: pass data between two clocks, before & after BUFGMUX

Jump to solution

avrum, thanks for your thoughts.  To understand my application better, I have data & clock generated by external fiber, and I have internal clock & data generated using on-board 125MHz crystal clock.  Normally, the fiber clock & data will drive subsequent processing, however if the fiber is not plugged in, I want to use internal clock & data to drive the subsequent processing. Thus the clock MUX. Once I have a clock mux, I must pass the fiber data from the fiber clock to the post-MUX clock.  I see the insertion delay in the MUX, but I think the tools are able to handle it properly using FROM/TO spec.

 

I would love to use the new Vivado tools.  When they support Virtex-6 and Spartan-6, let me know!  I am managing 4 projects using these FPGAs on various hardware boards, and this hardware is not going away for at least 10+ years.

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

Re: pass data between two clocks, before & after BUFGMUX

Jump to solution

I agree with avrum that you should have BUFG/BUFGMUX in parallel to overcome the hold issue. Anyway, you have GTS805_CLK clock driving sequential elements and you'll have a BUFG for this clock. You should have the this BUFG and the BUFGMUX in parallel rather than in series.

BUFG_parallel.png

Your revised constraints look good. The FROM-TO constraint will cover all paths from GTS805_CLK to EVR_CLK.

 

Another method is to define the EVR_CLK as a derived clock to GTS805_CLK. In this way, you do not need to add the FROM-TO constraint. The paths from GTS805_CLK to EVR_CLK will be automatically analyzed under the EVR_CLK period constraint because the two clocks are "related".

NET "GTS805_CLK" TNM_NET = "GTS805_CLK";
TIMESPEC "TS_GTS805" = PERIOD "GTS805_CLK" 80.5 MHz HIGH 50%;
NET "EVR_CLK" TNM_NET = "TNM_CLK80M";
TIMESPEC "TS_CLK80M" = PERIOD "TNM_CLK80M" TS_GTS805 HIGH 50%;

 

-vivian