Difference between revisions of "Design Partitioning"
(→How) |
(→How) |
||
Line 20: | Line 20: | ||
Small blocks are '''much''' easier to constrain, to implement and verify, and to reuse in future projects. | Small blocks are '''much''' easier to constrain, to implement and verify, and to reuse in future projects. | ||
− | With an overview of the blocks in | + | With an overview of the blocks in the diagram, now take a look at the system constraints. |
The constraints can have a diverse nature, examples could be: | The constraints can have a diverse nature, examples could be: | ||
Line 27: | Line 27: | ||
* The device must be field-upgradable, without disassembly. | * The device must be field-upgradable, without disassembly. | ||
* The device must be build around an NXP lpc2478 ARM7 CPU. | * The device must be build around an NXP lpc2478 ARM7 CPU. | ||
− | * The device must be able to | + | * The device must be able to accommodate future feature add-ons. |
− | ''A production price of 3$ implies certain restrictions on the selection of components, from | + | ''A production price of 3$ implies certain restrictions on the selection of components, from which to build the platform from. I.e it would probably be necessary to select a low cost, targeted microcontroller that matches the immediate needs, instead of reusing the large microcontroller platform already known.'' |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
+ | ''A lifetime of 25 years implies selecting hardware with great care, paying special attention to temperature ratings, lifetime, de-rating usage parameters, etc.'' | ||
The difference between '''requirements''' and '''constraints''' can be identified as follows | The difference between '''requirements''' and '''constraints''' can be identified as follows | ||
* Requirements are used for design and verification of all blocks in a design. | * Requirements are used for design and verification of all blocks in a design. | ||
− | * Constraints defines overall | + | * Constraints defines overall behaviour and guidelines for the system-to-be to conform to. |
==Why== | ==Why== |
Revision as of 09:04, 15 July 2015
What
Assigning responsibility and functionality, within the entire system, to blocks and components, hereby resulting in updated block and component diagrams.
How
Ingredients
- One or more drafts of the blockdiagram of you system-to-be
- System requirements and design constraints
Process
The process of partitioning a design can have multiple approaches, depending on the prerequisites.
A good starting point for performing partitioning would be to take a look at the block diagram.
The correct block diagram, represents all the functional blocks in your design, each fulfilling a part of the systems functionality. The obvious advantage of splitting functionality into small manageable blocks is: simplicity.
Small blocks are much easier to constrain, to implement and verify, and to reuse in future projects.
With an overview of the blocks in the diagram, now take a look at the system constraints.
The constraints can have a diverse nature, examples could be:
- The YYY device must have a maximum production price of 3$
- The lifetime of the device must be a minimum 25 Years
- The device must be field-upgradable, without disassembly.
- The device must be build around an NXP lpc2478 ARM7 CPU.
- The device must be able to accommodate future feature add-ons.
A production price of 3$ implies certain restrictions on the selection of components, from which to build the platform from. I.e it would probably be necessary to select a low cost, targeted microcontroller that matches the immediate needs, instead of reusing the large microcontroller platform already known.
A lifetime of 25 years implies selecting hardware with great care, paying special attention to temperature ratings, lifetime, de-rating usage parameters, etc.
The difference between requirements and constraints can be identified as follows
- Requirements are used for design and verification of all blocks in a design.
- Constraints defines overall behaviour and guidelines for the system-to-be to conform to.
Why
Design Partitioning is an essential part of [System architecture].
Modeling The system architecture is an activity composed of :
- modeling the blockdiagram,
- partitioning the design
- assessing the designs constraints
After performing partitioning (probably more than one try...), you should end up with the final blueprint for your design, aka. 'The System Architechture