Hi Vereese, Adding an iadc block will (I think, having just checked the adc yellow block code) change the number or software devices on the OPB bus, so could affect the problem if Dave's first hypothesis is correct. Having said that, your test using sys_clk, as long as you left all the yellow blocks in your design the same, won't change the number of OPB devices so I think that exonerates the OPB bus. It seems to me that it's very unlikely that there's a problem that hasn't been noticed before that affects only certain OPB devices, and would show up at 155 MHz but not 100. Probably you already know this, but you should be able to clock off something close to your desired frequency by using sys_clk and setting the rate to 155. The toolflow will try to generate a clock of this frequency by multiplying/dividing the 100MHz onboard oscillator. I think the matlab prompt will print a line at the start of the compile telling you what clock speed it's managing to generate.
My inclination is to blame the yellow block - are all the clock constraints set up right? are there any MMCMs whose "locked" signals you can tie to software registers? If you run roach.est_board_clk() does it suggest your board is actually running at the speed you think? Cookie kebabs when you solve the problem, Jack On Wed, 5 Aug 2015 at 10:49 Vereese Van Tonder <vton...@nrao.edu> wrote: > Hi Andrew, Dave and Wes, > > Thanks for all the advice, I have a lot of things that I can test again > now. > > I'm currently using the casper_astro_soak_test mlib_devel repository, I'll > see the SKA-SA mlib_devel for the fix on the aux_clk. When I ran the > aux_clk design at 143MHz the XSG_core_config configured the MULTIPLY and > DIVIDE to be 8. It said the FVCO = 500MHz and it gave the formula as: > FVCO = (1000*CLKFBOUT_MULT_F)/(CLKIN1_PERIOD*DIVCLK_DIVIDE) > However the hard coded values for CLKFBOUT_MULT_F = 6, DIVCLK_DIVIDE = 1 > and using a CLK_FREQ = 143 then CLKIN1_PERIOD = 1000/143 ~ 6.99 then FVCO = > 858MHz and not 500MHz. > > I've only tested the design on one ROACH2 board, I'll test it with another > board as well. If I lower the input clock frequency to 145 MHz and then > turn it back up to 155.52 MHz then the output is as expected. > > I saw that the different brams are accessed via different opb's, however I > couldn't see any correlation between specific opb's and correct data from > the brams. I'll continue to compare these though. > > Thanks so much for everyone's help - I really appreciate it. > Vereese > > On 08/05/2015 04:21 AM, Wesley New wrote: > > The problem here is that the FVCO is not within the range of 600MHz to > 1600MHz. This is an MMCM configuration issue as Dave has already mentioned. > > I have recently fixed a similar bug in the SKA-SA mlib_devel repository. > Is this the repository that you are using? > > I have tested the aux clock on this repository between 100MHz and 200MHz. > > Thanks > > Wes > > > Wesley New > South African SKA Project > +2721 506 7300 > www.ska.ac.za > > > > On Tue, Aug 4, 2015 at 11:41 PM, David MacMahon <dav...@astro.berkeley.edu > > wrote: > >> Hi, Vereese, >> >> That's a very curious failure mode! It's very interesting that >> everything worked fine when clocking via iADC, but not when clocking via >> your mezzanine board (or aux_clk) even though the fabric clock rate was the >> same. I can think of two possible theories for what's going on (both >> alluded to in your email). >> >> The first theory is that the problem is somehow related to the address >> mapping. Maybe under certain circumstances the memory map works out such >> that bram7 is accessed via an extra opb_to_opb bridge (or some other slight >> variation) compared to the other brams? It would be interesting to compare >> the system.mhs and core_info.tab files for your various test builds so >> what's different between working builds and non-working builds. What if >> you add additional unrelated BRAMs such that they appear earlier in the >> address map (maybe give them a lexicographically "early" name like >> "aaa_bram0") or maybe enlarge the existing BRAMs? That might push bram6 >> (and others?) into the hypothetically troublesome address range. Maybe >> clocking from the iADC changed the address map such that this hypothesized >> problem was avoided. >> >> The other theory is that some sort of MMCM (mis-)configuration is causing >> the MMCM to behave in a weird way. I don't know what kind of problem that >> would be. I've only seen issues when trying to use the ISERDES resources >> at fairly high bit rates, but the ~155 MHz clock should be fine. I think >> the MMCM config options are shown in the system_map.mrp file, so maybe >> comparing working vs non-working versions of those files would be >> illuminating. >> >> When you tried to run aux_clk at faster than 143 MHz, what values did you >> use for MULTIPLY and DIVIDE? It looks like the defaults would result in >> the same settings as the hardcoded values (with the exception of CLKOUT5) >> . I think the MULTIPLY and DIVIDE parameters are intended to be used for >> sys_clk, so I'm not sure how they get set (or passed on) for aux_clk. >> >> Hope this helps, >> Dave >> >> On Aug 4, 2015, at 12:13 PM, Vereese Van Tonder wrote: >> >> > Hi Everyone, >> > >> > I'm clocking a ROACH2 design from a mezzanine board at 155.52MHz. In >> the design I have 8 bram's each with a 16 bit address width and data width. >> I'm writing the bram's address counter value into the bram, (so at the >> first address write 0, at the second address write 1, ... at the last >> address write 2^16-1). The output bram's 0-6 shows the expected linear >> relationship however bram7 does the following (also see attached .png's): >> > >> > Address 0-16387: expected linear relationship with gradient = 1 >> > Address 16388 - 20476 (diff=4088): the output toggles between the >> expected behavior and the following set >> (4,12,20,...,252,4,12,20,...,252,......4,12,....,252) >> > Address 20477 - 36867: expected linear relationship with gradient = 1 >> > Address 36868 - 40956 (diff=4088): the output toggles between the >> expected behavior and the following set >> (4,12,20,...,252,4,12,20,...,252,......4,12,....,252) >> > >> > The design works in simulation and when I clock the same design from >> the on board 100MHz system clock I don't get the problem anymore. I also >> saw that when I include only 7 brams and occupy the memory space >> 1020000-0103FFFF for bram0 ..... 01080000-0109FFFF for bram6 then I don't >> get the error but when I do include the 8th bram which occupies the space >> 010E0000-010FFFFF then I get the error. I'm unsure whether this is a memory >> problem or a clocking speed error. I also clocked the design off an iadc >> running at 4*155.52=622.08 MHz and then the design worked. >> > >> > Then I tried compiling a design that clocks from the aux_clk input and >> the design fails because the FVCO is out of range, I found the input limit >> to be 143MHz. From an earlier post I saw that Dave said the limit is >> between 100MHz-200MHz as there are some hard-coded parameters in the MMCM >> of the roach_infrastructure_v1_00_a pcore. I modified the MMCM_BASE_aux_clk >> instantiation to take the parameter values instead of having the hard coded >> values as follows: >> > >> > .CLKFBOUT_MULT_F (6), - .CLKFBOUT_MULT_F (MULTIPLY) >> > .CLKOUT1_DIVIDE (6), - .CLKOUT1_DIVIDE (DIVIDE), //THIS IS THE >> DIVISOR >> > .CLKOUT2_DIVIDE (6), - .CLKOUT2_DIVIDE (DIVIDE), >> > .CLKOUT3_DIVIDE (6), - .CLKOUT3_DIVIDE (DIVIDE), >> > .CLKOUT4_DIVIDE (6), - .CLKOUT4_DIVIDE (DIVIDE), >> > .CLKOUT5_DIVIDE (6), - .CLKOUT5_DIVIDE (DIVIDE/2), >> > .CLKOUT6_DIVIDE (6), - .CLKOUT6_DIVIDE (MULTIPLY/DIVCLK), >> > .DIVCLK_DIVIDE (1), - .DIVCLK_DIVIDE (DIVCLK), >> > >> > but it didn't solve the problem. Has anyone clocked a ROACH2 board from >> the aux_clk input at a frequency higher than 143MHz? >> > >> > Thanks, >> > Vereese >> > <all_brams.png><bram7.png><slx.png> >> >> >> > >
