Hi Rurik, I have a question of the adc5g yellow block. I can meet the time requirement by relocating the adc pblock (ZDOK_0_1_1) in planahead (e.t. modify the .ucf constrain file), but I'm not sure if I'm allowed to do so. Maybe I should not move the pblocks, and come out other way to meet the timing.
Weiwei On Wed, Nov 6, 2013 at 10:11 AM, Primiani, Rurik <[email protected]>wrote: > Hi Weiwei, > > In most cases, as long as you run your design below the > successfully-compiled-for clock rate, i.e. the clock rate at which the > Xilinx tools have guaranteed timing for you, you should be okay. This > is complicated by the fact that the clock goes through an MMCM which > has various parameters that may not work at a lower rate. However for > the two clock-rates I mentioned before I have verified the ADC5g to > work correctly. Note: you may need to compile for slightly above 5400 > Msps because the Xilinx tools have issues with rounding clock periods. > In our test designs we use 5408 MHz which corresponds to an input > frequency of 2704 MHz (the value you put into the yellow block). > > I'll just reiterate that running the MMCM's PFD at an unapproved > frequency may present other problems in the future! Thankfully we > haven't run into any problems so far in our testing. > > Additionally if your design starts to use a significant amount of > resources you will start having trouble meeting timing.. just a > warning! > > Best, > Rurik > > On Wed, Nov 6, 2013 at 12:51 PM, Weiwei Sun <[email protected]> wrote: > > We are hoping to run it at 5GHz for the our need, so I'll try the option > 2 & > > 3 first. I have a question about the option 3: How does the fpga/adc > > actually work if the design and running are at different clock rate? > > > > Thanks very much Rurik! Your suggestions are really helpful to me to dig > > into the problem. > > > > Weiwei > > > > > > > > > > On Wed, Nov 6, 2013 at 8:31 AM, 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 > >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > > > > >
