-
Notifications
You must be signed in to change notification settings - Fork 15
CCI Inspection
The CCI WG in Accellera has created the CCI Configuration standard.
A proof-of-concept implementation of the standard is available from Accellera.
Inspection has been discussed in CCI WG as an upcoming step after configuration.
A proposal, referred to as scireg, for inspection of regions, such as registers, register banks and memories, was submitted to Accellera in August 2012.
A list of Accellera items, such as presentations and e-mails, releated to scireg and mentioning the concepts of registers and configuration parameters, but also how these topics are handled in UVM, is found in the Accellera CCI WG document folder.
CCI inspection has been discussed at SystemC Evolution Days, in 2017 in a presentation named Standardization Around Registers - What's Needed? and in 2019 in a presentation named Re-envisioning CCI Inspection.
The purpose of this document, besides giving a brief background to the topic of CCI inspection, is to collect information that can be used to formulate requirements for an inspection feature in CCI.
The document shall, if possible, also formulate explicit requirements, and indicate an outline of upcoming CCI inspection work in the Accellera CCI WG.
The main use case for CCI inspection is to enable a possibility to inspect and, where applicable, to modify entities in a SystemC simulation.
Using CCI inspection, it shall be possible to read and write values.
When reading values, it must be possible to specify from which entity the reading shall take place.
It must also be possible to figure out what parts of the entity that can be read, and how the values read shall be represented for a reader.
There are several questions to consider when reading, such as
- how can an entity be found?
- how can values inside an entity be found?
- are there side effects of reading?
- do different readers, of a specific value, see different values? (e.g. if one reader sees a little-endian value and another reader sees a big-endian value)
- do different readers, of a specific value, find the value at different places? (e.g. if the address used by one reader is different from the address used by another reader)
When writing values, there are similar questions to consider, such as
- how can an entity (to which we shall write) be found?
- how can values inside an entity be found?
- are there side effects of writing?
- in what format shall a value to be written be supplied?
- do different writers, of a specific value at a specific place, use different ways to locate the value (e.g. using different adresses?)
The readers and writers of values, in entities, might be other SystemC models.
For the purpose of CCI inspection, however, we consider the readers and writers to be "outside" of the actual model.
Two categories of such readers and writers could be
- a tool, or
- a testbench
A tool, connected to (or embedded in) a virtual platform (a.k.a. virtual prototype), might use CCI inspection to access different parts of the simulation.
A test bench, e.g. in a UVM context, might want to inspect a SystemC model, for example for accessing the registers in a DUT.
In the Accellera CCI WG document folder referenced above, we also see mentioning of UVM, in e-mails and in a presentation about complementarity and compatibility of scireg and uvm_reg.
At the SystemC Evolution Days, in 2017 and 2019, inspection of registers and memories was discussed.
It was pointed out that the actual implementations, specifically of registers, inside the SystemC models, should not be part of a CCI inspection standard.
Besides the access to individual registers and memories, the concept of discovery was mentioned. In the presentation from 2017, discovery is mentioned as something that can
- Enumerate all available registers, and
- Get the address map of all registers
The case of registers not mapped into a processor's address space was also mentioned, with SPI as example.
The possibility of inspecting the basic information associated with a register, such as bit fields, accessibility (read access, write access), and reset values, was also discussed.
The fact that the address used when accessing a register can depend on "who is looking" was also discussed.
The presentations in 2017 and 2019 both mentioned the concept of callbacks. The possibility to install callbacks, in the form of actions that are triggered when a certain inspectable entity is accessed, should be considered as a topic for the CCI inspection standard.
The presentation in 2019 also discussed the concept of inspectable variables, referred to as inspectable simulation variables and inspectable architectural variables. Such variables could be part of an individual model (one example being fill level in a buffer), or part of the overall simulation architecture (one example being an enumeration of the available AXI managers).
Inspectable variables could be part of a CCI inspection standard. They could also be considered as "already available", in the form of CCI configuration parameters.
As a generalization of enumerating the entities active on a given bus (such as AXI), it might be of interest, in the context of CCI inspection, to ask for an enumeration of the available buses in a system. This should include memory-mapped as well as non-memory-mapped buses, and it could also include other, more message-oriented and network-oriented buses.
Communication mechanisms, using e.g. Ethernet or a standard UART, should also be possible to enumerate, and inspect.
IP-XACT is standardized by Accellera and IEEE. The latest standard available from IEEE is IP-XACT_2014.
Accellera has delivered, to IEEE, a proposal for an updated IP-XACT standard. The accellera document which was delivered to IEEE is available as IP-XACT_2021.
There is also an IP-XACT User guide from Accellera.
When defining inspectable entities in CCI, it might be advantageous to take into consideration that many concepts are defined in IP-XACT.
Based on this, instead of inventing names and properties for inspectable entities in CCI, names and properties already defined in IP-XACT could be used.
This re-use can also be applied to the relations between entities, such as the relations between an address space, its included memory maps, and in turn, registers files and registers that are defined inside the memory maps.
Such relations are defined in IP-XACT, and for the example at hand, with addres spaces, memory maps, register files, and registers, the relevant sections in IP-XACT_2021 are 6.11, 6.12, and 6.14.
Register-related concepts, such as bit-fields and access rights, which have been discussed in the context of CCI Inspection at SystemC Evolution Days, are also defined in IP-XACT.
For such definitions, see Section 6.14 in IP-XACT_2021, which has definitions for register elements such as accessPolicies and field in Section 6.14.3.2, and definitions for register files (which contain groups of registers) such as addressOffset and parameters in Section 6.14.6.2.
IP-XACT also standardizes the concept of a bus. As an example of definitions, there are bus definitions in Section 5.2. in IP-XACT_2021, definitions of ports in Section 5.5 and packets in Section 5.11.
For the overall design, which might be important for CCI inspection (e.g. to answer the question "where shall I start?" when looking for inspectable entities), there is the IP-XACT definition of design in Section 7.1 in IP-XACT_2021, where it is said that a "design describes a list of components referenced by this description, their configuration, and their interconnections to each other."
It is also said that a "design description is analogous to a schematic of components".
side effects? callbacks?
[IP-XACT_2014], 1685-2014 - IEEE Standard for IP-XACT, Standard Structure for Packaging, Integrating, and Reusing IP within Tool Flows, available from IEEE
[IP-XACT_2021], Accellera IP-XACT WG Comments on 1685-2014, available from Accellera