Clock through fpga or not

Either way is valid. You just have to do a timing analysis.

The advantage of running the clock through the FPGA is that you can control the delay of the clock coming out (assuming your FPGA can do this). Or use a PLL. But routing it through the FPGA will add more delay than a trace.

But you have to do a timing analysis.

ADV7380 output is MIPI CSI-2 (serial high speed interface) and has is its own clock. Does the diagram suggest a separate clock line beside CSI-2 clock? In any case input data have to be synchronized to local clock or FPGA clock would be derived from CSI-2 clock.
Output data should be generated with consistent clock and data from FPGA, I don't see a point of clock feed through.

ADV7380 is some other chip. I use ADV7180 which outputs 8 bit parallel bus and clock


In FPGA I made framebuffer for two lines of video data using internal BSRAM. When one block finished writing first line in BSRAM and starts writing second line, other block in FPGA get's signal of line ready and starts to read for output first line. My aim is to do as small delay as possible, that's why I do not store whole frame, but only few lines.

Right now it all works fine as on first image, if output from framebuffer is sequential for data. Like FIFO - first in, first out (pixel_0, pixel_1, pixel_2...).

But when I start to do some image processing and output data from memory in different order, like (pixel_586, pixel_301, pixel_1, pixel_200...) I get some strange noise on output image.

When I type pixel_586, I mean one sequential group of 4 bytes (Cb586, Y586, Cr586, Y586+1) which make YCrCb 4:2:2 pair

My first thought was maybe it has to do something with design of clock passing through FPGA.

@neanton28
Is the PCB Schematics done and board manufactured?
If not, then ask the board design engineer to connect the clock using PCB trace.
Else route it through the FPGA.

dpaul said:

@neanton28
Is the PCB Schematics done and board manufactured?
If not, then ask the board design engineer to connect the clock using PCB trace.
Else route it through the FPGA.

Click to expand...

No, it's currently in design process, so was wondering what would be the better solution.

neanton28 said:

No, it's currently in design process, so was wondering what would be the better solution.

Click to expand...

The answer is given at post #2 -- yes, that's basically it!

From the flexibility pov or playing around with the delays, I think it is better to route the clock through the FPGA:

The only ways to hold alignment that I know of, are to
co-route through, depend on matching and modeling,
or to phase-lock the "through" output(s) to the routed-
around signal at the final register. I'd always go for simpler
until the skew spec approached DLL/PLL jitter & offset.