Re: [sv-bc] Question on mandatory "static" to declare intent

From: David Jones <djones_at_.....>
Date: Tue Dec 30 2008 - 06:00:17 PST
> And it's not as simple as determining if the initialization occurs once
> or nor, but when the initialization occurs. For example
>
> module top;
> int A = 1;
> initial begin
>   int B = A+1; // not legal
> end
> endmodule
>
> If B is intended to be static, which was the default, then this is a
> race condition

Hmmm... we're quickly going down a rathole.

Is the following legal?

> module top;
> int A = 1;
> initial begin
>   int B = 5; // ???
> end
> endmodule

The only difference is that now I've removed the reference to A that
caused the race condition. We could argue that this is legal. If you
want to make your original code illegal, then we are applying two
different semantic restrictions:

1. It is mandatory to declare intent where a misunderstanding of the
static nature of a declaration may lead to a hard-to-find
initialization bug. (And I've been burned here many times. I feel the
pain.)
2. It is mandatory to declare a variable automatic (even static is
illegal in your example) where not doing so would lead to a race
condition.

But there are many causes of race conditions in (System)Verilog. I
would argue that it's intractable for a compiler to find them all at
compile time, through static analysis and yield useful results (few
false positives). If we start mandating that constructs that lead to
race conditions be made illegal then are we instilling too much
confidence in users that their tools will find all of these issues?

I'm beginning to think that this sort of stuff should result in a
simulator WARNING rather than being outright illegal. If we are
worried about drowning in a sea of warnings then let the vendors solve
that problem through creative presentation of diagnostic messages. A
conscientious engineer will look at the warnings. But we've had that
discussion before here as well.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Dec 30 06:04:30 2008

This archive was generated by hypermail 2.1.8 : Tue Dec 30 2008 - 06:05:10 PST