VHDL Design Review And Presentation

1
VHDL Design ReviewAndPresentation

• Dr. Rod Barto
• 3312 Moonlight
• El Paso, Texas 79904
• 915-755-4744
• rbarto_at_klabs.org
• rod.barto_at_att.net

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

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 designers responsibility

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

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.

6
Designers 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?

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?

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

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

10
E.g., a spelling error?

• A VHDL module contained two signals
• CSEN appeared only on the left side of a
  replacement statement
• CSEN lt
• CS_EN sourced several signals, i.e., appeared on
  the right side
• X lt CS_EN
• Were they intended to be the same signal?

11
E.g., meaning of names

• -- ADDRESS DECODE LOGIC VALUES
• IF (ADDRCOUNT gt "000001000") THEN
• ADCGE8_I lt '1' note name ends in 8
  and comparison value is 8
• ELSE
• ADCGE8_I lt '0'
• END IF
• IF (ADDRCOUNT gt "000000110") THEN
• ADCGE6_I lt '1' note name ends in 6
  and comparison value is 6
• ELSE
• ADCGE6_I lt '0'
• END IF
• IF (ADDRCOUNT "000110101" OR LOADAC '1')
  THEN
• ADCGE36_D lt '1' note name ends in 36
  but comparison value is 35
• Lesson Be careful with your names!

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

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

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 lt ((((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 lt ((HLDTX_N_Q AND O_EN_Q(1)) OR
  (ROFRDY_N_Q AND O_EN_Q(0)))-- V2.2
• HOLD2 lt (((((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))))

15
Simplifying

• Let
• aHDL2TX_N_Q and O_EN_Q(2)
• bHLDTX_N_Q and O_EN_Q(1)
• cROFRDY_N_Q and O_EN_Q(0)
• dBYPASS_EN_Q
• Then
• HOLD2(abc)(db) (ab)(db) abc.
• What happened to dBYPASS_EN_Q??

16
Lessons

• Dont just try things, think about what youre
  doing
• Either BYPASS_EN_Q is needed or its not whats
  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.
• Its on orbit, now

17
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

18
E.g., found in a VHDL file

• CASE BVALREG3A_Q IS
• WHEN "0000" gt
• 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??

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!

20
Solution to VHDL Problem

• Detailed design review
• Make sure designs are reviewable and transferable
• Dont use VHDL

21

• VHDL Review
• Tools and Techniques

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

23
.srr files

• Flip-flop replication
• State machine encoding and illegal state
  protection
• Inferred clocks
• Resource usage

24
.adb files

• Check timing
• External part timing
• I/O pin options

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

26
E.g., breaking a FIFO
Heres the full flag, but well keep writing
Here we get the full flag while reading out
Turned out to be a problem for the project
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

28
Suggestions for FPGA Design Presentation
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

30
Steps to preparing for design review

• 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

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

32
2. Make a datasheet for each module

• Describe the modules behavior
• Show truth table
• Show timing diagrams of operation
• Provide test bench used to verify module
• Model MSI part data sheet

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

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

35
5. Describe state machines

• Encoding chosen
• Protection against lock-up states
• Homing sequences
• Reset conditions

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!

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

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

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

40
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