How to use UML in your SoC hardware/software design: Part 1 - Embedded.com

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

From determining the hardware/software partition to meeting performanceand cost objectives, the job of building systems on a chip has neverbeen easy, and with ever-increasing demand for more functionalitypacked into smaller spaces consuming less power, building systems on achip is unquestionably becoming more complex every day.

Add to this the desire to shrink development cycles and reduce theoverall cost of the system, and you have an acute need to raise thelevel of abstraction and reduce unnecessary miscommunication betweenhardware and software teams.

To meet this need, several specification languages have beenproposed such as Handel-C , SystemC,and so on. These languagesunite hardware and software to some degree, but C is at such a lowlevel of abstraction that software engineers have begun to move awayfrom it as a specification language and use a more abstract modelinglanguage, namely the Unified ModelingLanguage (UML).

As with most of the hardware-oriented C variants, one solution tothe problem of taking a software-oriented language for use in SoC is toadd hardware features to it. The same has been proposed for UML [1] , but we propose the opposite:use only the minimum necessary to specify system functionality.

We then use model mappings, coupled with marks that indicate whichmapping rule to apply, to translate the application model into hardwareand software description languages. This approach enables a majorsimplification of the use of UML in SoC, and correspondingsimplification of the work of SoC developers.

The State of the Practice
SoC design can be broken down into three important tasks:

(1) partitioning the designinto hardware and software segments,
(2) understanding thehardware/software interface; and
(3) integration of the hardwareand the software.

Partition: Atthe beginning of an SoC project, it is common for the hardware andsoftware teams to build a specification, usually in natural language.This defines a proposed partitioning into hardware and software so thetwo teams, with different skills, can head off in parallel.

Verifying the hardware/software partition requires the ability totest the system, but it takes months of effort to produce a prototypethat can be executed.

Yet we need to execute the prototype before we will know whether thelogic designers and the software engineers have the same understandingof the hardware/software interface. We also need to run the prototypesystem before we can measure its performance, but if the performance isunacceptable, we must spend weeks changing the hardware/softwarepartition, making the entire process circular.

Interface: The only thing connecting the two separate teams, heading off inparallel, each with different skills, is a hardware/software interfacespecification, written in natural language. Two teams with disparatedisciplines working against an ambiguous document to produce a coherentsystem.

Sounds like a line from a cheap novel.

Invariably, the two components do not mesh properly. The reasons aremyriad: the logic designers didn't really mean what they said aboutthat register in the document; the software engineers didn't read allof the document, especially that part about waiting a microsecondbetween whacking those two particular bits; and of course, the mostcommon failure mode of all, logic interface changes that came aboutduring the construction of the behavioral models that didn't make itback into the interface specification.

Integration: So what's a few interface problems among friends? Nothing really. Justtime. And money. And market share. We've been doing it this way foryears. It's nothing a few days (well, weeks) in the lab won't solve.Besides, shooting these bugs is fun, and everyone is always so pleasedwhen it finally works. It's a great bonding experience.

Eventually, the teams manage to get the prototype running, at leastwell enough that they can begin measuring the performance of thesystem. “Performance” has a number of meanings: Along with the obviousexecution time and latency issues, memory usage, gate count, powerconsumption and its evil twin, heat dissipation, top the list ofperformance concerns in many of today's embedded devices.

There's nothing like a performance bottleneck to throw a bucket ofcold water on the bonding rituals of the integration heroes. Unlikeinterface problems, you don't fix hardware/software partition problemswith a few long nights in the lab. No, this is when the engineers headback to their desks to ponder why they didn't pursue that career as along-haul truck driver. At least they'd spend more time at home.

What Wrong with That?
The problems associated with working this way are deeply interrelated.

Partition: Forthe early part of the process, logic designers andcoders are actually doing the same thing, just using differentapproaches. Distilled, we are all involved in:

* Gathering,analyzing, and articulating product requirements.
* Creatingabstractions for solutions to these requirements.
* Formalizing theseabstractions.
* Rendering theseabstractions in a solution of some form.
* Testing the result(almost always through execution).

So, why can't we all just get along? At least in the beginning.

Interface: It is typical to describe the interface between hardware andsoftware with point-by-point connections, such as “write 0x8000 to address 0x3840 to activatethe magnetron tube ;” and “whenthe door is opened interrupt 5 will be activated .”

This approach requires that each connection between hardware andsoftware be defined, one by one, even though there is commonality inthe approach taken. Using a software example, each function call takesdifferent parameters, but all function calls are implemented in thesame way.

