[Elphel-support] 10359 data packing and clock tree

[Oleg K Dzhimiev]

Dear Gladys,

> As introduced in the website, The board 10359 could simultaneously acquire
> images from up to 3 sensors, compress them and send out one after another,
> in alternation mode it could combine frames from 2 sensors into one
> resulting frame vertically. I have several questions here.

10359 doesn't do any compression - it's done in the main 10353 board.

> 1 I want to know if we don't use SDRAM to store frame but directly use the
> real time data, should we use asynchonous FIFO to get a 1 line delay for
> sensor1 then pack it after each line of sensor 2 during the horizontal
> blanking time?

1. I'm not sure the current horizontal blanking time will be enough to fit
another line (currently it is like ~500 to ~1000 clocks - need to check
that). The blanking can be increased as it's a sensor setting but the 353
can handle 75Mpix/s - this should be taken into account. So, you would like
to combine frames horizontally?

> 2 how does the clock tree function, since there are different pixel clock
> from each sensor,  if we send out the pixel data one after another(either
> line by line or frame by frame), how to choose the output pixel clock? How
> to generate the FIFO clock in this case?

2. Clock tree:
The picture on the wiki is a little outdated but the logic is close:

   - 3 sensors are fed with one clk source "sensor_clk"
   - 3 DCMs are used to generate 3 different clocks for latching data from
   sensors - resync to the system clock is done in the "sensor_phase353"
   module.
   - Sensors output pixclks are not used. Only VACT,HACT & DATA.

You can use system clock "sclk0" and the output of resync module.

> 3 When I use asynchonous FIFO to scale the lines, there is clock
> latency(about 4 to 5 pixel clock), so the output data are not correct, do
I
> need to use shift register to delay the pixel data, is there any other
> solution?

3. Not clear. The only important delay is the one between HACT(horizontal
active) & DATA - there should be no delay actually - you only need to take
care about is how to latch them synchronously.
And if you use the same FIFO for HACT & DATA you can rely on HACT being
active (high) or generate your own correct HACT signal when you expect data
to be valid.

There's one more signal - VACT - vertical active. It is better to sync it
with other signals (HACT & DATA) but since there's a delay between VACT
rising and the first HACT - it can be done with less care.

Best regards,
Oleg

On 17 August 2010 11:48, Gladys <yuhui.b at gmail.com> wrote:
> Dear Oleg/Andrey,
>
> As introduced in the website, The board 10359 could simultaneously acquire
> images from up to 3 sensors, compress them and send out one after another,
> in alternation mode it could combine frames from 2 sensors into one
> resulting frame vertically. I have several questions here.
>
> 1 I want to know if we don't use SDRAM to store frame but directly use the
> real time data, should we use asynchonous FIFO to get a 1 line delay for
> sensor1 then pack it after each line of sensor 2 during the horizontal
> blanking time?
>
> 2 how does the clock tree function, since there are different pixel clock
> from each sensor,  if we send out the pixel data one after another(either
> line by line or frame by frame), how to choose the output pixel clock? How
> to generate the FIFO clock in this case?
>
> 3 When I use asynchonous FIFO to scale the lines, there is clock
> latency(about 4 to 5 pixel clock), so the output data are not correct, do
I
> need to use shift register to delay the pixel data, is there any other
> solution?
>
> Thank you for answers!
>
> Kind Regards.
>
>
> Gladys
>
>
>
> _______________________________________________
> Support-list mailing list
> Support-list at support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100817/2106c137/attachment-0002.html>