- 0 - P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hoofdstuk 2...

- 1 - P. Marwedel, Univ. Dortmund, Informatik 12, 2003

Universität Dortmund

Hoofdstuk 2Systeemspecificatietechnieken

2.2 Specificatietalen

Prof. dr. ir. Dirk Stroobandt

Academiejaar 2004-2005

De transparanten van hoofdstuk 2 werden overgenomen van Prof. Peter Marwedel (Universiteit

Dortmund) en waar nodig bijgewerkt.

Prof. dr. ir. Dirk Stroobandt

Academiejaar 2004-2005

De transparanten van hoofdstuk 2 werden overgenomen van Prof. Peter Marwedel (Universiteit

Dortmund) en waar nodig bijgewerkt.



Inhoud (deel 1)

Inleiding over Ingebedde systemen, System-on-Chip en Platform-gebaseerd ontwerp

Systeemspecificatietechnieken

Specificatietalen– MSC, UML– Process networks– JAVA– VHDL– SystemC– Verilog, SystemVerilog– SpecC– Modeleringsniveaus– Vergelijking talen

Exploratie van de ontwerpruimte







Message sequence charts (MSC)

Graphical means for representing schedules; time used vertically, geographical distribution horizontally.

Graphical means for representing schedules; time used vertically, geographical distribution horizontally.

No distinction between accidental overlap and synchronizationNo distinction between accidental overlap and synchronization



Time/distance diagrams as a special case©

ww

w.o

pen

tra

ck.c

h



PROs:• Appropriate for visualizing schedules,• Proven method for representing schedules in transportation.• Standard defined: ITU-TS Recommendation Z.120:

Message Sequence Chart (MSC), ITU-TS, Geneva, 1996.

• Semantics also defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC)—Annex B: Algebraic Semantics of Message Sequence Charts, ITU-TS, Geneva.

CONS:• describes just one case, no timing tolerances:“What does

an MSC specification mean: does it describe all behaviors of a system, or does it describe a set of sample behaviors of a system?” *

* H. Ben-Abdallah and S. Leue, “Timing constraints in message sequence chart specifications,” in Proc. 10th International Conference on Formal Description Techniques FORTE/PSTV’97, Chapman and Hall, 1997.

PROs:• Appropriate for visualizing schedules,• Proven method for representing schedules in transportation.• Standard defined: ITU-TS Recommendation Z.120:

Message Sequence Chart (MSC), ITU-TS, Geneva, 1996.

• Semantics also defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC)—Annex B: Algebraic Semantics of Message Sequence Charts, ITU-TS, Geneva.

CONS:• describes just one case, no timing tolerances:“What does

an MSC specification mean: does it describe all behaviors of a system, or does it describe a set of sample behaviors of a system?” *

* H. Ben-Abdallah and S. Leue, “Timing constraints in message sequence chart specifications,” in Proc. 10th International Conference on Formal Description Techniques FORTE/PSTV’97, Chapman and Hall, 1997.

Message sequence charts



Life Sequence Charts (LSCs)- Distinction between Universal and Existential Charts -

W. Damm, D. Harel: LSCs: Breathing Life into Message Sequence Charts, Formal Methods in System Design, 19, 45–80, 2001



Use in UML

Heavy usage in UML

(known as sequence diagram);

No precise timing.

Many kinds of additional elements

Heavy usage in UML

(known as sequence diagram);

No precise timing.

Many kinds of additional elements

fro

m:

htt

p:/

/ ww

w.g

en

tlew

are

.co

m/p

rod

uc t

s/d

ocu

me

nta

t ion

/ Po

seid

on

Us e

rsG

uid

e/x

14

62

.htm

l



State machine diagrams (UML 2.x)State diagrams (UML 1.x)

State machine diagrams/State diagrams:UML includes variant of StateCharts

State machine diagrams/State diagrams:UML includes variant of StateCharts

© S

cott

Am

bler

, A

gile

Mod

elin

g,//

ww

w.a

gile

mod

elin

g.co

m,

2003



Activity diagram

© Cris Kobryn: UML 2001: A Standardization Odyssey, CACM, October, 1999

Extended Petri nets. Include decisions (like in flow charts). Graphical notation similar to SDL.

„swimlane“



Deployment diagram

Describe execution architecture of systems (HW or SW). Important for embedded systems.

Describe execution architecture of systems (HW or SW). Important for embedded systems.

Example including some details:

© Scott Ambler, Agile Modeling,//www.agilemodeling.com, 2003



Deployment diagram- More concise example -

© Scott Ambler, Agile Modeling, //www.agilemodeling.com, 2003



Use case diagram

Captures typical application scenariosCaptures typical application scenarios

//sds.hss.cmu.edu/courses/Syllabi/ids/271/umlfaq.asp#ucdefinition




Package diagram

Represents the partitioning into packages. Introduces hierarchy.

Example: Use case package diagram.

Represents the partitioning into packages. Introduces hierarchy.

Example: Use case package diagram.




Class diagrams

Describe object classes. Example:Describe object classes. Example:




Timing diagrams

Can be used to show the change of the state of an object over time.

Can be used to show the change of the state of an object over time.




Component diagram


.. model the business software architecture, the technical software architecture, … . Physical architecture issues, in particular hardware issues, are better addressed via UML

deployment diagrams ..

Represent components used in applications:

Represent components used in applications:



Additional diagrams

• Communication diagram (called collaboration diagram in UML 1.x)

• Object diagrams• Interaction overview diagrams• Composite structure diagrams

• Communication diagram (called collaboration diagram in UML 1.x)

