Forums

Hello Eyal,

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)?

Fizix

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?

-Eyal

Hello Eyal,

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.

Fizix

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?

Thank you,

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?

Eyal

Eyal,

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.

Eyal,

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.

Fizix

Hello Fizix,

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.

Thanks,

Eyal

Hello Eyal,

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.

Fizix