1 / 29

Phase 2 -- Logic Implementation & Simulation

Phase 2 -- Logic Implementation & Simulation. Switching & Logic Design Project. Overview. Logic Implementation Translation of Controller to VHDL Translation of Dataflow to BDF Simulation Controller Dataflow Controller/Dataflow together. Rule 3 of Design.

dagmar
Télécharger la présentation

Phase 2 -- Logic Implementation & Simulation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Phase 2 -- Logic Implementation & Simulation Switching & Logic Design Project

  2. Overview • Logic Implementation • Translation of Controller to VHDL • Translation of Dataflow to BDF • Simulation • Controller • Dataflow • Controller/Dataflow together

  3. Rule 3 of Design • All designs must have a controller! • And it must be a non-trivial controller (3 or more states). • No excepts permitted.

  4. Translation of Controller to VHDL • State Assignments • Compact NFLIP-FLOP=Log10NumState/Log102 • One-Hot NFLIP-FLOP= NumStates • Add comments w/ Title, Group, Date, & Description • Use enumerated and state names (see handout) • Use CASE statement with embedded IF statements • Use Moore Outputs

  5. Translation of Controller to VHDL • Use a single process design • Place Wait-UNTIL or IF statement with clock at top of process • WAIT UNTIL (clk’event AND clk = ‘1’); • IF(clk’event AND clk = ‘1’) THEN …. END IF;

  6. Warning! • Every IF statement must have an ELSE statement even if there are ELSIF statements. • It is better to specify controller outputs using the conditional assignment statement, then a CASE statement in a process. • Do not write statements that lead to implied latches. That is, make sure that values for all outputs are specified at all times so VHDL does not assume that the present output is the previous output.

  7. Warning! • Remember that the VHDL programs the logic gates in the MAX part that is running in parallel or concurrent. • All signals that are read in a process have to be listed in the sensitivity list, except for the "clock"-process, that is used for implementing registers. In this case, the inputs for the registers should be omitted. • Use parentheses in complex expressions in order to avoid ambiguities.

  8. Warning! • Use one processes for a state machine. • Put outputs in conditional assignment statements. • All synchronous components must use the same global clock. No ripple clocks allowed. • Every VHDL module must have a header specifying title, designers, date, and short description.

  9. Warning! • Don’t assign initial values to signals and variables. • All warnings are bad and good designs have no warnings present.

  10. Add comments --Title: Blackjack Controller --Designer: Dr. James Grover --Date: April 2006 --Description: Controller for Blackjack game. This design --example was based on C.R. Clare's design in Designing Logic --Systems Using State Machines (McGraw Hill, 1972). The blackjack --machine plays the dealer's hand, using typical dealer strategies --to decide whether to draw another card (hit) or stand after --each round. -- --The example contains the following logic designs: -- 1. A State Machine that controls the game logic which include: -- (a) checking the status of the card reader. -- (c) making the decision of what action to take for a hit, -- stand or bust. An example is to draw a card if the -- hit signal is true. -- (b) making the decision of when to use the value 1 or 11 -- for an ace card. . . . . -- adds the value of the drawn card. -- 3. A Binary-to-BCD converter for converting the 5-bit -- binary score and converts it to 2-digit BCD for the -- digital display.

  11. State as Enumerated Types ARCHITECTURE Behavioral OF Controller IS TYPE STATE_TYPE IS (sClear,sShowHit,…) SIGNAL State : STATE_TYPE; SIGNAL Ace, NextAce : BIT; BEGIN

  12. Use Case statements with If Statements FSMLOGIC: PROCESS (Reset,CardIn,IsAce,Ace,CardOut,Hit,Bust,State) BEGIN WAIT UNTIL (CLK’EVENT AND CLK = ‘1’); CASE State IS WHEN sClear => --Reset State NextAce <= '0'; IF Reset = '1' THEN State <= sClear; ELSE State <= sShowHit; END IF; . . . . . END CASE; END PROCESS FSMLOGIC;

  13. Moore Outputs OUTPUT02: WITH State SELECT Sel <= "11" WHEN AddCard, "10" WHEN Add10, "01" WHEN Sub10, "00" WHEN OTHERS;

  14. Dataflow With Title

  15. Random Logic ENTITY Bin2BCD IS PORT ( Tally : IN INTEGER Range 0 to 31; MSD,LSD : OUT BIT_VECTOR(3 DOWNTO 0)); END Bin2BCD;

  16. Random Logic ARCHITECTURE behavioral OF Bin2BCD IS BEGIN Combo01: WITH Tally SELECT LSD <= "0000" WHEN 0, "0001" WHEN 1, "0010" WHEN 2, "0011" WHEN 3, . . . . . "0001" WHEN 31; . . . . . . END Behavioral;

  17. Registers and Adder Tally

  18. Combinational Logic & Display Tally

  19. Dataflow/Controller

  20. Cascade Counters • Use Cnt Enable nor Clk Enable • Use common clock • Use SCLR (synchronous clear)

  21. Cooking Timer • Consider • LPM_COUNTER • LPM_DECODE • LPM_MUX • Hex7Seg • Random Logic

  22. UART (Rx) • LPM_SHIFTREG • LPM_COUNTER • LPM_XOR (for parity if included) • Random Logic

  23. RC Servo and Stepper Motor • LPM_COUNTER • LPM_COMPARE • LPM_CONSTANT • LPM_FF for register • Random Logic • LPM_ADD_SUB for RC Servo

  24. 3-Man Rush • LPM_COUNTER (binary or modulo counter) • LPM_SHIFTREG for PRSG (shift register) • LPM_CLSHIFT (barrel shifter) • Random Logic • Hex7Seg

  25. Thermometer • LPM_REG to hold data between Reads • Configure counter as decade or BCD counters BCD

  26. Simulation • Simulate scenario that leads to success • Simulate scenario that leads to fault condition (non success) • Simulate scenario suggested by laboratory assistant or instructor • Simulate and verify simulation

  27. Problems in the past • Timer without state diagram • Digit select on timer display stopped in some states • Did not use three folder/project design • One folder & project for controller • One folder & project for dataflow • One folder & project for dataflow & controller combination

  28. Problems in the past • Did not include LPMs in project • Each counter with different modulo requires new LPM_COUNTER not just new instance of LPM_COUNTER. • Not using common clock causes ripple counter glitches in logic

  29. Implementation Weeks

More Related