37cbf2b598
Generate files in-memory (which is a cheap operation) and only write the file to disk if it is different from the existing file. This prevents rebuilds in the following circumstances: 1. When changing utralibs, an extra rebuild is always generated due to the file being updated mid-build. This will no longer happen. 2. When switching targets, there will no longer be an unconditional rebuild. This is because the feature flags are mixed in with the package hash, and different builds use different feature flags. 3. When one svd file is updated, other variants of that feature flag are no longer rebuilt. For example, when updating the Renode SVD, Precursor DVT1 will not need to be rebuilt, since that has not changed. Changing a given SVD file will cause that target's version of utralib to be rebuilt, and only that target's version. Signed-off-by: Sean Cross <sean@xobs.io> |
||
|---|---|---|
| .. | ||
| precursor | ||
| renode | ||
| src | ||
| .gitignore | ||
| build.rs | ||
| Cargo.lock | ||
| Cargo.toml | ||
| README.md | ||
UTRA (Unambiguous Thin Register Abstraction) Library Crate
utralib is responsible for mapping a hardware target specification
to the set of physical memory locations used by the hardware.
The mapping is derived from an SVD file. SVD files are XML descriptions of a set of registers and fields that has been adopted by LiteX, but is also broadly used by other silicon vendors such as ST.
Rust strongly discourages auto-generated source content so this crate pre-generates the various configurations from SVD files and stores them in the directory "generated".
However, the generated UTRA descriptions will automatically regenerate if the source SVD files are modified, so during development one may replace an SVD file and expect that the generated.rs files should automatically update to reflect the changed SVD file.
Target selection
Target selection is done with a pair of flags, one which specifies the general target, and the other which whittles it down to a revision of the target.
For traditional silicon platforms, the revision almost never changes. For FPGA platforms, the revision can change and the convention adopted here is to use the short 32-bit gitrev to specify a revision. Because the 32-bit namespace is fairly small, the target name is still bundled in with the revision specifier.
Thus, to fully specify a Precursor target, one will need to pass two flags:
--features precursor: specifies the target--features precursor-c809403: specifies the revision
The target specifier is meant to simplify top-level crate decisions about which module to use to implement hardware features.
The revision is provided for very specific situations where a hardware feature may or may not be present in a specific revision of an FPGA SoC.
The feature system could also be (ab)used to, for example, specify an STM32 family and then the specific chip configuration of that family with the revision.