dgb v1.0 3-16-18 product development methodologies for...

3-16-18DGB V1.0

Product Development

Methodologies for Success! –

IT Hardware and Software©2018 J. Bellott

2018 IEEE/ACM TCF Information Technology

Professional Conference

March 16, 2018

Presented by: Jerry Bellott, MSEE

IEEE PCJS SPS Chapter Vice Chair; Computer Society Member

[email protected]

www.gtdigital.org/welcome

Product Development

Methodologies for Success! –

Talk Outline:

1. How Product Development Methodologies Ensure Success

2. Typical Product Development Methodology Steps

3. State of Several Advanced Technologies for IT

4. Ensuring Product Development Process Quality

5. Examples of Methodology Document Contents (Read on your own on the web)

3-16-18DGB V1.0

DGB V1.0DGB V1.0DGB V1.0

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.

DGB V1.0

Examples of Customer Needs and

Expectations

DGB V1.0

Features

Price

Availability Dates

Reliability

Maintainability and Support

Corporate Competition

DGB V1.0

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.

DGB V1.0

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

DGB V1.0


Roles Of Departments In

Planning New Products

Organization of a Typical Company

DGB V1.0DGB V1.0

• Corporate Management

• Accounting

• Business Planning

• Marketing

• Engineering and Project Management Teams

• Manufacturing

• Quality Assurance

• Sales and Customer Support

• HR

DGB V1.0

Methodologies followed by companies encompass practices, procedures, and guidelines that are designed to help the workforce achieve success in its goals.

DGB V1.0DGB V1.0

Roles of Marketing Department in

Product Development

• Ideas for market innovation

• Customer identification. Demographics.

• Identifying customer needs.

• 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

DGB V1.0

DGB V1.0DGB V1.0

Role of Business Planners in

Product Development

Business plan documents are for executive managers. They produce Business Cases, which cover:

• Description of product

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

• Assessment of risk/ returns

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

DGB V1.0


UNIT 2

TYPICAL PRODUCT DEVELOPMENT

METHODOLOGY STEPS

DGB V1.0DGB V1.0

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 Algorithm (standards based or custom), Software Code, FPGA Code, and Design Simulation

• Product Design Verification Testing

• Intro to Manufacture

DGB V1.0

DGB V1.0DGB V1.0

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.

DGB V1.0

DGB V1.0DGB V1.0

Methodology Steps & 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.

DGB V1.0


• 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, Test Plans, and Mechanical Design Files/Documents

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

Product Development Methodology

Hierarchical Steps (II)

DGB V1.0DGB V1.0

Product Development Methodology

