Future Directions of SVUnit
This post looks at some ideas for future directions for SVUnit. Both Neil and I put forth our views.
I’m putting these ideas out there with a hope that you’ll tell me that my thoughts are good, impractical, ridiculous, or feel free join in the discussion and share your own ideas on where we should go with the SVUnit. Now that the source code is open-source (Apache License) and pushed into a GitHub project we can all contribute and use the framework.
But first, I’ll throw my ideas onto the wall to see what sticks!
This framework was created pre-UVM so you can probably guess that I think it might be a good idea to either convert SVUnit over to be an UVM compliant framework, or at worst fork this library off and create a new project e.g., uvm_unit. That is, the non-UVM SVUnit will continue so that people not using UVM can still get value from the work, while the UVM compliant version can also develop in parallel.
I think creating a UVM-compliant library for unit-testing is necessary. The SystemVerilog world is standardizing on the UVM base class library and creating something that is eventually not compliant seems pointless. I do appreciate that there are still plenty of projects that are using pre-UVM base class libraries and can still benefit from a methodology-independent TDD framework — which is what SVUnit currently provides.
As well, if it is a UVM-compliant library, it is conceivable that it could be discussed, and eventually rolled into the UVM “standard” — giving a consistent way for all of us to do TDD.
What do I mean by ‘converting’ to UVM? At the very least, the UVM Unit would have the following features:
- Move all messaging to use the `uvm_info, `uvm_error etc. macros.
- Deriving each from the uvm_component so that it can benefit from the standard phasing and objection mechanisms.
The last one is bit open for speculation i.e., should I derive from uvm_component, or is there a more appropriate class like the seemingly appropriate uvm_test. From my perspective, the SVUnit framework needs to be fairly light-weight. (I find it difficult to describe UVM as ‘light-weight’). Comprehensive yes; light-weight, no. Meaning that while it clearly defines a very nice structure to build a verification environment, it does require a lot of classes and a lot of ‘plumbing’ code to get running. Albeit true, once you get all that plumbing code finished, you have a fine structure to work from to add the application specific code i.e., what we get paid for.
This post is already long, and I have some other ideas to cover so my next post will start to put out some further ideas on creating a UVM-compliant SVUnit library. Here’s a teaser UML diagram of what I’m thinking. More on that in a later post…
The second direction that needs to be considered is to improve the current batch of scripts that are available to generate all the ‘plumbing’ code required by the framework itself. Neil has done a great job updating these scripts to be more robust than the initial implementation. These generators make it truly convenient and quick to create a test environment to run your unit tests quickly. Two key elements of TDD are “fast” and “easy”. In other words, you want to create a testcase quickly and easily, and you want to run a testcase quickly and easily. The generator scripts enable that fast and easiness.
My current thoughts on improvements to the generator scripts are:
- Look at using the more standard ‘template’ libraries to generate the code.
- Generate the appropriate UVM related infrastructure
- Wrap a simple GUI Test Runner to allow people to execute, report and view test case execution. Related to this is that I’m currently looking at Jenkins as a continuous integration tool (think continuous regression). If I could tie the two together that would allow me to launch jobs and then the pass/fail reporting would be done for me. Jenkins uses a web-based front-end. Just a “twinkle-in-my-eye” for now.
Eating My Own Dog Food
Now, do I use TDD for creating the UVM-SVUnit? Kind of recursive, but you bet. Another task for this framework is to create a set of unit-tests that test the framework.
First on the list is eating my own dog food. Personally, I think with TDD we have a technique that can provide immediate benefits to hardware teams in that it’s tangible, understandable and doable. TDD doesn’t require major organizational change or buy-in (really… you can do it by yourself without anyone else even knowing) and SVUnit is easy to use.
On the flip-side, TDD and SVUnit are also unproven in hardware hence me having “eat my own dog food” at the top of the list. I’ve already started using it for all the new code I’ve written and the results have been promising though not yet conclusive. I’ll continue to use it so I can get a better idea of what works, what doesn’t and what makes sense in future.
Next on my list is supporting others that are interested in SVUnit (we’re actively looking for people to… uhh… eat our dog food so if you’re interested in being one of the first few to try SVUnit, you can let us know at firstname.lastname@example.org or email@example.com). I started the SVUnit Demo Series that should help get people going. I’ll continue with more of those in future. We also have some usage examples to update. We need an FAQ page that new folks can reference for the easy stuff. Basically, whatever else people need to make an informed opinion, I’m ready to put it together :).
Then there’s “testing my own dog food”. This is something I started a couple months ago. The SVUnit testsuite isn’t comprehensive yet (ie. there are a lot of untested features in the SVUnit code), but it’s started so we can regress some of the core functionality. I’m also verifying new features and updates as they happen.
Honorable mention on my list is to write a project charter. Before we have too many hands in the cookie jar, we’ll need to capture some big picture goals for SVUnit with a list of things that we’re not going to concern ourselves with. Considering it’s an open-source project, we’ll also need some development guidelines.
Q. What are your thoughts on the direction where SVUnit can (or should go)?
One thought on “SVUnit Future Directions”
On the point of using uvm_component vs uvm_test have you ever looked at the implementation of uvm_test? I wouldn’t really sweat this decision very heavily.
There is nothing in the BCL that differentiates uvm_test or uvm_component – even the uvm_root::run_test method that creates your test and executes it refers to the uvm_test instance as uvm_component.
No special sauce at all for uvm_test that I can see – so use it – in fact, you probably want to make some sort of uvm_unit_test base class to work from.