SymbiFlow meeting #1

noted.md

SymbiFlow meeting #1

• What is the current state/timeline?

• GCC for FPGAs

  • Correct build system
    • Follows the Filesystem Hierarchy Standard (FHS)
      • Allows setting prefix (/usr/local for users, /usr for distributions)
      • Allows setting libdir (lib , lib32 or lib64, distribution dependent)
      • Allows setting libexecdir (if used)
    • Honor CFLAGS, CXXFLAGS , LDFLAGS and all other standard environment variables
      • Could be done via a build system switch, but optimally it would check if the variables are set and if so it wouldn't overwrite
      • Eg. no adding -O3 to CFLAGS
    • Reproducibility
      • The build system should not connect to the internet
        • If that you feel this is really needed, have a build system flag to disable it
        • Sources are fetched before the build and the checksums are validated, this way we should be able to reproduce builds at a binary level
    • Support PIE
    • No static libraries (at least not as a requirement)
      • Dynamic libraries should be used
    • Ship pkgconfig files for libraries
    • Dynamic libraries should have a SO version to keep track of ABI changes
      • semver is preferred but not a requirement
    • No workarounds to find dependencies
      • This is system specific and hard to get right without having a massive CI to track every change in the different distributions
        • Unfortunately this is exactly what happens in CMake, which seems to be the current preferred build system
      • Eg. use pkgconfig
    • Don't use SIMD instructions directly in the binary
      • If you want to use SIMD instruction they should be resolved at runtime, see VOLK
      • If you really need them and resolving at runtime is not doable, provide build system switches (and honor CFLAGS)
  • Stability
    • Have a good CI
    • Be careful when merging
    • Fix the correct upstream instead of adding temporary (or not so temporary) hacks
  • Releases
    • It seems like we are not there yet?
      • What is the ETA?
      • If the software is not ready to be used in production it should be advertised (put a disclaimer)
    • Consider having 1~2 releases/year
      • Still motivates users to use master while users can safely use it in production
        • Major bug fixes would be backported by packagers, or alternatively we could provide a minor release update

• Keep track of all SymbiFlow components

  • arch-defs
  • prjtrellis
  • prjxray
  • yosis-symbiflow
  • (what actually is SymbiFlow)