Skip to content

[racl_ctrl,dv] Template the bits of DV that needed it (but no more)#28692

Open
rswarbrick wants to merge 7 commits intolowRISC:masterfrom
rswarbrick:racl-ctrl-template-dv-properly
Open

[racl_ctrl,dv] Template the bits of DV that needed it (but no more)#28692
rswarbrick wants to merge 7 commits intolowRISC:masterfrom
rswarbrick:racl-ctrl-template-dv-properly

Conversation

@rswarbrick
Copy link
Contributor

@rswarbrick rswarbrick commented Nov 9, 2025

This is following up from feedback from @Razer6 and @davidschrammel, pointing out that my "terribly clever" DV code for racl_ctrl doesn't actually work if there is non-trivial templating. The problem was that the non-templated part of my DV code depended on names from stuff that was templated (the RAL package).

There are seven commits:

  • [dv] Make creation of CFG_T object more general in dv_base_test
  • [dv] Allow dv_base_env_cfg with a templated RAL type
  • [racl_ctrl,dv] Avoid templated type in vseq / scoreboard
  • [racl_ctrl,dv] Move the RAL type from a param to ral_type_name
  • [racl_ctrl,dv] Avoid type name of racl_ctrl_reg_block in base test
  • [racl_ctrl,dv] Override cfg_type from the tb
  • [racl_ctrl,dv] Expunge the templated RAL name from racl_ctrl DV

The first two are "generic changes" (that are needed by the racl_ctrl-specific stuff that follows).

[dv] Make creation of CFG_T object more general in dv_base_test

The test object instantiates an environment config. Unfortunately, the environment config contains stuff that depends on the RAL (and thus must be templated). The obvious approach would then be to template the test type (since it has the environment config as a parameter). But we might want more than one test type, and templating all of them starts to get a bit ridiculous!

To avoid that, this commit allows the testbench (which needs to be templated already) to pass in the type that should be instantiated for the environment config, overriding the CFG_T parameter in the test class. This type still has to be a subclass of CFG_T (to avoid the code that uses the result getting confused), but it can now depend on something templated, without needing to template the test class that receives it.

[dv] Allow dv_base_env_cfg with a templated RAL type

This is a bit similar to the previous problem, but now we're seeing a slight inflexibility of using parameters in class types. The problem is that you can have a class P that specialises to P1, but there's no way to make a class X1 #(P1) specialise some base class X #(P). SystemVerilog doesn't allow that, and probably shouldn't! There's no way to guarantee the covariance property that you need.

The unfortunate thing is that the type we fundamentally wanted was something like racl_ctrl_env_cfg #(racl_ctrl_reg_block) (where the latter type is templated). This can't derive from some my_base_class #(dv_base_reg_block).

This commit side-steps the issue, by making it so that the dv_base_env_cfg type instantiates its "core RAL model" by creating an object with a supplied type name. If nothing is supplied, that type name defaults to match the RAL_T parameter. For the templated case, this lets us get things working: our templated type can just be racl_ctrl_env_cfg #(dv_base_reg_block) (where the RAL_T parameter doesn't really do anything) and can set the new class variable (ral_type_name) to point at the templated RAL type. This can derive perfectly happily from a base class that doesn't mention the templated type.


Those are the two complicated commits. The remainder of the PR is five commits that move the racl_ctrl testbench to use this machinery in a way that avoids mentioning racl_ctrl_reg_block in non-templated code.

Phew, this was rather tricky to get right! I'm hoping that the "annoying architectural stuff" is now done, and we'll be able to do something similar for other templated IP blocks with rather less thought!

@rswarbrick rswarbrick requested a review from a team as a code owner November 9, 2025 17:15
@rswarbrick rswarbrick removed the request for review from a team November 9, 2025 17:15
@rswarbrick rswarbrick added the Component:DV DV issue: testbench, test case, etc. label Nov 9, 2025
The motivation here comes from templated blocks. Because their RAL
will depend on the template, we'll need to have some extension of
dv_base_env_cfg with the appropriate RAL type. That seems reasonable:
making a templated subclass of my_package_env_cfg isn't too much
cruft.

Unfortunately, the cfg object gets created by the test. My initial
thought was to template *that* too (grumble, grumble). But that's a
terrible idea if you have several different test types, because they
would all need templating: you can't have a non-templated class that
derives from a templated one. Yuck!

This hack should work a little differently. Now, a test can look for a
type name that is supplied by the (already templated) tb.sv.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
This is motivated by blocks that are templated, so the RAL model is
itself generated by templated code. It would be nice to avoid having
to template everything that contains a RAL.

After this commit, you can make a (simple) templated subclass that
derives from dv_base_env_cfg. This was a little tricky, because the
type parameters have to match! The solution here is to allow a user
to use a subclass of RAL_T instead.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
This type and its name are generated with a template, but we don't
care about that in either the vseq or the scoreboard.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
Now that the scoreboard uses a weaker RAL type in the parameter, we
can now switch the env_cfg to use it too.

This uses the framework developed a few commits ago ("Allow
dv_base_env_cfg with a templated RAL type"). The point is that we'll
now be able to template racl_ctrl_env_cfg (so that it can define
ral_type_name) without having to template its base class.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
This way, the code in racl_ctrl_base_test doesn't need to be templated
to depend on the (templated) type of the reg block.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
This doesn't actually do anything yet (because the CFG_T parameter
still equals the thing we're wiring through), but the trick is that it
will allow us to avoid talking about racl_ctrl_env_cfg (which should
depend on templated code) in the non-templated racl_ctrl_base_test.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
The clever bit of the trick is to define a templated env cfg class,
which is a tiny extension of the real one, whose only modification is
that it sets ral_type_name to be a templated RAL type.

Annoyingly, we didn't actually have a package in which to define the
class, so this commit has to do a bit of extra legwork, defining a
templated package and renaming the previous version of the package to
have a "_base_" in the name.

But that's it! The "interesting" part of the commit is the bit where
we no longer set ral_type_name in the module that is now called
racl_ctrl_base_env_cfg, but do set it in the templated env
cfg (racl_ctrl_env_cfg).

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
@rswarbrick rswarbrick force-pushed the racl-ctrl-template-dv-properly branch from 0d2c6e1 to 6d7df20 Compare March 9, 2026 17:52
@rswarbrick
Copy link
Contributor Author

Force-push rebases this over other PRs that have landed in the meantime.

@rswarbrick rswarbrick requested a review from vogelpi March 9, 2026 17:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Component:DV DV issue: testbench, test case, etc. IP:racl_ctrl

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant