06-28-2012 03:57 PM
I'm a bit stumped. I've been trying to use the ISERDES2 and IODELAY2 to deserialize a 1080i TMDS signal running at a pixel clock of 74.25MHz. I've set up a PLL to get a bit clock (10x the input) and a half-pixel clock (2x input, deserializing 5 bits of a 10 bit pixel at a time), feeding a BUFPLL to get the SERDESSTROBE signal. The BUFPLL is set up #(.DIVIDE(5)) and is getting the bit clock from the PLL and the half-pixel clock from a BUFG. In simulation, everything locks up to the input clock and the BUFPLL generates a lock signal and a strobe, but when I test it on an Atlys board, the BUFPLL LOCK signal never goes high.
I checked for the presence of the pixel and half-pixel clocks out of the PLL by throwing together some counter dividers on the chip and blinking some LEDs. I also measured the frequency of the divided output and determined that it corresponded to the 74.25MHz input. Bringing the PLL lock out to an LED also shows that it locks up to a signal no problem. Is the BUFPLL just being optimized out of the design because I'm not routing the IOCLK output anywhere yet? Any ideas on how to troubleshoot further without a high-speed oscilloscope?
Solved! Go to Solution.
06-29-2012 09:22 AM
Is the BUFPLL just being optimized out of the design because I'm not routing the IOCLK output anywhere yet?
Any ideas on how to troubleshoot further without a high-speed oscilloscope?
The simplest answer is to connect some load(s) to the BUFPLL IOCLK output. Until you do this, you shouldn't be too concerned about this problem.
By the way, the synthesis reports should warn you of trimmed logic, and the Design Summary reports the count of BUFPLLs and BUFPLL_MCBs (separately) in your design.
A 500MHz or better oscilloscope is still a very useful tool for hardware design, but the problem you describe does not (yet) require one.
-- Bob Elkind