UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer jhallen
Observer
849 Views
Registered: ‎03-23-2017

MIPI DSI Transmitter Subsystem sync timing

I have an application where I need uniform line timing throughout the frame, as if I'm driving an old CRT monitor.  But MIPI DSI Tx timing is a little off...

DPHY reference clock and s_axis_aclk are supplied with 200 MHz.  MIPI transmit clock is 800 MHz.  The byte rate is 400 M / sec (there are four lanes).

I want 6000 bytes per line total and 1200 lines per frame total.  [Actually I just need assurance that I can control this accurately].

When I measure the total frame time by counting the number of 200 MHz clocks between successive SOFs (TUSER[0] == 1 && TREADY && TVALID) from the Xilinx TPG, I get 3,600,056 every frame.  But I should get 3,600,000: 200 MHz / Frame rate, where frame rate = 400 MB/s / (6000 * 1200).  Where are the extra 56 cycles coming from?  Shouldn't the horizontal timing be exactly uniform?  An LCD won't care, but a CRT certainly will...

Are there any work-arounds for this?

Here are the parameters:

  HACT = 5760, HSA = 12, HFP=98, HBP=98, VACT=1080, VSA=36, VFP=42, VBP=42.

Here are the registers, and I see that LTIME is 6000 bytes.  I'm suspecting that something is wrong during the vertical sync period.

CCR = 1
PCR = 3f03
GIER = 0
ISR = 0
IER = 0
STATUS = 20
COMMAND = 0
TIME1 = c0000
TIME2 = 16800438
TIME3 = 620062
TIME4 = 242a2a
LTIME = 1770
BLLP = 1750

Update: I have set up an IMX274 image sensor with these same parameters (with IMX274 reference clock derived from the 200 MHz DPHY clock), and have measured the Start of Frame time coming from the MIPI CSI receive subsystem: it gives exactly 3,600,000 cycles as expected.  So if I connect the camera to the MIPI DSI Tx without a frame buffer, they eventually go out of sync [the FIFO between them overflows] due to the extra 56 cycles.  It looks like I'm not going to be able to use the Xilinx DSI core..

 

Thanks,

Joe

 

Tags (2)
0 Kudos
15 Replies
Xilinx Employee
Xilinx Employee
754 Views
Registered: ‎03-30-2016

Re: MIPI DSI Transmitter Subsystem sync timing

Hello Joe @jhallen 

>HACT = 5760, HSA = 12, HFP=98, HBP=98, VACT=1080, VSA=36, VFP=42, VBP=42.

1. How did you calculate those parameters value (HBP,HFP,HSA, etc ) ?
    Did you refer to "Example Timing Register Calculations" from PG238 Chapter3 ?

2. What Video mode are you using ? ( Sync Events, Sync pulses or Burst mode )
--If you can share your details usecase, I can double check the timing register calculation.

3. My understanding is:
    For a precise result , the actual measurement has to be done at MIPI D-PHY PPI TX interface by looking at the “VSync” packet.


Thanks & regards
Leo

0 Kudos
Observer jhallen
Observer
740 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

Hi Leo,

1. Yes, I followed the instructions in PG238.  The number of lines is supposed to be VACT+VFP+VBP+VSP.  The number of bytes is supposed to be HACT+HFB+HBP (and +HSA in sync pulse mode), plus the packet overhead bytes.  The core is nice in that it provides the LTIME register to confirm the total bytes per line.  The error would be a lot worse if the line time was not correct (because it would be multiplied by the total number of lines), but the observed error is very small- 15 PPM or so.

2. I tried both sync events and sync pulse modes: the math is a little different, but the results are the same, 56 extra cycles per frame. I've not tried burst mode, maybe I'll do that today.

3. I don't think it's necessary- the data input rate has to equal the output rate, so you can infer the frame rate from the SOF input.  It's possible that there could be jitter on the SOF input due to FIFOs in the core, but I didn't see any, and in any case the long term average must equal the output rate.

Thanks,

Joe

 

 

0 Kudos
Observer jhallen
Observer
730 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

