1 / 14

An Exploration of the MPEG Algorithm Using Latency Insensitive Design

An Exploration of the MPEG Algorithm Using Latency Insensitive Design. EE249 Presentation (12/04/1999) Trevor Meyerowitz Mentored by: Luca Carloni. Outline. Motivation Explanation of Latency Insensitive Design Why MPEG is interesting? Current Implementation Conclusions and Future work.

barton
Download Presentation

An Exploration of the MPEG Algorithm Using Latency Insensitive Design

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. An Exploration of the MPEG Algorithm Using Latency Insensitive Design EE249 Presentation (12/04/1999) Trevor Meyerowitz Mentored by: Luca Carloni

  2. Outline • Motivation • Explanation of Latency Insensitive Design • Why MPEG is interesting? • Current Implementation • Conclusions and Future work

  3. Motivation:Doomsday for IC design? • Die Size, Design complexity, and Clock speed are all increasing. • Clock propagation is an increasing problem. • Multiple clock cycles to cross a chip • Verification becomes harder • Buffering the clock isn’t enough

  4. The Current Situation • Traditional design flow uses direct connections between individual blocks • The wires might be too long. • Blocks are highly coupled. • Difficult to connect independent IP’s

  5. Remove wires and put shells around blocks • Remove wires and put shells around blocks • Connect shells with an arbitrary number of relay stations • Data coherency is preserved RS RS RS RS RS Solution: Latency Insensitive Design

  6. Latency Insensitive Design: The Relay Station • Data- the signal • Void- whether the signal is legitimate data • Stop- tells previous relay station whether it’s ready or not to receive data Data_in,Void_in Data_out,Void_out control Stop_Out Stop_In Source: A Methodology for Correct by Construction Latency Insensitive Design (carloni et al)

  7. Current Status: • Proof of concept (Carloni, McMillan, Sangiovanni-Vincentelli 1999) • Functional Example • Case Study: The PDLX micro-processor • Different examples are required • Demonstrate SOC feasibility • Especially Multimedia

  8. Sample SOC idea MPEG Decode& Wireless Comm Chip HDTV(picture from www.sony.com)High MHzHigh Powerand Bandwidth Cell Phone(picture from www.nokia.com)Low MHzLow Powerand Bandwidth

  9. Why MPEG Decode is Good • Complicated & Highly Data Dependant • Different resolutions, encoding techniques • Not as arbitrary or complicated as Encode • Real Time Constraints • Great Target for HW/SW Partitioning/Co-Design • Relevant for SOC today

  10. Description of MPEG Decode • Aside from headers can be classified as 4 types of blocks • D-Block - (control information) • I-Block - Full Picture • P-Block - Picture Dependant on prior picture • B-Block - Picture Dependant on future picture • Each non-D-Block is split up into 8x8 chunks

  11. ? software hardware Description of MPEG Decode Header Decode VLC/RLCDecode Input Stream Inverse DCT Inverse ZigZag Inverse Quantize Add Picture Forward Predictor Backward Predictor DecodedPicture Memory Bus Picture Store (I) Picture Store (P) Source: MPEG-2 John Watkinson

  12. Current Implementation Relay Station • Have translated hardware portions from MPEG-2 Decoder C file to Verilog • Hooked up them up using relay stations • Verified Functionality Inverse Quantize Relay Station Inverse ZigZag Relay Station Inverse DCT

  13. Results: • Relay Stations do add a startup delay similar to pipelining • Basic Simulation confirms 4.5* cycle delay • Software-ish portions are a nightmare to translate to Verilog • Memory access and pointers • Software is sequential, HW isn’t usually

  14. Conclusion • What Remains to be Done: • More thorough verification • Further exploration of results • Perhaps add VLC/RLC to hardware • Possibly interface with PLI • Possible Future Work: • Exploration of interfacing with software • Further Performance Analysis • Automatic Shell Synthesis • Instantiation of Multiple Execution Units

More Related