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