How to use UML in your SoC hardware/software design: Part 4 -

How to use UML in your SoC hardware/software design: Part 4


The basic tools we have proposed (Parts 1,2,and 3)that the SoC hardware developer use to simplify his job—UML models,metamodels, and transformations to text—all fit into a larger context.The ObjectManagement Group, the organization that standardized the UML, hasan initiative called Model-DrivenArchitecture (MDA) which intends to standardize many of theelements required for SoC.

You may have heard of MDA in an IT context, but the principlesbehind it apply to system development in general, and they're notspecific to a certain kind of system or even to software. [1].

MDA is three things:
* An OMGinitiative to develop standards based on the idea that modeling is abetter foundation for developing and maintaining systems
* A brandfor standards and products that adhere to those standards
* A set oftechnologies and techniques associated with those standards

(Dr. Richard Mark Soley, theChairman of the OMG, defined MDA thusly. We also used his definition in[1] , for which Dr. Soley was areviewer .)

At present, MDA is still in development, and some of thetechnologies need further definition while others need to bestandardized.

MDA Standards
Technically speaking, MDA relies on four concepts: models, metamodels,mappings and marks; not all of these are yet standardized.

We have discussed, at length, the UML metamodel, but it is not theonly possible metamodel. Indeed changes are made to it as the UML isrevised and improved. But as users of these standards, we don't want tohave to change our models each time the standard changes.

To avoid this problem, we need a way to capture any metamodels so wecan manipulate them without worrying about their structure. That is,just as we need a metamodel to be able to manipulate arbitrary models,so we need, believe it or not, a meta-metamodel to manipulate arbitrarymetamodels. This is standardized as the Meta-Object Facility, or MOF.

It is now possible to define text transformation languages againstmodels stored in a single common format (MOF), thus providing formappings from models to text. The request for proposal [2] was released in 2004, and thelatest proposal can be found at [3] .

Another standard, Query-View-Transform, (QVT), provides formappings from one metamodel to another, both using MOF.

There are today no standards proposed for marks. By and large,people use the profile mechanism to capture marks, but this does notaddress issues such as combining what we have called the “plasticsheets.”

One key standard that is missing at the time of writing is astandard definition of an executable, translatable UML. While there aremechanisms that allow for the interchange of models between tools,there must be agreement on the UML elements they can each understand.

That is, the tools must share a common subset of UML for the toolsto communicate effectively. It is possible for one tool to be “morepowerful” than another, but effectively that restricts the power of atwo-tool tool chain to the weaker of the two. When multiple tools claimto be in the same tool chain, it is only as strong as its weakest link.

Model-driven architecture, of course, is the name of the game. Notonly must there be standards for the UML and the rest, but it's alsoimportant that tools built to these standards also fit together withinthat architecture and so create a complete model-driven developmentenvironment. This set of tools, loosely sequenced, constitutes a toolchain.

There are many possible tools that need to be integrated to make acomplete development environment. With the right standards, one canenvision tools that do the following:

* Transform one representation of an underlying model to anotherrepresentation friendlier to a reader
* Generate testvectors against the application model, and then run them
* Check forstate-space completeness, decidability, reachability, and the like
* Manage deploymentinto processors, hardware, software, and firmware
* Mark models
* Partition or combinebehavior application models for visualization or deployment
* Analyze performanceagainst a given deployment
* Examinethe generated code in execution (inother words, model debuggers )

We can imagine a developer receiving a application model from avendor or colleague; turning that application model into a comfortablenotation or format; making a change with a model builder; verifyingthat the behavior is correct by analysis and by running test cases;marking the models and deploying them; analyzing performance; debuggingthe resulting system, and so forth.

When developers have the ability to provide specification tidbits atvarying levels of abstraction and then link them all together, MDA willface additional tool challenges regarding smooth integration betweendifferent specification levels, such as consistency checking,constraint propagation, and incremental mapping-function execution.

As the SoC community continues to push toward a higher level ofabstraction for the specification of systems it will be important toestablish and maintain relationships with organizations focused onmodel-driven development, even if the traditional focus of such groupshas been software development.

