New Contributor
Super ContributorYeah, that clock skew is most likely the problem.
You say the clock source is the downstream device itself receiving the data, not a separate clock source? That is pretty unusual. It means, though, you probably need to include the latency of the clock arriving at the FPGA with a set_clock_latency command and that the clock arriving at that downstream device itself is 0.
It would be helpful to see the waveform view from the timing analyzer to see what the clock edges and arrival and required times look like based on your .sdc. Based on the report you show, the data is getting launched at time 0 and expected to arrive at the downstream device in time to meet setup less than 12.5 ns later. The launch and latch should be delayed because of the time it take for the clock to arrive at REGB. set_clock_latency would do this. But you may even need to use a multicycle exception if the timing analyzer is using the wrong clock edge for the latch. Again, seeing the waveform view would help visualize this much better.
