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 thomas1974
Observer
17,332 Views
Registered: ‎05-16-2012

specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

Im having problems when specifying the timing constraints for the following clock mux design:

 

 

example_design.gif
0 Kudos
1 Solution

Accepted Solutions
Observer thomas1974
Observer
25,920 Views
Registered: ‎05-16-2012

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

Just to complete this thread, I found the solution in setting the right ignores. As said there is no practical crossing problem, because the two paths are not to be switched during normal operation, but set BEFORE data has to be sent over the path. The contraints should just make sure, that the synthesis does not try to arrange that somehow and rans into false solutions or takes too mucht time.

 

Anyway I took some information from the last answer regarding a possible issue with the inpus data streams beeing clocked directly into FFs. Well I did not observe any misbehaviour with that design and nothing was reported either to me but will investigate this possibly.

 

 

0 Kudos
9 Replies
Observer thomas1974
Observer
17,331 Views
Registered: ‎05-16-2012

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

The task is to switch the both data streams coming form two sources, decide which to use and forward it to the output.

 

(the receiver can detect the speed and knows what to do with the data)

 

Switching is functionally no problem: the can be some seconds of data loss - no worry about that.

 

But:

 

I have to sepcify the correct input data relations (flaling edge / rising edge) and do not know which clock to refer to! :-(

 

Also I cannot specify the  ou put constraint: Since I do not know, which clock will finally be active - the clock signal I named for this is not recorgnized by the tool when mapping (?)

 

The 3. Thing: which signals should be takten to specify the TIG?  How should the TIG contraint look like to show the tool, not to worry about clock crossing.

 

 

0 Kudos
Observer thomas1974
Observer
17,330 Views
Registered: ‎05-16-2012

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

Some more information:

 

Data source 1 is 166MHz and securely edge aligend, meaing, the clock is 100% directly before the data change.

 

Data source 2 is 152,5MHz and center aligned, having some 300 ns jitter. I assume I have to use a stricter IO input offset contraint, shrinking the data valid period?

 

Data Port 3 for the processor is totally asnych and sampled. Works fine with 97/48 MHz. (cant use more than 100).

 

I think I have to use TIGs for all the clocks?

 

How do I have to specify the TIG for the signal coming out of the swtich?

 

The switch inlcudes a BUFGMUX and generates a new clock (violett) from either the orange or the blue path.

 

Finally: How do I have to set the offset out con for this clock?  internally it runs edge aligned of course with it's data, then the data is synched out to the FF bank and then the clock is going thorugh an inverting ODDR to get the falling edge aligned to the data. 

 

Any Ideas about this?

 

Thanks in advance

 

 

0 Kudos
Historian
Historian
17,316 Views
Registered: ‎01-23-2009

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

First. I presume this diagram is more "illustrative" than actually literal. For example, you don't show any clock buffers... What clock buffers are you using for driving the IO FF and for the LOGIC? If you don't have any, then you need to put them in. You don't tell us what technology you are using, so its hard to make recommendations, but if it is Virtex then you probably want to use BUFIO and BUFR.

 

Next you need to constrain the capture of the input interfaces with respect to these clocks. If you are using BUFIO/BUFR and the IO FFs are actually IOB FFs then this should be relatively easy.

 

Now the problems...

 

You say you are muxing the two clocks together using a BUFGMUX. Thats fine, but now you have a fundamental problem - the phase of the clock coming from the BUFR (which would be driving the LOGIC on each domain) and the clock coming from the BUFG are not related. You cannot synchronously cross between these two clock domains. While it may work "most of the time" there will be certain combinations of process, temperature and voltage where this will fail.

 

So the problem is not that you need to TIG the domains (which will actually just mask the problem) - you need to architect a solution that solves it. You almost certainly need a clock crossing FIFOs to move the data from the BUFR domains to the BUFGMUX domain.

 

This will also get very complicated around the switchover - the FIFO that is in the datapath that is not selected will have different rates on its input and output and hence will over/underflow. When you switch over, you will need to find a way to clear the FIFO and bring it up gracefully.

 

Similarly, since your switchover logic is running on yet another domain - you will need to syncronize all signals coming from that domain to the other 3 domains - possibly including the selector of the BUFGMUX (although some technologies have the BUFGMUX_VIRTEX4, which can take an async selector).

 

When you do have the FIFOs and all other synchronizers in place, then you can TIG the different clock domains - and, yes, with the FIFO and synchronizers in place the clock domains are all asynchronous.

 

As for the constraint on the output, the tool doesn't really care about the BUFGMUX. You can constrain the output from either of the two input clock pins (presumably the faster one). You may need to TIG the path from the other clock (or you may not - I don't remember how ISE deals with this).

 

Avrum

0 Kudos
Observer thomas1974
Observer
17,311 Views
Registered: ‎05-16-2012

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

