--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
As far as I know, the only thing that prevents you of using the CSI-2
protocol is the clocking frequency of the serial lane.
CSI-2 has quite a lot of generic features that are defined. All of
them need not be supported. If your clocking is within 300MHz, I think
a Xilinx FPGA can easily de-serialize this stream. Each lane in the
CSI-2 specification serializes a byte and transmits to the receiver.
So the first thing which one would require is a clock recovery on the
clock lane which can be implemented using a DDR flop(IDELAY) can be
used to centre the clocking to the data and a de-serializer working at
line rate.
Post serialization, that has to be a packet processing/parsing state
machine which runs on a byte wise basis which shall run at a frequency
equal to ([line rate / 8]*Lane Width). Hence the internal processing
logic always runs at much slower speed as compared to CSI-2 serial
lines.
Then there are packet formats that are to be supported. Some of them
have the SOF. EOF, SOL, EOL packet headers aligned to generate precise
HS and VS timing signals. Some of the CSI-2 specs do not. If the
timing signals are not defined by these SOF EOF SOL EOL fields, then a
frame buffer might be required to video rendering.
In a simplest set-up these signals can be directly used as HS and VS
signals for display driving!.
CSI-2 also specifies virtual channels to interleave video data, which
when used again requires frame buffering since it spoils HS VS timing
in the incoming data stream.
Additionally, the CSI-2 interface also consists of a CCI (Camera
Configuration Interface) which is used to configure the camera
parameters. This interface is just a simple I2C bus interface which
are used to program configuration registers of the camera. The
register bit map can be easily found from the camera datasheet.
On the whole, I do not think it is a difficult task to implement the
receiver in the FPGA if you have a relatively good FPGA(as far as
timing and logic is concerned).
Thanks
Shyam
>On Mar 31, 10:12=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>> I've run into a bit of a problem. A camera module I would like to use
>> has a MIPI CSI-2 interface. The SoC I want to connect to only has a
>> parallel camera interface. How difficult would it be to use an FPGA in
>> between? Or are there already MIPI to parallel converters?
>>
>> --
>
>As far as I know, the only thing that prevents you of using the CSI-2
>protocol is the clocking frequency of the serial lane.
>
>CSI-2 has quite a lot of generic features that are defined. All of
>them need not be supported. If your clocking is within 300MHz, I think
>a Xilinx FPGA can easily de-serialize this stream. Each lane in the
>CSI-2 specification serializes a byte and transmits to the receiver.
>So the first thing which one would require is a clock recovery on the
>clock lane which can be implemented using a DDR flop(IDELAY) can be
>used to centre the clocking to the data and a de-serializer working at
>line rate.
I guess using the DPLL and use the clock delay line is also an option.
I'm surprised Xilinx has no appnote on MIPI.
>Post serialization, that has to be a packet processing/parsing state
>machine which runs on a byte wise basis which shall run at a frequency
>equal to ([line rate / 8]*Lane Width). Hence the internal processing
>logic always runs at much slower speed as compared to CSI-2 serial
>lines.
>On the whole, I do not think it is a difficult task to implement the
>receiver in the FPGA if you have a relatively good FPGA(as far as
>timing and logic is concerned).
If only I had access to the MIPI specs before paying the fee... I'd
hate to findout I wasted thousands of dollars for nothing.
Basically it is a paid specification, so Xilinx would not disclose
things on its app notes. Xilinx has IDELAY primitives which are very
effective in centering data and controlling calculated skew/ delay on
data/clocking lines. (it has both fine grain and coarse grain
adjustments I suppose) at around 7.5 may be. Not really sure. (256
taps on a 200MHz clock)
> >Post serialization, that has to be a packet processing/parsing state
> >machine which runs on a byte wise basis which shall run at a frequency
> >equal to ([line rate / 8]*Lane Width). Hence the internal processing
> >logic always runs at much slower speed as compared to CSI-2 serial
> >lines.
> >On the whole, I do not think it is a difficult task to implement the
> >receiver in the FPGA if you have a relatively good FPGA(as far as
> >timing and logic is concerned).
>
> If only I had access to the MIPI specs before paying the fee... I'd
> hate to findout I wasted thousands of dollars for nothing.
>
If you have the camera receiver, I do not think you ll require MIPI
specification. You just have to build the receiver according to the
datasheet information from the MIPI trasmitter :) I have the
specification but I cannot share it with you
> --
> Failure does not prove something is impossible, failure simplymanaging
>On Apr 3, 10:09=A0am, n...@puntnl.niks (Nico Coesel) wrote:
>> shyam <mail.ghanashyam.pra...@gmail.com> wrote:
>> >On Mar 31, 10:12=3DA0pm, n...@puntnl.niks (Nico Coesel) wrote:
>> >> I've run into a bit of a problem. A camera module I would like to use
>> >> has a MIPI CSI-2 interface. The SoC I want to connect to only has a
>> >> parallel camera interface. How difficult would it be to use an FPGA in
>> >> between? Or are there already MIPI to parallel converters?
>>
>> >> --
>>
>> >As far as I know, the only thing that prevents you of using the CSI-2
>> >protocol is the clocking frequency of the serial lane.
>>
>> >CSI-2 has quite a lot of generic features that are defined. All of
>> >them need not be supported. If your clocking is within 300MHz, I think
>> >a Xilinx FPGA can easily de-serialize this stream. Each lane in the
>> >CSI-2 specification serializes a byte and transmits to the receiver.
>> >So the first thing which one would require is a clock recovery on the
>> >clock lane which can be implemented using a DDR flop(IDELAY) can be
>> >used to centre the clocking to the data and a de-serializer working at
>> >line rate.
>>
>> I guess using the DPLL and use the clock delay line is also an option.
>> I'm surprised Xilinx has no appnote on MIPI.
>>
>
>Basically it is a paid specification, so Xilinx would not disclose
>things on its app notes. Xilinx has IDELAY primitives which are very
>effective in centering data and controlling calculated skew/ delay on
>data/clocking lines. (it has both fine grain and coarse grain
>adjustments I suppose) at around 7.5 may be. Not really sure. (256
>taps on a 200MHz clock)
IIRC thats Virtex or Spartan 6.
>> >Post serialization, that has to be a packet processing/parsing state
>> >machine which runs on a byte wise basis which shall run at a frequency
>> >equal to ([line rate / 8]*Lane Width). Hence the internal processing
>> >logic always runs at much slower speed as compared to CSI-2 serial
>> >lines.
>> >On the whole, I do not think it is a difficult task to implement the
>> >receiver in the FPGA if you have a relatively good FPGA(as far as
>> >timing and logic is concerned).
>>
>> If only I had access to the MIPI specs before paying the fee... I'd
>> hate to findout I wasted thousands of dollars for nothing.
>>
>If you have the camera receiver, I do not think you ll require MIPI
>specification. You just have to build the receiver according to the
>datasheet information from the MIPI trasmitter :) I have the
Any pointers to such datasheets? I have the datasheet for the camera
module but its author had a really lazy day.
>specification but I cannot share it with you
I know, but maybe you know an unofficial source. Many specifications
have leaked onto the internet.
--
Failure does not prove something is impossible, failure simply
Google search should give you some datasheets!
> >specification but I cannot share it with you
>
> I know, but maybe you know an unofficial source. Many specifications
> have leaked onto the internet.
>
I am not sure about unofficial sources.