The roach 1 will only work at the speeds you are interested at with the dmux 2:1 option at 4 bits. I think the max speed at 8 bits is about 3.2GSPS and that is due to the ZDOK interface.
I'm sure with significant effort in planahead you could achieve 5GSPS on a low resolution correlator in a ROACH-1 (I have it working at 4GSPS). My advice would be to just go the ROACH-2 route and eat the cost - I believe there are correlator designs already working out there at 5GSPS using an adc5g on a ROACH2 On Fri, Jan 24, 2014 at 8:19 AM, John Ford <jf...@nrao.edu> wrote: >> i suggest you contact mo ohady at digicom electronics >> for pricing and availability of adc's and roach boards. >> m...@digicom.org >> >> casper collaborators might already have a design similar to >> what you need. >> are you building a correlator? or a spectrometer? >> how many frequency channels? how many adc inputs? >> readout rate? full stokes? >> >> it might be hard to get the roach1 to sample all the way up to 5 Gsps. >> it's been accomplished by several people on roach2, but i don't know >> anyone that has a roach1 and adc08-5000 working at 5 Gsps. > > Agreed, although I think it would be easy to port a working spectrometer > with an iADC to use the 5gs sampler sampling at only 800 MS/s. > > Using it in the demux x8 it should work fine. the demux x16 is more of a > problem for roach1 due to routing resource usage, I think. > > John > >> >> best wishes, >> >> dan >> >> On Fri, Jan 24, 2014 at 2:16 AM, Marco Bartolini >> <mbartol...@med.ira.inaf.it >>> wrote: >> >>> Hi everyone, >>> from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 >>> bit without a great effort in the design phase. >>> I'd like to understand how portable would it be a design using >>> roach1+iADC >>> with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, >>> just by encreasing the processed bandwidth and tweaking the necessary >>> bits >>> in the model file like the number of parallel streams ecc... >>> >>> Also, can anyone provide informations about pricing and availability of >>> these high freq samplers? >>> >>> thanks for the info >>> cheers >>> Marco >>> >>> >>> >>> 2014/1/15 Weiwei Sun <su...@uw.edu> >>> >>>> Oh, that's clear! I followed it and got the design compiled >>>> successfully >>>> in Simulink. Thanks Jack! >>>> >>>> Best, >>>> >>>> Weiwei >>>> >>>> >>>> On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish >>>> <jackhick...@gmail.com>wrote: >>>> >>>>> 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) >>>>> >> >> >>>>> > >>>>> > >>>>> >>>> >>>> >>> >> > > > -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
