1 / 20

Easy Steps Towards Virtual Prototyping using the SystemVerilog DPI

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

althea
Télécharger la présentation

Easy Steps Towards Virtual Prototyping using the SystemVerilog DPI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Easy Steps Towards Virtual Prototyping using the SystemVerilog DPI by 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 bothconcepts well enough for verification

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

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

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

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

  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; @(posedge clock) 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 APB_read APB_read op4 … op1001 APB_write MemWrite APB_write op1002 op1003 APB_read 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); APB_read APB_write op4 … op1004 APB_idle(50) APB_read; Read Write idle Read Do I really need 1000 cycles? Write idle Read

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

  15. Transaction Specification

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

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

  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)

More Related