VHDL Design Review
And
Presentation
Dr. Rod Barto
3312 Moonlight
El Paso, Texas 79904
915-755-4744
rbarto@klabs.org
rod.barto@att.net
Basic Design Rule
• The designer should know and be able to
prove:
– The design meets the spec
– The design passes a worst case analysis
• The designer presents this proof to the
reviewer
• The reviewer verifies the proof
May 30, 2002
RLB
2
Problems In Design Review
• Biggest problem: inadequate design
documentation, giving rise to questions
such as
– What does this thing do?
– How does this implement the spec?
– How does this work?
• Documentation is the designer’s
responsibility
May 30, 2002
RLB
3
Special VHDL Problem
• Poorly written code
– Endless, mindless structural and spaghetti
VHDL
• Writing good code is difficult
• Understanding design by reading code
extremely difficult
• Documentation and comments crucial
May 30, 2002
RLB
4
Results of Poor Documentation
• Reviewer asks a lot of questions
– Of the designer
– Of the system engineer
– Of the scientists
• Reverse engineering
• The reviewer should not automatically
assume that the designer understands the
design.
May 30, 2002
RLB
5
Designer’s Responsibilities
• Make the design reviewable
– Documentation
• Theory of operation
• Proof that spec and WCA are met
– Organization
• Partitioning into logical components
– Presentation
• Readability of schematics, VHDL, etc.
• How would you, the designer, explain your
design to someone else?
May 30, 2002
RLB
6
How to Review VHDL Designs
• How does one perform a design review, in
general?
– Most design review tasks are independent of
how the design is presented
• What does VHDL add to the task?
May 30, 2002
RLB
7
What VHDL Adds to the Review
Process
• Probably, an awful lot more work!!
• VHDL introduces serious problems:
– It hides design details
– It is not WYSIWYG: What you see (as your
design concept in VHDL) may not be what
you get (as an output of the synthesizer)
– Coupled with FPGAs, it encourages bad
design practices
May 30, 2002
RLB
8
VHDL Hides Design Details
• Connectivity hard to follow in VHDL files
– Especially true for translations from
schematics
• Behavior of sequential circuits can be hard
to follow through processes
• Interactions between logical blocks can be
difficult to understand
• Spelling errors → undetected circuit errors
May 30, 2002
RLB
9
E.g., a spelling error?
• A VHDL module contained two signals:
– CSEN appeared only on the left side of a
replacement statement:
CSEN <= …
– CS_EN sourced several signals, i.e.,
appeared on the right side
X <= CS_EN…
• Were they intended to be the same
signal?
May 30, 2002
RLB
10
E.g., meaning of names
-- ADDRESS DECODE LOGIC VALUES
IF (ADDRCOUNT >= "000001000") THEN
ADCGE8_I <= '1'; [note name ends in “8” and comparison value is 8]
ELSE
ADCGE8_I <= '0';
END IF;
IF (ADDRCOUNT >= "000000110") THEN
ADCGE6_I <= '1'; [note name ends in “6” and comparison value is 6]
ELSE
ADCGE6_I <= '0';
END IF;
IF (ADDRCOUNT = "000110101" OR LOADAC = '1') THEN
ADCGE36_D <= '1'; [note name ends in “36” but comparison value is 35]
• Lesson: Be careful with your names!
May 30, 2002
RLB
11
VHDL is not WYSIWYG
• Signals intended to be combinational can
end up being sequential, and vice versa
• Sequential circuits can have unexpected,
undesirable SEU behavior
– Paper: “Logic Design Pathology and Space
Flight Electronics”, R. Katz, R. Barto, K.
Erickson, MAPLD 2000
• The designer gives up some control over
the design to unvalidated software
May 30, 2002
RLB
12
VHDL and Bad Design Practices
• VHDL and FPGAs combine to allow
designers to treat design as software
– Especially for FPGAs for which there is no
reprogramming penalty, e.g., Xilinx
• Rather than designing by analysis,
designers simply “try” design concepts
May 30, 2002
RLB
13
E.g., part of a 16 page process
-- V1.02 & V2.2
-- DATA WILL STOP TANSFERING IFF BOTH HOLD AND OUTPUT ENABEL ARE
-- ACTIVE FOR THE SAME PORT
-----
HOLD2 <= ((((HLD2TX_N_Q AND O_EN_Q(2)) OR
(HLDTX_N_Q AND O_EN_Q(1)) OR
(ROFRDY_N_Q AND O_EN_Q(0))) AND
NOT(BYPASS_EN_Q AND (HLDTX_N_Q AND O_EN_Q(1)))));
HOLD1_I <= ((HLDTX_N_Q AND O_EN_Q(1)) OR (ROFRDY_N_Q AND
O_EN_Q(0)));-- V2.2
HOLD2 <= (((((HLD2TX_N_Q AND O_EN_Q(2)) OR
(HLDTX_N_Q AND O_EN_Q(1)) OR
(ROFRDY_N_Q AND O_EN_Q(0))) AND
NOT(BYPASS_EN_Q AND (HLDTX_N_Q AND O_EN_Q(1))))) OR
(((HLD2TX_N_Q AND O_EN_Q(2)) OR (HLDTX_N_Q AND O_EN_Q(1)))
AND (BYPASS_EN_Q AND HLDTX_N_Q AND O_EN_Q(1))));
May 30, 2002
RLB
14
Simplifying
Let:
a=HDL2TX_N_Q and O_EN_Q(2)
b=HLDTX_N_Q and O_EN_Q(1)
c=ROFRDY_N_Q and O_EN_Q(0)
d=BYPASS_EN_Q
Then
HOLD2=(a+b+c)·(d·b)’ + (a+b)·(d·b) = a+b+c.
What happened to d=BYPASS_EN_Q??
May 30, 2002
RLB
15
Lessons
• Don’t just try things, think about what
you’re doing
– Either BYPASS_EN_Q is needed or it’s not –
what’s the requirement of the system?
• Make modules small enough to test via
VHDL simulation, and test them fully.
– If this logic was tested by itself, the error
would have been found.
• It’s on orbit, now
May 30, 2002
RLB
16
Combined Effects of VHDL
Hidden design details
+ Non-WYSIWYG nature
+ Bad design practices
Designer can lose control of design
i.e., the designer loses understanding of
what is in the design, then adds erroneous
circuitry until simulation looks right
May 30, 2002
RLB
17
E.g., found in a VHDL file:
CASE BVALREG3A_Q IS
WHEN "0000" =>
IF (DAVAIL_LCHA_Q = '1' ) THEN
-- ISN'T THIS CONDITION ALWAYS TRUE
-- AT THIS POINT??? PC
• Just how well did the designers
understand the design??
May 30, 2002
RLB
18
Worst Case Result
• A design that works in simulation for
expected conditions, but with flaws that
show up in unusual conditions
• Passed on with little documentation by
engineers who become unavailable
A total programmatic disaster!!
An common occurrence!
May 30, 2002
RLB
19
Solution to VHDL Problem
• Detailed design review
• Make sure designs are reviewable and
transferable
• Don’t use VHDL
May 30, 2002
RLB
20
VHDL Review
Tools and Techniques
May 30, 2002
RLB
21
Netlist Viewer
• Crucial because
– Synthesizer output, not VHDL, is the final
design
– Easy to see asynchronous design items
– Connectivity often more apparent in viewer
than in VHDL
May 30, 2002
RLB
22
.srr files
• Flip-flop replication
• State machine encoding and illegal state
protection
• Inferred clocks
• Resource usage
May 30, 2002
RLB
23
.adb files
• Check timing
• External part timing
• I/O pin options
May 30, 2002
RLB
24
VHDL Simulator
• Simulate modules or extract parts of
modules
• Try to break them:
– Most simulations are success oriented, in that
they try to show the module works when it
gets the expected inputs
– Try to simulate with the unexpected inputs
May 30, 2002
RLB
25
E.g., breaking a FIFO
Here’s the full flag,
but we’ll keep
writing
Here we get the full
flag while reading out
Turned out to be a problem for the
project
May 30, 2002
RLB
26
Most Important Tool:
• Your thought and logical reasoning
• There is no algorithm for design review
• Based on the type of work you have to do
(simple review or reverse engineering),
– Partition the design into simple blocks
– Start with what you understand and move out
– Ask all the questions you need to
– Model and simulate as necessary
May 30, 2002
RLB
27
Suggestions for FPGA Design
Presentation
Goals
• Detailed design review and worst case
analysis are the best tools for ensuring
mission success.
• The goal here is not to make more work
for the designer, but to:
– Enhance efficiency of reviews
– Make proof of design more clear
– Make design more transferable
– Improve design quality
May 30, 2002
RLB
29
Steps to preparing for design
review
1.
2.
3.
4.
5.
6.
7.
8.
9.
Modularize your design
Make a datasheet for each module
Show FPGA design in terms of modules
Describe internal circuitry
Describe state machines
Describe FPGA connections
Describe synthesis results
Provide timing spec for external timing analysis
Show requirements of external circuitry
May 30, 2002
RLB
30
1. Modularize your design
• Easier to do during design phase
• Goal is to describe design in terms of
components that can be individually verified
• Each component, or module, is a separate
VHDL entity
• Modules should be of moderate, e.g., MSI, size
– E.g., FIFO, ALU
– Counter, decoder probably too small
– VME interface too big
May 30, 2002
RLB
31
2. Make a datasheet for each
module
•
•
•
•
•
Describe the module’s behavior
Show truth table
Show timing diagrams of operation
Provide test bench used to verify module
Model: MSI part data sheet
May 30, 2002
RLB
32
3. Show FPGA design in terms of
modules
• Provide requirements spec for FPGA
• Draw block diagram
• Top-level VHDL entity shows FPGA inputs and
outputs and ties component modules together
• Show necessary timing diagrams
– Interaction between modules
– Interaction with external circuitry
• Text for theory of operation
• Provide test bench for FPGA-level VHDL
simulation
May 30, 2002
RLB
33
4. Describe internal circuitry
• Use of clock resources
• Discuss skew issues
• Describe deviations from fully synchronous
design
– Be prepared to show necessary analysis
• Show how asynchronism is handled
– External signals
– Between clock domains
• Glitch analysis of output signals used as clocks
by other parts
May 30, 2002
RLB
34
5. Describe state machines
•
•
•
•
Encoding chosen
Protection against lock-up states
Homing sequences
Reset conditions
May 30, 2002
RLB
35
6. Describe FPGA connections
• Use of special pins: TRST*, MODE, etc.
• Power supply requirements
– Levels, sequencing, etc.
•
•
•
•
•
Termination of unused clock pins
Input and output options chosen for pins
Discuss transition times of inputs
POR operation and circuitry
Critical signals and power-up conditions
– Remember WIRE!
May 30, 2002
RLB
36
7. Describe synthesis results
• Percentage of utilization
• Flip-flop replication and its effects on
reliable operation
• Margin results from Timer
• Timing of circuits using both clock edges
May 30, 2002
RLB
37
8. Provide timing spec for external
timing analysis
• Tsu, Th with respect to clock
• Clock to output Tpd
• Tpw for signals connected to flip-flop
clocks
• Clock symmetry requirements if both
edges of clock used
May 30, 2002
RLB
38
9. Show requirements of external
circuitry
• Provide data sheets for parts interfacing to
FPGA
• Show timing diagrams of interactions of
FPGA to other parts
• Show timing analysis of external circuitry
May 30, 2002
RLB
39
References
• Design guidelines:
http://klabs.org/DEI/References/design_guidelines/nasa_guidelines/index.htm
• Design tutorials
http://klabs.org/richcontent/Tutorial/tutorial.htm
• Design, analysis, and test guidelines:
http://klabs.org/DEI/References/design_guidelines/design_analysis_test_guides.htm
May 30, 2002
RLB
40