Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

README.md should elaborate more on why both CMakeLists.txt and the Makefile are necessary. #1903

Open
cr1901 opened this issue Dec 20, 2020 · 4 comments

Comments

@cr1901
Copy link

cr1901 commented Dec 20, 2020

I've been doing a port of symbiflow-arch-defs to the machxo2 family of FPGAs, using ice40/xc examples as a smoke test to make sure I'm ready to add my own machxo2 tree to the source code.

The README.md's Getting Started and Development Notes sections are reasonable/correct. However, as someone who had no experience working with symbiflow or vpr, I found that I needed to write my own set of notes, before the README.md made sense to me. My notes are based on studying the various CMakeLists.txt and cmake files, the top-level Makefile, and make-env.

Perhaps we could take my notes (still writing them!) and incorporate them into the README.md? My guess is that other people who are getting started with development (or even building their own copies for experimenting!) may have the same issues as me, and adding my notes on getting started can save some trouble.

Here are my notes for "CMakeLists.txt" vs "Makefile":

1. Before starting to code, experiment/explore by building targets. You
   _really_ should use the `conda` env.
  * `conda` env only works on Linux at present.
  * There is both a `Makefile` and `CMakeLists.txt`. The Makefile wraps the
    `cmake` build system so that the `conda` environment is picked up during
    `cmake` config. Therefore, configuring the `cmake` build should be done via the
    `Makefile`.
  * `make env` or e.g. `make CMAKE_COMMAND="cmake -GNinja" env` will get you a
    tree ready for building in the `build` directory. `make` will run
    `make env` and then do the build.
@mithro
Copy link
Contributor

mithro commented Dec 20, 2020

FYI - @mgielda, @rw1nkler

@mithro
Copy link
Contributor

mithro commented Dec 21, 2020

FYI - I think this is related to https://docs.google.com/drawings/d/15sVUnCHS1ex3lmuD3J7nDR-F1Xst6Panotc-2WlNRtQ/edit

Google Docs
OR Local System Conda Environment SymbiFlow Environment Providers Choose ONE (Do not mix-n-match!) Advantages Feeling of smugness You foobar your system Your tools are out of date Advantages Self Contained Removable with rm -rf Instructions Install binary package apt-get / yum / etc Install pytho...

@mithro
Copy link
Contributor

mithro commented Dec 21, 2020

SymbiFlow Environment Providers

@cr1901
Copy link
Author

cr1901 commented Dec 21, 2020

@mithro I'd like to note, in my defense, that I've been using conda from the very beginning for building symbiflow-arch-defs, particularly because I cannot be arsed to build Node. I did not spend time even trying to make it work with the system packages. All my notes here, including the top line where I say "you really should use conda" were written after I decided to use conda :).

I just believe that the option should exist for users who already have yosys, nextpnr, vpr, and friends installed as part of their local system already. Installing pre-built databases/build artifacts for your system/local vpr should work fine without the conda env. That way, users with local copies can avoid the lovely problem where you have two FPGA toolchains/workflows for everything except symbiflow and you may accidentally use the wrong one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants