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