BTW, I don't think that the ability to refer to tasks and functions that have not been declared yet is due to a special "forward reference" rule. I think it is due to a special and nonstandard "upward reference" rule. Verilog-XL allows references to tasks and functions that have not been declared in the module, and treats them as if they were hierarchical names, searching upward for them in the design hierarchy. This allows tasks and functions to be declared in a top-level module, but used with simple names, giving much the same effect as a package. This is not specified in the 1364 LRM, but many tools support it because XL does. I believe that the "forward reference" case probably just falls out from this. If there is a reference to a task or function that is declared later, then it is treated as if it is not declared in the module. Then the upward search in the design hierarchy starts with the current scope, and finds the declaration in the current module. This special "forward reference" case is causing problems with the search order, and the full general "upward reference" case would cause even more. If you want to stick to the letter of the standard, then tasks and functions can't be used before being declared, exactly like parameters and variables. This makes their search order the same as parameters and variables. It also means that a lot of legacy Verilog code that relies on forward references won't work in a SystemVerilog tool that uses the standard search order. If you want to accept the de facto standard of full "upward reference", then you have to figure out where that falls in the search order too. That could get messy. However, this is the only way to get compatibility with legacy code that might rely on "upward reference". What people have been discussing so far has effectively accepted the nonstandard "forward reference" special case, without the general case that it comes from. There is some merit to this, since the "forward reference" case is probably a lot more common than full "upward reference." However, taking this approach means that the rules being discussed are not compatible with either the official or the de facto Verilog standards. Steven Sharp sharp@cadence.comReceived on Mon Aug 29 16:56:09 2005
This archive was generated by hypermail 2.1.8 : Mon Aug 29 2005 - 16:56:59 PDT