Hi Ross,
Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1)
pocket correlator compiled, and the final piece of the puzzle was
getting the ADCs running properly (I only got hold of the hardware
relatively recently). But it's always reassuring to know someone else
is using a similar system with success!
For anyone that's interested, I think I may have solved my problem. I
changed the adc interface to use SERDES blocks in oversampling mode,
which allowed me to dispense with the high frequency MMCM output.
Without this troublesome output, the MMCM can be set into high
bandwidth mode and the data capture seems to perform much more
happily.
After this mod, and setting the IODELAY blocks appropriately, the ADC
appears to be capturing data happily without any problems....
Cheers,
Jack
On 14 January 2014 18:18, Ross Williamson <rwilliam...@astro.caltech.edu> wrote:
> Hi Jack,
>
> Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator
> on a ROACH-1. The only think I would say is that I've put a fair
> amount of effort in planahead to try and get 5GSPS. I'm sure it could
> be done and I've thought I've got close a number of times but in the
> end I've just eaten that 500MHz of BW as too much effort for the
> little gain it gives in receiver noise. I would say that on a
> Roach-1, two boards at 5GSPS (4-bit) works fine if you are just
> dumping data to a snapshot. I believe a ROACH-2 is harder to reach
> timing.
>
> Ross
>
> On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish <jackhick...@gmail.com> wrote:
>> Hi all,
>>
>> Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a
>> simple ADC to snap model, and (as Rurik warned) getting reliable data
>> capturing is difficult at this speed. I've tried per-bit calibration
>> of input data streams via IODELAYs in conjunction with phase-shifting
>> of the sampling clock, but can't seem to achieve glitchless data
>> capture for any reasonable length of time.
>>
>> In the email I'm replying to, Rurik suggests a number of ways around
>> this problem, but before I opt for forcing an unsupported MMCM mode by
>> compiling and running at different speeds, I thought a final desperate
>> plea for any advice on the maillist might be worthwhile. If anyone has
>> any words of wisdom, I'd be excessively grateful to hear from them.
>>
>> Cheers,
>>
>> Jack
>>
>> On 6 November 2013 16:31, Primiani, Rurik <rprimi...@cfa.harvard.edu> wrote:
>>> Hi Weiwei,
>>>
>>> Generally the sma-wideband/mlib_devel has the most recent changes to
>>> the ADC5g yellow block, please use the latest commit of that repo (at
>>> this moment it is 2c80cb2).
>>>
>>> The problem your are seeing is related to a change that was introduced
>>> in the Xilinx tools (I believe from version 11 to 12) that increased
>>> the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125
>>> MHz in HIGH bandwidth mode. This made it no longer possible to clock
>>> the fabric from an ADC5g running at >4800 Msps using an MMCM in HIGH
>>> bandwidth mode.
>>>
>>> There are a few options for moving forward (ordered by ease of
>>> implementation):
>>>
>>> 1. Clock the ADC below (and not including) 2400 MHz
>>> 2. Change MMCM from HIGH to LOW bandwidth mode
>>> 3. Compile your design with the ADC clocked above (and not including)
>>> 5400 MHz, but actually run it at 5 GHz
>>> 4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH
>>> bandwidth mode
>>> 5. Compile your design using the Xilinx 11 tools
>>>
>>> If you don't need to sample at exactly 5 Gsps then option 1 is the
>>> optimal solution. If 5 Gsps is critical then you can go with options 2
>>> or 3. Option 2 has non-ideal clock-to-out timing and may cause
>>> problems when trying to calibrate out jitter due to the data
>>> capturing. Option 3 may cause timing problems since your fabric clock
>>> will run at >337.5 MHz. I have not found a way to implement option 4
>>> but I can't see why this shouldn't be possible. Finally option 5 may
>>> or may not be useful to you.
>>>
>>> The SMA wideband correlator runs its ADCs below 4800 Msps. However we
>>> have bitcodes that we use to characterize the ADC that run at 5 Gsps
>>> and which have low resource utilization. For what it's worth we used
>>> option 3 to get around this issue and this appears to work for us.
>>> Whatever reason Xilinx had for changing the minimum PFD frequency to
>>> 135 MHz does not seem to cause problems for us.
>>>
>>> Hope this helps,
>>> Rurik
>>>
>>>
>>>
>>> On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun <su...@uw.edu> wrote:
>>>> I tried the casper-astro, ska-sa, sma-wideband. None of them seemly works.
>>>>
>>>> Weiwei
>>>>
>>>>
>>>> On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik
>>>> <rprimi...@cfa.harvard.edu>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Which version of mlib_devel are you using?
>>>>>
>>>>> Rurik
>>>>>
>>>>> On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun <su...@uw.edu> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I have trouble to compile the adc clock rate of asiaa_adc5g block at
>>>>> > 2500MHz.
>>>>> > Block parameter: two-channel, ZDOK0, demux 1:1 .
>>>>> > System: roach2, clock source:adc0_clk, clock rate: 312.5MHz)
>>>>> >
>>>>> > The error is as follows:
>>>>> >
>>>>> > Creating block object: xps_adc5g
>>>>> > Problem with block: lab_test_adv5/asiaa_adc5g1
>>>>> > : An optimum PLL solution is not available!
>>>>> > Backtrace 1: xps_adc5g:175
>>>>> > Backtrace 2: gen_xps_files:229
>>>>> > Backtrace 3: run_Callback:149
>>>>> > Backtrace 4: casper_xps:82
>>>>> > Backtrace 5:
>>>>> >
>>>>> > @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
>>>>> > Error using gen_xps_files (line 242)
>>>>> > Error found during Object creation.
>>>>> >
>>>>> > There are a bunch of frequency justification in the xps_adc5g.m that I
>>>>> > just
>>>>> > can't understand. Could some one give me some suggestions on the error
>>>>> > or
>>>>> > the codes? Does it mean that the 5G adc can't run at 2.5GHz?
>>>>> >
>>>>> > Any help or suggestions are very appreciated!
>>>>> >
>>>>> > Weiwei
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>
>>>>
>>>
>>
>
>
>
> --
> Ross Williamson
> Research Scientist - Sub-mm Group
> California Institute of Technology
> 626-395-2647 (office)
> 312-504-3051 (Cell)
