WIP: Add a simpler version of the driver compatible with Verilator 5.020

[thommythomaso]

TODO:

• Pull in 8ef87ab
• Avoid code redundancy with jtag_test itself (how about a macro?)
• Once to be merged, close redundant Verilatable jtag_test module #175.

[bluewww]

As from our previous discussion I like and support the idea. Let me know if you need directions.

[thommythomaso]

As from our previous discussion I like and support the idea. Let me know if you need directions.

Thank you. From a functional perspective, the PR is ready to be reviewed. However, we do not have a solution for backward compatibility yet.

Our idea was to wrap the module-based driver in the more complex class-based driver. After checking the spec (I should have checked before - sorry), it is clear that modules cannot be instantiated within classes. Long story short, we do not yet have a solution to ensure backward compatibility without code duplication.

[paulsc96]

Our idea was to wrap the module-based driver in the more complex class-based driver. After checking the spec (I should have checked before - sorry), it is clear that modules cannot be instantiated within classes.

This may be a more extreme measure, but what if we just replace jtag_test and create a new pre-release version?

As we discussed before, there is no good reason for a non-parametric interface to require virtual interfaces and classes for verification.

Nobody using proper versioning practices should experience any regressions from this change, and updating testbench code to the new module approach is very straightforward.