[daniele paolo scarpazza @ codes+isss 2003, october 3 rd 2003, newport beach, ca, usa][slide # 1/...

[Daniele Paolo Scarpazza @ CODES+ISSS 2003, October 3rd 2003, Newport Beach, CA, USA][Slide # 1/ 23]

•Agenda•Context•Objective•Results•Theory• SO• SOG• Bunch• KSOG•Data•Models•Model Tree•Tools•Parser+DB•GUI•Future Developments

Early Estimation of the Size of VHDL Projects

POLITECNICO DI MILANODipartimento di Elettronica e Informazione

(Faculty of Engineering – Department of Computer Engineering)

D. P. Scarpazza, W. Fornaciari, F. Salice

Speaker: Daniele Paolo [email protected]

www.elet.polimi.it/~scarpazz

CODES+ISSS 2003, Newport Beach, CA, USA



Agenda• Context

• Objectives

• Results

• Theory

• Data

• Models

• Tools

• Future Developments



Context: impacts on cost• Embedded system design process phases:

• choices taken during concept study phase impact much more on costs than ones of implementation;

• Human resources are the scarcest and the most expensive;• We wish a cost-driven approach in order to take system-

level design-choices ASAP, i.e. in the concept study phase;• Filling the gap: delay, silicon area, power consumption

estimation now possible at the system level: what about development effort?

Concept study Detailed Implementation ...

Cost span due to different

implementations

Time

Cost span due to different concepts

Development effort

Cost

s



Objective

A methodology such that:– Given a project specification:

• of an embedded system;

• expressed in VHDL;

• possibly partial;

– an estimate is returned:• of the final project size;

• expressed in lines of code;

• as accurate as possible;

• exploiting “well” all available information

• gracefully scaling accuracy when the amount of available information decreases



Results• We devised such a methodology. It

exhibits the following properties:– it features a rigorous but flexible

formalization;

– it shows a good coefficient of correlation between real and estimated data:

• 0.8627 in internal validation;

• 0.8713 in external validation;(test performed in actual operating conditions);

– there is graceful degradation of accuracy when available amount of information decreases;

– there are interesting future developments;



Results (internal validation)



Results (external validation)



The Theory: Purpose

• Rigorous formalization of any VHDL project, in any phase of its development process;

• It actualizes in the ”known syntax object graph” (KSOG);

• We proved that it is possible to create the KSOG of any possible VHDL project and set of specifications;



Syntax Objects• The nodes of the syntax object graph;

• They represent code units(entitites, architectures, processes, subprograms, ...)

• Easily recognizable by a syntax analyzer;

• Connected to each other by oriented relationships: contains and references, e.g.:– If a process P is declared inside architecture

A, we say that A contains P;

– If an architecture A instances an entity E as a subsystem, we say that A references E;



The Syntax Object Graph•It represents all syntax objects and their relationships;•In general not a tree nor a DAG (structural recursion allowed);•Example:



The Bunches• They are elements of intermediate granularity,

between the syntax object and the SOG;

• They are informally composed by and entity and “whatever belongs to it”;

Any given SOG can be partitioned into bunches*.

The size of a given SOG is the sum of the size of its bunches.



Extending SOGs to K-SOGs• SOGs suitably

model finished projects, completely known in every detail;

• But we need to model specifications, i.e. partially-known projects

• Represent the so-called metacognitive information ~ “How much do I know?”•We extend the SOG to a KSOG:

–nodes can be partially known–nodes have a label indicating their knowledge state;–(contraints are imposed on child/referenced nodes);



Data: The Project Base60 real projects were gathered from

“open”sources:

• Projects cover a wide spectrum:• GPP, DSP, application notes, FFT, libraries ...

• Large number of cases:• a wide training+test set allows for a good model

estimation, especially for SO and Bunch models;

Tuning Validation Total

Projects 41 19 60

Files 573 469 1 042

Lines 388 790 222 188 610 978

Size 20.0M 16.5M 36.5M

Architectures 967 570 1 537

Signals 58 836 39 017 97 835



The Models• Models were prepared for the 3

granularity levels: graph, bunch and syntax object; each level recursively reuses lower-level estimates;

• Models are available in several variants, each requiring a different amount of information;

• Model design strategy: – Choice of the scenarios:– Correlation study and variable

selection;– Model identification, estimation;– Internal and external validation;



The Model Tree



Tools



Tools: VHDL Parser + Database●VHDL Parser:

● includes a lexical filter to remove comments and cosmetic empty lines

● remake of a free syntax (by T. Dettmer, orig. by den Ouden, Hofstede: incomplete, non std IEEE 1076-1993);

● extension, standardization, validation, creation ex-novo of semantic actions;

● Result: 600 kLOC parsed, 0 errors.●Database

● contains information on any syntax object● allows complex and structured statistics

extraction;● implemented as 22+4 tables in mySql● the enabling technology for the

experiments



Parser-database interaction example

For each syntax object found in the parsing...architecture struct of reg4 is signal int clk : bit ;begin bit0 : entity work.d latch(basic) port map (d0, int clk, q0); bit1 : entity work.d latch(basic) port map (d1, int clk, q1); bit2 : entity work.d latch(basic) port map (d2, int clk, q2); bit3 : entity work.d latch(basic) port map (d3, int clk, q3); gate : entity work.and2(basic) port map (en, clk, int clk);end architecture struct;




... the grammar rules recognizing the construct are identified ...architecture struct of reg4 is signal int clk : bit ;begin bit0 : entity work.d latch(basic) port map (d0, int clk, q0); bit1 : entity work.d latch(basic) port map (d1, int clk, q1); bit2 : entity work.d latch(basic) port map (d2, int clk, q2); bit3 : entity work.d latch(basic) port map (d3, int clk, q3); gate : entity work.and2(basic) port map (en, clk, int clk);end architecture struct;

<architecture body> ::= architecture <identifier> of <entity name> is <architecture declarative part> begin <architecture statement part> end [architecture] [<architecture simple name>] ;




• ... lexical and context information are extracted..

architecture struct of reg4 is signal int clk : bit ;begin bit0 : entity work.d latch(basic) port map (d0, int clk, q0); bit1 : entity work.d latch(basic) port map (d1, int clk, q1); bit2 : entity work.d latch(basic) port map (d2, int clk, q2); bit3 : entity work.d latch(basic) port map (d3, int clk, q3); gate : entity work.and2(basic) port map (en, clk, int clk);end architecture struct;


PROJECT NAME ExampleENTITY NAME reg4ARCHITECTURE NAME structFILE NAME /root/sources/fg_01_11.vhdSTART LINE 1START COLUMN 14END LINE 19IDENTIFIER LENGTH 6HOMOGENEITY NULLLINE COUNT 19




• ... and stored in the corresponding database tables.

architecture struct of reg4 is signal int clk : bit ;begin bit0 : entity work.d latch(basic) port map (d0, int clk, q0); bit1 : entity work.d latch(basic) port map (d1, int clk, q1); bit2 : entity work.d latch(basic) port map (d2, int clk, q2); bit3 : entity work.d latch(basic) port map (d3, int clk, q3); gate : entity work.and2(basic) port map (en, clk, int clk);end architecture struct;


PROJECT NAME ExampleENTITY NAME reg4ARCHITECTURE NAME structFILE NAME /root/sources/fg_01_11.vhdSTART LINE 1START COLUMN 14END LINE 19IDENTIFIER LENGTH 6HOMOGENEITY NULLLINE COUNT 19

PROJECT ENTITY ARCHITECTURE FILE START START END IDENTIFIER HOMOGENEITY LINENAME NAME NAME NAME LINE COLUMN LINE LENGTH COUNT

Leon Mul1733 Struct /root/... 172 16 35519 6 NULL 35348Leon Mul3333 Struct /root/... 37896 16 89723 6 NULL 51828Example Reg4 Struct /root/... 1 14 19 6 NULL 19ERC32 MEC MEGGen /root/... 21980 14 32891 6 NULL 10912

... ... ... ... ... ... ... ... ... ...



GUI Features• visually manages projects, constituent files and state;• automates parser invocation and output log analysis;• generates reports, analyses and represents SOGs;• invokes model tuning, application and validation;



Future Developments• Application-specialized models:

– in landscape LOC = f(<available vars>), datapoints tend to accumulate in clusters;

– current syntax object models are already specialized on type and mode: application specialization (timer, cache, ALU, multiplier, ...) should increase accuracy;

• Extension to other languages• More data for better SOG-model

tuning:– currently available data ok for SO and Bunch

model, few for SOG models;– all VHDL projects available on the Internet used

• Reconnection to Function Points theory:– FP theory applicable in principle, but evidences

prove LOC/FP=19 ratio to be wrong;



The End

Thanks for your attention.

[daniele paolo scarpazza @ codes+isss 2003, october 3 rd 2003, newport beach, ca, usa][slide # 1/...

Documents