Dear sir,
I am looking for high speed(>75MHz pixel clock for 720p ) serializer / deserializer chip to transmation TUV422 format 16 bits data. Can DS90UH925Q-Q1 and DS90UH926Q-Q1 (24 bits) support it? If it cans which data pin should I connect?
Hi Kevin,
Another SerDes pair - DS90UB913Q and DS90UB914Q might be more suitable to your color space and bus width.
In principle the UH925/6 can support it. Which pins you use may depend somewhat on your application and whether other features are to be used (I2S audio, GPIO, etc). Could you tell us some more about the application?
The 925/926 comes in UH (HDCP enabled) and UB (non-HDCP) versions. Does your application require HDCP support? If so, you would need to register and become and HDCP adopter through DCP, the licensing body for HDCP technology.
Thanks,
Ryan
Best Regards,
SVA APPS
Hi
Yes the DS90UB913/914Q chipset is more suitable for this application. You can contact me at amritraj.khattoi@ti.com for additional information regarding this chipset.
Raj
Dear Ryan,
Thanks for your reply. The reason why I need to use DS90UB913Q and DS90UB914Q is pixel clock. My project need to support 720P. That means the pixel clock is approach 75Mhz and only DS90UB913Q and DS90UB914Q can support it!
Kevin!
Dear All,
Sorry for my mistake in last mail. I want to tell you about data bits not pixel clock. I use this chip to transmation 16 bits YUV422 data. Only DS90UB913Q and DS90UB914Q can support more then 16 bits and >75MHz pixel clock data in SDI interface!
Kevin
Hi Kevin
The DS90UB913/914Q can only support 12 bits up to a PCLK frequency of 75MHz and 10 bits upto a PCLK frequency of 100MHz. For a 16 bit wide data you need to use the DS90UB925/926 which supports a 24 bit color depth up to a PCLK frequency of 85MHz.
Thanks for reply! Let's go back to my second question. DS90UH925Q-Q1 and DS90UH926Q-Q1 is 24 bits and our request is 16bits, so which part should I connect(Ex. R&G, G&B B&R). Also what should I deal with for non connect pin(Ex. Pull high/low or float)?
Thanks!
Any combination would be acceptable. However, for maximum flexibility I recommend distributing your video bits across the six (6) most significant bits (MSBs) of each color channel. This includes R[7:2], G[7:2], and B[7:2]. The reason for this is that the two least significant bits (LSBs) of each color channel are shared with I2S audio and GPIO pins - depending on your design you may want to use them now or in the future. For example, you might use R[7:2], G[7:2], and B[7:4].
Unused inputs may be pulled low. I recommend a kOhm-range pull-down but connecting directly to GND is also acceptable. You might also consider placing the device in 18-bit mode so that the 2 LSBs for each color channel are ignored by default. 18-bit mode is also required if you intend to use I2S_B or any back-/forward-channel GPIO options.
Thanks for excellent explain for those information that is exactly what I need. But one more question. Basis on datasheet the data pin should be leave if unused. It looks conflict to you suggestion? Can you help me to explain more?
You are correct - the RGB inputs do have internal active pull-downs, so you are not required to implement it externally. However, it's reasonably good design practice to tie the unused pins low if the design permits it.
-Ryan
Thanks for your reply. I have no more question in this issue.
kevin
Thanks for help!