Design Integrity Concepts - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Design Integrity Concepts

Description:

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: http://www.klabs.org
Category:

less

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

Title: Design Integrity Concepts


1
Design Integrity Concepts
2
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

3
Who is this guy?
  • John Stone
  • Chief Engineer (Department of Space Systems
    SwRI)
  • 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

4
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

5
Consistent Terminology, Consistent Results
  • Introduction and Definitions

6
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

7
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.

8
Design 1 Radarsat 1 ACP
9
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
    PROM
  • 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)
    external

10
PAL Reminder
11
Design 2 - Command Telemetry Board (CTB)
12
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
    active)
  • Logic Implementation 4 54SX32S FPGAs
  • Additional resources (in same box) RAD 750, Mass
    Memory, Instrument Interface Card

13
Whats Changed?
  • Capability / Complexity
  • Logic Density
  • Specificity
  • RADARSAT (1 small specification with interface
    focus)
  • 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

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

15
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

16
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
    away
  • 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

17
Why Should I Care?
  • Why do we work?
  • Self-actualization (fun, monetary reward,
    interest)
  • 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
    needs
  • How do they want us to produce such a product?
  • Consistently and efficiently

18
The Laymans View The Miracle Cloud
19
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

20
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

21
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

22
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

23
A Model for Discussing the Design Process
24
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
    instantiation
  • Complexity multiplies
  • Complex requirements increase design complexity
    which, in turn, increases verification complexity
  • Processes are absolute gates to the next stage of
    development

25
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
    activities
  • Simplicity is an essential virtue!
  • Complexity inevitably multiplies
  • A product is not qualified until both
    verification and validation are complete

26
Additional Useful Definitions (courtesy of
Q9000-2000)
  • 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
    fulfilled
  • 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

27
Summary
  • I have no assurance that my product will have
    consistent quality without
  • Well-defined requirements
  • A well planned approach to implementing the
    requirements
  • 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
    impossible
  • Without customer satisfaction, I wont work!
  • Therefore, I must care about ensuring design
    integrity

28
What Does It Have to Do?
  • Specifying the design

29
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

30
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
    interfacially
  • 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
    statements
  • To become a users manual
  • As a box to check on the schedule checklist

31
Basic Specification Concepts (cont.)
  • 2 Specification language must meet certain
    criteria
  • 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)
    requirement
  • Phrases must be short and understandable
  • All must agree on the meaning of what is written

32
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
    requirements
  • Every requirement must be verified
  • The narrower the requirement, the more specific
    the verification
  • The more requirements, the more work needs to be
    performed
  • 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

33
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

34
Examples of Things to Include
  • Interfaces
  • The unit shall provide 16 low-level discrete
    interfaces
  • 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
    interface
  • System Integration
  • The unit shall have a .75 probability of success
    as calculated per the parts count method of
    MIL-HDBK-217
  • The Unit shall use only EEE parts that meet the
    requirements of EEE-INST-002

35
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
    acceptable)
  • The unit shall use 4 7206 FIFOs made by IDT
    corporation
  • 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)

36
What Shouldnt Be Included in the Specification
(cont)?
  • Ambiguous, unclear, or interpretive requirements
  • The unit shall be constructed using techniques
    found in generally accepted space hardware
    guidelines
  • The unit shall interface to other components per
    figure 2 (picture based requirements)
  • The unit shall provide the best performance
    possible
  • 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

37
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
    complexity
  • 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
    requirements
  • Implemented design is not 100 verifiable to
    specification unclear requirements
  • Implemented design requires significant number of
    waivers and deviations

38
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
    process
  • Buy in requires early review and participation
    by the design team
  • Therefore, design engineers have a significant
    role to play in the specification development
    process
  • What is this role?

39
Role of the Design Engineer (cont.)
  • Know how to write a specification
  • Allows constructive review of the imposed
    specification
  • Improves qualities of derived requirements
  • Try to understand the why behind the various
    requirements
  • 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
    functionality

40
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
    requirements
  • Ask for relief from impossible requirements
  • Remain engaged in the process
  • Be thorough in review
  • Dont be passive with suggestions

41
Summary
  • 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

42
FPGA Specifications - Rationale
  • FPGAs are a major part of modern day spaceflight
    designs
  • Primary control functionality
  • Equivalent of multiple boards of traditional
    circuitry
  • 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

43
FPGA Specification Prototype
  • Interface Section
  • Specific pinout requirements
  • I/O type definition (Names, Direction, Logic
    levels)
  • 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

44
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

45
Why Include Fine Timing?
  • Reduces influence of changes external to FPGA
    (encapsulation)
  • 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
    verification
  • 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.

46
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
    board
  • 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

47
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
    person
  • When heritage design with adequate specifications
    exist

48
Letting Constraints Work For You
  • Proportional Design

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

50
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

51
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

52
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
    constraints
  • Accepts that the constraints provide benefits
    (more later)
  • More efficient designs
  • More thorough designs
  • More correct designs
  • Caveat All other things being equal

