12-14-2015 07:44 PM - edited 12-14-2015 07:47 PM
I am using video in to AXI4 Stream (v4.0) in independent clocking mode and it seems that axis_enable is being used by both clock domains (vid_io_in_clk & aclk) which is causing timing violations regardless to which clock it's synchronized. This seems like a bad design. Any idea how to get around this cleanly?
12-15-2015 08:42 PM
12-16-2015 11:48 AM - edited 12-16-2015 11:53 AM
could you please add your experience (new version of the IP indeed seems to use the signal in both domains) to the SR I opened (10340355) on this issue? The datasheet claims that this signal is synchronous to vid_io_in_clk and that's what the person who's handling the case is repeating without looking at the code as you did.
Actually when it's fixed I think the axis_enable signal should be synchronous to axi_clk (ie output clock) which is what the name suggests.
In the mean time, I changed my code to use the vid_io_in_ce signal which works with a signal synchronous to vid_io_in_clk. I don't see any reason to change this and it's another reason that axis_enable to be synchronous to output clock. I don't see the need to have two enable signals on the same clock domain.
12-16-2015 01:40 PM
I might have spoken too soon. I'm looking into it in more detail.
The axis_enable should be synchronous to the input clock domain (despite the nomenclature...). The intent is that it should be driven from the VTC detector's 'locked' bit. This VTC detector instance would be synchronous to the input video's clock domain.
The axis_enable signal is essentially a gate to help prevent partial frames come coming through before the VTC locks. Thus, it makes sense that it is in the vid_io_in_clk domain. This is functionally different from the other clock enables for each domain.
Do you get timing errors when it's synchronous to the input clock?
12-16-2015 01:43 PM
12-16-2015 03:10 PM