Hierarchical Steps (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.

DGB V1.0

Waterfall Scheduling Concept

DGB V1.0

• Steps are hierarchical.

• Each step completed in order.

DGB V1.0

• 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

DGB V1.0

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


Company Product Development

Portfolios (I)

An Example IC Product Family Tree • Vary by Features, Price, Speed

DGB V1.0DGB V1.0

Company Product Development

Portfolios (II)• 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.

DGB V1.0


UNIT 3

EXAMPLES OF PRODUCTS BASED

UPON NEW TECHNOLOGY DRIVEN

REQUIREMENTS


TECHNOLOGIES USEFUL FOR IT

APPLICATIONS DRIVEN REQUIREMENTS

A. DDR1-4 DRAM Memories (Speeds to 2.4 GHz)

B. DSP Parallel Processing (1000 DSP’s on a signal FPGA; 1GHz +)

C. LVDS Signals – PCIe, PCB’s,Backplanes

Point-to-point 16 GHz serial data bus on PCB or backplane

D. SYNCHRONOUS ETHERNET IEEE1588 to distribute a count or time-of-day info on low layer.

DGB V1.0DGB V1.0

New Product Example: Use of New Memory Bus

Standards in Product Requirements

DGB V1.0

A. DDR1-4 DRAM Memories

DGB V1.0DGB V1.0

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

Control DRAMs Inserted into Slots (older PC design).

DGB V1.0

DGB V1.0DGB V1.0

Intel iCore Design

Requirements

Specified Dual

External DDR3

Memory Buses

Connected to the

Processor IC For

Performance

Improvement

DGB V1.0

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

Chip-On-Chip Technologies – For Fast Memory

Chip on chip packages place Memory (rates to DDR3) atop the DSP and other CPU core die to form an SOC with DRAM and/or Flash memory. 1.6 GHz DDR3 memory speeds possible.

Samsung produces a dual core ARM Cortex A9 die in the same package as DDR3 memory (1.6 GHz). Micron is the largest DRAM maker.

DDR MEMORY IC

PROCESSOR IC

B. Digital Signal Processingof analog signals

1. Low pass (or band pass) filter the analog signal to band limit the signal to the frequency spectrum of interest.

2. Applying Nyquist’s theorem, an analog signal can be reproduced later if sampled at a rate more than twice its highest component frequency.

3. Process the signal as desired using math algorithms. The algorithms are typically Z transformations of the time domain transfer function representing the algorithm.

4. Use DAC to convert the DSP algorithm output to analog if desired.

http://en.wikipedia.org/wiki/File:DSP_block_diagram.svg

Filters: FIR Filter Output Spectral Plot

• 15kHz Low Pass FIR Filter• dB vs. Frequency (kHz)• 500 coefficient filter; used 500

multiplications/additions

Filters: FIR Z-transform Graphical

Representations

A typical DSP algorithm in that it involves steps with algorithm coefficients multiplied by each data sample and added to the earlier result.

Basic Architectural Component: MAC

• Two operands are multiplied together and added to the previous results using a Multiplier / Accumulator Circuit with minimized combinational logic for high speed.

X Y

16 16 16

3216

AlAhAe

4 16 16

CLOCK

16

16

16

COEFFICIENTS DATA

DSP Timeline – MAC Speeds1980• TRW TDC1010 16x16 MAC, 1980 - 60 microseconds• AT&T DSP1 and NEC µPD7720 were first single chip DSP’s.1983• TI TMS32010 and Motorola 56000• 390 nsec MAC operation. 1988• AT&T DSP16A or the Motorola DSP56001• 21 nsec MAC• Features included Harvard architecture, internal instruction storage to

accelerate tight loops (not a full cache), ability to increment addresses for sequential access.

1995• By the mid 1990’s, DSP’s included acceleration coprocessors for

specific applications, and also were available in SOC. TI high performance C6 offered efficient C programming.

Current DSP’s • <3 nsec MAC operations; small geometries (e.g. 28 nm). Some have

VLIW instruction sets for efficiency and extensibility, superscalar architectures. Data Flow DSP’s for GPU applications.

MULTI-CORE

BROADBAND ACCESS

CHIP EXAMPLE

• 6 High Performance DSP Cores with L1, L2 Caches

• CPU

• Communications Co-processor (Viterbi, Trellis, other comm. encoding/ decoding and bit manipulation)

• Local RAM

• External DDR2/3

• LVDS High Speed serial I/O

• PCIe Host Interface

• Ethernet networking

PERIPHERALS

(Timers, Int,

DMA, ,GPIO,

SPI)

DDR

INTERFACE

SIX DSP CORES

ADDR

RAM

DDR2/3

MEMORY

FLASH

PERIPHERAL

IC'S

SERIAL

RAPID I/O

INSTR

ADDRESSES

DATA

ADDRESSES

S

W

I

T

C

H

L1 INSTR L1 DATA

L2 CACHE

DSP

CORE

L1 INSTR L1 DATA

L2 CACHE

CPU

COMM.

PROTOCOLS

COPROCESSOR

ETHERNET

RF

INTERFACE

DATA

TO BOARD ICS OR

SWITCH FABRIC

TO BACKPLANE

TO ADC/DAC

AND RF CIRCUITS

EXTERNAL

MEMORY

INTERFACE

DMA

AES

ENCRYPTION

SYSTEM ON CHIP

PERIPHERALS

TIMERS, INT,

DMA, GPIO, SPI

Technology:

Differential current mode signals terminate on OpAmp + and – inputs; reverse the current direction for “0” or “1”

DC offset approx. 0.9 Volts. Common mode noise is removed by the OpAmp.

EMI is minimal because of reverse current directions inpairs. (Lines of flux cancel each other.)

C. Low Voltage Differential Signals (LVDS)

• Used in PCIe slots (PC PCI Express buses)

• up to 16 Gbps per pair (lane) x 32 lanes in PCIe 4 standard.

• PCIe uses 8b/10b edge insertion for clock recovery at the receiver.

• FPGA’s (Field Programmable Gate Arrays) have modules that can terminate PCIe, and thus the DSP functions of an FPGA can be fed data from a PC quickly.

• XILINX FPGA’s have up to 1000 DSP’s that can operate in parallel. Data hungry application.

• PCIe can be used for interconnect to Fiber Channel SAN interface cards

PCIe LVDS Signals

4/15/2012

• High speed backplane signals

• PICMG Industry Consortium; http://www.picmg.org

• SATA Disk Drive Interface Standards

• ADC Outputs

• Interconnection of ADC’s and signal processors

• Interconnection of ADC’s and FPGA’s with DSP’s

• Output has accompanying bit clock and frame synch signal

• Data output begins after analog to digital conversion latency

Low Voltage Differential Signals –

Additional Applications

http://www.picmg.org/

4/15/2012

LVDS Serial Path Design

LVDS (Low Voltage Differential Signal) info:• Current Mode, Pair of Differential Signals• Rates to > 4 Gbps; 16 Gbps in PCIe Version 4• Transmission line issues resolved by impedance matching.

Bends and Via counts are limited to avoid small reflections.

• Simulation of bit error rates for signal integrity desirable.• Signal Integrity study of prototypes can be done using

waveform generators plus storage scopes/eye analysis tools. (See Tektronix website for example equipment).

• Mentor HyperLynx is a leading design and PCB layout simulation tool.

TECHNOLOGY:

• Uses IEEE 1588

• Precision Ethernet clocks, fixed packet size, PHY carries time or time of day info to synchronize endpoint clocks.

• Clocks synchronized to within a few microseconds.

APPLICATIONS:

• Measurement systems, centrally controlled by CPU

• Synchronous collection of data from multiple sensors

• Control systems, centrally controlled by CPU

• Real-time control of actuators/sensors connected to distributed local endpoints

D. Synchronous Ethernet


55

UNIT 4

DGB V1.0DGB V1.0

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

DGB V1.0

57

Gantt Charts Show Scheduled Milestones

DGB V1.0

58

• Example below produced by Microsoft Project

▫ The critical path is red

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

DGB V1.0DGB V1.0

Traceability of Milestone Documents –

Definition and Purpose

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

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.

DGB V1.0

59

DGB V1.0DGB V1.0

Example Requirements Traceability Table

(Traceability of Test Plan)

DGB V1.0

60

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

DGB V1.0

61

• 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

DGB V1.0

62

• 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

DGB V1.0

63

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

MR Logging Concepts

DGB V1.0

64

• Seibel and GNATS – 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

DGB V1.0DGB V1.0

“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

DGB V1.0

65

4/15/2012

Thank you!

Jerry Bellott, MSEE

[email protected]

www.gtdigital.org/welcome


43

UNIT 5 – On Your Own

EXAMPLE METHODOLOGY

DOCUMENT OUTLINES

VG4032 240 Line Fiber to Basement Broadband Switch (HDTV, Ethernet modems for 240 Rooms)

DGB V1.0DGB V1.0

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

DGB V1.0

DGB V1.0DGB V1.0

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.

DGB V1.0DGB V1.0

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

• 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 Where Product Will Be Sold

• Power Supply Requirements

DGB V1.0

DGB V1.0DGB V1.0

Software Design Requirements

• 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

DGB V1.0

• Introduction

▫ Purpose

▫ Scope

▫ Definitions, acronyms and abbreviations

▫ References

▫ Overview

• Overall Descriptions

▫ product perspective

▫ product functions

▫ user characteristics

▫ constraints

▫ assumptions and dependencies

DGB V1.0DGB V1.0

Circuit Board Design Requirements Document• 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)

