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 <http://www.ska.ac.za>
On Tue, Aug 4, 2015 at 11:41 PM, David MacMahon
<[email protected] <mailto:[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>
