Extern function/task definition in generate-block scope within scope of class definition

Is it legal to define an extern function within an if-generate that is in the same scope where the class was declared?
eg:

module m # (parameter bit ME = 1) ();
class c();
 extern function void hello();
endclass
if (ME) begin
 function void c::hello();
  $display("Hello You!");
 endfunction
end
endmodule

I see that the spec requires ‘same scope’, but it wasn’t clear to me if this meant access to all scoped variables or local scope and not within a generate block. I want to define 2 different variants of a function/task dependent on a parameter.

Thanks,
Nachum

In reply to nachumk:

Please use code tags making your code easier to read. I have added them for you.

“same scope” means the scope with the same name. The generate block creates an unnamed sub scope, so this is not legal.

Without knowing exactly why you want to do this (see the XY problem), it’s hard to suggest a better alternative.

You might want to look at this paper which was awarded the Best Paper at the Design and Verification Conference (DVCon) 2016.

In reply to dave_59:

I need 2 different definitions of a function dependent on a parameter, and this seemed like an easy way to do this. Thanks for your response.

In reply to nachumk:

Why is this not a workable solution?

module m # (parameter bit ME = 1) ();
class c();
  function void hello();
    if (ME) begin
      $display("Hello Me!");
    else 
      $display("Hello You!");
  endfunction
endclass

endmodule

In reply to dave_59:

I have 2 different protocols that I support with my module for a register interface. I use a class to drive the register interface. As the driver class is different depending on the protocol, the handle that I use is different and the other handle doesn’t exist. Without both handles I get the error E,CUVUNF under Cadence’s tools.

I am driving the protocols directly without any abstraction as I need to drive a privileged transaction and they work differently (eg my base class is useless in this scenario). Although of course a bit more abstraction and I could have a common class that knows how to do this, but that feels a bit like over-engineering.

I’ve resolved the issue (atm in an ugly way) by having a class handle for each protocol, and letting one of them stay null and the other get assigned. And I use this solution within the task to determine which to use. But it’s ugly, and I would’ve preferred the extern definition inside an if-generate.

I thought this extern mechanism would work, so I was saddened to find out it doesn’t. If you have better ideas, I’m all for it. Thank you