I currently have two FMC176 boards in my posession: serial numbers 0038 (v1.0, MMCX) and 0054 (v1.1, SSMC). Both are producing corrupted waveform data on D0, but the data on D1 is fine.
I am running both boards on an ML605 with the unmodified FMC176/ML605/Ethernet reference design and its unmodified host application. This design outputs a 300MHz sine wave on both D0 and D1.
From a cold start, 0038 looks correct on both channels for the first 30-60 seconds. See the attached file 20130924_FMC176_0038_1.png (yellow trace=D0, green trace=D1). After that, the D0 waveform is corrupted; see 20130924_FMC176_0038_2.png (yellow trace=D0, green trace=D1).
0054 works somewhat more reliably, but still does output corrupted data. For the first ~30-60 minutes of operation in a recent test, I observed no corrupted data. After that, every minute or two it goes through fits where it outputs corrupted data on D0. An example is shown in 20130924_FMC176_0054.png (yellow trace=D0, green trace=D1).
I am blowing a table fan over my setup, as recommended to me by 4DSP staff. Both cards read temperatures under 50C even after extended operation. What possible causes are there for this? Any suggested solutions?
Another observation I've made is that when the waveforms are correct, the amplitudes of the waveforms output by 0038 are larger than those output by 0054. The software and firmware used by both cards is identical. Did something change in the hardware between v1.0 and v1.1?
I have finished testing the design with the MMCM locked signals pinned out. This design does meet timing, and it exhibits the same behavior I observed using ChipScope. The data are correct on DAC0 until the first falling edge of the MMCM locked signal. The MMCM sometimes comes unlocked multiple times per second. Other times it will stay locked for minutes on end. If it stays unlocked for long, of course, the output gets turned off because the OSERDES get reset. But a brief unlocked period seems to be enough to cause some havoc. I have yet to see it stay unlocked for more than 10-20 us.
I have also observed that the output can be corrupt during long periods with a locked MMCM - but only after it has already been unlocked. My guess is that this state is caused by a brief unlocked period which fails to reset the OSERDES. I can see how this might cause the OSERDES to get out of phase with the data frames. Further reinforcing this theory is the fact that during these periods the corrupted output is not changing; the same corrupted data get output repeatedly until the MMCM loses its lock again.
I also did an experiment where I provided the FMC176 with an external 2.458GHz sample clock. This did not appear to change the behavior of the DAC0 MMCM. I came unlocked just as regularly as when using the internal clock.
over 4 years ago
Could you answer me the following questions? 1. ML605 revision number 2. Steps how you test the FMC176 firmware on ML605
I will try to reproduce the error with the same hardware and fw/sw. If not, we may offer an RMA to see if it happens on our ML605.
over 4 years ago
I am using ML605 rev D. The steps to reproduce the error are pretty simple.
1) Generate the ISE project using 4DSP's tools. 2) Build the project in ISE 14.1. Program the ML605 using iMPACT. 3) Run the FMC176 app from MS Visual Studio, communicating with the ML605 via Ethernet. 4) Observe the DAC outputs on a scope. If your FMC176 app is (like mine) unmodified, both channels should be outputting a 300MHz sine wave. 5) Set the scope to trigger if the DAC0 output exceeds the normal envelope of the sine wave. 5) Wait and check the scope periodically for a trigger event. On one of my FMC176 boards I did not observe any failures for 30-60 minutes. On the other board it took only 30-60 seconds to see a failure.
I can provide my modified design which pins out the MMCM locked signals if that is useful to you.
I should also let you know that yesterday I got both of my FMC176 boards to work on the board I am using for my product. I discovered that both MMCMs were in fact staying locked when using my carrier board and that the real problem was that the DLL on the AD9129 was failing to lock. For some reason, turning off the duty-cycle correction on the DLL allows it to lock for certain phase settings. Once it locks, it stays locked and the data output is clean.
over 4 years ago
It's good to hear that you fixed the issue. Thank you for your feedback and let me know if you have any more questinos.