Handling parameterization in SystemVerilog packages

Question

SystemVerilog added packages to provide namespaces for common code pieces (functions, types, constants, etc). But since packages are not instantiated, they cannot be parameterized, so dealing with parameterized members is problematic. In practice I have found this pretty limiting since very often my custom types have some parameters dictating field widths etc.

I generally deal with this by using parameters with default values and just understanding that I will need to go back change the package source code for some applications, which seems very wrong to me. But i have yet to find a way to handle this more cleanly. For example:

package my_pkg;
    parameter ADDR_MSB = 7;
    parameter DATA_MSB = 31;

    typedef struct {
        logic [ADDR_MSB:0] address;
        logic [DATA_MSB:0] data;
    } simple_struct_t;

endpackage

Has anyone found a cleaner way of dealing with this? I'd love to hear about it since I think packages are a very powerful addition to SV enabling safer code reuse, but this limitation is pretty severe.

Answer 1

Yeah, I agree. That's a missing feature of packages.

Just spitballin' here, but you could abstract your parameters into a secod package and use the right one at compile-time to tweak your package. I know that's not what you really want, but it might get you close.

I think I would just end up with multiple packages representing each configuration if I faced this in my project.

Answer 2

I have a couple of thoughts. First, I would lean towards modeling my data using classes instead of structs. Classes can be parameterized, dynamically allocated, randomized, contain covergroups, etc. I only use structs when I want a packed struct. Packed structs are wonderful because you can assign to them like a regular vector and then access the data using the named fields. Very nice. :)

Second, even if it were possible to redefine package parameters, there is only one "instance" of a package in a simulation; there can't be multiple specializations with different parameter values like there can be for modules or classes. So it seems to me that doing away with the parameter and using a macro instead is a workable solution. Although I don't like using macros, that would allow you to recompile with new values without changing the source code.