I tried burst mode, the results are the same.  For burst mode, the parameters are:

HACT=5760, HSA=12, HFP=98, HBP=98, BLLP_BURST_VALUE=16, VACT=1920, VSA=36, VFP=42, VBP=42

LTIME shows 6000.

Again the frame count is 36,000,056 instead of 36,000,000.

I also tried BLLP mode (PCR bit 6, "Use LP mode for BLLP periods"), but there is no documentation on how the timing works when this mode is enabled, and the results are very different- the frame rate is slower.  My guess is that the LP time from the DPHY core is added to the high speed times (maybe the DPHY escape mode clock is used?).  Even so, I was able to get closer to the target: 35,999,998: just 2 cycles off per frame, but it needs to be exact and I need to be able to calculate it, not guess.

 

0 Kudos
Xilinx Employee
Xilinx Employee
707 Views
Registered: ‎03-30-2016

Re: MIPI DSI Transmitter Subsystem sync timing

Hello @jhallen 

I just added PG238 "Example Timing Register Calculations" Example configuration 2
In the Excel File attached in this post.

Please see column "H" for example configuration calculation.
Could you please put your timing register calculation in column "F"  and share the result with us ?
- The information written in red is required.

EXCEL.png

Thanks
Leo

0 Kudos
Mentor watari
Mentor
701 Views
Registered: ‎06-16-2013

Re: MIPI DSI Transmitter Subsystem sync timing

Hi @jhallen 

 

How do you connect CRT and drive old CRT ?

BNC cable ? Analog RGB cable ?

Also, analog signal or digital signal ?

 

I guess you use DAC to convert signal via MIPI DSI.

If yes, what is your target frame rate ?

Also, does old CRT accept this frame rate and you mentioned video timing ?

 

I'm probably sure that it's video timing issue for old CRT.

 

Best regards,

Observer jhallen
Observer
687 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

Hi, I'm not driving a CRT, I just said I have an application where I need uniform line timing, _as_if_ I'm driving a CRT. 

What I'm really trying to do is have a low latency path between an image sensor and a display.  I want to use a small FIFO instead of a full frame buffer, but this requires the sensor and display to be exactly in sync.

Image sensors can be programmed with uniform line timing with no trouble- it just means the number of clocks per line is evenly divisible into the number of clocks for the entire frame.  I was expecting the same for the MIPI DSI core.

 

0 Kudos
Observer jhallen
Observer
678 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

Xilinx Employee
Xilinx Employee
662 Views
Registered: ‎03-30-2016

Re: MIPI DSI Transmitter Subsystem sync timing

@jhallen 
Thank you for sharing your Timing register calculation.

Instead of these
HACT=5760, HSA=12, HFP=98, HBP=98, BLLP_BURST_VALUE=16, VACT=1920, VSA=36, VFP=42, VBP=42

Could you please try these regs setting also ?
HACT=5760, HSA=69, HFP=70, HBP=70, BLLP_BURST_VALUE=--, VACT=1080, VSA=36, VFP=42, VBP=42

Thanks
Leo

0 Kudos
Observer jhallen
Observer
615 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

Hi Leo,

I tried it in sync pulse mode with your parameters:

>HACT=5760, HSA=69, HFP=70, HBP=70, BLLP_BURST_VALUE=--, VACT=1080, VSA=36, VFP=42, VBP=42

Whole frame clock count ends up 3,600,656

CCR = 1
PCR = 3f03
GIER = 0
ISR = 0
IER = 0
STATUS = 20
COMMAND = 0
TIME1 = 450000
TIME2 = 16800438
TIME3 = 460046
TIME4 = 242a2a
LTIME = 1771
BLLP = 1718

But note that with these settings, the LTIME is 6001.  I also tried it with HSA=68 and I get LTIME=6000 and:

Whole frame clock count is 3,600,056

CCR = 1
PCR = 3f03
GIER = 0
ISR = 0
IER = 0
STATUS = 20
COMMAND = 0
TIME1 = 440000
TIME2 = 16800438
TIME3 = 460046
TIME4 = 242a2a
LTIME = 1770
BLLP = 1718

