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.

Uhhh, pass?

moduletop(input a, b,output o);wire c, d, e, f;bb #(.SOME_PARAM(1))bb1 (.a (a), .b (b), .o (c));wbwb1 (.a (a), .b (b), .o (d));bb #(.SOME_PARAM(2))bb2 (.a ({a,b}), .b ({c,d}), .o ({e,f}));some_modsome_inst (.a (c), .b (d), .c (e), .o (o));endmodule(* blackbox*)modulebb #(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;endspecifyendmodule(* whitebox*)modulewb(input a, b,output o);assign o= a ^ b;endmodule(* keep_hierarchy*)modulesome_mod(input a, b, c,output o);assign o= a& (b| c);endmodule

read -vlog2k cutpoint_blackbox.vhierarchy -top topcutpoint -blackboxflattenopt -purge

read -vlog2k cutpoint_blackbox.vhierarchy -top topselect topsetundef -blackbox -anyseq

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

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

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 thesetundef 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.

I wasn't there for the original dev JF discussion, but when we discussed#4812 in docs JF about whether callingcutpoint from withinsetundef 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)

I worked out that callinghierarchy with-keep_portwidths prevents changing the cell port width to match the module definition and matches the behaviour betweenread_verilog andverific. It looks like when it comes from read_verilog, the blackbox module has aID::dynports attribute on it which is how the problem gets resolved withread_verilog. So I've added a check tohierarchy which sets a flag (boxed_params) if a cell instantiates a parametrised blackbox module without theID::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 tocutpoint, so that callingcutpoint -blackbox -instances will replace instances of blackbox modules (a la the approach fromsetundef).

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 ?