IEEE 2804‐2019 pdf free

IEEE 2804-2019 pdf free.IEEE Standard for Software-Hardware Interface for Multi-Many-Core.
A ComponentSet can nest itself. For example, it can be used to express a chip that contains multiple hardware clusters, each cluster containing multiple cores with a cluster local memory. It can also be used to describe a board, which in turn may contain one or more multicore chips. A ComponentSet can even be used to describe a system with multiple boards, each board connected via PCI Express, for example. As such, the ComponentSet tree describes the multicore hardware system topology. This topological architectural information is important for software tools to be able to identify the number of cores, the location of the memory devices, and how cores are organized into different clusters.
Since SHIM is for software tools, it is essential to understand from a software perspective, the connection and communication mechanism between the cores (including accelerators), as well as how these cores can access the different memories. The former is described as CommunicationSet containing different communication classes. A simple example of defined classes is InterruptC ommunication, which contains one or more“connection” classes, which binds a pair of MasterComponents. For memory acess, the SubSpace contained in the AddressSpace includes its start address and size and one or more MasterSlaveBinding, containing references to a MasterComponent and SlaveComponent, describing which core/accelerator can access which memory through the address range.
The hardware architectural information described so far allows tools to understand the hardware topology, and how the cores and memory devices are connected. However, this alone is often insufficient for many tools, since the application software supported by these tools must not just ‘run’, but run with performance qualifiers. To achieve this, the tools must “estimate’ the rough performance so that the system designers and software developers know the expected performance from the given application and multicore hardware. Therefore, SHIM, in adition to the hardware topological information, describes the performance properties associated with the processor cycles consumed to perform the various core-to-core communication (CommunicationSer) and also the memory access cycles by different cores and accelerators.
The performance is described as Performance element, which contains Latency and Pitch, expressed in processor cycles. The Performance element exists for each CommunicationSet, for each specific pair of two MasterComponents. For memory access performance, for each MasterSlaveBinding of each SubSpace, and for each AccessType, which are defined for each MasterComponent, a specific Performance clement is included. So, for each different access type (e.g, read or write, word access, or double word access), a different Performance element is provided. The cycles can be described in a form of the triplet, which is ‘best’，, ‘typical’, and ‘worst’, to accommodate the possible performance variance. The tool must be intelligent enough to benefit from these figures, such as analyzing the application code if it is issuing a sequential memory access, which generlly falls into the use of the ‘best’ cycles. Note that the cycles mentioned here are processor-cycles, whose related frequency is defined using OperatingPoints.
1.4.2 Software view- -what is in and what is not Tools should primarily use SHIM to aid developing software that runs on multi-many-core hardware.
Therefore, the key strategy in defining the SHIM specification is to describe the hardware but only for the information that is relevant to such tools. This is referred to as a *software view’ of hardware, as opposed to “hardware view”, where the focus would be the physical/electrical means of inter-connects between processing cores, the Network on Chip (NoC) protocol used to route the memory read request by a particular core, the number of processor pipeline stages, the cache coherency protocol, etc., unless these features matter greatly to some class of tools that aid software development.
It is tempting and relatively easy to include additional hardware properties in SHIM; however, thisill result in a more complex SHIM XML, requiring more effort to grasp the schema and complicating the effort for tools to use this information. Furthermore, the most critical issue is the challenge to create a SHIM XML in the first place- leading to limited adoption of the SHIM standard.
The basic principle is to capture the properties that affe the sofiware at the architectural design level.
This is to say, if a design-aid tool uses SHIM to produce an appropriate software design for a particular hardware described by a SHIM XML, then the design should not require modification at the sofware architectural level at the later stages of system development.
Although the“sofware architectural design level” is the baseline, it is sometimes difficult to agree on whether a particular hardware property is important. The rule of thumb is that if an actual (even imaginable) use case cannot be derived, the SHIM specification excludes it.
For various reasons, a number of potential hardware properties have not been included in the current specification. One of the primary reasons is that the excluded types of hardware properties are peripheral to ex isting properties in the specification. Such hardware properties may be included in a future version of the specification, but it was decided to take an evolutionary approach and stabilize the more basic properties first.
The most basic properties selected for inclusion in SHIM are the following: topology, address space, intercore communication, and performance and configuration.IEEE 2804 pdf download.