Track c-High speed transaction-based hw-sw coverification -eve
23
May 4, 2011 1 High Speed Transaction-based HW-SW Coverification May 4, 2011 Laureano Felipe Carrasco Costilla
Transcript of Track c-High speed transaction-based hw-sw coverification -eve
May 4, 2011 1
High Speed Transaction-basedHW-SW Coverification
May 4, 2011
Laureano Felipe Carrasco Costilla
May 4, 2011 2
Traditional Emulator Deployment:In-Circuit Emulation (ICE)
Target System
Cables
The design binary is downloaded
into the emulator
The emulator, connected to a physical target system in place of a yet-to-be-
built chip, either drives the target system or is driven by the target
system
PCIe Interface
The RTL design is compiled in a
workstation into a binary object
process(clk)Begin
if rising_edge(clk) thenQ <= not Q;
end if;end process ;
Emulator
May 4, 2011 3
ICE: Pros and ConsFeature Pros Cons
Ease of Setup
• No need create testbenches; stimulus provided by real hardware
• Requires design, manufacture, and debug/maintenance of hardware adapters for each interface
Performance • Can run at maximum speed of emulation; Not limited by test environment
• Emulator is not synchronized with target hardware, requires speed-rate adapters (FIFOs); buffering may cause loss of test accuracy
Flexibility & Scalability
• Connect to different hardware for different system configurations
• Run different application software for different tests
• New configurations require new hardware; cannot be changed/added remotely without on-site help
Verification Coverage &
Debug
• Validate design using real-world stimulus; software applications
• Emulator is not synchronized with target hardware
• Non-deterministic behavior compromises and prolongs design debug
• Cannot slow-down the real-world HW; Debugging can only occur at-speed, and dependent on logic analyzer-style debug
• Not suitable for HW verification; limited interactive debug capabilities
May 4, 2011 4
Traditional Emulator Deployment:Cycle-based coverification
The design binary is downloaded
into the emulator
PCIe Interface
The RTL design is compiled in a
workstation into a binary object
process(clk)Begin
if rising_edge(clk) thenQ <= not Q;
end if;end process ;
The emulator is driven by the cycle-based
Verilog/VHDL/C/C++ testbench
Cycle-Based
Time
Test Bench
Communication Overhead
Emulated DUT
Emulator
May 4, 2011 5
Cycle-based coverification pros/cons
Feature Pros Cons
Ease of Setup
• Re-use Verilog/VHDL testbenches from hardware verification • None
Performance • Time spent in design -> 0• Order of magnitude over pure simulation
• Performance limited by testbench; typically 20-50kHz
Flexibility & Scalability
• Simple to compile/run new Verilog testbenches, random seeds
• New system configurations require simple instantiation
• None
Verification Coverage &
Debug
• Easy to dump waveforms, perform interactive debug – simulator is the master
• Well-suited for HW verification• Unable to validate real-world stimulus or
develop software, too slow
May 4, 2011 6
Transaction-based coverification
Cycle-Based
Time
Test Bench
Communication Overhead
Emulated DUT
Transaction-Based
Time
Test Bench
Communication Overhead
Emulated DUT
• Testbench and Emulated DUT are synchronized only when required– Test bench and DUT can run in parallel and transactions can be queued– The speed improvement over cycle-based can be orders of magnitude faster reaching tens of MHz
May 4, 2011 7
What is a transactor:Conceptual design
HDL Simulator
Cycle-Level Communication
EmulatorPC
HDLDUTFront-end
C++/SC/SVModel
Bit-level Protocol Hi-level Commands
TX
RX
CommunicationInfrastructure
Back-endVerilog BFM
Model
Transactor
HDLTestbenchC++/SC/SVTestbench
Front-end
• C++ (SC/SV) model to send/receive high-level commands (transactions) to/from Testbench
• Not compute intensive
Back-end
• BFM model to convert high-level commands into bit-level protocol
• Compute intensive
May 4, 2011 8
Example: Video-in transactorEmulator
VerilogTestbench
FrameGenerator
DUT
pixel_clkv_sync
pixel
h_syncVideo
ProcessorVideo Frame Video_In
Transactor
C++Testbench
FrameGenerator
ONE FRAME
pixel_clk
v_sync
h_sync
pixel 1st row pixels 2nd row pixels Nth row pixels
May 4, 2011 9
Natural integration withVirtual Platforms
System-on-Chip
CPU(s)Instruction
Set Simulator
SystemI/O
RTLDevice
MemoryControlMemory
SystemI/O
Device
ESL Virtual Platform
Cycle/BitAccurate RTL
TransactionLevel
Emulator
Peripheral
Peripheral
TLM
Bus
TLM 2.0 Transactor
May 4, 2011 10
Creating a transactor: Acellera’s SCE-MI 2.0
SCE-MI 2.0 defines three types of HW/SW communication• Macro-based interface (SCE-MI 1 compatibility)
• Function-based interface (Limited subset of the SystemVerilog DPI)• SystemVerilog compatible, transactors can be simulated
• Only functions are allowed (no import/export tasks), each function call is a transaction
• Pipe-base interface (fixed functions)• Transactions go through unidirectional pipes
• Data is not guaranteed to be available to the consumer immediately
• User has to map data to messages and insure response
• Not 100% SystemVerilog compatible
SCE-MI 2.0 is not optimized for performance• Each call in SCE-MI generates a HW/SW synchronization point
• No DPI-based streaming or parallel communication
• It does not leverage emulator-specific performance improvements
May 4, 2011 11
Creating a transactor: ZEMI-3ZEMI-3 is EVE’s behavioral SystemVerilog compiler that:
• generates RTL BFMs for the HW portion of the transactor
• Creates DPI-based low-level communication layer between HW and SW
Easy creation High performance
• Accepts a large set of behavioral constructs (implicit state machines, wait states, mixed clock edges etc.)
• Automatic detection of streaming, pre-fetching support
• Supports DPI functions and tasks (including time consuming export tasks) • Optimization for latency, area or throughput
• Possible to debug with any SystemVerilog simulator prior to emulation
• Leverages ZeBu emulator architecture to send transactions in parallel
May 4, 2011 12
Transactor exampleA transactor to write and read from a virtual memory implemented in the PC
Cycle-Level Communication
EmulatorPC
HDLDUTFront-end
C++ Model
CommunicationInfrastructure
Back-endSV BFMModel
Memory Transactor
HDLTestbench
VirtualMemory
Mem_dout
Mem_din
Mem_addr
Mem_re
Mem_we
read
Write
May 4, 2011 13
The virtual memory:Memory32.cc
#include "Memory32.hh"#include <stdio.h>#include <string.h>
Memory32::Memory32(unsigned int depth){
_ memArray = new unsigned int [depth]; memset(_memArray, 0, depth*sizeof(unsigned int));
}
Memory32::~Memory32)({
delete [] _memArray;}
unsigned int Memory32::read(const unsigned int addr){
return _memArray[addr];}
void Memory32::write(const unsigned int addr, const unsigned int din){
_ memArray[addr] = din;}
May 4, 2011 14
The transactor’s front-end: mem_xtor.cc#include <stdlib.h>#include <stdio.h>
#include <mem_xtor.h>#include "Memory32.hh"
extern "C" void readData(const svBitVecVal addr[1], svBitVecVal dout[1]){
svScope s = svGetScope;)( Memory32 *mem = (Memory32 *)(svGetUserData(s, (void *)(readData)));
dout[0] = mem->read(addr[0]); printf("# Read Data addr=%d, dout=%x\n", addr[0], dout[0]);
}
extern "C" void writeData(const svBitVecVal addr[1], const svBitVecVal din[1]){
printf("# Write Data addr=%d, din=%x\n", addr[0], din[0]); svScope s = svGetScope;)(
Memory32 *mem = (Memory32 *)(svGetUserData(s, (void *)(writeData))); mem->write(addr[0], din[0]);
}…
…extern "C" void initialize)(
{ printf("# Initializing SW part of the transactor\n");
svScope s = svGetScope;)( Memory32 *newMem = new Memory32(MEM_DEPTH);
svPutUserData(s, (void *)(read), (void *)(newMem)); svPutUserData(s, (void *)(write), (void *)(newMem));
printf("# Init done\n");}
May 4, 2011 15
The transactor’s back-endmodule mem_xtor(input clk, input [15:0] addr, input [31:0] din, input ce, input we, input re, output reg [31:0] dout)
import "DPI-C" context function void readData(input bit [15:0] addr, output bit [31:0] dout); import "DPI-C" context function void writeData(input bit [15:0] addr, input bit [31:0] din) ;
import "DPI-C" context function void initialize;)(
initial begin dout = 0;
initialize;)( end
always @(posedge clk) begin
if (we) begin writeData(addr, din);
if (re) dout = din; end else
if (re) readData(addr, dout); end
endmodule
May 4, 2011 16
Not all has to be written!EVE’s Transactors portfolio
• Large (Sparse) SRAM Memory • RS232 (UART)• Keypad• Input/Output Stream • LCD RGB TFT Display• Digital Video / YUV/656/420 Display• I2S Digital Audio (Master, Slave)• JTAG (XtensaTensilica, ARC SeeCode)• JTAG TAP Controller• 10/100/1G ETHERNET MII/GMII• PCI Express Gen1/2 1,4,8,16 lanes• MMC/SD Card (Host, Device)
• FireWire (Isochronous only)• Digital Video Input stream ( YUV,656,DVB)• USB 2.0 (Host, Device) • AHB Master• AXI Transactor (Master, Slave)• I2C (Master, Slave)• Ethernet Transactor SW bridge• HDMI Sink ( Video Only)• Coware Platform Architect ZeBu Adapter• ETHERNET LAN Controller• PCI Express Gen2, 4VC, 1, 4, 8, 16 lanes
Very rich and increasing portfolio of transactors and verification IP
May 4, 2011 17
Using a transactor
Xtor Doc
Xtor Doc
…i2c_driver i2c_xtor( .sda(sda1), .scl(scl1), .sda_oe(sda_oe1), .scl_oe(scl_oe1));defparam i2c_xtor1.cclock="i2c_clk";defparam i2c_xtor1.debug = "yes";…
Design Verification Environment
int main (int argc, char *argv[]) { Board* board = 0; I2c* i2c_interface = 0; ... try { board = Board::open(ZWORK); fflush(stdout);fflush(stderr); ... i2c_interface = new I2c; ... while(!i2c_interface->runBFM(RunUntilTrnSent));...
Testbench.cc
May 4, 2011 18
Case study: ICE wireless platformEmulator @ few hundreds of kHz
DUT
LCD DisplayInterface
TerminalInterface
Digital Still CameraInterface
KeypadInterface
USB 2.0Interface
Ethernet10/100Interface
I2S AudioInterface
JTAGInterface
Flash MemoryInterface
ARM11Core
DSPCore
Logic
DDR MemoryInterface
NTSC TVInterface
FrameGrabber
FrameGrabber
FrameCapture
HWBridge
HWBridge
Ethernet
HWCODEC
Memory
LauterbachPod
May 4, 2011 19
EVE’s ZeBu emulator @ 5MHz
RTB
PC – Software Test Environment
NTSC XTOR
DUT
LCD DisplayInterface
TerminalInterface
Digital Still CameraInterface
KeypadInterface
USB 2.0Interface
Ethernet 10/100Interface
I2S AudioInterface
JTAGInterface
Flash MemoryInterface
LCD XTOR
Terminal XTOR
DSC XTOR
Keypad XTOR
USB FunctionXTOR
Ethernet XTORBridge
I2S XTOR
JTAG XTOR
SynthesizableFlash Memory
DDR MemoryInterface
NTSC TVInterface
DisplayWindow
DisplayWindow
ImageFiles
ARM11Core
DSPCore
Logic
MemoryNICCard
SWCODEC
HDDC Model
Ethernet
SynthesizableDDR Memory
Case study: transaction-based
May 4, 2011 20
TSC2101 - SPI
Main
Battery Gauge - HDQ
GPIO
RTC – I2C
Keypad - GPIO
LCD - Display
TV - Display
TCM8002MD – CCP Camera
Terminal - UART
GPIO Expander
SW Debug
Case study: PC sample display
May 4, 2011 21
Case study: results
Able to boot Symbian OS in 45 secondsAllowed starting of early software development and HW/SW coverification
• No timing limitations in a complex clocking scenario
• No additional power supply, level shifting, memory hardware mapping, hard reset etc.
• No hardware induced frequency limitations
• Only a single Linux PC required for SW side• All interfaces are virtual and displayed in the PC• Full remote access
• Software debugging tool running on the PC• Disassembly Core instructions
• Full access to the design running on the emulator (probing, regs and memory etc.)
• Advanced debugging capabilities (Save and restore, Stop/dump on trigger, SVA etc.)
May 4, 2011 22
Transaction based coverificationFeature Pros Cons
Ease of Setup
• Create transactors in RTL; debug in simulation
• Can re-use transaction-level HVL testbenches and ESL virtual platforms; if available
• Transactors need to be created, debugged; may require protocol expertise
• May need to create test environment for SW development
Performance • Can run at maximum speed of emulation
• Performance dependant on transactor bandwidth and amount of parallelization between emulator and testbench
• Still testbench limited; may need to modify/create testbenches for high performance
Flexibility & Scalability
• Simple to compile/run new Verilog testbenches, random seeds
• New system configurations require simple instantiation
• None
Verification Coverage &
Debug
• Transactors can operate in synchronous and asynchronous modes
• Full use of at-speed and interactive debug capabilities
• Usable for both HW verification & SW development
• None
Verification IP, ZEMI-3 &ESL Tools
May 4, 2011 23
Thank you!
