Embedded Software Architecture Specification Developments in Support of SoC Design and Re-use

By Robert Deaves, Andrew Jones, Martin Habets and Stuart Ryan, STMicroelectronics

Abstract:

Embedded software and its specification is a vital component in deploying SoCs with reduced time-to-market. A key contribution to this is the technology area of embedded software architecture.

This paper reviews the open literature on general software architecture highlighting techniques applicable to the embedded domain. These areas include use of multiple views, hierarchical patterns, standard modeling, advanced documentation and application of architecture assistance tools. Applying software architecture for embedded re-use is an area identified as not being fully explored in current literature. This concept is investigated in the paper.

An example is provided to show how embedded software architecture specification can be applied to software re-use. This is based on a SoC inter-processor communication system.

Conclusions indicate that (i) using established software architecture techniques in embedded developments, and (ii) applying software architecture for re-use can reduce the time-to-market for SoC devices along with other benefits. Future work areas are described.

1. Introduction

It has long been understood that a key requirement to reducing time-to-market for SoC devices is to start software development early in the design process [1]. Now that this approach has been established the next challenge is to mature embedded software engineering. This includes embedded system software architecture and its specification.

This paper reviews techniques applied in general software architecture and highlights areas that can be re-applied to specification in the embedded domain. Further, it is noted that software architecture re-use, essential in embedded systems is not fully covered in current literature.

The remainder of this document is organized as follows: Section 2 provides a brief review of general software architecture. Section 3 highlights areas of that work that are applicable to the embedded software architecture domain. Section 4 extends software architecture in the embedded domain by exploring issues relevant to re-use. Section 5 provides an example of considering re-use in software architecture specification. Concluding remarks and future work in this area are documented in Section 6.

2. General SW Architecture Review

This section highlights techniques that have been proven to improve specifications in the general software architecture domain [2]. Further, areas not covered in the literature but required for embedded developments are highlighted.

Seminal work on modern software architecture was provided by D. Garlan [3]. This early work focused on the idea of architectural design patterns to provide familiarity and clarity to the software architecture. This has analogy with the popular design pattern concept applied in object orientated programming [4].

This early academic work was followed by industrial contributions that focused on providing a design process [5].  Two important elements of this work were the concept of views and the use of standardized models for architecture representation. Views aim to partition the architecture into well defined areas. For example, conceptual view, module view, execution view and code view. This makes the architecture accessible to engineers who want access to different information. For example, a marketing engineer may only require knowledge of the conceptual view, whereas a software engineer may be more interested in the execution view.

The standardization of architectural representation brings the benefit of familiarity and eliminates the need for bespoke definitions. The de-facto standard for such representations is UML [6]. This is widely accepted as a useful representation and is supported by a number of software development tools. Therefore the use of standardized modeling provides familiarity, clarity and productivity for software architecture specification.

Another important technology development area is XML/XMI [7]. This technology is supported by software tool vendors, document processing packages and web applications. This provides the capability for information interchange and database representation. This maximizes the information generated leading to an increase in engineer productivity.

The current status of general software architecture is summarized in [8]. Here it is stated that over that over the past two decades software architecture has matured to become a recognized engineering discipline. However, it could be argued that this is not yet the case for embedded software architecture since this area is a relatively new discipline, and re-use is a major component of architecture and design of embedded systems. This is an area that is not fully considered in (current) general software architecture.

The remainder of this paper is focused on two areas (i) aspects of general software architecture that are relevant to specification in the embedded domain, and (ii)  applying software architecture to enhance software re-use.

3. Embedded Domain Developments

The review of general software architecture highlighted multiple-views, hierarchical patterns, standard modeling (UML), advanced documentation (XML) and the use of tools as useful techniques for improving software architecture specification in embedded systems. These are currently being evaluated. The remainder of this section provides a snapshot of that work.


Fig 1: Multiple Views


The multiple views concept is represented in Fig 1.

Here the Requirements View captures the use cases of the SoC. These use cases provide a basis for developing a Conceptual View. This view, along with the Hardware View leads to the Implementation View. This documents what software/firmware runs on what processor/IP. The Delivery View lists details of the software versions and performance details.

