Design Integrity Concepts - PowerPoint PPT Presentation


PPT – Design Integrity Concepts PowerPoint presentation | free to download - id: 4a60c7-NzlhY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Design Integrity Concepts


Design Integrity Concepts Unit Agenda Consistent terminology, consistent results Introduction and definitions What does it have to do? Specifying the design ... – PowerPoint PPT presentation

Number of Views:119
Avg rating:3.0/5.0
Slides: 143
Provided by: klabsOrgm2
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Design Integrity Concepts

Design Integrity Concepts
Unit Agenda
  • Consistent terminology, consistent results
  • Introduction and definitions
  • What does it have to do?
  • Specifying the design
  • Letting constraints work for you
  • Proportional design
  • More than the sum of its parts
  • Partitioning a design
  • You mean were still working on it?
  • Sustaining a design
  • Whats the exit strategy?
  • Verifying a design
  • What do you mean, it doesnt do what we thought?
    Validating a design

Who is this guy?
  • John Stone
  • Chief Engineer (Department of Space Systems
  • 18 years experience (Exclusively space-flight)
  • CDH design (hardware and software)
  • Instrument electronics design
  • Box-level integration and test
  • Hardware project management
  • Product assurance (parts, radiation, reliability)
  • Process improvement
  • Broad interest in improving what we do

What do we want to accomplish?
  • Discuss techniques that may help us to do our
    jobs better
  • Based on general principles
  • Broad applicability (logic, board, box, system)
  • Foster necessary discussion / brainstorming
  • To extent possible (as time allows)
  • No one person has all of the answers
  • Suggestions appreciated

Consistent Terminology, Consistent Results
  • Introduction and Definitions

Agenda Introductions and Definitions
  • Design integrity A working definition
  • Why is this important?
  • A tale of two designs
  • Has anything changed?
  • Why should I care?
  • The miracle cloud
  • The alternative
  • Overview
  • Implications
  • Additional Definitions
  • Summary

Definition and Goal
  • Design The invention and disposition of the
    forms, parts, or details of something according
    to a plan. (AH dictionary online)
  • Integrity The state of being unimpaired
    Soundness The quality or condition of being
    whole or undivided completeness (AH)
  • This seminar is intended to talk about techniques
    and issues that ensure the soundness and
    completeness of both the end product and the
    means used to produce it.

Design 1 Radarsat 1 ACP
Radarsat 1 ACP Overview
  • Program dates late 1990 late 1992
  • Specifications
  • Processor 8 MHz 80386/80387
  • Memory128 k x 8 SRAM, 192kx8 EEPROM, 16k x 8
  • Interfaces A/D (16), D/A (4-12), Synchronous
    serial (3 input, 3 output), RS-232 GSE
  • Function Attitude control processor for the
    RADARSAT1 satellite
  • Logic Implementation MSI logic PALs (16L8,
    16R6, 16R8)
  • Additional functions (cross-strap, control)

PAL Reminder
Design 2 - Command Telemetry Board (CTB)
CTB Overview
  • Program Dates early 2001 late 2003
  • Specifications
  • Processor RTX2010 (16 MHz)
  • Memory 4M x 8 (random), various FIFOs (16k x8)
    as necessary
  • Interfaces
  • MIL-STD-1553B
  • Synchronous Serial (command / telemetry)
  • Analog input
  • High-level discrete (output)
  • Low-level discrete (input / output)
  • Functionality S/C command/telemetry (level 0 and
  • Logic Implementation 4 54SX32S FPGAs
  • Additional resources (in same box) RAD 750, Mass
    Memory, Instrument Interface Card

Whats Changed?
  • Capability / Complexity
  • Logic Density
  • Specificity
  • RADARSAT (1 small specification with interface
  • CTB (1 large specification with interface, s/w,
    operations focus)
  • Software Centricity
  • Initial Errors
  • RADARSAT 3 jumpers 1 PAL design change
  • CTB 14 FPGA revisions
  • 2 spec change
  • 5-6 mistakes
  • 6-7 data dependency

Whats Not Changed?
  • Overall program schedules
  • Proportional budget
  • Expectation of correctness
  • Pain from mistakes

What Explains the (error) Difference?
  • Engineers arent as capable? Insulting!
  • Everything is just more complex? Copout!
  • Methodology?
  • Methodology hasnt changed
  • Always inadequate, we just got lucky
  • Adequate for old designs, no longer adequate
  • Methodology has changed
  • Used to be adequate, but we lost the recipe
  • Design philosophy of systems has changed?
  • Predicated on maximum flexibility
  • Expectation of extreme complexity
  • Over-specification almost impossible to meet

What Do These Examples Illustrate?
  • The incidence of initial correctness for designs
    seems to be decreasing
  • Design changes seem to be more common
  • Problems late in the verification/validation
    cycle seem to be more frequent
  • Perhaps a combination of the factors presented
    explains this, but
  • Desired complexity is not going to decrease
  • Budgets are not going to get bigger
  • The expectation of excellence isnt going to go
  • The only solution is to develop and improve a
    consistent methodology for implementing robustly
    designed products
  • Based on basic principles
  • Applicable to a variety of conditions

Why Should I Care?
  • Why do we work?
  • Self-actualization (fun, monetary reward,
  • Why do people want us to work for them?
  • They need what we produce
  • What do people want engineers (especially in
    Aerospace) to produce?
  • A quality product that satisfies the customers
  • How do they want us to produce such a product?
  • Consistently and efficiently

The Laymans View The Miracle Cloud
The Miracle Cloud Method
  • Note that too many engineering schools teach this
    approach without meaning to
  • Advantages to the miracle cloud method
  • Total creative freedom
  • Disadvantages to the miracle cloud method
  • Product quality is variable
  • Team makeup dependent
  • Team mood/morale dependent (Monday morning car)
  • Luck dependent
  • Product is not produced in a repeatable manner
  • Product is not produced in an efficient manner
  • Result
  • Quality low
  • Customer Satisfaction Low

How Do We Replace the Miracle Cloud?
  • Provide structure to the development effort
  • Evaluate the effort and the product produced
  • Improve the effort and the product
  • Repeat

Definitions of Importance
  • From Q9000-2000
  • Process A set of interrelated and interacting
    activities which transforms inputs to outputs in
    our case ideas to devices
  • Product The result of a process

Implications From These Definitions
  • If we want a consistent product, we must have a
    consistent process
  • If we want to improve a product, we must improve
    the process
  • If our company has no (or inadequate) process and
    we must produce a quality product, then we must
    establish a process personal responsibility
  • Developing, imposing, and improving a process is
    not an end (in and of itself) it is only a means
    to an end

A Model for Discussing the Design Process
Notes on the Model
  • Feedback / iteration are not shown for clarity
  • Model may be recursive
  • Board development process includes FPGA
    requirement definition, FPGA development,
    instantiation, etc.
  • Board verification process includes the FPGA
    validation product
  • Successes and failures are cumulative
  • Good requirements successful development gt
    successful instantiation
  • Bad requirements failed development gt failed
  • Complexity multiplies
  • Complex requirements increase design complexity
    which, in turn, increases verification complexity
  • Processes are absolute gates to the next stage of

Implications From the Model
  • All processes must be addressed at all levels of
    design there are no shortcuts!
  • Does not imply same formality at all levels
  • Does imply same rigor at all levels
  • Up front work on requirements is essential!
  • Must provide adequate time and money
  • Must gain team buy-in to the process
  • Benefits compound throughout the rest of the
  • Simplicity is an essential virtue!
  • Complexity inevitably multiplies
  • A product is not qualified until both
    verification and validation are complete

Additional Useful Definitions (courtesy of
  • Specification A document stating requirements,
    needs, or expectations that are obligatory
  • Quality The degree to which a set of inherent
    characteristics fulfill requirements
  • Customer satisfaction Customers perception of
    the degree to which the customers requirements
    have been fulfilled
  • Verification Confirmation, through the
    provision of objective evidence, that specified
    requirements have been fulfilled
  • Validation Confirmation, through the provision
    of objective evidence, that the requirements for
    a specific intended use or application have been
  • Objective evidence Data supporting the
    existence or verity of something
  • Continual Improvement recurring activity to
    increase the ability to fulfill requirements
  • Note the importance of Requirements

  • I have no assurance that my product will have
    consistent quality without
  • Well-defined requirements
  • A well planned approach to implementing the
  • A clearly defined plan for verification and
    validation of the requirements
  • The ability to improve the process that produces
    the product
  • Without quality product, customer satisfaction is
  • Without customer satisfaction, I wont work!
  • Therefore, I must care about ensuring design

What Does It Have to Do?
  • Specifying the design

Agenda Specifying the Design
  • Basic concepts and implications
  • What should we include in a specification?
  • What should we avoid in a specification?
  • The role of the design engineer
  • Summary
  • FPGA specifications

Basic Specification Concepts
  • 1 A specification has a limited set of purposes
  • It is intended
  • To capture product requirements that are
    essential to meeting a need functionally and
  • To ensure traceability of the requirements from
    higher levels
  • To provide a fixed framework for verifying
    product conformance
  • To provide a framework for derived requirements
  • It is not intended
  • To impose a detailed implementation for a design
  • To provide unnecessary theory of operation
  • To become a users manual
  • As a box to check on the schedule checklist

Basic Specification Concepts (cont.)
  • 2 Specification language must meet certain
  • Structure
  • Similar requirements must be grouped together
  • All requirements must stand on their own
  • Verbs must have a consistent specific meaning
  • Shall, must -gt impose imperatives
  • Should, might -gt define preferences
  • Will -gt defines objective information
  • Phraseology
  • Phrases must be unambiguous
  • Phrases must define one (and only one)
  • Phrases must be short and understandable
  • All must agree on the meaning of what is written

Basic Specification Concepts (cont.)
  • 3 Specifications are inherently intrusive
  • Requirements exclude options in a design
  • The number and specificity of requirements
    determine the level of exclusion
  • Specifications impose non-negotiable verification
  • Every requirement must be verified
  • The narrower the requirement, the more specific
    the verification
  • The more requirements, the more work needs to be
  • A well designed specification assists the design
    and verification process
  • A poorly designed specification
  • Unnecessarily shuts down trade space
  • Increases verification time and effort
  • Makes for an unhappy engineer

What is Included in a Specification?
  • Interfaces
  • Number
  • Type
  • Timing / Handshaking
  • Interrelationships
  • Temporary storage
  • Data Flow
  • Software Support (careful)
  • System impact
  • Quality and Reliability
  • Parts, materials, and processes

Examples of Things to Include
  • Interfaces
  • The unit shall provide 16 low-level discrete
  • The unit shall configure 8 low-level discrete
    interfaces as pulsed interface
  • Pulse interfaces shall generate pulses between 2
    and 20 ms long
  • Interrelationships
  • The unit shall provide on-board temporary storage
    sufficient for 2 packets from the XYZ interface
  • The unit shall forward data from the XYZ to QRS
    interfaces on a packet by packet basis
  • The unit shall provide an interrupt to the S/W
    upon receipt of a complete package from the XYZ
  • System Integration
  • The unit shall have a .75 probability of success
    as calculated per the parts count method of
  • The Unit shall use only EEE parts that meet the
    requirements of EEE-INST-002

What Should Not Be Included in the Specification?
  • Implementation details (unless essential to
    safety or reliability)
  • The unit shall implement standard pyrotechnic
    fire circuit 2 as found in (marginally
  • The unit shall use 4 7206 FIFOs made by IDT
  • 370 ns after the last bit of a packet is received
    the unit shall raise bit 3 of interrupt control
    register 21
  • Requirements based on inherent capability of
    devices used
  • The unit shall provide a 14-bit A/D converter for
    interface X (when based upon the part being used)
  • Note Decisions on precision or accuracy etc.
    should be made for interface characteristics
    (physical measurement range and accuracy)

What Shouldnt Be Included in the Specification
  • Ambiguous, unclear, or interpretive requirements
  • The unit shall be constructed using techniques
    found in generally accepted space hardware
  • The unit shall interface to other components per
    figure 2 (picture based requirements)
  • The unit shall provide the best performance
  • Overly complex requirements
  • The unit reset shall be immediately triggered
    upon expiration of the watchdog timer unless the
    watchdog timer has timed-out five times (8 times
    if in mode 2) in which case the circuitry shall
    look at discrete bit 2 to determine whether to
    delay 3 s (discrete bit 2 1) before timing out
  • Extraneous information
  • The unit shall interface with the visible CCD
    used in spectrographic mode
  • The unit shall replace the functionality provided
    by p/n 276401-01

Why Shouldnt These Be Included?
  • This type of requirement increases cost time,
    money, emotional to develop a product
  • Increase design effort (less trade space,
    inefficient design, overly complex design)
  • Increase verification effort planning,
    implementing, configuring due to design
  • Increase probability of re-design or re-build
    validation uncertainty
  • This type of requirement reduces the overall
    quality of the product developed
  • Implemented design not per intention interpreted
  • Implemented design is not 100 verifiable to
    specification unclear requirements
  • Implemented design requires significant number of
    waivers and deviations

The Role of the Design Engineer
  • The design engineering team must buy in to the
    specification development process
  • They have to deal with the consequences if it is
    done poorly
  • Lack of buy in produces a non-controlled
  • Buy in requires early review and participation
    by the design team
  • Therefore, design engineers have a significant
    role to play in the specification development
  • What is this role?

Role of the Design Engineer (cont.)
  • Know how to write a specification
  • Allows constructive review of the imposed
  • Improves qualities of derived requirements
  • Try to understand the why behind the various
  • Improves efficiency of design trade studies
  • Allows intelligent suggestion of alternatives
  • Suggest alternatives when necessary
  • Expose more efficient ways of producing
    equivalent functions
  • Support trade offs between software and hardware

Role of the Design Engineer (cont.)
  • Think forward
  • Take the lead in defining derived requirements
  • Ask
  • What implications does this have for the design?
  • What implications does this have for testability?
  • Will this let me sleep at night?
  • Push back
  • Seek clarification of ambiguous requirements
  • Inform others of impractical or costly driving
  • Ask for relief from impossible requirements
  • Remain engaged in the process
  • Be thorough in review
  • Dont be passive with suggestions

  • Specifications are critically important to the
    design engineer and must not be ignored
  • Design teams must be intimately involved in the
    specification development process
  • Detailed design and implementation will succeed
    or fail largely based on successful application
    of the specification process

FPGA Specifications - Rationale
  • FPGAs are a major part of modern day spaceflight
  • Primary control functionality
  • Equivalent of multiple boards of traditional
  • Major schedule driver
  • FPGAs are impossible to verify completely from
    external signals
  • Too many buried modes and functions
  • Too much dependence on simulation
  • Correcting FPGAs is conceptually simple
  • Temptation to sloppiness
  • First time right is an essential virtue
  • The FPGA specification is a means to achieve
    first time right

FPGA Specification Prototype
  • Interface Section
  • Specific pinout requirements
  • I/O type definition (Names, Direction, Logic
  • Imposed Software requirements (addressing, etc.)
  • Do not include non-imposed addressing / register
    mapping / software interfaces
  • Functionality Section
  • Interface interaction requirements
  • Data flow requirements
  • Exclusion requirements
  • Do not include
  • Implementation details
  • Theory of operations
  • Usage instructions

FPGA Specification Prototype (cont.)
  • Fine timing section
  • All timing imposed by board peripheral circuits
  • Include
  • Min and max delay between I/Os
  • Set-up and hold for controlled peripherals
  • Fine timing requirements should be an input to
    the FPGA development effort, not outputs of the
    concluded design

Why Include Fine Timing?
  • Reduces influence of changes external to FPGA
  • Board implementation can change significantly
  • FPGA implementation can change significantly
  • Changes ok as long as interfaces remain stable -
    but fine timing must be a controlled item
  • Simplifies verification
  • Verification between implemented FPGA performance
    and fixed requirements defined at the board level
    can be easily accomplished
  • Reduces reliance on complex back-annotated
    simulations at the board level for FPGA specific
  • Increases reliability of static timing analysis
  • Note this only works if a structured design
    approach is used such that valid requirements can
    be imposed on the FPGA early in the process.

Stand-Alone or Integral?
  • When should an FPGA specification stand alone?
  • When the FPGA design engineer is not the board
    design engineer
  • When there are multiple interrelated FPGAs on a
  • When the FPGA design will be used in multiple
    board applications
  • When the FPGA will become an ASIC
  • When the development schedule between the board
    and FPGA are disjoint
  • When the complexity of the FPGA is greater than
    that of the board support circuitry

Stand Alone or Integral (cont.)?
  • When should an FPGA be specified as part of the
    board specification?
  • When the FPGA is so intertwined with the
    peripheral circuitry that writing a stand-alone
    specification is not practical
  • When the FPGA functionality is easily expressed
    by simple gate level schematics
  • When the FPGA and board are designed by the same
  • When heritage design with adequate specifications

Letting Constraints Work For You
  • Proportional Design

Agenda Proportional Design
  • Conceptual background
  • Types of constraints
  • Examples
  • The proportional design mindset
  • Summary

Conceptual Background
  • Three parts to solving a problem
  • Need, solution set, constraints
  • All parts have a role to play in the solution
  • Ignoring any of them will lead to problems

Conceptual Background (cont.)
  • Example
  • Need means of conveyance to work
  • Solution set Skateboard, bicycle, bus, jogging
    shoes, mid-size sedan, luxury car, helicopter
  • Constraints Distance (6 miles), , not on bus
    route, , not in very good shape,
  • Solution 1992 Honda Accord (120 kmiles, 4 k)
  • The constraints guide selection of the solution
    from the solution set
  • The particular solution is not necessarily -
  • The cheapest (roller skates)
  • The most desired (Lexus LS400)
  • What is perceived as best for society (bus)
  • But the best overall fit to the needs

Conceptual Background (cont.)
  • Definitions
  • Constraint the state of being checked,
    restricted, or compelled to avoid or perform some
    action (AH)
  • Proportional corresponding in some degree or
    intensity (AH)
  • Proportional design is design that results in a
    product sized appropriately to the needs and
    restrictions of the specification
  • The concept of proportional design
  • Accepts the reality of constraints
  • Attempts to optimize the solution given the
  • Accepts that the constraints provide benefits
    (more later)
  • More efficient designs
  • More thorough designs
  • More correct designs
  • Caveat All other things being equal

Types of Constraints
  • External (mass, power, cost, quality)
  • Internal
  • Derived (packaging, architecture, component
    availability, maximum clock speed)
  • Self-imposed
  • Design rules/guidelines (free space, clock use,
    logic structure, HDL language)
  • Documentation style (pre-design, post design)
  • Component acceptability (maturity of part,
    limited use of various features

Examples (1)
  • Problem provide decoding logic for memory map
  • 0-3FFF SRAM 4000-4FFF Peripheral E000-FFFF
  • Constraint use minimum amount of logic
  • But what about
  • Unused addresses, future expansion, etc.
  • Doesnt matter given the constraints

Examples (2)
  • Problem provide all combinational / sequential
    logic for the RADARSAT ACP
  • Constraint Only low density high speed logic
    available (16X8 PALs, MSI/SSI logic)
  • What was forced by the constraint?
  • Careful mapping of peripherals into available
    address space
  • Careful partitioning between
  • Programmable logic and MSI/SSI
  • MSI/SSI functionality
  • Efficient data bus partitioning (tri-state enable
  • Special attention to component delays at the gate

The Proportional Design Mindset
  • Constraints inevitably foster attention to detail
    (creativity inside the box)
  • With respect to methodology
  • With respect to level of planning
  • With respect to implementation
  • Attention to detail is of inherent value because
    it produces carefully structured, well-thought
    out designs
  • Improved up-front correctness
  • Decreased design post-processing time
    (simulation, verification, validation, lab time)
  • Efficient designs that meet the stated
  • Increased reliability
  • Therefore, constraints are welcomed, whether
    externally imposed or self-imposed

The Proportional Design Mindset (cont.)
  • Examples of self-imposed constraint
  • Ignoring achievable flexibility (when not
  • Removing non-specified capability
  • Avoiding gratuitous cleverness (especially with
    abstract design techniques)
  • Rejecting brute force solutions without analysis

The Proportional Design Mindset (cont.)
  • Characteristics of the right mind set
  • Planning before starting
  • Reviewing before finalizing
  • Simplifying ruthlessly
  • Making the design do only what it must
  • Viewing resources as precious commodities to be
    used only to the extent needed
  • Understanding the implication of the designs
    level of abstraction
  • Being satisfied with the result

The Proportional Design Mindset (cont.)
  • Why arent self-imposed constraints more common?
  • They arent absolutely essential because we have
  • Lots of logic space FPGAs, ASICs
  • Lots of memory space DOS file systems,
    complicated operating systems
  • Lots of bandwidth fast data busses, general
    purpose communications protocols
  • They dont match the current paradigm
  • Flexibility is all-important re-use,
    re-configure, adapt
  • Specifications are malleable late in the game
  • Software changes, why cant hardware?
  • We can catch problems in simulation and reprogram
    the part
  • They arent fun
  • We dont train people to value constraints and
    work within them
  • This is unfortunate because constraints can make
    our job easier without degrading the end product

  • The proportional design mindset is important
    because it
  • Focuses on fulfilling needs, not wants
    specification orientation
  • Deepens understanding of the final design
    ownership oriented
  • Avoids unnecessary effort efficiency oriented
  • Fosters simplicity that aids verification and
    validation quality oriented

More Than the Sum of Its Parts
  • Design Partitioning

Agenda Design Partitioning
  • Definitions and examples
  • Why partition an electronic design?
  • Guidelines for partitioning an electronic design
  • Why isnt it done more often?
  • Summary

Definitions and Examples
  • Partition to divide into parts or shares
  • Examples budgeting, outlining, WBS development
  • Design partitioning refers to the deconstruction
    of a design into various sub-designs in an
    ordered and logical manner
  • Goal to simplify the whole by optimizing the
    parts and thus increase
  • Efficiency
  • Reliability
  • Maintainability

Why Partition (General)?
  • Complexity interferes with ready comprehension
  • Comprehension of a complex system depends on
    ability to impose order upon it
  • But a given mind has a finite capability to
    impose order which depends on the quantity and
    structure of the data related to the system
  • The more complex the system, the more difficult
    its comprehension
  • Partitioning a design introduces a piece-wise
    reduction in complexity
  • Reduces quantity and complexity of design to
    manageable chunks
  • Improves comprehension of the various parts of
    the design
  • Increased comprehension of the parts leads to
    better comprehension of the whole
  • Better comprehension of the whole increases the
    ability to
  • Verify correctness of the design
  • Correct errors in the design
  • Update the design when necessary

Why Partition (cont.)?
  • Programmatic advantages
  • Refines scope of work
  • Identifies unexpected effort
  • Identifies reuse possibilities
  • Identifies staffing requirements
  • Identifies schedule dependencies
  • Improves allocation of resources
  • Identifies parallelization and schedule
    enhancement opportunities
  • Promotes management visibility

Why Partition? - Design
  • Improved interface organization / more formal
  • Interfaces between functions have more
    predictable characteristics
  • Expansion by addition of functions is more
  • Enhanced functional encapsulation
  • Individual functions have predictable results
    when invoked
  • Functional design enhancements have limited
    side-effects when installed
  • Effects of faults are more easily predicted and
  • Efficient design implementation
  • Functional (fewer functions and types of
  • Data flow (fewer, more sensible data busses)
  • Control flow (simpler address decoding and state
  • All are side effects of additional thought put
    into How?

Why Partition? - Correctness
  • Simpler inspection
  • Functionality may be obvious at a glance
  • Error space is more limited
  • Within the function or within the interconnect
  • Simpler Qualification
  • Verification can begin with encapsulated modules
    or circuit subsets
  • Overall functionality correctness becomes less of
    a late concern because subset functionality is
    proven correct early in the process
  • Simpler / more thorough review
  • Structure provides orientation to peer reviewers
  • Encapsulation allows easier review
  • Peer input more likely to be useful

Why Partition? Maintainability
  • Clearer documentation
  • Documentation has smaller parts to focus on
  • Structure of documentation grows from the design
  • Simpler maintenance
  • Changes affect only enhanced area
  • Interactions between changed area of design and
    remainder of original design is controlled by a
    formal structure
  • Enhanced reuse
  • Sub-circuits / functions usable in other
    applications as long as the interface structure
    is observed
  • Inherent capability of design better understood

Guidelines for Partitioning
  • Take advantage of organizational strengths
  • Expertise (analog, digital, software, etc.) is
    seldom the same across organizations
  • Partition the design in accordance with
    organizational strengths according to primary
  • Divide auxiliary functions (those that can be
    assigned to multiple organizations) so that
  • Interfaces are simplified
  • Workload is equalized
  • Functions are easily tested without requiring all
    of the hardware

Guidelines for Partitioning (cont.)
  • Example Alice UV spectrograph electronics
  • Core expertise
  • Sensor Sciences Detector and front end
  • Mobius Systems Embedded software
  • SwRI space systems Digital, low speed data
  • SwRI space science LV and HV power supplies
  • Primary partition per core expertise

Guidelines for Partitioning (cont.)
  • Alice example (work breakdown chosen)
  • Sensor Sciences detector electronics through
    parallel digital output simplified interface
  • Mobius instrument control / protocol servicing
    (some error decoding partitioned to H/W)
  • Space systems microcontroller s/c interface
    heater, motor, door digital control analog
    high-voltage control
  • Space sciences LVPS HVPS motor, door, and
    heater drive circuitry

Guidelines for Partitioning (cont.)
  • Alice example partitioning decisions
  • Auxiliary expertise split along sensible
  • CDH to detector analog or digital? (noise,
    ease of test) - digital
  • CDH to HVPS analog or digital? (space, noise
    susceptibility, ease of test) - analog
  • CDH to S/W protocol decoding? (performance
    margin, logic capability) hardware error
    decoding, s/w protocol encoding

Guidelines for Partitioning (cont.)
  • Use specific functionalities
  • Combine functionality with very similar
  • Low-level analog / discrete bi-level (comparator
    is difference)
  • Example Spacelab flex interfaces
  • Cluster related functionalities
  • Shared data-flow direction, shared logical
  • Examples
  • Constant level discretes / pulsed discretes
  • Low-level discretes / high-level discretes

Guidelines for Partitioning (cont.)
  • Use specific functionalities (cont.)
  • Isolate related functional sub-groups from other
  • Ex. analog data acquisition group
    (multiplexers, converters, signal processing,
    control logic)
  • Isolate
  • Through appropriate data/address buffering
  • Through separate programmable logic sub-sets
  • Exploit directionality
  • Write functions read functions read/write
    functions appropriate buffering
  • Examples
  • Write Analog output, digital output, telemetry
  • Read Analog input, digital input, command
  • R/W Memory, bi-directional discretes, GSE

Guidelines for Partitioning (cont.)
  • Exploit operational considerations
  • Operational considerations often determine the
    specific configuration of a set of common
  • Example memory system
  • Components memory, write control, read control,
    sequencing, buffering
  • Application telemetry system
  • Packetized / unpacketized?
  • Asynchronous timing / TDM ?
  • Science data / engineering data?
  • Pushed / pulled ?
  • The type of telemetry system determines the

Example Science Data Storage and Readback System
  • How should the logic be partitioned?
  • Is write logic part of science data process or
    memory process?
  • Is read logic part of telemetry system or memory
  • How complicated is the arbitration?
  • How it is partitioned depends on specific
    operational requirements

Example - New Horizons Alice Science Data
  • Alice Operation
  • Slow source accumulation relative to output speed
  • Push interface initiated by instrument
  • Alice Implementation (others likely in different
  • Block 1 handshake and latch data
  • Block 2 Ingest data, process, write to memory
  • Block 3 Read, serialize, send, blank memory
  • Arbitration simplified to a switched double
    buffered memory access (no real-time arbitration)

Guidelines for Partitioning (cont.)
  • Ensure encapsulation is reflected in the form of
    the engineering documents
  • Functions contain many types of operations
  • Example Telecommand interface
  • De-serialization, decoding, error determination,
    re-packetization, temporary storage
  • Real time functionality level 0, forwarding to
  • Storage access / arbitration, status log
    maintenance, data-bus handshaking
  • Partitioning should ensure that all reasonable
    aspects of a function are in one locality (we are
    ordering data for understanding)
  • One (or a few) pages in a schematic
  • One module in HDL
  • One object in software
  • Benefits readability, error determination,
    testability, maintainability

Ordering Example Bus Structure
  • A logical bus structure
  • Simplifies data flow
  • Eases expansion / enhancement
  • Identifies bottlenecks / opportunities for
  • Ensures signal compatibility
  • Reduces timing uncertainty (capacitive loading)
  • Reduces power
  • Simplifies control logic / arbitration
  • Simplifies analysis

Ordering Ex. Bus Structure (cont.)
Ordering Ex. Bus Structure (cont.)
  • Directional data flow is clustered
  • High-speed access devices (SRAM) not buffered
  • Exclusive functions clustered (PROM/ EEPROM)
  • Simplification of
  • Timing
  • Loading
  • Control

Why is Partitioning Not a Priority?
  • It is at the S/C, sub-system, and box level
  • Why not at the board level?
  • Requires potentially significant planning effort
    (schedule / cost)
  • The tool syndrome (CAD / CAE)
  • Crush creativity by forcing an early start to
  • Primarily a way to communicate between software
    packages rather than humans (schematic gt PWB)
  • Too much junk being placed in too little space
    (simplification may not always be space
  • Lack of emphasis from senior engineers
  • Boards arent where the action is (FPGAs) less
    effort placed on them

Why is Partitioning Not a Priority? (cont.)
  • At the FPGA level
  • Lack of solid design methodology
  • Methodology must be tailored to a tool
  • VHDL / Verilog are functional descriptions
  • VHDL / Verilog dont inherently enable data flow
    visualization or block oriented deconstruction
  • The synthesizer can understand non-partitioned
  • Perception of expansive resources (no / few
  • The tool syndrome (I must start coding)
  • Lack of effective design quality gates prior to
    start of detailed design

  • A design is only as solid as its weakest part
  • Proper planning and partitioning of a design
  • Ensures individual functions are logical and
  • Ensures interconnects are ordered and efficient
  • Provides for improved reliability / verifiability
  • Allows easier modification and enhancement
  • Enhances detailed understanding of how things
  • Partitioning requires ordering the design by
  • The capabilities of the team
  • The functionality of the modular pieces
  • How the design will operate
  • The individual components of a particular
  • Partitioning a design ensures that all parts are
    solid resulting in a solid whole

You Mean Were Still Working On It?
  • Sustaining a Design

Agenda Design Sustainability
  • Definitions
  • Sustainable Capable of being supported (AH)
  • Sustainability The characteristic of an item
    that allows it to be supported
  • Why is this important?
  • Suggestions for sustainability
  • Summary

Why Sustainability?
  • Missions may be multiple decades long
  • Flight systems may develop anomalous behavior
  • Ground equivalents may need repair
  • An understanding of the design is necessary to
    ensure mission success
  • Original designers will not be available for
  • Other critical assignments
  • Working in telecon
  • Cruising the Pacific
  • Sustainable designs allow analysis and correction
    without the access to the original designers

Why Sustainability? (cont.)
  • Many designs are derivative
  • Reuse of unmodified circuits essential for
    similar performance in modified designs
  • Acceptable modification depends on creative
    incorporation of what IS
  • Derivation may take many years
  • Example Alice UVS
  • Design 1 Rosetta (1997-2001)
  • Design 2 New Horizons (2002-2005)
  • Design 3 LRO (2005-2008)
  • Design 4 Juno (2006 - ???)
  • Staffing will not be constant
  • Human memory will not be precise
  • Sustainability ensures an ability to efficiently
    build on past successes

Why Sustainability (cont.)
  • You may not be the person who has to make it work
  • Staffing is dynamic
  • You may quit
  • You may get re-assigned
  • Somebody with more clout may be needed to satisfy
    the customer
  • Teams produce a product and share debugging
  • Test technician
  • S/W designer
  • IT team
  • Self-interest and common courtesy
  • You dont want 18 questions per day
  • Ethics Do unto others
  • Example (ICB)

Suggestions for Sustainability
  • Remember the dual nature of design input
  • The CAD perspective
  • Schematic gt PCB layout package gt circuit board
  • HDL gt Synthesizer gt Fuse file gt Programmed
  • The human perspective
  • Schematic
  • Interrelationships (time, space, connection)
  • Debugging tool
  • Functionality description
  • HDL
  • Describes functions and interaction
  • Renders constraints understandable
  • Ensure Readability!

Suggestions for Sustainability (cont.)
  • Record the design process
  • Keep a notebook (type not vital)
  • Describe everything of importance
  • Why?
  • Is this bus used for this function?
  • Is this function implemented like this?
  • Etc.
  • How?
  • Do these things talk to one another?
  • Does this sequential logic work (state diagrams)?
  • Is the address map decoded?
  • Are errors handled?
  • Etc.

Suggestions for Sustainability (cont.)
  • Record the Design Process (cont.)
  • Describe (cont.)
  • What?
  • Signals are needed to perform this function?
  • Do the waveforms look like?
  • Timing do I expect to observe?
  • Changes have I made?
  • Etc.
  • When? Record chronology
  • Provide a way to reproduce what was done
  • Make part of permanent project record
  • Example Radarsat 1 Notebook

Suggestions for Sustainability (cont.)
  • Schematics
  • Provide an overview of the design
  • Schematic table of contents
  • Block diagram (hierarchical design if available)
  • Provide consistent naming scheme
  • Descriptive of signal direction / function /
  • Consistent across logic gates and within various
  • Cluster sub-circuits on contiguous pages
  • Make connections between components explicit
  • Add comments where necessary for clarification
  • Remove unused circuitry (for FPGA schematics)

Suggestions for Sustainability (cont.)
  • Dont

Suggestions for Sustainability (cont.)
  • Do

Suggestions for Sustainability (cont.)
  • Help!

Suggestions for Sustainability (cont.)
  • HDL (Must be done from beginning!)
  • Provide overall orientation to design
  • Provide top-level comments on
  • Level of use (top, intermediate, etc.)
  • Overall purpose of function / block / module
  • Signal function and origination (external and
  • Provide operational comments on
  • State machine purpose and configuration (how?
  • Transition logic (theory and reasoning)
  • Function of particular sequences
  • State to control signal translation
  • Clarify obscure references
  • Remove superseded code (dont comment out) and
    explain uncommon structures
  • Improve readability
  • Create logical file names
  • Minimize file, logic block, function sizes
  • Include related functions together (error
    generation, data interface, basic function, etc.

Suggestions for Sustainability (cont.)
Suggestions for Sustainability (cont.)
Header from same design! (After the fact
Suggestions for Sustainability (cont.)
  • Post process documentation
  • Theory of Operation / Users Manual
  • Generate One
  • Include
  • Design concept / features
  • Operational Constraints
  • Appropriate Uses
  • Complete Engineering Documentation
  • Update, release and correct as necessary
  • Create design archive
  • Self-consistent and complete
  • Place under revision control
  • Control changes

  • Useful designs will be corrected, modified and
  • By people besides you
  • Sustainability measures must be implemented to
    make this happen efficiently
  • Sustainability requires
  • Adequate conceptual documentation and records
  • Clear and readable implementation records
  • Finalized and controlled configuration records
  • Ensuring sustainability will preserve your legacy

Whats the Exit Strategy?
  • Verifying a Design

Agenda Design Verification
  • Concepts and implications
  • The specification connection
  • Verification before test
  • Test thoroughness
  • Tiered verification
  • Concluding the process
  • Summary

Verification Concepts
  • Verification Confirmation, through the
    provision of objective evidence, that the
    specified requirements have been fulfilled
  • Confirmation the act of ratifying or
    corroborating (AH)

Verification Implications
  • The verification process is not intended to be a
    craps shoot
  • Verification is primarily intended to highlight
  • Verification is NOT primarily intended to reveal
  • The mindset is important!
  • Doubt that a design will work expresses a lack of
    confidence in the designer and the design process
  • Waiting until verification to guarantee
    correctness is an excuse for being sloppy
  • We should expect our designs to work!
    Verification simply puts the seal of confirmation
    on the expectation

Verification Implications (cont.)
  • Verification addresses two processes
  • Design
  • Primarily a one-time, iterative process in which
    the developed concept is proven sound
  • Fundamental correctness can be proven
  • Inspection confirms logical correctness in all
  • Peer reviews are a manual form of inspection
  • Functional simulation is an automated form of
  • Inspections must be tailored to design
  • Analysis verifies correctness in the presence of
  • Reliability (WC, Derating, FMEA, etc.)
  • Timing over environments and age

Verification Implications (cont.)
  • Verification addresses two processes (cont.)
  • Instantiation
  • Particular instance must be sound
  • Particular correctness must be demonstrated
  • Inspection confirms that instructions are
  • Correct components installed
  • Correct configuration selected
  • Correct processes performed
  • Test and demonstration confirms that operation
    matches expectations
  • Functionally and parametrically
  • Predicted by nominal analytical predictions

Verification Implications (cont.)
  • Verification after the fact is too late
  • Analysis and test are NOT equivalent
  • Design analysis and inspection must proceed in
    lockstep with design processes
  • Implementation tests and inspections should
    simply confirm what is known
  • Design efforts fail because they occur in a
  • Creativity takes primacy over correctness
  • Functionality comes first with operability being
    shoehorned after the fact
  • The monster simulation syndrome
  • Conclusion Verify as you proceed

Verification Implications (cont.)
  • Correctness is a matter of personal integrity for
    the designer
  • Verification is not simply externally imposed
  • Verification is something that the designer must
    want to do (a part of his/her ethos)
  • Verification is confirmation that the designer is
    worth his/her salt

The Specification Connection
  • Requirements are confirmed during verification
  • The designer does not have a free hand with
    respect to how a design is confirmed
  • Specification provides the constraint set under
    which verification is prosecuted
  • Therefore, verification must be defined prior to
    start of design
  • Not simply in a general manner
  • Specifically
  • Since specification is a customer and vendor
  • Both customer and vendor must be involved in the
    verification process
  • Trust me is not a reasonable phrase when it
    comes to verification

The Specification Connection (cont.)
  • Specification contains a complete ideally set
    of requirements for the design
  • Some requirements are very specific
  • All discrete outputs shall have a source
    impedance of 2 kOhms.
  • An adequate test is fairly obvious
  • Some requirements are not very specific
  • The unit shall provide 512 kbytes of SRAM
  • Note the implied requirement The SRAM shall
    function correctly
  • What is an adequate functional test for this
    requirement? (walking 1s, 0s addressing, etc?)
  • Some requirements lend themselves to quantitative
    analysis The unit shall provide a .1 C
    accuracy at end of life
  • Some requirements lend themselves to simple
    inspection The unit s