Lecture 14 Reconfigurable Computing Case Studies Prof Jan

Lecture 14: (Re)configurable Computing Case Studies Prof. Jan Rabaey Computer Science 252, Spring 2000 The contributions of Andre Dehon (Caltech) and Ravi Subramanian (Morphics) to this slide set are gratefully acknowledged JR. S 00 1

Summary of Previous Class • Configurable Computing using “programming in space” versus “programming in time” for traditional instruction-set computers • Key design choices – Computational units and their granularity – Interconnect Network – (Re)configuration time and frequency • Next class: Some practical examples of reconfigurable computers JR. S 00 2

Applicability of Configurable Processing • Stand-alone computational engines – E. g. PADDI, UCLA Mojave • Adding programmable I/O to embedded processors – E. g. Napa 2000 • Augmenting the instruction set of processors – E. g. GARP, RAW • Providing programmable accelerator coprocessors to embedded micro’s and DSP – Chameleon, Pleiades, Morphics JR. S 00 3

Stand-Alone Computational Engines UCLA Mojave System Template Matching for Automatic Target Recognition I 960 Board JR. S 00 4

As Programmable Interface and I/O Processor • Logic used in place of – ASIC environment customization – external FPGA/PLD devices • Example – bus protocols – peripherals – sensors, actuators • Case for: – Always have some system adaptation to do – varying glue logic requirements – Modern chips have capacity to hold processor + glue logic – Reduces part count – Valued added must now be accommodated on chip (formerly board level) JR. S 00 5

Example: Interface/Peripherals • Triscend E 5 JR. S 00 6

Model: IO Processor • Array dedicated to servicing IO channel – sensor, lan, wan, peripheral • Provides • Case for: – many protocols, services – only need few at a time – dedicate attention, offload processor – protocol handling – stream computation » compression, encrypt • Looks like IO peripheral to processor JR. S 00 7

IO Processing • Single threaded processor – cannot continuously monitor multiple data pipes (src, sink) – need some minimal, local control to handle events – for performance or real-time guarantees , may need to service event rapidly – E. g. checksum (decode) and acknowledge packet JR. S 00 8

NAPA 1000 Block Diagram TBT Toggle. Bus. TM Transceiver System Port External Memory Interface CR 32 RPC Compact. RISCTM 32 Bit Processor Reconfigurable Pipeline Cntr BIU PMA Bus Interface Unit Pipeline Memory Array CR 32 Peripheral Devices SMA Source: National Semiconductor ALP Adaptive Logic Processor CIO Configurable I/O Scratchpad Memory Array JR. S 00 9

NAPA 1000 as IO Processor SYSTEM HOST Application Specific System Port NAPA 1000 CIO Sensors, Actuators, or other circuits Memory Interface ROM & DRAM Source: National Semiconductor JR. S 00 10

I/O Stream Processor Combines Trimedia VLIW with Configurable media co-processors Philips Nexperia NX-2700 A programmable HDTV media processor JR. S 00 11

Model: Instruction Augmentation • Observation: Instruction Bandwidth – Processor can only describe a small number of basic computations in a cycle » I bits 2 I operations – This is a small fraction of the operations one could do even in terms of w w w Ops » w 22(2 w) operations – Processor could have to issue w 2(2 (2 w) -I) operations just to describe some computations – An a priori selected base set of functions could be very bad for some applications JR. S 00 12

Instruction Augmentation • Idea: – provide a way to augment the processor’s instruction set – with operations needed by a particular application – close semantic gap / avoid mismatch • What’s required: – some way to fit augmented instructions into stream – execution engine for augmented instructions » if programmable, has own instructions – interconnect to augmented instructions JR. S 00 13

“First” Instruction Augmentation • PRISM – Processor Reconfiguration through Instruction Set Metamorphosis • PRISM-I – 68010 (10 MHz) + XC 3090 – can reconfigure FPGA in one second! – 50 -75 clocks for operations [Athanas+Silverman: Brown] JR. S 00 14

PRISM-1 Results Raw kernel speedups JR. S 00 15

