From an architectural perspective, multi-core hardware platforms adopt a series of configurations, which in most cases are customized to the requirements posed by each product under development. Considering the asymmetric multiprocessing platform (AMP) used in the eMuCo handset, a combination of hard real-time, or time-critical tasks, in addition to the soft real-time tasks were identified to run on L4 and the Linux platforms. In either case, whether to implement soft or hard real-time scenarios in the product, it becomes necessary to test small increments of the software application, at various stages of development.
Executing Source Code vs. Executing the Model
It is common practice to create higher level architecture and design using a modeling tool, but then develop the executable code by hand. This approach usually relies on a set of structural code (or code frames) to be generated from the model. Any change in the subsequent code is reverse engineered back into the model, so as to maintain a sense of synchronization between the architecture and the code. However, this approach relies on conventional programming and source level debugging to verify correctness of the evolving application. Fixing any bugs and architectural design oversights at code level will consume development time and delay project completion; especially since this method usually results in many problems being discovered toward the end of development cycle. It is demonstrably less time-consuming to execute and debug the model earlier in the cycle so as to avoid the problems downstream.
An alternative approach to executing and debugging the resultant source code is to instead execute and debug the architectural model. The main benefit of an executable model over executable code is its higher level of abstraction. This is not unlike what programming languages did for assembly languages, which in turn, abstracted the machine languages. The point is, when defining the semantics of an executing system, higher levels of abstraction tend to make us more productive; and the step up to executing the architectural model is the next logical step in this progression.
Virtual Platform
Another benefit of an executable model is that it runs in the context of a self-contained target, termed a virtual platform. When developing systems and applications where the platform may not be available, or may be too scarce or expensive for use in testing, developers can still properly verify their designs. These designs can seamlessly transfer to the final platform (or platforms) when available.
During multi-core software design, it becomes necessary to make key architectural decision at the higher, systems architecture, level. This is necessary, in order to: (a) determine average, aggregate and peak CPU processing needs, (b) Characterize the load distribution in the computing embedded system e.g:smartphone during its different modes of operation, in order to ensure optimum performance during these modes, (c) validate the overall software architecture and make the necessary changes during the earlier development cycles.
In order to address these problems, one needs to build a system of checks-and-balances where a system is gradually built and continually tested during the course of the development process (Figure 1). The "V" process shown emphasizes testing and verification at every stage of both analysis and design. This approach pushes the actual software generation further downstream, as shown on the left side of the "V", in favor of developing more models instead. Testing is concurrently and continually performed on the corresponding models, as opposed to once at the end of the developed iteration by testing the resulting source code. Finally, testing at model level is also used for trade-off studies, in order to determine the initial load balancing in the system.
In essence, the approach described above resembles an Agile, Model Based development methodology. |
|
In case of the eMuCo handset
For the eMuCo handset, a virtual platform was used at all the development milestones referenced in, Figure-1, Agile, Model Based development methodology.
Model-level execution was used as a design validation mechanism for both the load balancer and the protocol stack. The protocol stack utilized the simulation engine in IBM Rational SDL Suite to execute the model at architectural level and generated Message Sequence Chart (MSC) as a result of simulation. MSCs, used for specification purpose and defined through the MSC Editor, are also generated as a logging mechanism from the model execution exercise. The goal is to compare the specified version with the generated MSC resulting from the executing system. The overall system, once simulated, was validated for functionality and compared with the design MSC, with the mismatches flagged by the SDL Suite MSC comparator. Corrections to the LTE models were made when needed and the process continues until all known bugs were fixed. Figure 2 illustrates an MSC generated from simulating the SDL model |
|
A differentiating factor in the generated MSC is the runtime values of the system variables, which are shown on the diagram. These values facilitate a later validation of the complete end-to-end execution scenario using co-simulation of hardware/software by using virtual prototyping of a multi-core hardware platform and executing an LTE protocol stack software component. In this example, a host based simulation was carried out, and the development team was able to validate the given system-level transactions, without needing to run the application on the actual target. The targets, especially in the prototype phase, are usually in high-demand and not easily available.
Another facet of model execution is significant at detailed design level, where models are defined and executed at the state machine (SM) level. SM's are the most detailed notation supported by most modeling languages, and reflect the behavior of a single object. Typically, a SM simulation reveals design oversights or unexpected runtime behavior such as Figure 3 exemplified.
|
