Unified Simulation/Prototyping Environment on Synopsys CHIPit Platform
Weidong Liuweidong.liu@tridentmicro.com
Trident, Inc.
Abstract
This paper presents one successful methodology for IP verification, which is based on Synopsys CHIPit prototyping platform. In this platform, direct UMRBUS access mode is used to communicate between the host and the FPGA platform. Less effort is necessary to transfer from regular SystemVerilog+C verification in simulator to this efficient methodology, the detailed transfer is described in this article. With this new hardware-assistant methodology, unified verification environment can be achieved compared to regular simulation, and this will efficiently accelerates the achievement of the development goals.
Key words: methodology, verification, CHIPit, UMRBUS, FPGA, prototyping, simulation
1. Introduction
As short life cycle of consumer IC and huge cost of sub- deep micro process tape out, first time right is big challenge but have to achieve target for our products. We always meet tradeoff scenario between completion of test sets and schedule pressure, In order to achieve quick case running time, FPGA prototyping based on CHIPit Platinum is chosen. As we already have mature simulation environment, this paper introduces the solution for platform migration with limited efforts.
2. IP Simulation Environment
2.1 IP Overview
The simulation environment is built on IP called TSA_FTS. The primary purpose of the TSA_FTS is to receive, descramble and de-multiplex multiple MPEG2 Transport Streams. Streams can be fed externally over TS interfaces or sourced internally via system memory from devices such as Hard Disk or network. The TSA_FTS interacts with various conditional access systems to assist with scrambling/descrambling. After data processing, the result could be sent out to either TS interfaces or system memory.
Although the gate count for TSA_FTS is not huge, TSA_ FTS does have 32bit Trident internal developed CPU which runs embedded software for plenty of application, DDR Memory access bus structure, high speed data ports which exchange stream with internal/external IP or chips. It is fully match so-called “SOC” system and would be good reference design for Trident TV/STB SOC verification/prototyping methodology development in later phase.
2.2 IP Simulation Environment Overview
In order to accomplish the verification goal of TSA_FTS, a SystemVerilog+C based verification environment has been developed with the support of different verification components. The test bench modules are developed in SystemVerilog. The PROVE including test plans and associated APIs are developed in C. It hooked up with Host Processor with the assistance of DPI interfaces.
PROVE+Host Processor will be emulated as the main CPU processing in the final SOC design and talk to DUT as well as verification component by MMIO initiators.
The DPIs in Host Processor are used to implement command FIFO and status FIFO, and these two FIFOs are used to interface with external PROVE process. The command FIFO is used to accept read/write commands, and the status FIFO is used to return read data.
Figure 1 TSA_FTS Simulation Environment Overview
2.3 PROVE Introduction
The PROVE main C function calls the test_case() from different test case directory. Test case entry function test_ case() calls common API functions which are wrappers for certain verification tasks.
API functions call read/write functions rd()/wr(). Then, rd()/wr() will call prove_rd()/prove_wr() functions. prove_rd()/prove_wr() provide basic function to interchange data with DPIs in Host Processor via command FIFO and status FIFO files.
See figure 5 define PROVE path for reference
2.3.1 Execute Prove in Simulator
After compile all C source files into the executable file prove_ exec, PROVE process is initiated from test bench and it will be launched after TB environment ready by following simple process:
always@(posedge launch) begin
$swrite(commandName, “prove_exec”);
$display(”Command is \”%s\”", commandName);
$system(commandName);
end
3. FPGA Environment Development
3.1 CHIPit Platform and UMRBus Quick Overview
The CHIPit Platinum Edition System is a high-capacity, high- speed emulation and rapid prototyping system for ASIC designs. Based on the different complexity requirement, it supports 3, 6, 9, 12, 15 or 18 user FPGAs of Xilinx Virtex- II and/or Virtex-4 and/or Virtex-5 families, Not only the good scale ability, plentiful software sets have been supported for prototyping engineers for easy implementation (CHIPit Manager, CHIPit Manager Pro), automatic partition (certify) and strong debug (HDL Bridge, Visibility tool, Host Controlled Debug tool, identify etc).
The UMRbus Communication system is well-defined interface for physical data transfer between the host (PC, Workstation) and a dedicated hardware (FPGA, ASIC). Almost all Synopsys FPGA prototyping platforms including CHIP and HAPS serials support UMRBus, Both C/C++ and TCL Software API provided for UMRBus access.
3.2 FPGA Development Idea
In order to take advantages of existing test environment, current SystemVerilog+C based verification environment has been adopted into the FPGA environment. Obviously DPI connection via FIFO between Host C and DUT is not applicable in FPGA environment. UMRBus is used for communication between Host and DUT. Corresponding IP modification and flow extension for UMRBus connection and FPGA connection is required.
Figure 1 TSA_FTS Simulation Environment Overview
3.3 Key IPs Adoption
Several IPs need to be developed in order to communicate between Host and IPs including MMIO access, memory access and IP interrupt response. Corresponding IPs UMR2MMIO, MMIO2MMBD and UMR2INT have been developed to fulfill above functionality. MMIO is main access protocol in verification environment, so UMR2MMIO IP architecture will be introduced as typical example for concept understanding. MTL2SSRAM for on board SSRAM usage will be introduced as well.
3.3.1 UMR2MMIO
UMR2MMIO IP takes the responsibility on transferring UMRBus protocol to MMIO, As Figure shows, 2 CAPIMs have been used in this IP, CAPIM1 is responsible on command acceptance and interrupt response. CAPIM2 is responsible on data exchange between Host and IPs.
Figure 2 UMR2MMIO Architecture
3.3.2 MTL2SSRAM
As our IP requires big memory usage for TS storage, CHIPit Platinum on board SSRAM has been used. MTL2SSRAM IP has been designed for protocol transfer between MTL (Trident internal memory access bus) and SSRAM interface protocol, As Synopsys provide multiple kinds of memory daughter board which is easy to connect to CHIPit system. Memory extension is out of problem, in case the on-board memory is not enough.
3.4 Host C Adoption
The majority of C codes for verification environment could be reused for CHIPit FPGA prototyping. The only modification is that prove_wr()/prove_rd() function would be replaced by umrbus_wr()/umrbus_rd() for DUT access via UMRbus API.
3.4.1 Write Register by umrbus_wr()
With the assistance of API provided by UMRBus driver and UMR2MMIO, umrbus_wr() will implement register writing function to DUT. It defines asvoid umrbus_wr(unsigned int addr, unsigned int data)and main sequences are:
1. Send write command to CAPIM1 -> umrbus_write(CAPIM1_HANDLE, &ctrl, 1, &errormessage)
2. Send write address to CAPIM2 -> umrbus_write(CAPIM2_HANDLE, &addr, 1, &errormessage)
3. Send write data to CAPIM2 -> umrbus_write(CAPIM2_HANDLE, &data, 1, &errormessage)
4. Wait write done interrupt from UMR2MMIO -> umrbus_interrupt(CAPIM1_HANDLE, &interrupt, &errormessage)
3.4.2 Read Register by umrbus_rd()
Similar as umrbus_wr(), It defines as unsigned int umrbus_rd(unsigned int addr) and sequences are:
1. Send read command to CAPIM1 -> umrbus_write(CAPIM1_HANDLE, &ctrl, 1, &errormessage)
2. Send read address to CAPIM2 umrbus_write(CAPIM2_HANDLE, &addr, 1, &errormessage)
3. Wait read done interrupt from UMR2MMIO -> umrbus_interrupt(CAPIM1_HANDLE, &interrupt, &errormessage)
4. Read data from CAPIM2 -> umrbus_read(CAPIM2_HANDLE, &results, 1, &errormessage)
3.5 UMRBus PLI Connection between C and Simulator
As several IPs and Host have added/replaced into original simulation environment, debugging capability in Simulator is very important for end users to find out potential bugs in early phase. Luckily Synopsys CHIPit platform provides such simulation environment.
Instead of communicate between UMRbus API and HIM, The UMRBus library for the UMRBus PLI Interface provides connection between the C language application and the UMRBus PLI Interface Server. It provides the normal UMRBus API to the application, but no hardware is needed.
Figure 3 General simulation set-up when using the UMRBus PLI Interface
3.6 FPGA Environment Architecture
After Host and IP modification, the detailed FPGA block-level diagram is shown on Figure 4, the non-synthesizable blocks have been replaced and majority blocks are just same as verification environment.
Figure 4 TSA_FTS FPGA Prototyping Environment Overview
3.7 Execution Flow
Based on above architecture and development idea, running wrapper could be created for every engineer switch between normal simulation environment, FPGA simulation environment and FPGA prototyping environment. All log files in different platform are exactly same and differences between different platforms are running time and debug ability.
• Original simulation
RUN –C -> creates file list, compiles test bench module and DUT
RUN –G -> compile PROVE C program, and runs simulation
• FPGA simulation
RUN –C –mode fpga_sim -> creates file list, compiles test bench module, DUT and related FPGA IPs
RUN –G –mode fpga_sim -> compile PROVE C program, launch UMRBus PLI server and runs simulation
• FPGA prototyping
RUN –C –mode fpga_pro -> creates file list, launch CHIPit Manager auto-created scripts for FPGA BIN generation by Synplify and P&R (by ISE) tools
RUN –G –mode fpga_pro -> compile PROVE C program, checks PFGA status, downloads FPGA bin files, and runs PROVE on CHIPit system.
4. Environment Extension to Validation
Not only for verification before tape out, same idea is also adopted for validation when chips come back, the only modification is to adopt chip_rd() and chip_wr() API into rd() and wr() function used by PROVE.
Figure 5 PROVE Generation Sequence for Multiple Platforms
5. Conclusions and Recommendations
With unified simulation/prototyping verification platform, the simulator, FPGA and real CHIP become transparent for end users. Only one verification platform need to be kept development and maintenance. Its consistence definitely saves time and efforts which is important for project success.
6. References
[1] Synopsys, Inc. SystemVerilog DPI Workshop
[2] Trident, Inc. TSA FTS IP Verification Specification (v0.14) October 2010.
[3] Trident, Inc.TSA IP FPGA Architecture (v0.1) March 2010.
[4] Synopsys, Inc. CHIPit Manager Pro. Handbook, (v3.4), October 2010.
[5] Synopsys, Inc. CHIPit Platinum Edition. Handbook, (v4.6), October 2010.
[6] Synopsys, Inc. UMRBus Communication System. Handbook, (v3.5), October 2010.
Insight China
-
SNUG
-
White Paper
-
Good Chip Series
