PDMFS! –

Product Development

Methodologies for Success!©2019

Talk by Jerry Bellott, MSEE

PCJS SPS Chapter Chairjbellott.ieee@outlook.com

www.gtdigital.org

Sponsored by:

IEEE Princeton/Central NJ Signal Processing Society ChapterOctober 15, 2019

Product Development

Methodologies for Success! –Talk Outline:

1. How Product Development Methodologies Enable Success

2. Product Development Steps and Methodology Milestones

3. Digital Signal Processor Based Product Development

4. Methodology Document Example Contents

5. Ensuring Quality Of The Development Process

UNIT 1

HOW PRODUCT DEVELOPMENT

METHODOLOGIES ENABLE

SUCCESS

Why Customers Buy Products

• A basic thesis: Company income occurs only if customers want to buy their products, and customers only want to buy products if they meet their needs and expectations.

Examples of Customer Needs and

Expectations

Features

Price

Availability Dates

Reliability

Maintainability and Support

Corporate Competition

Companies compete by:

•Using methods and practices designed to deliberately produce products that meet customer needs and expectations.

• Continuously improving their methods and

practices.

Company Needs and Expectations of

their Employees

1. Earn company income and profit to

▪ recoup product development, manufacturing and marketing costs,

▪ pay salaries,

▪ appreciate the value of company stock, and

▪ invest in the future.

2. Meet customer needs and expectations so that sales will occur at appropriate levels.

Product Development Methodologies

• Help engineers succeed by serving both customers and their company well.

• They Are Roadmaps to Success

• They Are Repeatable

• They Can be Improved

UNIT 2

PRODUCT DEVELOPMENT

STEPS AND METHODOLOGY

MILESTONES

Organization of a Typical Company

• Corporate Management

• Accounting

• Business Planning

• Marketing

• Engineering and Project Management Teams

• Manufacturing

• Quality Assurance

• Sales and Customer Support

• HR

Roles of Marketing Department in

Product Development

• Ideas for market innovation

• Identifying customer needs.

• Customer identification. Demographics.

• Engaging customers to discuss possible product development and preliminary plans.

• Market forecasting

• Product pricing

Traditional role related to sales advertising:

• Advertising plans for reaching targeted customers

Role of Business Planners in

Product Development

Business Case documents are for executive managers.

Business Cases cover:

• Description of product

• Plans for development of product (cost, schedule, resources).

• Assessment of riskreturns

• Evaluation of length of time until cost of product development is recouped, and profits begin.

• Analysis of anticipated profits. Timeframe when profits will occur.

• Financial assessment of capital depreciation and salvage of items used to produce product at end of manufacturing.

Typical Set of Product Development

Methodology Steps• Identify:

▫ Marketing Product Requirements

▫ Engineering System Requirements

▫ Hardware, Software, and FPGA/ASIC HDL Specifications

• Design:

▫ Hardware Schematics, Signal Processing Algorithms (standards based or custom), Software Code, FPGA Code, and Design Simulation

• Product Design Verification Testing

• Intro to Manufacture

System Design Methodology Documents

Can Serve as Schedule Milestones

• Documentation of each step: ▫ facilitates scheduling of milestones.

▫ facilitates review by many engineers (two minds are better than one).

▫ Serves as important intellectual property and helps other engineers in the future.

Methodology Step Milestone Documents Are Completed

Approximately in Order and are Hierarchical

• Market Product Requirements Document – Answer the question, “What does the customer want, need, and expect.”

▫ They list and describe customers and their needs and expectations.

▫ Can be jointly prepared by marketing, sales, and engineering based on customer and market knowledge.

• Engineering Product Requirements – Answer the question “What” product to meet the customers needs.

▫ Lists technical aspects of products that fit the market product requirements at a high level

▫ Do not over-constraining detailed implementation design choices too early in the process.

• Engineering Product Specifications – Answers the question “How.”

▫ Describes detailed product implementation and design plans.

▫ Circuits, Software, DSP Algorithms, FPGA/ASICs, HDL

• Implementation: Schematics, Software, VHDL, Simulation, and Mechanical Design Files/Documents

▫ These items often include many related materials, such as BOM’s, simulation results, etc.

Milestone Documents (II)

Milestone Documents (III)

• Engineering Design Verification Test Plans – Test to verify that prototype unit and system designs are error free, matching requirements.

▫ If not, iterate the design.

▫ Else verify that acceptable design has resulted that can be characterized and included in the customer documentation.

Waterfall Scheduling Concept

• Steps are hierarchical.

• Each step completed in order.

Goal of Reviews

• Problems found late have higher impact!

