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

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

Once you have captured the semantics of your SoC application modelcompletely in a neutral form (seePart 2), you are now ready to compile it intosoftware and silicon. Only the semantics of the modeling languagematter for translation purposes.

If a class is represented graphically as a box, or even as text,this is of no consequence. The UML is just an accessible graphicalfront-end for those simple elements.

When you build a 'class' such as CookingStep in amicrowave oven, that represents a set of possible cooking steps youmight execute, each with a cooking time and power level.

Similarly, when you describe the lifecycle of a cooking step using astate machine, it follows a sequence of states as synchronized by otherstate machines, external signals, and timers. And in each state, weexecute some functions. All of this structure and behavior, for theentire model, is captured as data in the metamodel.

Rules and Rule Languages
Now that we have a verified platform-independent model of ourapplication captured as a metamodel, we can translate it into hardwareand software description languages, such as VHDLor C, using a model compiler. A model compiler is implemented as a setof rules.

One rule might take a 'class' represented as a set CookingStep(cookingTime, powerLevel ) , and produce a class declaration.Crucially, the rule could just as easily produce a struct for a Cprogram, or a VHDL entity. Similarly, we may define rules that turnstates into arrays, lists, switch statements, or follow the Statepattern from the DesignPatterns community.

(This is why we put 'class' inquotation marks. A 'class' in an executable model represents the set ofdata that can be transformed into anything that captures that data; ina blueprint-type model, a class is an instruction to construct a classin the software .)

These rules let us separate the application from the architecture.The xtUML modelcaptures the problem domain graphically, and represents it in themetamodel. The rules read the application as stored in the metamodel,and turn that into code.

There are many possible rule languages, and the ObjectManagement Group is now working to define a standard [1] . All that's required is theability to traverse a model and emit text. As an example, the rule below generates code forprivate data members of a class by selecting all related attributes anditerating over them.

.function PrivateDataMember(class Class )
.select many PDMs from instances ofAttribute related to Class
.for each PDM in PDMs
${PDM.Type} ${PDM.Name};

All lines beginning with a period ('.' )are commands to the rule language processor, which traverses themetamodel whose instances represent the executable model and performstext substitutions.

${PDM.Type} recovers the type of the attribute, and substitutes it on the outputstream. Similarly, the fragment ${PDM.Name} substitutes the name of the attribute. The space that separates themand the lone ';' is just text, copied without change onto the output stream, as shownbelow:

You may wonder what the produced code is for. It is an enumerationthat contains each of the states of a state machine for a class. (There is a similar rule that produces anenumeration of signals. )

The enumerations are used to declare a two-dimensional arraycontaining the pointers to the activity to be executed. You may notlike this code, or you may have a better way to do it.

Cool: all you have to do is modifythe rule and regenerate. Every single place where this code appearswill then be changed. Propagating changes this way enables rapidperformance optimization.

While the generated code is less than half the size of the rule, therule can generate any number of these enumerations, all in the sameway, all equally right—or wrong. We have also used the rule language togenerate VHDL, as follows:

The rule language can be used in conjunction with the generator togenerate code in any language: C, C++, Java, Ada, and, if you know thesyntax, Klingon.

Model Compilers and SystemConstruction
Figure 1 below shows theoverall structure of a model compiler. The application is captured inthe metamodel, and the model compiler comprises some library code and aset of rules. The rules are interpreted against the metamodel toproduce text. The rules may also “wrap” external libraries and legacycode. All of this is compiled—using the appropriate compilers—toproduce the system-on-a-chip.

Figure1: Model Compiler and System Construction

The overall architecture of the generated system is determined bythe model compiler. Each model compiler is thus coupled to the target,but the model compiler is independent of the application models that ittranslates. This separation of application from design allows us toreuse both application model and model compiler as needed.

We can translate the same application model for many differenttargets by using different model compilers, but the models of theapplication do not change. Similarly we can use the same model compilerto translate any number of application models for a given targetwithout changing the model compiler.

For example, a model compiler for an object-oriented architecturewill likely contain rules to translate each UML class to a C++ class ora C struct with each associated UML attribute being translated to adata member of the class or a member of the struct.

The state machines in the application model would be translated intotwo dimensional arrays where the row index represents the current stateof an object, and the received event provides the column index. Eachcell contains the value of the next state for the transition identifiedby the current state (row) and thereceived event (column) .

This next-state value is then used as an index into an array offunction pointers, each corresponding to a state. This particularapproach leads to a constant-time dispatching mechanism for the actionsof each state machine.Of course we can use alternative implementations depending on ourneeds.

For example, in some cases, we might choose to use a switchstatement or nested if-else statements to implement the state machine,each of which would have slightly different speed and spacecharacteristics (if-else is linear inthe product of states and events ).

For hardware implementations we might choose to translate each UMLclass into a collection of registers, one for each attribute in theclass. Each state machine of the application model could be mapped to aVHDL case statement. There are, of course, many other possibleimplementations. UML classes can be mapped into blocks of RAM, andstate machines can be translated into a data-driven andgate-conservative dispatcher.

But what about the interfaces between the hardware and softwarecomponents of the system? These interfaces are just a part of thearchitecture encapsulated within the model compiler.

Let's look at a simple example.
Suppose we have two UML classes, CookingStep and Oven where CookingStep istranslated to software and Oven istranslated to hardware. In this case the hardware architecture for Oven is acollection of memory-mapped registers.

