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