Conclusion: How Does All This StackUp?
Partition? Because the xtUML models accurately and precisely represent theapplication, and the implementation is generated, with absolutefidelity from these models, the partition can easily be changed, and anew implementation can then be generated. This replaces weeks oftedious manual changes to an implementation with a few hours ofautomatic generation.

With the ability to change the partition and regenerate theimplementation, the developers can explore much more of the designspace, measuring the performance of various allocation arrangementsthat would otherwise be prohibitively expensive to produce.

Interface? The interface between the hardware and software is defined by the modelcompiler. Because the implementation is generated, there can be nointerface mismatches. Because we no longer have two separate teams ofpeople working from a natural-language interface specification, thegenerated implementation is guaranteed to have exactly zero interfaceproblems. (This does have theunfortunate side effect of reducing the number of opportunities forlogic designers and software engineers to spend long nights together inthe integration lab fixing interface problems .)

Marks are a non-intrusive way to specify allocation of systemfunctionality without affecting system behavior. The existence ofautomated tools to cause the generation of the system with interfacesknown to be correct completely removes any interface problems that canlead to a failure to integrate the system.

Integration? Integration is now the integration of two independently tested pieces:the application model and the model compiler. Each can be understoodseparately, tested separately, reviewed separately, and builtseparately. The integration is realized by the generalized part of themodel compiler (the generator) that embeds the application into thetarget platform.

The real integration issue now whether that model compiler meets theperformance needs of the system. Should performance be less thanadequate, we can change the allocation using the existing modelcompiler, or change the rules to create a new target architecture thatdoes meet the performance requirements.

Thisseries is reprinted in four parts from Chapter 2 of “ UMLfor SoC Design“with permission of Springer.

To read Part 1 in this series, go to “Thecentral problem of SoC design and a proposed xtUML solution.”
To read Part 2 in this series, go to ExecutableUML Models for SoC design.”
To read Part 3 in this series, go to  “
Manipulatingand using SoC xtUML application models.”

StephenJ. Mellor is Chief Scientist of theEmbedded Software Division at Mentor Graphics, is an internationally recognized pioneerin creating effective, engineering approaches to software development.In 1985, he published the widely read Ward-Mellor trilogy StructuredDevelopment for Real-Time Systems, and in 1988, the first booksdefining object-oriented analysis. His latest book MDA Distilled:Principles of Model-Driven Architecture was published in 2004.

John R.Wolfe is Director of Operations andEngineering for the BridgePoint UML suite at Mentor Graphics, wasPresident and CEO of Project Technology, Inc., since acquired by MentorGraphics acquired the company, which was focused on tools to executeand translate UML models in the context of Agile MDA.

CampbellD. McCausland isa Principal Engineer, Mentor Graphics Corp, where he is the chiefdesigner of the BridgePoint UML Suite. He is the creator of (to hisknowledge) the very first model compiler that translates xtUML modelsto behavioral VHDL.

John Wolfe will be at theupcoming Embedded Systems Conference Boston, September 25-28 at theMentor Graphics booth #1201.  In addition, Cortland Starret t will be conductinga series of seminars. Go to  to check on the speaker's scheduledetails. Starrett is Engineering Manager leading development oftranslation technology at Mentor Graphics, responsible for theproduction of tools and methods for translating xtUML models intosource code such as C, C++, Java and VHDL.

[1] MDA Distilled: Principles of Model-Driven Development, Mellor,Scott, Uhl and Weise, Addison-Wesley, 2004.
[2]  MOF Model to TextTransformation RfP.
[3]  Latest MOF Modelto Text Transformation Submission.

Otherresources on about UML and xtUML :

1) Executable and Translatable UML
2)Need for modeling tools rises with design complexity
3) In Focus: Unified Modeling Language
4) Introduction to UML statecharts
5) UML evolves total system perspective
6) Introduction to UML Class Diagrams
7) State machine shortcuts
8)From UML to embedded system: Is it possible?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.