Easy Steps Towards Virtual Prototyping using the SystemVerilog DPI by Dave Rich Verification Architect Mentor Graphics

Overview The world loves two kingdoms Hardware you can touch Software is what most people see Not very many people understand both concepts well enough for verification Finding clip art for software

Objectives Provide a verification environment for hardware and software as a system Early hardware access from software Preserve debugging environments for both sides Provide most optimal abstraction levels for performance Do not duplicate hardware/software component verification

external bus interface Typical SOC Design Software in Memory Embedded Core ARM core/CPU on-chip RAM or ROM test i/f ctrl external bus interface Bus Fabric AHB External Devices DMA controller bridge UART timer parallel i/f APB other master/slave devices Internal Devices

Virtual Prototype Backplane CPU or native code RAM Direct Memory References Memory Mapped References External bus interface Memory Map UART timer parallel i/f other master/slave devices Virtual Backplane

Block-Level Verification Environment UART timer parallel i/f USB VIP APB VIP APB Processor is irrelevant

Mixed Software/Hardware Simulation Memory Mapped References external bus interface Virtual CPU or native code Virtual Bus handler Direct Memory References RAM Bus agent UART timer parallel i/f Virtual backplane routes traffic APB

Levels of Abstraction

Abstraction Levels of Accuracy Untimed (UT) – limited or unspecified timing accuracy. At this level, only ordering of operations matters and there may be no bookkeeping of elapsed simulated time. Loosely-timed (LT) – time is broken into slices or some quantum unit. An SoC virtual platform is likely to choose the execution of an instruction as its quantum time unit. Approximately-timed (AT) – Quantum units are broken down into phases and the tracking of elapsed simulated time is enough to gather relative performance statistics. Cycle-accurate/cycle-callable (CC) Timing is accurate enough to run in lock-step to match the hardware models at a pin-level, clock or bus-cycle boundaries.

Partitioning Choices Wide range of abstraction choices for software models Hardware tends to limit to what is synthesizable What components can be black-box verified?

Software to Hardware DPI link void C_routine() { if (address==0xFFA) { APB_read(address,&data); } else { data = MemRead[address]; } APB_write(address,data+1); Pin-level transactions task APB_read(input int address, output int data); @(posedge clock) bus <= address; cmd <= read; cmd <= ack; data = bus; endtask   export “DPI-C” task APB_read; export “DPI-C” task APB_write; function call transactions

Compressed Hardware Simulation Timing APB_read op1 op2 APB_write MemRead op3 op4 … op1001 MemWrite op1002 op1003   Read Write Read Read Write Write Read Simulation time

Approximated Hardware Simulation Timing task APB_idle(input int cycles); repeat (cycles) @(posedge clock); endtask   APB_read op1 op2 APB_write MemRead op3 APB_idle(3); op4 … op1004 APB_idle(50) APB_read;   Read Write idle Read Do I really need 1000 cycles? Write idle Read

One of many ways to represent an interrupt Interrupt Monitor task APB_idle( input int requestedCycles, output int iRequested, output int actualCycles); int i; fork for(i=0;i<requestedCycles;i++) @(posedge clock); @(IRQ!=0); join_any disable fork; actualCycles = i; iRequested = IRQ; endtask One of many ways to represent an interrupt

Transaction Specification Field Type Description Operation Enum Read, write,idle,burst Address 32-bit Physical starting address ReqStart Time Time of Request ReqDuration Time allocated for operation TrStart Actual start time TrEnd Actual end time InterruptMode Ignore, Complete, Abort InterruptReq None,Requested InterruptTime Time of Interrupt Length Int Size of data Payload nBytes Transaction data

MASTER to MASTER Communication

Starting A C Thread int c_code() { /* C task */ while(1) { /* C thread */ v_code(args); ... } }   module top; import “DPI-C” task c_code(); initial c_code; // start C thread bit clk; always #10 clk++; export “DPI-C” task v_code; task v_code(args); addr <= args; @(posedge clk); args = result; endtask endmodule  

Inter-process Communication Software Master Hardware Client C Thread System Verilog Threads Virtual Prototype Threads Initiate Socket Connect to Socket Single bus transaction   Software Bus Model Wait for message DPI Communication Send message IPC Communication Send transaction Wait for response Wait for message Send message

UVM Testbench Re-Use IPC Bus Model channel Virtual Prototype UVM Test DPI C Thread UVM Test   regA.read() regA.write() DUT Register Model Bus Agent Sequence

Summary This methodology has been deployed with a number commercially and internally developed virtual prototypes It turns out this technique can be used for a wide range of applications where non-SystemVerilog stimulus is needed Any C code needs to be the master Python/Perl Testbench (For legacy, of course)