It should be emphasized that the multiple views approach is a process and not a flow. This means that in the design phase multiple/concurrent entry points exist. This is particularly useful for evolutionary designs; which is often the case for SoC devices. Conversely, for the documentation phase the views are presented in a logical order for readability.

The concept of hierarchical patterns is represented in Fig 2. Here a cable input dataflow pattern is described. For clarity and familiarity a Generic Pattern (high abstract) is described first. Detail is added to this pattern to give the Technology Pattern. Further detail is added to the pattern to give the Implementation Pattern. This gives the lower abstraction representation.  

 

Fig 2: Hierarchical Patterns


Fig 3 represents a mapping between the views suggested and UML models for their description.

UML provides a rich and (near) complete set of software models. It should be noted that this is only a suggested mapping and that other UML models (of which there are 12) could be applied as required.

 


Fig 3: UML Application

Fig 4 represents the use of XML as a communications mechanism. Here a document is written in word and saved as an XML document. This allows the document to be used as a database through the use of the Javascript Document Object Management (DOM) parser to display the data through html. Automatic Parse Checks can then be carried-out on the document, for example ensuring that template tables have appropriate entries. In addition, automatic Consistency Checks can be carried-out, for example to ensure that names/tags are consistent. Normally, these checks would be carried-out manually.


Fig 4: XML and Bespoke Tool


Another function of the tool is to reformat the data. For example, consider several Use Case tables in a document.  These would each have a Status field. Given the database it is then straightforward to display the Status of each Use Case on a single html page, although this information does not appear (collectively) in the original document.  Finally, the data can be filtered. For example, the status table described above could be generated but only including the Use Cases with a high Priority.

The application of Computer Aided Software Engineering (CASE) tools can ensure consistency and correctness of the software architecture specification. In addition, CASE tools can increase the engineering productivity.  A number of candidates for this role exist and are currently being evaluated, for example [9].

4. Software Architecture for Re-use

The review of general software architecture highlighted that the area of re-use was not fully considered in the literature. In the context of this paper software architecture for re-use can be defined as the application of architectural effort on the ‘current’ software in preparation for ‘future’ software in order to achieve a given criteria (or utility).

In ‘real’ developments the utility will be a complex multi-dimensional value based on a number of different factors including timescales, cost, market forces, technical benefits etc. Further, project stakeholders (program management, customers, design engineers, architects etc.) will each calculate the utility to have different values. For example, the Program Management may want little effort spent on re-use due to time constraints on the ‘current’ software. However, the architects may have a different view and require more effort to be spent on the re-use aspect to obtain an elegant architecture. In the context of this paper a simplified 3-axis, dimensionless views of representative utilities are provided for illustration, see Fig 5. Here the example Project Management and Architect views are provided in diagrams (a) and (b) respectively. This demonstrates how the project management may emphasize timeliness (Ta > Tb) while the architect may emphasize software re-use (Ab > Aa).


Fig 5: Example Utility Values for Different Stakeholders


The final decision on the scheme to use would be reached through consensus of the stakeholders taking into account all the utilities and (possibly) other issues. This process is usually carried-out through discussion. However, this can be mathematically defined as [10]:

Ui  = β . Ai  + δ . Ti +  Ω . Di

where U is overall utility, D represents the Device Resource Usage, and i is the scheme (either a or b).  β, δ and  Ω are the ‘weightings’ associated with the individual utilities A, T and D respectively with:

β + δ + Ω = 1

It should be noted that setting the weightings is non-trivial as they will be non-linearly and dependent on A, T and D. Further, there may be uncertainty associated with the values of A, T and D.

5. SW Architecture Re-use Example

This section provides an example of the benefits of considering re-use during software architecture specification.

The scenario considered is based on a phased approach to the deployment of two solutions for a customer application. In the first phase a dual chip solution was to be deployed. Some time later the second phase solution would be deployed based on a single chip. This would combine and extend the functional capability of the two chip solution. Motivation for the single chip solution is to provide the customer with a number of cost saving opportunities [11].

Specifically, the example considers the inter-processor communication (IPC) software used to allow two processors to communicate.

As a basis for analysis two software architecture specification approaches are considered:

