IEEE Std 2804:2019 pdf free download – IEEE Standard for Software-Hardwarelnterface for Multi-Many-Core
A ComponentSet can nest itself.For example,it can be used to express a chip that contains multiplehardware clusters, each cluster containing multiple cores with a cluster local memory. It can also be used todescribe a board,which in turn may contain one or more multicore chips. A ComponentSet can even beused to describe a system with multiple boards,cach board connected via PCI Express,for example.Assuch,the ComponentSet tree describes the multicore hardware system topology. This topologicalarchitectural information is important for software tools to be able to identify the number of cores,thelocation 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 connectionand communication mechanism between the cores (including accelerators), as well as how these cores canaccess the different memories. The former is described as CommunicationSet containing differentcommunication classes. A simple example of defined classes is InterruptCommunication,which containsone or more“connection”classes，which binds a pair of MasterComponents.For memory access,theSubSpace contained in the AddressSpace includes its start address and size and one or moreMasterSlaveBinding, containing references to a MasterComponent and SlaveComponent, describing whichcore/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 manytools, since the application software supported by these tools must not just ‘run ‘, but run with performancequalifiers. To achieve this, the tools must ‘estimate’ the rough performance so that the system designersand software developers know the expected performance from the given application and multicorehardware. Therefore, SHIM, in addition to the hardware topological information, describes the performanceproperties associated with the processor cycles consumed to perform the various core-to-corecommunication (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 inprocessor 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, andfor each AecessType,which are defined for each MasterComponent, a specific Performance element isincluded. So， for cach different access type(e.g.，read or write,word access, or double word access), adifferent 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 beintelligent enough to benefit from these figures,such as analyzing the application code if it is issuing asequential memory access,which generally falls into the use of the ‘best’cycles. Note that the cyclesmentioned 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 theinformation 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 physicalelectrical means of inter-connects betwecnprocessing cores,the Network on Chip (NoC) protocol used to route the memory read request by aparticular core,the number of processor pipeline stages, the cache coherency protocol, etc., unless thesefeatures matter greatly to some class of tools that aid software development.
lt is tempting and relatively easy to include additional hardware properties in SHIM; however, this willresult in a more complex SHIM XML,requiring more effort to grasp the schema and complicating theeffort for tools to use this information.Furthermore,the most critical issue is the challenge to create aSHIM XML in the first place—leading to limited adoption of the SHIM standard.
The basic principle is to capture the properties that affect the sofiware at the architectural design level.This is to say, if a design-aid tool uses SHIM to produce an appropriatc software design for a particularhardware described by a SHIM XML, then the design should not require modification at the softwarearchitectural level at the later stages of system development.
Although the“software architectural design level”is the baseline, it is sometimes difficult to agree onwhether a particular hardware property is important.The rule of thumb is that if an actual(evenimaginable) use case cannot be derived, the SHIM specification excludes it.