Open-Silicon.com 490 N. McCarthy Blvd, #220 Milpitas, CA 95035 408 240-5700 HQ
UVM based Automated SoC Interconnect Verification Methodology Ganesh Venkata Venkatakrishnan krishnan Prajakta Rohom C O N F I D E N T I A L
7th November 2014
Traditional SoC Interconnect Verification Methodology
•
–
•
•
Test-Bench
Traditional approach: Standalone development of Test-Bench and Test-Cases for Interconnect verification
Test-Cases
Limitations to this approach : –
Separately maintain a Test-Bench environment for Interconnect
–
Does not take into consideration the final integrated SoC RTL
–
Additional efforts are required at the SoC level to ensure the Connectivity and Integration of the IPs with the Interconnect
Toggle coverage closure for Interconnect signals cannot be achieved at SoC level by only functional Test-Cases at IP level
M1 VIP
M2 VIP
M3 VIP
M4 VIP
Interconnect
S1 VIP
S2 VIP
Traditional SoC Interconnect Test-Bench
Proposed SoC Interconnect Methodology
•
Basically enables the verification of the Interconnect in the Integrated SoC
•
The Verification Setup generation/automation is divided into 2 parts: –
–
Instantiating the Bus VIPs (Master/Slave) inside the top level file of the IP RTL at the Interface connecting to the Interconnect.
Architecture/IP capabilities
Interconnect RTL generation tool
UVM Environment Layer Generation for controlling the Transactions to/from the Bus VIPs.
Custom TEXT input from Spec to generate traffic
SoC Integration Interconnect/IPs UVM layer for VIPs / Test-Cases
SoC File-List DUT config
File-list management Modified File-List New SoC RTL with VIPs connected inside IP top
Configurable functional SoC TB
Simulator
Proposed SoC Interconnect Methodology – Implementation •
The BUS VIP Interfaces are instantiated through an automated process inside the IP RTL top files.
•
The setup must have the following information to enable the automation of replacement of IP by BUS V IP :
•
–
IP block name with block flavor
–
BUS type (AXI/AHB/APB)
–
Interface type ( Master or Slave)
–
Name of clock and reset signals of the BUS Interface
–
BUS signal naming format used in IP top
For the UVM based Test-Bench generation of Interconnect, the same block of code with different configurations repeat in the environment for large number of agents. –
Automation of the UVM layer using a ‘Perl’ script to avoid manual errors and save time
–
In addition, the automation also includes generation of coverage, assertions and necessary Test-Cases too
UVM layer auto generation
•
The ‘Perl’ script takes inputs from a text file which reflects the attributes of the Interconnect Master/Slaves and generates following UVM files: –
UVM Interconnect Environment
–
Basic sequence library
–
Basic M-S access and non-access test-cases
–
System Verilog Functional Coverage
–
System Verilog Assertions
IP
BUS
SA
EA
M/
D
W
R
S
W
I
I
ID
REMAPSA
REMAPEA
ERRSLV
CPU
AXI3
0000_0000
FFFF_FFFF
M
128
1
1
7
0000_0000
FFFF_FFFF
-
CPU
-
0000_0000
FFFF_FFFF
M
128
1
1
7
0000_0000
FFFF_FFFF
BOOTAM
CPU
-
0000_0000
FFFF_FFFF
M
128
1
1
7
0000_0000
FFFF_FFFF
UART0
DMA
AXI3
0000_0000
FFFF_FFFF
M
64
1
1
5
0000_0000
FFFF_FFFF
-
DMA
-
0000_0000
FFFF_FFFF
M
64
1
1
5
0000_0000
FFFF_FFFF
BOOTBM
DRAM0
AXI3
0000_4000
3FFF_FFFF
S
64
1
1
15
0000_0000
3FFF_FFFF
UART0
APB3
FFF1_D000
FFF1_DFFF
S
32
0
0
0
FFF1_D000
FFF1_DFFF
UART1
APB3
FFF1_E000
FFF1_EFFF
S
32
0
0
0
FFF1_E000
FFF1_EFFF
BOOTAM
AXI3
0000_0000
0000_3FFF
S
64
0
0
0
0000_0000
0000_0000
BOOTBM
AXI3
FFFF_0000
FFFF_3FFF
S
64
0
0
0
0000_0000
0000_0000
RSVD1
-
FFF1_0000
FFF1_3FFF
-
-
-
-
-
FFF1_0000
FFF1_3FFF
DMC Performance measurement using the proposed SoC Interconnect Verification Methodology •
The proposed Methodology allows user to configure the DUT to pick the actual RTL File for any IP or the VIP instantiated top File of the IP on the go.
•
This can be extended to do a DMC performance analysis. –
This can be achieved by choosing a DUT config uration that picks DMC as r‘ tl_top’ flavor while all the IP Masters can be chosen to be in their ‘vip_top’ flavor.
–
Performance monitors can be instantiated at the interface level of the IP Masters and DMC.
–
The sequences generated from each master can be bombarded simultaneously to stress test the performance of the DMC.
Issues found in Interconnect/SoC
•
Some of the issues that have been identified and resolved are: –
Address Maps specified in MAS not matching the RTL implementation
–
A few Slave/Master ports not implemented in the Interconnect which otherwise are caught only when the IP is verified for functionality.
–
ID width Mismatches
–
Width Mismatches of certain AMBA protocol signals between the Master-Interconnect-Slave
–
Clock/Reset signal not driven
–
Outstanding issuing and accepting capability of Interconnect not defined correctly
–
Latency issues with a few slaves (DMC) that adversely affect performance.
• Note : The proposed Methodology was proven on a SoC with multi-level Interconnect architecture. The SoC had close to 50 AMBA Masters and close to 80 AMBA Slaves
Conclusion
•
The proposed Methodology ensured that the Specification and the final RTL of the Interconnect are coherent.
•
The Interconnect verification environment using a single ‘Perl’ script – –
Saves a lot of t ime in the verification cycle Only manual effort needed is for input text file creation as per the project specifications
THANK YOU
[email protected] [email protected]
