Decoupled constraint modelling – a design methodology for hard real-time systems on chip
Using UML to define a software-defined modem SoC in terms of decoupled constraints – the order of activities, the timing they have to meet, and the available resources
This article describes a methodology for designing and implementing hard-real-time systems on chip (SoCs) that have to meet cost, power consumption and performance constraints.
The model-driven methodology, expressed in UML, enables a system to be defined as software that runs on a scalable fabric of heterogeneous multiprocessors.
This helps manage the complexity of the SoCs, and means that developers can focus on defining their application independent of the implementation details. It should also increase design productivity.
Cognovo has used the approach to develop a software-defined modem (SDM) platform that enables one SoC to support many types of wireless processing. The methodology can also be applied to other real-time signal processing tasks, such as those found in broadcast, wire-line communications and imaging.
Software defined modem
Wireless products have to support an increasing number of standards, both coordinated (e.g. running LTE with 3G inter-system measurements), and uncoordinated (e.g. running LTE and Wi Fi simultaneously). The complexity of doing so is compounded by the evolving nature of many modem specifications.
There is quite a lot of similarity between many wireless standards, so it is possible to identify a common hardware infrastructure for modem designs using a generic set of programmable resources. These are complemented by a common application framework, in which modems are treated as applications, or a domain-specific operating system.
Figure 1
Modem application architecture (Source: Cognovo – click image to enlarge)
Cognovo uses this approach to build SDMs for low-power, cost-sensitive applications. These rely on the availability of very long instruction word (VLIW) vector signal processors (VSP), whose instruction and data parallelism helps deliver very high throughput. Using many such cores enables additional, application-level parallelism.
Programming multi-processing systems, especially in languages with little support for parallelism, is difficult. Rather than invent a language to fix the problem, Cognovo has created a domain-specific model of the ‘application’ (in this case, a wireless modem) that a designer can use to define a design, including their concerns about the overall design envelope (e.g data rates or battery capacity), directly.
In this article, we define a ‘standard, scalable’ architecture, describe the common application framework and define the design methodology.
Decoupled constraint modeling (DCM)
Decoupled constraint modeling relies on three concepts:
- Decoupling the application from the execution platform
- Decoupling the system (application and execution platform) into a number of orthogonal areas of functionality
- Separating out key design concerns and modelling these across orthogonal areas of functionality to derive a set of decoupled constraints
The flow is illustrated in Figure 2 below. The application designer’s initial concerns are expressed from a number of Perspectives and these are then modelled as orthogonal Views of the functionality. This process yields a number of orthogonal design constraints.
To design modems, we use three Views:
- Action Sequences, which capture the control and data dependencies
- Timelines, which define how the planned Action Sequences should be executed to meet to time constraints
- Resources, which define which resources on a real platform need to be allocated to complete the Action Sequences to meet the Timeline
This enables designers to look at their designs in three different ways, and to understand how the requirements of each View are coupled and can be traded off. This analysis drives the allocation of resources (supplied by the platform being used to implement the design) according to a policy designed to minimise one or more cost functions (constraints). Model-driven tools can then generate code to create the implementation, and report the results for validation.
The methodology can be implemented using standard languages and tools, such as UML. In the final device, a solution for each aspect of the design problem can be realised on dedicated programmable hardware elements.
Figure 2
Decoupled constraint modelling methodology (Source: Cognovo – click image to enlarge)
Action Sequences
Action Sequences express the order in which discrete actions should be executed, based on the dependencies (such as control or data) inherent in the application. The ordering and interdependencies of Action Sequences are defined independent of any timing.
Timelines
Timelines – the live-lines and dead-lines – are an important part of expressing a real-time application’s behaviour. Timelines define when activities can start and when they must complete, in other words, the time-based dependencies of the application. These dependencies are usually defined by the application but are not, at this stage, driven by its implementation.
Resource allocation
The way the application can act is limited by the capabilities of the platform on which it runs. The capabilities are defined by the platform’s resources, such as:
- Processors and HW accelerators
- Memory
- Interconnect throughput
- Processing power
- Memory access topology
- Electrical power profiles
- I/O resources
Together, the number and type of each of these resources defines the platform.
Analysis
DCM produces constraints for each View of the design, which in turn define the dependencies on other Views that affect the ultimate implementation. For example, an Action Sequence may be defined with several Actions that run in parallel in the model, but which have to run sequentially on the platform due to a lack of Resources, such as processing power and/or memory. This is where the decoupled nature of the methodology pays off: the functional behaviour described in the Action Sequence View is not affected by the lack of Resources – its implementation is.
Figure 3 summarises the overall flow. Action Sequences are amalgamated with Timeline constraints that should run on a specified platform to satisfy the needs of the application. Action Sequence execution, Timeline generation and Resource allocation are handled by entities mapped on to the processing resources of the platform. Those entities can be run in the tool for static analysis. They could also be implemented as run-time elements on the platform to enable dynamic analysis, coupling and Resource allocation.
Figure 3
DCM flow (Source: Cognovo – click image to enlarge)
Modeling and coupling Views
The DCM methodology is independent from any particular implementation or modelling technique. However, Cognovo has used the UML graphical modelling language to apply the methodology to SDM development since it is a natural fit.
Action Sequences are captured using UML Activity diagrams, which enable us to show Actions in parallel or in sequential order based on the application’s behavior, but independent of any timing. Conditional sequence flow is also possible, as are data and object flow. A completed Activity diagram shows the execution order and data-flow order dependencies. The diagram does not define which processing resources execute the Actions at this stage, either – at this point the definition of the application is still decoupled from the platform upon which it will run.
A typical UML Activity diagram is shown in Figure 4.
Figure 4
UML Activity diagram for Sequence modelling (Source: Cognovo – click image to enlarge)
In Figure 4, conditional execution is described using Decision and Merge primitives. Parallel execution and control-flow synchronization are handled by Fork and Join primitives. Each Action diagram, showing a sequence of Actions, has one Initial entry and one Final exit. Data flows are given by links between the Action data input/output pins and buffer/data objects. Buffer/data object attributes manifest themselves as constraints to the model of the system. Actions can be constrained to certain processing resource types at this stage, or left to the coupling stage.
In the next stage, all the constraints of each View are brought together in a coupling process, in which the Activity diagrams are linked to Timelines and Resources with UML stereotypes and tags. A portion of a coupled Activity diagram with platform-related couplings is given in Figure 5.
Figure 5
A Sequence coupled with platform elements (Source: Cognovo – click image to enlarge)
In Figure 5, the Resources are given as memory and processing resource stereotypes. The processing Resources are given as types not instances. The Timelines are given as attributes in the tags of the Actions.
After completing the View coupling stage, the tool helps allocate instances of static resources and generates code. If the constraints defined in the Views are not met, the tools can employ algorithms to solve the conflicts. For example, the platform might not have enough memory capacity, or excess capacity; or not enough processing resource instances to complete the Actions in parallel. The conflict can be resolved by the tools and reported back to user with cost figures.
A standard platform architecture
Figure 6 shows Cognovo’s platform architecture for implementing SDMs. The Sequencer and Timing Control Unit directly implement the Action Sequence and Timeline Views defined in the methodology, serving as targets for the model-driven development flow’s code generation.
Figure 6
Standard SDM platform architecture (Source: Cognovo – click image to enlarge)
Modem data-processing calls for specialist processing elements that exploit a high degree of parallelism. The VSPs in the platform above can be scaled according to each application’s needs. For example, a 3G W-CDMA modem would operate on a single VSP at 350MHz, whereas an LTE-Advanced modem would require six VSPs running at 350MHz.
The VSPs are optimized to perform wireless data processing and, therefore, have some restrictions on general-purpose code execution. They have to run to completion, because their execution context is large. This makes them highly efficient and deterministic, which is important for modelling behaviour, but also means they have to be used in a particular way. It also means they can’t run an operating system.
VSPs also require local code and data memory storage for efficiency. Communications between VSPs can take place using shared memory, pipes, or DMA. Actions running on the VSPs are coded in C/C++ and a specialized compiler extracts the most instruction parallelism from the program.
A general-purpose processor (GPP) manages the VSP resources and runs the Modem Application Framework (MAF). When a modem is deployed, the VSPs are loaded with appropriate code for the tasks that each needs to run, and memory is pre-allocated and managed by the MAF API.
The three Views, of Action Sequencing, Timing and Resource allocation, are mapped to, respectively:
- the programmable Sequencer
- the programmable Timing/Control Unit (TCU)
- static Resource allocation in the SDM System Design tool
When the System Design Tool generates its code it creates the Timeline programming information for the TCU and an Action Sequence program to run on the Sequencer. The static allocation of Actions to processing elements is decided at design time and implemented by the tool. Dynamic allocation at run-time would be possible with the addition of a Resource allocation engine to the platform hardware, but this is not needed for most current modem applications.
The Sequencer has an instruction set that corresponds to the UML Activity diagram sequencing primitives. It can:
- Invoke an activity
- Action on activity completion
- Fork (Parallelism)
- Join (Synchronization)
- Decision (Conditional execution)
- Merge
This heterogeneous multi-processor platform consists of a number of different processing ‘engines’; processors (VSPs, Sequencers and GPP), co-processors, DMA controllers and I/O. Each can perform an activity that can be modelled using our methodology and which adheres to a specific engine abstraction definition.
Co-processors have been optimized for specific tasks. The GPP executes the MAF – acting like a proxy operating system to the other processing elements and providing an API for the tool-flow’s code generator (and for the modem application developer).
The platform can be scaled by adding processor cores, sizing memories and extending the processor capabilities. Cognovo have implemented this architecture in a 45nm development chip clocked at 300MHz, which has been demonstrated running the LTE-Advanced protocols.
Conclusions
The demand for cheaper, faster signal-processing capabilities, delivered more quickly, is putting pressure on design teams. This is especially apparent in the wireless device market, where the concept of software-defined modems is now being recognised as one way to address this problem. However, implementing multiple complex modems in software has its own complexities.
The creation of a scalable processing architecture, based on the commonality found in many modem designs, can help standardise the silicon hardware. Differentiation can then be done in software. Developing modems according to a clear and robust methodology helps manage design complexity and separate application development from implementation concerns. The use of a model-driven approach should reduce implementation and integration costs, as well as bringing the validation of system issues forward into the design phase, away from the more costly implementation phase.
In a second article from Cognovo, the company will explain how it has used the Decoupled Constraint Modelling to implement a 3GPP LTE-Advanced modem.
About the authors
Erkut Uygun – principal modem architect
Paul Tindall – head of software
Peter Kibutu – senior modem engineer
Dusko Vujadinovic – senior Modem engineer
About the company
Cognovo is an IP licensing company which supplies software defined modem (SDM) technology enabling manufacturers to create flexible multi-mode devices capable of operating a dynamic mix of cellular, wireless and broadcast standards. The key components of the technology are a small die size and low-power heterogeneous compute engine which is programmed in C, and a modem-driven design toolset to enable optimal design for correctness in parallel with silicon device fabrication.
Since this article was first published Cognovo has been acquired.