The generated interface for an action in CookingStep thataccesses an attribute of Oven is then asimple memory access of the address allocated for the register inquestion.

Consider a slightly different hardware architecture in which the UMLclass Oven is mapped to only two addresses, one representing a control registerand one for a data register. Accesses to attributes of the class wouldthen be accomplished by writing the attribute identifier and the typeof access (read or write) to the control register and then manipulatingthe data register accordingly (reading it after writing to the controlregister or writing it before writing to the control register).

Since the model compiler is generating the implementation for boththe hardware and the software components of the system, it hassufficient information to generate the interface between the two, andit will do so without succumbing to the ambiguities of a naturallanguage specification. And it will do it correctly, every time.

It's possible to build and deploy model compilers that providecompletely open translation systems. Exposing the translation rules inthis way allows you to make changes to the rules to meet yourparticular needs so that the model compiler generates code exactly theway you want. This puts the translation of the models completely underyour control.

The importance of marks in your UML design
To tell the model compiler whether to generate hardware or software fora given model element we need additional inputs to decide which mappingto perform. These additional inputs are provided as marks, which arelightweight, non-intrusive extensionsto models that capture information required for modeltransformation without polluting those models.

Each kind of mark has a name and a type. In addition, a kind of markcan have a default value. In programmer-esque language, we might write:

Mark HardSoft [ isHardware,isSoftware ] = isSoftware

which declares a kind of mark named HardSoft thatcan have one of two values, where the default is isSoftware .

Most marks apply to instances of metaclasses, so that, for example,if we have a metamodel with class Class, and two instances of thatclass, Oven andCookingStep ,the mark HardSoft can have a separate value for each of those instances, isHardware forthe Oven ,say, and isSoftware for the CookingStep .

Were the kind of mark to apply instead to generated signals, thenthe marks would be associated with instances of the class GenerateSignalAction in the metamodel. A given application model element can have severalmarks associated with it. Each of these marks is an extended attributeof the appropriate metamodel class.

Metacasses as plastic sheets
We do not intend to leave the impression that the metamodel should beextended directly. Marks are not part of either the application modelor the metamodel, though they can refer to them both. Rather, we viewthe extended attributes of the metaclasses as being housed on a plasticsheet that can be peeled off at will for a different model compiler.This separation supports both model portability and longevity.

The separation also provides the ability to evaluate a number ofdifferent architectural possibilities without requiring modification ofthe application model. Just change the values of the marks. Not to puttoo fine a point on it, this solves the problem of changing thehardware-software partition after we have verified the behavior of theapplication model by executing test cases against it.

The plastic sheet analogy suggests that some marks might be relatedand could all be placed on the same sheet. A single sheet could containmultiple related marks, such as those indicating which types ofhardware implementations should be applied to which elements of theapplication model. Removal of the plastic sheet, then, implies theremoval of the entire hardware architecture represented by that sheetfrom the system.

Marks may also be quantities used to optimize the targetimplementation. Consider a model that must be transformed into animplementation that occupies as small an amount of memory as possible.We can save memory if we observe that a particular class has only oneinstance (e.g.,Oven ). Such a class can be marked as extentLess , andno container need be generated for instances of that class, makingreferences to the instances more efficient.

Similarly, we can make trade-offs within the hardware architecture.Suppose the original target had plenty of address space available andconsequently mapped each class attribute implemented in hardware to aspecific address, making the software access to the attributes simpleand efficient.

In a subsequent release we move to a lower-cost processor with aconstrained address space. Through marks we then instruct the modelcompiler to use a single pair of addresses for each class to provideaccess to all the attributes in the class. Since the model compilerknows how to generate the software required for this more interestingapproach for accessing hardware-resident attributes, the applicationmodels do not change even though the nature of the hardware/softwareinterface has been drastically altered.

There have to be ways for the modeler to assign values to marks.Some implementations provide for graphical drag-and-drop allocation ofmodel elements into folders that correspond with marks; others definean editor for the defined mark sets that can display all marks definedby the model for a selected model element, with pull-down menus foreach of the marks. Another option is to define text files, and then usethe large set of available editing, and scripting tools.

In the final article of this series, we assess progress instandardization, and in the market.

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.”

This series isreprinted in four parts from Chapter 2 of “ UMLforSoC Design“with permission of Springer.

StephenJ. Mellor , Chief Scientist of the Embedded SoftwareDivision 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 , Director of Operations and Engineeringfor theBridgePoint UML suite at Mentor Graphics, was President and CEO ofProject Technology, Inc., since acquired by Mentor Graphics acquiredthe company, which was focused on tools to execute and translate UMLmodels in the context of Agile MDA.

Campbell D.McCausland is a PrincipalEngineer, Mentor GraphicsCorp, where he is the chief designer of the BridgePoint UML Suite. Heis the creator of (to his knowledge) the very first model compiler thattranslates xtUML models to behavioral VHDL.

John Wolfe will be at the upcomingEmbedded SystemsConference Boston, September 25-28 at the Mentor Graphics booth#1201.  In addition, CortlandStarret t will be conducting a series ofseminars. Go to  to check on the speaker's scheduledetails. Starrett is Engineering Manager leading development oftranslationtechnology at Mentor Graphics, responsible for the production of toolsandmethods for translating xtUML models into source code such as C, C++,Java andVHDL.

[1] MOF Model to Text Transformation RfP – 

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)FromUML to embedded system: Is it possible?

Leave a Reply

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