Re: [casper] Tutorial 3 Calibration Problems
hi tim, i suggest you phase lock your 20 MHz generator to the frequency synthesizer that's generating the adc clock, and setting the input frequency to the exact center of a spectral bin. (that insures that every spectra will have the same exact and integer number of sine waves in it). for example, if you are sampling at 1 Gsps, and you have 1024 spectral bins over a 500 MHz band, then each spectral bin is 488,281 Hz wide, so you should set your input frequency to 19.53125 MHz, which will be the center of bin 40. best wishes, dan On Tue, Jun 4, 2013 at 3:43 PM, Timothy L. Madden wrote: > Hi All, > > I am working with the Phil Lubin's Deepspace group at UCSB on a ROACH > based spectrometer. I have been testing tutorial 3 using a 1 Volt > peak to peak sine wave with a frequency of 20 MHz. When set the gain > to a reasonable level it outputs a sharp peak in a consistent > location, but the amplitude of the peak changes quite a bit (on the > order of 10%) between accumulations. I just wanted to know if this > was normal, as it makes calibration irritating to say the least. I am > using a revision A ADC2x1000-8. > > > Thank you for your time, > > Luke Madden >
[casper] Tutorial 3 Calibration Problems
Hi All, I am working with the Phil Lubin's Deepspace group at UCSB on a ROACH based spectrometer. I have been testing tutorial 3 using a 1 Volt peak to peak sine wave with a frequency of 20 MHz. When set the gain to a reasonable level it outputs a sharp peak in a consistent location, but the amplitude of the peak changes quite a bit (on the order of 10%) between accumulations. I just wanted to know if this was normal, as it makes calibration irritating to say the least. I am using a revision A ADC2x1000-8. Thank you for your time, Luke Madden
Re: [casper] QDR problems
Checked in to casper_vanilla branch of https://github.com/oxfork/mlib_devel/tree/casper_vanilla which is almost identical to the main casper repo but with a few bug fixes (i.e., it "should" merge easily). I've just compiled the design you emailled and identical stuff is coming out of both QDR blocks. FWIW, the qdrX_ctrl addresses were already updated a few months ago (there was an email thread about it iirc) but never propagated to casper-astro. Cheers, Jack On 4 June 2013 09:40, Jack Hickish wrote: > Hullo, > > So first of all -- That appears to be my commit, so sorry. I'll fix it in > the vanilla fork of the oxford github repo when i get into work this > morning. > > FWIW, I believe core_info.tab on ROACH2 also has control addresses which > are wrong. Or rather, are out of date now the ROACH2 QDR module has > hardware link calibration. (the 3-30100 (etc.) ranges were for the > software calibration module). > > > On 4 June 2013 09:06, David MacMahon wrote: > >> Thanks, Pam, >> >> The problem appears limited to the CPU interface of QDR1 on ROACH1. It >> appears you are the first ones to use the CPU interface of QDR1 on ROACH1 >> with an mlib_devel on or after commit 1cfc60ea from 2012-02-03 (lucky >> you!). In that commit, the QDR's system.mhs generation script changed the >> base address of the CPU interface for QDR1 on both ROACH and ROACH2. The >> core_info.tab template for ROACH2 was changed accordingly, but the >> core_info.tab template for ROACH1 was not so lucky. >> >> Until this gets fixed in mlib_devel, you can fix your existing BOF files >> by manually editing the core_info.tab file generated for your design. >> Change the lines: >> >> qdr0_memory 3 200 100 >> qdr1_memory 3 300 100 >> >> ...to... >> >> qdr0_memory 3 200 80 >> qdr1_memory 3 280 80 >> >> Note that the final field of the qdr0_memory line changed and the final >> two fields of the qdr1_memory line changed. >> >> I think the qdr0_ctrl and qdr1_ctrl lines are also wrong. I think they >> should be changed from: >> >> qdr0_ctrl 3 3100 >> qdr1_ctrl 3 30100100 >> >> ...to... >> >> qdr0_ctrl 3 71 >> qdr1_ctrl 3 81 >> >> After making these changes, re-run gen_prog_files to create a new bof >> file. The good news is that this takes just seconds since the FPGA >> bitstream does not need to be rebuilt. >> >> Dave >> >> On Jun 3, 2013, at 9:20 AM, Pam Ford wrote: >> >> > Model attached. Identical inputs go to two "snapqdr" blocks (snapshot >> blocks >> > using qdr instead of bram), one assigned to qdr0 and one assigned to >> qdr1. If >> > you run "hd qdr0_memory" you get data but "hd qdr1_memory" is all zeros >> on our >> > systems. >> > >> > Pam Ford >> > >> > On Mon, June 3, 2013 11:55 am, John Ford wrote: >> >>> Hi, John, >> >>> >> >>> On Jun 3, 2013, at 6:03 AM, John Ford wrote: >> >>> >> > We use both simultaneously quite reliably on KAT-7. I'm not aware of >> > any >> > issues. >> > >> > Have you tried another ROACH board? >> >> Yes, three different ones exhibit the same problem. Here's the >> library >> we >> have: >> >> Yes, Master<1017> git describe --always >> last_ibob_bee2_support-87-g29edeea >> >>> >> >>> We've got to start using more tags! :-) This means that you are using >> >>> commit 29edeea, which is 87 commits after the tag >> >>> "last_ibob_bee2_support". >> >>> >> >>> This is a rather recent version. I'm not aware of any ROACH1 changes >> >>> since then that would affect QDR behavior. Can you boil the problem >> down >> >>> to a minimalistic test model that demonstrates the problem? >> >> >> >> I will get one posted. >> >> >> >>> >> Yes, Master<1018> git log -l >> >>> >> >>> You probably wanted a -1 there rather than a -l. >> >> >> >> Yeah, no kidding. The only thing more complicated than the casper >> tools >> >> is git. :) >> >> >> >> John >> >> >> >>> Dave >> >>> >> >>> >> >> >> >> >> >> >> > >> >> >> >
Re: [casper] QDR problems
Hullo, So first of all -- That appears to be my commit, so sorry. I'll fix it in the vanilla fork of the oxford github repo when i get into work this morning. FWIW, I believe core_info.tab on ROACH2 also has control addresses which are wrong. Or rather, are out of date now the ROACH2 QDR module has hardware link calibration. (the 3-30100 (etc.) ranges were for the software calibration module). On 4 June 2013 09:06, David MacMahon wrote: > Thanks, Pam, > > The problem appears limited to the CPU interface of QDR1 on ROACH1. It > appears you are the first ones to use the CPU interface of QDR1 on ROACH1 > with an mlib_devel on or after commit 1cfc60ea from 2012-02-03 (lucky > you!). In that commit, the QDR's system.mhs generation script changed the > base address of the CPU interface for QDR1 on both ROACH and ROACH2. The > core_info.tab template for ROACH2 was changed accordingly, but the > core_info.tab template for ROACH1 was not so lucky. > > Until this gets fixed in mlib_devel, you can fix your existing BOF files > by manually editing the core_info.tab file generated for your design. > Change the lines: > > qdr0_memory 3 200 100 > qdr1_memory 3 300 100 > > ...to... > > qdr0_memory 3 200 80 > qdr1_memory 3 280 80 > > Note that the final field of the qdr0_memory line changed and the final > two fields of the qdr1_memory line changed. > > I think the qdr0_ctrl and qdr1_ctrl lines are also wrong. I think they > should be changed from: > > qdr0_ctrl 3 3100 > qdr1_ctrl 3 30100100 > > ...to... > > qdr0_ctrl 3 71 > qdr1_ctrl 3 81 > > After making these changes, re-run gen_prog_files to create a new bof > file. The good news is that this takes just seconds since the FPGA > bitstream does not need to be rebuilt. > > Dave > > On Jun 3, 2013, at 9:20 AM, Pam Ford wrote: > > > Model attached. Identical inputs go to two "snapqdr" blocks (snapshot > blocks > > using qdr instead of bram), one assigned to qdr0 and one assigned to > qdr1. If > > you run "hd qdr0_memory" you get data but "hd qdr1_memory" is all zeros > on our > > systems. > > > > Pam Ford > > > > On Mon, June 3, 2013 11:55 am, John Ford wrote: > >>> Hi, John, > >>> > >>> On Jun 3, 2013, at 6:03 AM, John Ford wrote: > >>> > > We use both simultaneously quite reliably on KAT-7. I'm not aware of > > any > > issues. > > > > Have you tried another ROACH board? > > Yes, three different ones exhibit the same problem. Here's the > library > we > have: > > Yes, Master<1017> git describe --always > last_ibob_bee2_support-87-g29edeea > >>> > >>> We've got to start using more tags! :-) This means that you are using > >>> commit 29edeea, which is 87 commits after the tag > >>> "last_ibob_bee2_support". > >>> > >>> This is a rather recent version. I'm not aware of any ROACH1 changes > >>> since then that would affect QDR behavior. Can you boil the problem > down > >>> to a minimalistic test model that demonstrates the problem? > >> > >> I will get one posted. > >> > >>> > Yes, Master<1018> git log -l > >>> > >>> You probably wanted a -1 there rather than a -l. > >> > >> Yeah, no kidding. The only thing more complicated than the casper tools > >> is git. :) > >> > >> John > >> > >>> Dave > >>> > >>> > >> > >> > >> > > > > >
Re: [casper] QDR problems
Thanks, Pam, The problem appears limited to the CPU interface of QDR1 on ROACH1. It appears you are the first ones to use the CPU interface of QDR1 on ROACH1 with an mlib_devel on or after commit 1cfc60ea from 2012-02-03 (lucky you!). In that commit, the QDR's system.mhs generation script changed the base address of the CPU interface for QDR1 on both ROACH and ROACH2. The core_info.tab template for ROACH2 was changed accordingly, but the core_info.tab template for ROACH1 was not so lucky. Until this gets fixed in mlib_devel, you can fix your existing BOF files by manually editing the core_info.tab file generated for your design. Change the lines: qdr0_memory 3 200 100 qdr1_memory 3 300 100 ...to... qdr0_memory 3 200 80 qdr1_memory 3 280 80 Note that the final field of the qdr0_memory line changed and the final two fields of the qdr1_memory line changed. I think the qdr0_ctrl and qdr1_ctrl lines are also wrong. I think they should be changed from: qdr0_ctrl 3 3100 qdr1_ctrl 3 30100100 ...to... qdr0_ctrl 3 71 qdr1_ctrl 3 81 After making these changes, re-run gen_prog_files to create a new bof file. The good news is that this takes just seconds since the FPGA bitstream does not need to be rebuilt. Dave On Jun 3, 2013, at 9:20 AM, Pam Ford wrote: > Model attached. Identical inputs go to two "snapqdr" blocks (snapshot blocks > using qdr instead of bram), one assigned to qdr0 and one assigned to qdr1. If > you run "hd qdr0_memory" you get data but "hd qdr1_memory" is all zeros on our > systems. > > Pam Ford > > On Mon, June 3, 2013 11:55 am, John Ford wrote: >>> Hi, John, >>> >>> On Jun 3, 2013, at 6:03 AM, John Ford wrote: >>> > We use both simultaneously quite reliably on KAT-7. I'm not aware of > any > issues. > > Have you tried another ROACH board? Yes, three different ones exhibit the same problem. Here's the library we have: Yes, Master<1017> git describe --always last_ibob_bee2_support-87-g29edeea >>> >>> We've got to start using more tags! :-) This means that you are using >>> commit 29edeea, which is 87 commits after the tag >>> "last_ibob_bee2_support". >>> >>> This is a rather recent version. I'm not aware of any ROACH1 changes >>> since then that would affect QDR behavior. Can you boil the problem down >>> to a minimalistic test model that demonstrates the problem? >> >> I will get one posted. >> >>> Yes, Master<1018> git log -l >>> >>> You probably wanted a -1 there rather than a -l. >> >> Yeah, no kidding. The only thing more complicated than the casper tools >> is git. :) >> >> John >> >>> Dave >>> >>> >> >> >> >
