eecs 150 components and design techniques for digital systems lec 13 project overview
Download
Skip this Video
Download Presentation
EECS 150 - Components and Design Techniques for Digital Systems Lec 13 – Project Overview

Loading in 2 Seconds...

play fullscreen
1 / 38

EECS 150 - Components and Design Techniques for Digital Systems Lec 13 – Project Overview - PowerPoint PPT Presentation


  • 279 Views
  • Uploaded on

EECS 150 - Components and Design Techniques for Digital Systems Lec 13 – Project Overview David Culler Electrical Engineering and Computer Sciences University of California, Berkeley http://www.eecs.berkeley.edu/~culler http://www-inst.eecs.berkeley.edu/~cs150 You Are Here

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'EECS 150 - Components and Design Techniques for Digital Systems Lec 13 – Project Overview' - andrew


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
eecs 150 components and design techniques for digital systems lec 13 project overview

EECS 150 - Components and Design Techniques for Digital Systems Lec 13 – Project Overview

David Culler

Electrical Engineering and Computer Sciences

University of California, Berkeley

http://www.eecs.berkeley.edu/~culler

http://www-inst.eecs.berkeley.edu/~cs150

traversing digital design
You Are Here

EECS150 wks 6 - 15

EECS150 wks 1-6

Traversing Digital Design

CS61C

EE 40

EECS 150, Fa04, Lec 13-Project

caveats
Caveats
  • Today’s lecture provides an overview of the project.
  • Lab will cover it in MUCH more detail.
  • Where there are differences, the lab information is correct!
  • Names of many components are different from what is used in lab, so you won’t be confused…

EECS 150, Fa04, Lec 13-Project

basic pong game
17

9

Basic Pong Game
  • Court = set of obstacles
    • fixed position
  • Paddle = moving obstacle
    • Position & vertical velocity
    • Function of joystick
    • P’ = f ( P, j )
  • Ball
    • 2D position & velocity
    • [ spin, acc ]
    • Bounces off walls and paddles
    • B’ = f ( B, j ,C )
  • Score
    • Ball hitting sides
  • Effects
    • Display, audio, …

composite video

player-0

input

player-1

input

EECS 150, Fa04, Lec 13-Project

calinx board
Video & AudioPorts

Four 100 Mb Ethernet Ports

AC ’97 Codec & Power Amp

Video Encoder & Decoder

8 Meg x 32

SDRAM

Flash Card & Micro-drive Port

Quad Ethernet Transceiver

Prototype Area

Xilinx

Virtex 2000E

Seven Segment LEDDisplays

Calinx Board

EECS 150, Fa04, Lec 13-Project

add on card
Add-on card

EECS 150, Fa04, Lec 13-Project

project design problem
17

9

Project Design Problem

Map this application

To this technology

EECS 150, Fa04, Lec 13-Project

input output constraints
17

9

Input-Output Constraints
  • Ball moves within a court
  • Players control movement of the paddles with joysticks
  • Observe game as rendered on video display
  • Bounces off walls and paddles till point is scored
  • I/O devices provide design constraints

composite video

ADV7194

8

ITU 601/656

FPGA

player-0

input

player-1

input

N64 controller interface

LCD

LEDS

switches

EECS 150, Fa04, Lec 13-Project

input output support
9

17

Input/Output Support
  • Digitize and abstract messy analog input
  • Rendering pipeline to translate display objects into byte stream
  • Off-chip device to translate digital byte stream into composite video

composite video

ADV7194

8

ITU 601/656

FPGA

Video Stream

Render Engine

Game

Physics

Joystick

Interface

player-1

input

player-0

input

N64 controller interface

EECS 150, Fa04, Lec 13-Project

physics of the game
17

9

?

“Physics” of the Game
  • Court = set of obstacles
    • fixed position
  • Paddle = moving obstacle
    • Position & vertical velocity
    • Function of joystick
    • P’ = f ( P, j )
  • Ball
    • 2D position & velocity
    • [ spin, acc ]
    • Bounces off walls and paddles
    • B’ = f ( B, j ,C )
  • Score
    • Ball hitting sides
  • Effects
    • Display, audio, …

