Add -blackbox option to cutpoint pass

[KrystalDelusion]

What are the reasons/motivation for this change?
Supersedes #4812.

Explain how this is achieved.
Calling cutpoint -blackbox [options] will replace the contents of all (black)boxes in the design with a formal cut point ($anyseq cell by default).
This is preferable to #4812, which instead calls cutpoint on instances of (black)box modules.
Since the module now has contents, it is also no longer a (black)box so we can remove those attributes.

If applicable, please suggest to reviewers how they can test the change.

[povik]

From #4812:

This way we avoid any problems with needing to derive de-blackboxed modules to handle I/O signals with parametrizable widths, which isn't possible when they came from verific.

So I take it this new approach doesn't support parametrizable widths.

[KrystalDelusion]

Uhhh, pass?

module top(input a, b, output o);
    wire c, d, e, f;
    bb #(.SOME_PARAM(1)) bb1 (.a (a), .b (b), .o (c));
    wb wb1 (.a (a), .b (b), .o (d));
    bb #(.SOME_PARAM(2)) bb2 (.a ({a,b}), .b ({c,d}), .o ({e,f}));
    some_mod some_inst (.a (c), .b (d), .c (e), .o (o));
endmodule

(* blackbox *)
module bb #( parameter SOME_PARAM=0 ) (input [SOME_PARAM-1:0] a, b, output [SOME_PARAM-1:0] o);
assign o = a | b;
specify
	(a => o) = 1;
endspecify
endmodule

(* whitebox *)
module wb(input a, b, output o);
assign o = a ^ b;
endmodule

(* keep_hierarchy *)
module some_mod(input a, b, c, output o);
assign o = a & (b | c);
endmodule

read -vlog2k cutpoint_blackbox.v
hierarchy -top top
cutpoint -blackbox
flatten
opt -purge

read -vlog2k cutpoint_blackbox.v
hierarchy -top top
select top
setundef -blackbox -anyseq

[KrystalDelusion]

I'm not seeing any change in behaviour there; the $anyseq cells for the bb module are both 2bit wide when coming from verific using both the cutpoint and setundef versions of this.

[povik]

I understood inserting the $anyseq cells on blackbox outputs without going the flatten route was motivated by making parametrizable widths work with Verific. Since this PR now has a different approach I'm wondering if parametrizable widths dropped from the requirements

[KrystalDelusion]

I don't have any examples that demonstrate whatever problems are being encountered with the current options when it comes to blackboxes in verific, but as far as I can tell changing the cell outputs (i.e the setundef version of this) gives the same result as this when it comes to output widths. In my quick testing it looks like verific sets the port width on the module and all instances of it to the widest required.

Rather than it no longer being required, I would say that if this implementation is not meeting that requirement then I don't see how #4812 was.

[KrystalDelusion]

I wasn't there for the original dev JF discussion, but when we discussed #4812 in docs JF about whether calling cutpoint from within setundef was the right approach we said:

• Using cutpoint to remove an instance should be equivalent to cutting out all contents of the module and then flattening that module into the module containing the instance (wrt generated $scopeinfo and hdlname attributes)
• Cutpoint alone can handle all current use cases, let's not put it in setundef for now

(or at least that's what is in the minutes)

[KrystalDelusion]

I worked out that calling hierarchy with -keep_portwidths prevents changing the cell port width to match the module definition and matches the behaviour between read_verilog and verific. It looks like when it comes from read_verilog, the blackbox module has a ID::dynports attribute on it which is how the problem gets resolved with read_verilog. So I've added a check to hierarchy which sets a flag (boxed_params) if a cell instantiates a parametrised blackbox module without the ID::dynports attribute, and then if that flag is set, a verific module has been loaded, and there's a mismatch in the port size then it raises a warning instead of resizing the port.

I also added an extra flag to cutpoint, so that calling cutpoint -blackbox -instances will replace instances of blackbox modules (a la the approach from setundef).

So this does now properly support modules from verific with parametrisable widths, but I'm not sure if there are any cases where skipping the resize could cause problems that would make this unsafe. Also whether the -instances behaviour should be a flag or if I should just remove the other method.

Thoughts, @povik ?