Timing closure on assynchronous clock domains

hello,

Vivado cannot close timing between two clocks, "vid_io_in_clk" and "vid_io_out_clk". Both IP cores have been configured for assynchronous buffering. I was expecting that the IP core are including constraints to declare the clocks between the data path as mutually exclusive (which is what I want them to be).



Vivado tries to meet timing with all clocks, which is default behaviour. Now I have 2 options:

(A) declare "vid_io_in_clk" as assynchronous to "aclk" and "aclk" to "vid_io_out_clk"
(B) declare "vid_io_in_clk" and "vid_io_out_clk" as assynchronous, which is what Vivado is complaining about

(A) seems more correct to me than (B). I think with (A) Vivado should no longer see a clock relation for (B). But CDC's for (A) are black boxes, so what about control signals like handshaking and watermarks, these are not assynchronous and I cannot constrain them.

P.S. sorry for the image I don't know why it's so tiny

- - - Updated - - -

theUltimateSource said:

CDC's for (A) are black boxes, so what about control signals like handshaking and watermarks, these are not assynchronous and I cannot constrain them.

Click to expand...

Ok, I see now that (A) has multicycle constraints. I think I can treat (B) as completely assynchronous then, as long as (A) meets timing. Is this correct?

In my experience vivado needs every permutation of clock relationship individually marked as ignore. It's not going to infer anything there.

The two clocks coming from the clock wizzard could be syncronous depending on their rates. Are you sure they're not?

I know I try to keep timing as simple as possible. In this case I would right click on the timing violation in question and follow the path to the menu item that lets you ignore all paths between the source and destination clock as it seems that's what you want.

asdf44 said:

In my experience vivado needs every permutation of clock relationship individually marked as ignore. It's not going to infer anything there.

Click to expand...

Yes, this is the default behaviour of Vivado. I expected this been taken care of by the IP already, which it did as per multicycle.

asdf44 said:

The two clocks coming from the clock wizzard could be syncronous depending on their rates. Are you sure they're not?

Click to expand...

The output clocks from the wizzard are beeing seen as synchronous by Vivado. This is not what I want them to be in this case.

asdf44 said:

I know I try to keep timing as simple as possible. In this case I would right click on the timing violation in question and follow the path to the menu item that lets you ignore all paths between the source and destination clock as it seems that's what you want.

Click to expand...

Yes, this is what I want to do, but is it correct? Inproper handling of CDC leads to low MTBF.

Not quite sure what the problem is? just make all the clocks asynchronous to each other. The video and control signals will all be passed through a FIFO and be safe, and related to each other. You dont need to time the control signals as they are treated as data in the fifo.

@TrickyDicky,

Why do I have to set (B) asynchronous? If I declare (A) as asynchronous there should not be any clock relation for (B) at all.

By default, Vivado will assume all clocks are related, and without a timing spec will try and time the CDC using a 1ns period, which will be pretty impossible.
ALL outputs from PLLs need to be set as asynchronous to avoid this implied relationships.

You can always check what constraints are recommended by Vivado for your design by lunching Constraints Wizard after Synthesis (Open Synthesized Design).