composite video

ADV7194

8

ITU 601/656

FPGA

Video Stream

Render Engine

Game

Physics

Joystick

Interface

player-1

input

player-0

input

N64 controller interface

EECS 150, Fa04, Lec 13-Project

representing state
composite video

ADV7194

9

17

8

ITU 601/656

FPGA

Video Stream

SDRAM

Control

Render Engine

SDRAM

Control

frame

Data

player-1 input

32

Game

Physics

player-0

input

Joystick

Interface

N64 controller interface

board

state

Representing state
  • State of the game
    • Court obstacles
    • Paddles
    • Ball
    • Score
  • Additional data
    • Display blocks
      • Paddle & ball image
    • Numerals
    • Frame buffer
  • SDRAM holds frame buffer
    • Rendered to frame buffer
    • Spooled to video encoder
  • SDRAM has sophisticated interface
    • Grok Data sheet, design bus controller
  • FPGA block RAM holds board
    • also Registers, Counters, …
    • Timing sequence, Controller state
    • FIFOs, Packet buffers

EECS 150, Fa04, Lec 13-Project

n64 interface cp 1
9

17

N64 controller interface

8

velocity

pause

start

DQ

reset

clock (27 MHz)

N64 Interface (cp 1)
  • Continually poll N64 and report state of buttons and analog joystick
    • Issue 8-bit command
    • Receive 32-bit response
  • Each button response is 32 bit value containing button state and 8-bit signed horizontal and vertical velocities
  • Serial interface protocol
    • Multiple cycles to perform each transaction
  • Bits obtained serially
    • Framing (packet start/stop)
    • Bit encoding
      • start | data | data | stop

composite video

ADV7194

8

ITU 601/656

FPGA

Video stream

SDRAM

Control

Render Engine

SDRAM

Control

board

state

Data

player-1 input

32

Game

Physics

player-0

input

Joystick

Interface

EECS 150, Fa04, Lec 13-Project

video encoder cp 2
9

17

Video Encoder (cp 2)
  • Rendering engine processes display objects into frame buffer
    • Renders rectangles, image blocks, …
  • Drive ADV7194 video encoder device so that it outputs the correct NTSC
  • Gain experience reading data sheets
  • Dictates the 27 MHz operation rate
    • Used throughout graphics subsystem

composite video

ADV7194

8

ITU 601/656

FPGA

Video Stream

SDRAM

Control

Render Engine

SDRAM

Control

board

state

Data

player-1 input

32

Game

Physics

player-0

input

Joystick

Interface

N64 controller interface

EECS 150, Fa04, Lec 13-Project

announcements
Announcements
  • Midterm will be returned in section
  • Solutions available on-line
  • Reading:
    • Video In a Nutshell (by Tom Oberheim) on class web page
    • Lab project documents (as assigned)

EECS 150, Fa04, Lec 13-Project

digital video basics a little detour
Digital Video Basics – a little detour
  • Pixel Array:
    • A digital image is represented by a matrix of values where each value is a function of the information surrounding the corresponding point in the image. A single element in an image matrix is a picture element, or pixel. A pixel includes info for all color components.
    • The array size varies for different applications and costs. Some common sizes shown to the right.
  • Frames:
    • The illusion of motion is created

by successively flashing still

pictures called frames.

EECS 150, Fa04, Lec 13-Project

refresh rates scaning
The human perceptual system can be fooled into seeing continuous motion by flashing frames at a rate of around 20 frames/sec or higher.

Much lower and the movement looks jerky and flickers. TV in the US uses 30 frames/second (originally derived from the 60Hz line current frequency).

Images are generated on the screen of the display device by “drawing” or scanning each line of the image one after another, usually from top to bottom.

Early display devices (CRTs) required time to get from the end of a scan line to the beginning of the next. Therefore each line of video consists of an active video portion and a horizontal blanking interval portion.

