AsFigo - enabling opensource chip design and verification.

Is your DPI-enabled SystemVerilog simulation running slow? Are you looking for ways to improve performance? Sometimes, a small remodelling of your DPI functions and using pure functions can help significantly. The Direct Programming Interface (DPI) allows SystemVerilog to interact with C code. Among the DPI constructs, pure functions are special because they are side-effect free and predictable. Using them correctly can improve simulation speed and reliability. However, SystemVerilog LRM imposes several subtle restrictions on imported pure  functions. Let's delve into one such nuance today a bit deeper! Referential Transparency Referential transparency is a concept from programming. An expression is referentially transparent if it can always be replaced by its value without changing the behaviour of the program. For example: The expression 2 + 3 can always be replaced with 5 . The expression rand() cannot, since each call may give a different result. In SystemVer...

 SystemVerilog is a vast language with long history. With any history, you have the problem of legacy - sometimes bad too, unfortunately. One such bad legacy is the use of "DPI" as spec-string in SystemVerilog Direct Programming Interface (DPI) code, used to interface C with SystemVerilog. It is a very commonly used feature in certain classes of systems as it allows reuse of reference models as-is in Design Verification. Jumping straight into a potential compatibility issue with DPI, historically Accellera SV (3.1a) allowed the following code: import "DPI" function int c_sum (int f1, f2);     However, as LRM matured and became an IEEE 1800 version, the above got refined to be "DPI-C". This is often referred to as "spec-string". Now, what's the big deal - one may ask, well below is a quote from IEEE 1800 LRM: So, if your old SV code was using "DPI" as spec-string, potentially: You have confusing 2-state, 4-state value passing across ...