Part Number: DLPC410
Tool/software: Code Composer Studio
Our setup is as followed: (Virtex7, DLPC410, DLP7000)
As we have resolved the previous problem, the DLPC410's initialization and calibration go successfully, and we can also retrieve the right DMD_TYPE and VERSION. However, the control outputs somehow couldn't get to the mirror, and I'll list some of our observation below:
1. The RST_ACTIVE stays low even after we output BLK_MD = 11, BLK_AD = 1000, ROW_MD = 00, ROW_AD = 'd0, and other control signals (e.g. wdt_ena, rst2blkz, ns_flip ...) weren't toggled during the output.
2. ECP2_M_TP16 (Clock reset) stays high after initialization. We're not sure if this is normal and what causes this if it is not.
In reply to Justin Chen14:
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to ykc:
DMD_TYPE:0001, VERSION: 5
When the PLL and LVSD modules are ready, the DCLK will always be provided. And after the initialization, our DVALID is constantly logic high (we checked the LVDS output using oscilloscope).
This is our DCLK measurement, is this a valid one?
In addition, we want to know what is the mechanism of ECP2_M_TP5 (DVALID_A) assertion. Does it indicate directly our DVALID LVDS signal from APP_FPGA, or is it an indication of the validity of the DVALID + DATA signals? If it is the latter one, and if we measured those signals using an oscilloscope, how can we know if they are valid or not?
Hi Justin, Dvalid latches the block and mode settings and indicates start of row operation when it is asserted. It should be deasserted after 16 clocks Please check Figure 8. DLP7000 / DLP7000UV 2XLVDS DMD Input Data Bus. When you say Dvalid is constantly high. You mean right after initialization it stays high? Please try keeping it low, adding some delay after init then assert it. Please also check Figure 3 of datasheet regarding timing requirements of these signals. -ykc
" It should be deasserted after 16 clocks"
How long should it be deasserted? We now deasserted it for 2 clocks after asserting it for 16 clocks but the TP5 is still not asserted.
"Please try keeping it low, adding some delay after init then assert it."
We now keep it low after init and then assert it.
"Please also check Figure 3 of datasheet regarding timing requirements of these signals."
Both of our NS_FLIP and COMP_DATA are constantly logic low.
"DCLK scopeshot you attached is it differential signal ?"
We found that the LVDS clock gets well after we inserted a GBUF for the reset pin of the LVDS module. This is our DCLK signal now.
We found that when we deasserted the ARSTZ, the INIT_ACTIVE will only be asserted for 14ms, unlike the 220ms assertion on the datasheet.
What could possibly cause this, and will this cause any other problem such as the lack of training pattern lasting time?
And please we would like to know the mechanism of the ECP2_M_TP5 assertion.
Thanks a lot,Justin
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.