• Object diagrams• Interaction overview diagrams• Composite structure diagrams

Less frequently used



Evaluation

Precise specification of semantics?Typically combined with SDL or C++

Precise specification of semantics?Typically combined with SDL or C++



UML for real-time?

Initially not designed for real-time.

Lacking features (1998):• Partitioning of software into tasks and processes• specifying timing• specification of hardware components

Projects on defining real-time UML based on previous work• ROOM [Selic] is an object-oriented methodology for real-

time systems developed originally at Bell-Northern Research.

• „UML profile for schedulability, performance and time“http://www.rational.com/uml/resources/documentation

• …

Initially not designed for real-time.

Lacking features (1998):• Partitioning of software into tasks and processes• specifying timing• specification of hardware components

Projects on defining real-time UML based on previous work• ROOM [Selic] is an object-oriented methodology for real-

time systems developed originally at Bell-Northern Research.

• „UML profile for schedulability, performance and time“http://www.rational.com/uml/resources/documentation

• …



Inhoud (deel 1)











Process networks

Many applications can be specified in the form of a set of communicating processes.Example: system with two sensors:

Many applications can be specified in the form of a set of communicating processes.Example: system with two sensors:

mux

temperature sensor

humidity sensor

FIFO

Alternating readloop read_temp; read_humiuntil false;of the two sensors not the right approach.



The case for multi-process modelingin imperative languages

MODULE main; TYPE some_channel = (temperature, humidity); some_sample : RECORD value : integer; line : some_channel END; PROCESS get_temperature; VAR sample : some_sample; BEGIN LOOP sample.value := new_temperature; IF sample.value > 30 THEN .... sample.line := temperature; to_fifo(sample); END END get_temperature;

PROCESS get_humidity; VAR sample : some_sample; BEGIN LOOP sample.value := new_humidity; sample.line := humidity; to_fifo(sample); END END get_humidity;

BEGIN get_temperature; get_humidity; END;

• Blocking calls new_temperature, new_humidity• Structure clearer than alternating checks for

new values in a single process

How to model dependencies between tasks/processes?



Dependences between processes/tasks

Get_tem-perature

Get_humidity

FIFO

General discussion of process networks

main



Task graphs

Def.: A dependence graph is a directed graph G=(V,E) in which E V V is a partial order.

If (v1, v2) E, then v1 is called an immediate predecessor of v2 and v2 is called an immediate successor of v1.

Suppose E* is the transitive closure of E.If (v1, v2) E*, then v1 is called a predecessor of v2 and v2 is called a successor of v1.

Def.: A dependence graph is a directed graph G=(V,E) in which E V V is a partial order.

If (v1, v2) E, then v1 is called an immediate predecessor of v2 and v2 is called an immediate successor of v1.

Suppose E* is the transitive closure of E.If (v1, v2) E*, then v1 is called a predecessor of v2 and v2 is called a successor of v1.

Nodes are assumed to be a „program“ described in some programming language, e.g. C or Java.

Nodes are assumed to be a „program“ described in some programming language, e.g. C or Java.

Sequence constraint



Task graphs 1. Timing information -

Task graphs may contain additional information,

for example: Timing information

Task graphs may contain additional information,

for example: Timing information

]



Task graphs 2. I/O-information



Task graphs 3. Shared resources



Task graphs 4. Periodic schedules

.. infinite task graphs



Task graphs 5. Hierarchical task graphs -



Multi-thread graphs (IMEC)

Def.: A multi-thread graph M is defined as an 11-tuple(O, E, V, D, , , , Elat, Eresp, i, av) with:

• O: set of operation nodes,• E: set of control edges,• V, D, : refer to the access of variables,: is the set of input/output nodes,: associates execution latency intervals with all threads,• Elat, Eresp, i, av are timing constraints.

Def.: A multi-thread graph M is defined as an 11-tuple(O, E, V, D, , , , Elat, Eresp, i, av) with:

• O: set of operation nodes,• E: set of control edges,• V, D, : refer to the access of variables,: is the set of input/output nodes,: associates execution latency intervals with all threads,• Elat, Eresp, i, av are timing constraints.



MTG graphs: graphical notation



Multi-thread graph (Example)



Asynchronous message passing:Kahn process networks

Kahn process networks are executable task graphs.

Communication is assumed to be via infinitely large FIFOs

Kahn process networks are executable task graphs.

Communication is assumed to be via infinitely large FIFOs



Asynchronous message passing:Synchronous data flow (SDF)

Asynchronous message passing=tasks do not have to wait until output is accepted.

Synchronous data flow =all tokens are consumed at the same time.

Asynchronous message passing=tasks do not have to wait until output is accepted.

Synchronous data flow =all tokens are consumed at the same time.

SDF model allows static scheduling of token production and consumption.In the general case, buffers may be needed at edges.

SDF model allows static scheduling of token production and consumption.In the general case, buffers may be needed at edges.



Synchronous message passing:CSP

• CSP (communicating sequential processes)[Hoare, 1985],rendez-vous-based communication:Example:

• CSP (communicating sequential processes)[Hoare, 1985],rendez-vous-based communication:Example:

process A..var a ... a:=3; c!a; -- outputend

process A..var a ... a:=3; c!a; -- outputend

process B..var a ... ... c?b; -- inputend

process B..var a ... ... c?b; -- inputend



Synchronous message passing:ADA

After Ada Lovelace (said to be the 1st female programmer).

US Department of Defense (DoD) wanted to avoid multitude

of programming languages

Definition of requirements

Selection of a language from a set of competing designs

