Hi Gard Johnathon, These numbers worked with the 512 Mhz. Thanks. I remember trying these combinations before. but during that time my bandwidth was set to Optimized and I was getting weird data from the ADC. Now that the bandwidth is set to high the adc samples looks good.
And I was not running the entire firmware at 480Mhz. I was running it at 240 Mhz. thanks and regards, Nishanth On Tue, Mar 10, 2015 at 2:07 PM, G Jones <[email protected]> wrote: > Hi Jonathon, > Are you able to share your state machine that moves data from 10 GbE to > DRAM? Sounds useful! > > Thanks, > Glenn > > On Tue, Mar 10, 2015 at 5:04 PM, Gard, Johnathon D. < > [email protected]> wrote: > >> Hello Everyone, >> >> >> Just an update on what I have worked out. Thank you Wesely New for the >> idea, that worked once I got the correct multipliers and dividers in the >> >> instantiation of the MMCM. To get the correct numbers, I created an ISE >> project and IP Core project (you may not need the ISE project to create the >> IP Core project, but I am just starting with ISE) and created an MMCM IP >> core and pulled the values out of that. For instance, we are running the >> MKID ADC/DAC board at 512 MHz, the clock we are syncing to is half of that, >> 256MHz , so we want a 1 to 1 MMCM: >> >> CLKFBOUT_MULT_F = 8.00 >> >> DIVCLK_DIVIDE = 2 >> >> CLKIN1_PERIOD = 4.00 >> >> CLKOUT0_DIVIDE_F = 4.00 >> >> CLKOUT1_DIVIDE = 4 >> >> CLKOUT2_DIVIDE = 4 >> >> CLKOUT3_DIVIDE = 4 >> >> >> I hope this helps. I have done a loop test of sending a signal into the >> ADC and then just passing it through the FPGA back out to the DAC and on a >> oscilloscope I do not see anything unusual except for the digitization >> noise. >> >> >> Running the entire firmware to 480MHz is rather impressive. I would >> imagine you are running into timing issues beyond that which is not at all >> surprising. Unless you meant the ADC/DAC running at 480MHz and the FPGA >> itself being clocked at 240MHz. >> >> >> At the moment I have written a state machine to interface between the >> 10Gbe rx port and the DDR3 DRAM block. This is a work around for the PPC to >> DRAM interface. I guess it also opens up the ability to send data to the >> ROACH2 over the 10Gbe link. Our link is only sending data to the PC it is >> connected to. >> >> >> I hope this helps. >> >> >> Johnathon Gard >> >> National Institute of Standards and Technology >> >> Quantum Sensors Project >> >> >> >> ------------------------------ >> *From:* Nishanth Shivashankaran <[email protected]> >> *Sent:* Friday, March 6, 2015 11:20 AM >> *To:* Brad Dober >> *Cc:* Wesley New; Gard, Johnathon D.; [email protected]; >> [email protected] >> *Subject:* Re: [casper] ROACH2 MKID Block and DDR3 DRAM >> >> Hi All, >> >> I have replaced the DCM with the MMCM, and the firmware works till >> about 480MHz. I tried to play with other multipliers and dividers values, I >> get it to compile for higher frequencies but the ADC data gets clipped when >> I set the value of the DIVCLK_DIVIDE greater than 1. If anyone can tell me >> why the ADC samples has a clipped waveform when I set it to greater than 1, >> I would really appreciate it. Currently, I am trying to figure out a way to >> use two MMCM's and play with 2 sets of multiplier and divider to see if it >> gets rid of the weird clipping problem so that I can clock it greater than >> 500Mhz. >> >> The files attached has the value of DIVCLK_DIVIDE set to 1 and the >> Firmware codes compile to about 480 MHz and there is no clipping observed. >> >> Warm regards, >> Nishanth >> >> On Fri, Mar 6, 2015 at 9:48 AM, Brad Dober <[email protected]> wrote: >> >>> Nishanth at ASU has been working on getting the MKID ADC/DAC working on >>> the ROACH2. >>> >>> The DAC is fully functional, and the ADC works up to CLK frequency of >>> 480 MHz, then some NCO clock errors pop up. >>> >>> We are also interested in the PPC interface to the DRAM. >>> Feel free to contact Nishanth and I to talk about this further. >>> >>> >>> Brad Dober >>> Ph.D. Candidate >>> Department of Physics and Astronomy >>> University of Pennsylvania >>> Cell: 262-949-4668 >>> >>> On Fri, Mar 6, 2015 at 2:56 AM, Wesley New <[email protected]> wrote: >>> >>>> Hi Johnathan. >>>> >>>> I can point you in the right direction for the first issue you are >>>> having. It seems that no one has used that ADC on a ROACH2 before so you >>>> will need to migrate the core to support Virtex 6. This is probably just a >>>> replacement of the DCM with and MMCM, but there may be other issues. >>>> >>>> You will need to edit this file: >>>> >>>> >>>> https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/pcores/adc_mkid_interface_v1_00_a/hdl/vhdl/adc_mkid_interface.vhd >>>> >>>> The DCM is at the end of the file. >>>> >>>> You can see how the MMCM has been setup in the MKADC here: >>>> >>>> >>>> https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/pcores/mkadc_interface_v1_00_a/hdl/vhdl/adc5g_dmux1_interface.vhd >>>> >>>> For more info on the MMCM see the Xilinx Clocking Resource users >>>> guide. >>>> >>>> Regards >>>> >>>> Wesley >>>> >>>> >>>> Wesley New >>>> South African SKA Project >>>> +2721 506 7300 >>>> www.ska.ac.za >>>> >>>> >>>> >>>> On Fri, Mar 6, 2015 at 2:54 AM, Gard, Johnathon D. < >>>> [email protected]> wrote: >>>> >>>>> Hello Everyone, >>>>> >>>>> I have a series of questions concerning the ROACH2 system and tool >>>>> flow. >>>>> >>>>> OS = Ubuntu 14.04.2 LTS >>>>> >>>>> Tool flow = ISE 14.7, MATLAB R2012b, mlib-devel-master (casper-astro >>>>> git clone) >>>>> >>>>> Hardware = MUSIC ADC/DAC board and MUSIC IF_Board from Techne >>>>> Instruments (Rich Raffanti) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> First thing, syncing the FPGA clock to the ADC/DAC clock. Using the >>>>> mkid adc or dac blocks from the xps library and selecting any one of the >>>>> adc0_clk, adc1_clk, dac0_clk, or dac1_clk settings in the xsg_core_config >>>>> results in errors in the compilation. There are usually one of two errors >>>>> the come up “Cannot retarget DCM to MMCM” because of VCO frequencies being >>>>> out of range or an input period of 0.00ns for the DCM. Looking at the >>>>> Xilinx forums, they generally do not recommend letting the toolflow >>>>> upgrade >>>>> the DCM to a MMCM. There are a lot of complications that arise from this. >>>>> I >>>>> was wondering if anyone has a block set were they have already fixed this >>>>> problem and have been able to use an external clock from the ZDOK >>>>> connectors. >>>>> >>>>> >>>>> >>>>> I, at one point, found an email on the CASPER archive about this same >>>>> problem and downloaded the attached block set. However this did not work >>>>> either. I really wish I could find this email again. >>>>> >>>>> >>>>> >>>>> Another question I had was about the DDR3 DRAM. >>>>> >>>>> >>>>> >>>>> http://www.mail-archive.com/casper%40lists.berkeley.edu/msg04323.html >>>>> >>>>> >>>>> >>>>> I was if anyone has tried to change the IDELAYCTRL frequency so that >>>>> the RAM can run at a higher clock speed. This work may be able to be tied >>>>> into the PPC interface work or error free work from the following email. >>>>> >>>>> >>>>> >>>>> http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05670.html >>>>> >>>>> >>>>> >>>>> I would be more than happy to try and help with this. I have an >>>>> interest in the PPC interface but error free operation is more critical. >>>>> >>>>> >>>>> >>>>> Johnathon Gard >>>>> >>>>> National Institute of Standards and Technology >>>>> >>>>> Quantum Sensors Project >>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Nishanth Shivashankaran >> Arizona State University >> Phone:-480-246-6866 >> Email:[email protected] >> > > -- Nishanth Shivashankaran Arizona State University Phone:-480-246-6866 Email:[email protected]
