Re: Verilog++ LRM draft 1

Subject: Re: Verilog++ LRM draft 1
From: Peter Flake (flake@co-design.com)
Date: Mon Oct 08 2001 - 08:35:27 PDT

Stu,

Thanks for your draft.   It looks really good.  Here are comments, some of which I have already sent you.

P6.
The size of int and longint has caused confusion.  In my mind they are exactly 32 and 64 bits.
A char can be either a byte (ASCII) for English etc. or a shortint (Unicode) for Japanese etc.

P6/7
The difference between int and integer is that int is unmasked (i.e. 2 state logic) and integer is masked (i.e. 4 state logic).  The masked values have additional data (the mask bit or bits) that encodes the X and Z states. Unmasked data types should simulate faster, take less memory, and are preferred in some design styles, such as those proposed by Harry Foster.

P7
The default time unit should be 1s.

A more detailed description is provided in section 12.

P10
$bits should be defined in System Functions as returning the number of bits required to hold a value.  Note that a 4 state value counts as one bit, so that $bits on an integer returns 32.

P11
I think vectored and scalared should be like pragmas to optimize performance in a tool-specific manner.
216 could be written 2**16.

P12
I believe that VCS accepts integer [31:0].  Please correct me if I am wrong.  However, we can drop it from the standard.

P13
Out of range index values are illegal for both reading from and writing to an array which is not of type 'logic'.

A slices (part select) can only apply to one dimension, but other dimensions may have single index values in an expression.

P16
Data declared in a static task, function or block defaults to a static lifetime and a local scope.  If an initializer is used the keyword static must be specified to make the code clearer.

P17
It is an error to have a continuous assignment and a procedural assignment write to the same logic variable (even through ports).

P27
The unique/priority keyword should determine the simulation behavior.  Attributes may be used to determine synthesis behavior, but it is recommended that the simulation behavior should be followed where possible.

P29
A label can be put before any statement.  However, a label must be either before the begin (or fork) or after it, not in both places.  A label cannot appear before the 'end' (or join), as 'end' is not a statement.  A label after the 'end' (or join) must match that on the 'begin' (or fork).

P32
I believe that the @* is the same as Verilog 2001 but stated negatively instead of positively.

I agree wait should be re-phrased as in Verilog 2001.

P39
This syntax matches that of enums, but it should only affect synthesis not simulation, as the value cannot be cast.

P40
initial begin
fork @S.S0_S2; @S.S2_S1; @S.S2_S0; join
end

The easiest way to provide random initialization of state variables is to write an initial block with transitions determined by a random number.

P41
// Superlog description of two-player Reflex game from
// Hierarchical Finite State Machines with Multiple Concurrency Models
// Alain Girault, Bilung Lee, Edward A Lee
// IEEE Transactions on Computer Aided Design Vol 18 No 6 June 1999 pp 742

// Note this is an abstract model with events for input and enumeration for output

module REFLEX ( input event ready, stop, go, coin,
    output enum {blue, yellow, red, green, flashing} light) ;

`define L 10

event timer;

always #10 ->timer;

state {
    game_off,
    {
        {wait_ready, wait_go, wait_stop, done} player1 and
        {idle, waiting} player2
    } game_on
} game;

always begin: normal

    // Either player may assert coin to start the game, status light turns blue

    @(coin) transition (game) game_off: ->> game_on light = blue; endtransition

    // When player 1 presses ready, the status light turns yellow

    @(ready) transition (game)
        wait_ready and idle: start->> wait_go and waiting light = yellow;
    endtransition

    // When player 2 presses go the status light turns green

    fork : fork1
        @(go) disable fork1;
        repeat (`L) @timer disable fork1; // if player 2 does not press go in time
        @(stop) begin // stop before go
            transition (game)
                wait_go: ->> game_off light = flashing;
            endtransition
            disable normal;
        end        
    join
    transition (game)
        wait_go and waiting: end2->> wait_stop and idle light = green;
    endtransition

    // Player 1 presses stop within L time units

    fork : fork2
        begin @(stop) transition (game)
            wait_stop: ->> game_off light = red;
        endtransition disable fork2; end
        begin repeat (`L) @(timer) transition (game)
            wait_stop: ->> game_off light = flashing;
        endtransition disable fork2; end
    join

end: normal

always @light $display("%t %s", $realtime, light);

endmodule

event ready, stop, go, coin;

enum {blue, yellow, red, green, flashing} light;

REFLEX u1 (ready, stop, go, coin, light);

$display(u1.game);

#10 ->coin;
#10 ->ready;
#10 ->go;
#10 ->stop;
#10 $finish();

P45
// pipeline module

module p(input clk, flush, input int x_in, y_in, z_in);
parameter int latency = 6, throughput = 2;
int z_out;
int processes = 0;

always begin
        while (!flush) begin
                process begin
                        int v2, v3, v4, v5; // lifetime matches process
                        processes++;
                        v2 = x_in + y_in;
                        v3 = x_in - z_in;
                        v4 = v2 * v3;
                        v5 = v4 * x_in;
                        repeat(latency) @ (posedge clk);
                        z_out <= v5;
                        processes--;
                end
                repeat(throughput) @(posedge clk);
        end
        wait(processes == 0); //wait for flush
end

endmodule

P48
function void myprint (int a); .... endfunction

P49
We can probably delete the first 3 paras of section 12.1

P53
Default time unit is 1s.  I believe this is needed for V2001 compatibility.

P55
If the port is a wire vector, then the connection rules for wires are followed.
If the port is an inout port variable, then a port connection must have the same size and representation.
If the port is an input or an output variable then the assignment rules are followed.

Regards,

Peter.

This archive was generated by hypermail 2b28 : Mon Oct 08 2001 - 08:35:01 PDT