(selected design based on PASCAL)

ADA’95 is object-oriented extension of original ADA.

Salient: task concept

After Ada Lovelace (said to be the 1st female programmer).

US Department of Defense (DoD) wanted to avoid multitude

of programming languages

Definition of requirements

Selection of a language from a set of competing designs

(selected design based on PASCAL)

ADA’95 is object-oriented extension of original ADA.

Salient: task concept



Synchronous message passing:Using of tasks in ADA



Synchronous message passing:ADA-rendez-vous

task screen_output is entry call_ch(val:character; x, y: integer); entry call_int(z, x, y: integer);end screen_out;task body screen_output is... select accept call_ch ... do .. end call_ch; or accept call_int ... do .. end call_int; end select;

task screen_output is entry call_ch(val:character; x, y: integer); entry call_int(z, x, y: integer);end screen_out;task body screen_output is... select accept call_ch ... do .. end call_ch; or accept call_int ... do .. end call_int; end select;

Sending a message:begin screen_out.call_ch('Z',10,20); exception when tasking_error => (exception handling)end;

Sending a message:begin screen_out.call_ch('Z',10,20); exception when tasking_error => (exception handling)end;



Inhoud (deel 1)











Java (1)

Potential benefits: • Clean and safe language• Supports multi-threading (no OS required?)• Platform independence (relevant for telecommunications)

Potential benefits: • Clean and safe language• Supports multi-threading (no OS required?)• Platform independence (relevant for telecommunications)

Problems:• Size of Java run-time libraries? Memory requirements.• Access to special hardware features • Garbage collection time • Non-deterministic dispatcher for threads • Performance problems• Checking of real-time constraints

Problems:• Size of Java run-time libraries? Memory requirements.• Access to special hardware features • Garbage collection time • Non-deterministic dispatcher for threads • Performance problems• Checking of real-time constraints



Java 2 Micro Edition (J2ME)

CVM KVM

J2ME CDC J2ME CLDC

Au

tom

otiv

eP

rofil

e

TVP

rofil

ePersonal

Profile

RMIProfile

FoundationProfile

HandheldProfile

MIDProfile

Limited support of Java More flexibility than J2ME CDCMin. 320 kB runtime support [Courtesy:

W. Rosenstiel, 2000]

Smaller: CardJava

Smaller: CardJava

Larger: J2SE

Larger: J2SE

MIDP 1.0/ 2.0 API



Currently relevant real-time extension to Java:

Real-time specification for Java (JSR-1), see //www.rtj.orgReal-time specification for Java (JSR-1), see //www.rtj.org



VHDL

HDL = hardware description languageTextual HDLs replaced graphical HDLs in the 1980‘ies

(better description of complex behavior).In this course:VHDL = VHSIC hardware description languageVHSIC = very high speed integrated circuit1980: Definition started by DoD in 19801984: first version of the language defined, based on ADA

(which in turn is based on PASCAL)1987: revised version became IEEE standard 10761992: revised IEEE standardmore recently: VHDL-AMS: includes analog modeling

HDL = hardware description languageTextual HDLs replaced graphical HDLs in the 1980‘ies

(better description of complex behavior).In this course:VHDL = VHSIC hardware description languageVHSIC = very high speed integrated circuit1980: Definition started by DoD in 19801984: first version of the language defined, based on ADA

(which in turn is based on PASCAL)1987: revised version became IEEE standard 10761992: revised IEEE standardmore recently: VHDL-AMS: includes analog modeling



Entities and architectures

Each design unit is called an entity.

Entities are comprised of entity declarations and one or several architectures.

Each design unit is called an entity.

Entities are comprised of entity declarations and one or several architectures.

Each architecture includes a model of the entity. By default, the most recently analyzed architecture is used. The use of another architecture can be requested in a configuration.

Each architecture includes a model of the entity. By default, the most recently analyzed architecture is used. The use of another architecture can be requested in a configuration.



The full adder as an example- Entity declaration -

Entity declaration:

entity full_adder is

port(a, b, carry_in: in Bit; -- input ports

sum,carry_out: out Bit); --output ports

end full_adder;

Entity declaration:

entity full_adder is

port(a, b, carry_in: in Bit; -- input ports

sum,carry_out: out Bit); --output ports

end full_adder;



The full adder as an example- Architectures -

Architecture = Architecture header + architectural bodiesArchitecture = Architecture header + architectural bodies

architecture behavior of full_adder is begin sum <= (a xor b) xor carry_in after 10 Ns; carry_out <= (a and b) or (a and carry_in) or (b and carry_in) after 10 Ns; end behavior;

architecture behavior of full_adder is begin sum <= (a xor b) xor carry_in after 10 Ns; carry_out <= (a and b) or (a and carry_in) or (b and carry_in) after 10 Ns; end behavior;

Architectural bodies can be- behavioral bodies or - structural bodies.

Bodies not referring to hardware components are called behavioral bodies.

Architectural bodies can be- behavioral bodies or - structural bodies.

Bodies not referring to hardware components are called behavioral bodies.



The full adder as an example- Simulation results -

Behavioral description different from the one shown.Behavioral description different from the one shown.



Structuralbodies

architecture structure of full_adder iscomponent half_adder

port (in1,in2:in Bit; carry:out Bit; sum:out Bit); end component;

component or_gate port (in1, in2:in Bit; o:out Bit); end component; signal x, y, z: Bit; -- local signals begin -- port map section i1: half_adder port map (a, b, x, y); i2: half_adder port map (y, carry_in, z, sum); i3: or_gate port map (x, z, carry_out); end structure;

