Re-introduce Ordinary Shared Variables
Is your capability/feature request related to a problem?
It has been a frustration for many designers that ordinary shared variables (OSV) (not Protected Types (PT)) were no longer a part of VHDL after VHDL-2002. We were asked to write a proposal for this feature to be re-introduced, which we think is a very good idea for many reasons. We've got plenty of feedback at various conferences and courses that designers are wanting this back.
Some benefits of re-introducing OSV are
- Simpler and faster configuration of testbench behaviour
- Simpler and faster control of verification IP - whether that is processes or entities
- Communication between testbench processes
- Hierarchy independent connection from design to testbench
- Multi-port RTL memories (input from Jim Lewis)
To elaborate a bit on control/configuration/communication - and the difference between OSV and PT:
Assume you have a verification process, where the behaviour can be controlled from a test sequencer - and assume there are 10 different features to control
- With PT the TB-developer must provide 10 different set and get methods for individual access.
- If combining the control set into a single record, then it could suffice with a single set and get, but that would give more work to the test case developer who would need to define a variable for the record, get the record, modify the right field and then set the record
- Whereas with OSV, no methods are required and all can be controlled with simple assignments, which for this kind of control is 100% safe (or as safe as PT).
Using OSV may result in race conditions, but that is also the case for most scenarios with Protected types.
Users must understand how to benefit from OSV and avoid potential problems, but the same applies for many other features in VHDL. They are great features for users who understand them, but could result in problems if not properly understood.
Describe the solution you'd like
The wanted solution is just a re-introduction of OSV as valid VHDL code - exactly as before it was removed from the language. Most (or all?) simulators are still supporting OSV - but just issues a warning that this is no longer valid code. Hence, these simulators already (or still) have full support for OSV, and the only change needed is to remove the warning. This should make it very simple for the tool vendors to accept this proposal.
Keeping OSV unchanged also means that all testbenches using OSV will still work exactly as before.