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