Difference between revisions of "Design Partitioning"
(→What) |
(→Example) |
||
| (21 intermediate revisions by 2 users not shown) | |||
| Line 6: | Line 6: | ||
'''Ingredients''' | '''Ingredients''' | ||
| − | * One or more drafts of the [[ | + | * One or more drafts of the [[Blockdiagram]] of your system-to-be |
* System requirements and design constraints | * System requirements and design constraints | ||
| Line 13: | Line 13: | ||
The process of partitioning a design can have multiple approaches, depending on the prerequisites. | 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. | + | A good starting point for performing partitioning would be to take a look at the block diagram, and discuss whether each functional block has sufficient responsibility or too much functionality in the system. |
| + | |||
| + | A correct block diagram represents all the functional blocks in your design, each fulfilling a part of the system's functionality. | ||
| + | The obvious advantage of splitting the functionality into small manageable blocks is: '''simplicity'''. | ||
| − | + | Small blocks are '''much''' easier to constrain, to implement and verify and to reuse in future projects. | |
| − | + | ||
| − | + | When dividing your system-to-be into functional blocks, expect to do multiple iteration, where you describe the desired functionality in each block and model its interfaces. A simple thing as giving the blocks meaningful names has often been a topic for discussion. But it should not be neglected; a block name gives your reader a quick impression of the functionality one can expect. | |
| − | With an overview of the blocks in the diagram, now take a look at the system constraints. | + | With an overview of the blocks in the diagram, you should now take a look at the system constraints. |
| − | 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 | + | * Constraints define overall behaviour and guidelines with which the system-to-be shall conform. |
==Why== | ==Why== | ||
| − | Design | + | Design partitioning is an essential part of the system architecture. |
| − | + | Modelling the system architecture is an activity consisting of: | |
| − | * | + | * Modelling the block diagram |
| − | * | + | * Partitioning the design |
| − | * | + | * Assessing the design's constraints |
| + | * Rewriting functional descriptions and refining interfaces between blocks until you have a system architecture that balances well with the system-to-be's architecture | ||
| − | After | + | After the partitioning (probably more than one try), the outcome should be the final blueprint for the design, i.e. '''the system architecture'''. |
==Example== | ==Example== | ||
| − | The constraints can | + | |
| − | * The device must have a maximum production price of | + | Consider the two block diagrams below. |
| − | * The lifetime of the device must be a minimum 25 | + | |
| − | * The device must be field-upgradable | + | The first is an example of a diagram illustrating "what components are on my desktop today". |
| − | * The device must be build around an | + | |
| + | The diagram does not devote much attention to partitioning the systems functionality into modular blocks. | ||
| + | |||
| + | In addition, this design will most likely suffer from | ||
| + | * A lack of requirements | ||
| + | * A lack of use cases being modelled | ||
| + | * A lack of the dynamics of the system being modelled and discussed. | ||
| + | |||
| + | [[File:poorDesign.png|800px|border|Figure 1: A poorly specified block diagram]] | ||
| + | |||
| + | |||
| + | The second diagram shows a better block diagram. Here, some discussion has led to division of functionality into logical functional blocks that can be specified. | ||
| + | |||
| + | The naming of the blocks are more generic in this example. From good and generic naming you will not be locked by design decisions, and you will still be able to select the suitable technology to implement the solution. | ||
| + | |||
| + | [[File:betterDesign.png|800px|border|Figure2: A better version of the same block diagram where some partitioning of the system functionality has been considered]] | ||
| + | |||
| + | |||
| + | Each functional block can be affected by the systems design constraints. | ||
| + | |||
| + | Design constraints can be of diverse nature. Examples could be: | ||
| + | * The 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 certain vendor and model CPU. | ||
* The device must be able to accommodate future feature add-ons. | * The device must be able to accommodate future feature add-ons. | ||
| − | ''A production price of | + | ''A production price of $3 implies certain restrictions on the selection of components from which to build the platform. In other words, 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.'' | ''A lifetime of 25 years implies selecting hardware with great care, paying special attention to temperature ratings, lifetime, de-rating usage parameters, etc.'' | ||
''Field-upgradability leads to design with network connectability.'' | ''Field-upgradability leads to design with network connectability.'' | ||
| + | |||
| + | Such constraints can lead to several iterations of the block diagram, until the functionality of the system can be implemented on the selected architecture. | ||
Latest revision as of 12:08, 23 November 2015
What
Assigning responsibility and functionality to blocks and components within the entire system, thus resulting in updated block and component diagrams.
How
Ingredients
- One or more drafts of the Blockdiagram of your 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, and discuss whether each functional block has sufficient responsibility or too much functionality in the system.
A correct block diagram represents all the functional blocks in your design, each fulfilling a part of the system's functionality. The obvious advantage of splitting the functionality into small manageable blocks is: simplicity.
Small blocks are much easier to constrain, to implement and verify and to reuse in future projects.
When dividing your system-to-be into functional blocks, expect to do multiple iteration, where you describe the desired functionality in each block and model its interfaces. A simple thing as giving the blocks meaningful names has often been a topic for discussion. But it should not be neglected; a block name gives your reader a quick impression of the functionality one can expect.
With an overview of the blocks in the diagram, you should now take a look at the system constraints.
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 define overall behaviour and guidelines with which the system-to-be shall conform.
Why
Design partitioning is an essential part of the system architecture.
Modelling the system architecture is an activity consisting of:
- Modelling the block diagram
- Partitioning the design
- Assessing the design's constraints
- Rewriting functional descriptions and refining interfaces between blocks until you have a system architecture that balances well with the system-to-be's architecture
After the partitioning (probably more than one try), the outcome should be the final blueprint for the design, i.e. the system architecture.
Example
Consider the two block diagrams below.
The first is an example of a diagram illustrating "what components are on my desktop today".
The diagram does not devote much attention to partitioning the systems functionality into modular blocks.
In addition, this design will most likely suffer from
- A lack of requirements
- A lack of use cases being modelled
- A lack of the dynamics of the system being modelled and discussed.
The second diagram shows a better block diagram. Here, some discussion has led to division of functionality into logical functional blocks that can be specified.
The naming of the blocks are more generic in this example. From good and generic naming you will not be locked by design decisions, and you will still be able to select the suitable technology to implement the solution.
Each functional block can be affected by the systems design constraints.
Design constraints can be of diverse nature. Examples could be:
- The 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 certain vendor and model 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. In other words, 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.
Field-upgradability leads to design with network connectability.
Such constraints can lead to several iterations of the block diagram, until the functionality of the system can be implemented on the selected architecture.
