Modeling the Effectiveness of Reuse in SoC DesignModeling the Effectiveness of Reuse in SoC Design

William Fornaciari, Fabio SaliceFDL’00, Tubingen, Germany, September 2000

Presenter: William Fornaciarifornacia@elet.polimi.it

Politecnicodi MilanoItaly

CEFRIELResearch CenterItaly

2

Presentation outlinePresentation outline

Problem definition and paper goal

The identified models for• financial analysis

• project size estimation

Methodology assessment• Analysis of the LEON-1 microprocessor

Concluding remarks

3

Problem backgroundProblem background

The productivity gap is becoming the crucial factor influencing the technological/financial choices

Almost all digital designs are centered on some HDL-based (e.g., VHDL) design flows

The development of a design requires to cope with management/refinement of specifications

Problems• Introduction of design templates• Storing/retrieval of reusable parts• Make-it or buy dilemma • Financial analysis of reuse benefits• Estimation of the development time vs TTM • Strong sensitivity of any tradeoff on the

prediction of the project size

4

Paper goalsPaper goals

Overall goal of our ongoing project• Estimation of the cost-effectiveness of soft-reuse of

VHDL-based designs

Main focus of this paper• Outlining of the financial model

• Customization of the COCOMO analysis

• Identification of a strategy to predict the crucial factor, namely the project size, from a high-level system characterization

Function Point (FP) analysis has been adapted to deal with the peculiarity of VHDL-based designs

Application of the analysis to a real VHDL design: LEON-1, a 32-bit microprocessor

5

The Economical Model (EM)The Economical Model (EM)

A possible solution to identify the cost of a Hw project is the use of parametric models• Identification of the factors influencing the quantities

to be estimated• Definition of the sources of cost (NRC, RC, Fixed) and

their cross-relations with the above quantities• Definition of the predictive variables (parameters) to

compute the estimates via a formal model

Three models are useful• From scratch, for reuse, with reuse

In addition, it should be considered• Losses (cost) due to TTM windows• ROI

6

The Economical Model - cont’d The Economical Model - cont’d

Definitions• Eff [pm] global development effort for a project

• T [m] time to develop the project for a proper team of R designers

• S project size (Klines of code)

In general, the cost C is proportional to Eff

C = k * Eff

The top-level relations are those of COCOMO-2

Eff = A * SB T = A2 * EffB2

so that R = Eff / T

7

Factors of the EMFactors of the EM

A, A2 are multiplicative factors for the effort• Personnel, product, project

B, B2 account for economy/diseconomy originates in developing projects of different sizes• Familiarity, flexibility, group cohesion, risk-resolution,

maturity of the development process

Typical values for different project complexities

For our purposes, the selected formalism to estimate S is VHDL

complexity

8

EM for reuse: static aspectsEM for reuse: static aspects

Integration costs can offset the reuse benefits

Static aspects

• SMes is the equivalent size for a module M to be

reused whose original size is SM

• AA [0..8] Evaluation and selection (Assessment and Assimilation)

• CU Code Undestanding and UNFM Unfamiliarity• AAF Modification. It depends on Percent Design

Modified (DM), Percent Code Modified (CM)and the integration for the modified code

(IM)

SMes=0.01 SM[AA+AAF+(1+0.02 CU) UNFM] AAF 0.5

SMes=0.01 SM[AA+AAF+CU UNFM] AAF > 0.5

SMes is used to compute Eff and T for reuse of M

9

EM for reuse - dynamic aspectsEM for reuse - dynamic aspects

Key point: prediction of the design costs while considering the evolution of productivity• Pr (productivity): # tested gates

produced in one month Pr = gates/Eff

• G: # of gates after t years G = 1.588t G0

• Steady improvement of EDA tools produces

PrMt = (1+ qM)t PrM0 with qM=0.3 - 0.25

Design for Reuse Factor (DRF 1.5 - 4.0) captures the effort to design a component for reuse

Design for Integration Factor (DOIF 0.1 - 0.3) considers the trend of the integration effort

