Open RasmusGOlsen opened 1 year ago
SystemVerilog is a Verilog release. It can be distinguished by the Verilog version.
Good point.
I don't see any reason for making two different classes.
Currently the file extension is also (implicitly?) bound to the class.
Maybe we need a concept for an n-to-m mapping.
I don't think there is anything wrong with having both a VerilogSoureFile and a SystemVerilogSourceFile class. But to share the similarities the SystemVerilogSourceFile class should basically just look like this since the only difference is the value of the Verilog version.
class SystemVerilogSourceFile(VerilogSourceFile):
pass
This sounds reasonable.
As a consequence, the fields _verilogVersion
and _svVersion
, and there properties should be merged.
IEEE Std. 1800 superseeded IEEE Std. 1364, so only SystemVerilog parts should exist. On the other hand, Verilog is the common name part in both standards.
We could model it as follows:
SystemVerilogSourceFile
from VerilogSourceFile
.SystemVerilogHeaderFile
from VerilogHeaderFile
._...Version
field.VerilogVersion
property on Verilog classes.SVVersion
property on SystemVerilog classes.Latest changes are on dev branch.
As an update: I'm still struggling with a major change to pyTooling (changing to v6.0), which blocks me on other repositories to upgrade and merge items.
SystemVerilog is a Verilog release. It can be distinguished by the Verilog version. I don't see any reason for making two different classes.