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 <[email protected]> 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> > > >
