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.hu...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
