DOC PREVIEW
Berkeley COMPSCI 150 - Digital Interface Design

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

111/18/2008 EECS150 Lecture #23 1Digital Interface DesignEECS150 Fall 2008 – Lecture #23Greg GibelingSlides adapted from everywhere11/18/2008 EECS150 Lecture #23 2Motivation Any useful system includes at least two interfaces: input and output In a computer: keyboard & screen In your project: audio & video The most difficult work in any system is matching incompatible interfaces Compare CS70 and CS61B Compare K-maps or adder design and your project You will be designing interfaces Either hardware or software The basic ideas presented here apply fairly widely11/18/2008 EECS150 Lecture #23 3Outline Quick Review: SDRAM and Audio Principles Metrics: Bandwidth, Latency, Pin Count & Logic Overhead Datapath & Control (States & Events) Synchronization: Clock & Reset Handshaking (Ready/Valid) Protocols (structure, syntax, sematics) Interfaces Simple Interfaces: SPI, I2C, UART, N64 Intermediate Interfaces: LCD, Ethernet (10M-10G), Interchip CPU Interfaces: ISA, PCIe Design Back to principles Reuse & Standardization Modeling, Verification & Debugging11/18/2008 EECS150 Lecture #23 4Quick Review (1 of 4) So What? Almost everything needs storage Lots of space -> DRAM SDRAM SDRAM is BIG Time multiplex address lines 2 Dimensional Address (Row & Column) Often Shared Arbitration for access Affects performanceSDRAMSDRAM DataSDRAMControlSDRAMControlSDRAMArbiterAddressHandshakin gHandshakin gHandshakingDataAddressSDRAMAddressAddressDataDataAct Act RefRead WriteRSTMicron SDR AM ChipsSDRAM Con trolMuxSelectMux MuxAddressHandshakingDataHandshak ingDataAddress11/18/2008 EECS150 Lecture #23 5Quick Review (2 of 4) SDRAM (cont) Steps to Read/Write Send Row Address (RAS) Send Column Address (CAS) Send/Get Data (For 2,4,8 cycles) Wait (precharge, autorefresh, etc) Synchronous Interface Uses a clock & bursts to increase bandwidth Control requires precise timing Issue sequences of commands Timing must be matched to clock frequency11/18/2008 EECS150 Lecture #23 6Quick Review (3 of 4) So what? Example data stream Low bandwidth Includes control Audio Primary interfaces are analog Audio is analog Mixers, etc… Bit Serial Low & fixed bandwidth Low complexity Expandable (e.g. 5.1, 7.1)211/18/2008 EECS150 Lecture #23 7Quick Review (4 of 4) Audio (cont) Driver Pair of shifters Simple sync framing Control Abstract registers Highly stateful VERY low bandwidth{CMD_A, CMD_D}IORegisterAP_BIT_CLOCK (12MHz)PHY_RX_CLK (~25MHz)CMD_RequestCMD_Valid11/18/2008 EECS150 Lecture #23 8Metrics (1 of 3) So What? We need some way to judge good vs bad Allows us to compare interfaces without guessing Evaluate tradeoffs and requirements in a formal manner Objective Metrics Bandwidth Latency Pin Count State & Logic Overhead Subjective Metrics Documentation Ease of use or debugging Elegance11/18/2008 EECS150 Lecture #23 9Metrics (2 of 3) Bandwidth High or Low Higher is always better, but e.g. humans can only hear so much Video, Audo are classic, but programs need instructions, which means DRAM bandwidth Fixed or Variable Raw video or audio have fixed bandwidth, compression (e.g. MP3) can make this vary Network bandwidth varies because of sharing Latency High or Low Lower is usually better If there’s no elastic buffer (no way to say “I’m not ready”) This can cause data loss or require extra buffering, which is costly Humans are very sensitive to gross latency Generally reducing latency is VERY HARD without affecting the clock rate Fixed or variable Generally referred to as “jitter” E.g. on VOIP phones, Audio is fixed latency, network is variable, so we have a problem11/18/2008 EECS150 Lecture #23 10Metrics (3 of 3) Pincount Fast becoming a major problem Chip area grows with N2, Pins are N for DIPs or N2 for BGAs Either way pins are just physically large They require a lot of area They are slow and power hungry Serial vs Parallel Old: Parallel for high bandwidth New: Serial for high bandwidth What changed? State & Logic Overhead This is where major cost & complexity come into play The bigger the circuit the more places to have a bug Also affects power, yield and price Interfaces can be very large For example DDR2 SDRAM on a Virtex2 Pro The FPGA couldn’t support the clocking/handshaking easily Required an incredible amount of logic to make up for this Never very reliable as a result11/18/2008 EECS150 Lecture #23 11Datapath & Control (1 of 4) So What? Separates the data & control Allows us to understand the meaning of signals Separates timing from dataflow Datapath Variable information not known until runtime Regular structure or meaning (e.g. all integers) Easy to design and debug Control Circuits which deal with meaning and timing Small, irregular and complicated Difficult to design and debug, even harder to extend11/18/2008 EECS150 Lecture #23 12Datapath & Control (2 of 4) Datapath Signals Wires which carry a value with temporal significance Form the backbone of the datapath May include “control” values E.g. that this is a value to be written to DRAM This is common in “data stationary control” Coding Common Codes Binary: easy to understand, easy to work with One-hot: allows inexpensive decoding Gray Code: asynchronous logic, one bit change at a time Other issues: state coding, floating point, etc311/18/2008 EECS150 Lecture #23 13Datapath & Control (3 of 4) Control Signals Wires which carry timing, but little data Form the backbone of the control logic Enables, resets, and so forth fall into this category Event Coding Edge (neg or pos) Generally we only use the clock edge in FPGA designs Latch based designs use edges all the time, of course Pulse High Do something when a wire is 1, usually relative to a clock edge Pulse Change Do something when a signal is different than on the last cycle Time Do something a certain amount of time after a previous event Measured with a clock in synchronous systems Possible to build “delay lines” using transistors and gates11/18/2008 EECS150 Lecture #23 14Synchronization (1 of 4) Clocking 1 Clock Fully synchronous, no


View Full Document

Berkeley COMPSCI 150 - Digital Interface Design

Documents in this Course
Lab 2

Lab 2

9 pages

Debugging

Debugging

28 pages

Lab 1

Lab 1

15 pages

Memory

Memory

13 pages

Lecture 7

Lecture 7

11 pages

SPDIF

SPDIF

18 pages

Memory

Memory

27 pages

Exam III

Exam III

15 pages

Quiz

Quiz

6 pages

Problem

Problem

3 pages

Memory

Memory

26 pages

Lab 1

Lab 1

9 pages

Memory

Memory

5 pages

Load more
Download Digital Interface Design
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Digital Interface Design and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Digital Interface Design 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?