PRISM • • • FPGA on bus access as memory mapped peripheral explicit context management some software discipline for use …not much of an “architecture” presented to user JR. S 00 16

[Razdan+Smith: Harvard] PRISC • Takes next step – what look like if we put it on chip? – how integrate into processor ISA? • Architecture: – couple into register file as “superscalar” functional unit – flow-through array (no state) JR. S 00 17

PRISC • ISA Integration – add expfu instruction – 11 bit address space for user-defined expfu instructions – fault on pfu instruction mismatch » trap code to service instruction miss – all operations occur in clock cycle – easily works with processor context switch » no state + fault on mismatch pfu instr JR. S 00 18

PRISC Results • All compiled • working from MIPS binary • <200 4 LUTs ? – 64 x 3 • 200 MHz MIPS base Razdan/Micro 27 JR. S 00 19

Chimaera • Start from PRISC idea – – integrate as functional unit no state RFUOPs (like expfu) stall processor on instruction miss, reload • Add – manage multiple instructions loaded – more than 2 inputs possible [Hauck: Northwestern] JR. S 00 20

Chimaera Architecture • “Live” copy of register file values feed into array • Each row of array may compute from register values or intermediates (other rows) • Tag on array to indicate RFUOP Results • Compress 1. 11 • Eqntott 1. 8 • Life 2. 06 (160 hand parallelization) [Hauck/FCCM 97] JR. S 00 21

Instruction Augmentation • Small arrays with limited state – so far, for automatic compilation » reported speedups have been small – open » discover less-local recodings which extract greater benefit JR. S 00 22

GARP Identified Problems: • Single-cycle flow-through – not most promising usage style • Moving data through Register File to/from array – can present a limitation » bottleneck to achieving high computation rate [Hauser+Wawrzynek: UCB] JR. S 00 23

GARP • Integrate as coprocessor – similar bandwidth to processor as FU – own access to memory • Support multi-cycle operation – allow state – cycle counter to track operation • Fast operation selection – cache for configurations – dense encodings, wide path to memory JR. S 00 24

GARP • ISA -- coprocessor operations – issue gaconfig to make a particular configuration resident (may be active or cached) – explicitly move data to/from array » 2 writes, 1 read – processor suspend during coprocessor operation » cycle count tracks operation – array may directly access memory » processor and array share memory space • cache/mmu keeps consistency » can exploit streaming data operations JR. S 00 25

GARP • Processor Instructions JR. S 00 26

GARP Array • Row oriented logic – denser for datapath operations • Dedicated path for – processor/memory data • Processor not have to be involved in array memory path JR. S 00 27

GARP Results • General results – 10 -20 x on stream, feedforward operation – 2 -3 x when datadependencies limit pipelining [Hauser+Wawrzynek/FCCM 97] JR. S 00 28

PRISC/Chimera … GARP • PRISC/Chimaera – basic op is single cycle: expfu (rfuop) – no state – could conceivably have multiple PFUs? – Discover parallelism => run in parallel? – Can’t run deep pipelines • GARP – basic op is multicycle » gaconfig » mtga » mfga – can have state/deep pipelining – ? Multiple arrays viable? – Identify mtga/mfga w/ corr gaconfig? JR. S 00 29

Common Theme • To get around instruction expression limits – define new instruction in array » many bits of config … broad expressability » many parallel operators – give array configuration short “name” which processor can callout » …effectively the address of the operation But – Impact of using reconfiguration at Instruction Level seems limited Explore opportunities at larger granularity levels (basic block, task, process) JR. S 00 30

Applicability of Configurable Processing • Stand-alone computational engines – E. g. PADDI, UCLA Mojave • Adding programmable I/O to embedded processors – E. g. Napa 2000 • Augmenting the instruction set of processors – E. g. GARP, RAW • Providing programmable accelerator coprocessors to embedded micro’s and DSP – Chameleon, Pleiades, Morphics JR. S 00 31

