How to use UML in your SoC hardware/software design: Part 1
Jul 17 2006 (10:00 AM), Embedded.com
From determining the hardware/software partition to meeting performance and cost objectives, the job of building systems on a chip has never been easy, and with ever-increasing demand for more functionality packed into smaller spaces consuming less power, building systems on a chip is unquestionably becoming more complex every day.
Add to this the desire to shrink development cycles and reduce the overall cost of the system, and you have an acute need to raise the level of abstraction and reduce unnecessary miscommunication between hardware and software teams.
To meet this need, several specification languages have been proposed such as Handel-C, SystemC, and so on. These languages unite hardware and software to some degree, but C is at such a low level of abstraction that software engineers have begun to move away from it as a specification language and use a more abstract modeling language, namely the Unified Modeling Language (UML).
As with most of the hardware-oriented C variants, one solution to the problem of taking a software-oriented language for use in SoC is to add 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 which mapping rule to apply, to translate the application model into hardware and software description languages. This approach enables a major simplification of the use of UML in SoC, and corresponding simplification of the work of SoC developers.
E-mail This Article | Printer-Friendly Page |
Related Articles
- How to use UML in your SoC hardware/software design: Part 4
- How to use UML in your SoC hardware/software design: Part 3
- How to use UML in your SoC hardware/software design: Part 2
- Hardware/software design requirements analysis: Part 1 - Laying the ground work
- How to make virtual prototyping better than designing with hardware: Part 1