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>
