Filling an important gap

Virtual platforms are nothing new; modelling hardware has long been a way of accelerating the development cycle by allowing parts of a system to be developed in parallel. Typically this is achieved through abstracting out those features that impact the design at a system level and allowing them to interact in some way. One method for achieving this is Transaction Level Modelling (TLM), which is used extensively in the development of integrated systems-on-a-chip (SoC).

However while TLM is robust, creating the models can be arduous and, arguably, is most effective for alleviating design bottlenecks in the hardware domain. It is widely agreed that the lion’s share of development costs are now incurred in developing software and it’s not hard to see why; a single team of engineers may be responsible for developing an SoC, but it’s likely (and economically crucial, in many cases) that the SoC will itself be used by many hundreds of development teams — each of which will most probably be developing bespoke software at some level.

The benefits of a highly integrated SoC could easily be eroded by the difficulties and delays incurred when developing the software that takes advantage of those benefits; any solution to shortening the software development cycle could prove critical. The problem is, with each SoC being an essentially unique design, how do you create a model that accurately reflects or models its features before they are entirely defined, to enable early software development?

Providing support

The problem is compounded by the increasing trend towards multicore platforms, where the key objective is performance. Many things in an SoC can impact performance, including but not exclusively the number of cores used and how the software running on those cores is executed. This scenario is further complicated by the fact that many of the methods used to achieve the very best possible performance are provided by third party tools vendors.

This complex and inter-dependent supply chain challenge is now being addressed by a new Working Group within The Multicore Association; the Software-Hardware Interface for Multi-Many Core, or SHIM (Figure 1).

Figure 1: SHIM will provide the link between multicore systems and the tools needed for software optimisation

Markus Levy, President of The Multicore Association, explained: “It’s crucial that the industry develops a standard method for describing hardware features than can be used in software development tools. It’s analogous to the world of real-time operating systems; the RTOS vendor needs to provide a new board support package for every new embedded processor — you can take this situation and multiply it by an order of magnitude if you’re trying to port development tools to the unlimited number of different SoCs. SHIM will provide that SoC description, to allow tool vendors to more easily migrate their tools to new hardware.”

Initially, SHIM will target specific pinch-points; for performance analysis tools and auto-parallelising compilers, SHIM will be able to provide the information needed to estimate performance to around 80% accuracy (the initial target). “SHIM will be used to describe the SoC’s memory hierarchy, which will have an effect on bandwidth and latency,” explained Levy. This can then be factored in by the analysis tools as well as the compiler, to figure out how to best schedule the software program.

SHIM will also be employed in system configuration, where the operating system, middleware and runtime libraries need basic architectural information to ‘self configure’. “Take, for example, middleware that supports special hardware accelerators on an SoC,” said Levy. “Even within a specific vendor’s product family, maybe the hardware accelerator changes from generation to generation, so providing a description of the hardware accelerator in SHIM format could enable a tool that auto-configures the middleware.” PolyCore Software, one of the member companies participating in the SHIM Working Group, is an example of this.

In addition, SHIM should also provide a quicker and easier way to set up a simulator for hardware modelling, including third-party IP, as long as the vendor provides a SHIM description. For example, parameters or parameter ranges for a Serial RapidIO (SRIO) link between two chips could be derived from a SHIM XML description of the SRIO device (Figure 2).

Figure 2: SRIO configuration example from Poly-Platform, a multicore programming platform from PolyCore Software

Optimising performance

The concept of SHIM came from a project to build a standardised ecosystem to support multicore platforms, funded by the Japanese government. One of the companies to benefit from that funding was eSol and Masaki Gondo, Software CTO and GM of eSol, is now chairing the SHIM WG. Other Multicore Association members on the WG include Freescale, TI, Renesas Electronics and Mentor Graphics, as well as Vector Fabrics. Jos van Eijndhoven, CTO and Co-Founder of Vector Fabrics, commented: “Optimising for multicore is far too often a trial-and-error game. Attempts at parallel execution can even slow down the application program. Caching and non-uniform memory leave the programmer in the dark and the programmer must always take such hardware specifics into account for every new architecture. Even for a 100-line compute kernel this is a daunting task for an expert; for larger code bases, forget it. Analysis tools must go beyond profiling to help create the right parallel design; with SHIM’s uniform way of describing hardware, parallel development tools like Vector Fabrics’ can help programmers optimise their code for a wide range of multicore architectures.”

eSol’s Gondo believes that SHIM will enable successive generations of SoCs to be supported without the need for extensive tool upgrades. The Working Group expects to complete the first draft of the specification in 2014.

“Some vendors might perceive standards to limit their ability to comprehensively express the functionality of their products,” commented Levy. “However, while SHIM will be a very complete specification, it will also include some optional capabilities to allow vendor customisation.”