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 <[email protected]> > 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 <[email protected]>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 <[email protected]> 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 <[email protected]> >> wrote: >> >> >> >> On 15 January 2014 16:28, Primiani, Rurik <[email protected]> >> >> 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 <[email protected] >> > >> >> > 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 >> >> >> <[email protected]> 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 < >> [email protected]> >> >> >>> 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 < >> [email protected]> >> >> >>>> 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 <[email protected]> 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 >> >> >>>>>> <[email protected]> >> >> >>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> Hi, >> >> >>>>>>> >> >> >>>>>>> Which version of mlib_devel are you using? >> >> >>>>>>> >> >> >>>>>>> Rurik >> >> >>>>>>> >> >> >>>>>>> On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun <[email protected]> >> 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) >> >> >> >> > >> > >> > >
