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

In the first article in this series, we introduced the notion of an executable UML, but we did not describe the elements of which it consists. These elements must be sufficiently primitive to be translatable into multiple implementations, including hardware, but be powerful enough to be useful.

The number of elements in executable UML must also be low to ease the construction of translators, to ease the burden of learning the language, and to eliminate the ambiguity that accompanies the use of multiple constructs to represent the same concept. Determining exactly which elements make up an executable UML is therefore a matter of judgment.

In this second article, we describe the elements of Executable and Translatable UML (xtUML, or just Executable UML) [1], how actions enable description of behavior at a higher level of abstraction, the dynamic behavior of an executable UML model, and how a model of an SoC design can be verified before committing to a hardware-software partition.