A vertical blanking interval corresponds to the time to return from the bottom to the top.

In addition to the active (visible) lines of video, each frame includes a number of non-visible lines in the vertical blanking interval.

The vertical blanking interval is used these days to send additional information such as closed captions and stock reports.

Refresh Rates & Scaning

EECS 150, Fa04, Lec 13-Project

interlaced scanning
Early inventers of TV discovered that they could reduce the flicker effect by increasing the flash-rate without increasing the frame-rate.

Interlaced scanning forms a complete picture, the frame, from two fields, each comprising half the scan lines. The second field is delayed half the frame time from the first.

Non-interlaced displays are call progressive scan.

Interlaced Scanning
  • The first field, odd field, displays the odd scan lines, the second, even field, displays the even scan lines.

EECS 150, Fa04, Lec 13-Project

pixel components
A natural way to represent the information at each pixel is with the brightness of each of the primary color components: red, green and blue (RBG).

In the digital domain we could transmit one number for each of red, green, and blue intensity.

Engineers had to deal with issue when transitioning from black and white TV to color. The signal for black and white TV contains the overall pixel brightness (a combination of all color components).

Rather than adding three new signals for color TV, they decided to encode the color information in two extra signals to be used in conjunction with the B/W signal for color receivers and could be ignored for the older B/W sets.

The color signals (components) are color differences, defined as:

Y-B and Y-R, where Y is the brightness signal (component).

In the digital domain the three components are called:

Y luma, overall brightness

CBchroma, Y-B

CR chroma,Y-R

Note that it is possible to reconstruct the RGB representation if needed.

One reason this representation survives today is that the human visual perceptual system is less sensitive to spatial information in chrominance than it is in luminance. Therefore chroma components are usually subsampled with respect to luma component.

Pixel Components

EECS 150, Fa04, Lec 13-Project

chroma subsampling
Chroma Subsampling
  • Variations include subsampling horizontally, both vertically and horizontally.
  • Chroma samples are coincident with alternate luma samples or are sited halfway between alternate luna samples.

EECS 150, Fa04, Lec 13-Project

common interchange format cif
Common Interchange Format (CIF)

Developed for low to medium quality applications. Teleconferencing, etc.

Variations:

QCIF, 4CIF, 16CIF

Examples of

component streaming:

line i: Y CR Y Y CR Y Y…

line i+1: Y CB Y Y CB Y Y…

Alternate (different packet types):

line i: Y CR Y CB Y CR Y CB Y …

line i+1: Y Y Y Y Y …

Bits/pixel:

6 components / 4 pixels

48/4 = 12 bits/pixel

Common Interchange Format (CIF)

Example 1: commonly used as output of MPEG-1 decoders.

EECS 150, Fa04, Lec 13-Project

itu r bt 601 format
Formerly, CCIR-601. Designed for digitizing broadcast NTSC (national television system committee) signals.

Variations:

4:2:0

PAL (European) version

Component streaming:

line i: Y CB Y CR Y CB Y CR Y …

line i+1: Y CB Y CR Y CB Y CR Y …

Bits/pixel:

4 components / 2 pixels

40/2 = 20 bits/pixel

ITU-R BT.601 Format

The Calinx board video encoder supports this format.

EECS 150, Fa04, Lec 13-Project

calinx video encoder
Analog Devices ADV7194

Supports:

Multiple input formats and outputs

Operational modes, slave/master

VidFX project will use default mode:

ITU-601 as slave

s-video output

Digital input side connected to Virtex pins.

Analog output side wired to on board connectors or headers.

I2C interface for initialization:

Wired to Virtex.

Calinx Video Encoder

EECS 150, Fa04, Lec 13-Project

itu r bt 656 details
Interfacing details for ITU-601.

Pixels per line 858

Lines per frame 525

Frames/sec 29.97

Pixels/sec 13.5 M

Viewable pixels/line 720

Viewable lines/frame 487

