Simplifying SoC Verification by communicating between HVL Env and processor

By Sandeep Vaniya
October 20, 2014

Before I describe a way to simplify SoC verification, let me clarify what do I mean by SoC. SoC, System on Chip, means a chip which is having different design blocks integrated together, in which the main controlling block is the Processor (Proc). The Proc in SoC will have access to most or all blocks in the chip to control them.

Now, if we need to verify SoC, we have to deal mostly with Proc because most of the things will be controlled by it. We need to initialize/configure registers of different blocks, configure DMA channels for data transfer, handle interrupts and other kinds of exceptions, etc. using Proc only. When we say, we have to do all these things using Proc that means, we need to write C or Assembly Language code which will be converted to hex code (machine code), which Proc can execute.

Since we have to do most of the things in C or Assembly Language, strength of verification will become very limited because we can’t use powerful features of HVL like SystemVerilog (SV), Vera, etc.

Someone might argue that we can use PLI or DPI (of SV) for directly calling C from SV and vice versa. But, you might already know that PLI or DPI is going to make simulation very slow which can’t be afforded if you are verifying a very big chip. Also, Proc might not support syntaxes which are required to use DPI. In case of ARM Proc (which supports very limited set of instructions), it doesn’t even support all syntaxes of C language.

As an alternate way, we can implement our own communication mechanism between Proc and HVL env which is faster than PLI/DPI and flexible also. Since we are developing it on our own, we can customize it as per our requirement.

Using this new mechanism,

1. We can read/write any register or memory location which can be accessible by Proc (C code), using SV.
2. We can pass valuable information back and forth from Proc to HVL Env and vice versa, to achieve synchronization between the two. This will be very useful in generating complex SoC scenarios.

From now onwards, we will term this mechanism as SV-C (SystemVerilog-C) mechanism.

Following shows the block diagram for SV-C mechanism.

Figure 1. SV-C Architecture Diagram

In this mechanism, we will have set of memory locations, which will act as communication medium between C code (Proc) and SV code. These memory locations should be very near to Proc so that it can access them with minimum amount of latency. Time that Proc takes to access these locations determines the speed of this mechanism. For faster access, we can map these locations in DTCM (Data side Tightly Coupled Memory) of Proc or nearest cache memory available to Proc. One more thing, this memory should also be accessible to SV using backdoor.

We will use three words (32-bit) of this memory for CMD_LOC, ADDR_LOC and DATA_LOC. These locations are used to pass register/memory read/write request/data to/from Proc/SV.

1. CMD_LOC will be used to pass Read, Write and Done command from SV to Proc and Sync command from Proc to SV.
2. ADDR_LOC will be updated by SV to pass address value of register to be read/written using Proc. Any address value can be provided which Proc can access.
3. DATA_LOC will be updated by SV to pass ‘Data to be written’ in case of Write Command. And it will be updated by Proc to pass ‘Read Data’ in case of Read Command.

We will have SV-C Interrupt Service routine written in Proc to understand and execute the requests made by SV. SV will also have set of tasks/functions to request read/write access to registers using Proc.

Now, let’s look at how the flow works.

1. SV code will update CMD_LOC, ADDR_LOC and DATA_LOC locations as per the requirement using backdoor and generates Interrupt to Proc.
2. Once Interrupted, Proc executes SV-C Interrupt Service routine and executes the things requested from SV.
3. Once done with execution, Proc updates CMD_LOC with Sync Command, which indicates completion of request to SV code.
4. By this time, SV code was waiting for CMD_LOC to be updated by Proc with Sync command.
5. Once SV receives Sync Command in CMD_LOC, it ensures that Write/Read request, it made earlier, is executed by Proc. After this, it can take read data from DATA_LOC in case of Read request.
6. Proc continues to execute SV-C Interrupt Service Routine until it gets Done Command in CMD_LOC.
7. When SV no longer need to access any register, it will update CMD_LOC with Done Command and de-asserts the interrupt.
8. Once interrupt is de-asserted, Proc comes out of SV-C Interrupt service routine and executes its main code.

Following state machine depicts details for Read Command execution.

Figure 2. SV-C Read State Machine

This explains how we can access any address (register or memory) which is accessible to Proc, using SV.

Now, while generating different SoC test scenarios, you might need to pass information from Proc (C code) to SV and vice versa. You can achieve this by using SV-C Stat Locations as depicted in Block Diagram.

1. SV will write these locations using backdoor to pass information to Proc. Proc will read them and get the information from SV.
2. Proc will write these locations and SV will read them using backdoor to get information from Proc.

One can reserve one of the Stat Location for Synchronization between SV and Proc to know when to get the information. So when this Stat Location is updated with specific pattern, which is agreed upon by Proc and SV code, Proc/SV can read Other Stat Locations to get the information.

For example, consider one of test scenario requires SV code to determine how much cycle spent in DMA transfer, so it can calculate the throughput of the transfer. In this case, when Proc gets transfer completion interrupt from DMA, we can read cycle counter register and updates one of Stat Location with particular pattern and other Stat Location with cycle counter value. Once SV will detect that pattern on particular Stat Location updated by Proc, it will come to know that DMA transfer is completed and then it can read cycle counter value from other Stat Location updated by Proc. This way SV code will come to know about how much time taken to do the given amount of data transfer. This is very simple example. Based on complex SoC scenarios, these Stat Locations can be used accordingly.

At last, we have implemented and used above mentioned SV-C mechanism in couple of our SoC verification projects and it proved very useful, flexible and efficient. We were able to access register/memory from SV as fast as if they were accessed directly using Proc. We were able to generate very complex scenario easily which is very difficult to generate in absence of this mechanism. We have mapped memory space used between SV and Proc into L2 (Level 2) cache outside the Proc.

In case of any query/question, you can reach me on my email ID: sandeep.vaniya@gmail.com.

Acronyms used in this article: