Subject: RE: [sv-ec] Re:
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Feb 20 2003 - 10:43:25 PST
Arturo,
Thanks for the detailed response.
Please see some more points to consider below.
Regards,
Doug
-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Thursday, February 20, 2003 9:53 AM
To: sv-ec@server.eda.org
Subject: [sv-ec] Re:
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.
DOUG: I agree with all you wrote above.
The problem I see is that this new and predictable behavior
is not too Verilog-like, since it is inconsistent with
existing assignment operator behavior (for good and bad).
This semantic inconsistency may be a source of confusion,
since the syntaxes are so similar. And the current proposal
seems to limit some use models. I hope SV-EC will consider
this semantic consistency issue carefully.
Another example of a use model that is limited (some would
argue this is a very good thing!) is as follows:
always @(sig1 or sig2 or sig3) begin
...
if (some_expression) begin
a = sig1;
end
...
end
always @(sig1 or sig2 or sig3) begi
...
if (some_mutually_exclusive_expression) begin
a = sig2;
end
...
end
This isn't good code, and synthesis may do some terrible
things with it. Nonetheless a lot of people use this style
of "last assignment wins", especially in TB or bhv models.
Synchronous drives would be inconsistent w.r.t. normal
assignments in this context, too.
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.
DOUG: Agreed, it is an easy workaround.
But I'm concerned users will run into problems, debug,
then scratch their head wondering why they have to do this
workaround for synchronous drive assignments, but not other
kinds of assignments.
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.
DOUG: When you say same time, do you mean "same scheduling time"
or "same maturity time"? I could see the case for producing an X
if different values were scheduled to mature at the same time.
But the way the LRM is currently written, it reads more like
"same scheduling time", which would disallow 'waveform creation'
as I have written in the example. Please clarify.
Thanks again,
Doug
<EOM>
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 - 10:45:11 PST