Caltech CS184a Fall DeHon1 CS184a: Computer Architecture (Structures and Organization) Day17: November 20, 2000 Time Multiplexing

Caltech CS184a Fall DeHon2 Last Week Saw how to pipeline architectures –specifically interconnect –talked about general case Including how to map to them Saw how to reuse resources at maximum rate to do the same thing

Caltech CS184a Fall DeHon3 Today Multicontext –Review why –Cost –Packing into contexts –Retiming implications

Caltech CS184a Fall DeHon4 How often reuse same operation applicable? Can we exploit higher frequency offered? –High throughput, feed-forward (acyclic) –Cycles in flowgraph abundant data level parallelism [C-slow, last time] no data level parallelism –Low throughput tasks structured (e.g. datapaths) [serialize datapath] unstructured –Data dependent operations similar ops [local control -- next time] dis-similar ops

Caltech CS184a Fall DeHon5 Structured Datapaths Datapaths: same pinst for all bits Can serialize and reuse the same data elements in succeeding cycles example: adder

Caltech CS184a Fall DeHon6 Throughput Yield FPGA Model -- if throughput requirement is reduced for wide word operations, serialization allows us to reuse active area for same computation

Caltech CS184a Fall DeHon7 Throughput Yield Same graph, rotated to show backside.

Caltech CS184a Fall DeHon8 Remaining Cases Benefit from multicontext as well as high clock rate –cycles, no parallelism –data dependent, dissimilar operations –low throughput, irregular (can’t afford swap?)

Caltech CS184a Fall DeHon9 Single Context When have: –cycles and no data parallelism –low throughput, unstructured tasks –dis-similar data dependent tasks Active resources sit idle most of the time –Waste of resources Cannot reuse resources to perform different function, only same

Caltech CS184a Fall DeHon10 Resource Reuse To use resources in these cases –must direct to do different things. Must be able tell resources how to behave => separate instructions (pinsts) for each behavior

Caltech CS184a Fall DeHon11 Example: Serial Evaluation

Caltech CS184a Fall DeHon12 Example: Dis-similar Operations

Caltech CS184a Fall DeHon13 Multicontext Organization/Area A ctxt  80K 2 –dense encoding A base  800K 2 A ctxt :A base = 10:1

Caltech CS184a Fall DeHon14 Example: DPGA Prototype

Caltech CS184a Fall DeHon15 Example: DPGA Area

Caltech CS184a Fall DeHon16 Multicontext Tradeoff Curves Assume Ideal packing: N active =N total /L Reminder: Robust point: c*A ctxt =A base

Caltech CS184a Fall DeHon17 In Practice Scheduling Limitations Retiming Limitations

Caltech CS184a Fall DeHon18 Scheduling Limitations N A (active) –size of largest stage Precedence: –can evaluate a LUT only after predecessors have been evaluated –cannot always, completely equalize stage requirements

Caltech CS184a Fall DeHon19 Scheduling Precedence limits packing freedom Freedom do have –shows up as slack in network

Caltech CS184a Fall DeHon20 Scheduling Computing Slack: –ASAP (As Soon As Possible) Schedule propagate depth forward from primary inputs –depth = 1 + max input depth –ALAP (As Late As Possible) Schedule propagate distance from outputs back from outputs –level = 1 + max output consumption level –Slack slack = L+1-(depth+level) [PI depth=0, PO level=0]

Caltech CS184a Fall DeHon21 Slack Example

Caltech CS184a Fall DeHon22 Allowable Schedules Active LUTs (N A ) = 3

Caltech CS184a Fall DeHon23 Sequentialization Adding time slots –more sequential (more latency) –add slack allows better balance L=4  N A =2 (4 or 3 contexts)

Caltech CS184a Fall DeHon24 Multicontext Scheduling “Retiming” for multicontext –goal: minimize peak resource requirements resources: logic blocks, retiming inputs, interconnect NP-complete list schedule, anneal

Caltech CS184a Fall DeHon25 Multicontext Data Retiming How do we accommodate intermediate data? Effects?

Caltech CS184a Fall DeHon26 Signal Retiming Non-pipelined –hold value on LUT Output (wire) from production through consumption –Wastes wire and switches by occupying for entire critical path delay L not just for 1/L’th of cycle takes to cross wire segment –How show up in multicontext?

Caltech CS184a Fall DeHon27 Signal Retiming Multicontext equivalent –need LUT to hold value for each intermediate context

Caltech CS184a Fall DeHon28 Alternate Retiming Recall from last time (Day 16) –Net buffer smaller than LUT –Output retiming may have to route multiple times –Input buffer chain only need LUT every depth cycles

Caltech CS184a Fall DeHon29 Input Buffer Retiming Can only take K unique inputs per cycle Configuration depth differ from context-to- context

Caltech CS184a Fall DeHon30 DES Latency Example Single Output case

Caltech CS184a Fall DeHon31 ASCII  Hex Example Single Context: K 2 =18.5M 2

Caltech CS184a Fall DeHon32 ASCII  Hex Example Three Contexts: K 2 =12.5M 2

Caltech CS184a Fall DeHon33 ASCII  Hex Example All retiming on wires (active outputs) –saturation based on inputs to largest stage Ideal  Perfect scheduling spread + no retime overhead

Caltech CS184a Fall DeHon34 ASCII  Hex Example (input depth=4, c=6: 5.5M 2 (compare 18.5M 2 )

Caltech CS184a Fall DeHon35 General throughput mapping: If only want to achieve limited throughput Target produce new result every t cycles Spatially pipeline every t stages –cycle = t retime to minimize register requirements multicontext evaluation w/in a spatial stage –retime (list schedule) to minimize resource usage Map for depth (i) and contexts (c)

Caltech CS184a Fall DeHon36 Benchmark Set 23 MCNC circuits –area mapped with SIS and Chortle

Caltech CS184a Fall DeHon37 Multicontext vs. Throughput

Caltech CS184a Fall DeHon38 Multicontext vs. Throughput

Caltech CS184a Fall DeHon39 Big Ideas [MSB Ideas] Several cases cannot profitably reuse same logic at device cycle rate –cycles, no data parallelism –low throughput, unstructured –dis-similar data dependent computations These cases benefit from more than one instructions/operations per active element A ctxt << A active makes interesting –save area by sharing active among instructions

Caltech CS184a Fall DeHon40 Big Ideas [MSB-1 Ideas] Economical retiming becomes important here to achieve active LUT reduction –one output reg/LUT leads to early saturation c=4--8, I=4--6 automatically mapped designs 1/2 to 1/3 single context size Most FPGAs typically run in realm where multicontext is smaller –How many for intrinsic reasons? –How many for lack of HSRA-like register/CAD support?