Creating IP level test cases which can be reused at SoC level

By Ravinkumar Patel, eInfochips an Arrow company

We are in an era where time is very important for product delivery. For processor based SoC, we invest lot of time in creating test cases which could have been simply reused from IP level verification. What is the blocking item here is C based flow - For processor hex code is required and we generate it using C file whereas IP level verification is generally based on SV-UVM. But is it too easy to reuse IP level test cases at SoC level? Yes it is, and that is what we are going to discuss.

Generally, we put lot of efforts into creating constraint random test cases at IP level verification but it is not being reused at SoC level. How can we utilise the IP level test cases at SoC level with minor extra efforts during test case creation at IP level verification itself.

Let us first discuss general CPU based SoC level test case flow.

You will have two files in your SoC level test case. i.e C and System Verilog(.SV referred henceforth in this paper). In C file, we write conditional/unconditional register write/read on any IP in the SoC. In SV side we might have lot of UVM based code to verify the functionality of the IP like creating packet from/for VIP, starting sequences etc. In IP level test cases we generally have one file.ie “.SV”. In this “.SV” file we will have both register write/read and UVM based code like starting sequences.

Idea is to come up with a flow where we can separate register write/read and other UVM based code in two different “.SV” files/classes in IP level test cases itself. Separate files can be created for Register write/read code (Same as “.C” code in CPU based verification) and rest of the UVM code (Same as “.SV” code in CPU based verification). If we already have these two separate files at IP level test case itself, We can convert file which contains register write/read code to C file by just using simple Perl script. These two “.SV” classed can be ran as parallel threads during testcase execution.

Let us consider below example test.

The above mentioned example test case is what we generally do in IP level test cases.

Now we want to re-architect this IP level test case such that it can be used in SoC level as well without any major modifications/efforts. We will achieve this by creating two separate “.SV” file as discussed initially with one file contain register write/read information and other related to VIP sequence from above example.

Below flow chart describes the communication between C and “.SV” side using sync_method.

sync_method is required at SoC level because you need to have some mechanism which provides runtime timing control to perform certain register write/read from processor (which is in C file) .i.e In above example, first we configure I2C controller IP registers from C file and then we pass the control to “.SV” side to start VIP sequence(i.e We cannot start VIP sequence at 0 time since Controller configuration is not yet done) using sync_method. Similarly we pass control from “.SV” side to C file using sync_method once VIP sequence is completed. In C file than we can check status register value of controller IP(Checking status ).

Logic of sync_method() used in above example test is out of scope of this article.

We can use this test flow in IP level test cases and then when we migrate to SoC level verification same test cases can be reused by just converting SV file(which contains register write/read code) to C file using simple Perl script.

To conclude though we need to spend little more time in creating IP level test cases, this flow saves approximately 30% to 70% of time we spent in creating SoC level test cases. This percentage may vary depending on the complexity of protocol and test cases. It may not be required to code all IP level test cases using this approach hence effective decision can be taken to select set of test cases to be coded using this approach.