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 <jackhick...@gmail.com> 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 30000-30100 (etc.) ranges were for the > software calibration module). > > > On 4 June 2013 09:06, David MacMahon <dav...@astro.berkeley.edu> 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 2000000 1000000 >> qdr1_memory 3 3000000 1000000 >> >> ...to... >> >> qdr0_memory 3 2000000 800000 >> qdr1_memory 3 2800000 800000 >> >> 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 30000 100 >> qdr1_ctrl 3 30100 100 >> >> ...to... >> >> qdr0_ctrl 3 70000 10000 >> qdr1_ctrl 3 80000 10000 >> >> 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 >> >>> >> >>> >> >> >> >> >> >> >> > <test_2snapqdr.mdl> >> >> >> >