Hello I am using Virtex right, but is this important for the TIG contraint or the overall input output offset constraints??

 

Regarding the buffers: Yes I am using two BUFG for the real clocks - mentioned in the design as the triangle - see above. All clocks come through a CC pin.

 

Crossing is no problem, since some data loss can occur - this is ob. when the clock switches then the operation mode is fundamentaly different - the receiver will synch to the data himself. No problem.

 

My only problem is, how to make sure that the data is adjusted well for both of the two cases with one design, even if only one of the two cases takes place. (switching is done maybe every hald an our no also not at all)

 

Synchronizing of the switcher signal is done - allthough it is again not a problem if it works false for some clocks. When ever switching takes place, i will have several frames lost - no prob about that

 

 

 

0 Kudos
Historian
Historian
17,306 Views
Registered: ‎01-23-2009

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

You missed several points in my last post.

 

1) What clock buffer are you using for the IOB FFs and the LOGIC. The "triangle" is labeled as an IBUFG which is an input buffer, not a clock buffer. If you are really clocking logic (and IOB FFs) with the output of an IBUFG this is treated as a local clock and will have terrible performance for capturing the input data

 

2) Clock crossing does not mean switching - it means transferring data from one clock domain to another. You have many different clock domains here. In this case, I am talking about the clock domain that clocks the block maked "LOGIC 166" and the clock domain that is the output of the BUFGMUX. When the BUFGMUX selects the 166MHz clock, these clocks are "mesochronous", but they are not "synchronous" - you cannot send data from one to the other without some sort of clock crossing circuit.

 

You need to address these issues before you even think about constraints and TIGs.

 

Avrum

Observer thomas1974
Observer
17,222 Views
Registered: ‎05-16-2012

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

Ok, then I am using a BUFG after the Input buffer to get the data into the FFs.

 

Because of the clock crossing:

 

I am not sure were the problem might be: It need just a switch between these two paths, there is no need to maintain data during switching, so if the are some hundert clocks wrong, no matter.

 

I just need a switch.

 

Can this be done this way?

 

Can there by some issues when the clocks fail?

 

For example I also detect, if the is no clock available from source one and then change to source two.

 

 

0 Kudos
Historian
Historian
17,208 Views
Registered: ‎01-23-2009

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

You say (but seem unsure) that you are using a BUFG for the clock driving the IO FFs. I still don't know what device you are targetting, but if its a Virtex-6 (in -1) then clocking IOB FFs with an IBUFG/BUFG combination has a documented setup and hold requirement (See DS152, Tpsfd/Tpfd) of about 2-2.5ns. Running this at 166MHz is going to be quite difficult unless the data coming in has very tight tolerances in your 6ns period.

 

As for the clock crossing - I can't really be much clearer. The orange clock and the purple clock in your diagram are NOT in phase - there is a large process/voltage/temperature (PVT) dependent phase variation between them - the delay through the BUFGMUX and the global clock distribution. In general, you cannot simply have a path that starts on the orange clock and ends on the purple clock - this is a clock crossing path. Even when the MUX is selecting the I0 input, these two clocks are at the same frequency, but the phase relationship between them is unknown.

 

While it may work under certain conditions, it is difficult (if not impossible) to guarantee that it is going to work across PVT.

 

It is possible to do what you want, but not the way you are doing it.

 

You need to design all aspects of this system

 

1) Design a proper capture mechanism for your incoming data - a BUFG clocking an IOB FF is not likely to work reliably.  You will likely either need

  a) A BUFG with MMCM/DCM deskew or

  b) A BUGIO/BUFR (ChipSync) clocking mechanism

2) Design a proper clock cossing mechanism to cross data from the two unmultiplexed domains to the multiplexed domain

  - this will likely need clock crossing FIFOs and a mechanism to clear them on switchover

 

Avrum

0 Kudos
Observer thomas1974
Observer
25,921 Views
Registered: ‎05-16-2012

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution

Just to complete this thread, I found the solution in setting the right ignores. As said there is no practical crossing problem, because the two paths are not to be switched during normal operation, but set BEFORE data has to be sent over the path. The contraints should just make sure, that the synthesis does not try to arrange that somehow and rans into false solutions or takes too mucht time.

 

Anyway I took some information from the last answer regarding a possible issue with the inpus data streams beeing clocked directly into FFs. Well I did not observe any misbehaviour with that design and nothing was reported either to me but will investigate this possibly.

 

 

0 Kudos
Voyager
Voyager
9,131 Views
Registered: ‎05-31-2012

Re: specifying timing io constraints for clock mux design with differing speeds and data constellations

Jump to solution
HI, I have to do the same thing, I didn't realize that I need a Fifo for every clock domain. I thought that Bufgmux introduce a delay that the tool can calculate and to not worry about Cdc on same clock. I really have to use fifos?
0 Kudos