Nathan Slingerland CS294-7 Reconfigurable Computing Day 27 Notes

Day 27

Specialization and Binding Time

Data Entropy

Data values are not fully random - often show localization in probability space. Therefore, handle the common case quickly. Handle the less common cases too, but perhaps less elegantly.

Examples:

Limited range of values
P(x<10) = 0.99
Limited set of values
P(x=0) = 0.4, P(x=1) = 0.3
Correlation to previous values
P(x_i = x_i-1) = 0.8
Small change in values over time
P(x_i-1-2 < x_i < x_i+1+2) = 0.98

Why is this?

inherent nature of the input data (localization in probaility space)
computed values exhibit structure (data processing inequality)
values used during computation may be bound early and then don't change for some operational lifetime (epoch)

Computational needs at any instant in time are less than the general case.

Optimize the common case - data values are not fully random - often show localization in probalility space

Data Processing Inequality

Recall from information theory that the entropy of some function of x has less entropy than the original x.

H(F(x)) < H(x)

Computation adds structure.

Binding Time

A value used in a computation may be determined (bound) and then used many times before it changes again (if ever).

Idea:

specialize at binding time
use specialized computation throughout bound domain

Examples of Operational Epochs:

pre-fabrication
pixel widths im MPEG-2 decoder ASIC

application/algorithm selection
constant coefficients, structure

"compile" time
implementation alues, data layout

program startup
machine parameters, environment parameters

instantiation
instance variable

program internal epochs
recalibration periods, changes in user preferences

loops
loop invariants - values set outside a loop and used many times within a loop

procedure/routine

Types of values to bind

static - identify in program structure

P(x=x_bound) = 1

true but not provable - value is dependent but not identifiable through current static analysis methods

P(x = x_prev) ~ 1

highly probable but not guranteed - highly unlikely to be different

