Download presentation

Presentation is loading. Please wait.

Published byYolanda Calvery Modified about 1 year ago

1
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 1 A Game of Othello zOthello: popular board game (often known as Reversi) z8x8 board, black and white tokens zToday, we will use it as a design example

2
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 2 Othello: Rules and Game Play zThe object of the game is to have the majority of your colour discs on the board at the end of the game zRules yBlack places two black discs and White places two white discs as shown in here. The game always begins with this setup. yA move consists of "outflanking" your opponent's disc(s), then flipping the outflanked disc(s) to your colour. yTo outflank means to place a disc on the board so that your opponent's row (or rows) of disc(s) is bordered at each end by a disc of your colour. (A "row" may be made up of one or more discs). yHere's one example: White disc A was already in place on the board. The placement of white disc B outflanks the row of three black discs.

3
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 3 Outflanking Example White disc A was already in place on the board. The placement of white disc B outflanks the row of three black discs. White flips the outflanked discs and now the row looks like this:

4
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 4 Rules zBlack always moves first. zIf on your turn you cannot outflank and flip at least one opposing disc, your turn is forfeited and your opponent moves again. However, if a move is available to you, you may not forfeit your turn. zA disc may outflank any number of discs in one or more rows in any number of directions at the same time - horizontally, vertically or diagonally. zYou may not skip over your own color disc to outflank an opposing disc.

5
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 5 Rules zDiscs may only be outflanked as a direct result of a move and must fall in the direct line of the disc placed down. zAll discs outflanked in any one move must be flipped, even if it is to the player's advantage not to flip them at all. zOnce a disc is placed on a square, it can never be moved to another square later in the game.

6
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 6 Rules zWhen it is no longer possible for either player to move, the game is over. Discs are counted and the player with the majority of his or her colour discs on the board is the winner.

7
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 7 Our Design Problem zDesign an Othello Board and Gamekeeper. zThe gamekeeper will yKeep track of the score and state of the board yIndicate whose move it is yIndicate where legal moves can be made yAccept and make a legal move xFlip all the discs who have been outflanked zFocus of today’s lecture yGame engine and logic alone yWe will assume xDisplay device for an 8x8 board xInput device which tells us where to move on an 8x8 board

8
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 8 Global Picture of Our System Circuit in Each Square to: 1.Keep State of the Square 2.Compute whether move in square is legal Game Controller 1.Global Game State 2.Orchestrates individual move logic

9
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 9 Game Controller State Machine Flip Current Color Legal Move? Enable Move Update Board Flip Current Color Legal Move? Game Over Current Color = White Y N Y N Move selected’ Move selected

10
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 10 Square FSM zBasic Functions yStore state of square (Empty, White, Black) yReport when move is legal yReport when user moves into square yUpdate state of square in response to a move Square Current Color Move Enabled Legal Move Move Selected

11
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 11 Square Finite State Machine

12
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 12 What’s a Legal Move? zDecided in each square zSquare state must be empty z“Run” of colors yStraight line of squares of one color bordered by a square of the other color xWhite run: line of white squares terminated by black square xBlack run: line of black squares terminated by white square xCurrent run: line of squares of current color terminated by square of other color zLegal move ySquare is empty and neighbor square is part of current run

13
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 13 Key Consideration for Cell zIs it on a “run” in any direction? yOriginates a white (black) run: xCell is white (black); and xNeighbor in direction is black (white); yContinues a white (black) run xCell is white (black); and xNeighbor in direction continues or originates a white (black) run zMove to a square is legal if and only if yCurrent Mover is white (black) yCurrent State is empty ySome neighbor continues or orginates a black (white) run

14
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 14 Originating and Continuing a Run Begins a white run Continues a white run Begins a black run

15
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 15 Legal Moves Legal to move black Legal to move white How do we build a circuit to pick this up?

16
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 16 Two Functions Per Color and direction zRemote yBlack: this square is white yall the squares in some direction are white until we hit a black yReverse black/white for Remote White zRemoteOrLocal yBlack: this square is black OR remoteBlack is true for this square zNote that if a square is empty both remote and remoteOrLocal are false.

17
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 17 Originating and Continuing a Run remoteOrLocalWhite (all directions) remoteOrLocalBlackWest remoteBlackWest remoteOrLocalWhite (all directions) remoteOrLocalBlackWest remoteBlackWest remoteWhiteEast remoteOrLocalBlack (all directions) remoteOrLocalBlack East

18
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 18 Cell circuit picture

19
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 19 RemoteBlack (Continue White Run) White run from SE White run to NW

20
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 20 RemoteOrLocal black (on white run or neighbor can start white run)

21
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 21 Cell circuit picture On each link: 2 wires in 4 wires out

