Verification Automation Using IPXACT


Published on

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

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Firstly , IP-XACT is widely accpeted due to which it needs few enhancements to cover all corner cases also Secondly people want to use more and more data exchange through XML for verification. Software. Analog etc and this is where the challenge is. Because there is no end to it to usage of XML and where to put the border line. Cosim_wrapper
  • Verification Automation Using IPXACT

    1. 1. Verification Automation usingIPXACTRohit Jindal & Raman SinglaST MicroelectronicsDate – 22ndDec,2011
    2. 2. Agenda Typical Challenges in verification Using IP-XACT for verification platformintegration Using IP-XACT for register test generation IP-XACT history Q&A2
    3. 3. Introduction Ever increasing design complexity IP Integration Verification Increased Cost ~80% cost is head-count related TTM pressures ~89% of designs go over deadline by avg. 44%3
    4. 4. DAC Study4significant efforts
    5. 5. Typical challenges in verification• Developing Testbench• Integration of components• Configuration of IPs Developing Register test cases Changes are inevitable during design process Add/remove registers Register definition/bit fields Register location Register type Register implementation Monotonous work How to be consistence with Design and ArchitectureTeam5
    6. 6. What if we have ? One specification for all information All representations/code generated from thesingle source Single description for all registers Fully automated flow Industry (IEEE) standard6
    7. 7. What are the solutions ? Excel based solutions In house solutions CIDL Use IEEE IP-XACT standard7IP-XACT
    8. 8. 8What is IP-XACT ? IP-XACT is an XML schema and semantics providing: Unified authoring, exchange and processing of design meta-data Complete API for meta-data exchange and database querying IP-XACT enabled meta-data provides language (and vendor)independent description for IP’s Component meta-data describes IP ports and interfaces Registers IP Configurable parameters Design meta-data describes: Component instances Connectivity Provides mechanism to model IP at different abstraction levels
    9. 9. IP-XACT Objects An IP-XACT description of a design or componentconsists of a set of XML documents referring to oneanother: Main document types are: Component – A description of a component type, includinginterfaces, memory maps, and registers (IP) Bus Definition – A description of a bus type. Design – A high level description of a design (SoC Netlist) References between IP-XACT document are by 4element identifier (vendor, library, name and version;often abbreviated to VLNV).9
    10. 10. IP-XACT component descriptions10ComponentPhysical signal Sig1Physical signal Sig2Physical signal Sig3Bus interface B1Bus type XSlaveBus interface B2Bus type YMasterSignal mapSignal MapMemory map map1Register R0Register R1SignalsMain elements ofcomponents are:Bus interfaces,referencing busdefinitions to describethe bus typeMemory maps,including registerdescriptionsPhysical signaldescriptions
    11. 11. IP-XACT component XML Example11
    12. 12. IP-XACT Design File12ComponentPhysical signal Sig1Physical signal Sig2Physical signal Sig3Bus interface B1Bus type XSlaveBus interface B2Bus type YMasterSignal mapSignal MapMemory map map1Register R0Register R1SignalsMain elements ofcomponents are:Bus interfaces,referencing busdefinitions to describethe bus typeMemory maps,including registerdescriptionsPhysical signaldescriptions
    13. 13. IP-XACT Design XML Example13
    14. 14. Pre IP-XACT : Separate design threads14VerificationSolutionSynthesisSolutionRTLIP SpecCPUCPUCPUNo exchange ofsystem configuration… implies difficultdesign iterationand consistencymanagementSystemProfiling andExplorationCPUCPUIP SpecSystemC Design EnvironmentVerification TBIP Spec
    15. 15. With IP-XACT: Design iteration simplified15Co-VerificationSolutionSynthesisSolutionCPUCPUCPUISystemProfiling andExplorationCPUCPUYour IPIPIP-XACT XMLSystemC Design EnvironmentRTL DesignIP-XACT SoCconfiguration XML
    16. 16. Applying IP-XACT to the verification platformIntegration What is Required IP-XACT descriptions of RTL design and verification components Testbench comprises of Component instances (design and verification) Connection between components Configurable Parameters of design and verification components Output IP-XACT Design file16
    17. 17. 17IP specIP-XACTIP-XACT ToolTLM skeletonTool Verification PltTLM IP verification platform generation flowTLM IPIPDatabaseDUTROUTERC testHOST Test EnvIPIPIP
    18. 18. 18IP specIP-XACTIP-XACT ToolRTL skeletonTool Verification PltRTL IP verification platform generation flowRTL IPIPDatabaseROUTERBFMssc wrapperC testHOST Test EnvRTLIPIPIP
    19. 19. 19Registers : Typical scenario Cost per register type Specifications ( 0.5 page ) Datasheets Register tests RTL register decoder / netlist TLM models / netlist Register tests ( 30 lines per registers* [1..n] ) Register C header, eSW (20 lines per registers *[1..n]) Memory map representation ( ?? ) There are hundreds of register in a typical IP Who will ensure coherency ?
    20. 20. 20Use IP-XACT and auto-generate allregister specific codes from this file
    21. 21. 21IP specIP-XACTIP-XACT ToolC header/testRegister Generation FlowRegister testcasesDUTROUTERtestHOST Test EnvIPIPIP
    22. 22. 22Design Flow using IP-XACTFunctionalSpecIP -XACTDescriptionIPC headerIPRegistertestMixedTLM/RTLtestbenchIP / (Sub)system architectIP Verification teamChip integration teamSW Driver teamSpec importCheckQA Cosim wrapperexportHeader / Reg test exportDatasheetTech PubDatasheet exportTLMSkeleton/NetlistTLM Modeling teamTLM Skeleton / netlistexportEditVerilogRTLdecoderIP Design TeamRegister bank exportIPRegistertest
    23. 23. IP-Xact benifits Standard allows multi vendor IPs/EDA tools use. Simplified integration Coherency with other design teams No duplication Automatic flow to avoid manual repetitive jobs Benefits: dramatic TTM Improvements23
    24. 24. How SPIRIT evolves… Six companies started the SPIRIT Consortium in2003 with the initial goal is to provide a standard fordescribing IP to enable maximum design automation with multisourceIPs/multi vendor design flows reuse vendor neutral approach IP-Xact evolves as an industry standard to describeIPs IP-Xact now an IEEE standard(p1685) SPIRIT Consortium now merge with another EDAstandards organization, Accellera24PHILIPS
    25. 25. 25
    26. 26. 26Background of IP-Xact IP-XACT 1.5 was handed off to the IEEE P1685 WorkingGroup in late June 2009. Later in June 2010, IEEE released the standards as IEEEStd1685-2009 Merger of Electronic Design Automation (EDA) industryorganizations, Accellera and The SPIRIT Consortium
    27. 27. 27IP-XACT TC Objectives and Goals To collect requirements from all members for IP-Xactenhancements Discuss and proposed solution amongst TC members Update IP-Xact standard as accellera extensions Handover the IP-Xact Accellera extensions to IEEE To ease the adoption of IP-Xact standard in industryIf you liked IP-XACT based flow and want to participatein TC, join us through Accellera.
    28. 28. 28On the lighter sidePresent Verification plan and reports are in XML Output logs and debug reports are in XMLNear Future Comments of code in XML Minutes of meeting in XMLFuture Discussion between team members in XML For no further discussion - slash(/) discussion
    29. 29. 29On the lighter sideFuture Resume of engineer <skillset>VHDL,Verilog</skillset> Interviewer asking candidate what is your VLNV Grenoble Institute of Technology, Electronics, Gregory Bernard,2010
    30. 30. <lastslide> Thanks </lastslide>30
    31. 31. Thanks ! Questions?31