[PATCH v2] eng: Add register block specification types

Fri Apr 14 19:51:02 UTC 2023

I read this discussion, and it's pretty fascinating. I just want to
point out that "linear address" and "linear address space" are both
terms defined in Intel documentation for the address you get after
doing segmentation but before paging. Just to further complicate the
choice of terminology. :)

On Tue, Mar 28, 2023 at 2:16 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> On 28.03.23 07:53, Chris Johns wrote:
> > On 23/3/2023 3:59 am, Sebastian Huber wrote:
> >> Hello Chris,
> >>
> >> I would like to come back to this topic, because it blocks the integration of
> >> the sparc/gr712rc and sparc/gr740 changes we have done for the pre-qualification
> >> activity.
> >>
> >> On 27.09.21 02:23, Chris Johns wrote:
> >>> On 24/9/21 11:09 pm, Sebastian Huber wrote:
> >>>> A register block may be used to specify the interface of devices which
> >>>> use a linear address space.  Register blocks consist of register block
> >>> Can we please move away from the "linear address" in the definitions? As stated
> >>> previously it only serves a specialized version of a bus and register-block.
> >>> What about something like this:
> >>>
> >>> A register block specifies a word addressable set of elements in a device
> >>> software is required to access and manipulate. The mechanics software uses to
> >>> access a register element in a register-block is defined by the bus-interface.
> >>> The software and register may be a direct coupling to the CPU bus as found in a
> >>> linear cache coherent memory mapped device or the access may be indirect through
> >>> a bus hierarchy that may require more than one software action to complete.
> >>> Device and register specifications are independent of the CPU architecture and
> >>> connecting bus architectures.
> >> A linear address space is just an address space in which a single integer is
> >> sufficient to address something. So a word addressable set of elements in a
> >> device is a linear address space. In contrast to for example the AArch32 system
> >> register space, which uses a coprocessor index, Opcode_1, CRn, CRm, and
> >> Opcode_2. An address space granule is the smallest block of memory that can be
> >> addressed. This could be a subword depending on what a word is and the bus
> >> system capabilities.
> > I am sorry I have read and reread this and I do not follow. I do not know if you
> > are saying the aarch64 cp access and addressing is an example for or a counter
> > example?
>
> The AArch32 system registers are an example for a not linear or
> segmented address space.
>
> >
> > The term "linear address" offers no value. An address bus at any point in a
> > circuit is are collection of signals wired to the address decoder of a device so
> > by the nature of how that works it is going to resolve itself to a number and to
> > be accurate it is a whole number because the concept of negative addressing
> > would be interesting. The wiring of the interfacing address to a device's
> > address bus does not have to be 1:1 and it does not need to be continuous in the
> > external interface's addressing scheme. If linear is saying there is a series of
> > numbers then again I wonder what the value is. You can view this in datasheets
> > and code that maps struct to memory mapping devices because reserved (or what
> > ever they get called) are added. Adding these reserved etc fields is doing
> > nothing more than making a memory mapped struct work as you hope and I mean
> > hope. That logic needs a continuous address space.
>
> The register block specification is used to specify a device which
> consists of registers with an address. Each register consists of bit
> fields. We need a name for the address space of the register block
> specification and linear address space is from my point of view the best
> name for an address space in which an address is simply an unsigned
> integer. How would you name it?
>
> The register block specification does not specify a bus system. It just
> transfers what you have documented in a datasheet of a device. I did
> read quite a lot of datasheets and the register block specification
> resulted from this experience. Do you have a datasheet which would be
> difficult to translate into the proposed scheme?
>
> Actually the register block specification for the Gailser IP Library was
> done by translating the PDF
>
> https://www.gaisler.com/products/grlib/grip.pdf
>
> into a text file, parsing the text file with a Python script and then
> generating the specification files:
>
> https://git.rtems.org/rtems-central/tree/spec/dev/grlib/if
>
> This work was reviewed by the ISVV activity:
>
> https://devel.rtems.org/ticket/4842
>
> >
> >> The offsets in the register block specification are just the offset you find in
> >> the corresponding datasheet.
> >>
> >>> I know this is just the commit message but I think this should be in the manual.
> >>>
> >>> bus-interface:
> >>>
> >>> A bus interface is the mechanics software uses to access a register word element
> >>> in a device. A bus interface specifies the requirements needed by software to
> >>> access a register word. It must consider timing, CPU word size to device word
> >>> size, byte ordering for word sizes greater than 8bits, cache considerations and
> >>> sequencing of multiple software accesses if required.
> >>>
> >>> I would like to see a bus-interface section and the device reference it. It only
> >>> needs to cover the type of bus interface you need to specify at this point in
> >>> time.
> >> At the moment I just have a header file generator for memory-mapped devices. I
> >> don't think there will be major issues to adopt the generator to output
> >> interfaces for some bus space API.
> > I think the language used is too specific to memory mapped devices.
> >
> >>>> use a linear address space.
> >>>> members specified by the ``definition`` attribute.  Register block
> >>>> members are either instances of registers specified by the ``registers``
> >>>> attribute or instances of other register blocks specified by links with
> >>>> the "register-block-include" link role.  Registers consists of bit
> >>>> fields.
> >>> Registers are defined in terms of the device word size. The bus interface needs
> >>> to deal with the CPU word size to device word size.
> >> I don't think that a single "word size" is sufficient. A device may have
> >> registers of different sizes. For example an array of 8-bit registers with
> >> priorities and a 32-bit status register. Some devices may only have 64-bit
> >> registers, so here using a "word" makes sense, but not in the general case.
> > The data size is wired and fixed. There is nothing dynamic happening here. This
> > is the word size of the device I am talking about. Accessing parts of device's
> > word size is a function of the bus it is connected to and the ability of the
> > device to control the data pins it outputs data on. Different buses handle this
> > in different ways.
>
> You have to view the register block specification simply as a human and
> machine readable datasheet for a device. Please don't mix in the bus
> system. The bus system is currently not covered by the specification. We
> could add this if needed. I don't need it at the moment.
>
> >
> >>> Is the bit ordering the CPU architecture order or some other form of ordering?
> >> It would be up to a bus interface specification to deal with bit orderings. For
> >> an isolated register block specification the bit ordering should match with the
> >> datasheet.
> >>> The register block members are placed into the address space of
> >>>> the device relative to the base address of the register block.  Register
> >>>> member offests and the register block size are specified in units of the
> >>>> address space granule.  The address space granule is usually 8-bits also
> >>>> known as one byte.
> >>> This paragraph would be much simpler and clearer if defined in terms of a bus
> >>> interface. The use of "usually" could be avoided.
> >> Ok, I will move the "usually" stuff to a paragraph which states what the
> >> abstract terms mean if you have a memory-mapped device.
> >>
> >>>> Update #3715.
> >>>> ---
> >>>> For examples see:
> >>>>
> >>>> https://git.rtems.org/rtems-central/tree/spec/dev/grlib/if
> >>>>
> >>>> v2:
> >>>>
> >>>> Clarify wording and remove the "register-block-type" attribute.
> >>>>
> >>>>    eng/req/items.rst | 322 ++++++++++++++++++++++++++++++++++++++++++++++
> >>>>    1 file changed, 322 insertions(+)
> >>>>
> >>>> diff --git a/eng/req/items.rst b/eng/req/items.rst
> >>>> index e1b64b6..924e79d 100644
> >>>> --- a/eng/req/items.rst
> >>>> +++ b/eng/req/items.rst
> >>>> @@ -103,6 +103,8 @@ The specification item types have the following hierarchy:
> >>>>          * :ref:`SpecTypeInterfaceVariableItemType`
> >>>>    +    * :ref:`SpecTypeRegisterBlockItemType`
> >>>> +
> >>>>      * :ref:`SpecTypeRequirementItemType`
> >>>>          * :ref:`SpecTypeFunctionalRequirementItemType`
> >>>> @@ -1143,6 +1145,8 @@ This type is refined by the following types:
> >>>>      * :ref:`SpecTypeInterfaceVariableItemType`
> >>>>    +* :ref:`SpecTypeRegisterBlockItemType`
> >>>> +
> >>>>    .. _SpecTypeApplicationConfigurationGroupItemType:
> >>>>      Application Configuration Group Item Type
> >>>> @@ -1615,6 +1619,68 @@ name
> >>>>    notes
> >>>>        The attribute value shall be an :ref:`SpecTypeInterfaceNotes`.
> >>>>    +.. _SpecTypeRegisterBlockItemType:
> >>>> +
> >>>> +Register Block Item Type
> >>>> +^^^^^^^^^^^^^^^^^^^^^^^^
> >>>> +
> >>>> +This type refines the :ref:`SpecTypeInterfaceItemType` through the
> >>>> +``interface-type`` attribute if the value is ``register-block``.
> >>> bus-interface rather than interface-type?
> >>>
> >>>> This set of
> >>>> +attributes specifies a register block.  A register block may be used to specify
> >>>> +the interface of devices which use a linear address space.
> >>> How about ...
> >>>
> >>> A register block is a set of bus interface addressable device words. Offset
> >>> values are relative to the device's address bus.
> >>>
> >>>>    Register blocks
> >>>> +consist of register block members specified by the ``definition`` attribute.
> >>>> +Register block members are either instances of registers specified by the
> >>>> +``registers`` attribute or instances of other register blocks specified by
> >>>> +links with the :ref:`SpecTypeRegisterBlockIncludeRole`.  Registers consists of
> >>>> +bit fields (see :ref:`SpecTypeRegisterBitsDefinition`.  The register block
> >>>> +members are placed into the address space of the device relative to the base
> >>>> +address of the register block.
> >>> This should be part of the bus-interface not the register block.
> >> What I would like to specify is a set of registers. Each register has an address
> >> and contains a set of bits. I really don't understand what is the point with the
> >> bus interface here. All the datasheets I have seen so far use one or more
> >> integers (or enumerators) to identify a register and a registers contains a
> >> certain amount of bits. I used this register block specification also for
> >> network switches which are accessed through SPI.
> > This is true for a lot of stuff that is wired into devices like SoCs. I work
> > with FPGA designers and the addressing they provide is relative to their IP's
> > address bus and not the final wired address bus, eg A0 of a device may be wired
> > to A2 of a CPU.
>
> Yes, I don't see an issue here with the register block specification.
> The offset in the register block specification could be the address
> relative to the IP's address bus.
>
> >
> >>> Register member offests and the register block
> >>>> +size are specified in units of the address space granule. The address space
> >>>> +granule is usually 8-bits also known as one byte. All explicit attributes shall
> >>>> +be specified.
> >>> This may only be true for a linear memory mapped cache coherent bus-interface.
> >>> The register block spec becomes much simpler with the introduction of a bus
> >>> interface construct as most of these words could be removed.
> >>>
> >>> And for you the bus-interface is simply "linear memory mapped cache coherent"
> >>> and in that you only need a simple statement on CPU word to device word mapping,
> >>> ie 1:1, the timing, ie timing is controlled by the CPU bus interface, and cache
> >>> coherence, ie the mapped address space needs to be cache coherent.
> >>>
> >>> An important aspect of this approach to the specification is the implementation
> >>> is not detailed and if you wish to implement volatile structs and pointers
> >>> (<shudder>) or alternatively inline functions you can. The specification is the
> >>> same.
> >> I don't see a restriction here with the current specification approach. You can
> >> use a register bock specification and generate code for a particular bus system.
> >> You just have to know the bus system.
> > It is up to you to consider what I have offered. My hope is to avoid this being
> > a template for struct based memory mapped IO however in the end it will be what
> > you think you need.
>
> It is not limited to memory mapped IO because the bus system part is not
> specified. It is very simple. It is basically just a table like this:
>
> Address | Register Name | Bit Fields
> 1 | A | X[0] Y[1:5] Z[8:23]
> 7 | B | U[0:31]
> ... | ... | ...
>
> I will now prepare a v3 of the patch with adjustments in the wordings.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel