Transcript VHDL Synthesis for High

What Does It Have to Do?
Specifying the design
2005 MAPLD
28
Design Integrity Concepts
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
2005 MAPLD
29
Design Integrity Concepts
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 user’s manual
As a box to check on the schedule checklist
2005 MAPLD
30
Design Integrity Concepts
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 -> impose imperatives
• Should, might -> define preferences
• Will -> 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
2005 MAPLD
31
Design Integrity Concepts
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 test 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
2005 MAPLD
32
Design Integrity Concepts
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
2005 MAPLD
33
Design Integrity Concepts
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 EEEINST-002
2005 MAPLD
34
Design Integrity Concepts
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)
2005 MAPLD
35
Design Integrity Concepts
What Shouldn’t 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
– The unit shall replace the functionality provided by p/n 276401-01
2005 MAPLD
36
Design Integrity Concepts
Why Shouldn’t 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
2005 MAPLD
37
Design Integrity Concepts
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?
2005 MAPLD
38
Design Integrity Concepts
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
2005 MAPLD
39
Design Integrity Concepts
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
– Don’t be passive with suggestions
2005 MAPLD
40
Design Integrity Concepts
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
2005 MAPLD
41
Design Integrity Concepts
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”
2005 MAPLD
42
Design Integrity Concepts
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
2005 MAPLD
43
Design Integrity Concepts
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
2005 MAPLD
44
Design Integrity Concepts
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.
2005 MAPLD
45
Design Integrity Concepts
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
2005 MAPLD
46
Design Integrity Concepts
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
2005 MAPLD
47
Design Integrity Concepts