How to use UML in your SoC hardware/software design: Part 2
Jul 24 2006 (9:00 AM), Embedded.com
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.
To read the full article, click here
Related Semiconductor IP
- MIL-STD-1553 Controller IP
- UFS 5.x Device IP
- UCIe 3.x Controller IP
- Ethernet 800G PCS IP
- CHI to UCIe Bridge IP
Related Articles
- How to manage changing IP in an evolving SoC design
- How to reuse your IIoT technology investments - now
- How to use snakes to speed up software without slowing down the time-to-market?
- How a voltage glitch attack could cripple your SoC or MCU - and how to securely protect it
Latest Articles
- CHIA: An open-source framework for principled, agentic AI-driven hardware/software co-design research
- Croc: Training the Next Generation Chip Designers on Domain-Specific End-to-End Open Source Silicon
- Design and Development of a Neuromorphic Silicon Suite: PVT Sensing, Stochastic LIF Inference, On-Chip STDP Learning, and Crossbar Programming
- LLM4RTL: Tool-Assisted LLM for RTL Generation
- Towards Delta Aware Training: Efficient DNN Weight Storage for Resource-Constrained FPGAs