Collapsing of the three equations reveal the evolution over the years of the effort for reuse and for single use

10

Project size estimationProject size estimation

Starting point of any analysis is the project size S• Typically underestimated from 50%-150%

For VHDL we split S in two componentsS = Ssystem + Stestbench

Estimation of Ssystem

• Lines of code VHDL (KLOC or LOCVHDL)

• Function Point VHDL (FPVHDL)

LOCVHDL problems

• Requires a well-structured and detailed view of the project to obtain reliable values

• VHDL is inherently parallel, and the different statements vary in expressiveness and complexity

11

LOCVHDL : direct metricLOCVHDL : direct metric

Direct computation of LOC through analysis of the different contributes

• Port (I/O), signal, concurrent statements, package and library

• Processes and components are the relevant ones

• Components• LOC is of the same order of magnitude of the

signals composing the component interface ( e.g. LOCcomp = 1.5 * N )

• Processes• Inputs: primary in and out of the process• Vectors, signals have weight = 1, while records must be

decomposed and only the relevant fields are considered• LOC is a parabolic function of the number of inputs and

outputs

12

Example of LOCVHDLExample of LOCVHDL

ctrl: process(mpcio, r) variable v : pci_type; variable ready, mexc : std_logic; begin v.data := (others => '0'); v.state := '0'; ready := '0'; mexc := '0';-- pragma translate_off v := r; case r.state is when '0' => if mpcio.en = '1' then v.state := '1'; v.data := mpcio.addr; ready := '1'; mexc := not mpcio.read; end if; when others => v.state := '0'; end case; if rst = '0' then v.state := '0'; end if;-- pragma translate_on ri <= v; mpcii.data <= r.data; mpcii.ready <= ready; mpcii.mexc <= mexc; end process;

Inputs:mpco - 4 componentsr - 2 components

rst - 1 componentOutputs:

ri - 2 components mpcii - 3 components

ctrl

Actual: 25Estimated: 33

13

Function Point VHDLFunction Point VHDL

Suitable to the analysis of new projects• Requires a structured but not necessarily detailed view of

the project• The starting point is a reasonable hierarchical

decomposition; the primary inputs and outputs of the system and subsystems must be known

• From the description, some functional classed are identified and associated with a weight depending on their complexity

• To quantify S, the weights are finally converted in LOC Elements of a generic specification vs VHDL

• General activities: acquisition of information, processing, memory access and emitting of information

• Functional categories in VHDL: primary inputs and outputs, basic blocks, internal signals, interface signals

14

FPVHDL : weights calculationFPVHDL : weights calculation

A weight is associated with each element composing a given unit, according to a lookup table considering the complexity

Given a functional unit k, the average of the weights of its mk components is considered

For an intermediate node, all the children contributes are summed up

For the entire system, all the contributes are collapsed

k

m

iik

k m

wFP

k

1

,

15

FPVHDL : weights calculation - cont’dFPVHDL : weights calculation - cont’d

Primary inputs• Contains inputs from specification surrounding the

system both for control and data acquisition

• Complexity depends on • Uniformity of data constituting the inputs, ie.e type• Number of involved blocks

Primary outputs• Similar to primary inputs but with a different lookup

table

16

FPVHDL : weights calculation - cont’dFPVHDL : weights calculation - cont’d

Internal signals• Involves uniformity of data and the control

information exchanged among components and subsystems

• The table reports the correspondence between the number of uniform data constituting the signal and its complexity

Interface signals• Similar to internal signals but with a different lookup

table

17

FPVHDL : weights calculation - cont’dFPVHDL : weights calculation - cont’d Basic Blocks

• Are instances of blocks identifiable from specification

• It is important to identify those functionalities that will be converted in VHDL as components or processes

• Test-bench functionalities can be considered as basic blocks

• The complexity of a basic block depends on• Number of concurrent sub-blocks composing it• Level of communication between sub-blocks, expressed as

a function of the complexity of internal and external signals

18

From FPVHDL to LOCFrom FPVHDL to LOC