P(x = x_prev) = 0.999
Note: Need to check value in the second and third case - O(# input bits) - Checking the input value may be a win or lose depnding on the relative complexity of the function.

Specialization

specialization - constrain a computational problem through foreknowledge of the range of cases to be solved.

Key Idea: The more we know about the inputs, the less work we have to do to compute a function

May get savings from:

removing state elements
control paths to load
simplification of logic

Case Studies in Specialization

Fixed Benefit Due to Specialization: Matching (a=b)

b variable b constant w/state w/o state

size CLBs path CLBs path Area-Time ratio Area-Time ratio

8 2.5 (+4) 2 1.5 2 0.60 0.23

16 5.5 (+8) 3 2.5 2 0.30 0.12

32 10.5 (+16) 3 5.5 3 0.52 0.21

64 21.5 (+32) 4 10.5 3 0.37 0.15

Note: In the size 16 and 64 cases, the AT ratios exhibit oddly low results relative to neighboring values. This is due to their fully utilizing the 4-LUT's in the Xilinx array. (These cases were repeated with the Altera Flex 8000 and Actel Act2 families of devices to insure that results are independent of the particular FPGA design.)

Negligible Benefit Due to Specialization: DES F Function

k variable k constant

Function Speed Mapped Area Mapped Speed Mapped Area Mapped

(size) CLBs Path CLBs Path CLBs Path CLBs Path

F 290.5 7 282 8 <280 6 ~250 7

Notes: The F function which forms the kernel of the DES algorithm takes a 32-bit data input and a 48-bit key input to generate a 32-bit output. The F function includes an expansion of the input, an XOR with the key, lookup through 8 S-boxes and a permutation of the output bits. Since the key is XOR'd with the expanded data, the output of the XOR can still take on any input value. Specialization succeeds only in removing the XOR stage, but very little of the encoding logic. Hence the small benefit.

Variable Benefit Due to Specialization: Less Than (a<b)

b variable b constant

Function Speed Mapped Area Mapped Speed Mapped Area Mapped

(size) CLBs Path CLBs Path CLBs Path CLBs Path

8 4 8 4 8 <2 <2 <1.5 <3

16 18.5 14 16.5 16 <6.5 <3 <3 <5

32 35 19 36 24 <13.5 <4 <6 <11

64 77.5 20 74.5 28 <30 <5 <14 <16

General Result: specialized instances have a slightly shorter critical path while requiring significantly less area

Specialization Through Bounding

Knowing that a value will be constant can get a bound on area (time).

There is often a bound on (A op Constant) which is tighter than (A op B) and independent of Constant

Examples:

Pattern Matching
Less Than
Multiply

Case Study - Bounding Multiply

16x16 8x8

Area Time mpy scale mpy scale

316 CLBs 26 ns 8216 (1.00)

84 CLBs 40 ns 3360 (0.41)

220 CLBs 12.1 ns 2662 (0.32)

22 CLBs 25 ns 550 (0.07)

Savings Through Specialization

Savings Depend On:

which data is known
their values
computational structure

Possible Metrics for Specializability

Given PDF on likely early bound values, can compute expected Area-Time. But how cheaply?
Impact of specializing particular inputs to a function
Variability associated with specializing particular inputs

Relationship with Data Entropy/Predictability

Can predict/bound "real" computational work in a problem (much like "real" information content of a data stream)

Instruction Load

Loading specialized instances into a device takes time (assume can not compute during load)

Computing new specializations make take 10s of minutes (synthesis, placement, routing)

Reloading conventional FPGAstakes 10s of milliseconds (once a configuration exists)

Swapping to a loaded configuration on a DPGA design can occur in 10s of nanoseconds

T_task = T_load + T_sc

AT_s = A_s(T_load+T_sc)

AT_g = A_gT_g

A_sT_load+A_sT_sc < A_gT_g

A_sT_load/A_gT_g + A_sT_sc/A_gT_g < 1

Where:
T_task - time for task
T_load - time to load configuration
T_sc - time to switch context
T_s - time in specialized case
T_g - time in general case
A - total area
A_s - area in specialized case
A_g - area in general case

Compute long enough with special value -> ammortize out load time

For short computational runs, benefit is diminished by load time

Still profitable if benefit large even when T_load > T_sc

With background load (requires ability to predict next case):

AT_s = A_smax(T_load, T_sc)

T_load < T_sc, then no load penalty

Instruction Space

Instructions take up space

AT_s = A_s(T_load + T_sc)

A_s = A_active + A_instruction

4-LUT Area bits SRAM/inst DRAM/inst

Xilinx 640 k-lambda² ~200 240 k-lambda² 20 k-lambda²

Model 880 k-lambda² 64 80 k-lambda² 6.4 k-lambda²

Nick's DNA Sequence Match - 8 4-LUTs/char

8200 = 1600 bits (versus 2 bits in problem)
800x more memory
If storing a large dataase, A_memory>>A_sc

Nick's DNA Sequence Match w/ Relocatable Macros

Only need to save 16 different configurations
Compute using original 2 bit/char string

Runtime Code Generation

One way to solve space requirement is to compute specializations on the fly (especially since potential cases exponential in number of bound bits)

T_task = T_gen + T_sc

AT_s = A_s(T_gen+T_sc)

AT_g = A_gT_g

A_sT_gen+A_sT_sc < A_gT_g

A_sT_gen/A_gT_g + A_sT_sc/A_gT_g < 1

Variable Space

Fully exploiting reduced area requirements of specialized instances requires that we look at variable space requirements

Amount of simultaneous computation depends on data

Many problems can exploit this - particularly when we have to fold the problem to fit on the device (get more simultaneous instances with smaller specialization)

Online composition and packaging becomes a must.

In more sophisticated cases: online resource management, allocation and scheduling.

Review

Low data entropy arises from:

bound values
derived/correlated values
probabilistic value localization

Specialized instances:

smaller and faster (less A:T)
size bound (tighter than the general case)
savings depend on functional structure
data dependent AT in general

Designer needs to pay attention to:

instruction load (or generation) time
instruction area