TDES960: Camera line time

Hi Ishiwata,

Line period is calculated as 1/[(frame rate*(total number of lines)]. 

Can you confirm what your frame rate is?

I can also help check whether the 960 can aggregate successfully with these camera settings. Is the data type YUV-422 8-bit? And what is the total number of lines?

Regards,

Cindy

Hi Cindy,

Thank you for your reply.
Sorry for the late reply.
We are currently checking the frame rate.
The data will be UYVY (16bit/pixel).

I have an additional question.
The data sheet states that one lane can transmit 1.6Gbps.
In the case of 4lane, it is 4 times the speed, so I think it is 6.4Gbps, but the data sheet says it is 3.2Gbps.
Please tell me the reason for 3.2Gbps.

Best Regards,
Ishiwata

Hello Ishiwata,

Cindy is OoO today and will be back on Monday.

Hi Ishiwata,

Thanks, I will wait for your update on the frame rate. And the reason it says 3.2Gbps for 4 lanes in that section is because this example assumes 800Mbps per lane (see last bullet in the first paragraph).

Regards,

Cindy

Hi Cindy,

Thank you for your reply.
I understand your answer.
I'm sorry for the confusion caused by my mistake.

I'll ask you again question.

BW was calculated from the data sheet p.44 Equation 2. formula based on the camera specifications. BW will be 5721Mbps.
Calculate the line time if two cameras are used.
・For 2 cameras
→ Bit rate per camera 2860Mbps (= 5720/2)
→Time per line 14.4us or more (= 2560*16/2860M)
Since 15usec or more is required, I set the line time to 15usec. I confirmed that it works properly.

If you use 3 cameras, calculate the line time in the same way.
・For 3 cameras
→ Bit rate per camera 1906Mbps (= 5720/3)
→Time per line 21.5us or more (= 2560*16/1906)
Since 22usec or more is required, I set the line time to 22usec. It didn't work properly.
I set the line time to 26usec and it worked fine.

There is a difference between the calculated line time and the actual line time. I would like to know the cause of this difference.
Do you know any cause?

■Camera specifications
・Active width: 2560pixel
・active height: 1944pixel
・Format: UYVY(16bit/pixel)

Best Regards,
Ishiwata

Hi Ishiwata,

Line time depends on the total number of lines and the frame rate, so the horizontal active pixels are not part of the calculation. The total number of lines is the active vertical resolution + vertical blanking. 

You can refer to my equation above to calculate the line time.

If you are trying to do aggregation bandwidth calculations, you may find this training video helpful as it goes into the calculations in more detail: https://www.ti.com/vi-vn/video/6247583604001

Regards,

Cindy

Hi Cindy,

Thank you for your reply.

Which equation does "my equation above" in your comment refer to?
Also, can you calculate the correct line time? I would like to compare it with the customer's line time.
I don't have time to understand all TDES960. I need your help.

Best Regards,
Ishiwata

Hi Ishiwata,

Apologies for being unclear, I was referring to my first reply: 

Cindy Li said:

Line period is calculated as 1/[(frame rate*(total number of lines)]. 

Line time = 1/(frame rate * total number of lines). 

Once you know the total number of lines and the frame rate of the imager, you will be able to calculate the line time. I was not provided with the frame rate of your imager so am unable to calculate it myself. 

Regards,

Cindy

Hi Cindy,

Thank you for your support.

I forgot to tell you. sorry.
When the line time is set to 26us, the frame rate is 19.4 frames/second.

Best Regards,
Ishiwata

Hi Ishiwata,

If the total number of lines per frame is 1944 lines and the frame rate is 19.4, then line time would be 1/(19.4*1944) = ~26us. Is there any other question you had about this topic or does this answer your question? 

Regards,

Cindy

Hi Cindy-san,

Thank you for your feedback.

You are discussing about the frame rate and blanking time,
however, it may be inappropriate.
According to the video you introduced me, it insists that,
rather than frame base bit rate, line base rate is more critical,
because DS90UB960 has line buffer instead of frame buffer.
So, the data reach to the device within one line period must be
output within one line period.
https://www.ti.com/vi-vn/video/6247583604001 

Based on this advice, I calculate line base bit rate.
     2560 pixels/Line
     UYVY16 bit format (16 bit/pixel) 2560*16 bit
     Line rate: 22 us/Line 2560*16/22 bit/us
     Bit rate/Camera = 1.862 Gbps
     Bit rate of 3 cameras = 5.585 Gbps

DS90UB960 set up.
     Best-Effort Round Robin CSI-2 Forwarding
     CSI-2 @1.6 Gbps 4 lanes
     Estimated output bandwidth = 5.721Gbps
     *Referring the equation (2) on the DS90UB960 data sheet

Summary Input rate 5.585 Gbps < Output bandwidth 5.721Gbps

Despite of input rate is well below the output rate the DS90UB960.
cannot take care the input.

Question: Why DS90UB960 cannot take care as low as 5.5 Gbps input?

Best Regards,
Ishiwata

Hi Ishiwata,

The line time in the equation I provided is used in the bandwidth calculation equation as shown below: 

Based on your calculation for the input bandwidth, the 960 should be able to aggregate 3 image sensors with those parameters. Are you experiencing an issue?

Regards,

Cindy 

Hi Cindy-san,

My issue is that the data rate of 3 cameras is smaller than the bandwidth, but it cannot be transmitted.

Summary Input rate 5.461 Gbps < Output bandwidth 5.721Gbps

Despite of input rate is well below the output rate the DS90UB954.
cannot take care the input reporting BUFFER_ERROR, while
DS90UB960 can do it.
Question: Why DS90UB954 cannot take care as low as 5.4 Gbps input?

Below is the calculation formula that is the basis.

Estimated Input data rate and Output Bandwidth.
Sensor
    2560 pixels/Line
    UYVY16 bit format (16 bit/pixel)
    Line rate: 15 us/Line
    Bit rate = 2.731 Gbps
    Bit rate of 2 cameras = 5.461 Gbps
Serialize
   DS90UB953

DS90UB954 set up.
   Best-Effort Round Robin CSI-2 Forwarding
   CSI-2 @1.6 Gbps 4 lanes
   Estimated output bandwidth = 5.721Gbps
     *Referring the equation (2) on the DS90UB960 data sheet

Summary Input rate 5.461 Gbps < Output bandwidth 5.721Gbps

Best Regards,
Ishiwata

Hi Ishiwata,

I checked the calculation on my end (2560 active horizontal pixels, 1944 vertical total lines, 35Hz frame rate, two sensors on 954, continuous clock mode, round robin forwarding, 1.6Gbps, 4 lanes). Your calculation is correct, so it should be able to aggregate the two sensors successfully.

Can you please send a register dump of the DS90UB954 so I can check the errors? Can you also send the configuration script for 954? 

Regards,

Cindy  

Hi Cindy-san,

I'm glad my calculations were correct.
For 2 cameras, 5.461 Gbps <output bandwidth 5.721Gbps, so it works fine.
It doesn't work when there are 3 cameras.
This is the calculation formula for 3 cameras.

Estimated Input data rate and Output Bandwidth.
Sensor
2560 pixels/Line
UYVY16 bit format (16 bit/pixel)
Line rate: 22 us/Line
Bit rate = 1.862 Gbps
Bit rate of 3 cameras = 5.585 Gbps
Serialize
DS90UB953

Since 5.585Gbps <output bandwidth 5.721Gbps, it is possible to transmit according to the calculation, but in reality it is not possible.

Please tell me the difference between 2 cameras and 3 cameras.

Best Regards,
Ishiwata

Hi Cindy-san,

We received the contents of the register from the customer.
I have sent you a private message, so please check there.

It works fine with 2 cameras. 3 cameras cannot transmit correctly.

I have some additional questions.

Q1. Does DS90UB960 output SYNC code in single packet mode or multi packet mode?

Q2. If it output SYNC code in single packet mode, does the overhead factors on the Table 7-16.
(CSI-2 Transmitter Overhead vs Data Rate) include the overhead time for the short packet?

Best Regards,
Ishiwata

Ishiwata,

The calculation given in the datasheet/training video is a simplification of a much more complex state machine and is meant to be used as an estimate. For cases which are right on the edge like this one, we may need to check on bench to verify the aggregation use case can work. 

Q1) Not sure what multi-packet mode is. But 960 outputs short packets same as they were received. So that would be a standard MIPI short packet format

Q2) Overhead number in the table is meant to include all overheads including the overhead from short packets, long packet header/footer, and LP->HS entry/exit. But again, it is an estimate - not an exact number. 

