The part that is not driven by the continuous assignment should still behave like a normal variable, so the uninitialised bits should be x not z, and released bits should retain the forced value until a new value is assigned by the procedural code.
I have added two tests to the test suite that demonstrate this, sv_mixed_assignment1 and sv_mixed_assignment2. Both are currently marked as NI as they fail.
This comes about because the compiler changes the type of the NetNet object representing the variable to UNRESOLVED_WIRE when it finds a continuous assignment to part or all of that variable. As part of fixing the procedural/continuous assignment conflict detection, I have added a flag that indicates this happens, but at present that is only used during elaboration. This information needs to be passed down to vvp so it can implement the correct behaviour.
The part that is not driven by the continuous assignment should still behave like a normal variable, so the uninitialised bits should be
xnotz, and released bits should retain the forced value until a new value is assigned by the procedural code.I have added two tests to the test suite that demonstrate this,
sv_mixed_assignment1andsv_mixed_assignment2. Both are currently marked as NI as they fail.This comes about because the compiler changes the type of the
NetNetobject representing the variable toUNRESOLVED_WIREwhen it finds a continuous assignment to part or all of that variable. As part of fixing the procedural/continuous assignment conflict detection, I have added a flag that indicates this happens, but at present that is only used during elaboration. This information needs to be passed down tovvpso it can implement the correct behaviour.