How to use UML in your SoC hardware/software design: Part 1
By Stephen J. Mellor, John R. Wolfe and Campbell McCausland, Mentor Graphics
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.
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.
To read the full article, click here
Related Semiconductor IP
- HBM4 PHY IP
- eFuse Controller IP
- Secure Storage Solution for OTP IP
- Ultra-Low-Power LPDDR3/LPDDR2/DDR3L Combo Subsystem
- MIPI D-PHY and FPD-Link (LVDS) Combinational Transmitter for TSMC 22nm ULP
Related Articles
- How to manage changing IP in an evolving SoC design
- How to make virtual prototyping better than designing with hardware: Part 1
- How to reuse your IIoT technology investments - now
- How to use snakes to speed up software without slowing down the time-to-market?
Latest Articles
- Making Strong Error-Correcting Codes Work Effectively for HBM in AI Inference
- Sensitivity-Aware Mixed-Precision Quantization for ReRAM-based Computing-in-Memory
- ElfCore: A 28nm Neural Processor Enabling Dynamic Structured Sparse Training and Online Self-Supervised Learning with Activity-Dependent Weight Update
- A 14ns-Latency 9Gb/s 0.44mm² 62pJ/b Short-Blocklength LDPC Decoder ASIC in 22FDX
- Pipeline Stage Resolved Timing Characterization of FPGA and ASIC Implementations of a RISC V Processor