English
MIPI D-PHY / C-PHY Combo IP for TSMC (5nm, 6/7nm, 12/16nm, 22nm, 28nm, 40nm)
An architecture for designing reusable embedded systems software, Part 1
By Dinu P. Madau, Visteon Corporation
Embedded.com (05/01/08, 12:00:00 AM EDT)
Want to make your application software more reusable? Don't change the hardware, operating system, or your tools. Instead change the architectural framework within which you do your design.
The drive to reduce product development cycle times has led to the need for designing reusable code. It's apparent that reusing code across software projects decreases project development time. Nonetheless, software engineers often resist developing reusable code because they're burdened by time-to-delivery commitments.
From design to documentation, reusable code requires that project managers assign additional resources up front. Project managers must decide whether to initially spend the extra effort in designing reusable software modules, which would benefit the long term, or to first quickly design the software to meet their clients' deadlines and later rework the modules to be reusable.
In an effort to reduce the development time of designing reusable software, adopting an architectural template that can be applied from project to project would be beneficial. The template would define hardware-independent reusable modules and an interface layer that is hardware dependent--changing when the hardware in the system changes. By applying the architecture template consistently across several program platforms, the goal would be to decrease the development time from one project to another while improving the maintainability of the software product.
Let's start off by viewing the overall system as an object that is partitioned into several smaller objects or layers. Some of these objects are written to be reusable while others, by design, are dependent on the hardware and have to change when the hardware changes. We can divide the system into four distinct layers as shown in Figure 1. The perceived system behavior, the outermost layer of the system, is where the users expect a certain behavior, typically defined in a functional requirements document. For example, when someone pushes the call button for an elevator, they expect that within some reasonable amount of time the elevator door will open allowing the person to enter and choose a desired floor.
Embedded.com (05/01/08, 12:00:00 AM EDT)
Want to make your application software more reusable? Don't change the hardware, operating system, or your tools. Instead change the architectural framework within which you do your design.
The drive to reduce product development cycle times has led to the need for designing reusable code. It's apparent that reusing code across software projects decreases project development time. Nonetheless, software engineers often resist developing reusable code because they're burdened by time-to-delivery commitments.
From design to documentation, reusable code requires that project managers assign additional resources up front. Project managers must decide whether to initially spend the extra effort in designing reusable software modules, which would benefit the long term, or to first quickly design the software to meet their clients' deadlines and later rework the modules to be reusable.
In an effort to reduce the development time of designing reusable software, adopting an architectural template that can be applied from project to project would be beneficial. The template would define hardware-independent reusable modules and an interface layer that is hardware dependent--changing when the hardware in the system changes. By applying the architecture template consistently across several program platforms, the goal would be to decrease the development time from one project to another while improving the maintainability of the software product.
Let's start off by viewing the overall system as an object that is partitioned into several smaller objects or layers. Some of these objects are written to be reusable while others, by design, are dependent on the hardware and have to change when the hardware changes. We can divide the system into four distinct layers as shown in Figure 1. The perceived system behavior, the outermost layer of the system, is where the users expect a certain behavior, typically defined in a functional requirements document. For example, when someone pushes the call button for an elevator, they expect that within some reasonable amount of time the elevator door will open allowing the person to enter and choose a desired floor.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
Related Articles
- An architecture for designing reusable embedded systems software, Part 2
- Embedded DSP Software Design on a Multicore SoC Architecture: Part 1
- Optimizing embedded software for power efficiency: Part 1 - measuring power
- A guide to VHDL for embedded software developers: Part 1 - Essential commands
- Providing memory system and compiler support for MPSoc designs: Memory Architectures (Part 1)
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Design Rule Checks (DRC) - A Practical View for 28nm Technology
- Layout versus Schematic (LVS) Debug