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 <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>
