Generate stripped-down manifest (evaluate generate blocks)

Hi,

I freely admit to being a raw-newbie with this and may be asking an obvious question...

I am trying to read in a large “generic” manifest for a project, many of whose components are included/not included based on parameters driving generate statement logic.

parameter USE_BIG_CORE = <from external over-ride>;
generate 
  if( USE_BIG_FAST_CORE )
    big_fast_core u_core (…);
  else    
    small_slow_core u_core (…);
endgenerate

My goal is to just list the modules/files that are actually included and skip those that are never instantiated because of the disabled generate logic. The intent is to be able to construct a stripped-down manifest of just the files required by the specific configuration (no extraneous files).

Is this possible with your package?

BTW: While trying to learn how you put all this together (by tracing through vhier) I came across the follow that appears to be an anomaly:

Verilog::Getopt.pm, v3.302 - Line 336: Shouldn’t the replacement be made using $out instead of $filename?

Feature suggestion: VCS (and possibly other simulators as well) allows the use of a "-F" inside a manifest to include a new manifest but set the ‘root’ directory to the directory where the new manifest is located. This is similar to the "-f" except that where the lower case retains the location of the current manifest as its ‘root’, the upper case version resets the ‘root’. This is a very nice feature because it allows hierarchical manifests to be created such that each sub-manifest is correct and unique to its own location – things can be built up in a library methodology. Is the "-F" something you might see adding to the project?

Best regards...

Replies (4)

RE: Generate stripped-down manifest (evaluate generate blocks) - Added by Wilson Snyder over 1 year ago

It's possible but not easy. This requires full elaboration of the design, which Verilog-Perl doesn't currently do. If your design doesn't include SV verification code, an alternative is to feed it to verilator with a -MMD --lint flags, which will create a dependency list which is what your looking for.

$out - yes, fixed.

The -F sounds reasonable; please add a bug so I don't forget to get to it soon.

RE: Generate stripped-down manifest (evaluate generate blocks) - Added by Wilson Snyder over 1 year ago

Actually, even if a module is "if"ed out, it's still legal for the compiler to need the source for the generate-if removed file. So to be most portable I think you should include them.

RE: Generate stripped-down manifest (evaluate generate blocks) - Added by Neil Hamilton over 1 year ago

Wow! Thanks for the quick answer!

Yes, I agree that it is the most portable solution to send everything. We have discovered a (very) few tools that absolutely require the all modules be present (0-In comes to mind) whether they are enabled in the logic or not. However, most tools don't require the 'missing' modules to be present (though they may fuss a bit with a warning or two).

However, we are in the business of shipping IP and it is highly configurable as to what components are in or out of a specific design. We prefer to not have to ship components that are not in the contract. (We could generate stub modules but that could be a maintenance nightmare.)

I will try your verilator suggestion. It sounds promising.

Cheers...

RE: Generate stripped-down manifest (evaluate generate blocks) - Added by Wilson Snyder over 1 year ago

To me, once you say "shipping IP" your standard of delivery should now be much higher. (BTW please see the "10 IP edits" linked here under papers - thanks!)

Even though you agree some tools like 0-in require the modules you're not going to ship them? Won't that break your customers? I'd be really frustrated if I was your customer and you didn't ship those files.

Since you're already proposing to detect the modules that aren't needed, I'd suggest you take the extra time to auto-generate the stubs for them. It's an easy Verilog-Perl script to read a module and write out just the module statement and I/O declarations.

(1-4/4)