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 <nshiv...@asu.edu>
Sent: Friday, March 6, 2015 11:20 AM
To: Brad Dober
Cc: Wesley New; Gard, Johnathon D.; johnathon.g...@gmail.com; 
casper@lists.berkeley.edu
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 
<do...@sas.upenn.edu<mailto:do...@sas.upenn.edu>> 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<tel:262-949-4668>

On Fri, Mar 6, 2015 at 2:56 AM, Wesley New 
<wes...@ska.ac.za<mailto:wes...@ska.ac.za>> 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<tel:%2B2721%20506%207300>
www.ska.ac.za<http://www.ska.ac.za>



On Fri, Mar 6, 2015 at 2:54 AM, Gard, Johnathon D. 
<johnathon.g...@nist.gov<mailto:johnathon.g...@nist.gov>> 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:nshiv...@asu.edu<mailto:email%3anshiv...@asu.edu>

Reply via email to