MachXO3: MIPI CSI2 pair input connected to MIPI CSI2 pair output

[gregoireg]

I have a MachXO3LF-6900C starter kit and I want to "connect" an input MIPI CSI2 differential HS pair to an output MIPI CSI2 differential HS pair. I don't care about LP as it's a free-running clock signal.

I have the input pair connected on bank 2, PB35A / ball R11 (+) and PB35B / ball T12 (-). I have a 100 ohm resistor between the two input pins. VCCIO2 = 2.5V.

I have the output pair connected on bank 0, PT27A / ball D10 (+) and PT27B / ball E10 (-). I have a voltage resistor divider 70/300 ohm on each output pin. VCCIO0 = 2.5V.

I can modify, compile and flash the Lattice blink demo project. I have tried to edit manually the file Blink1.lpf but it's not working well. I have also tried to play with the "Spreadsheet View", but I can't figure out how to add the pins.

Any pointer, help, guidance? Many thanks in advance.

[gregoireg]

For reference, "assign" seems to be the instruction I need.

[gregoireg]

The question is still open and is now discussed here with more details: http://electronics.stackexchange.com/questions/233046/lattice-machxo3l-mipi-csi2-bridge If somebody has any idea, feel free to comment on StackExchange.

[bktemp]

If you had included all those details in the original question somebody here would have answerd it already:
You circuit does not work, because you need to initialize the highspeed mode first, before using it.
Have a look at Mike's Ipod Nano V6 display reverse engineering:
http://electricstuff.co.uk/nanohack.html
You need the resistors for low-power mode to be able to switch into highspeed mode correctly.

[gregoireg]

Thanks for answering and helping.

I'm very aware of Mike's Nano 6 reverse engineering. I'm also very aware of DSI which is much more complex than CSI2. CSI2, unlike DSI, doesn't have the LP communication for all the settings/setup. Have you read the MIPI CSI2 specifications? Most cameras (at least Omnivision, Aptina, Sony which should represent 99.99% of the market) are getting their settings through I2C. In my particular case, I'm using an Omnivision camera. So, I'm not sure to fully understand your point but perhaps I'm missing something important. Yes, the camera is correctly initialized and it's sending HS data.

[bktemp]

I have not read the CSI specs in full detail, because I've only used MIPI for driving displays, but it looks like CSI is based on the same packet format:
If you look at the MIPI signal generated by the camera, there should be periods whith 1.2V on the data lines and periods with 300mV.
You can't generate the 1.2V levels and therefore you can't do the LP-11 -> LP-01 -> LP-00 -> HS transition necessary for entry into highspeed mode.

From the CSI-2 specs:
"The minimum physical layer requirement for a CSI-2 transmitter is
Data Lane Module: Unidirectional master, HS-TX, LP-TX and a CIL-MFEN function"

If you look at the "Low Level Protocol" section, the data lane switches into low power state between each highspeed packet.

[gregoireg]

I do see the LP transitions on the output because I simply assign output=input. As I mentioned on the StackExchange page, I'm trying to do an "analog" bridge, analog being perhaps not the right term, but this is more by opposition to "digital" == deserialization / reserialization. Perhaps, I should not not use LVDS25 or MIPI type of input / output.

My objective in the end is to replicate the logic behind Fairchild FSA642 (https://www.fairchildsemi.com/datasheets/FS/FSA642.pdf) and add more logic. I have deeply tested this chip and I'm 100% sure that they don't deserialize/reserialize data because I have swapped clock and data, and it's still working.

I have added an edit to the question on StackExchange.

[gregoireg]

I would like to add a couple of points to try to clarify some confusion:

-a) First, the camera is in free-running clock. Meaning that the clock never stops. Therefore, the LP transitions don't happen and doesn't matter.


-b) I mentioned analog a few times and it's indeed a little bit confusing:
* FSA642 is an analog switch. Read the datasheet if you need to be convinced.