Example: Chameleon Reconfigurable Co. Processor (network, communication applications) JTAG Debugging Port PCI Interface Memory Controller Data Memory Wide Internal communications bus Bus Manager & DMA Controllers ARC CPU Instruction Cache Background Configuration Plane Configuration bit stream Reconfigurable Logic Array of 32 -bit Data Path Operators & Control Logic Multiple banks of I/O Local Store Memory (LSM) JR. S 00 32

Reconfigurable Processor Tools Flow Customer Application / IP (C code) C Compiler ARC Object Code RTL HDL Synthesis & Layout Linker Configuration Bits Chameleon Executable C Model Simulator C Debugger Development Board JR. S 00 33

Heterogeneous Reconfiguration Reconfigurable Logic Datapaths Arithmetic Control Bit-Level Operations e. g. encoding Dedicated data paths Arithmetic kernels e. g. Filters, AGU e. g. Convolution RTOS Process management JR. S 00 34

Multi-granularity Reconfigurable Architecture: The Berkeley Pleiades Architecture Configuration Bus Arithmetic Processor Communication Network Control Processor Configurable Datapath Configurable Logic Configuration Arithmetic Processor Satellite Processor Dedicated Arithmetic Network Interface • Computational kernels are “spawned” to satellite processors • Control processor supports RTOS and reconfiguration • Order(s) of magnitude energy-reduction over traditional programmable architectures JR. S 00 35

Matching Computation and Architecture Address. Gen Memory MAC Convolution L G C Control Processor Two models of computation: communicating processes + data-flow Two architectural models: sequential control+ data-driven JR. S 00 36

Execution Model of a Data-Flow Kernel Embedded processor Code seg for(i=1; i<=L; i++) for(k=i; k<=L; k++) end start Addr. Gen MEM: in Addr. Gen phi[i][k]= phi[i-1][k-1] +in[NP-i]*in[NP-k] -in[NA-1 -i]*in[NA-1 -k]; MPY MEM: phi ALU Code seg • Distributed control and memory ALU JR. S 00 37

Reconfigurable Kernels for WCDMA • Dominant kernel M(MTX) requires array of MACs and segmented memories • Additional operations such as sqrt(x), 1/x, and Trellis decoding may be implemented using FPGA or cordic satellite JR. S 00 38

Inter-Satellite Communication • Data-driven execution – A satellite processor is enabled only when input data is ready • Data sources generate data of different types: scalars, vectors, matrices • Data computing processors handle data inputs of different types end-of-vector token 1 Addr. Gen Memory 1 1 n Embedded processor Data sources n n MPY 1 MPY n MAC 1 Data computing processors JR. S 00 39

Impact of Architectural Choice 570 n 0. 75 Pleiades Example: 16 point Complex Radix-2 FFT (Final Stage) Pleiades 13 JR. S 00 40

Adaptive Multi-User Detector for W-CDMA Pilot Correlator Unit Using LMS JR. S 00 41

Architecture Comparison LMS Correlator at 1. 67 MSymbols Data Rate Complexity: 300 Mmult/sec and 357 Macc/sec 16 Mmacs/m. W! Note: TMS implementation requires 36 parallel processors to meet data rate validity questionable JR. S 00 42

Maia: Reconfigurable Baseband Processor for Wireless • 0. 25 um tech: 4. 5 mm x 6 mm • 1. 2 Million transistors • 40 MHz at 1 V • 1 m. W VCELP voice coder • Hardware • 1 ARM-8 • 8 SRAMs & 8 AGPs • 2 MACs • 2 ALUs • 2 In-Ports and 2 Out-Ports • 14 x 8 FPGA JR. S 00 43

Reconfigurable Interconnect Exploration Mesh Hierarchical Mesh Module JR. S 00 44

Software Methodology Flow C++ SUIF+ C-IF JR. S 00 45

Hardware-Software Exploration Macromodel call JR. S 00 46

Implementation Fabrics for Protocols RACH req A protocol = Extended FSM RACH akn Memory idle RACH slotset update read write R_ENA idle W_ENA BUF Slot_Set_Tbl 2 x 16 addr slot_set <31: 0> Slot_no <5: 0> Slot Pkt start end Intercom TDMA MAC JR. S 00 47

