200 likes | 687 Views
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
E N D
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 bothconcepts well enough for verification
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
UART APB timer Typical SOC Design parallel i/f 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 other master/slave devices Internal Devices
Memory Mapped References Virtual CPU or native code Virtual Prototype Backplane Direct Memory References RAM External bus interface Memory Map UART timer parallel i/f other master/slave devices Virtual Backplane
UART APB timer Block-Level Verification Environment parallel i/f USB VIP APB VIP Processor is irrelevant
UART timer Mixed Software/Hardware Simulation parallel i/f Memory Mapped References external bus interface Virtual CPU or native code Virtual Bus handler Direct Memory References RAM Bus agent Virtual backplane routes traffic APB
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; @(posedge clock) 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 APB_read APB_read op4 … op1001 APB_write MemWrite APB_write op1002 op1003 APB_read 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); APB_read APB_write op4 … op1004 APB_idle(50) APB_read; Read Write idle Read Do I really need 1000 cycles? Write idle Read
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
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 SystemVerilog Threads Initiate Socket Virtual Prototype Threads Connect to Socket Single bus transaction Software BusModel Wait for message DPI Communication IPC Communication Send message Send transaction Wait for response Wait for message Send message
UVM Testbench Re-Use Virtual Prototype Bus Model IPC channel UVM Test regA.read() regA.write() IPC channel DPI C Thread 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)