AsFigo - enabling opensource chip design and verification.

Race conditions are one of the dreaded aspects of Verilog/SystemVerilog. Race conditions in SystemVerilog  lead to unpredictable behavior due to competing threads or processes accessing shared resources without proper synchronization. Debugging race conditions is challenging due to their non-deterministic nature, which means issues may appear sporadically and be hard to reproduce, complicating the identification and resolution of the underlying problem. It gets compounded by the fact that different EDA tools can behave differently on your code (with race condition) and yet be 100% LRM compliant (meaning no one will fix it for you).  Would you believe that up until recently, UVM Base Class Library (BCL) had potential race conditions deep inside? Hard to believe? See for yourself a report from IEEE 1800.2 UVM core team members:  08376: 'static const xx ' class members with initialization - Accellera Mantis (mantishub.io) Understanding Race Conditions in UVM: Why S...

Our Director of Verification, Ajeetha Kumari took part in offering her review comments based on her decades of AMS design verification experience to Accellera's UVM-MS standard.  Overall, our focus is on  clarity, correctness, good coding practices, and ensuring UVM-MS follows standard verification methodologies .    Clarifications and Expansions Suggested explicitly stating IEEE 1800.2 UVM version to avoid ambiguity. Asked whether VHDL should also be considered in addition to SystemVerilog. Recommended good coding guidelines for UVM-MS lint rules . Pointed out grammatical issues , such as removing unnecessary "s" in certain words. Suggested formatting improvements, such as italicizing specific terms . Code and Implementation Improvements Recommended ensuring all UVM components/agents are in separate packages for better reuse. Questioned the lack of UVM factory registration for some proxy classes. Suggested adding function prototypes (like ne...