Lets say i have one group of logic operating with clock1 clock signal which does something and then writes result to True Dual Port BRAM through port A, which is also clocked from clock1.
Also, there is another logic group which works from clock2 and which reads/writes stuff to same BRAM, but from port B, which is clocked with clock2.
i noticed that sometimes when there are some timing violations within first group of logic which writes stuff to BRAM, the timing analyser for some reason yells that it is a timing violation within group of logic which reads BRAM.
However, i know that it is not the case...and for example when i go ahead and split up logic within first group (which writes to BRAM) and absolutely do not touch anything within second group of logic (which reads from BRAM), then issue is solved.
i.e. i know that problem is with first group of logic, i go ahead fix that problem and it gets OK. But the fact that timing analyser starts complaining about another group does not make any sense! Both sides of BRAM are clocked with clocks which are absolutely unrelated to each other!
of course this fact slows down development significantly...since one needs to take even smaller steps in design, in order not to be misleaded that timing violations occured in another domain in which everything in fact is fine.
Timing analyzer should not 'complain' if the transferring of clock domains is between two unrelated clocks. You may also want to make sure the constaint you made didn't relate each other by specifying the others' time group name. You should be able to find out if the path should have been analyzed in the timing report and verify with planahead on why it's being analyzed. Posting the failing path here may also help us explain why this is happening as well.