RFC 54: Initial and reset values on memory read ports.

[wanda-phi]

Rendered

[tpwrules]

I would want to make sure that the emulation logic does not break inference. Is an implementation available to test?

Could the default be init=0 and explicitly saying init=None to mean the previous behavior (disabling emulation if appropriate)? This would pacify complainers, such as potentially myself, but would leave undefined behavior as a possibility. This somewhat negates the RFC but at least the user would be signing up for consequences themselves.

With regards to the alternative, is this referencing an implementation detail? Not sure how I as the user would specify those attributes on the signature if it's created by the Memory.

[whitequark]

I do want to exclude the uninitialized register hole one way or another.

[wanda-phi]

I would want to make sure that the emulation logic does not break inference. Is an implementation available to test?

Could the default be init=0 and explicitly saying init=None to mean the previous behavior (disabling emulation if appropriate)? This would pacify complainers, such as potentially myself, but would leave undefined behavior as a possibility. This somewhat negates the RFC but at least the user would be signing up for consequences themselves.

With regards to the alternative, is this referencing an implementation detail? Not sure how I as the user would specify those attributes on the signature if it's created by the Memory.

Emulation will definitely not break inference in yosys. This RFC is, however, likely to cause problems in other toolchains.

Part of the goal of lib.Memory was adding a platform hook that allows us to effectively move memory inference to Amaranth on such platforms, to deal with this problem.

[FatsieFS]

I don't have problem with having default to have a port have 0 as init.
When later undefined values are introduced as will be required for certain SRAM support, I would like to have possibility to allow to optimize it so that no MUX and an extra set of flops are inserted on for example a register file for a CPU when the ports don't support init values. So at that point I would like to have init=None or similar as option for a memory read port.
As usual I am looking at it from an ASIC angle; on ASIC MUXes are relatively slow cells.

[whitequark]

So at that point I would like to have init=None or similar as option for a memory read port.

@wanda-phi How do we handle this, init=None or reset_less=True or both?

[wanda-phi]

So at that point I would like to have init=None or similar as option for a memory read port.

@wanda-phi How do we handle this, init=None or reset_less=True or both?

in whatever way we do that for plain Signals, I think; on an ASIC, the initial value cannot be supported for the exact same reasons

init=None already has the semantics of "give me the default value", by way of the ShapeCastable.const protocol; I believe the options are either init=<sentinel>, or something like init_less=True (which has the advantage [?] of allowing us to express a FF with reset but no initial value, which is what ASICs and some FPGAs have)

[whitequark]

(which has the advantage [?] of allowing us to express a FF with reset but no initial value, which is what ASICs and some FPGAs have)

I'd say reset_less=True already allows us to do that, since the domain's behavior shouldn't depend on the way in which it was reset. This is not the current semantic, but I think we should probably make it the new semantic.

I.e. alter the guide as follows:

-Reset-less signals are not affected by explicit reset.
+Reset-less signals are not affected by explicit reset, and assume an unspecified value,
+which may differ between toolchains and platforms, at power-on reset.

[whitequark]

Oh, wait, I misread what you said. My comment applies in general but not to "reset with no initial value" desire. I'm not sure if we should support that, it seems rather niche. Oh right, that covers all ASICs.

I think we are going to need a coherent strategy for dealing with reset and nondeterminism on ASICs, but probably not as a part of this RFC. For this RFC I think we should be OK saying essentially "the read port is a funny Signal and the same rules apply".

[wanda-phi]

Oh, wait, I misread what you said. My comment applies in general but not to "reset with no initial value" desire. I'm not sure if we should support that, it seems rather niche. Oh right, that covers all ASICs.

I think we are going to need a coherent strategy for dealing with reset and nondeterminism on ASICs, but probably not as a part of this RFC. For this RFC I think we should be OK saying essentially "the read port is a funny Signal and the same rules apply".

Agreed fully.

[whitequark]

Maybe add that to "Future work"? Oh it's there. I am really not awake today.

[whitequark]

We have discussed this RFC on the 2024-03-18 weekly meeting. The disposition was to merge.

Due to the potential for disruption of memory inference, the implementation for this RFC should not be merged until either:

• After Amaranth 0.5 is released.
• Memory inference is confirmed to work with vendor toolchains at least on major platforms.
• There is a clearly marked workaround for cases where memory inference fails due to the changes made according to this RFC.