architecture structure of full_adder iscomponent half_adder

port (in1,in2:in Bit; carry:out Bit; sum:out Bit); end component;

component or_gate port (in1, in2:in Bit; o:out Bit); end component; signal x, y, z: Bit; -- local signals begin -- port map section i1: half_adder port map (a, b, x, y); i2: half_adder port map (y, carry_in, z, sum); i3: or_gate port map (x, z, carry_out); end structure;



Multi-valued logic and standard IEEE 1164

How many logic values for modeling?

Two ('0' and '1') or more?

If real circuits have to be described, some abstraction of the

resistance (inversely-related to the strength) is required.

We introduce the distinction between:• the logic level (as an abstraction of the voltage) and• the strength (as an abstraction of the current drive

capability) of a signal.

The two are encoded in logic values.

How many logic values for modeling?

Two ('0' and '1') or more?

If real circuits have to be described, some abstraction of the

resistance (inversely-related to the strength) is required.

We introduce the distinction between:• the logic level (as an abstraction of the voltage) and• the strength (as an abstraction of the current drive

capability) of a signal.

The two are encoded in logic values.



IEEE 1164

VHDL allows user-defined value sets.

Each model could use different value sets (unpractical)

Definition of standard value set according to standard IEEE 1164:

{'0', '1', 'Z', 'X', 'H', 'L', 'W', 'U', '-'} ‘Z’: high impedance (disconnected outputs)

‘X’: Unknown, undefined

‘H’, ‘L’, ‘W’: weak ‘1’, ‘0’, ‘X’

'U': un-initialized signal; used by simulator to initialize all not explicitly initialized signals.

‘-’: don’t care

VHDL allows user-defined value sets.

Each model could use different value sets (unpractical)

Definition of standard value set according to standard IEEE 1164:

{'0', '1', 'Z', 'X', 'H', 'L', 'W', 'U', '-'} ‘Z’: high impedance (disconnected outputs)

‘X’: Unknown, undefined

‘H’, ‘L’, ‘W’: weak ‘1’, ‘0’, ‘X’

'U': un-initialized signal; used by simulator to initialize all not explicitly initialized signals.

‘-’: don’t care



Input don‘t care

'-' denotes input don't care.

Suppose: f undefined for a=b=c='0';

Then, we could like specifying this in VHDL as

f <= select a & b & c

'1' when "10-" -- first term

'1' when "-11" -- second term

'X' when "000"

Simulator would check if a & b & c = "10-", i.e. if c='-'.

Since c is never assigned a value of '-', this test would always fail. Simulator does not know that '-' means either '1' or '0', since it does not include any special handling for '-'.

'-' denotes input don't care.

Suppose: f undefined for a=b=c='0';

Then, we could like specifying this in VHDL as

f <= select a & b & c

'1' when "10-" -- first term

'1' when "-11" -- second term

'X' when "000"

Simulator would check if a & b & c = "10-", i.e. if c='-'.

Since c is never assigned a value of '-', this test would always fail. Simulator does not know that '-' means either '1' or '0', since it does not include any special handling for '-'.

