> 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