We are in the process of configuring a system to test the performance of the AD9957 as a flexible multi-channel exciter for a phased-array radar for atmospheric research. The setup contains three EVAL-AD9957 boards, running off a common AD9513-buffered 70 MHz clock. The PLL multiplication factor is set to 14, corresponding to an internal clock rate of 980 MHz. The 9957s will eventually have to be synchronized using the built-in sync feature.
The boards have been run up individually using the USB interface and Windows GUI and correct operation in QDUC mode has been verified. We then proceeded to run in a "half-way" mode, where the 9957 is set up from Windows but the I/Q data to be transmitted is generated by a Xilinx FPGA and input to the 9957 via header connector P1. This mode is not described in the EVAL_AD9957 data sheet, but is easily set up; setting strap W2 to DIS tristates the outputs of U1, allowing an active external driver to take over the baseband data bus. The FPGA, which is clocked at 100 MHz, monitors PDCLK (set up to run at half rate) at SMA connector J8 and outputs data after each detected transition. In this way we have been able to generate and verify a large number of constant-amplitude phase codes at bandwidths up to (so far) a few MHz; that is, the system works in principle. Increasing the modulation BW up to 30 and then 60 MHz will be attempted later.
So far so good. However, when attempting to let the FPGA take over also the setup and control of the AD9957, we ran up against an unexpected problem - if we set strap W4 on the EVAL-AD9957 to DIS as per Table 3 on page 3 of the data sheet, the PDCLK signal at J8 disappeared! Checking the schematic (Drawing 9957CE01G), one finds that the PDCLK signal at J8 is buffered by octal buffer U12, but lifting W4 disables U12. That is, when the board is strapped in the recommended external controller configuration, there is no PDCLK signal available on any of the connectors provided - but it is needed to synchronise the baseband data stream!
Q1: Are we missing something?
Q2: Is this way of controlling the PDCLK output intentional or a design oversight?
Q3: Please suggest how we should best circumvent the problem -
Can we leave W4 in ENABLE without running into problems with the MasterReset and PowerDown signals coming from the USB controller going active at arbitrary times, or must we start cutting/patching the PCB wiring? We would like to avoid this if at all possible so as to retain the possibility to run the board from the Windows GUI for verification purposes.