If you need, we can double check your result to verify on bench that this use case of 3 cams with the 22us line time can't be supported. Also please check that you are enabling continuous clock mode on the CSI-2 interface, since that would need to be enabled in order to reduce overhead. 

Best Regards,

Casey 

Casey,

Thank you for your support.
Customer register setting is 0x33[1] = 0.
I set 0x33[1] = 1 and asked the customer to confirm.
Thank you very much for your validation.

Best Regards,
Ishiwat

Casey,

I double checked and found that the customer's register setting was x33[1] = 1.
With this setting, overflow occurs when there are 3 cameras.

I would like to send the customer's register settings to your private message, is this ok?

We will also inform the customer how to map the Frame Valid signal to his GPIO.

Please tell me how to set it up.
After setting GPIO_OUT_SRC to 0xx and GPIO_OUT_SEL to 110, where do I check the Frame Valid signal?
Is it possible to check without a logic analyzer?

Best Regards,
Ishiwata

Hello Shuji,

Due to the US public holiday the team is currently out of office and will resume operations on Tuesday. Thank you for your patience at this time 

Best Regards,

Casey 

Hello Casey,

When the customer checked the Line Valid output, they reported that about 10 lines of data were being output for a period shorter than the set line time.
I decided to check the settings on the camera side.
Thank you for your support.

Best Regards,
Ishiwata