hps: test without master SPI

[acomodi]

This PR is built on collection of other PRs:

CFU:

• new models #427: new models

LiteSPI (bumped):

• mmap: make CSR optional litex-hub/litespi#67

With this PR and nextpnr from YosysHQ/nextpnr#897 yielded a bitstream that passed golden tests and nextpnr closed timing at 84.84 MHz (pass @ 55 MHz)

[danc86]

Thanks for testing this @acomodi. Now that a few other things have settled (like the new models, and the fix for the multiplier primitive) I have gone back and more carefully re-tested the Litespi size reductions.

I am still seeing strange failures with certain combinations of gateware. The failure modes seem to change even based on small, unrelated changes in the design, which I find suspicious. It reminds me a lot of gatecat/prjoxide#10 where small perturbations would trigger some incorrectly-implemented element in prjoxide (or nextpnr).

As a starting point, I am using CFU-Playground main branch as of right now (commit fd2c06e), in the hps_accel project. I have the latest master branch of the tools: yosys commit bc027b2c, nextpnr commit 1301feb4 + cherry pick of PR#897, prjoxide commit 318331f8.

For my test procedure, I am flashing the bitstream+software onto HPS proto2 board, and then using the UART to check all of:

• SPI flash non-sequential test, check for OK (menu 8 -> n)
• SPI flash CRC, check for expected value (menu 8 -> c)
• flash strided loads benchmark, check for 39 cycles/load (menu 6 -> g)
• golden tests with HPS 09_20 model, check for OK (menu 1 -> 1 -> g)
• reinitialize 01_05_74ops model and repeat golden tests, check for OK (1 -> g)
• repeat with all remaining models

If I pass with_master=False to LiteSPI(), the result is good.

If I also cherry-pick litex-hub/litespi#67 and pass with_master=False, with_csr=False, the CPU does not boot (no UART output).

Purely by coincidence, I was experimenting with an unrelated change the same time, to remove the "controller" CSRs which we do not use:

--- a/soc/hps_soc.py
+++ b/soc/hps_soc.py
@@ -85,7 +85,6 @@ class HpsSoC(LiteXSoC):

         # Clock, Controller, CPU
         self.submodules.crg = platform.create_crg()
-        self.add_controller("ctrl")
         if execute_from_lram:
             reset_address = 0x00000000
         else:

If I combine that change with with_master=False, with_csr=False, the result is good.

For completeness I also tried the above change with with_master=False, with_csr=True and with_master=True, with_csr=True and they are also good.

Those minor, unused controller CSRs almost certainly cannot influence the behaviour of Litespi so I am wondering if it could be another bug in synthesis.

[danc86]

I made tarballs of the synthesis intermediate files for the above good and bad designs:

gateware-build-no-litespi-master.zip -- GOOD

gateware-build-no-litespi-master-no-litespi-csrs.zip -- BAD

gateware-build-no-litespi-master-no-litespi-csrs-no-controller-csrs.zip -- GOOD

[danc86]

The bad design mentioned above (with_master=False, with_csr=False but controller CSRs left included) works when I synthesise it using router1 instead of router2.

[danc86]

I filed a fresh nextpnr issue for the above "bad" design, we can follow it up there:
YosysHQ/nextpnr#903

I think we can probably close this PR now since all the remaining issues are sorted out now.

[acomodi]

@danc86 All right, thanks, we can discuss new insights and findings in the new nextpnr issue.

Closing this PR