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