• Milestone reviews by many engineers help get each step right to avoid late changes that have high impact.

• Users often notice aspects of prototype application software that need improvement.

• Software applications are less costly to change than hardware prototypes.

• The “Agile” software development methodology involves planning to schedule changes iteratively until the product is “polished.” Ideas for improvement are fed back into for prototype specifications and revised releases.

• The Agile methodology was developed by the Agile Alliance.See: http://www.agilealliance.org

Software Scheduling Challenge –

The Need to Iterate to Correct Problems

AGILE Software Development Overview

• Software methodology uses iteration.

• Results converge on final product (the “Implementation” at left).

• Even using Agile, a scheduled completion date is still the goal.

(Illustration reproduced following wiki image rules permitting reproduction.)

New Product Example: Use of New Memory Bus

Standards in Product Requirements

X86 Processor (left) Uses External IC (lower right) to

Control DRAMs Inserted into Slots (older PC design).

Intel iCore Design

Requirements

Specified Dual

External DDR3

Memory Buses

Connected to the

Processor IC For

Performance

Improvement

Intel Core i5-600, i3-500 Desktop Processors and Intel Pentium

Processor G6950 Platform Diagram

Routing length of DDR3 traces is short (<1inch).

Intel iCore

Company Product Development

Portfolios• A set of products that have been approved

for development are called the company’s product development portfolio.

• Business planners evaluate risk and help executive managers choose an appropriate mix of low, medium, and high risk products to develop.

Low risk: incremental improvements to established product lines.

High risk: R&D intensive, and for non-established markets. Potential high rewards.

Digital Signal Processor Based

Product Development

Lucent Wireless Basestation DSP Demo and Evaluation Board

Designed by By J. Bellott, MSEE

UNIT 3

DSP Manufacturers (partial)DSP’s cost from $1.00 to several hundred dollars.• ARM – Core IP • Texas Instruments - Full product line; i.e. low

power, high perf, and multi-cores, SOC, ARM• Freescale – Full product line.• Analog Devices – Full product line; includes high

performance floating point TigerSharc.• CEVA – SOC’s in cell phone designs.• XMOS – multi-cores, RTOS• Xilinx FPGA’s with CPU Cores and 1000 MACs• STMicrolectronics

Xilinx and Intel FPGA’s for DSP

Applications

FPGA’s offer IP blocks for DSP functions.

• Low level DSP architecture building blocks including MAC’s, adders, registers, and other functions.

• Xilinx FPGA’s can include an ARM processor and many MAC’s that can execute DSP functions quickly

• IP is available to implement filters, encoders/decoders, and numerous other application specific functions.

• The MathWorks Simulink and MATLABenvironments provide means to model and then generate FPGA HDL code.

MathWorks DSP Toolbox

• Simulink Models and MATLAB algorithms allow simulation and debugging of DSP functions.

▫ Can automatically generate TI C6XXX code with 60% efficiency of hand coding.

▫ If Simulation works, Auto generated code will too.

• Xilinx tools work with Simulink and Matlab to create code to program an FPGA with DSP functions after the design has been simulated and debugged.

• http://www.mathworks.com

IC Evaluation Circuit Boards

• Contain DSP, CPU and useful peripherals for target market.

• Development interface for downloading code, setting breakpoints, and inspecting values. PC interface: USB or Ethernet to JTAG or 1-wire.

• Software development kits:1. PC IDE Compiler (most medium to high performance

DSP’s are C programmable)

2. Support routines or driver software for board IC’s.

3. Many RTOS’s available for some chips

DSP Board Design Considerations

• Application algorithms required. Buy IP or write.

• Algorithm real-time requirements

• Key real-time execution benchmarks for application

• Software size in Bytes

• # Cores, frequency

• System Algorithm Design simulation (e.g. Simulink)

• Planning of communication between cores

DSP Board Design Considerations (Con’t)

• High speed clocks – DDR3/DDR4

• Analog and digital ground regions

• Controlled impedances for critical nets

• Signal Integrity analysis – Eye BERR simulation, test and measurement post-verification. Mentor Hyperlynx Line-Sim and Board Sim useful tools.

• Power up sequencing for multiple power supplies for high end DSP’s and other large IC’s.

• Noise isolation on supplies

• Lithium Ion charger circuit (portable)

• Power saving modes, all IC’s in product (portable)

6/10/2011DGB V1.0 6/10/2011DGB V1.0DGB V1.0

43

UNIT 4

METHODOLOGY MILESTONE

DOCUMENT CONTENTS -

EXAMPLES

Marketing Product Requirements

(An Example Outline)

• Target Market (Who Will Buy For What Purpose)

