Is this card compatible with the Xilinx ZC706 evaluation board?
Yes it is- here is the pin mapping. Any one of the 7 series reference designs should work as it is (except for the other peripheral changes).
Is there a ZC706 reference design available? If not, could I just import the axi_adc_1c peripheral from one of the other reference designs available on the wiki page and function properly? Of course I would need an SPI peripheral to configure the ADC as well. Can you think of anything else I would need to access the raw ADC data and push it to my own custom peripheral?
No. The pcore is same for all (Zynq, 7 series or 6 series). To be specific, you can use the KC705 MHS file - copy the sections of the DMA (or your custom core), ADC and SPI to your ZC706 MHS - make the connections and you should be all set.
If you run into problems, let us know.
Last couple of questions:
1. Are there any Xilinx proprietary cores that I would need licensing for to build this design?
2. My design requires a sampling clock of 143 MHz. Is that frequency achievable using the AD9517-4 and how would I accomplish this?
Thanks for all your help,
1. All of our cores are free and open source. The Xilinx cores need licensing- most of the IPs comes with the software (the software do require a license or webpack) - additional IP (such as JESD - will need additional license (cost)). You should probably contact Xilinx - there may be some special consideration for educational/research purpose.
2. The board requires an external clock (by default)- you need to make some modifications to use AD9517. Refer to the wiki and schematics. I am not sure about 143MHz - try the ADI clock simulation software - http://www.analog.com/en/rf-tools/adisimclk/topic.html.
In regards to 2, what is the frequency of the optional oscillator that can be selected instead of the external reference?
The bill of materials on the wiki page lists the part number for the oscillator as VECTRON VCC6-QCD-25M000 which is a 25 MHz oscillator. Is it getting multiplied up somewhere?
This is an error in the BOM. The crystal is a 250MHz Vectron crystal. It will need some work on the board to get the crystal to drive the ADC. Moreover, the crystal performance is very lackluster. You can see below how bad the SNR degrades with the VCC6. At the time of the release of the AD9467-FMC-250EBZ, the VCC6 was the only 250MHz crystal oscillator with any decent performance. Since then, there have been others, most notably Crystek. You can see from the curve below how the SNR keeps up with the Rohde&Schwarz SMA100A.
We are in the process of redesigning this board to include the Crystek CCSO-914X series crystal oscillator.
Can you be more specific when you say “It will need some work on the board to get the crystal to drive the ADC”. I connected a jumper between pins 2 and 3 on header P200 to enable the onboard oscillator. I also jumpered pins 1 and 2 on header J300 to change the reference select. This did not seem to route the onboard oscillator to the ADC as we had hoped. Another thing we tried was leaving the board in its default configuration and driving it with an external clock. We were able to see the clock inside the FPGA change which was great but the ADC data does not appear to be right. We configured the ADC to be signed 2’s complement and when we plot the ADC data with noise on the input it is railing. The values are sporadic between -32768 and +32768. Noise should have very low amplitude. We are able to communicate with both chips via SPI and it appears that the registers are being set correctly, however the data we are seeing out of the ADC does not appear to be correct. Any help you can give us would be greatly appreciated.
To enable the on-board oscillator, you will need to do the following:
1. place C205/C206 = 0.1uF 0402 size capacitor
2. remove R209/R210
3. remove CR200
4. enable oscillator by placing jumper P200 to the ON position. Pins 2 and 3 need to be shorted.
Hope this helps.
I am the software engineer working with Kiel on this project. We now have the card integrated and are using an external clock due to the delay that would be involved in reworking the board.
The problem now is that while I can read and write the AD9517 via SPI I can only read the AD9467 and I need to modify the chip for our desired behavior.
My initial goal is to set the chip to twos complement output for integration into our follow-on processing. I expected to have no issue setting register address 0x14 to value 0x09 and subsequently latching the data by writing 0x1 to address 0xFF. I see the UPDATE bit get set back to 0 but a read of register 0x14 reflects the original value (0x08) instead of what I just assigned.
Any help is appreciated
The AD9467 needs the transfer bit to be set for the commands to take effect. after writing to all the required registers, you will need to write a 0x01 to register 0xFF. This should update the registers.
Hopefully this works. If you are able to read the contents from the SPI, there shouldnt be any difficulty in writing to it either.
Please read my entire post. I am doing precisely that. Can you think of any other reason that my configuration would fail to latch? Should I be able to read back my configuration values even before I latch?
The only other thing I can think of is the CSB signal. If the timing is as it is shown in the datasheet and AN-877, SPI should work
We now have the ADC configured correctly but the data is still incorrect. I started looking through the HDL code and I noticed that there is a delay primitive in the adc_if file that seems to be getting configured over the AXI bus. Currently my software lead is not writing anything to the adc peripheral over the axi bus. We started looking at the c code provided with the reference design and noticed a piece of code that is sending in delay commands and monitoring some sort of data from the adc block over the AXI interface. Could you describe to me what is taking place here. What is the software monitoring? What is the delay doing that the software is sending to the adc_if? Any help you can give is very appreciated.
The ADC can optionally send PRBS pattern as samples.
The software is adjusting the delay until the PRBS synchronizes inside the receiver.
OK, I figured it out. It was cockpit error. I was loading the command bits correctly but the data bits were being shifted out of range. Thus I was always writing 0.
Thank you for your help
Retrieving data ...