53
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

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

55
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
    issues)
  • Special attention to component delays at the gate
    level

56
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
    requirements
  • Increased reliability
  • Therefore, constraints are welcomed, whether
    externally imposed or self-imposed

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

58
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

59
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

60
Summary
  • 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

61
More Than the Sum of Its Parts
  • Design Partitioning

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

63
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

64
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

65
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

66
Why Partition? - Design
  • Improved interface organization / more formal
    structure
  • Interfaces between functions have more
    predictable characteristics
  • Expansion by addition of functions is more
    controlled
  • 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
    mitigated
  • Efficient design implementation
  • Functional (fewer functions and types of
    functions)
  • Data flow (fewer, more sensible data busses)
  • Control flow (simpler address decoding and state
    machines)
  • All are side effects of additional thought put
    into How?

67
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

68
Why Partition? Maintainability
  • Clearer documentation
  • Documentation has smaller parts to focus on
  • Structure of documentation grows from the design
    structure
  • 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

69
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
    functions
  • 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

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

71
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

72
Guidelines for Partitioning (cont.)
  • Alice example partitioning decisions
  • Auxiliary expertise split along sensible
    interfaces
  • 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

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

74
Guidelines for Partitioning (cont.)
  • Use specific functionalities (cont.)
  • Isolate related functional sub-groups from other
    items
  • 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

75
Guidelines for Partitioning (cont.)
  • Exploit operational considerations
  • Operational considerations often determine the
    specific configuration of a set of common
    components
  • 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
    partitioning

76
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
    process?
  • How complicated is the arbitration?
  • How it is partitioned depends on specific
    operational requirements

77
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
    circumstances)
  • 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)

78
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
    software
  • 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

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

80
Ordering Ex. Bus Structure (cont.)
Before
After
81
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

82
Why is Partitioning Not a Priority?
  • It is at the S/C, sub-system, and box level
    (sometimes)
  • 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
    design
  • 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
    efficient)
  • Lack of emphasis from senior engineers
  • Boards arent where the action is (FPGAs) less
    effort placed on them

83
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
    design
  • Perception of expansive resources (no / few
    constraints)
  • The tool syndrome (I must start coding)
  • Lack of effective design quality gates prior to
    start of detailed design

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

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

86
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

87
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
    debugging
  • Other critical assignments
  • Working in telecon
  • Cruising the Pacific
  • Sustainable designs allow analysis and correction
    without the access to the original designers

88
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

89
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)

90
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
    FPGA
  • The human perspective
  • Schematic
  • Interrelationships (time, space, connection)
  • Debugging tool
  • Functionality description
  • HDL
  • Describes functions and interaction
  • Renders constraints understandable
  • Ensure Readability!

91
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.

92
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

93
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 /
    polarity
  • Consistent across logic gates and within various
    blocks
  • Cluster sub-circuits on contiguous pages
  • Make connections between components explicit
  • Add comments where necessary for clarification
  • Remove unused circuitry (for FPGA schematics)

94
Suggestions for Sustainability (cont.)
  • Dont

95
Suggestions for Sustainability (cont.)
  • Do

96
Suggestions for Sustainability (cont.)
  • Help!

97
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
    internal)
  • Provide operational comments on
  • State machine purpose and configuration (how?
    why?)
  • 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.

98
Suggestions for Sustainability (cont.)
Comments?
99
Suggestions for Sustainability (cont.)
Header from same design! (After the fact
documentation)
100
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

101
Summary
  • Useful designs will be corrected, modified and
    evaluated
  • FOR A LONG TIME!
  • 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

102
Whats the Exit Strategy?
  • Verifying a Design

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

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

105
Verification Implications
  • The verification process is not intended to be a
    craps shoot
  • Verification is primarily intended to highlight
    correctness
  • Verification is NOT primarily intended to reveal
    incorrectness
  • 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

106
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
    analytically
  • Inspection confirms logical correctness in all
    circumstances
  • Peer reviews are a manual form of inspection
  • Functional simulation is an automated form of
    inspection
  • Inspections must be tailored to design
  • Analysis verifies correctness in the presence of
    variability
  • Reliability (WC, Derating, FMEA, etc.)
  • Timing over environments and age

107
Verification Implications (cont.)
  • Verification addresses two processes (cont.)
  • Instantiation
  • Particular instance must be sound
  • Particular correctness must be demonstrated
    experimentally
  • Inspection confirms that instructions are
    followed
  • 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

108
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
    vacuum
  • Creativity takes primacy over correctness
  • Functionality comes first with operability being
    shoehorned after the fact
  • The monster simulation syndrome
  • Conclusion Verify as you proceed

109
Verification Implications (cont.)
  • Correctness is a matter of personal integrity for
    the designer
  • Verification is not simply externally imposed
    task
  • 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

110
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
    document
  • Both customer and vendor must be involved in the
    verification process
  • Trust me is not a reasonable phrase when it
    comes to verification

111
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
About PowerShow.com