Published Articles

CPAN.org: Perl GUI Builder

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,

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:

 

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

Link to Published Article

Design-reuse.com: An Effective way to drastically reduce bug fixing time in SoC Verification

Introduction

Many times we are not aware of very useful EDA tool options which are already available. Even if such options are very well documented, we don't look at them and try them [I partly agree that tool supports MANY options and trying/understanding them is time consuming and boring]. But some options are very useful and if you know them, it makes job of design engineer and/or verification engineer very easy.

Here, I am going to talk about one very powerful and useful VSIM option of QuestaSim. It is VCDSTIM option of VSIM. As per Mentor Graphics Corporation, people didn’t understand the value of this powerful option in bug hunting though it is already in the tool for so long.

[Note: VSIM is last step of 3 step (vlog => vopt => vsim) simulation flow of QuestaSim].

Details of VCDSTIM option

VCDSTIM is one of the options of VSIM of QuestaSim. Here are the details of this option as described in QuestaSim User Manual.

Read Complete Article 

Design-reuse.com: Basics of Assertion IP

The purpose of this article is to provide some basic information about Assertion IP to people who don’t have much information about it.

As per the name, AIP is having assertions written at interface level.

Mostly, AIP is written following strict design coding guidelines so that it can be synthesizable.

AIP can be used in Functional simulation environment as an interface monitor similar to transaction level monitor which is used to check interface behavior as per interface protocol. But, mainly it is targeted for Formal environment with Formal tool.

In Formal environment with Formal tool, it is used to generate stimulus to design, perform interface level checks and provide coverage in the Formal environment to verify the design with very less efforts.

Inside AIP

One will found following details in most of the AIP

• Top level module having Inputs and Outputs which is used to connect [or bind] AIP with DUT
• Parameters to customize AIP to work with customized DUT
• Having interface checkerswritten in the form of properties
• Assert / Assume / Cover declarations of the properties
• Glue logic to help writing complex protocol check conditions in the properties

Bind

Bind will be used to connect AIP with DUT without creating separate test bench module or without editing design code.

One can create separate bind file and using bind keyword, AIP can be connected to DUT.

One can use internal signals and parameters of top level DUT module during binding. Binding AIP with DUT using bind keyword is something like one is creating instance of AIP module inside top level DUT module.

Glue logic

Main purpose of the AIP is to run it with Formal tool in Formal environment. So, AIP should be written in such a way that it will be Formal tool friendly and fully synthesizable. There are various coding guidelines to code AIP to make it formal tool friendly. Those details are out of scope for this article.

Glue logic is required in AIP to avoid writing very complex conditions in the properties. Formal tool will find it very hard to converge on properties if they involve very complex conditions. So, one need to write separate glue logic which can take care of complex condition of the property and code in the property will get simplified.

Assert, Assume and Cover

People familiar with SystemVerilog assertions will be mostly aware of assert, assume and cover declarations of the properties.

AIP will be having various properties to perform protocol checks on given interface.

Then, those properties will be declared as “assert” so that it can indicate adherence or violation of the protocol condition in either formal or simulation environment. In Formal environment, one can look at property falsification and in simulation environment, one can look at failing message in the log.

Read Complete Article Here