Subject: [sv-ec] Re:
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Feb 20 2003 - 09:52:42 PST
Doug,
1) The motivation for contention resolution to the synchronous drives
is to catch simple errors and give users deterministic behavior.
Driving a clocking domain output is a synchronous non-blocking
assignment (synchronous because the clocking domain specifies
the edge at which data appears on the signal). Keep in mind that
the drive is a non-blocking assignment, and consider the following:
reg [1:0] a = 2b'11;
a <= 2b'10;
a <= 2b'11;
According to 1364 the value final of 'a' in this simple example is 3.
However, the language doesn't specify the behavior of:
always @( a )
Do the previous assignments trigger the sensitivity list of a? This is
unspecified and different simulators do it differently.
If you next consider that multiple processes may write to the same
variable:
always @(posedge clk) a <= 'z;
always @(posedge clk) a <= 1;
always @(posedge clk) a <= 2;
The behavior or 'a' is undefined. This often leads to a situation where
a test that seems to work correctly in one simulator fails in another.
In general, this is a problem that is very difficult to debug.
The proposal makes all of these situations predictable.
I see your point about using the clocking domain output as a temporary
to hold a default value, but for that situation perhaps a temporary variable
that is assigned with blocking assignments may be more appropriate.
You question regarding the 'waveform creation' is a misunderstanding.
The proposal does not disallow code like the one you wrote. It only
disallows drives that would result in a waveform glitch, that is, multiple
assignments to a different value at the same time.
2) If it were allowed it would only apply to variables with identical clocking
domain behavior, that is, same output active edge and output skew.
This would disallow using outputs from different clocking domains that
may have very similar timing. For example, different gated clocks that
may end up having the same (or very similar) timing.
The LRM could be amended to add these restrictions, but we felt that
it would cause more confusion and decided to disallow it altogether.
Arturo
----- Original Message -----
From: <owner-sv-ec@eda.org>
To: <undisclosed-recipients:>
Sent: Thursday, February 20, 2003 8:20 AM
Hi SV-EC,
Sender: owner-sv-ec@eda.org
Precedence: bulk
I've been reviewing draft 3 of the LRM and I have a couple questions
regarding the synchronous drive section (13.14).
1) What is the motivation for requiring contention resolution
in case more than one assignment is made to a synchronous
drive in the same time slot? (Sec. 13.14.2)
At first glance, this appears to disallow a popular
modeling style. It also disallows creation of waveforms.
ex1.
// use of "default" value assignment at top of process
always @(some_event) begin
cd.syncdrive = some_default_value;
if (...) begin
...
cd.syncdrive = some_other_value;
end
end
ex2.
// creation of a waveform on a synchronous drive
initial begin
cd.syncdrive = ##1 some_value;
cd.syncdrive = ##2 some_other_value;
etc.
end
2) Why is concatenation expressly disallowed in the
clockvar_expression of synchronous drive assignments?
Sorry if I've misunderstood anything in this area.
Knowing the motivations behind these language limitations
would help out.
Regards,
Doug Warmke
This archive was generated by hypermail 2b28 : Thu Feb 20 2003 - 09:54:13 PST