[][src]Type Definition cc3220sf::sspi::hl_rev::R

type R = R<u32, HL_REV>;

Reader of register HL_REV

Implementations

impl R[src]

pub fn scheme(&self) -> SCHEME_R[src]

Bits 30:31 - SCHEME

pub fn rsvd(&self) -> RSVD_R[src]

Bits 28:29 - Reserved These bits are initialized to zero and writes to them are ignored.

pub fn func(&self) -> FUNC_R[src]

Bits 16:27 - Function indicates a software compatible module family. If there is no level of software compatibility a new Func number (and hence REVISION) should be assigned.

pub fn r_rtl(&self) -> R_RTL_R[src]

Bits 11:15 - RTL Version (R) maintained by IP design owner. RTL follows a numbering such as X.Y.R.Z which are explained in this table. R changes ONLY when: (1) PDS uploads occur which may have been due to spec changes (2) Bug fixes occur (3) Resets to '0' when X or Y changes. Design team has an internal 'Z' (customer invisible) number which increments on every drop that happens due to DV and RTL updates. Z resets to 0 when R increments.

pub fn x_major(&self) -> X_MAJOR_R[src]

Bits 8:10 - Major Revision (X) maintained by IP specification owner. X changes ONLY when: (1) There is a major feature addition. An example would be adding Master Mode to Utopia Level2. The Func field (or Class/Type in old PID format) will remain the same. X does NOT change due to: (1) Bug fixes (2) Change in feature parameters.

pub fn custom(&self) -> CUSTOM_R[src]

Bits 6:7 - CUSTOM

pub fn y_minor(&self) -> Y_MINOR_R[src]

Bits 0:5 - Minor Revision (Y) maintained by IP specification owner. Y changes ONLY when: (1) Features are scaled (up or down). Flexibility exists in that this feature scalability may either be represented in the Y change or a specific register in the IP that indicates which features are exactly available. (2) When feature creeps from Is-Not list to Is list. But this may not be the case once it sees silicon; in which case X will change. Y does NOT change due to: (1) Bug fixes (2) Typos or clarifications (3) major functional/feature change/addition/deletion. Instead these changes may be reflected via R S X as applicable. Spec owner maintains a customer-invisible number 'S' which changes due to: (1) Typos/clarifications (2) Bug documentation. Note that this bug is not due to a spec change but due to implementation. Nevertheless the spec tracks the IP bugs. An RTL release (say for silicon PG1.1) that occurs due to bug fix should document the corresponding spec number (X.Y.S) in its release notes.