How do I implement a DML bank that is accessed through 3 different interfaces with varying access restrictions per interface?

Question

I have device with a common register bank that can be accessed through 3 different interfaces, one is the "regular" interface where the register and fields have the normal access restriction (e.g. rw or ro) per the specification, but the other two interfaces are privileged access interfaces where the access restrictions are lifted in different ways for different registers/fields.

How would I implement that in a convenient way in DML?

One could imagine implementing a register bank with no restrictions on register and fields, but how would I then apply the normal access restrictions on top of it for the regular interface?

score 1 · Answer 1 · answered Nov 17 '22 at 20:46

You could put all your registers in one bank, and create two trampoline banks that bounce accesses to the "real" bank, after marking access in the aux struct. Each register can then inspect aux and apply access restrictions accordingly. Something like:

typedef struct { bool from_x; bool from_y; } aux_t;
bank x {
    param use_io_memory = false;
    shared method transaction_access(
        transaction_t *t, uint64 offset,
        void *aux) -> (exception_type_t) default {
        local aux_t aux = {.from_x=true, ...};
        default(t, offset, &aux);
    }
}
bank y {
    param use_io_memory = false;
    shared method transaction_access(
        transaction_t *t, uint64 offset,
        void *aux) -> (exception_type_t) default {
        local aux_t aux = {.from_y=true, ...};
        default(t, offset, &aux);
    }
}
template read_only_in_x is write_register {
    method read_register(uint64 enabled_bytes, void *aux) -> (uint64) {
        local aux_t *a = aux;
        if (a->is_x) {
            log spec_viol: "Write to read-only register %s", qname;
        } else {
            return default(enabled_bytes, aux);
        }
    }
}
bank z {
    // will be read-only only when accessed through bank x
    register r size 4 @ 0 is read_only_in_x;
}

score 1 · Answer 2 · answered Nov 18 '22 at 12:23

Eriks answer fits quite well if you want to put the access restriction logic in the main bank, in his case this is bank z, and then just add meta data in bank x and y describing access path.

However, an alternative solution would be to do the restrictive logic on bank x and y and only forward the accesses to bank z if it is allowed on the specific interface. That way, the logic in bank z remains clean and does not have to consider any special access interfaces.

The example code below handles restrictive access on register level and not on field level. Next example will expand to also include field level.

template register_accessor is register {
    param configuration = "none";
    method write_register(uint64 value, uint64 enabled_bytes, void *aux) {
        try {
            z.write(offset, value, enabled_bytes, NULL);
        } catch {
        }
    }
    method read_register(uint64 enabled_bytes, void *aux) -> (uint64) {
        try {
            return z.read(offset, enabled_bytes, NULL);
        } catch {
            return 0;
        }
    }
}

bank x {
    register reg0 @ 0x0 size 2 is register_accessor;
}

bank y {
    register reg1 @ 0x2 size 2 is register_accessor;
}

bank z {
    register reg0 @ 0x0 size 2;
    register reg1 @ 0x2 size 2;
}

In the example above, an access on interface x only has access to reg0 in bank z and an access on interface y only has access to reg1 in bank z.

But the question also includes access restrictions on field level which makes it a bit more complicated but perfectly doable. Here is an example of how that could be done with the same design pattern.

template field_accessor is (field) {
    shared method read_only() -> (bool);
}
template read_only_access is (field_accessor) {
    shared method read_only() -> (bool) { return true; }
}

template register_accessor is register {
    param configuration = "none";
    method write_register(uint64 value, uint64 enabled_bytes, void *aux) {
        foreach f in (each field_accessor in (this)) {
            if (f.read_only())
                enabled_bytes[f.lsb + f.bitsize - 1:f.lsb] = 0;
        }
        try {
            z.write(offset, value, enabled_bytes, NULL);
        } catch {
        }
    }
    method read_register(uint64 enabled_bytes, void *aux) -> (uint64) {
        try {
            return z.read(offset, enabled_bytes, NULL);
        } catch {
            return 0;
        }
    }
}

bank x {
    register regX @ 0x0 size 4 is register_accessor {
        field a @ [15:0] is read_only_access;
        field b @ [31:16];
    }
}

bank y {
    register regX @ 0x0 size 4 is register_accessor {
        field a @ [15:0];
        field b @ [31:16] is read_only_access;
    }
}

bank z {
    register regX @ 0x0 size 4 {
        field a  @ [15:0];
        field b  @ [31:16];
    }
}

In this example a read access of register regX is allowed on both interfaces x and y. However, on interface x it is not possible to write to field a and on interface y it is not possible to write to field b. The template register_accessor masks the bits corresponding to the read-only field before forwarding the write to bank z. You can create as many interfaces as you want without having to modify any logic in the storage bank (bank z in this example).

I would also write something in the catch block. They should never happen, right? so `log error` would make sense, or `assert false;` if you are really confident. — Erik Carstensen, Nov 21 '22 at 11:39
In a real large-scale setting you'll also want to turn `read_register`/`write_register` into shared methods for performance. It should be pretty easy to do this, but would maybe harm readability in your example. Perhaps add a comment about it? — Erik Carstensen, Nov 21 '22 at 11:43

How do I implement a DML bank that is accessed through 3 different interfaces with varying access restrictions per interface?

2 Answers2