Portable Stimulus: What's Coming in 1.1
Total Page:16
File Type:pdf, Size:1020Kb
Portable Stimulus: What’s Coming in 1.1 and What it Means For You Portable Stimulus Working Group PSS 1.1 Tutorial Agenda • What is PSS Introduction • Tom Fitzpatrick, • Abstract DMA model in PSS 1.0 Mentor, a Siemens Business Memory • The problem • Prabhat Gupta, AMD Allocation • New PSS concepts Higher-Level • The problem • Matan Vax, Scenarios • New constructs Cadence Design Systems • The problem • Karthick Gururaj, HSI Realization • New concepts and constructs Vayavya Labs System-Level • Portability • Hillel Miller, Synopsys Usage • Complex scenarios • Summary Special Thanks to: Conclusion • What’s next Dave Kelf, Breker Verification Systems Josh Rensch, Semifore 2 The Need for Verification Abstraction Test content authoring represents major proportion of development SIMULATION Disconnected cross-process methods Test Content • Block EMULATION • UVM tests laborious, error-prone • SoC FPGA PROTO • Hard to hit corner-cases with C tests • Post-Silicon • Disconnected diagnostic creation IP BLOCK SUBSYSTEM FULL SYSTEM Test portability, reuse, scaling, maintenance all problematic 3 Key Aspects of Portable Stimulus Capture pure Partial scenario Composable Formal Automated test Target multiple test intent description scenarios representation generation platforms of test space Separate test intent from implementation High-coverage test generation across the verification process with much less effort 4 PSS Improves Individual Verification Phases IP BLOCK SUB-SYSTEM FULL SYSTEM Create block-level (UVM) tests & Easily model system-level Generate software processor tests sequences based on operations, reuse modular block and IO transactions from common scenario intent level tests scenario model Easily compose complex, Drive hard-to-predict corner-case Flush out system functions with concurrent, high-coverage tests tests to flush out design operation software-driven tests, while avoiding processor complexity 5 PSS Generalized Tool Flow DSL DSL Compiler Gen-time or Run-time Constraint Test Scenario model Solver Solved Model Generator + Constraints C++ Compile / Compile Link / Run Link UVM Transaction Sync C-test Sequences Sequences PSS Abstract AXIAXI VIPVIP TB Scenario AXI CPUVIP Model DMAC DMAC UART UART DDR UART UART DDR VIP MEM VIP MEM UVM Testbench SoC Testbench 6 Active PSWG Participants 7 Key Additions to PSS 1.1 Modeling Improvements • Better Reusable Content Capture • Storage Allocation Test Realization • Register Space Definition • Reusable Abstract Procedural Layer Programming Enhancements • Templates • Collection Types 8 What is a Portable Stimulus Model? The • What does Abstract Model it do The • How does Realization it do what Layer it does 9 The Parts of a PSS Model flow objects describe resources represent actions describe behavior communication chan pieces of the system action b2s_a { dbuf input dbuf din; b2s dstr output dstr dout; rand int in [1..100] size; struct dat_s { rand bit[31:0] addr; constraint din.size == size; rand int size; } lock channel_r chan; } buffer dbuf : dat_s { rand bit[12:0] key; actions may have data fields } actions may have constraints stream dstr : dat_s { actions may claim resources rand bit dir; } 10 Data Flow Objects Imply Scheduling bufo_a activity describes schedule action actdemo_a { dbuf b2s_a b2s; s bufo_a bufo; b2s dstr stri_a stream object buffer objects imply parallel stri_a stri; imply sequential activity { struct dat_s { bufo; rand bit[31:0] addr; parallel { rand int size; b2s; } stri; } buffer dbuf : dat_s { bind bufo.dout b2s.din; rand bit[12:0] key; bind b2s.dout stri.din; } } } stream dstr : dat_s { rand bit dir; constraints on bufo.dout } apply to b2s.din 11 Activities Can Define Flexible Scenarios bufo b2s s2b b2b action sched_a { bufo_a bufo; s2b_a s2b; ax_a ax; b2s_a b2s; b2b_a b2b; my_a a1,a2; b2a activity { Directed-Random bufo; select { a1 a2 Scenario parallel { b2s; s2b; } a1 a2 b2b; a2 a1 } b2a; schedule { a1; a2; } ax ax; 123456 distinct control paths } } 12 Activities Can Define Flexible Scenarios bufo dbuf dbuf dstr b2s s2b b2b action sched_a { dbuf dbuf bufo_a bufo; s2b_a s2b; ax_a ax; b2s_a b2s; b2b_a b2b; my_a a1,a2; b2a activity { db2 db2 bufo; select { a1 a2 Explicit binding parallel { b2s; s2b; } db2 a1 a2 db2 gets complicated b2b; a2 a1 } b2a; db2 db2 schedule { a1; a2; } ax ax; } } 13 Flow Objects Managed via Pools bufo pool dbuf dbpool_p; bind dbpool_p *; pool db2 dbp2_p; dbpool bind dbp2_p *; dbufdbufdbuf dstr b2s s2b b2b action sched_a { bufo_a bufo; s2b_a s2b; ax_a ax; b2s_a b2s; b2b_a b2b; my_a a1,a2; b2a dbp2 activity { db2 db2db2 bufo; select { a1 a2 parallel { b2s; s2b; } a1 a2 b2b; a2 a1 } b2a; schedule { a1; a2; } ax ax; } } 14 Resources Add Dependencies pool [NUM] chan_r chan_p; bind chan_p *; Each resource in a Resources may be pool is unique action sched_a { locked or shared ... chan_p activity { schedule { a1; a2; } resource chan_r : base_r { chan ax; ... } } } action a1_a { a1 a2 ... a1 a2 lock chan_r chan; a2 a1 } action a2_a { Can't run in parallel ax ... if both require the lock chan_r chan; same resource } 15 Components Group Model Elements component pss_top { Default top-level name comp1_c c1; comp2_c c2; pool [NUM] chan_r chan_p; pss_top bind chan_p *; pool dbuf dbuf_p; bind dbuf_p *; comp1_c comp2_c chan_p Pool binding is pool db2 db2_p; bufo chan hierarchical bind db2_p *; b2s } b2b a1 dbpool dbp2 dbufdbuf db2 s2b a2 dbufdbuf db2db2 component comp2_c { my_a a1, a2; b2a ax ax_a ax; activity { ... Components can instantiate } subcomponents } 16 So What's the Point? Activity defines critical behaviors • May define partial specification • Tools will infer additional elements to complete the scenario Other parts of the model define how behaviors interact • Instantiated components define available actions • Flow object bindings constrain inference choices • Resources constrain scheduling options 17 component pss_top { Quick DMA Example dma_c dma; util_c util; pool dbuf dbuf_p; bind dbuf_p *; action m2mtest_a { activity { do dma_c::mem2mem_xfer; do util_c::check_data; pss_top } util_c dma_c m2mtest } } chan_p component dma_c { gen chan resource channel_r {}; dbuf_p pool [NUM] channel_r chan_pool; dbufdbufdbuf bind chan_pool *; check m2m action mem2mem_xfer { input data_buff src_buff; output data_buff dst_buff; ... lock channel_r chan; } } 18 component pss_top { Quick DMA Example dma_c dma; util_c util; dbuf pool dbuf dbuf_p; bind dbuf_p *; gen m2m action m2mtest_a { activity { dbuf dbuf do dma_c::mem2mem_xfer; gen m2m do util_c::check_data; } } } gen m2m dbuf_p m2m dbufdbufdbuf check 19 Quick DMA Example dbuf gen m2m dbuf dbuf gen m2m gen m2m gen m2m gen m2m PSS 1.1 Provides for Memory Allocation Must make sure that m2m m2m data buffers don't overlap in memory check check 20 The Rubber Meets the Road The Abstract Model must be implemented on different targets Atomic Actions → target code • Target code modeled in exec blocks Generator assembles target code according to Activity schedule 21 Target Template Exec Blocks Define SV extend action mem2mem_xfer { implementation exec SV """ begin m2m_xfer xseq = m2m_xfer::type_id::create("xseq"); xseq.item.src == {{src_buff.addr}}; xseq.item.dst == {{dst_buff.addr}}; Define C xseq.item.size == {{size}}; extend action mem2mem_xfer { implementation xseq.start(m_env.m_agent.m_seqr); exec C """ end Pass PSS args SRC_REG.write({{src_buff.addr}}); """ DST_REG.write({{dst_buff.addr}}); } SZ_REG.write({{size}}); CSR_REG.write(GO); """ } 22 Procedural Interface Exec Blocks package func_pkg { function void m2m_xfer(bit[31:0]src, bit[31:0]dst, Single method bit[6:0]size); prototype } extend action mem2mem_xfer { import func_pkg::*; exec body { m2m_xfer(src_buff.addr, dst_buff.addr, size); } } PSS1.1 adds an Must provide implementations abstract procedural layer in both SV and C 23 Thank You Please Continue with Part 2 Thank you to our Accellera Global Sponsors Portable Stimulus: What’s Coming In 1.1 And What It Means For You Part 2: MEMORY ALLOCATION Prabhat Gupta, AMD Memory Allocation Topics Problem Concepts Application Issues with memory allocation Address space Address space operations Address space region Packed struct Allocation claim Descriptor chain Address space handle 2 Portability and Controllability Problem src_addr = mem_mgr.allocate(size, properties); dst_addr = mem_mgr.allocate(size, properties); // Program descriptor in memory // ... // Program IP IP testbench write_reg(CTRL_REG, descriptor) mem_mgr.deallocate(src_addr); Need to manage memory resource mem_mgr.deallocate(dst_addr); HOW TO ESTABLISH INTERESTING RELATIONSHIP WILL TEST RUN OUT OF IS MEMORY MANAGER BETWEEN SOURCE AND MEMORY PORTABLE DESTINATION 3 Portability and Controllability Problem // Manage two different memory manager addr1 = IP1_mem_mgr.allocate(size, properties); addr2 = IP2_mem_mgr.allocate(size, properties); //-------------------- OR ---------------------- // Sub-system // Create unified memory manager Reconcile memory management addr1 = unified_mem_mgr.allocate(size, properties); of different IP addr2 = unified_mem_mgr.allocate(size, properties); ESTABLISH INTERESTING ARE MEM MANAGERS IS MEMORY MANAGER RELATIONSHIP BETWEEN COMPATIBLE? PORTABLE? ADDR1 AND ADDR2 4 Model Allocation – Portability Problem // Processor based tests // hardcode addresses Uint64_t addr = 0x123456; // Simple mem manager at runtime SoC and post-silicon addr = malloc(0x1000); Reuse stimulus that allocate and // How to create test that would hit all memory access memory controller? // IP tests need to be re-written HARDCODE ADDRESS OR IS MEMORY