switch to host, primary, or over-arching as appropriate
Signed-off-by: Scott Johnson <scottdj@google.com>
diff --git a/doc/ug/design.md b/doc/ug/design.md
index 4e64015..a845bd0 100644
--- a/doc/ug/design.md
+++ b/doc/ug/design.md
@@ -174,11 +174,11 @@
But our first goal is to take full advantage of the language as much as possible, and only resort to generated code where necessary.
At the moment, all generated code is checked in with the source files.
-The pros and cons of this decision are still being discussed, and the decision may be reversed, to be replaced with a master build-all script to prepare a final design as source files changed.
+The pros and cons of this decision are still being discussed, and the decision may be reversed, to be replaced with an over-arching build-all script to prepare a final design as source files changed.
Until that time, all generated files (see for example the output files from the
[register generation tool]({{< relref "doc/rm/register_tool" >}}))
are checked in.
-There is a master build file in the repository under `hw/Makefile` that builds all of the `regtool` content.
+There is an over-arching build file in the repository under `hw/Makefile` that builds all of the `regtool` content.
This is used by an Azure Pipelines pre-submit check script to ensure that the source files produce a generated file that is identical to the one being submitted.
## Getting Started with a Design
diff --git a/doc/ug/dv_methodology.md b/doc/ug/dv_methodology.md
index 3353f0e..f8c5a83 100644
--- a/doc/ug/dv_methodology.md
+++ b/doc/ug/dv_methodology.md
@@ -22,7 +22,7 @@
For professional tooling, the team has chosen [Synopsys' VCS](https://www.synopsys.com/verification/simulation/vcs.html) as the simulator of choice with respect to the tracking of verification completeness and [JasperGold](https://www.cadence.com/content/cadence-www/global/en_US/home/tools/system-design-and-verification/formal-and-static-verification/jasper-gold-verification-platform.html) for FPV.
Wherever possible we attempt to remain tool-agnostic, but we must choose a simulator as our ground truth for our own confidence of signoff-level assurances.
-Likewise, for FPV, [Synopsys VC Formal](https://www.synopsys.com/verification/static-and-formal-verification/vc-formal.html) is also supported within the same flow, and can be used by those with access to VC Formal licenses.
+Likewise, for FPV, [Synopsys VC Formal](https://www.synopsys.com/verification/static-and-formal-verification/vc-formal.html) is also supported within the same flow, and can be used by those with access to VC Formal licenses.
At this time there is also some support for Cadence's Xcelium, for those organizations which have few Synopsys VCS licenses.
However support is not as mature as for VCS, which remains the tool for signoff.
Furthermore, as a project we promote other open source verification methodologies - Verilator, Yosys, cocoTB, etc - and work towards a future where these are signoff-grade.
@@ -272,7 +272,7 @@
Categorizing such tests into a sanity suite provides a quick path for users who touch common / shared piece of code to run those tests for all DUTs and ensure no breakages occur.
If the DUT testbench has more than one compile-time configuration, there needs to be at least 1 sanity test per configuration.
-Ideally, the sanity regression is run as a part of the CI check whenever a PR is submitted. Due to use of proprietary tools for running DV simulations, this cannot be accomplished. Instead, we run a daily cron job locally on the up-to-date master branch to identify such breakages and deploy fixes quickly.
+Ideally, the sanity regression is run as a part of the CI check whenever a PR is submitted. Due to use of proprietary tools for running DV simulations, this cannot be accomplished. Instead, we run a daily cron job locally on the up-to-date `master` branch to identify such breakages and deploy fixes quickly.
### Nightly
diff --git a/doc/ug/getting_started_verilator.md b/doc/ug/getting_started_verilator.md
index 264c6fb..8d09d42 100644
--- a/doc/ug/getting_started_verilator.md
+++ b/doc/ug/getting_started_verilator.md
@@ -135,7 +135,7 @@
## SPI device test interface
-The simulation contains code to monitor the SPI bus and provide a master interface to allow interaction with the `spi_device`.
+The simulation contains code to monitor the SPI bus and provide a host interface to allow interaction with the `spi_device`.
When starting the simulation you should see a message like
```console
diff --git a/doc/ug/github_notes.md b/doc/ug/github_notes.md
index 30f8db2..22d2b00 100644
--- a/doc/ug/github_notes.md
+++ b/doc/ug/github_notes.md
@@ -79,9 +79,9 @@
## Working in your local repo
The repository that you have created locally will initially be on the
-**master** branch. In general you should not make changes on this
+`master` branch. In general you should not make changes on this
branch, just use it to track your GitHub repository and synchronize with the
-lowRISC master repo.
+main lowRISC repository.
The typical workflow is to make your own branch which it is
conventional to name based on the change you are making:
@@ -196,7 +196,7 @@
## Update your repository with changes in the lowRISC repo
There is a little work to do to keep everything in sync. Normally you
-want to first get your local repository master branch up to date with the
+want to first get your local repository `master` branch up to date with the
lowRISC repository (**upstream**) and then you use that to update your GitHub
copy (**origin**).
@@ -208,9 +208,9 @@
If you do this while you have changes on some other branch then before
a Pull Request will work you need to be sure your branch merges
-cleanly into the new lowRISC repo. Assuming you got the local master
+cleanly into the new lowRISC repo. Assuming you got the local `master`
branch up to date with the procedure above you can now **rebase** your
-changes on the new master. Assuming you have your changes on the local
+changes on the new `master`. Assuming you have your changes on the local
branch `forchange`:
```console
@@ -219,7 +219,7 @@
```
If you are lucky this will just work, it unwinds your changes, gets
-the updated master and replays your changes. If there are conflicts
+the updated `master` and replays your changes. If there are conflicts
then you need a big pot of coffee and patience (see next section).
Once everything has rebased properly you can do
@@ -230,7 +230,7 @@
```
And see that the changes you commited on the branch are at the top of
-the log followed by the latest changes on the master branch.
+the log followed by the latest changes on the `master` branch.
## Dealing with conflicts after a rebase
@@ -301,16 +301,20 @@
```
-In this case the master tree (between `<<<<<<< HEAD` and `=======`)
-was modified to import `docgen.generate` rather than just `docgen` and
-the local tree (between `=======` and `>>>>>>>` followed by the first
-line of the commit message) had been changed to re-order the
-imports. These lines have to be edited to get the correct merged
+In this case, the upstream repository's copy of `util/build_docs.py`
+was modified to import `docgen.generate` rather than just `docgen`.
+Because git couldn't automatically merge that change with the one
+we made, it gave up. The code between `<<<<<<< HEAD` and `=======`
+represents the change in the upstream repository and the code between
+`=======` and `>>>>>>>` represents the change in our copy.
+
+These lines have to be edited to get the correct merged
result and the diff markers removed. There may be multiple points in
the file where fixes are needed. Once all conflicts have been
addressed the file can be `git add`ed and once all files addressed the
rebase continued.
+
After the fix a status report will remind you where you are.
```console
@@ -350,7 +354,7 @@
You can check the rebase worked as expected by looking at the log to
see your branch is one commit (or more if there were more) ahead of
-the master branch.
+the `master` branch.
```console
$ git log
@@ -372,7 +376,7 @@
This shows the new commit (`HEAD` of the branch `sastyle`) and the
preceding commit is at the `master` branch (and at the same point as
`master` on both `origin` and `upstream` so everything is in sync at
-master).
+`master`).
At this point the conflicts have been cleared and the local repository can
be used as expected.
diff --git a/doc/ug/rust_for_c.md b/doc/ug/rust_for_c.md
index 4c4bfa1..52bc64a 100644
--- a/doc/ug/rust_for_c.md
+++ b/doc/ug/rust_for_c.md
@@ -54,7 +54,7 @@
* `std` and `core`, the standard libraries.
The Rust toolchain is on a six-week release cycle, similar to Chrome's: every six weeks, a release branch is cut as the next beta, and after six weeks it becomes the next stable.
-Nightly Rust is cut from master every day; it is on nightly that unstable features can be enabled.
+Nightly Rust is cut from `master` every day; it is on nightly that unstable features can be enabled.
Some unstable features[^5] are very useful for embedded, so it is not uncommon for embedded Rust projects to use a nightly compiler.
`rustup` is used for managing Rust installations.
@@ -572,7 +572,7 @@
``` rust
extern "C" {
fn malloc(bytes: usize) -> *mut u8;
- static mut errno: i32;
+ static mut errno: i32;
}
```
When the ABI specified is `"C"`, it can be left off; `extern {}` is implicitly `extern "C" {}`.
@@ -1879,7 +1879,7 @@
* `iter.enumerate()`.
Changes the `Item` type from `T` into `(usize, T)`, tracking the current index in the sequence along with the value.
* `iter.step_by(n)`.
- Changes the iterator to return every `n`th element.
+ Changes the iterator to return every `n`th element.
* `iter.take(n)`.
Shortens the iterator to return `n` elements before fusing.
* `iter.map(|x| /* ... */)`.
diff --git a/doc/ug/vendor_hw.md b/doc/ug/vendor_hw.md
index 21ddd60..ba29437 100644
--- a/doc/ug/vendor_hw.md
+++ b/doc/ug/vendor_hw.md
@@ -84,7 +84,7 @@
This description file essentially says:
We vendor a component called "lowrisc_ibex" and place the code into the "lowrisc_ibex" directory (relative to the description file).
-The code comes from the master branch of the Git repository found at https://github.com/lowRISC/ibex.git.
+The code comes from the `master` branch of the Git repository found at https://github.com/lowRISC/ibex.git.
With this description file written, the `util/vendor` tool can do its job.
