|
 |
News
July 2, 2002
STOC (SpecC Technology Open Consortium)
Announce of approved issues of the 4th General Meeting
From this year, General Meeting was done through e-mail.
This is the announcement that of all the approving Issues are agreed from all members.
Approved Issues are:
1. Appointment of STOC Officials
2. Financial Report of the Year 2001
3. Year 2002 Activities
4. Year 2002 Financial Plans
5. Approval of SpecC v2.0 specification
Note:
1. Officials in the year 2002
 |
|
|
Kiichiro Tamaru (Toshiba)
|
|
|
Yukio Kunimine (GAIO Technology)
|
|
|
|
|
Case Study WG
|
|
|
|
Prof.Yoshihiro Matsumoto
(Musashi Institute of Technology)
|
|
|
Masato Igarashi (Toshiba)
|
|
|
|
|
Masahiro Fujita (University of Tokyo)
|
|
|
|
| |
Daniel Gajski (University of California Irvine)
|
|
|
Ken Chiboshi (Soliton Syetems)
|
|
2. SpecC 2.0 refined points:
|
|
[1] Semantics of par
|
|
In SpecC 1.0, there have been some ambiguities in the semantics of parallel behaviors.
In SpecC 2.0, it was defined clearly as follows;
- Behaviors in a par block begin at the same time and terminate at the same time.
- Statements in a behavior are executed sequentially but not always in continuous way.
- If behaviors B1 and B2 are in the same par block, and if statement st2 follows st1
in B1 and statement st3 is in behavior B2, then no deterministic order exists between
st1, st2, and st3, except that termination of st1 precedes beginning of st2.
- The length of statement interval is quite small and infinitely close to 0 in
"simulation time"
- Any kind of atomicity is not guaranteed between concurrent instances of behavior,
which means that statements may be preempted at any time in their execution, even in
the middle of memory accesses.
|
|
[2] Mutual exclusion
|
|
Since in the semantics of par, preemption and no atomicity for a sentence are defined, some special features are needed to control the mutual exclusive access.
SpecC 1.0 has no clear primitives for mutually exclusive access.
- Only one method in a channel instance can run at a time. Other methods in the channel
instance can run after the previous method completes, or it executes a wait or waitfor
statement. The methods in other channel instances can run independently.
- In hierarchical channels, i.e. a channel method call of other channel method, when
it executes a wait statement, all channel mutexes of the current thread are released.
In SpecC, wait and waitfor are not bound to a channel, so every thread will have its
own list of obtained mutexes.
|
|
[3] Synchronization semantics
|
|
In SpecC 2.0, the synchronization semantics in SCRC (SpecC reference compiler) version
1.x is clarified. However, the synchronization semantics is not defined as the language
specification at this time.
|
|
[4] Exception handlers
|
|
While SpecC 1.0 limits interrupt points only after wait or waitfor statement, SpecC 2.0
allows interrupts and traps at any place chosen in a non-deterministic manner.
|
|
[5] Fixed-point data type
|
|
It was approved that SpecC should support the fixed point data type. The detailed
implementation will be defined in the future version of SpecC.
|
|
[6] AND conditions for event wait statement
|
|
SpecC 2.0 allows new wait notation as;
wait (e1 && e2);
The semantics of this statement is to wait for both e1 and e2 events, but we don't
care the arrival order. This statement is a shortcut of the following code;
|
|
behavior B_wait(in event e)
{
void main(void) { wait e; }
};
behavior B_andwait(in event e1, in event e2)
{
B_wait b1(e1);
B_wait b2(e2);
void main(void)
{
// Do something before wait (e1 && e2);
par {
b1.main();
b2.main();
}
// Do something after both e1 and e2 arrive
}
};
|
|
[7] Simple notation of par/pipe/try statement
|
|
In SpecC 2.0, we can replace
par { S1.main(); S2.main(); S3.main(); }
with
par { S1; S2; S3; }
or
par ( S1; S2; S3 );
as shortcuts. Same rule applies to pipe and try/trap/interrupt statement.
|
|
[8] Arbitrary statements in FSM statement
|
|
SpecC 2.0 allows arbitrary C language statements including function call in fsm
as follows;
|
|
fsm{
s1:
goto s2; // state transition (allowed in SpecC1.0)
s2: {
if( local_i == 0 ) goto s1; // conditional state transition
goto s3; // default state transition (allowed in SpecC1.0)
}
s3: {
local_i = 1; // allow any C language statements (New)
...
goto s1;
}
};
|
|
[9] Extension of persistent annotation
|
|
In SpecC 1.0, the note construct is limited to a single annotation value of
constant type (or constant expression, evaluated at compile time).
In SpecC 2.0 the syntax is extended to a list of values, or even a list of
a list (...) of values, by using grammar rules similar to the ones for
variable initializers as follows;
|
|
annotation = constant_expression
| '{' annotation_list '}'
annotation_list = annotation
| annotation_list ',' annotation
|
|
[10] Modeling RTL in SpecC
|
|
- Introduce FSMD and some related constructs for describing RTL model in SpecC.
- Detailed language extension is described in the document of "RTL Semantics
according to Accelera Standard (revision 10/29/01)."
|
|
[11] RTL model of SpecC
|
|
FSMD constrct
Accellera RTL semantics is defibed by FSMD model, the object is expressed as a variable.
Some of objects can be expressed by SpecC1.0, but newly introduced expression by SpecC2.0
also there.
|
|
|
Accellera object:
|
SpecC expression:
|
|
uninterpreted variable
|
normal variable
|
|
port
|
port
|
|
storage (register)
|
buffered variable (*)
|
|
wire,bus in FSM
|
normal variable
|
|
wire, bus intra FSM
|
signal variable (*)
|
|
clock
|
event
|
|
reset
|
event or bool
|
|
(*) added in SpecC 2.0
|
|
|
[12] SpecC RTL model(3)
|
|
buffered variable, signal variable
Express the wire between FSMD communication
It is used as a event.
|
|
|
syntax
|
semantics
|
|
signal int x;
|
event x_e; buffered[x_e] int x_v;
|
|
x = 55;
|
x_v = 55; notify x_e;
|
|
y = x + 2;
|
y = x_v + 2;
|
|
wait x;
|
wait x_e;
|
|
notify x;
|
notify x_e;
|
|
wait (x == 5);
|
while(x_v != 5) {wait x_e;}
|
|
|
Express storage(register)
|
|
(e.g.)
|
buffered[CLK] int R1, R2; // event CLK update
buffered[CLK1,CLK2] int R3; // event CLK1, CLK2 update
R1 = R2; // R1, R2 swap
R2 = R1;
wait CLK;
|
|
|
[13] SpecC RTL model
|
|
signal variable
Express intra FSMD communication wire.
It is used as aevent.
|
|
|
syntax
|
semantics
|
signal int x; |
event x_e; buffered[x_e] int x_v;
|
|
x = 55;
|
x_v = 55; notify x_e;
|
|
y = x + 2;
|
y = x_v + 2;
|
|
wait x;
|
wait x_e;
|
|
notify x;
|
notify x_e;
|
|
wait (x == 5);
|
while(x_v != 5) {wait x_e;}
|
|
|
[14] SpecC RTL model
|
|
Construct element fsmd
SpecC1.0 presents state base behavior by fsm.
SpecC2.0 introduced Accellera standard FSMD expression by fsmd.
|
|
(e.g.)
|
fsmd(CLK) {
unsigned bit [31:0] Data; // unmapped variable
unsigned bit [31:0] Ocount;
{ Outport = 0; Done = 0; } // initial value set
if (RST) { State = S0; } // reset time behavior notation
S0 : { Done = 0; // every times behavior notation
if (Start != 0) goto S1; // state transition
else goto S0; }
S1 : { Data = Inport;
goto S2; }
S2 : ...
}
|
|
|
|
