A Lightweight Infrastructure for the Dynamic Creation and
Configuration of Virtual Platforms
Christian Sauer
Cadence Design Systems, Munich, Germany sauerc @ cadence.com
Hans-Peter Loeb
Cadence Design Systems, Munich, Germany loeb @ cadence.com
Abstract—Virtual prototypes leverage SystemC/TLM for simulating programmable platforms comprising 100s of modules. Their efficient creation and configuration is vital for acceptable turnaround times, e.g., during performance exploration or software development. Therefore, our lightweight infrastructure provides a factory creating designs from abstract descriptions of module instances, properties, and connections. Modules mark properties as creation or runtime parameters. The resulting generic design descriptions are usable by non-experts and enable front-ends. The infrastructure is a small C++ library that can be combined with existing SystemC/TLM models and simulation kernels. An industrial case study of a complex multiprocessor SoC shows a distinct productivity gain.
I. INTRODUCTION
SystemC/TLM-based models have become the means of choice for most companies building virtual prototypes of complex, pro-grammable SoC platforms. These prototypes are composed of 100s to 1000s transaction-level model modules of embedded processors, het-erogeneous memory hierarchies, distributed interconnect networks, and peripheral components [3].
Dynamic creation, i.e., composition from pre-compiled modules, and configuration of an instance of such virtual platforms is required for acceptable startup and turnaround times in the development and deployment flow. However, SystemC does not provide the required infrastructure. Only by avoiding code changes and recompilation, properties of a virtual platform can be modified quickly, such as the number and type of processors in the design, SoCs on a board, or the size of the memories. This enables specialized platform variants which are tailored to the use case at hand, consuming fewer resources and starting up much faster.
Many use cases rely on frequent changes of model parameters and benefit from a quick startup. For example, the user must wait for startup in interactive sessions during pre-silicon SW development. Large-scale platforms often come with regression suites for HW and SW that are comprised of many small tests running only 10s of seconds each and hence benefit from quick startup. Tests can often be restricted to a tailored subset of the overall system for faster simulation. A key problem during design space exploration is the efficient generation of platform instances, which also depends on construction and configuration parameters to be easily accessible. In addition, a quick turnaround makes initial assembly of a virtual platform more productive.
The advantage of a dynamic creation and configuration infrastruc-ture for these use cases is shown in Figure 1. In the conventional approach, a SystemC design is first compiled statically. Once the executable is invoked, instantiation of a hardwired design description (static create) is performed during simulator startup before the actual simulation is started. This means, that a recompile of the top-level testbench is required after each modification. If, in addition, configu-ration must be changed inside a submodule, the overall startup time may even exceed simulation runtime due to dependency checking
compile time simulator executable runtime
recompile & linkage of submodules recompile of top sim startup static create simulate ... compile time simulator executable runtime time saved with factory factory overhead sim startup dynamic create simulate ... startup time simulation time Fig. 1. Comparison of time to reach start of simulation (startup time) for static vs. dynamic creation of a virtual platform instance. Execution of the simulator executable is shown in green colors.
and re-compilation. This is opposed to the dynamic approach, where the design is flexibly instantiated from a textual design description and pre-compiled modules (dynamic create) once the executable is invoked. Even though dynamic creation inevitably entails a small startup overhead, it avoids recompilation in use cases where only configuration or topology is changed.
Thus, dynamic creation relies on a generic means to configure mod-ules at creation time. Only if a model’s parameter space is accessible, a factory infrastructure reaches its full potential. The configuration infrastructure can also be used at run time for control and inspection purposes, such as changing of verbosity levels, switching of processor modes, or retrieval of internal state of modules.
Usability is key to achieve broad adoption by users and to improve productivity. Modules must be loadable from libraries that can be exchanged and updated on-the-fly. Configurable parameters must not add to the complexity of a module’s code or impede run time per-formance. The design descriptions must be natural and lightweight. There must be no limitation on how the configuration mechanism is used through files, the command line, or external tools.
We present a lightweight infrastructure for dynamic creation and configuration that can be added to any SystemC/TLM design. It provides a factory for the design, a composite module class, a component factory, and a means for configuration through attributes. The factory dynamically generates, configures, and connects a hier-archy of modules from a textual design description. Modules expose attributes which store state or expose creation or run time parameters. Key contributions are:
• It is shown how the combination of a factory infrastructure with making a model’s parameter space accessible enables the fully dynamic creation of SystemC/TLM-based virtual prototypes and their configuration at startup or run time.
format for design descriptions can be used by non-experts and enables use of front-ends (graphical, etc.). Our attributes do not impose overhead on the module developer, as they provide operator overloads, support for user-defined data types, and automatic registration facilities. Modules are registered with the factory in a modular fashion by linking or dynamically loading. • The infrastructure is a lightweight C++ library that overlays the SystemC kernel and simulation tools without requiring any changes.
The key benefit is a distinct increase of productivity, and an overall increase of the value proposition of virtual prototypes. Startup and turnaround times can be greatly reduced, configuration interfaces are unified, and prototype assembly becomes feasible for non-experts. Pre-compiled libraries become easy to use and integrate, and the full spectrum of use cases becomes accessible.
Restrictions of SystemC still apply to the dynamic creation of SystemC objects, namely, the SystemC hierarchy must be created and fully connected before the start of simulation(). Dynamic creation thus means that the factory creates and binds all SystemC objects at runtime during the execution of the sc main() function, but changes to the module hierarchy are not possible during simulation time.
In the next section of this paper, we discuss related work. Sec-tion III then describes our infrastructure. SecSec-tion IV characterizes and evaluates a real-world virtual prototype. We conclude in Section V.
II. RELATEDWORK
Approaches related to our infrastructure exist, but only the tailored combination of a configuration infrastructure with factory facilities enables truly dynamic and efficient creation and configuration of virtual platforms. Existing approaches fall short of sufficiently ad-dressing both facets, are not lightweight and readily available, do not support SystemC/TLM, focus on modeling single modules, or are not easy enough to use in industrial settings.
Comprehensive system-level frameworks exist [6][1] that feature instance configuration and creation, but they have a much broader scope, e.g., design space exploration and functional modeling. They do not support SystemC/TLM and cannot be easily combined with existing environments in industrial settings.
Configuration-only efforts tailored for SystemC-based virtual plat-forms exist as part of the Greensocs initiative [13]. Subprojects GreenControl and GreenConfig strive for vendor-independent control and introspection, both at creation and at runtime, but do not address creation. Their parameter class offers similar features than our attributes. However, the overall infrastructure is more heavy-weight and embedded in the Greensocs environment. There is no support for extended attributes or easy to use automatic registration. These efforts have been continued as part of the Accelera CCI draft initiative [14], focusing on an interoperable, interface-based approach to tool-to-model configuration. A means for dynamic creation is not in the scope of the initiative. An overview of other academic and commercial approaches is given in [13].
Simics has a Python-based infrastructure for configuration and cre-ation of virtual prototypes modeled in Simics [10]. This infrastructure is used for configuration and checkpointing in SystemC in [11], where a static model is configured via GreenControl parameters. Similarly, ReSP [2] is a Python-based simulation and debugging platform focusing on real-time SW. It provides introspective capabilities that rely on the availability and the static parsing of C++ code, which is susceptible to error and does not distinguish relevant parameters from internal state. It has means for instantiation of modules in Python, but does not address, e.g., construction time parameters, handling of
Factory Design description (netlist + Attributes) Composite (top) Composite (subsystem) Module A (incl. Attributes) Component Factory creates Attributes top { module A{ x 1234 y 5678 z 3141 } module B{ a 111 } ... } Module B (incl. Attributes) SystemC Model instantiates requests
Fig. 2. Creation and configuration infrastructure.
hierarchy, handling of a library of modules, or binding of TLM 2.0 interfaces. The dependency on Python and code transformation is heavyweight and limits usability in certain use cases.
Commercial approaches for creation exist [5], however, their configuration capabilities are limited, and they rely on the under-lying vendor-specific simulation infrastructure, as opposed to our lightweight overlay library.
Our efforts are orthogonal to specification languages such as IP-XACT [4]. In fact, an IP-IP-XACT description can conceptually be con-verted into our flat, fully populated description format, and vice versa. XML-based descriptions [1] are hard to use by humans. UML and other model-based approaches focus on description of the internals of the model, its function, or verification of its interconnect [12][9]. This is opposed to our composition infrastructure that is orthogonal to modeling module internals, and that relies on SystemC/TLM to ensure proper binding based on named binding.
Dynamic creation and introspection are well-known problems in software engineering. However, C++ has poor support for introspec-tion, and factory patterns [7] alone lack registration of modules, means for their configuration, and binding of SC ports. None of which can be readily provided ad-hoc, e.g., by tailoring makefiles, a customizable top-level, or devising model-specific single-purpose C++ configuration interfaces.
Automatic registration of embedded components in the design hi-erarchy via a hidden name stack has been used in the implementation of the SystemC kernel.
III. CREATION ANDCONFIGURATIONINFRASTRUCTURE
An overview of our creation and configuration infrastructure is shown in Fig. 2. Attributes expose the configurable state of the model. The structure of the model including instance names and module types, its connections, and its configuration are specified in a common Design Description. This description is passed to the infrastructure’s Factoryprior to elaboration. The Factory in turn creates a recursive Composite module that instantiates, configures, and connects the design at each level of hierarchy. A Component Factory is used to create instances of pre-registered types and to provide SystemC binding information.
A. Attributes
SystemC modules can be parameterizable both at creation and run time, and they can have debuggable state to inspect at run time. These aspects are addressed by parameter-like Attributes that are designated by the module developer by instantiating an appropriate object of
type BasicAttribute in lieu of a member variable. The main design objective for such attributes in our infrastructure is that they must be usable by the module developer like ordinary class members, while at the same time being accessible from the outside of the module and even outside the model, e.g., by a tool.
Listing 1. Attribute usage examples.
c l a s s ModuleA { B a s i c A t t r i b u t e <i n t > x ; BASIC ATTRIBUTE ( i n t , y , 5 6 7 8 ) ; BASIC ATTRIBUTE N ( i n t , z ) ; ModuleA ( A t t r i b u t e N a m e an ) : x ( ” x ” , 1 2 3 4 ) , z ( 3 1 4 1 ) { i f ( t h i s −>x > t h i s −>y ) / / u s e l i k e p r i m i t i v e ( t h i s −>z ) + + ; / / C++ member v a r i a b l e s } } ;
Listing 1 shows usage examples. Like any C++ member variable, attributes have an underlying type, an identifier, and must be initial-ized with a default value. In addition, a textual name of the identifier is needed, similar to SystemC object names. Attribute x uses a direct declaration, and hence needs further initialization in the module’s constructor. Convenience macros as used for y and z improve usability and do not require additional initialization. In the example, the syntax for z is closest to that of an ordinary member declaration and hence best suited for migrating existing modules. Attributes are usable in operations and conversions, as appropriate operators are overloaded. The ExtendedAttribute class wraps arbitrary user-defined data types such as string or sc time to be accessed as attributes. By making such data types direct parents of ExtendedAttribute, all original member operations can be used transparently.
Attributes can be associated with get/set callbacks that are invoked upon external access to the attribute. For example, this allows to read out SystemC time, to enable/disable features at run time, or to provide adapters to existing modules that require, e.g., configuration via function calls.
Attribute values are represented externally as strings, as strings are an easy to use, portable, and uniform way of representing data struc-tures. A templatized mapper separates the task of (de)serialization from the attribute’s access mechanics: Mappers are provided for all basic types via boost’s lexical cast [8], strings are trivially serialized, and enumerations are converted to numbers. More mappers can be added as needed for ExtendedAttribute classes.
Attributes are embedded into Attribute Containers. From an outside perspective, these containers provide access to the em-bedded attributes. Leveraging a mechanism similar to SystemC’s sc module name, Attribute Containers automatically associate any attribute instantiated within their scope at creation time. They are extensible in nature, and attributes can also be added at run time. Attribute Containers form a hierarchy, or tree, that can be different from the SystemC hierarchy. In our infrastructure, such a hierarchy and embedded attributes are represented externally as a boost property tree [8], which can be serialized into INFO or Json formats. This is exemplified on the right-hand side of Figure 2.
A class diagram of the attribute implementation is given in Fig-ure 3. The implementation follows a handler approach with a common superclass. The handler method allows for a property tree to be set or retrieved from any entity. This decentralized and uniform approach enables local access - at any level of hierarchy - to the embedded sub-tree. Tree operations can be performed to get or set subtrees. The lean handler interface can also be extended, e.g., to make registers
visible as attributes. Global, external access is achieved via a hidden root Attribute Container that comprises all other Attribute Containers and attributes. The global access function lazily generates a map to speed up frequently accessed attributes. Using global access rather than local handler-based access from within the model is considered bad practice, as it violates module encapsulation.
AttributeBase Basic Attribute Attribute Handler Attribute Container Extended Attribute sc_core:: sc_module attr_module
Fig. 3. Attribute implementation class hierarchy.
Attributes are an integral part of the factory concept, because they allow to configure modules independent from their constructor parameters. The concept of initial values is introduced to enable use of attributes in constructors: Attribute values that cannot yet be consumed at the time of their setting are stored in the embedding Attribute Container; once the respective attribute is created at a later point in time they are retrieved and become immediately available as an attribute’s default value. Initial values can be provided by entities higher up in the design hierarchy or be overridden on the command line. The first specified initial value always has highest precedence. Since initial values also take precedence over any initialization in a module’s code, parameters in constructors can be made optional and overridable through the attribute interface. In the example of Listing 2, an initial value for a takes precedence over an explicit constructor parameter param a, which takes precedence over default value 111. This provides an effective way to use modules both, in the factory setting and in a conventional way relying on constructor parameters.
Listing 2. Initial value usage.
c l a s s ModuleB { BASIC ATTRIBUTE N ( i n t , a ) ; ModuleB ( A t t r i b u t e N a m e an , i n t p a r a m a = 1 1 1 ) : a ( p a r a m a ) { . . / / u s e t h i s−>a a s u s u a l } } ; B. Design Description
The attributes’ property tree representation of the hierarchy of vis-ible and configurable state is extended to fully describe a hierarchical system. For this, the tree is enriched by two keywords, classname and connections, and a wrapping sc module class Composite is introduced. Keyword classname associates every leaf instance with a pre-defined type, e.g., a user-defined module or a basic SystemC type such as a socket, to be created by the factory. The Composite serves as an otherwise empty wrapper to specify the subsystem at each level of hierarchy and comprises the embedded instances as well as a section named connections specifying the connections at its level of hierarchy. Sockets and SystemC ports instantiated explicitly in a Composite serve as inputs and outputs of the subsystem. Endpoints of connections are specified by sc object name. An example description
in INFO format [8] is given in Listing 3. Note that initial values for Attributes now override default values given in previous example listings.
Listing 3. Hierarchical design description.
t o p { c l a s s N a m e C o m p o s i t e Module A { c l a s s n a m e ModuleA x 12 y 56 z 31 } Module B { c l a s s n a m e ModuleB a 1 } s u b s y s t e m { c l a s s n a m e C o m p o s i t e . . . h i e r P o r t 1 { c l a s s n a m e s i m p l e i n i t i a t o r s o c k e t } c o n n e c t i o n s { . . . } } c o n n e c t i o n s { s u b s y s t e m . h i e r P o r t 1 module B . t a r g e t 1 moduleA . i n i t i a t o r 1 module B . t a r g e t 2 } } C. Component Factory
In C++ the problem arises of creating an instance of a user-defined type from a textual representation only. This problem is in principle addressed by the well-known factory design pattern [7]. An abstract Component Factory creates an abstract product without type information, a concrete Component Factory provides type information as a template parameter to a concrete product.
However, types must be known to the Component Factory. Often this is done in a hard-wired factory method. But in the virtual prototype setting, arbitrary sets of types must be created, that may change frequently or that are not known at compile time of the factory. We propose an easy-to-use method that registers a module’s name and type with a singleton registry, as shown in Listing 4. The registration takes place upon loading of the module via a hidden global variable, independent of whether the module’s object code is linked statically or loaded dynamically. There is no limitation on the types of objects that can be constructed, such as user-defined SystemC modules, SystemC primitives, or other user-defined non-SystemC entities.
The Component Factory follows an extensible and modular ap-proach. For example, an enhanced version can be configured to try loading a shared library from a given directory with pre-compiled modules if the requested module type is otherwise unknown.
Listing 4. Type registration with factory.
. cpp : n a m e s p a c e {
C o m p o n e n t F a c t o r y I t e m<Module A> u n i q u e 1 ( ” Module A ” ) ; C o m p o n e n t F a c t o r y I t e m<Module B> u n i q u e 2 ( ” Module B ” ) ; }
A problem specific to SystemC arises with respect to binding different types of interconnect by instance name in a uniform way. As ports and socket can be created implicitly inside a leaf module, their
SystemC primitive Hier. netlist Flat netlist
sc modules 288 160 sc ports 664 664 sc signals 446 441 sc semaphores 1060 1060 sc methods 44 44 sc threads 162 163 sc events 358 358 sc registers 11 11 initiator sockets 315 312 target sockets 418 340 sc other objects 1 1
total created by factory 663 586 total bindings by factory 1019 942
TABLE I
CASE STUDY MODEL INSTANCES BREAKDOWN
existence and precise type is unknown to the factory infrastructure in general. Instead, they must be retrieved as sc objects from the SystemC hierarchy by name. But since SystemC 2005 does not provide a base class for interconnect and no virtual bind() function, the type and binding function for a given interconnect instance is not known at compile time.
The solution is an abstract Bindable that is also created by the Component Factory if applicable. Standard interconnect types are registered by default, and more can be added, e.g., if different tem-plate parameters are needed. Binding is a two step process: first, the initiator sc object is matched by the Component Factory to a concrete Bindable via dynamic cast, such that its type is effectively known; then, an overloaded try bind() function calls the correct bind function with the target. The try bind() function makes use of the boost MPL library [8], namely BOOST MPL HAS XXX TRAIT DEF to identify port or socket type and boost::enable if to activate the correct function.
D. Factory and Composite Module
The Factory class is the main entry point for dynamically creating designs from design descriptions, which are given either as text file or as property tree object. A Factory instance is configured with a concrete Component Factory. It then provides a create() function that accepts the design description and instantiates the top-level Composite, which in turn creates the hierarchical design recursively. The resulting top-level instance is a hierarchical sc module with the specified contents and any number of open ports. It can be used as part of another design without limitation.
Each Composite is given the design description as a parameter. It will process the description at its level of hierarchy for configu-ration, creation, and connection. (1) Each subtree in the description containing the classname keyword (cf. Listing. 3) can be interpreted directly as an attribute subtree. This subtree is set as an initial value. (2) Then, an instance of the specified class name is created with the specified instance name as the only constructor parameter via the Component Factory. Initial values are available immediately during the construction of the object. (3) Finally, ports and socket are bound by name as described in the previous subsection. Binding errors are reported.
IV. CASE STUDY AND DISCUSSION
A virtual prototype developed by a large commercial network equipment provider for one of their future many-core data-plane network processor platforms is used as a case study. Virtual proto-types of several generations of the platform are heavily used by 100s
Creation Hier. [ms] Flat [ms]
Static (constructor) – 40
Dynamic (factory) 85 80
TABLE II
RUNTIMES OF CREATION FUNCTION[IN MS]FOR FLAT AND HIERARCHICAL DESIGN.
of SW engineers for early SW development, pre-silicon bring-up, and regression testing. We examine its characteristics and highlight the distinct real-world benefit the dynamic infrastructure adds to its deployment. The design description and the productivity gain during virtual prototype creation is also discussed.
The platform instance that is used for evaluation comprises more than 30 processors with their local memories, a latency-insensitive message passing communication system, shared on- and off-chip memories, 10s of accelerators, and multiple IO interfaces. The system model exposes its configurable state via attributes. Facets of control and inspection have been realized in the model as well. For example, execution modes can be toggled in the processor via callback attributes. Selected peripheral registers are modeled using a variant of sc register that provides access to the register’s value through the attribute mechanism. The model is fairly complex, as indicated by the breakdown of instances by SC primitive in Table I. Instance counts are given for a flat design netlist, which is identical for both static and dynamic top levels, and a netlist with added hierarchy via Composite modules in the dynamic top level. These additional modules are not strictly needed, but the dynamic nature and fixed format encourages use of additional hierarchy to make the model’s structure easier to reuse and understand.
Runtime profiles only for the factory’s create() function in the dynamic case and only for the top-level module’s constructor in the static case are given in Table II. The factory created 663 instances and did 1019 bindings (cf. Table I, bottom), other instances were generated implicitly. The static creation time is the lower bound for creation. The overhead for the dynamic method is due to the infrastructure needing to look up instances by name, retrieval of sc objects from the SystemC hierarchy by name, and needing to dynamically determine the type of sc objects during the binding-by-name phase. Especially the latter is expensive, as dynamic cast must be used on these sc objects until a known type is found, yet unavoidable, as the type of interconnect implicitly generated inside leaf modules cannot be known to the infrastructure. From the difference between flat and hierarchical design (approx. 10 %) it can be estimated that the overhead is linear in the number of modules/bindings. Improvements to SystemC such as common base classes for interconnect can reduce this overhead in the future. Since the factory creates regular SystemC modules, there is no overhead at simulation runtime.
However, the creation overhead is negligible compared to the startup time after a parameter or netlist change (cf. Fig. 1). We measured the time to reach SystemC’s start of simulation() function on a standard laptop’s virtual machine with a commercial simulator. Figure 4 shows that single invocation of a readily compiled top-level takes approximately 1.5 s and is about 5 % slower for the dynamic case due to the creation overhead (2 x 40 ms). If a change to the top-level testbench is needed, however, it must be re-compiled, which leads to a 12X increase of startup time. If no appropriate configuration interface is available, and the header of an instantiated module is changed, the total effort for dependency checking and recompilation brings the startup to more than 70 s. As there is no re-compilation
in the dynamic case, startup is 46X faster in this extreme case.
0 20 40 60 80 No change (parameter/netlist)
Change in Top (parameter/netlist) Change in module (parameter)
1,560 1,560 1,560 1,470 19,420 72,920 Dynamic Static
Fig. 4. Startup times [in ms] for static top-level and dynamic creation, excluding simulation time.
The difference is relevant for the SW developers in their daily use cases, even if only the top-level testbench has to be recompiled. In interactive debug sessions, the startup time is directly notable. Regression suites for the platform’s SW comprising hundreds of tests run for several hours on tailored platform instances. The average runtime of a single test, however, is only 15 s, which means that the suite will finish in half the time when using the dynamic infrastructure. As another example, a Linux boot on the platform takes 120 s to simulate and will finish 1.6X faster after a module-level parameter change, as is often required during initial bring-up. The generalized speedup is shown in Figure 5.
The size of the fully populated description of the dynamic top is ten times larger than the static top level (cf. Tab. III). However, this is mostly due to the repetitive nature of the dynamic description, e.g., more than 30 instances of the processor subsystem. If a preprocessor with a for-loop is used, the dynamic version is almost equal in size to the static testbench. A fully populated, explicit description is most easy to process and easy to generate. No assumptions are made, for example, regarding a preprocessor or other more advanced constructs such as class declarations. In fact, the well-defined format and dynamic capabilities can be easily complemented by such concepts or graphical assembly tools. The ability to easily use pre-compiled modules is also essential when making model libraries commercially available.
As an indication of the productivity boost associated with dy-namic creation and configuration, the platform was assembled by a developer previously unfamiliar with the architecture. Using the
2 3 4 5 6 edup wi th fa ct o ry [X ] Top‐level change only Module‐level change 0 1 0 50 100 150 200 250 300 350 400 Sp e Application simulation time [s]
Fig. 5. Overall speedup with factory for different application simulation times (excluding startup).
Type of design description Lines Static top-level + testbench (C++) 580
Dynamic design description 5600
Dynamic design description with preprocessor 600 TABLE III
LINES OF CODE IN THE STATIC TOP-LEVEL TESTBENCH AND THE DYNAMIC DESIGN DESCRIPTION.
well-defined format and factory description, assembly could be done within hours:
• The model file syntax is very simple and usable by
non-programmers. A top-down or bottom-up, block diagram oriented approach is natural.
• Grouping of instances is easy and helps to emphasize subsystem relationships and hierarchy.
• From a simple template for each module, parameters and inter-connections are easy to identify and use.
• A consistent and typeless syntax for port binding is provided. Errors are reported during elaboration.
• Rebuilding and changing the model during initial bring-up is quick, by modifying the design description or overriding parameters on the command line.
This is opposed by several days needed for the static top-level description:
• The model creator needs to be deeply familiar with C++ and SystemC concepts. Typical programming pitfalls include: header file dependencies, different namespaces, inconsistent typedefs, null pointers.
• Means for configuration are different for each module, and the addressing and syntax for binding ports and sockets is inconsistent. This makes the resulting top-level quite complex. • As a recompile is needed after each modification, elaboration
and connectivity errors are harder to debug.
Despite its capabilities the overall implementation of our config-uration and creation infrastructure has a very small footprint with less than 1350 lines of code altogether. The overlay technology does not require any modifications to the simulation kernel and SystemC language constructs.
As a small C++ library, it can be combined with any existing legacy SystemC/TLM model or virtual prototype. Specifically, the factory generates a fully compliant sc module that can – as a subsystem – be combined with or integrated into any other statically created SystemC design. Vice versa, wrapping of an existing legacy component for factory use only requires the addition of a single line of code for the registry macro (cf. Sec. III-C) in any compilation unit that is able to instantiate that component. Exposing internal state of a legacy component as attributes is simplified by the provided attribute macros (cf. Lst. 1) that closely follow the natural syntax and initialization pat-tern of regular C++ class member variables. Attribute callbacks even allow to wrap proprietary legacy configuration interfaces on black-box components to be used in a unified way with our infrastructure.
V. CONCLUSION
We have demonstrated the benefit that dynamic creation and con-figuration capabilities add to the deployment of virtual prototypes of complex SoCs. Such capabilities are enabled only by the combination of a tailored factory infrastructure with a means for configuration at creation time and run time. Our lightweight infrastructure is easy to use by model assemblers and end users. It addresses the problem of uniform module configuration also for user-defined data types,
and of creating and connecting arbitrary constructs in a generic, hierarchical way. Despite a small overhead for dynamic creation during startup, startup times are reduced by up to 40X and large-scale regression suites finish in half the time for our use case from industry. Our design descriptions are comparable in size to their static counterparts, but easier to understand and generate. The productivity increase makes assembly of a complex virtual prototype a matter of hours and feasible for non-experts.
ACKNOWLEDGEMENT
In parts, this work has been supported by Archie Zhang (Cadence, USA) and Eric Frejd (Ericsson AB, Sweden).
REFERENCES
[1] I. Bacivarov, H. Yang, L. Schor, D. Rai, S. Jha, and L. Thiele. Distributed application layer: Towards efficient and reliable programming of many-tile architectures, 2011.
[2] G. Beltrame, L. Fossati, and D. Sciuto. ReSP: A nonintrusive transaction-level reflective MPSoC simulation platform for design space exploration. Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, 28(12), 2009.
[3] L. Benini, E. Flamand, D. Fuin, and D. Melpignano. P2012: Building an ecosystem for a scalable, modular and high-efficiency embedded computing accelerator. In Proceedings of the Conference on Design, Automation and Test in Europe, DATE ’12. EDA Consortium, 2012. [4] V. Berman. Standards: The P1685 IP-XACT IP metadata standard. IEEE
Design & Test of Computers, 23(4), 2006.
[5] Carbon Design Systems. SOC Designer Plus.
http://www.carbondesignsystems.com/soc-designer-plus/.
[6] J. E. Coffland and A. D. Pimentel. A software framework for efficient system-level performance evaluation of embedded systems. In Proceed-ings of the 2003 ACM Symposium on Applied Computing, SAC ’03, pages 666–671, New York, NY, USA, 2003. ACM.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: el-ements of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc., 1995.
[8] A. Gurtovoy and D. Abrahams. The boost C++ source libraries. www.boost.org, 2002.
[9] V. Jain, A. Kumar, and P. R. Panda. A SysML profile for development and early validation of TLM 2.0 models. In Modelling Foundations and Applications - 7th European Conference, ECMFA 2011, Lecture Notes in Computer Science. Springer, 2011.
[10] P. Magnusson, M. Christensson, J. Eskilson, D. Forsgren, G. Hallberg, J. Hogberg, F. Larsson, A. Moestedt, and B. Werner. Simics: A full system simulation platform. Computer, 35(2), 2002.
[11] M. Monton, J. Engblom, and M. Burton. Checkpoint and restore for SystemC models. In FDL. IEEE, 2009.
[12] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. A UML 2.0 profile for SystemC: toward high-level SoC design. EMSOFT ’05, New York, NY, USA, 2005. ACM.
[13] C. Schr¨oder, W. Klingauf, R. G¨unzel, M. Burton, and E. Roesler. Configuration and control of SystemC models using TLM middleware. CODES+ISSS ’09. ACM, 2009.
[14] T. Wieman, B. Bhattacharya, T. Jeremiassen, C. Schroder, and B. Van-thournout. An overview of open SystemC initiative standards develop-ment. Design Test of Computers, IEEE, 29(2):14–22, 2012.
