hi dale, your plan sounds good to me.
the adc08-5000 yellow block for roach2 demuxes by 16, so a 5Gsps sample rates means a 312.5 MHz FPGA rate. 312 MHz fpga rate is not easy to acheive - you need to learn how to use the plan ahead software, and you can't pack the fpga full. how many spectral channels do you want? their may be some roach2/adc08-5000 spectrometer designs you can use or adapt. if you are lucky, you can use a design as is, and not have to learn floor planning to get to 312 MHz clock rates. i think NRAO's DiBAS design (led by John Ford) uses a Roach2 board to sample a pair of ADC's at 5 Gsps, and one of the DiBAS modes does stokes spectroscopy. and Jack Hickish's AMI correlator also samples a pair of 5 Gsps ADC's using Roach2. best wishes, dan On Fri, Jan 24, 2014 at 4:30 PM, Gary, Dale E. <dale.e.g...@njit.edu> wrote: > Hi All, > > Could someone summarize this discussion for me re: the case I am > interested in, which is as follows? I have a need for a dual-pol > spectrometer covering an RF of at least 1-18 GHz (0.5-18 GHz is better). > From the discussion, it sounds like one option is to use the 1x5GSPs board > at 1:1 (8-bit) on ROACH-2, using two such ADCs per ROACH, giving 2.5 GHz > dual-polarization per ROACH. Using 7 such ROACH systems would cover 17.5 > GHz, with suitable downconversion upstream. However, it is likely that I > can only afford 4 ROACH-2s for the project, which would mean I would have > to time-multiplex to cover the band, but could then relax the clock speed > to 2.2 GHz and cover 2.2 GHz x 4 ROACH x 2 times = 17.6 GHz. > > Is this a viable solution? What is the FPGA clock speed resulting from > this? Is it 8 times less than the ADC clock speed? > > Thanks, > Dale > > > On Fri, Jan 24, 2014 at 7:04 PM, Dan Werthimer <d...@ssl.berkeley.edu>wrote: > >> >> >> you can probably to sample faster than 3.2Gsps 8 bit on a roach1 >> if you use the -2 speed grade fpga. you can look at the fpga >> data sheets to find their max lvds bit rate for the -1 and -2 speed >> grades. >> >> note that if you want to use the 5Gsps 4 bit ADC, that that's >> a different adc board - you can not make an 8 bit board into a 4 bit board >> or vice versa. order the one you need. >> >> i agree that if you want to sample 5Gsps 8 bits, the easiest thing to >> do is get a roach2 board. several people have developed instruments >> using a pair of 5 Gsps ADC's feeding a roach2. >> >> best wishes, >> >> dan >> >> >> On Fri, Jan 24, 2014 at 3:43 PM, Ross Williamson < >> rwilliam...@astro.caltech.edu> wrote: >> >>> 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) >>> >> >> >