• Product High Level Description

• Product Features Of Importance to Customers

• Product Compatibility

• Technical Standards Required

• Target Cost

• Target Availability Date

• Size Constraints

• Performance

• Reliability

• Countries for Sale (Power sources)

• Agency Approvals that Must be Met (FCC, UL, CE, CSA, etc.)

Systems Engineer Role

When preparing system design requirements, the systems engineer or other responsible engineer takes into account:

• Technology trends (e.g. cell phone user interface paradigm shifts of past 3 years.)

• Current state of the art technologies (e.g. types of touchscreen technologies)

• Competitors technologies plus information from industry forums and associations (info about what groups of competitors are preparing together).

• Latest standards and standards under development in key areas.

• Capabilities of engineering department and how best to apply them to market needs.

• Recommend hiring needs to managers when appropriate.

System Design Requirements

(An Example Outline)• System Overview

• Overview of Target Market

• Typical Use Scenario - Customers goals and purposes for using the product

• System Requirements for Features and Functionality

• System Software Requirements plus high level Architecture

• Signal Processing Algorithm Modeling Requirements

• System Hardware Requirements plus high level Architecture

• System Reliability Requirements

• Standards Requirements (Industry standards to be met by system

• design; e.g. interface standards)

• EMI and EMC Requirements (FCC, CE, etc.)

• Environmental Requirements (Temperature, Altitude, Humidity,

• Shock, Vibration, Acceleration)

• Safety Requirements (UL, CSE, CE, etc.); Countries Product Will Be Sold

• Power Supply Requirements

Design Requirements for a Board (Example)• Circuit Board Functional Requirements

• Performance Requirements (e.g. rates)

• System External Interface Requirements

• System Internal Interface Requirements

• Control and Status Features Implemented in Hardware

• Design Testability Features

• Cost

• Reliability

• Operating Environment Requirements

• Manufacturing Standards Requirements (e.g. RoHS)

• Documentation

• Provisions for future versions

• Physical Design Requirements

• Manufacturability (Testability in Production) Design Requirements (e.g. diagnostics support)

• Power Requirements

• Design for EMI/EMC

• Mechanical Design Requirements (may be documented separately)

