wu-arch/chipyard
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Version Upgrade Docs Notes (#545)

Browse Source 
* version upgrade notes

* [skip ci] Update docs/Chipyard-Basics/Initial-Repo-Setup.rst

Co-authored-by: Abraham Gonzalez <abe.j.gonza@gmail.com>

* [skip ci] Update docs/Chipyard-Basics/Initial-Repo-Setup.rst

Co-authored-by: Abraham Gonzalez <abe.j.gonza@gmail.com>

* [skip ci] Update docs/Chipyard-Basics/Initial-Repo-Setup.rst

Co-authored-by: Abraham Gonzalez <abe.j.gonza@gmail.com>

* [skip ci] Update docs/Chipyard-Basics/Initial-Repo-Setup.rst

Co-authored-by: Abraham Gonzalez <abe.j.gonza@gmail.com>

* [skip ci] Update docs/Chipyard-Basics/Initial-Repo-Setup.rst

Co-authored-by: Abraham Gonzalez <abe.j.gonza@gmail.com>

Co-authored-by: Abraham Gonzalez <abe.j.gonza@gmail.com>
This commit is contained in:
alonamid
2020-05-19 19:09:53 -07:00
committed by GitHub
parent dca6604cf4
commit 9c73037e93
1 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/Chipyard-Basics/Initial-Repo-Setup.rst
View File

@@ -86,3 +86,28 @@ This depends on what you are planning to do with Chipyard.
* If you intend to run a tutorial VLSI flow using one of the Chipyard examples, go to :ref:`tutorial` and follow the instructions.
* If you intend to build a chip using one of the vanilla Chipyard examples, go to :ref:`build-a-chip` and follow the instructions.
Upgrading Chipyard Release Versions
-------------------------------------------
In order to upgrade between Chipyard versions, we recommend using a fresh clone of the repository (or your fork, with the new release merged into it).
Chipyard is a complex framework that depends on a mix of build systems and scripts. Specifically, it relies on git submodules, on sbt build files, and on custom written bash scripts and generated files.
For this reason, upgrading between Chipyard versions is **not** as trivial as just running ``git submodule update -recursive``. This will result in recursive cloning of large submodules that are not necessarily used within your specific Chipyard environments. Furthermore, it will not resolve the status of stale state generated files which may not be compatible between release versions.
If you are an advanced git user, an alternative approach to a fresh repository clone may be to run ``git clean -dfx``, and then run the standard Chipyard setup sequence. This approach is dangerous, and **not-recommended** for users who are not deeply familiar with git, since it "blows up" the repository state and removes all untracked and modified files without warning. Hence, if you were working on custom un-committed changes, you would lose them.
If you would still like to try to perform an in-place manual version upgrade (**not-recommended**), we recommend at least trying to resolve stale state in the following areas:
* Delete stale ``target`` directories generated by sbt.
* Delete jar collateral generated by FIRRTL (``lib/firrtl.jar``)
* Re-generate generated scripts and source files (for example, ``env.sh``)
* Re-generating/deleting target software state (Linux kernel binaries, Linux images) within FireMarshal
This is by no means a comprehensive list of potential stale state within Chipyard. Hence, as mentioned earlier, the recommended method for a Chipyard version upgrade is a fresh clone (or a merge, and then a fresh clone).