Design Evaluation
The requirements
for complex electronics are implemented in some design form, such as a
Hardware Description Language (HDL) model or circuit drawing. Most
modern designs for complex electronics are created using a HDL, such as
Verilog, VHDL, or SystemC. These designs are essentially models of the
system, with defined structure and behavior, which can be executed and
tested.
Evaluating
the design requires familiarity with the design language and a good
understanding of electronics. Because most assurance engineers have
limited experience with complex electronics, moderate or high
classification device designs should be evaluated by a knowledgeable
and independent electronic engineer. However, assurance engineers with
a basic level of knowledge can identify inconsistencies with
requirements, assess the testability of the design, and perform other
important evaluations.
For
Complex Electronics, the main goals of design evaluation are:
1.
Ensure that all CE requirements are correctly and
completely implemented in the design.
2.
Identify any inconsistencies or conflicts within the
design, with other system elements, or with good design practices.
3.
Ensure that the quality of the document (e.g.
readable, unambiguous) is adequate for its usage. Also ensure that
design standards are followed.
4.
Ensure that the design can be adequately verified
(tested).
Inputs
The main
inputs (documents) for a design evaluation are the design itself (e.g.,
HDL model, schematic diagrams) and the complex electronics requirements.
Additionally, the following types of documents may be useful:
- Interface control
document
- HDL coding standard and
any other design standards
- Complex electronics
testing plan and test bench documentation
- Verification and
Validation Plan for complex electronics
- Design documents from
system elements that interface with the complex electronics
Evaluation
Process
1.
Assess evaluator knowledge and experience. The
assurance engineer evaluating the design may be highly experienced with
complex electronics, or may just be learning. The evaluator needs to
consider his/her experience with the HDL language, the type of system,
and other details of the project, in order to determine the level of
evaluation possible. If the complex electronics classification is
moderate or higher, consider having an independent engineer evaluate
the design.
2.
Perform high-level evaluation. Evaluate the
architectural and behavioral design.
o
Is the design complete (does it implement all the
requirements)?
o
Is the design consistent – look for inconsistencies
within the design, and also with other designs in the project. Are
similar items and functions handled in the same way?
o
Does the design address testability?
o
Are the interfaces (external and internal) correct
and consistent?
o
Does the design meet the coding standard? Is naming
consistent within the design, and across similar designs?
o
IP cores: Are they being interfaced to correctly?
Are they being used within the CE in a way consistent with their
functions? What verification information is provided by vendor? How
will they be tested/verified as part of the CE?
o
For requirements that involve trade-offs (power
consumption, speed, performance, etc.), does this design have any
impacts on other system elements? Were the design decisions negotiated
and agreed to by all affected parties?
3.
Perform a detailed evaluation of the design.
o
Is the design correct?
o
Are all features driven by requirements (no gold
plating)?
o
Use the design review checklist to look for specific
potential problems.
4.
Document evaluation(s), including the information
used (inputs), the evaluation process followed, and results.
5.
Resolve errors, inconsistencies, and questions. Work
with the designer and other project people to answer questions and
resolve issues. Determine if the issue is an error, documentation
problem, or a misunderstanding. Put errors (defects) into the project
problem reporting system to ensure they are fixed.
Outputs
The
primary output is an Evaluation Report. The report will describe the
evaluation, the documents and information used as inputs, and the
results of the evaluation. Include identified errors, inconsistencies,
and open issues in the report. For open issues, include the status of
the issues if known (e.g., error was recorded as PRACA 1234).
|