Intercom TDMA MAC Implementation alternatives • • ASIC: 1 V, 0. 25 mm CMOS process FPGA: 1. 5 V 0. 25 mm CMOS low-energy FPGA ARM 8: 1 V 25 MHz processor; n = 13, 000 Ratio: 1 - 8 - >> 400 JR. S 00 48

The Software-Defined Radio FPGA Embedded u. P Dedicated FSM Dedicated DSP Reconfigurable Data. Path JR. S 00 49

An Industrial Example: Basestation for Cellular Wireless 1900 MHz 800 MHz A B Antenna System D B E F C Antenna System RF/IF Tuner Block-Spectrum A/D RF/IF multiple sectors Tuner RF/IF Tuner multi-band Block-Spectrum Tuner Block-Spectrum A/D A/D multiple sectors multi-band HIGH-SPEED DIGITAL BUS . . . 1 Modular/Parameterizable • per carrier • per TDMA time-slot • per CDMA code T 1 /E JR. S 00 50

BTS Signal Processing Platforms Comm Agent High-Speed Digital Bus D/A Conversion A/D Conversion Hardwired ASICs Standard A, F 1 Standard A, F 2 . . . Comm Agent N DSP/CPUs Standard B, F 1. . . CPU JR. S 00 51

Basestation of the Next Generation Wideband RF 10/ 100 or Gbit ATM Data Networks JR. S 00 52

Coexistence of Multiple Standards In Product Supply Chain 2 G 3 G – – – – GSM DCS 1800 PCS 1900 IS-95 IS-54 B IS-136 PDC CIRCUIT VOICE NARROWBAND 2. 5 G – – – GPRS HCSD IS-95 MDR IS-95 HDR IS-136 HS – – ETSI UTRA ARIB W-CDMA TIA cdma 2000 W-TDMA (UWC) PACKET DATA WIDEBAND JR. S 00 53

Wideband CDMA: MOPS? No, GOPS! Single 384 kbps ARIB W-CDMA Channel Source: J. Kohnen et al. “Baseband Solution for WCDMA, ” Proc. IEEE Communication Theory Workshop, May 1999, Aptos, USA. JR. S 00 54

HW Multistandard Solutions The common approach to hardware design involves: multiple ASIC’s to support each standard. DSP Control Processor Programmable Digital Hardwired ASIC Unique Combinations IF RF Analog • Hardwired implementation is not scalable or upgradeable to new standards. • This approach costs time in a time-to-market dominated world. • Creating new chipsets for every technology combination critically challenges available design resources! JR. S 00 55

SW Multistandard Solution Applying instruction-set processor architectures to all baseband processing would be desireable. . . IF RF DSP Control Processor Programmable Analog …but is simply not an good implementation for base stations: -Unacceptably high cost per channel -Unacceptably large power per channel This is definitely not a viable implementation for terminals JR. S 00 56

The Law of Diminishing Returns • More transistors are being thrown at improving general -purpose CPU and DSP performance • Fundamental bounds are being pushed – limits on instruction-level parallelism – limits on memory system performance • Returns per transistor are diminishing – new architectures realizing only 2 -3 instructions/clock – increasingly large caches to hide DRAM latency JR. S 00 57

Embedded Logic Evolution – Increasing fixed-function hardwired content of systems – Core+Logic becomes de-facto design architecture – Move to deep sub-micron technology » rapidly increasing product integration cycles » increasingly constrained design resources » sharp increases in cost of “trying out” an idea- NRE – Design methodologies optimized for random logic, homogeneous architectures, and lower speed signal processing (I. e. control-flow dominated systems) – Verification issues dominate design cycle time Growing Design Cycle Times At Odds With Shrinking Product Cycle Times JR. S 00 58

FPGA the Solution? Cellular Handset Using Current FPGA JR. S 00 59

Some Interesting Observations Don’t use more transistors to stretch general -purpose performance, whether for CPUs, DSPs, or reconfigurable logic. Don’t use more time to design dedicated hardwired solutions in cases where mass customization is what the market demands. JR. S 00 60