.),,( bcbacbaf



Function std_match

Special meaning of '-' can be used in special function std_match.

if std_match(a&b&c,"10-")is true for any value of c, but this does not enable the use of the compact select statement.

The flexibility of VHDL comes at the price of less convenient specifications of Boolean functions.

Special meaning of '-' can be used in special function std_match.

if std_match(a&b&c,"10-")is true for any value of c, but this does not enable the use of the compact select statement.

The flexibility of VHDL comes at the price of less convenient specifications of Boolean functions.



VHDL processes

Processes model parallelism in hardware.General syntax:label: --optionalprocess declarations --optionalbegin statements --optionalend process

a <= b after 10 ns is equivalent toprocess begin a <= b after 10 ns end

Processes model parallelism in hardware.General syntax:label: --optionalprocess declarations --optionalbegin statements --optionalend process

a <= b after 10 ns is equivalent toprocess begin a <= b after 10 ns end



Wait-statements

Four possible kinds of wait-statements:• wait until signal list;

wait until signal changes;Example: wait until a;

• wait until condition;wait until condition is met;Example: wait until c='1';

• wait for duration;wait for specified amount of time;Example: wait for 10 ns;

• wait;suspend indefinitely

Four possible kinds of wait-statements:• wait until signal list;

wait until signal changes;Example: wait until a;

• wait until condition;wait until condition is met;Example: wait until c='1';

• wait for duration;wait for specified amount of time;Example: wait for 10 ns;

• wait;suspend indefinitely



Sensitivity lists

Sensitivity lists are a shorthand for a single wait on-statement at the end of the process body:

process (x, y) begin prod <= x and y ; end process;

is equivalent to

process begin prod <= x and y ; wait on x,y; end process;

Sensitivity lists are a shorthand for a single wait on-statement at the end of the process body:

process (x, y) begin prod <= x and y ; end process;

is equivalent to

process begin prod <= x and y ; wait on x,y; end process;



VHDL semantics: global control

According to the original standards document:

The execution of a model consists of an initialization phase followed by the repetitive execution of process statements in the description of that model.

Initialization phase executes each process once.

According to the original standards document:

The execution of a model consists of an initialization phase followed by the repetitive execution of process statements in the description of that model.

Initialization phase executes each process once.



-simulation cyclesSimulation of an RS-Flipflop

architecture one of RS_Flipflop isbeginprocess: (R,S,Q,nQ) begin Q <= R nor nQ; nQ <= S nor Q; end process;end one;

architecture one of RS_Flipflop isbeginprocess: (R,S,Q,nQ) begin Q <= R nor nQ; nQ <= S nor Q; end process;end one;

0ns 0ns+ 0ns+2

R 1 1 1

S 0 0 0

Q 1 0 0

nQ 0 0 1

0ns 0ns+ 0ns+2

R 1 1 1

S 0 0 0

Q 1 0 0

nQ 0 0 1

0001

1100

0000

0111

1st

2nd

cycles reflect the fact that no real gate comes with zero delay. should delay-less signal assignments be allowed at all?

cycles reflect the fact that no real gate comes with zero delay. should delay-less signal assignments be allowed at all?



-simulation cyclesand deterministic simulation semantics

Semantics of

a <= b;

b <= a; ?

Separation into 2 simulation phases results in deterministic semantics( StateCharts).

Semantics of

a <= b;

b <= a; ?

Separation into 2 simulation phases results in deterministic semantics( StateCharts).



VHDL: Evaluation

• Behavioral hierarchy (procedures and functions),• Structural hierarchy: through structural architectures,

but no nested processes,• No specification of non-functional properties,• No object-orientation,• Static number of processes,• Complicated simulation semantics,• Too low level for initial specification,• Good for intermediate „Esperanto“ language for hardware

generation.

• Behavioral hierarchy (procedures and functions),• Structural hierarchy: through structural architectures,

but no nested processes,• No specification of non-functional properties,• No object-orientation,• Static number of processes,• Complicated simulation semantics,• Too low level for initial specification,• Good for intermediate „Esperanto“ language for hardware

generation.



SystemC: Motivation

• Many standards (e.g. the GSM and MPEG-standards) are published as C programs

Standards have to be translated if special hardware description languages have to be used

• The functionality of many systems is provided by a mix of hardware and software components

Simulations require an interface between hardware and software simulators unless the same language is used for the description of hardware and software

Attempts to describe software and hardware in the same language. Easier said than implemented.Various C dialects used for hardware description.

• Many standards (e.g. the GSM and MPEG-standards) are published as C programs

Standards have to be translated if special hardware description languages have to be used

• The functionality of many systems is provided by a mix of hardware and software components

Simulations require an interface between hardware and software simulators unless the same language is used for the description of hardware and software

Attempts to describe software and hardware in the same language. Easier said than implemented.Various C dialects used for hardware description.



SystemC: Required features

Requirements and solutions for modeling HW in a SW language:

• C++ class library including required functions.• Concurrency: via processes, controlled by sensitivity lists

and calls to wait primitives.• Time: Floating point numbers in SystemC 1.0 and Integer

values in SystemC 2.0; Includes units such as ps, ns, µs etc*.

• Support of bit-datatypes: bitvectors of different lengths; multiple-valued logic (2- and 4-valued logic; resolution*)

• Communication: plug-and-play channel model, allowing easy replacement of intellectual property

Deterministic behavior not guaranteed.

Requirements and solutions for modeling HW in a SW language:

• C++ class library including required functions.• Concurrency: via processes, controlled by sensitivity lists

and calls to wait primitives.• Time: Floating point numbers in SystemC 1.0 and Integer

values in SystemC 2.0; Includes units such as ps, ns, µs etc*.

• Support of bit-datatypes: bitvectors of different lengths; multiple-valued logic (2- and 4-valued logic; resolution*)

• Communication: plug-and-play channel model, allowing easy replacement of intellectual property

Deterministic behavior not guaranteed.



Verilog

HW description language competing with VHDLStandardized:• IEEE 1364-1995 (Verilog version 1.0)• IEEE 1364-2001 (Verilog version 2.0)Features similar to VHDL:• Designs described as connected entities• Bit vectors and time units are supportedFeatures that are different:• Built-in support for 4-value logic and for logic with 8

strength levels encoded in two bytes per signal.• More features for transistor-level descriptions• Less flexible than VHDL.• More popular in the US (VHDL common in Europe)

HW description language competing with VHDLStandardized:• IEEE 1364-1995 (Verilog version 1.0)• IEEE 1364-2001 (Verilog version 2.0)Features similar to VHDL:• Designs described as connected entities• Bit vectors and time units are supportedFeatures that are different:• Built-in support for 4-value logic and for logic with 8

strength levels encoded in two bytes per signal.• More features for transistor-level descriptions• Less flexible than VHDL.• More popular in the US (VHDL common in Europe)



SystemVerilog

Corresponds to Verilog versions 3.0 and 3.1.

Includes:• Additional language elements for modeling behavior• C data types such as int• Typedefinition facilities• Definition of interfaces of hardware components as

separate entities• Mechanism for calling C/C++-functions from Verilog• Limited mechanism for calling Verilog functions from C.

Corresponds to Verilog versions 3.0 and 3.1.

Includes:• Additional language elements for modeling behavior• C data types such as int• Typedefinition facilities• Definition of interfaces of hardware components as

separate entities• Mechanism for calling C/C++-functions from Verilog• Limited mechanism for calling Verilog functions from C.



SystemVerilog

• Enhanced features for describing the testbench• Classes can be used in testbenches.• Dynamic process creation.• Standardized interprocess communication and

synchronization including semaphores.• Automatic memory allocation and deallocation.• Language features providing interface for formal

verification. Significant hype about the potential of SystemVerilog

Emperors new clothes?

• Enhanced features for describing the testbench• Classes can be used in testbenches.• Dynamic process creation.• Standardized interprocess communication and

synchronization including semaphores.• Automatic memory allocation and deallocation.• Language features providing interface for formal

verification. Significant hype about the potential of SystemVerilog

Emperors new clothes?



SpecC [Gajski, Dömer et. al. 2000]

• SpecC is based on the clear separation between communication and computation. Enables „plug-and-play“ for system components; models systems as hierarchical networks of behaviors communicating through channels.

• SpecC specs consists of behaviors, channels and interfaces.• Behaviors include ports, locally instantiated components,

private variables and functions and a public main function.• Channels encapsulate communication. They include

variables and functions, used for the definition of a communication protocol.

• Interfaces are linking behaviors and channels together. They declare the communication protocols which are defined in a channel.

• SpecC is based on the clear separation between communication and computation. Enables „plug-and-play“ for system components; models systems as hierarchical networks of behaviors communicating through channels.

• SpecC specs consists of behaviors, channels and interfaces.• Behaviors include ports, locally instantiated components,

private variables and functions and a public main function.• Channels encapsulate communication. They include

variables and functions, used for the definition of a communication protocol.

• Interfaces are linking behaviors and channels together. They declare the communication protocols which are defined in a channel.



Example

channel

behavior



SpecC-Example

interface L {void Write(int x);};interface R {int Read (void);};channel C implements L,R {int Data; bool Valid; void Write(int x) {Data=x; Valid=true;} int Read(void) {while (!Valid) waitfor(10); return (Data);} behavior B1 (in int p1, L p2, in int p3) {void main(void) {/*...*/ p2.Write(p1);} }; behavior B2 (out int p1, R p2, out int p3)

{void main(void) {/*...*/ p3=p2.Read(); } }; behavior B(in int p1, out int p2) {int c1; C c2; B1 b1(p1,c2,c1); B2 b2 (c1,c2,p2); void main (void) {par {b1.main();b2.main();}} };

interface L {void Write(int x);};interface R {int Read (void);};channel C implements L,R {int Data; bool Valid; void Write(int x) {Data=x; Valid=true;} int Read(void) {while (!Valid) waitfor(10); return (Data);} behavior B1 (in int p1, L p2, in int p3) {void main(void) {/*...*/ p2.Write(p1);} }; behavior B2 (out int p1, R p2, out int p3)

{void main(void) {/*...*/ p3=p2.Read(); } }; behavior B(in int p1, out int p2) {int c1; C c2; B1 b1(p1,c2,c1); B2 b2 (c1,c2,p2); void main (void) {par {b1.main();b2.main();}} };



Other languages (1)

• Pearl: Designed in Germany for process control applications. Dating back to the 70s. Popular in Europe.

• Chill: Designed for telephone exchange stations.Based on PASCAL.

• IEC 60848, STEP 7:Process control languages using graphical elements

• SpecCharts: Combination of StateCharts and VHDL; designed by Gajski et al. (Irvine), replaced by SpecC

• Pearl: Designed in Germany for process control applications. Dating back to the 70s. Popular in Europe.

• Chill: Designed for telephone exchange stations.Based on PASCAL.

• IEC 60848, STEP 7:Process control languages using graphical elements

• SpecCharts: Combination of StateCharts and VHDL; designed by Gajski et al. (Irvine), replaced by SpecC



Other languages (2)

• Estelle: Designed to describe communication protocols; scope similar to SDL; unification of both failed.

• LOTOS, Z: Algebraic specification languages• Silage: functional language for digital signal processing.• Rosetta: Efforts on new system design language• Esterel: reactive language; synchronous;

all reactions are assumed to be in 0 time;communication based on ("instantenous") broadcast;//www.esterel-technologies.com

• Estelle: Designed to describe communication protocols; scope similar to SDL; unification of both failed.

• LOTOS, Z: Algebraic specification languages• Silage: functional language for digital signal processing.• Rosetta: Efforts on new system design language• Esterel: reactive language; synchronous;

all reactions are assumed to be in 0 time;communication based on ("instantenous") broadcast;//www.esterel-technologies.com



MATLAB/Simulink

• MATLAB (Matrix Laboratory):facility for defining matrix-based computations,extending numerical FORTRAN packages LINPACK and EISPACK with a GUI

• Simulink: GUI-based specification of control systems, internally using MATLAB for solving these problems.

• StateFlow: StateCharts-based tool integrated into MATLABTHE environment for (German, at least) car manufacturers

• MATLAB (Matrix Laboratory):facility for defining matrix-based computations,extending numerical FORTRAN packages LINPACK and EISPACK with a GUI

• Simulink: GUI-based specification of control systems, internally using MATLAB for solving these problems.

• StateFlow: StateCharts-based tool integrated into MATLABTHE environment for (German, at least) car manufacturers



Inhoud (deel 1)



Specificatietalen– MSC, UML– Process networks– JAVA– VHDL– SystemC– Verilog, SystemVerilog– SpecC– Modelleringsniveaus– Vergelijking talen




Specificatietalen– MSC, UML– Process networks– JAVA– VHDL– SystemC– Verilog, SystemVerilog– SpecC– Modelleringsniveaus– Vergelijking talen




Levels of hardware modeling

1. System level

2. Algorithmic level

3. Instruction set level

4. Register-transfer level (RTL)

5. Gate-level models

6. Switch-level models

7. Circuit-level models

8. Device-level models

9. Layout models

10.Process and device models

1. System level

2. Algorithmic level

3. Instruction set level

4. Register-transfer level (RTL)

5. Gate-level models

6. Switch-level models

7. Circuit-level models

8. Device-level models

9. Layout models

10.Process and device models



System level

• The term system level is not clearly defined.• It is used here to denote the entire embedded system and

the system into which information processing is embedded, and possibly also the environment.

• Such models may include mechanical as well as information processing aspects, and may be difficult to find appropriate simulators. Solutions include VHDL-AMS, SystemC or MATLAB. MATLAB and VHDL-AMS support modeling partial differential equations.

• Challenge to model information processing parts of the system in such a way that the simulation model can also be used for the synthesis of the embedded system.

• The term system level is not clearly defined.• It is used here to denote the entire embedded system and

the system into which information processing is embedded, and possibly also the environment.

• Such models may include mechanical as well as information processing aspects, and may be difficult to find appropriate simulators. Solutions include VHDL-AMS, SystemC or MATLAB. MATLAB and VHDL-AMS support modeling partial differential equations.

• Challenge to model information processing parts of the system in such a way that the simulation model can also be used for the synthesis of the embedded system.



Algorithmic level

• Simulating the algorithms that we intend to use within the embedded system.

• No reference is made to processors or instruction sets.• Data types may still allow a higher precision than the final

implementation.• If data types have been selected such that every bit

corresponds to exactly one bit in the final implementation, the model is said to be bit-true. Translating non-bit-true into bit-true models should be done with tool support.

• May consist of single processes or of sets of cooperating processes.

• Simulating the algorithms that we intend to use within the embedded system.

• No reference is made to processors or instruction sets.• Data types may still allow a higher precision than the final

implementation.• If data types have been selected such that every bit

corresponds to exactly one bit in the final implementation, the model is said to be bit-true. Translating non-bit-true into bit-true models should be done with tool support.

• May consist of single processes or of sets of cooperating processes.



Instruction level

Algorithms have already been compiled for the instruction set of the processor(s) to be used. Simulations at this

level allow counting the executed number of instructions.

Variations: -Simulation only the effect of instructions-Transaction-level modeling: each read/write is one transaction, instead of a set of signal assignments-Cycle-true simulations: exact number of cycles-Bit-true simulations: simulations using exactly the correct number of bits

Algorithms have already been compiled for the instruction set of the processor(s) to be used. Simulations at this

level allow counting the executed number of instructions.

Variations: -Simulation only the effect of instructions-Transaction-level modeling: each read/write is one transaction, instead of a set of signal assignments-Cycle-true simulations: exact number of cycles-Bit-true simulations: simulations using exactly the correct number of bits



Instruction level: example

Assembler (MIPS) Simulated semantics

and $1,$2,$3 Reg[1]:=Reg[2] Reg[3]

or $1,$2,$3 Reg[1]:=Reg[2] Reg[3]

andi $1,$2,100 Reg[1]:=Reg[2] 100

sll $1,$2,10 Reg[1]:=Reg[2] << 10

srl $1,$2,10 Reg[1]:=Reg[2] >> 10



Register transfer level (RTL)

At this level, we model all the components at the register-transfer level, including- arithmetic/logic units (ALUs),- registers,- memories,- muxes and- decoders.

Models at this level are always cycle-true.

Automatic synthesis from such models is not a major challenge.

At this level, we model all the components at the register-transfer level, including- arithmetic/logic units (ALUs),- registers,- memories,- muxes and- decoders.

Models at this level are always cycle-true.

Automatic synthesis from such models is not a major challenge.



Register transfer level: example (MIPS)

Controller

BP

C

Inst

ruct

ion

reg

iste

r IR

Mem

ory

Spe

iche

r

alu_

co

ntro

l

T

sign_extend

<<

2

4

*

AL

U

Reg

0

0

0

0

0

01

1

1

1

1

1

2

2

3

§

31:26

25:21

20:16

25:0

15:0

15:11

i2

a2

a1

i3

a

3

a

2

a

1

o2

o1

PC

So

urc

e

Ta

rge

tWrit

e

AL

UO

p

AL

US

elA

AL

US

elB

Re

gW

rite

Re

gD

est

Me

mT

oR

eg

IRW

rite

Me

mR

ea

d

Me

mW

rite

PC

Writ

e

PC

Wr it

eC

IorD

*§ 31: 28

"00“



Gate-level models

• Models contain gates as the basic components.• Provide accurate information about signal transition

probabilities and can therefore also be used for power estimations.

• Delay calculations can be more precise than for the RTL. Typically no information about the length of wires (still estimates).

• Models contain gates as the basic components.• Provide accurate information about signal transition

probabilities and can therefore also be used for power estimations.

• Delay calculations can be more precise than for the RTL. Typically no information about the length of wires (still estimates).



Gate-level models: Example

source: http://geda.seul.org/screenshots/screenshot-schem2.png



Switch-level models

• Switch level models use switches (transistors) as their basic components.

• Switch level models use digital values models.• In contrast to gate-level models, switch level models are

capable of reflecting bidirectional transfer of information.

• Switch level models use switches (transistors) as their basic components.

• Switch level models use digital values models.• In contrast to gate-level models, switch level models are

capable of reflecting bidirectional transfer of information.



Switch level model: example

Source: http://vada1.skku.ac.kr/ClassInfo/ic/vlsicad/chap-10.pdf



Circuit level models: Example

• Models Circuit theory and its components (current and voltage sources, resistors, capacitances, inductances and possibly macro-models of semiconductors) form the basis of simulations at this level.

• Models Circuit theory and its components (current and voltage sources, resistors, capacitances, inductances and possibly macro-models of semiconductors) form the basis of simulations at this level.

Simulations involve partial differential equations. Linear if and only if the behavior of semiconductors is linearized.

Simulations involve partial differential equations. Linear if and only if the behavior of semiconductors is linearized.

Ideal MOSFET

Tran-sistor model



Circuit level models: SPICE

The most frequently used simulator at this level is SPICE [Vladimirescu, 1987] and its variants.

Example:



Circuit level models:sample simulation results



Layout models

• Reflect the actual circuit layout,• include geometric information,• cannot be simulated directly:

behavior can be deduced by correlating the layout model with a behavioral description at a higher level or by extracting circuits from the layout.

• Length of wires and capacitances frequently extracted from the layout, back-annotated to descriptions at higher levels (more precision for delay and power estimations).

• Reflect the actual circuit layout,• include geometric information,• cannot be simulated directly:

behavior can be deduced by correlating the layout model with a behavioral description at a higher level or by extracting circuits from the layout.

• Length of wires and capacitances frequently extracted from the layout, back-annotated to descriptions at higher levels (more precision for delay and power estimations).



Layout models: Example

din

powlo

powhi

dout

© Mosis (http://www. mosis.org/Technical/Designsupport/polyflowC.html);Tool: Cadence



Process models

Model of fabrication process; Example [IMEC]:Doping as a function of the distance from the surface

Model of fabrication process; Example [IMEC]:Doping as a function of the distance from the surface

Simulated

Measured



Language Comparison

Language Beh.

Hier.

Struc.

Hier.

Prog.

Lang.

El.

Abstr.

Comm.

Time Exc.

Sup.

Dyn.

Proc.

Crea.

Formal

Cost of use

StateCharts

+ - - - + + - + +-

VHDL + + + +- + - - +- +

SpecCharts + - + + + + - +- +-

SDL +- +- +- + + - + + +

Petri Nets - - - + - - + + +

Java + - + + +- + + - +

SpecC + + + + + + + - -

SystemC 3 + + + +- + + + - +-

ADA + - + +- +- + + - +-

Matlab + + +- + + + - - +



How to cope with language problemsin practice?

Mixed approaches:Mixed approaches:



Dependability requirements

Allowed failures may be in the order of 1 failure per 10 9 h.

~ 1000 times less than typical failure rates of chips. For safety-critical systems, the system as a whole must

be more dependable than any of its parts. fault-tolerance mechanisms must be used.

Low acceptable failure rate systems not 100% testable. Safety must be shown by a combination of testing and

reasoning. Abstraction must be used to make the system explainable using a hierarchical set of behavioral models. Design faults and human failures must be taken into account.

Allowed failures may be in the order of 1 failure per 10 9 h.

~ 1000 times less than typical failure rates of chips. For safety-critical systems, the system as a whole must

be more dependable than any of its parts. fault-tolerance mechanisms must be used.

Low acceptable failure rate systems not 100% testable. Safety must be shown by a combination of testing and

reasoning. Abstraction must be used to make the system explainable using a hierarchical set of behavioral models. Design faults and human failures must be taken into account.



Kopetz‘s 12 design principles (1-3)

1. Safety considerations may have to be used as the important part of the specification, driving the entire design process.

2. Precise specifications of design hypotheses must be made right at the beginning. These include expected failures and their probability.

3. Fault containment regions (FCRs) must be considered. Faults in one FCR should not affect other FCRs.

1. Safety considerations may have to be used as the important part of the specification, driving the entire design process.

2. Precise specifications of design hypotheses must be made right at the beginning. These include expected failures and their probability.

3. Fault containment regions (FCRs) must be considered. Faults in one FCR should not affect other FCRs.




4. A consistent notion of time and state must be established. Otherwise, it will be impossible to differentiate between original and follow-up errors.

5. Well-defined interfaces have to hide the internals of components.

6. It must be ensured that components fail independently.

4. A consistent notion of time and state must be established. Otherwise, it will be impossible to differentiate between original and follow-up errors.

5. Well-defined interfaces have to hide the internals of components.

6. It must be ensured that components fail independently.




7. Components should consider themselves to be correct unless two or more other components pretend the contrary to be true (principle of self-confidence).

8. Fault tolerance mechanisms must be designed such that they do not create any additional difficulty in explaining the behavior of the system. Fault tolerance mechanisms should be decoupled from the regular function.

9. The system must be designed for diagnosis. For example, it has to be possible to identify existing (but masked) errors.

7. Components should consider themselves to be correct unless two or more other components pretend the contrary to be true (principle of self-confidence).

8. Fault tolerance mechanisms must be designed such that they do not create any additional difficulty in explaining the behavior of the system. Fault tolerance mechanisms should be decoupled from the regular function.

9. The system must be designed for diagnosis. For example, it has to be possible to identify existing (but masked) errors.




10.The man-machine interface must be intuitive and forgiving. Safety should be maintained despite mistakes made by humans.

11.Every anomaly should be recorded. These anomalies may be unobservable at the regular interface level. This recording should involve internal effects, since otherwise they may be masked by fault-tolerance mechanisms.

12.Provide a never-give up strategy.Embedded systems may have to provide uninterrupted service. The generation of pop-up windows or going offline is unacceptable.

10.The man-machine interface must be intuitive and forgiving. Safety should be maintained despite mistakes made by humans.

11.Every anomaly should be recorded. These anomalies may be unobservable at the regular interface level. This recording should involve internal effects, since otherwise they may be masked by fault-tolerance mechanisms.

12.Provide a never-give up strategy.Embedded systems may have to provide uninterrupted service. The generation of pop-up windows or going offline is unacceptable.

- 0 - P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hoofdstuk 2...

Documents

Transcript of - 0 - P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hoofdstuk 2...