• Straight Porting Scheme: Here the focus of software architecture specification is on the dual chip (first) phase development. As the single chip (second) phase has all the functionality of the first phase a ‘straight port’ of the software from the phase 1 to the phase 2 provides a working system.   
• Re-use Consideration Scheme: In this approach the software architecture for both phases are analyzed in more detail. This leads to optimization opportunities for the re-use design case.

These schemes are now considered further:

5.1 Straight Porting Scheme

Fig 6 provides a deployment diagram that represents the two chip solution.  



Fig 6:  Dual Device Communication

Here CPU1 on DEV1 makes a communication to CPU2 on DEV2. This is achieved by Application code running on CPU1. This performs the following sequence of events:

1. CPU1 places data for communication in MEM1.
2. CPU1 programs DMA1 to move data from MEM1 to MEM2.
3. DMA1 fetches data from MEM1.
4. DMA1 communicates the data to MEM2 via the MPX bus.
5. DMA1 issues an interrupt that informs CPU2 that a communication requires servicing.
6. CPU2 accesses the received data in MEM2.

The architecture of the software deployed on CPU1 is represented in the package diagram of Fig 7.

Here the Application communicates with the IPC via an interface API. The IPC communicates directly with DMA1 for programming as in Step 1.

The inter-CPU communications for the single device solution is represented in Fig 8. This is very similar to the two chip representation in Fig 6.



Fig 7: Straight Porting Software Architecture

However, in this case there is only one device, DEV and one memory, MEM.  Further, the communication in Step 4 is via the internal device bus and not MPX.  



Fig 8: Single Device Communication

In this scheme the only change required to the software in Fig 7 is concerned with the configuration file.

Analyzing this scheme concludes that only minor configuration file updates are required in order to facilitate both the two and one chip solutions.

5.2 Re-use Consideration Scheme

In this scheme a more detailed analysis of the dual and single chip solutions was carried-out. This highlighted the following shortfalls in the Straight Porting scheme when applied to the single chip solution. These include:

1. There is a potential for redundant data in memory, as the DMA transfer only replicates data already in memory. (The memory area accessed by 1 and 6 in Fig 8 contain the same data after the communication.)
2. There is latency introduced in the communication, due to the physical copy by the DMA.
3. Additional internal bus traffic is generated. (Due to accesses 3 and 4 in Fig 8).
4. An additional memory bandwidth requirement is introduced due to the physical copy. (Again, due to accesses 3 and 4 in Fig 8).
5. The DMA used for Straight Porting could be applied to other tasks.

These disadvantages can be overcome by applying alternative software architectures for the communication process.  Such an architecture is represented in Fig 9.

This architecture introduces an abstract layer for the IPC. This can be realized using two implementations. The first scheme is based on using a DMA IPC implementation, see 1 of Fig 9. This allows the dual chip solution to be implemented as described in the previous section.

However, for the single chip solution shared memory is used as a basis for the communications. This uses the Shared IPC implementation, see 2 of Fig 9. This implementation is provided in Fig 10 and represents a communication from CPU1 to CPU2.



 Fig 9: Re-use Consideration Software Architecture

This is achieved by performing the following sequence of events:

1. CPU1 places data for communication in the shared memory region.
2. CPU1 issues an interrupt that informs CPU2 that a communication requires servicing. This is sent via the mailbox hardware.
3. The mailbox hardware issues an interrupt to CPU2.
4. CPU2 can then access the data from the shared memory.

It should be emphasized that in this scheme zero copy communications is achieved.

Brief analysis concludes that the improved software architecture allows both the dual and single device solutions to be implemented. Importantly, this is achieved with the software architecture applicable to both the dual and single chip implementations. In addition, the shortfalls of the Straight Porting scheme are overcome. This can be deduced by comparing Fig 8 and 10 and noting that the DMA is not used, accesses 3 and 4 in Fig 8 have been eliminated, and accesses 1 and 6 are to a shared region. This was achieved at the cost of additional software architecture analysis, more complex implementation and use of less valuable device resource (mailbox).



Fig 10: Single Device Shared Memory Implementation

5.3    Analysis

Fig 11 summarizes the analysis from the example.



Fig 11: Example Summary Analysis

