> 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) >>>> >> >> >>>> > >>>> > >>>> >>> >>> >> >
