Virtual regfile (regfile within mem) supported in SystemRDL?

[Mike Trim]

I am currently trying to create a SystemRDL representation of the address map for an existing design.  In this particular design there is a configuration table which in the RTL is implemented as a RAM block, and which (from the software point of view) contains a repeating pattern of several registers.  Ideally I would represent this as a regfile array within the mem, e.g.:

addrmap {
    mem {
        mementries = 2048;
        memwidth = 32;
        regfile {
            reg {
                regwidth = 32;
                field {} x;
            } foo @0x0;
            reg {
                regwidth = 32;
                field {} x;
            } bar @0x4;
        } xyz[1024] @0x0 += 0x8;
    } external abc @0x0;
} top_map;

systemrdl-compiler rejects this ("Definitions of 'regfile' components not allowed inside a mem definition"), which indeed seems consistent with SystemRDL 2.0 section 11.1(b)(1):

i)  Component definitions are limited to field, reg, constraint, and enum components.
ii) Component instantiations are limited to reg and constraint instances.

However IP-XACT seems to allow this (IEEE Std 1685-2014 section 3.1):

Quote

virtual register: A collection of fields, overlaid on top of a memory, usually in an array.  The semantics and layout of virtual registers come from an agreement between the software and hardware.  Virtual registers are modeled in IP-XACT by creating register instances within addressBlocks with usage memory.  The child elements of a virtual register are restricted to a subset of the overall register element.

virtual register file: A grouping of virtual registers.  A virtual register file is modeled using the registerFile element in an addressBlock element with usage of memory.  The children of virtual register files shall be virtual.

and other references in the SystemRDL spec seem to imply it is a possibility:

3.1:

memory: A contiguous array of memory data elements. A data structure within a memory can be specified
with virtual registers or register files.

11.2(f):

f)  Virtual registers, register files, and fields shall have the same software access (sw property value) as
the parent memory.

So, is the omission of regfiles from section 11.1(b)(1) in SystemRDL accidental, or is it really not intended to be supported?

And if it isn't supported, is there a recommended way to represent this type of structure, without changing the memory layout of the existing design?  I did try representing as overlapping arrays of reg with a stride equal to the register file width, but systemrdl-compiler doesn't support overlapping (even if each individual register is at a different address).

[Richard Weber]

Hello Mike,

There are two issues with the example.

First, SystemRDL 2.0 does not support virtual regfile components as specified in semantic rule 11.2c:

csrCompile: ERROR: in file 'virtualRegfile.rdl' line 30:
csrCompile:        SystemRDL 2.0 11.2c, regfile cannot be instantiated in mem at:
csrCompile:        'xyz'

As my role as committee member of both IP-XACT and SystemRDL I championed the virtual objects within memories.  However, UVM does not define a virtual reg_file class, and, the SystemRDL 2.0 committee voted to follow the UVM limitation. I agree that some conflicting text from an early draft remains in the normative text, and, I have updated the SystemRDL committee post public review list of issues with the text mentioned above in 3.1 and 11.2(f).

Overlap is forbidden in all the Accellera standards related to registers (SystemRDL, IP-XACT and UVM). All the alternatives I considered do not meet your requirements.

Second, the example has additional semantic rule violation of the normative text in section 5.1.4:

csrCompile: ERROR: in file 'virtualRegfile.rdl' line 32:
csrCompile:        SystemRDL 2.0 5.1.4, addrmap cannot be instantiated in root scope at:
csrCompile:        'top_map'

 

Quote

Section 5.1.4:

The root scope shall only contain component type and struct type definitions and signal instantiations. No other component instantiations shall be allowed in the root scope. The root(s) of an addrmap hierarchy are those addrmaps that are defined, but not subsequently instantiated.