* An analog switch is probably impossible with a FPGA because FPGA have only digital IOs (read this: http://www.edaboard.com/thread270986.html)

* But I still want to avoid deserialization/re-serialization of data. Therefore, I think that I need a clock as fast as the MIPI clock so that the 0s and 1s of both the input MIPI clock and data can be "assigned" to the output MIPI clock and data. Having the FPGA clock derived from the MIPI clock is definitely something I consider though it means that the MIPI input clock should be fed into some high-speed differential input CLOCK pins of bank 2.

So even if I manage to derive a clock from the MIPI clock, I'm still confused on what kind of input output (LVDS25E, LVDS25, MIPI) I should use, what will be the maximum speed (150MHz, 400Mhz, 450MHz) and if "assign output = input" will be enough.

[kony]

What is the supposed point of passing the datastream trough FPGA, when tehre are no changes to it and only single data channel is to be done like this?

[gregoireg]

This is the first step of the design. Once I would have this working, I can switch between multiple inputs and multiple outputs at each frame (my ultimate goal). Similarly to FSA64* but in a more powerful way.

[kony]

Of the many things FPGA can be turned into, analog multiplexer is not one of them.

You have to at least decode bus state transitions (HS/LP) and hadnle the data accordingly also on transmitter port. I'm also doubious about passing the stream trough fabric without the need of deserialisation, especially when it is in its own clock domain, but there might be way around. However, you simply cannot avoid deserialization and then again serializing the datastream if >>any<< modification further than multiplexing whole image frames is desired.

Claim that LP transitions do not happen is false. (What relevance has free running clock for that?)

[gregoireg]

I have read the MIPI CSI and D-Phy document and I agree that my statement about LP transitions was wrong.

Nevertheless, I'm still confused by Lattice own document rd1146, page 6:
"The majority of embedded designs that use CSI2 image sensors only utilize the data contained in the HS mode packets. To simplify the I/O on the input side of the MachXO2 device, the CSI2 to Parallel Sensor Bridge dismisses information received from the sensor in LP (Low Power) mode as it is not needed to convert video data available in HS (High Speed) mode. In fact, many image sensors do not utilize LP mode and often prefer HS short packets or additional long packets as a way to transfer additional information related to the video stream. Users should consult their image sensor’s data sheet to determine the need to utilize LP mode. LP mode data can also be received by the MachXO2 device if desired, by using additional I/O. If it is determined that LP mode is necessary, Lattice suggests
the following additional recommendations."

So even if I deserialize/reserialize, this document implies that LP transition can be discarded on input. I guess that LP transition needs to be created on output to ensure CSI2 compatibility beyond the in-the-middle FPGA.

[bktemp]

I have read the MIPI CSI and D-Phy document and I agree that my statement about LP transitions was wrong.

Nevertheless, I'm still confused by Lattice own document rd1146, page 6:
"The majority of embedded designs that use CSI2 image sensors only utilize the data contained in the HS mode packets. To simplify the I/O on the input side of the MachXO2 device, the CSI2 to Parallel Sensor Bridge dismisses information received from the sensor in LP (Low Power) mode as it is not needed to convert video data available in HS (High Speed) mode.

I would say it is correct: You don't care about data transmitted in LP mode, but it does not say anything about detecting LP -> HS transitions. Detecting LP11, LP01, LP00  and HS mode is simple: You need to build a simple statemaching analysing the input levels. If you see the voltage levels changing in the correct sequence you know a HS transmission will follow and you can start searching for the sync byte.
If you decode the data, you now the packet length. Therefore you can recreate the original signal including the LP->HS and HS->LP transitions without receiving any LP packet.

[gregoireg]

This is more than LP data, this is LP transition too for input and that's my point. Unless, I don't read it well, the schematics in the Lattice reference design to decode Sony CSI2 IMX169 http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/1D/CSI2toParallelBridgeBoardUsersGuide.PDF doesn't include any LP circuitry.

[kony]

See lattice reference design manual RD1182, it should asnwer all your questions and provide working IP solution as well.

[gregoireg]

Thanks for the reference. I have "obviously" already read this document. Note on page 2: "In some applications LP mode is not needed." It doesn't answer the question in my previous post. Why/how there is no LP circuitry in the Sony CSI2 reference design (http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/1D/CSI2toParallelBridgeBoardUsersGuide.PDF) and how to avoid LP stuff in receiving/deserializing data?

[bktemp]

I skipped through the documentation, but it does not tell how the HS receiver works without being able to detect LP->HS transition. Maybe they are only looking at the sync byte to determine a new data packet.
If you don't want to parse the data, adding 2 resistors for reading+transmitting LP signals is probably the easiest way, then you can just forward the data including the mode transitions and get the correct signal at the output.

[Scrts]

Does the source work in continuous clock mode?

[gregoireg]

Just to close on this thread, I have eventually managed to do this CSI2 bridge. Indeed, it can't be analogic and I had to deserialize the input and re-serialize it for the output. I have written about in another thread here: https://www.eevblog.com/forum/microcontrollers/csi2-'bridge'-'switch'-'duplicator'-and-'merger'/