DML clarifications

Question

I have a few question related to regs hard/soft reset values. According to the documentation (in this case for soft reset value):

SOFT_RESET_VALUE The soft_reset_value parameter is renamed to soft_reset_val, and requires the template soft_reset_val to be instantiated. So, hard_reset_value is effectively init_val and soft_reset_value is now soft_reset_val. Except soft_reset must be overridden to provide a different value?

The hard_reset_value and soft_reset_value parameters in registers and fields are no longer recognized. Instead, the default implementations of the hard_reset and soft_reset methods invoke the init method, effectively replacing the hard_reset_value and soft_reset_value parameters with init_val. You must now override the soft_reset method explicitly in order to provide different reset values for hard and soft reset. Where is the method init() for the registers located?

Also, I suspect the answer is no but is there a list of all methods predefined somewhere along with all the magic variables and parameters?

Lastly, is it always necessary to use ‘is read’ to override an internal library function? The documentation suggests that putting a read method is sufficient but that does not work because:

warning: implementation of read() without 'is read' is ignored by the standard library

If ‘is read’ is always necessary, why is it there at all? Thanks in advance.

Answer 1

There are a number of questions here, so I'll separate and answer them in turn.

Re. soft reset. To provide an exhaustive explanation of how the mechanism surrounding soft-reset works:

• All registers and fields automatically instantiate the soft_reset template (as long as the device is declared to support soft reset via is sreset;), and provides a default implementation of the soft_reset() method, which calls init() of the register/field. In turn, the default implementation of init() for register/fields leverage the init_val parameter, which, if not specified, is by default 0 for registers; and for fields, by default dependent on init_val of the parent register.
• Behavior of soft_reset of a register/field is thus affected by any change of any link specified in the above chain. You can change init_val; or override init(); or override soft_reset()
• soft_reset_val is a separate template from soft_reset, and is not instantiated automatically for registers/fields. It affects the first link the chain, i.e., it provides its own implementation of soft_reset(), which leverages the soft_reset_val param. This is relevant if you want the value that your register/field initializes/hard resets to to be different compared to the value that it soft resets to.

Also, I suspect the answer is no but is there a list of all methods predefined somewhere along with all the magic variables and parameters?

Yes! The DML 1.4 reference manual! Sections 4 and 5 provides the answer to almost everything you're asking about -- although admittedly, its wording of the default behavior of soft_reset implies init_val is used directly in the default implementation of soft_reset(), rather than indirectly from the use of init(). We'll correct the wording to be more precise.

The documentation suggests that putting a read method is sufficient

That is not the case. What documentation suggests that? If it's anything non-public (i.e. not the DML 1.4 Reference Manual), then you'll have to raise that privately to Intel.

Is it always necessary to use ‘is read’ to override an internal library function?

No; you misunderstand. It is not a question of having to instantiate a template to override an internal library function. In DML 1.4, the read() and write() methods are not inherent to registers or fields. They are creatures of the read and write templates, which may be instantiated for registers/fields, and are meant to provide a simple means of customizing read/write behavior. If you make a definition of read() or write() without instantiating the read or write templates, then no code is added to the register/field to actually make use of those methods; so they're dead, hence, "ignored by the standard library".

If ‘is read’ is always necessary, why is it there at all?

Because it isn't always necessary -- only if you wish to have access to the simplified means of customizing read/write behavior -- and, more to the point, because instantiating read/write for a register/field will, by itself, change the semantics of reads/writes to the register/field. Most critically, if you instantiate read/write for a register, then reading/writing to it will cause it to ignore any customized read/write behavior of its fields! This is noted in the reference manual.