Upload
linus
View
27
Download
0
Embed Size (px)
DESCRIPTION
VHDL Design Review And Presentation. Dr. Rod Barto 3312 Moonlight El Paso, Texas 79904 915-755-4744 [email protected] [email protected]. Basic Design Rule. The designer should know and be able to prove: The design meets the spec The design passes a worst case analysis - PowerPoint PPT Presentation
Citation preview
VHDL Design ReviewAnd
Presentation
Dr. Rod Barto3312 Moonlight
El Paso, Texas 79904915-755-4744
[email protected]@att.net
May 30, 2002 RLB 2
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 3
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 4
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 5
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 6
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 7
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 8
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 9
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 10
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 11
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 12
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 13
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 14
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 15
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
ThenHOLD2=(a+b+c)·(d·b)’ + (a+b)·(d·b) = a+b+c.
What happened to d=BYPASS_EN_Q??
May 30, 2002 RLB 16
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 17
Combined Effects of VHDL
Hidden design details
+ Non-WYSIWYG nature
+ Bad design practicesDesigner 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 18
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 19
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 20
Solution to VHDL Problem
• Detailed design review
• Make sure designs are reviewable and transferable
• Don’t use VHDL
May 30, 2002 RLB 21
VHDL Review
Tools and Techniques
May 30, 2002 RLB 22
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 23
.srr files
• Flip-flop replication
• State machine encoding and illegal state protection
• Inferred clocks
• Resource usage
May 30, 2002 RLB 24
.adb files
• Check timing
• External part timing
• I/O pin options
May 30, 2002 RLB 25
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 26
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 27
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
Suggestions for FPGA Design Presentation
May 30, 2002 RLB 29
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 30
Steps to preparing for design review
1. Modularize your design2. Make a datasheet for each module3. Show FPGA design in terms of modules4. Describe internal circuitry5. Describe state machines6. Describe FPGA connections7. Describe synthesis results8. Provide timing spec for external timing analysis9. Show requirements of external circuitry
May 30, 2002 RLB 31
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 32
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 33
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 34
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 35
5. Describe state machines
• Encoding chosen
• Protection against lock-up states
• Homing sequences
• Reset conditions
May 30, 2002 RLB 36
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 37
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 38
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 39
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 40
References
• Design guidelines:http://klabs.org/DEI/References/design_guidelines/nasa_guidelines/index.htm
• Design tutorialshttp://klabs.org/richcontent/Tutorial/tutorial.htm
• Design, analysis, and test guidelines:http://klabs.org/DEI/References/design_guidelines/design_analysis_test_guides.htm