CPAN.org: Perl GUI Builder
Design-reuse.com: 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.
Read Complete Article
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.
Read Complete 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.
No comments:
Post a Comment