1. Easy Steps Towards Virtual Prototyping using the SystemVerilog DPIby
Dave Rich
Verification Architect
Mentor Graphics

2. 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

3. 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

4. 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

5. 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

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

7. 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

8. Levels of Abstraction

9. 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.

10. 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?

11. 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

12. 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

13. 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

14. 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 join_any disable fork; actualCycles = i; iRequested = IRQ; endtask
One of many ways to represent an interrupt

15. 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

16. MASTER to MASTER Communication

17. 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

18. 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

19. 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

20. 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)