I've been programming the APPSFPGA on the DLP4100 kit with my own algorithm leveraging the code supplied in TI's Extranet.
My 200MHz design works fine, and the DMD mirror array work as expected. However, replacing the 200MHz PLL, with a 400MHz PLL (VHDL code also supplied by TI) produces unexpected behavior of the mirrors at start-up.
Occasionally, the top few rows of the DMD mirror array will set, while the rest will float. Looking at the DMD mirror array, I can see the projected pattern weekly displayed. I assume the mirrors could not reach their final position and are somewhere between floating state to the state they were programmed to be at.
This behavior seems random and will either start immediately after programming and upon initialization or will not show up at all (Maybe DDC training related??).Functional simulation in Xilinx's tools works fine. Nonetheless, there is a problem of pulse swallowing in the timing (post place and route) simulation on the output buffers (OBUFDS) of the generating DCLK OSERDES DDR cells. While the input of the buffer toggles, the output does not.
Any ideas?BTW, I'm using the XGA .55" DMD
I will try to help you with this issue. Do you have the Discovery Explorer GUI installed? If so please open the GUI while connected to the board and go to "Help/About" and send a screenshot of the version information or at least of the DDC4100 version.
Second, when the issue occurs could you carefully measure the VBIAS rail and report the voltage?
Also please clarify for me. Sometimes with the 400 MHz PLL it operates correctly, but occassionally it does not. Is this correct? Could you estimate the frequency (i.e. 1 out every n startups)?
Thanks for responding.
I do not have the Discovery Explorer GUI installed, however I do have the ALP software by ViALUX. I will try to look for the DDC4100 version in there.
I haven't been able to measure the VBIAS rail yet. Is there a test point on the PCB where the voltage is easily accessible or is it part of the MICTOR connector?
It's hard to say how often the problem repeats itself but it's quite common, and may happen for 3 start-ups in a row.
One lead that I suspect is the the timing requirements of the DDC4100. I just remembered that most of the outputs of the APPSFPGA towards the DDC4100 (dout_*, dvalid, rowad, ...) should have a maximum skew of 150ps to dclk_in. I've been able to find a workaround to the pulse swallowing issue and got a timing simulation working. The skew between the LVCMOS25 outputs (rowad, rowmd, blkmd, blkad) and dclk_in is a little bit over 1ns!
I'm using the constraint file supplied with the sample code from the extranet (apps.ucf) which worked well with the 200MHz design. Are there any changes necessary to make it work with the 400MHz?
Can you please elaborate a little bit why are constraints from this type: NET "dout_ap_o[*]" OFFSET = OUT 15 ns AFTER "clk_i"; are required?Isn't this a source synchronous design, where the APPSFPGA generates the clk to the DDC4100?
By adding a "FAST" slew rate attribute to the LVCMOS25 outputs mentioned above, I've been able to decrease the skew to a few hundreds ps. However, the number is still over 150ps.Thanks in advance-Eyal
By the way,
Another discussion I started recently regarding this issue at Xilinx: http://forums.xilinx.com/t5/Timing-Analysis/minimal-skew-between-output-pads/m-p/254184#M3306
To summarize: different I/O standards: LVDS25 and LVCMOS25 are the main result of the SKEW. Not much I can do about it (Had a suggestion to change the drive strength of the LVCMOS25 outputs, but haven't tried it yet) since everything in the kit is already routed and the I/O standards are already set.
Is it possible that the routing between the DDC4100 and the APPSFPGA compensate on the SKEW between the I/O standards?
Sorry for the delay. Consulting with the FPGA team, I have the following information for you.
The timing restaint of ±150 ps is only for the LVDS Inputs (to the DDC4100). The LVCMOS inputs (i.e. Block Address, Block Mode, Row Address, Row Mode etc are not as stringent. They should be within 1/2 clock cycle of the first rising clock edge of a row cycle.
They indicate the outputs should be synchronized by design of the SERDES elements provided by Xilinx, unless you have alter one (or more) of the SERDES blocks which would pull the block into the fabric of the design.
At 400 MHz, are you ensuring that all row operations start on a rising clock edge? Does Init_Active go low indicating that it has at least completed the process. P.S. Init finishing does not ensure that everything initialized correctly.
Thank you for clarifying that.
I am still using the SERDES in the IOB and the LVCMOS inputs (to the DDC) are within 1/2 clock cycle so I guess this is not the reason for the 400MHz design inconsistent initialization.
All row operations are synchronized to the rising edge of DCLK_IN except of the skew I mentioned between LVCMOS and LVDS inputs.
~3us after Init_active goes low, APPSFPGA starts loading the DDC with data.
What does it mean "Init finishing does not ensure that everything initialized correctly." ?
Anything that I can do about it?
Initialization is a program that runs in the DDC4100. It is possible for it to finish, but this does not verify that the DAD voltages are correct or that the training patterns had the right timing.
It is important at this point to verify that the DAD2000 voltages are correct. Please check the rail votages according to the DAD datasheet pins. You must do this very carefully. It is possible (and easy) to damage the DAD by shorting the rail voltages to ground.
Are you able to verify which version of the DDC4100 firmware the board is running? If it is V3 or below then you must ensure that RST2BLKZ, COMP_DATA, and NS_FLIP pins are held low during initialization, otherwise init may not complete correctly. If they are left to float you can get random initialization failures.
If that does not work, then I suggest, while power is off, connecting a fine wire to one of each of the rail lines so that you can test with a voltmeter without danger of "fat probing" between the rails and adjacent grounds. The voltages should be V_BIAS = +26 V, V_RESET = -26 V, and V_OFFSET = 7.5 V (or 8.5 for 1080p).
Let me know how it works.
I did not have access to the DLP over the last few days, however, I assume that the voltages are fine since the ALP software from VIALUX works well with a 400MHz data rate. Therefore, there must be something wrong in my initialization. All the signals you mentioned (RST2BLKZ, COMP_DATA, and NS_FLIP) are held low during the init process. However, WDT_ENABLEZ (Watch dog) and the PWR_FLOATZ controls do change from high to low after 3 x 20us pulses = 60us by the debounce logic borrowed from TI example code). Could this be related?
Any other idea?
The V_RESET rail could be incorrect if your initialization routine somehow interrups the communication with the DAD2000(s). This process reads in the DMD type and then sets the voltages accordingly. If interupted it can result in V_RESET rail being at 19 V.
Are you using the training pattern block from the TI Example code?
Thanks for the quick response.
I am using the training pattern block from the TI example code.
It is important for you to measure V_BIAS voltage in those instances where it does not display (weakly displays) on the DMD. Please also see if INIT_ACTIVE has gone low.
I am sorry it took me so long to respond.
I've had a look today on the DAD2000 and am not sure how is it possible to measure the VBIAS rail without soldering a wire to the pin, which I rather not do.
Can you describe in further details what would be the best way to probe the voltage? As you mentioned, I'm afraid that a simple probe will short the pin with one of it neighbors.
The other way is to use one of the MBRST test points on the board. You will need the chipset guide from the extranet to identify the location one of the MBRST test points. However you will need an accurate scope to measure the full 26 Volts of VBIAS on the waveform. It briefly swing to -26 Volts set your trigger to 0V and falling edge then measure the high value.
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. 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 respect to these materials. 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.