At present, developers have to construct each interface by hand,both at specification and implementation time. We need to separate thekinds of interface (how we do function calls) from each interface (theparameters for each function call) and apply the kinds of interfaceautomatically just like a compiler.

Integration: Wepartitioned the system specification into hardware and software becausethey are two very different products with different skills required toconstruct them. However, that partitioning introduces multiple problemsas we outlined above so we need to keep the hardware and software teamsworking together for as long as possible early in the process bymaintaining common elements between the two camps. That which theyshare in common is the functionality of the system—what the systemdoes.

A significant issue in system integration, even assuming thehardware and software integrate without any problem, is that theperformance may not be adequate. Moreover, even if it is adequate atthe outset, version 2.0 of the product may benefit from shifting somefunctionality from software to hardware or vice versa. And here we are,back at the partitioning problem.

Evaluating Potential UML solutions
Happily, the problems described above do suggest some solutions.

Build a SingleApplication Model: The functionality of the system can beimplemented in either hardware or software. It is thereforeadvantageous to express the solution in a manner that is independent ofthe implementation. The specification should be more formal thanEnglish language text, and it should raise the level of abstraction atwhich the specification is expressed, which, in turn, increasesvisibility and communication. The specification should be agreed uponby both hardware and software teams, and the desired functioningestablished, for each increment, as early as possible.

Build anExecutable Application Model: Indeed, the specification shouldbe executable. The UML is a vehicle for expressing executablespecifications now that we have the action semantics of UML 1.5 and itslatest version, the action model of UML 2.0. This action model wasexpressly designed to be free of implementation decisions and to allowtransformation into both hardware and software. Executable applicationmodels enable earlier feedback on desired functionality.

Don't ModelImplementation Structure: This follows directly from the above.If the application model must be translatable into either hardware orsoftware, the modeling language must not contain elements designed tocapture implementation, such as tasking or pipe-lining.

At the same time, the modeling language must be rich enough to allowefficient implementations. Chief among the topics here is concurrency,both at the macro level (several threads of control as tasks orprocessors and blocks of logic that execute concurrently) and at themicro level (several elements in a computation executing at once).

In other words, we need to capture the natural concurrency of theapplication without specifying an implementation.

Map theApplication Model to Implementation: We translate the executableUML application model into an implementation by generating text inhardware and software description languages. This is accomplished by aset of mapping rules that reads selected elements of the executable UMLapplication model and produces text. The rules, just like a softwarecompiler generating a function call in our example above, establish themechanisms for communicating between hardware and software according tothe same pattern.

Crucially, the elements to be translated into hardware or softwarecan be selected by marking up the application model, which allows us tochange the partition between hardware and software as a part ofexploring the architectural solution space.

All this provides a way to eliminate completely thehardware/software interface problems that are discovered during theinitial integration, and to allow us to change the partition betweenthe hardware and software in a matter of hours.

The Key to a Solution: The DottedLine
A UML model can be made executable by simply adding code to it.However, this approach ties the model to a specificimplementation—precisely what we wish to avoid. Instead, we must allowdevelopers to specify functionality without specifying implementation

How can we capture the functionality of the system withoutspecifying implementation? The trick is to separate the applicationfrom the architecture, and this is the key to a solution. Figure 1, below, illustrates thisseparation.

Figure1. The separation between application and architecture

The top left of Figure 1, above, shows an executable UML model. Below the dotted line we show one of aset of mapping rules that refers to simple UML elements such as class.By executing the rules automatically, we may generate code. But the keyis the dotted line that separates the two parts.

The dotted line between “application” and “architecture” enables thecapture of an executable application model by representing it in asimple form: sets of data that are to be manipulated; states theelements of the solution go through; and some functions that execute toaccess data, synchronize the behavior of the elements, and carry outcomputation. This dotted line, consisting of sets, states, andfunctions, captures the modeling language.

A selection of these simple elements makes up an executable UMLmodeling language. The elements are primitive enough to be translatableinto multiple implementations, but powerful enough to be useful. Oncewe determine exactly which elements make up executable UML, we canmanipulate those elements completely independently of the applicationdetails, including whether to implement behavior in hardware orsoftware.

We take up the definition of executable UML [2] in Part 2 in this series:”Executable UML 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 www.embedded.com/esc/boston/  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.

References:
[1] UML Profile forSystem on a Chip at OMG Web site.
[2] Executable UML: A Foundation for Model-DrivenArchitecture, Mellorand Balcer, Addison-Wesley, 2002.

Otherresources on Embedded.com 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.