From: Adam Krolnik (adamk@cyrix.com)
Date: Thu Mar 12 1998 - 20:56:19 PST
Good morning:
<p>Where are we currently on B25 - Add struct / record data types [and typedef]?
I have seen no notes from the conference calls on it.
I was looking through my mailbox and noted these messages that have had no
discussion. I would like to present them for comments.
Adam
Begin forwarded message:
To: "Anders Nordstrom" <andersn@nortel.ca>
Cc: 1364core@galaxy.nsc.com
Subject: Another BTF error - Section 5.5 "Race conditions"
Date: Mon, 29 Sep 1997 15:23:42 +0100
From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk>
<p>module EXP_143;
reg q;
// comment out only one of the following two lines:
wire p; assign p=q;
// wire p=q;
initial begin
#1 $display("1st simulation cycle: q",q," p",p);
#0 $display("2nd simulation cycle: q",q," p",p);
end // initial #1
initial begin // this code based on that on p5-4, Oct P1364
q=1;
#1 q=0;
$display("1st: q",q," p",p);
#0 $display("2nd: q",q," p",p);
end // initial begin
initial begin
#1 $display("1st simulation cycle: q",q," p",p);
#0 $display("2nd simulation cycle: q",q," p",p);
end // initial begin
endmodule // EXP_143
/*
With wire p=q; only commented out
$verilog -q experiment.143.cv
1st simulation cycle: q1 p1
1st: q0 p1
1st simulation cycle: q0 p1
2nd simulation cycle: q0 p1 (p is still 1)
2nd: q0 p0
2nd simulation cycle: q0 p0
The example code in section 5.5 "Race conditions" is at fault.
It states that the display immediately following the q=0
assignment could show p as either 1 or 0.
This code shows that in fact, p does not become 0 until
partway through the 2nd simulation cycle in the same timestep,
hence it is impossible for the first display to see p=0.
This is because of the implicit #0 net delay.
With wire p; assign p=q; only commented out
$verilog -q experiment.143.cv
1st simulation cycle: q1 p1
1st: q0 p0
1st simulation cycle: q0 p0 (p is already 0)
2nd simulation cycle: q0 p0
2nd: q0 p0
2nd simulation cycle: q0 p0
Here, without the implicit #0 net delay, p becomes 0
within the 1st simulation cycle.
*/
Begin forwarded message:
From: Adam Krolnik <adamk@eng.cyrix.com>
Date: Tue, 21 Oct 97 14:25:27 +0600
To: 1364core@galaxy.nsc.com
Subject: Bit and part selection
<p><p><p>Good afternoon everyone,
Thinking about selection of fields (bit(s)) we can do the following:
reg[2:0] b, c;
reg[15:0] areg;
c = areg[2] ; // a single bit.
b = {areg[4], areg[3], areg[2]} // concatenated set of bits.
b = areg[4:2]; // a shorthand for a set of bits;
// only when they are consecutive.
What about allowing:
b = areg[7,5,2]; // a set of nonconsecutive bits?
Both on the right hand side and left hand side of assignments.
areg[7,5,2] = b;
<p> Adam Krolnik
Verification Engineer
Cyrix, Corp.
Richardson TX. 75085
Begin forwarded message:
<p>Date: Fri, 20 Jun 97 09:53:45 PDT
From: prabhu@lsil.com (Prabhakaran Krishnamurthy)
To: 1364core@galaxy.nsc.com
Subject: Deterministic vs. non-deterministic - Testcase1 from LSI
Cc: prabhu@lsil.com
One of the A.Is for LSI in the 1364 committee mtg was to bring to the
table the known inconsistencies in the Verilog simulators, to check to
see if that is in anyway due to the LRM being unclear.
Following is a testcase from LSI illustrating the difference in
interpretation of deterministic vs. non-deterministic operators inside
(and outside) of the specify block.
The testcase shows an inconsistency in the interpretations between
Verilog-XL and VCS (the two latest revisions which LSI has).
This was referred to Chronologic as an issue when we initially were
qualifying VCS. But according to them, it was a case of the LRM being
inconsistent/unclear with the actual interpretation.
Thanks,
Prabhu K.
Begin forwarded message:
<p>From: Adam Krolnik <adamk@eng.cyrix.com>
Date: Fri, 20 Feb 98 12:53:49 +0600
To: btf@boyd.com
Subject: Erratta for tasks/function declarations in the BNF.
Sender: owner-btf@boyd.com
<p><p>>From reading the proposed 1998 BNF, it was noted that the 1995 version
of task and function declarations allowed no statements within a
task or function.
This is in fact false, you must have one statement.
module test;
task a;
input b;
endtask
function f;
input b;
endfunction
Both of these are syntax errors in XL.
Propose to specify 'statement' instead of 'statement_or_null'.
<p> Adam Krolnik
Verification Engineer
Cyrix - NSM.
Richardson TX. 75085
Begin forwarded message:
<p>From: Adam Krolnik <adamk>
Date: Fri, 14 Nov 97 13:59:43 +0600
To: 1364core@ovi.org
Subject: Name of { {} } operator
cc: adamk
<p><p>Good afternoon:
In 1364-1995 on page 27, the operator {{}} is named "replication". On page 38,
the first component of the {{}} operator is named the "repetition multiplier".
What is the name of the operator: replication or repitition?
Also, the spec specifies (inversely) sized constants are required in the
concatenation field (while the BNF shows the generic "expression" instead of constant_expression). The spec doesn't specify what the repetition multiplier needs to be. Also the wording "constant_multiple_concatentation" is not defined
while "multiple_concatenation" is defined.
Also, what should be expected if the "repetition multiplier" evaluates to 0?
E.g.
a[31:0] = {1'b1, {0{1'b0}} };
<p> Adam Krolnik
Verification Engineer
Cyrix, Corp.
Richardson TX. 75085
Begin forwarded message:
From: Adam Krolnik <adamk>
Date: Tue, 9 Sep 97 16:22:53 +0600
To: 1364core@galaxy.nsc.com (IEEE-1364 Core Group Reflector)
Subject: Transport delay for events
cc: adamk
<p>It would be helpful to trigger events using transport delay. With nonblocking
assignments, you can get this effect, but events are a little cleaner
when they are used.
A proposed syntax for adding transport delay is:
-> timing_control event;
<p>E.g.
-> #100 event_a;
-> @(posedge clk) event_a;
-> repeat (2) @(posedge clk) event_a;
<p><p> Adam Krolnik
Verification Engineer
Cyrix, Corp.
Richardson TX. 75083
<p>Begin forwarded message:
From: Adam Krolnik <adamk@eng.cyrix.com>
Date: Wed, 22 Oct 97 17:58:42 +0600
To: 1364core@galaxy.nsc.com
Subject: Specification of sized constants
<p><p>Hello
<p>Please consider allowing parameters (at the least) to define the length of a constant. Should there be other ways to specify the size of a value? Should there be a restriction that the size be constant?
An Example
module tst;
<p>`define length 4
`define width 6
parameter size = `len * `wid;
reg[`width:1] a, out;
reg[`length*`width:1] b;
initial begin
$display("Size is %0d.", size);
b = size 'b0; // Using parameter to specify size.
end
always @(clk) begin
{out, b} = {b, a};
end
endmodule
Begin forwarded message:
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:47 PDT
and
sponsored by Boyd Technology, Inc.