Changing FIC0 clock freq in mpfs_dma_benchmarking of LSRAM

[Kian-KH]

I'm running the mpfs_dma_benchmarking bare metal example (on top of MPFS_ICICLE ref design generated with only MSS_BAREMETAL arg, Libero 2022.3) and it runs smoothly. I specifically want to run (and improve) the LSRAM involved PDMA performance (e.g. non-cached DDR to LSRAM), so I gradually increased the ACLK frequency going into FIC_0_PERIPHERALS from 125 MHz up to 250 MHz, modified the .sdc constraint (generated clock) accordingly, and reprogrammed the FPGA. However, the verify() function in the bare metal example app produces "Benchmarking Tests FAILED!" after changing the FIC0 ACLK to any value higher than 150 MHz (150 MHz passes). According to the note below Table 6-1 on page 120 of the TRM: "If the frequency of the FIC block is greater than or equal to 125 MHz, then the DLL must be enabled for removing clock insertion delay. If the frequency of the FIC block is less than 125 MHz, then the DLL must be bypassed". In my reference design, the Use Embedded DLL checkbox for FIC0 is checked. Also, the lowest FMAX of LSRAM in Table 80 of PolarFire SoC Advanced Datasheet is 196 MHz. Therefore, I don't see why I can't set FIC0 freq to values higher than 150 MHz. Help!
(P.S. I also couldn't set the LSRAM depth to more than 131072. It's the PF_SRAM_AHBL_AXI in the ref design named "MSS_LSRAM" in FIC0).
I've also seen FIC1-3 frequencies automatically change whenever I modify FIC0's freq to values like 140 MHz, which causes FIC1 & 2 to be set to 140 MHz and FIC3 to 33.33 MHz.

[hughbreslin]

Have you run verify timing when you've changed the clock configuration? Tbh I'd recommend adjusting the required clocks from the configurator of the PF_CCC in the "CLOCKS_AND_RESETS" block and then deriving the constraints instead of modifying the derived file directly.

I don't think the issue here is the FIC DLL, its on by default as we run at 125MHz in the base so going higher you shouldn't have to change it.

The FIC frequencies changing is odd, I've never seen this happen.. they're all independent outputs of the CCC/PLL so they shouldn't be affected when you change just one clock.. again I'd go through the configurator + derive and see what it does.

[Kian-KH]

Hi Hugh, I did go through the CCC GUI. Here's the sequence of events I encounter: I open the CCC GUI, FIC0-2 are all 125 and FIC3 is 50, as soon as I change FIC0 to 140, the "Actual Higher" fields of FIC1 & 2 will show 140, and FIC3 will show 33.333. I then go to the constraints manager and see a caution mark there, which means the derived timing constraints need to be regenerated. Before the change, the FIC clock dividers are all "multiply by 5 and divide by 2" and FIC3 is "divide by 1". But after regeneration, FIC0-2 are all "multiply by 14 and divide by 5", and FIC3 is "multiply by 2 and divide by 3". It's as if the "Actual Higher" values in the CCC GUI are taken into effect (for FIC1-3).

[hughbreslin]

Ahhh ok I see now, its this:

We can't solve this with the base design, you'll need to make a modification.

Leave the original CCC (CCC_FIC_X_CLK) as is and disconnect OUT0_FABCLK_0 (the output for FIC0) from the RESET_FIC_0_CLK block and the top level port called FIC_0_CLK and disconnect the PLL_LOCK input to the RESET_FIC_0_CLK block. Mark the OUT_0_FABCLK_0 output of the CCC "Unused".

Now add a new CCC to the design (just drag in a "Clock Conditioning Circuitry" core from the Catalog) - we'll use this to generate a dedicated FIC0 CLK. Configure it with a 50MHz reference and connect:

CLKINT_REF_CLKL_50MHz: Y -> FIC_0_DEDICATED_CCC_0: REF_CLK_0
AND4_0: Y -> FIC_0_DEDICATED_CCC_0: PLL_POWERDOWN_N
FIC_0_DEDICATED_CCC_0: OUT0_FABCLK_0 -> FIC_0_CLK
FIC_0_DEDICATED_CCC_0: OUT0_FABCLK_0 -> RESET_FIC_0_CLK: CLK
FIC_0_DEDICATED_CCC_0: PLL_LOCK_0 -> RESET_FIC_0_CLK: PLL_LOCK

Leaving all of the existing connections in place. This should give you:

This way the other FICs (1, 2 & 3) are driven by the original CCC at the original frequency and you can then configure the FIC 0 clock independently of the other FICs.

You'll need to re-derive constraints and edit the "fic_clocks.sdc" file to point at the new clock for FIC 0.

[hughbreslin]

Cool I’ll mark this as the answer so :) maybe get it to print out the mismatching address and data, it should make it easier to find the cause of the failure :)

[Kian-KH]

Yep. Glad I asked for guidance on this! Which makes me wonder… is there any info on this (isolating FIC0) in the TRM or the ref design docs?

[hughbreslin]

No there wouldn't be info there as its an implementation decision, really its down to the CCC / PLL and the frequencies you can achieve when using it. There is info on the frequencies you can produce between the outputs of a PLL using the CCC in the documentation / specs but it wouldn't tell you what to do as its situational depending on your design.

[hughbreslin]

But now if people google something similar to this they'll find this thread :)

[Kian-KH]

Yes! For Science! 😄