In literature there exist coefficients to convert FP to LOC for different languages

We found sound the following conversion factors• For single node

LOC = 19 * FPVHDL

• For a node at level Lev of the graph hierarchy

LOC = 19 * FPVHDL * Lev

• The value Lev is computed considering a “livelized” procedure where the top entity assumes the maximum value

• LOC is function of the level used to estimates the global cost of a given module when its final decomposition is unknown and its level is predictable

19

From FPVHDL to LOC : exampleFrom FPVHDL to LOC : example

In the example, C can be further decomposed insub-modules

The LOC for the overall project is the sum of the local costs of A, B and the global cost of C

A (LEVEL 4)

B (LEVEL3)

C (LEVEL 3)

(?) (LEVEL 2)

(?) (LEVEL 2)

(?) (LEVEL 1)

A

C B

Level 1

Level 2

Level 3

Level 4

LOC = 19 * (FPVHDL-A + FPVHDL-B + FPVHDL-C* 3)

20

Experimental resultsExperimental results

Real world complex VHDL benchmark: LEON-1• 32-bits SPARC V8 architecture for embedded apps

• 7655 lines of codes partitioned in 20 files

• Sufficiently documented and well structured example

21

Example: FP analysis of the UARTExample: FP analysis of the UART

• Primary inputs• 3 elementary involving three subcomp (A complexity)• 2 structured in joining only a subcomp (A complexity)

• Internal signals• 1 small vector (VL complexity)• 2 records each of 34 entries (H complexity)

• Primary outputs• 2 elements of L complexity

FPVHDL= 21

LOC= 21 * 19 = 399

22

LEON-1: structure and local costsLEON-1: structure and local costsLEON (local cost actual: 219; estimated: 190)

MCORE (local cost actual: 241; estimated: 145)

PERI (local cost 162)

PROC (local cost actual: 166; estimated: 183)

CACHE (local cost actual: 112; estimated: 235)

Dcache (local cost actual: 508; estim.: 376)

Icache (local cost actual: 341; estim.: 399)

Cachemem (local cost actual: 228; estim.: 304)

IU (local cost actual: 2255; estimated: 2390)

REGFILE (local cost actual: 204; estimated: 183)

UART (local cost actual: 395; estimated: 445)

TIMER (local cost actual: 227; estimated: 155 )

IOPORT (local cost actual: 180; estimated: 203)

IRQCTRL (local cost actual: 143; estimated: 161)

MCTRL (local cost actual: 1103; estimated: 912)

DMA (local cost actual: 138; estimated: 275)

RSTGEN (local cost actual: 61; estimated: 57)

MPCIIF (local cost actual: 104, estimated: 106)

PCI (local cost actual: 53, estimated: 91)

PADS (local cost 840) Library

CLOCKGEN (local cost 75) Library

Local cost [LOC] including BODY and ARCHITECTURE, no comments and a single statement per line

23

LEON-1: global costsLEON-1: global costs The table reports the global estimated costs, i.e.

number of VHDL lines constituting the portion of the project included in the considered module, supposing the corresponding hierarchical level

Example: LEON module

• FPVHDL-LEON 85

• Global Cost = 2206 *19* 5 = 11030 LOC

24

Concluding remarksConcluding remarks

The paper approached the problem of predicting the cost of large size VHDL-based projects

A conceptual analysis framework has been identified to analyze the effectiveness of reuse

The focus has been on the evaluation of the project size through the introduction of FP analysis

Soundness of the model has been assessed experimentally, considering both small benchmarks and a 32-bits microprocessor• Avg accuracy of local estim. is ~ 20%, variance 15%;

however, errors tend to compensate• Predictions starting only from top-level view of the

project have accuracy of 40%

25

Future workFuture work

Hw/Sw systems: extension to cover also the sw costs in a unified analysis strategy

Hybrid approach to include custom cost figures for regularly generated sub-components (e.g., caches)

Introduction of risk-analysis virtual costs

Integration with other metrics to evaluate the reuse effort