I am working as ASIC Verification Engineer, would like to write a paper (Abstract) on the topic “Unique Challenges in Verifying Automotive SoCs”.
Option 1 - I will start with best features of SV. Like; $countbits keyword in sv used to count number of words in the given input. But still some people will not use and they write for loop which acquires 4 to 5 lines of code. Hence we can save few lines using best features of language (avoiding redundant codes).
Option 2 - I will try to use few features of Cadence(ncsim)where users can run test cases in easier steps. But I can’t explain the same feature in Questa or VCS because user might using any simulator. Hence, this option may be difficult to include.
Kindly let me know whether can I use option 1 (and similar things ) to this topic. If not please suggest me few topics where I can prepare for Abstract on the above topic. I am not sure what things will come under “Unique Challenges in Verifying Automotive SoCs”.
I have very less idea on SOCs, so please suggest is it possible to proceed ?
In reply to Mahesh K:
Your title is Unique Challenges in Verifying Automotive SoCs, but your above options seem to concentrate on language features and tools. Although those are important, I would think that the challenges are far broader than that. For example, in the larger picture I can see:
Defining the requirements, including those in the field of safety
Defining the test plans
Defining the verification environment and methodologies
Incorporation of IPs and configurations
synthesis
Technologies of ASICs (e.g., high temp operation, capacity, vibration resistance, etc)
You can go from the large picture to more specific things like languages and tools types.
Below is a link to a few pages from my SVA Handbook 4th Edition, about design processes and SVA.
On languages and libraries, you may want to include:
SystemVerilog
SVA and SV checkers (included in SystemVerilog)
formal verification
UVM
Debugging and coverage methodologies
On tools, I would avoid naming specific tools, but I would consider adding features that tools provide, particularly in the field of debugging, coverage, synthesis, timing analysis, verification, etc. If you start naming tools, you run the risk that what you write is outdated or overcome by a better tool. Instead, talk about features of tools.