VHDL Design Review And Presentation

1. VHDL Design ReviewAndPresentation Dr. Rod Barto 3312 Moonlight El Paso, Texas 79904 915-755-4744 rbarto@klabs.org rod.barto@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 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 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 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. 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? 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? 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 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 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? 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! 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 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 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)))); 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 Then HOLD2=(a+b+c)·(d·b)’ + (a+b)·(d·b) = a+b+c. What happened to d=BYPASS_EN_Q?? 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 RLB

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 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?? 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! RLB

20. Solution to VHDL Problem • Detailed design review • Make sure designs are reviewable and transferable • Don’t use VHDL RLB

21. VHDL Review Tools and Techniques 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 RLB

23. .srr files • Flip-flop replication • State machine encoding and illegal state protection • Inferred clocks • Resource usage RLB

24. .adb files • Check timing • External part timing • I/O pin options 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 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 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 RLB

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 RLB

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 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 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 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 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 RLB

35. 5. Describe state machines • Encoding chosen • Protection against lock-up states • Homing sequences • Reset conditions 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! 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 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 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 RLB

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 RLB