What is the correct behaviour for signalling when the swmod property is used?

[Jonah-Foley]

Hi there, I am a maintainer of the peakrdl exporter https://github.com/NuQuantum/peakrdl-sv. I have recently been looking at the implementation of the swmod property. Each register we generate has the following interface

module rdl_subreg
  import rdl_subreg_pkg::*;
#(
    parameter int                   DW         = 32,
    parameter reset_type_e          ResetType  = ActiveHighAsync,
    parameter logic        [DW-1:0] ResetValue = '0,
    parameter on_read_e             OnRead     = OnReadNone,
    parameter on_write_e            OnWrite    = OnWriteNone
) (
    input logic clk,
    input logic rst,

    // From CPU
    input logic          re,
    input logic          we,
    input logic [DW-1:0] wd,

    // From HW
    input logic          de,
    input logic [DW-1:0] d,

    // Output to HW
    output logic [DW-1:0] q,
    output logic          qe,
    output logic          qre,

    // Output to CPU
    output logic [DW-1:0] qs
);

If the user sets the swmod property in their RDL, the qe output is assigned to we. The we signal is driven by the bus which interfaces with the register block. This way we get a single cycle pulse on qe to indicate to the hardware the register has been modified by software.

This means however that the qe output is asserted the cycle before the q data value propagates.

We currently arent sure if this is the correct behaviour, or whether the qe output should align with the data on the q port that has changed? Does anyone know what is standard?

Current behaviour:

       ___    ___    ___    ___    ___    ___    ___    ___    ___    ___ 
clk __/   \__/   \__/   \__/   \__/   \__/   \__/   \__/   \__/   \__/   \
                     ______
we  ________________/      \______________________________________________

re  ______________________________________________________________________
                     ______  
wd  ________________x_data_x______________________________________________
                     ______
qe  ________________/      \______________________________________________
                             ______
q   ________________________x_data_x______________________________________

Expected?

       ___    ___    ___    ___    ___    ___    ___    ___    ___    ___ 
clk __/   \__/   \__/   \__/   \__/   \__/   \__/   \__/   \__/   \__/   \
                     ______
we  ________________/      \______________________________________________

re  ______________________________________________________________________
                     ______  
wd  ________________x_data_x______________________________________________
                             ______
qe  ________________________/      \______________________________________
                             ______
q   ________________________x_data_x______________________________________

Thank you!

[amykyta3]

The SystemRDL spec does not formally describe what the "correct" timing relationship is with respect to swacc and swmod properties. Given the lack of a spec, I have interpreted this as an implementation-defined feature.

For PeakRDL-regblock, I have implemented these outputs to be asserted on the cycle before the software action takes place. I believe this ends up being the same as your implementation.
The reason I chose this interpretation is as follows:

• For swacc assertions due to software reads, it is preferable to have the signal assert on the exact same cycle that the data is being sampled. This is useful in situations where the data needs to be updated on the next cycle (such as a FIFO read interface)
• Since swacc also asserts for software write accesses, I need to ensure that back-to-back read/write accesses do not result in an overlapping swacc pulse. For this reason, the swacc pulse will conceptually strobe during the cycle prior to the register action taking place - before the write takes effect, and before the read samples the data.
• For swmod the behavior is matched with swacc for consistency.

On the other hand, swmod asserting on the same cycle that new data is available is often useful since it can be used as a "valid" signal without modification. I chose not to do this since adding a delay FF is trivial to align, while giving freedom to designs that may require no extra delay.

[Jonah-Foley]

Thank you for your answer, and for pointing to me to your documentation - great project. I'll use that going forward if I need help deciding the implementation, perhaps we can form a consensus that way, hah.

I chose not to do this since adding a delay FF is trivial to align, while giving freedom to designs that may require no extra delay.

Yes, I think this is a reasonable position. I'll keep it as it is for now, thanks again.