In (a) the timeliness, software architecture re-use and design resource usage by the Straight Porting scheme is summarized. The same analysis for the Re-use Consideration scheme is provided in (b). These values are calculated for the combined development of the dual chip (first) phase and single (second) phase solutions. The aim of the analysis is to determine which development scheme to follow.
This decision was made through discussion between the architects, designers and program management. The main points are summarized below:

1. As the Straight Porting scheme incurs a relative burden (e.g. memory bandwidth) on device resources during the single chip phase its Device Resource Usage utility is relatively low.
2. By its nature the Re-use Consideration scheme has a relatively high utility for Software Architecture Re-use.
3. The development time for the Re-use Consideration scheme is similar to that of the Straight Porting scheme for the dual chip phase as the only additional work is the introduction of an abstract layer, compare Fig 7 and 9. However, the development time for the single chip phase is greater as the Shared memory capability requires development (see Fig 9 and 10).

Although point 3 is a disadvantage for the Re-use Consideration scheme it was noted that the Software Architecture would facilitate the implementation of the DMA approach as well as the Shared memory approach in the single chip phase by simply changing the configuration file. This flexibility would be useful during development and provide a regression option.

The outcome of the analysis was that the Re-use Consideration scheme was selected. This demonstrates that this scheme provided (subjective) benefit over the Straight Porting scheme.

6. Concluding Remarks

Starting software development early in the SoC design process to reduce time-to-market is now a well established principle. An important aspect of this development is the embedded software architecture specification.

This paper provides a review of general software architecture emphasizing useful areas and indicating omissions that would enhance embedded software architecture.

Areas identified as applicable and beneficial include multiple views, hierarchical patterns, standard modeling, advanced documentation and tools. Initial work indicates that these areas can provide clarity, familiarity, standardization, productivity and automation (of consistency and correctness) improvements to embedded software architecture specification. All these improvements contribute to reducing software development timescales and ultimately have the potential to improve time-to-market for SoCs.

The application of embedded software architecture for re-use was noted as an omission from the literature review. The paper investigates this area by way of example based on recent experience concerning the development of two products: dual chip and single chip solutions. Analysis indicates how valuable SoC resources of memory bandwidth/capacity, internal bus communications, and IP usage could be saved through software architecture for re-use considerations.      

Our future work will continue to assess developments from general software architecture. An important part of this work will be in selecting/developing an appropriate CASE tool to manage different aspects of the architecture and improve productivity.  In addition, development work will continue in areas that are more specific to embedded software architecture.

Acknowledgements

The authors would like to acknowledge valuable comments from Roger Shepherd, Bill Fletcher, Yann Garnier and Ludovic Rattin concerning aspects of this work.

References

[1] Deaves, R.H. and Jones, A.M., ‘An IP-based SOC Design Kit for Rapid Time-to-Market’, IPSOC 02, Dec 2002.

[2] Bredemeyer Consulting, ‘Resources for Software Architects’, http://www.bredemeyer.com/

[3] Garlan, D. and Shaw, M., ‘An Introduction to Software Architecture’, Vol 1 Advances in Software Engineering and Knowledge Engineering, Singapore: World Scientific Publishing Company, 1993.

 [4] Gamma, T., et al, ‘Design patterns: elements of reusable object-oriented software’, Addison Wesley, ISBN-13: 978-0201633610, 1995.

[5] Hofmeister, C., Nord, R., and Soni, D., ‘Applied Software Architecture’, ISBN 9-780201-325713, Addison-Wesley, 2000.

[6] Pilone, D., ‘UML 2.0 Pocket Reference’, O’Reilly, ISBN 978-0-596-10208-1, 2006.

[7] McGrath, M., ‘XML In Easy Steps’, Computer Step, ISBN 1-84078-124-6, 2002.

[8] Shaw, M., ‘The Coming-of-age of Software Architecture Research’, Proceedings 23rd International Conference on Software Engineering, Toronto, Canada, 2001.

[9] Enterprise Architect, Sparx Systems.

[10] Hansson, S., ‘Decision Theory: A Brief Introduction’, Royal Institute of Technology, Stockholm, 1994.

[11] Ryan, S., Jones, A., Deaves, R., ‘A Cost Optimized Set-Top Box Architecture’, SoC Design and Re-use (2), IPSOC08, Dec 2008.