Thanks,

Joe

 

Xilinx Employee
Xilinx Employee
562 Views
Registered: ‎03-30-2016

Re: MIPI DSI Transmitter Subsystem sync timing

Hello @jhallen 

Are your dphy_clk_200M and s_axis_aclk synchronous clocks ?
-- If no perhaps will cause an accumulated error that result 56 clock difference for a whole frame.

Regards
Leo

0 Kudos
Observer jhallen
Observer
548 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

Yes, actually they are the same clock.

 

0 Kudos
Xilinx Employee
Xilinx Employee
521 Views
Registered: ‎03-30-2016

Re: MIPI DSI Transmitter Subsystem sync timing

Hello @jhallen 

1. Oh, one more thing how did you calculated 3,600,000 cycles ?

Since you have Total Line time = 15000ns
with Vertical period : 2000
-- The calculation should be :
2000 line x 15000 ns / 5ns = 6,000,000 clock.

2.  What is the data type & pixels per clock selection in GUI ?

Thanks & regards
Leo

 

0 Kudos
Observer jhallen
Observer
503 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

It's 1200 lines, not 2000, so you get 3,600,000 clocks.

The parameters are:

DSI lanes = 4

Input pixels per beat = 4

DSI datatype = RGB888

CRC Generation logic is checked.

Line rate = 800

LPX Period = 50

Enable AXI-4 Lite Register I/F unchecked

Infer OBUFTDS unchecked

Include shared logic in design is checked

Thanks,

Joe

 

Xilinx Employee
Xilinx Employee
471 Views
Registered: ‎03-30-2016

Re: MIPI DSI Transmitter Subsystem sync timing

Hello Joe @jhallen 


1. So, you want to count number of bytes transferred between two SOF's and you need to ensure that it should match with theoritical calculation. Please kindly confirm.

2. Input pixels per beat = 4 , DSI datatype = RGB888
It means you have 4 x RGB888 = 4 x 24 bits = 96 bits = 12 byte. transfered each beat.
Could you please count-up the number of (TVALID=1 and TREADY=1) between SoF ?
I do not see any reason to count-up the number of 200 MHz clock between SoF, since there would be some clocks where TVALID=0 or TREADY=0 so there won't be any data transfers.

Thanks & regards
Leo

0 Kudos
Highlighted
Observer jhallen
Observer
455 Views
Registered: ‎03-23-2017

Re: MIPI DSI Transmitter Subsystem sync timing

>1. So, you want to count number of bytes transferred between two SOF's and you need to ensure that it should match with theoritical calculation. Please kindly confirm.

No, I need the frame rate to exactly match the theoretical calculation.  The number of transferred pixels is correct.

>I do not see any reason to count-up the number of 200 MHz clock between SoF, since there would be some clocks where TVALID=0 or TREADY=0 so there won't be any data transfers.

I'm counting the clocks to measure the frame rate.  3,600,000 clocks should be one frame, but DSI core is using 3,600,056 for some reason.

I also checked this with a scope to be extra paranoid.  I have a counter that generates a pulse once every 3,600,000 clocks fed to a pin.  I have the SOF on another pin.  When I look with the scope, I can see the pulses drifting apart.

Anyway, I have since written my own DSI core.  I get perfect timing with it, like this:  On the last line of the VFP I transmit the EoTp instead of transmitting the blanking packet, and let the lanes return to low power mode (at all other times they are in high speed).  The core remains idle until an independantly running frame timer determines that it is time to start the next frame.  This way you don't have to know how much time the transitions between LP and HS take.  I'm pretty sure the Xilinx core is trying to build the frame time bottom-up by estimating these transition times or something.  I guess it could be trying to measure the transitions by looking at the D-PHY core state signals, but they are asynchronous, so the timing is not going to be exact.

A side benefit of my own core is that I have a direct way to start it: there is a start signal, instead of AXI-lite write transaction to the enable bit.  Still, I would have preferred if the Xilinx core worked- for the money we would be buying something fully verified and versatile.

Thanks,

Joe