22
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 22 Legal Move zMove to a square is legal if and only if yCurrent Mover is white (black) yCurrent State is empty ySome neighbor continues or orginates a black (white) run zTranslate into our circuit yCurrent Mover is white (black) yCurrent State is empty yFor some direction: neighbor’s remoteWhite (black)

23
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 23 Computation of Legal Computation from one direction Replicate here from each neighbor

24
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 24 What’s the delay? zWorst case is on edge or corner yAt most 7 AND or OR gates on remote chain yComputation of legal is ~6 gates (figure 3 gate delays for 8- input OR) yTotal delay is 13 gates zNote (Synchronous Mealy) we want to latch the output of legal! zWhat about the edges and corners? More later…

25
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 25 How much logic in a cell? z8x2 AND gates for remote = 16 z8x2 OR gates for localOrRemote = 16 z3 gates for leaf of legal computation (8 leaves), so 8x3 = 24 z7 OR gates + 1 AND gate for rest of legal computation zTotal 64 gates/cell (so far) zAlso need at least 2 latches for color + one for legal zMore logic to come

26
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 26 Doing The Move zThis is easy yOne external select (keyed by button or multiplexer from joystick – not our problem today) ySelect & legal (previously computed) zStill have to flip…

27
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 27 Flipping Move Flip How can we build a flip function?

28
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 28 Flipping Move = black Square selected RemoteBlackNorth = True RemoteBlackEast = True

29
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 29 Key zMover sends out a flip signal, with color and direction, to each neighbor y8x2 wires zFlip black if yFlip black signal from one direction (SE); and yColor is white; and yremoteBlack is true in other direction (NW) yFlipBlackNW = [FlipBlackFromSE AND Color=white AND RemoteBlackNW ySend FlipBlackNW out to NW neighbor yOR all FlipBackDirections to get Direction

30
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 30 Flip Calculation

31
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 31 Computation of Next Cell State

32
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 32 Cell circuit picture On each link: 4 wires in 6 wires out

33
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 33 Gate Delay Calculation for Clip z7x2 gates to propagate = 14 gate delays zBut need to consider the remote chain! yAdds another 7 delays (from slide 24) z3 gate delays through 8-way OR + 1 gate delay to comput next state zWorst-case is 25 gate delays zCan reduce to 18 by latching remote signals computed in legal-move phase

34
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 34 How Many Gates z2 gates/direction-color x 2 colors x 8 directions = 32 gates z2 gates for current move (one black, one white) z8 gates/color for upper end of next-state tree = 16 zTotal 50 gates zAdd to 64 from slide 25 zTotal 114 gates/cell z64 cells = 7296 gates for design zBut what about the corners and edges?

35
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 35 Two choices zCell design assumes neighbors in all directions yNote true at edges and corners zOne: special-case cells on the edge yNow have 9 different types of cell! x 1/49 cells in center of board (type 1) – cell we’ve designed x4/7 cells each on each edge (types 2-5) x4/7 cells each for each corner (types 6-9) yNote each specialty type is simpler than general case, but… y9 cell types to design! zTwo: Surround the board with shadow squares yLess efficient, but much simpler

36
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 36 Revised Board Shadow Cells Normal Cells we’ve designed

37
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 37 Shadow Cells zAlways empty (no next-state logic) zCan’t be selected zlocalOrRemote, local = false for all colors and directions zJust a small collection of 6 wires connected to ground zKey advantage: only two cell types, one trivial zDisadvantage: lose a little efficiency from specialization of edge, corner cells yAlways worth it! Let a synthesizer optimize away the constants

38
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 38 Timing Diagram for Each Move

39
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 39 Logic for controller

40
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 40 Game Control Logic

41
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 41 Key Steps to Making the Design Work zSoftware implementation first! yI did it in Smalltalk zTastes Differ, but… yOO programming model tends to fit circuits well yMap each object onto a circuit xVariables tend to map to latches xFunctions tend to map to logic circuits zUnit test, unit test, unit test! yDesign test circuits for each component ySynthesize test circuits as part of the design zAudit, audit, audit! yPin out internal state where possible yE.g., Legal should be displayed visually

42
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 42 Timing Bugs zNastiest, hardest to catch zTwo common examples: Read-Before-Wirte and Write-Before-Read zRead-Before-Write yReader reads sequential value before writer has updated it yActs on old value yE.G. no legal move but controller sees legal move from previous value zWrite-Before-Read yWriter writes before old value has been acted on yReader doesn’t act on value

43
CS 150 – Spring 2008 – Lec #22: Othello Design Example - 43 Two Solution zDirty/Clean bits yWriter sets dirty bit, reader cleans it when read yWriter checks dirty bits clean before writing, reader checks set before reading yError raised if condition not met zFIFO Queues yWriter writes, reader reads yDecouples send/receive asymmetries by a cycle or so yCan become event-driven: Reader only reads when new value yStill have to check overflow, etc yAutomatically implemented in V++

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google