OOPs! 3 Issues That Show System Verilog Threads are Not OOP Safe!
Verilog has a very limited and simple hierarchy. All processes are present in static modules. In some ways, System Verilog extends this concept of hierarchy with the support for dynamic data type of class. In System Verilog processes are also present inside dynamic objects. System Verilog updates to fork-join constructs, make the process more flexible and dynamic.
However, this also increases complexity of using processes in System Verilog. What makes it tricky is process usage in the context of object oriented programming. I know that sounds counter intuitive. Object Oriented Programming is good, right? What I mean is, not all the constructs of System Verilog are compatible with object-oriented interpretation. This limited support of object-oriented programming leads to confusion.
In this article I plan to provide the details of three such sources of confusion I have faced. I start off with a refresher about the updates to the fork-join construct in System Verilog. The refresher is followed by top three sources of confusion with examples.
Related Semiconductor IP
- Mesochronous Bridge for PCIe/CXL
- AI-native GPU
- OpenGMSL Verification IP
- OpenGMSL Leaf IP
- FlexGen Multi-Die Smart Network-on-Chip (NoC) IP
Related Blogs
- 3 Reasons That the Semiconductor Clouds Are Gathering
- Qualcomm: Scaling down is not cost-economic anymore - so we are looking at true monolithic 3D
- Six Issues that will Inhibit Profitable Growth in 2010 - Be Ready
- 70% of re-spin issues are AMS in nature: How mixed-signal design can mess up a perfectly good SoC
Latest Blogs
- Automated, Faster Specification to Sign-Off with IDS-AI
- NovaTech Automation Crius PIU: Bringing Conventional Instrument Transformers onto the IEC 61850 Process Bus
- Single Pair Ethernet and TSN: The In-Robot Network Behind the Next Humanoid Robots
- A design path to success exists for ultra-low-voltage SoCs
- Where Routine Flow Ends Veriest Formal Expertise Begins