DGB V1.0DGB V1.0

Circuit Board Specifications Document• Circuit Board Description

• Functional Block Diagram

• Specifications of Circuit Blocks

• Processors

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

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

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

• 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

DGB V1.0

Design Verification Test Plan Documents

May Include:

DGB V1.0DGB V1.0

• 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

• Temperature, Altitude, and Humidity Test Plan

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

• Shock and Vibration Test Plan

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

DGB V1.0

Full System Test Plan Example Contents

DGB V1.0DGB V1.0

• 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

DGB V1.0

DGB V1.0DGB V1.0

Additional Documents

• FPGA 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

The proactive engineer does these things:

• Studies field to stay aware of competitive technologies, trends, standards, tools, methods. Takes educational 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.

DGB V1.0

Things to Consider When Choosing

Companies/Products to Work on:

A good list of goals to consider:

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

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

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

• The value of the end use of products.

DGB V1.0

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 police shortwave digital radio relay stations)

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

DGB V1.0

AT&T WGS Windows PC

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 broadband switch project. MPEG2 HD video delivery, remote LAN bridging, and internet access for 240 rooms. Company purchased by VDSL innovator Tut Systems, now part of Motorola.

3

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 5 Books

• IMT (Integrated Microwave Technol.) (2009) –Documentation for HDTV COFDM microwave digital video links for ENG crews, streaming video over LAN products for law enforcement officials.

• DSPCon, Inc. (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-MAC 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