Hi Weiwei,
I'll leave it up to Rurik to merge or not the changes into
sma-wideband, but in the meantime, the changes (along with LOTS of
other modifications to other parts of the library) are in my repo at
https://github.com/jack-h/mlib_devel
Alternatively, if you've got the latest mlib_devel from sma-wideband,
you can apply the patch I emailed using the command (run within the
repository)
git apply /path/to/adc5g-mmcm.patch
Cheers,
Jack
On 15 January 2014 20:24, Weiwei Sun <su...@uw.edu> wrote:
> Hi Jack and Rurik,
>
> I'm very excited to hear that the adc could run at exact 5GSPS mode (2
> channels, demux 1:1) . I'd like to follow the modification, but the vhdl is
> something that I'm not familiar. I wonder if it is possible that the module
> could be merged into the sma-wideband github, or help with some more details
> to instruct me to make the modification. That would be a BIG help for my
> project. Thanks!
>
> Best,
>
> Weiwei
>
>
> On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish <jackhick...@gmail.com> wrote:
>>
>> On 15 January 2014 16:28, Primiani, Rurik <rprimi...@cfa.harvard.edu>
>> wrote:
>> > Hi Jack,
>> >
>> > Great work! The oversample mode is not something I realized existed!
>>
>> Me neither -- I eventually stumbled across it in the SelectIO
>> Resources guide. (Where the order of the SERDES module outputs are
>> documented wrongly, just for extra fun)
>>
>> >
>> > Previously when we've been able to get the tools to use HIGH bandwidth
>> > mode we could get away with just shifting the MMCM clock phase to
>> > remove glitches on the interface (i.e. no IODELAY adjustments). Have
>> > you tried just doing that?
>>
>> I've run your calibration routine to look at the glitches vs. phase
>> values and it seems to find reasonably wide glitchless regions. But I
>> find the differences between the "slowest" and "fastest" bits from the
>> ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a
>> per-bit calibration anyway.
>> With IODELAY calibration only (without bothering with the MMCM phase)
>> so far I haven't had any glitches in 2 hours of running. Strangely,
>> when I ran the MMCM phasing calibration after IODELAY cal, things got
>> worse, but I've been wildly hacking software, so there's a very
>> reasonable chance I've broken something. I'll look into this after
>> I've let my current glitch counting test run for a bit longer.
>>
>>
>> >
>> > I'd like to merge your change into sma-wideband, could you perhaps
>> > send me a Github pull request?
>>
>> Our git repos seem to have diverged quite a lot, but I've attached a
>> patch to peruse/edit/merge at your leisure. Obviously, YMMV :)
>>
>> Cheers,
>> Jack
>>
>>
>> >
>> > Thanks!
>> > Rurik
>> >
>> > On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish <jackhick...@gmail.com>
>> > wrote:
>> >> 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)
>> >>
>
>
