Design Partitioning

From EUDP
Revision as of 15:55, 27 August 2012 by Klaus (Talk)

Jump to: navigation, search

What

How

The dish

Ingredients

Process

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

How

Ingredients

  • One or more drafts of the blockdiagram of you system-to-be
  • System requirements and design constraints
  • Hardware, Software and System - engineers

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 your diagram, now take a look at your 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 accomodate future feature add-ons.

A production price of 3$ implies certain restrictions on the selection of components, from wich to build the platform from. i.e you would probably need to select a low cost, targeted microcontroller that matches your immediate needs, instead of reusing the large microcontroller platform you are familiar with

A lifetime of 25 years implies selecting hardware with great care, paying special attention to temperature ratings, lifetime, derating usage parameters etc...

Being able to


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 behavior and guidelines for the system-to-be to conform to.