Simplifying SoC Verification by communicating between HVL Env
and processor
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,
- We
can read/write any register or memory location which can be accessible by Proc
(C code), using SV.
- 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.
- CMD_LOC
will be used to pass Read, Write and Done command from SV to Proc and Sync
command from Proc to SV.
- 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.
- 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.
- SV
code will update CMD_LOC, ADDR_LOC and DATA_LOC locations as per the
requirement using backdoor and generates Interrupt to Proc.
- Once
Interrupted, Proc executes SV-C Interrupt Service routine and executes the
things requested from SV.
- Once
done with execution, Proc updates CMD_LOC with Sync Command, which
indicates completion of request to SV code.
- By
this time, SV code was waiting for CMD_LOC to be updated by Proc with Sync
command.
- 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.
- Proc
continues to execute SV-C Interrupt Service Routine until it gets Done
Command in CMD_LOC.
- When
SV no longer need to access any register, it will update CMD_LOC with Done
Command and de-asserts the interrupt.
- 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.
- SV
will write these locations using backdoor to pass information to Proc. Proc
will read them and get the information from SV.
- 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:
|
Acronym
|
Description
|
|
SoC
|
System on Chip
|
|
SV
|
SystemVerilog
|
|
Proc
|
Processor
|
|
PLI
|
Programming
Language Interface
|
|
DPI
|
Direct
Programming Interface
|
|
TCM
|
Tightly Coupled
Memory
|
|
DTCM
|
Tightly Coupled
Memory for Data
|
|
HVL
|
Hardware
Verification Language
|