With 4:2:2 chroma sub-sampling need to send 2 words/pixel (1 Y and 1 C).

words/sec = 27M,

Therefore encoder runs off a 27MHz clock.

Control information (horizontal and vertical synch) is multiplexed on the data lines.

Encoder data stream show to right:

ITU-R BT.656 Details

EECS 150, Fa04, Lec 13-Project

itu r bt 656 details24
Control is provided through “End of Video” (EAV) and “Start of Video” (SAV) timing references.

Each reference is a block of four words: FF, 00, 00,

The word encodes the following bits:

F = field select (even or odd)

V = indicates vertical blanking

H = 1 if EAV else 0 for SAV

Horizontal blanking section consists of repeating pattern

80 10 80 10 …

ITU-R BT.656 Details

EECS 150, Fa04, Lec 13-Project

calinx video decoder not this term
Analog Devices ADV7185

Takes NTSC (or PAL) video signal on analog side and outputs ITU601/ITU656 on digital side.

Many modes and features not use by us.

VidFX project will use default mode:

no initialization needed.

Generates 27MHz clock synchronized to the output data.

Digital input side connected to Virtex pins.

Analog output side wired to on board connectors or headers. Camera connection through “composite video”.

Calinx Video Decoder (not this term)

analog

side

digital

side

EECS 150, Fa04, Lec 13-Project

sdram interface cp 3
composite video

ADV7194

9

17

8

ITU 601/656

FPGA

Video Stream

SDRAM

Control

Render Engine

SDRAM

Control

frame

Data

player-1 input

32

Game

Physics

player-0

input

Joystick

Interface

N64 controller interface

board

state

SDRAM interface (cp 3)
  • Memory protocols
    • Bus arbitration
    • Address phase
    • Data phase
  • DRAM is large, but few address lines and slow
    • Row & col address
    • Wait states
  • Synchronous DRAM provides fast synchronous access current block
    • Little like a cache in the DRAM
    • Fast burst of data
  • Arbitration for shared resource

EECS 150, Fa04, Lec 13-Project

sdram read burst timing for later
SDRAM READ burst timing (for later)

EECS 150, Fa04, Lec 13-Project

rendering engine
9

17

Rendering Engine
  • Fed series of display objects
    • Obstacles, paddles, ball
    • Each defined by bounding box
      • Top, bottom, left, right
  • Renders object into frame buffer within that box
    • Bitblt color for rectangles
    • Copy pixel image
  • Must arbitrate for SDRAM and carry out bus protocol

composite video

ADV7194

8

ITU 601/656

FPGA

Video Enc. i/f

SDRAM

Control

Render Engine

SDRAM

Control

Data

player-1 input

32

board

state

Game

Physics

player-0

input

Joystick

Interface

N64 controller interface

EECS 150, Fa04, Lec 13-Project

game physics
9

17

board

state

Game Physics
  • Divide time into two major phases
    • Render
    • Compute new board
  • Compute phase is divided into 255 ticks
  • Each tick is small enough that paddles and board can only move a small amount
    • Makes fixed point arithmetic each
    • New paddle pos/vel based on old pos/vel and joystick velocity
    • New ball is based on old ball pos/vel and all collisions
    • Stream all obstacles and paddles by the ball next state logic to determine bounce

composite video

ADV7194

8

ITU 601/656

FPGA

Video Encode

SDRAM

Control

Render Engine

SDRAM

Control

Data

player-1 input

32

Game

Physics

player-0

input

Joystick

Interface

N64 controller interface

More when we look at arithmetic

EECS 150, Fa04, Lec 13-Project

network multiplayer game
9

9

17

17

Network Multiplayer Game

composite video

composite video

ADV7194

ADV7194

FPGA

FPGA

SDRAM

SDRAM

Control

Control

Data

Data

32

32

board

state

board

state

network

EECS 150, Fa04, Lec 13-Project

rendezvous mode of operation
Rendezvous & mode of operation
  • Player with host device publishes channel and ID
    • Write it on the white board
  • Set dip switches to select channel
  • Start game as host
    • Wait for guest attach
  • Start game as guest
    • Send out attach request
  • Host compute all the game physics
    • Local joystick and remote network joystick as inputs
      • Receive Joystick movement packets and xlate to equivalent of local
    • Determines new ball and paddle position
      • Transmits court update packets
    • Network remote device must have fair service
  • Both devices render display locally

EECS 150, Fa04, Lec 13-Project

host device player 0
Board

encoder

CC2420

Joystick

decoder

Host Device (player 0)

composite video

ADV7194

8

ITU 601/656

Video Stream

SPI

SDRAM

Render Engine

Control

Network Interface

controller

SDRAM

Control

Data

32

board

state

Game

Physics

Joystick

Interface

player-1

input

player-0

input

N64 controller interface

EECS 150, Fa04, Lec 13-Project

guest device player 1
CC2420

Joystick

Encoder

Guest Device (player 1)

composite video

ADV7194

8

ITU 601/656

Video Stream

SPI

SDRAM

Render Engine

Control

Network Interface

controller

SDRAM

Control

Data

32

board

state

Board

decoder

Joystick interface

player-1

input

N64 controller interface

EECS 150, Fa04, Lec 13-Project

protocol stacks
Usual case is that MAC protocol encapsulates IP (internet protocol) which in turn encapsulates TCP (transport control protocol) with in turn encapsulates the application layer. Each layer adds its own headers.

Other protocols exist for other network services (ex: printers).

When the reliability features (retransmission) of TCP are not needed, UDP/IP is used. Gaming and other applications where reliability is provided at the application layer.

MAC

MAC

IP

IP

TCP

UDP

application layer

ex: http

Streaming

Ex. Mpeg4

Protocol Stacks

Layer 2

Layer 3

Layer 4

Layer 5

Layer 2

Layer 3

Layer 4

Layer 5

EECS 150, Fa04, Lec 13-Project

standard hardware network interface
Usually divided into three hardware blocks. (Application level processing could be either hardware or software.)

MAG. “Magnetics” chip is a transformer for providing electrical isolation.

PHY. Provides serial/parallel and parallel/serial conversion and encodes bit-stream for Ethernet signaling convention. Drives/receives analog signals to/from MAG. Recovers clock signal from data input.

MAC. Media access layer processing. Processes Ethernet frames: preambles, headers, computes CRC to detect errors on receiving and to complete packet for transmission. Buffers (stores) data for/from application level.

Application level interface

Could be a standard bus (ex: PCI)

or designed specifically for application level hardware.

MII is an industry standard for connection PHY to MAC.

Standard Hardware-Network-Interface

application level interface

MAC

(MAC layer processing)

PHY

(Ethernet signal)

MAG

(transformer)

Ethernet connection

Media Independent Interface (MII)

Calinx has no MAC chip, must

be handled in FPGA.

You have met ethernet. IEEE 802.15.4 will look similar…yet different

EECS 150, Fa04, Lec 13-Project

802 15 4 frames
802.15.4 Frames

EECS 150, Fa04, Lec 13-Project

packet protocols
Packet protocols
  • Framing definitions
    • IEEE 802.15.4
  • Packet formats
    • Request game
    • Joystick packet
    • Board Packet

EECS 150, Fa04, Lec 13-Project

schedule of checkpoints
Schedule of checkpoints
  • CP1: N64 interface (this week)
  • CP2: Digital video encoder (week 8)
  • CP3: SDRAM controller (two parts, week 9-10)
  • CP4: IEEE 802.15.4 (cc2420) interface (wk 11-12)
    • unless we bail out to ethernet
    • Overlaps with midterm II
  • Project CP: game engine (wk 13-14)
  • Endgame
    • 11/29 early checkoff
    • 12/6 final checkoff
    • 12/10 project report due
    • 12/15 midterm III

EECS 150, Fa04, Lec 13-Project

ad