• Technical Standards Support Requirements (Std. #’s)

Software Design Requirements (Example)

• Specific requirements

▫ External interfaces

▫ Functional requirements

▫ Performance requirements

▫ Logical database requirements

▫ Design constraints

▫ Software system attributes

▫ Organizing the specific requirements

▫ Additional comments

• Supporting information

▫ Table of contents and index

▫ Appendixes

• Introduction

▫ Purpose

▫ Scope

▫ Definitions, acronyms and abbreviations

▫ References

▫ Overview

• Overall Descriptions

▫ product perspective

▫ product functions

▫ user characteristics

▫ constraints

▫ assumptions and dependencies

Circuit Board Specifications (Example)• Circuit Board Description

• Functional Block Diagram

• Specifications of Circuit Blocks

• Processors

• FPGA’s (Detailed specifications or reference to separate document.)

• Simulation Plan Describing Models and Software Tools to be Used(e.g. MathWorks Simulink)

• Other digital parts and logic.

• Analog Circuits

• Power Supplies

• Connectors

• Simulation Plans (before, after routing; model types; signals requiring simulation)

• PCB Type, Layers, and Routing Guidelines

• Signals Requiring Critical Routing; Signal Groups Requiring Controlled Impedance Routing; Length rules for critical signals.

• Target AC Specifications of Critical internal Signal Groups

• Table of I/O Specifications

• Table of target AC and Electrical Specifications of I/O Signals

• Operating Conditions, Storage Conditions

Additional Milestone Documents

• Software Specifications Document

• Signal Processing Algorithm Development Plan (Algorithms, Modeling Methods, Transfer to Design

• FPGA or ASIC Functional Requirements and Specifications

• System Simulation Platform Specification Document

▫ May include CPU Software, FPGA, and Analog Circuits

▫ Ex. MathWorks Simulink Platform Used as Design and Simulation Tool

• Test Plan Documents

Design Verification Test Plan Documents

May Include:• DSP/FPGA/Analog Circuit Simulation Using Simulink

• Hardware Unit Test Plans (e.g. a PCB)

• FPGA Test Plans

• Software Unit Test Plans

• System Integration Test Plan -Each piece of hardware requires diagnostic software for hardware regression testing

• Full System Test Plan – Test Cases Verify System Req.s

• Temperature, Altitude, and Humidity Test Plan

• EMI/EMC Test Plan (for agency approvals, e.g. FCC, CE) (Country dependent)

• Shock and Vibration Test Plan

• Safety Test Plans (e.g. UL, CSA, CE certification)

Full System Test Plan Example Contents

• Introduction

• Overview of goals and purpose

• References to other project documents.

• System Version to be tested▫ Hardware, FPGA, and software versions are to be tested.

• Test Configuration diagrams

▫ Also shows main test equipment and other systems connected during testing.

• Lab Test Equipment and Diagnostic Software used with Test Configurations

• Test Descriptions – Keyed names for reference, e.g. HW-Memory-001 or SW-DiskAccess-001 or SYS-UserInterface-001

▫ Broken down by functional areas (e.g. PC power supply, PC memory, PC SATA interfaces, PC DVD, PCIe slots, etc.)

▫ One page or less describing the approaches to be taken to test each area. (This section can be submitted for peer review before Test Steps are planned in detail.)

• Test Steps - Lists of lab steps for each test summarized in Test Descriptions section.

• Traceability Table

6/10/2011DGB V1.0 6/10/2011DGB V1.0DGB V1.0

55

UNIT 5

ENSURING QUALITY OF THE

DEVELOPMENT PROCESS

Ensuring Quality of Development Process

• Employee education on methodology expected to be followed (helps organize the process).

• Re-usable checklists of items to include in documents (changed by engineers as they wish; they are only helpful starting points).

• Peer Reviews of documentation – “Pass” status before proceeding to next milestone. Circulate docs or time limited meeting.

• Project databases (i.e. Project Change Control Tracking) – database stores lists of bugs and ideas for improvements; provides statistics about known problems and their resolution status.

• Traceability of Low to High Level Documents – Makes sure no features are left out or not tested.

• Automated Tools for Project Management and version/release planning

• Post-Evaluation of Results fed into Process Improvement

Gantt Charts Show Scheduled Milestones

• Example below produced by Microsoft Project

▫ The critical path is red

▫ The black lines connected to non-critical tasks show the schedule slack.

Traceability of Milestone Documents –

Definition and Purpose

Traceability of document sections shows how lower level documents cover the requirements.

Examples:

• Item per Item traceability of design specifications sections to market requirements sections ensures that designer meets the identified customer needs.

• Traceability of Test Plans to Requirements documents helps ensure that finished product meets the requirements.

Example Requirements Traceability Table

(Traceability of Test Plan)

Section Requirement Test Number Test Name

4.2.5 The processor shall run at 2 GHz, Minimum to support the firmware tasks.

HW-PROC-004 Hardware processor clock test, Section 3.2

4.2.6 The processor shall have 8 GPIO bits.

HW-LED-007 Board LED test, Section 4.2

4.2.7 The board shall have at least 2 GB of DDR2 memory

HW-MEM-001 Board Memory Address Test, Section 3.7

Etc. Etc. Etc. Etc.

Automated Tools for Documenting

Traceability

• DOORs software links sections of multiple, hierarchical documents. All can be opened simultaneously in cascaded document windows. DOORs has a built in word processor.

▫ More helpful when large product is created, and several releases will be made.

▫ Automated tools sometimes require learning curve and extra work for organization to use. Economic value needs to be considered.

Milestone Document Peer Reviewing

• Peer reviews are performed to bring the talents of many people to bear. As the old adage goes, “two minds are better than one.”

• Reviews ensure that mistakes are caught as soon as possible and that many good ideas are factored in.

• Net cost savings often occur if managers schedule time for engineers to study others’ documents, schematics, and code and participate in review meetings.

▫ Engineers can request an extra week (for example) in their schedule for several peer reviews.

• Managers must plan how this will be done and inform employees if this method of reviewing is to succeed.

Peer Reviewing – Suggested Method• Distribute documents several days in advance (avoid scheduling

surprises).

• Review meetings fixed length (suggested max 2 hours).

• Moderator is designated. Keeps team on track; big issues can be recorded and handled outside of meeting.

• Recorder takes notes about comments (unless handed in by commenter).

• Outcomes of a review meeting: 1. Approved as is.

2. Approved, subject to small comments (one person can check later and approve.).

3. Incorporate changes and hold another review.

• Document “frozen” (or “baselined”) when reviewers agree that it is complete. A “sign off” sheet shows which reviewers attended and agree to approve the item.

“Modification Request” Logging by

Testers or Customers

• Useful entries in software change control databases include:

▫ Description of problem or suggested change

▫ How to reproduce problem

▫ Area impacted (e.g. a board, an FPGA, or a software module)

▫ Severity (critical, high, medium, low)

▫ Impact of problem: who is affected how and where (e.g. in the field)

▫ Customer who reported problem from field (if appropriate) and notes about their needs.

• Change Control Manager / Project Manager Tracks Status of Proposed Changes

Modification Request Logging Concepts

• MR databases for Project Change Control Tracking

• A project team member is assigned role of MR administrator/tracker.

• MR’s pass through a series of steps related to their status. MR’s have owners assigned at all times.

• Status may include:▫ Open

▫ Under Investigation

▫ Fixed or Defer (to a later release)

▫ Verified

▫ Closed

POSITION YOURSELF FOR

ENGINEERING SUCCESS –

BE PROACTIVE

The proactive engineer does these things:

• Studies field to stay aware of competitive technologies, trends, standards, tools, methods. Takes Ed courses in technical field.

• Indicates type of assignments desired.

• A supervisor owns an employees schedule; however, an employee can be proactive by listing tasks the way they would like to do them, and presenting them as a schedule proposal.

• Negotiate schedules that are presented. “I think we need to add a two week step for this purpose: ____ .”

• Breaks down milestones into small tasks to form a personal plan for meeting company milestones. Your list of tasks can be kept to yourself. Use this as a tool for success.

• Present product ideas and proposals to your manager.

Things to Consider When Choosing

Companies/Products to Work on:

A good list of goals to consider:

• Products that help people do things in a new and better way.

• Products that help people by enhancing and enriching their lives in purposeful, constructive ways.

• Products that advance high goals such as helping the hungry, homeless, or disabled.

Engineers are part of a supply chain that delivers products to the end user for whatever their intended purpose may be. Be accountable for helping others through your work by applying a code of ethics/high moral values to the use of your talents in the supply of goods to the end user.

Thank you!

Jerry Bellott

jbellott.ieee@outlook.com

www.gtdigital.org

4/15/2012

J. Bellott Career Highlights• Bell Laboratories (1981-2000) – Designed reference design circuit used by

Motorola to design Bell Lab’s IC’s into first compact flip top lid 2G digital cell phone. Wrote specifications for custom ASIC interfaces in DSP for Motorola 2-way digital wireless pager. Specified and qualified Intel PC NTSC digital video encoder/decoder board, disk controller, video card, WD Motherboards, and PC Test Software. Co-developer of Definity PBX (CPU circuits plus trunks) and AT&T X.25 Network access circuits (used by bank ATM’s and shortwave digital radio relay stations)

• During career, >1.4 Million Boards deployed in field.

DGB V1.0

AT&T WGS Windows

PC Board

Bell Labs DSP Eval. and Reference

Design Platform (left).

Motorola StarTac Flip-Top Lid Cell

phone, first compact 2G digital on

market, used Bell Labs IC’s.

Motorola 2-Way Digital Pager used

custom Bell Labs DSP1621 (above).

Career Highlights• ViaGate Technologies, Inc. Startup (2000, 2001) – Senior Systems Engineer on

Fiber and VDSL 2Gbps ATM switch project. Remote LAN bridging, MPEG2 HD video delivery, and internet access for 240 rooms. Company purchased by VDSL innovator Tut Systems, now part of Motorola.

ViaGate Technologies VG-4032 ATM Switch –Fiber to Basement VDSL ATM Switch. Specs: 2 Gbps stat mux backplane switch, 4 OC-12 Fiber Interfaces, and 240 VDSL Interfaces. PowerPC processors, distributed Unix multiprocessing. Shown with ViaGate VDSL Ethernet

modem and OEM set-top boxes. Standards including: IP over ATM, encapsulated Ethernet over ATM, Remote EMS using SNMP, assignable QoS for each service type, QoS prioritization queues.

Career Highlights• Recent (2010-present) –Design Talks, Circuit Design, Author 6 Books

• IMT (Integrated Microwave Technol.) (2009) –Documentation for HDTV COFDM microwave digital video links and streaming video over LAN products. Multi-antenna diversity receivers.

• DSP Consultants (2005-2008) – System HW/FW/SW test plans, EMI/EMC test plans, and other documentation for products using DSP’s, microcontroller boards, PC’s, LAN and Fibre Channel SAN connectivity, MPEG encoders, GUI applications for elaborate spectral plots and time domain scopes, plus RF, SDR, and GPS receiver circuits. digital audio and video recorder system with built in file servers plus ability to stream MPEG4 video to remote clients over Ethernet.

• Valley Technologies, Inc. (2004) – Co-designer 1 GHz, 64-Core MathStar DSP PCB. MathStar DSP intended for use in satellites plus video and medical imaging applications.

MathStar reconfigurable 1GHz, 64-core DSP.

Valley Technologies VT-4000 Using MathStar 64-Core DSP