What is the state of the ariane-smp branch?

[rogpld]

Hello, this is actually more of a question than a feature request. I did follow the discussion in the Ariane Cache support issue #61. One thing is still not clear to me.

Can I follow the same configuration steps mentioned in the documentation for the Leon3 case to configure an Ariane SOC with caches hierarchy as well? Or only the pre-generated binaries work?

Thank you.

[davide-giri]

Hi!

Yes, all the SoC configuration steps are independent of the processor core selection. So they are the same for Leon3, Ariane and Ibex.

The ariane-smp branch is in good shape and we are planning to release it into master shortly (hopefully within a couple of weeks). This means that you can now build multicore Ariane SoCs that can run Linux SMP. At the moment you can have only up to 4 cores (4 CPU tiles), because that was the maximum for Leon3. We plan to remove this constraint for Ariane to allow for more than 4 cores, there is no particular limitation on this. While up to 3 cores things are even more stable than single-core Ariane was before, with 4 cores we still have a bit of occasional instability. It's good enough to do most stuff, but we are observing occasional failures during the Linux boot.

Notice that we also moved from riscv-pk to opensbi. This is the only thing we need to finalize before merging. At the moment you can switch between using riscv-pk and opensbi here. Depending on the target FPGA OpenSBI requires to tune the UART frequency. @jzuckerman can you provide more details on switching between riscv-pk and OpenSBI?

So bottom line, the ariane-smp branch is good to go if you want to try multi-core Ariane, and soon enough this feature will be merged into master.

Let us know if you have issues or questions, thanks!

Davide

[rogpld]

Thanks for the quick response.

I followed the guide on the website for setup and designing a single core soc with Ariane. I got a couple errors though. Some I was able to fix.

For instance, I had to disable htop, the link for download seems to be down.

utils/toolchain/riscv_buildroot_defconfig
58:BR2_PACKAGE_HTOP=n

However, I'm not sure about the one bellow, any ideas?

ERROR: [Synth 8-439] module 'GF12_SRAM_SP_512x28' not found

[davide-giri]

You're right, we did merge the epochs branch in the ariane-smp branch recently and that causes issues if you don't have those GF12 files. We will fix that when merging. I should have pointed you to the ariane-smp-old branch or better to commit cd7a8d1b55 of the ariane-smp branch. I'll ping you if we manage to test and fix the latest version of the ariane-smp branch soon.

[jzuckerman]

While we have begun the switch to openSBI (the officially supported supervisor binary interface from SiFive) and it results in some improvements, the riscv-pk still works well. You can switch to it by merely commenting out the linux.bin Make target that Davide pointed to that references openSBI, and uncommenting the one that uses riscv-pk. If using openSBI, you currently need to manually set the frequency defined in ESP's platform.c file for the particular FPGA you're using.

As Davide noted, we get good stability with two and three cores, but there are some occasional faults with four cores, particularly when running multithreaded applications for long periods of time.

[rogpld]

Thank you both for the clarifications. I'll be testing the ariane-smp-old branch in the next few days. I'll come back here if I find any issues.

Thank you.

On Fri, Nov 19, 2021 at 10:36 PM Joseph Zuckerman @.***> wrote:

While we have begun the switch to openSBI (the officially supported supervisor binary interface from SiFive) and it results in some improvements, the riscv-pk still works well. You can switch to it by merely commenting out the linux.bin Make target that Davide pointed to that references openSBI, and uncommenting the one that uses riscv-pk. If using openSBI, you currently need to manually set the frequency defined in ESP's platform.c https://github.com/sld-columbia/opensbi/blob/35d1d9ec03bc28382e9b3a44dbd26a6f1224332d/platform/esp-fpga/platform.c#L21 file for the particular FPGA you're using.

As Davide noted, we get good stability with two and three cores, but there are some occasional faults with four cores, particularly when running multithreaded applications for long periods of time.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sld-columbia/esp/issues/134#issuecomment-974517753, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUP7L53W7RG22IW55KQWX3UM3GPBANCNFSM5IMSA4AQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[rogpld]

Well, I had no luck.

Did the setup again from scratch. Checked out the ariane-smp-old branch. Had the same error on GF12_SRAM_SP_512x28. Removed the line from here, vivado runs but it gives the error attached right after.

vivado.log

Any ideas?

[davide-giri]

I think Vivado 2019.1 won't work, at the moment ESP works only with Vivado 2019.2. The ESP designs are using some Xilinx IPs (mainly MIG and SGMII) that change slightly in different versions of Vivado, so although porting to a new version is not super complicated, it normally doesn't work out of the box.

Here you can find the supported versions for the various CAD tools: https://esp.cs.columbia.edu/docs/setup/setup-guide/#cad-tools.

Let us get back to you soon about the GF12_SRAM sources problem. We're not getting that issue when running on our end.

[rogpld]

Indeed, Vivado 2019.2 produces the bitstream. I'm doing some further testing on the FPGA to ensure it is working properly.

You might not be getting the error on your end because you have already ran make l2-hls; make llc-hls. But I don't have Stratus configured on my system so I have skipped the HLS stuff.