Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
INVENTIVEHW-SW Co-VerificationA Constrained Random ApproachSwaminathan Venkatesan(swamiv@cadence.com)Ashwin Menon(ashwinm@...
Trends•  Embedded software complexity continues toincrease•  Quality is becoming more important everywhere–  Patches and u...
Some Co-Verification issues•  Software development needs to be brought forward andideally done in parallel with hardware• ...
Finding High-Value Bugs at the Hardware/Software Boundary•  How do we stress the hw/sw boundary?•  How do we know we thoro...
Metric Driven Verification•  Collect Software Metrics–  Functional Coverage•  Apply Constrained random verification to Sof...
Functional Coverage6
Functional Coverage•  Monitoring software accesses to variables•  Collecting coverage on the software. Coverage is collect...
Functional Coverage (Con’t)8IP 2BUSMemoryBridgeIP 4IP 1IP 3Bridge BridgeDriverRTOSApplicationCPUsnooperSpecman TestbenchEm...
Functional Coverage (Con’t)•  Variable coverage–  Assign local variables to global variables whose address are determinist...
Software Randomization10
Directed vs Metric-Driven Tests11•  Direct pre-ordered tests–  Write test cases manually•  Random constraint tests–  dynam...
12Software Randomization (Con’t)IP 2BUSMemoryBridgeIP 4IP 1IP 3Bridge BridgeDriverRTOSApplicationCPUsnooperSpecman Testben...
13Software Randomization (Con’t)•  Directed Testsw_test() {unsigned long pkt_len = 0x20; // - Fixedenum pkt_t my_pkt = ENE...
Hardware/Software co-debug14
Embedded Software Trace Requirements•  Debug hardware/software corner case issues•  Connects waveform viewer and software ...
Extensions for “software debugger like”featuresAllows waveform position tobe related to software/firmware positionStep for...
Conclusion•  No single person/team understands a complexembedded system•  Each group is using different tools, languages, ...
Conclusion (con‘t)•  Define constraints and checks for each component•  Provide API to use testbench in system context•  C...
Cadence Confidential: Limited to CDNLive! Attendees only19(c) 2006, Cadence Design Systems, Inc. All rights reserved world...
Upcoming SlideShare
Loading in …5
×

HW-SW Co-Verification: A Constrained Random Approach

697 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

HW-SW Co-Verification: A Constrained Random Approach

  1. 1. INVENTIVEHW-SW Co-VerificationA Constrained Random ApproachSwaminathan Venkatesan(swamiv@cadence.com)Ashwin Menon(ashwinm@cadence.com)
  2. 2. Trends•  Embedded software complexity continues toincrease•  Quality is becoming more important everywhere–  Patches and updates take time–  Even though it’s “just software”, time is not free•  Metric-Driven Verification, Validation and Test–  Automated stimulus generation, functional coverage, andchecking might be a solution
  3. 3. Some Co-Verification issues•  Software development needs to be brought forward andideally done in parallel with hardware•  Software and Hardware should be debugged together–  View software alongside hardware•  Writing many directed software tests is :Tedious, Time consuming, Not Scalable•  Hardware and software stimulus should be coordinatedand activity monitored in a unified way to–  Hit cross domain corner cases–  Check data/temporal behaviour across domains
  4. 4. Finding High-Value Bugs at the Hardware/Software Boundary•  How do we stress the hw/sw boundary?•  How do we know we thoroughly stressed it?•  How do we know it behaved correctly?Plogram flow corner casesState based scenariosEtc..Interface corner casesState based scenariosEtc..SW_STATE == init_driver&HW_ABORTMDV MDVWe know how toapply MDV tohardware interfacesHow do weapply MDV tosoftware interfacesMetric Driven Verification
  5. 5. Metric Driven Verification•  Collect Software Metrics–  Functional Coverage•  Apply Constrained random verification to Softwarefunctions•  Perform HW-SW co-debug
  6. 6. Functional Coverage6
  7. 7. Functional Coverage•  Monitoring software accesses to variables•  Collecting coverage on the software. Coverage is collectedon:–  function calls–  function call parameter values–  function call return values–  variable accesses7
  8. 8. Functional Coverage (Con’t)8IP 2BUSMemoryBridgeIP 4IP 1IP 3Bridge BridgeDriverRTOSApplicationCPUsnooperSpecman TestbenchEmbedded Memory ReadEmbeddedfirmware codeand data in SocSRAMEmits event whenever embeddedfirmware accesses C variables of interestin the SoC SRAMFirmwareelfExtract addressof Variables tobe coveredCreate Snooper (hdl)to monitor the addressOn the busCompile and linkHook the snooper toThe bus interfaceCoverage goals
  9. 9. Functional Coverage (Con’t)•  Variable coverage–  Assign local variables to global variables whose address are deterministic// global variable dtypeenum data_type dtype; // PULL, PUSH, ISO, ASYNC_SIMPLEXsw_test() {enum data_type dt_local;set_data_type(dt_local); // API to set the data typedtype = dt_local; // write to global variable};–  Create the snooper that monitors the writes to the global addresses•  Function Coverage–  Wrap the functions for coverage// global variable dtypesw_test() {unsigned long pkt_len = 0x20; // packet lengthenum pkt_t my_pkt = ENET_802_3; // packet lengthenum tag_t my_tag = UNTAGGED; // untagged packetsn_send_pkt(pkt_len, my_pkt, my_tag);// Function wrapper};sn_send_pkt(long pkt_len, enum pkt_t my_pkt, enum tag_t my_tag) {enet_pkt_len = pkt_len; // assign to global variablesenet_pkt_type = my_pkt; // assign to global variablesenet_pkt_tag = my_tag; // assign to global variablessend_pkt(enet_pkt_len, enet_pkt_type, enet_pkt_tag); // Call the Software API};
  10. 10. Software Randomization10
  11. 11. Directed vs Metric-Driven Tests11•  Direct pre-ordered tests–  Write test cases manually•  Random constraint tests–  dynamic generation of test casesStart systemModify network delaySet GPS locationReceive callStart systemModify network delaykeep delay in [150..500];keep lattitude in [45..49];keep longitude in [ -93.. -95];Set GPS locationSend SMSReceive CallMay miss importantuse cases!SMS received
  12. 12. 12Software Randomization (Con’t)IP 2BUSMemoryBridgeIP 4IP 1IP 3Bridge BridgeDriverRTOSApplicationCPUsnooperSpecman TestbenchEmbedded Memory ReadEmbedded Memory WriteRandomizevariable andwrite back tomemory(backdoor)Emits event wheneverembedded firmwareaccesses C variables ofinterest in the SoC SRAMEmbeddedfirmware codeand data in SocSRAM
  13. 13. 13Software Randomization (Con’t)•  Directed Testsw_test() {unsigned long pkt_len = 0x20; // - Fixedenum pkt_t my_pkt = ENET_802_3; // - Fixedenum tag_t my_tag = UNTAGGED; // - Fixedsn_send_pkt(pkt_len, my_pkt, my_tag);};sn_send_pkt(long pkt_len, enum pkt_t my_pkt, enumtag_t my_tag) {enet_pkt_len = pkt_len; // assign to globalvariableenet_pkt_type = my_pkt; // assign to globalvariableenet_pkt_tag = my_tag; // assign to global variablesend_pkt(enet_pkt_len,enet_pkt_type,enet_pkt_tag); // Call the API};•  Randomize the packet parametersextend enet_pkt_u {rand_pkt() is {var pkt_len : uint;var pkt_type : enet_pkt_t;var pkt_tag : enet_pkt_tag_t;// Randomize packet lengthgen pkt_len keeping{ it > 50 && it <= 1500};// random packet typegen pkt_type;// randomgen pkt_tag;// back door write to memorywrite_backdoor(pkt_len, pkt_type, pkt_tag);}}
  14. 14. Hardware/Software co-debug14
  15. 15. Embedded Software Trace Requirements•  Debug hardware/software corner case issues•  Connects waveform viewer and software source code•  Trace waveforms from simulation or emulation•  Post mortem backward and forward debugging
  16. 16. Extensions for “software debugger like”featuresAllows waveform position tobe related to software/firmware positionStep forward and backto the next/previousaddress valueStep forward and backto the next/previous lineof sourceStep forward and backto a specific addressStep forward and backto next/previous functionexecutionAll the time the source is linked to the waveform cursors
  17. 17. Conclusion•  No single person/team understands a complexembedded system•  Each group is using different tools, languages, methods•  Unit testing is not enough•  Connectivity and communication tests•  Testing speed and accuracy tradeoff17
  18. 18. Conclusion (con‘t)•  Define constraints and checks for each component•  Provide API to use testbench in system context•  Combine testbenches for next level•  Testing language that supports–  Parallelism–  Event-based Communication–  Reproducible Constraint Randomization–  Coverage–  Checks18
  19. 19. Cadence Confidential: Limited to CDNLive! Attendees only19(c) 2006, Cadence Design Systems, Inc. All rights reserved worldwide.

×