Your SlideShare is downloading. ×
  • Like
Verification Automation Using IPXACT
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Verification Automation Using IPXACT



Published in Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    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


  • 1. Verification Automation usingIPXACTRohit Jindal & Raman SinglaST MicroelectronicsDate – 22ndDec,2011
  • 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. 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. DAC Study4significant efforts
  • 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. 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. What are the solutions ? Excel based solutions In house solutions CIDL Use IEEE IP-XACT standard7IP-XACT
  • 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. 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. 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. IP-XACT component XML Example11
  • 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. IP-XACT Design XML Example13
  • 14. Pre IP-XACT : Separate design threads14VerificationSolutionSynthesisSolutionRTLIP SpecCPUCPUCPUNo exchange ofsystem configuration… implies difficultdesign iterationand consistencymanagementSystemProfiling andExplorationCPUCPUIP SpecSystemC Design EnvironmentVerification TBIP Spec
  • 15. With IP-XACT: Design iteration simplified15Co-VerificationSolutionSynthesisSolutionCPUCPUCPUISystemProfiling andExplorationCPUCPUYour IPIPIP-XACT XMLSystemC Design EnvironmentRTL DesignIP-XACT SoCconfiguration XML
  • 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. 17IP specIP-XACTIP-XACT ToolTLM skeletonTool Verification PltTLM IP verification platform generation flowTLM IPIPDatabaseDUTROUTERC testHOST Test EnvIPIPIP
  • 18. 18IP specIP-XACTIP-XACT ToolRTL skeletonTool Verification PltRTL IP verification platform generation flowRTL IPIPDatabaseROUTERBFMssc wrapperC testHOST Test EnvRTLIPIPIP
  • 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. 20Use IP-XACT and auto-generate allregister specific codes from this file
  • 21. 21IP specIP-XACTIP-XACT ToolC header/testRegister Generation FlowRegister testcasesDUTROUTERtestHOST Test EnvIPIPIP
  • 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. 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. 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
  • 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. 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. 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. 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. <lastslide> Thanks </lastslide>30
  • 31. Thanks ! Questions?31