View The “Reconfigurability” Problem From The System Level What Are the Application-Specific Performance Needs? – – What are the applications targeted? What algorithms are essential to achieving the performance goals? What are the functions at the heart of these algorithms? Which functions yield poor price-performance with general-purpose MOPS and system memory models? – What is the embedded systems programmer’s model? – Best performance at what cost: » Area - instruction-level parallelism, memory hierarchy » Power- energy requirements on a function basis » Time- quality and ease of programming for app development » Pain- forward opportunity vs backward compatibility JR. S 00 61

Successfully Using Reconfigurability Application-Specific Leverage Focus on first on applications and constituent algorithms, not the silicon architecture ! Wireless Communications Transceiver Signal Processing Minimize the hardware reconfigurability to constrained set Maximize the software parameterizability and ease of use of the programmer’s model for flexibility Define optimal architecture for efficient implementation JR. S 00 62

Application-Specific MOPS in Digital Communications RF/IF Digital Downconversion and Channelization TDMA Wideband Signal Processing Engine Programmable DSP Wideband Channel Decoder Engine CDMA Wideband Signal Processing Engine Microprocessor JR. S 00 63

Morphics’ DRL Architecture Heterogeneous Multiprocessing Engine Using Application. Specific Reconfigurable Logic DATAFLOW Large Granularity Kernel Small Granularity Kernel JR. S 00 64

DRL Kernels DATA MEMORY DATA SEQUENCER PARAMETERIZABLE CONFIGURABLE ALU JR. S 00 65

Mapping Software to Target Architecture DATA MEMORY DATA SEQUENCER PARAMETERIZABLE CONFIGURABLE ALU JR. S 00 66

Programmer’s Guide Document provided with each processor to enable application development, configuration, and system control via host processor. Includes complete • • description of each API function call system control functions variables, parameters coding examples, and performance realized (i. e. ROC curves) /* morphics soft API usage examples: */ /* search a pilot set in search set */ /* maintainance mode. */. . . set_ptr = get_next_set(); if (no_need_to_throttle()) { search_set(set_ptr); }. . . void search_set(PILOT_TYPE *pilot) { /* search threshold is assumed to be set in other places */ morphics_searcher_set_win_size(pilot->win_size); morphics_searcher_set_pn(pilot->pn); morphics_searcher_set_int_len(pilot->int_len); } /* finger re-assignments */. . . fing[i]. pos = morphics_demod_get_fin_pos(i); . . . distance = calc_fing_movement(&fing[i], new_pn); . . . fing[i]. slew = distance; fing[i]. pn = new_pn; morphics_demod_set_fing_iq(i, fing[i]. pn); while ( slew_not_done(morphics_demod_get_status()) ) { morphics_demod_set_fing_slew(i, fing[i]. slew); }. . . JR. S 00 67

Key Pieces of Design Methodology System-level Profiling • • • Analyze sequences of operations (arithmetic, memory access, etc) Analyze communication bottlenecks Key flexible parameters (algorithm v architecture parameters) Architecture-level Profiling • • ALU/kernel definition (sequences of operators) Memory profile Type of configurability required for flexibility Macro-sequencer development Implementation • • SW- programmer’s model developed at architecture specification stage SW- API proven out via behavioral models & demonstrator hardware VLSI-focus on regular predictable timing and routability VLSI- embedded reconfigurability in an ASIC flow JR. S 00 68

CDMA Modem Analysis JR. S 00 69

MOPS Breakdown Analysis JR. S 00 70

Prototype Demonstrator RISC Microprocessor Configurable Kernel(s) Data Router JR. S 00 71

Summary • Configurable computing is finding its way into the embedded processor space • Best suited (so far) for – Flexible I/O and Interface functionality – providing task-level acceleration of “parametizable” functions • Improvement of IP seems limited • Software flow still subject to improvement • Might become more interesting with the emergence of low-current devices (TFT, organic transistors, molecular computing) DO NOT FORGET CONFIGURATION OVERHEAD JR. S 00 72