>From: "Warmke, Doug" <doug_warmke@mentor.com> >But that is in contradiction to the P1800 LRM. >SystemVerilog designs are required to have one-file is >one-compilation-unit semantics as the default (See 19.3). We can get into legalistic quibbling about what "default" means in that context. However, the fact is that the command lines of tools are outside the scope of the LRM. This is acknowledged explicitly in the section that you are referencing. It says that the mechanism for defining which files constitute a compilation unit is tool specific. Tools have to provide both use-models, but how they do so is up to them. The statement that one of them is the "default" has no real meaning, since it doesn't constrain the mechanism used to get that default. A tool can require that each file be compiled with a separate tool invocation as the mechanism to get the default behavior. A tool can have a command-line option to get the default, and have the mechanism for getting the other use-model be to leave off the option. You can claim that this doesn't match what was meant by "default", but this is outside the scope of the LRM. Even if the LRM could somehow require that getting the other use-model required adding a command-line option rather than omitting one, there are still ways around this. A tool is not required to be compliant with the P1800 LRM with all possible command-line options. For example, a tool might require a -systemverilog command-line option to make it compile SystemVerilog instead of Verilog. So clearly a tool can require a particular command-line option in order to be compliant with the P1800 LRM. A tool could require the command-line option -file_unit to be used to get compliant P1800 behavior, and then require the additional option -no_I_really_meant_all_files to get the non-default behavior. And then the tool could say that without -file_unit, you also get the non-default behavior. This is OK because that option was required to get P1800 compliance, just like -systemverilog was. The result is that the default behavior in P1800-compliant mode is as required by the LRM, but the behavior with minimal options isn't. The tool must still be considered compliant. Given that such a requirement is easily circumvented, there is no point in making it in the first place. I agree that the "stream-of-text" model causes problems, and it would be good to move away from it. But as Shalom notes, users are accustomed to it. An implementor may decide that this is a more important consideration, and provide that use-model under the simplest command line options. And there is nothing that the LRM can reasonably say to make that illegal. >After reading this debate, I would be fine with treating >compiler directives the same as plain Verilog objects. >The argument about insulating different parts of large >designs from surprising interactions applies to compiler >directives as well as plain Verilog objects. I think it is a reasonable thing. And it falls out naturally if the mechanism used by the tool to cause each file to be treated as a separate compilation unit is to require them to be compiled with separate invocations. Steven Sharp sharp@cadence.comReceived on Wed Jan 25 12:45:00 2006
This archive was generated by hypermail 2.1.8 : Wed Jan 25 2006 - 12:47:13 PST