1 / 24

MDS: IP-XACT for critical system assembly and requirements traceability (part 2)

MDS: IP-XACT for critical system assembly and requirements traceability (part 2). 07/04/2011. Agenda. Requirement Traceability Flow Capture, mapping Refinement, implementation, generation Check Verification Documentation and Code Generation Environment JET Technology Content Management

desirae-molina
Télécharger la présentation

MDS: IP-XACT for critical system assembly and requirements traceability (part 2)

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. MDS: IP-XACT for critical system assembly and requirements traceability (part 2) Ronan LUCAS - Magillem Design Services 07/04/2011

  2. Agenda • Requirement Traceability Flow • Capture, mapping • Refinement, implementation, generation • Check • Verification • Documentation and Code Generation • Environment • JET Technology • Content Management • Consistency and coherency

  3. Traceability Management • Main Process Phases: • Capturing the requirements • Analysing the requirements • Validating the requirements • Analysing deviations • Allocating the requirements • Verifying the requirements. • All requirements must be: • identified by a single identification label, • allocated, • traced, • evaluated as regards maturity, priority, impact on the architecture, • validated, • verified according to an established procedure with defined means and must have an established satisfaction criterion (reaching an expected result).

  4. Requirement traceability process Level n (board) Specification Design Verification procedure Verification Result Data Specification document Design conception document Verification plan Result report Level n-1 (fpga) Specification document Design conception document Verification plan Result report code

  5. Phase 1: capture and mapping Spec • Build the platform from the specification with Magillem Platform Assembly (MPA) • Load the requirements from the specification in a traceability tool • Export the requirements tree • Import the requirements tree in Magillem • Map the requirements on the platform described in IP-XACT Standard (drag&drop) List of Requirements Id Description E1 Description E1.1 Description E2 Description E2.1 Description E2.2 Description Specification implementation Description E3 CSV E1 import E1.1 E2 Requirements mapping E2.1 E2.1.1 MAGILLEM Platform Assembly E2.1.2

  6. Phase 2: Refinement, implementation and generation • Refinement of the Requirements done during the conception • update the mapping on the platform described in IP-XACT • generate Preliminary Conception document with Magillem Generators • Tags intrusive implementation in the code with Magillem tools (SystemC, systemVerilog, vhdl) T1.2.3 Refinement E1 E1.1 E1.1.1 E1.2.1 E1.2.1.1 E2 E1.2.1.1.1 Document and code generation by MAGILLEM E2.1 E1.2.1.1.2 E2.1.1 Netlist T1.2.1 E2.1.1.2 wrapper E2.1.2 Preliminary Conception Document E3 T2.2.1 E2.1.2.1 skeleton T1.3

  7. Phase 3: Check Spec List of Requirements • Cross checking the requirements in the spec, Preliminary Conception Document and source codes with a dedicated tool • IP-XACT requirement description manage only one single source along the flow, during conception and implementation steps Id Description E1 Description E1.1 Description E2 Description E2.1 Description E2.2 Description Description E3 Preliminary Conception Document Netlist wrapper 100% skeleton

  8. Phase4: Verification • Each requirement must be verified • Map verification requirements on the IP-XACT verification platform where the DUT is instantiated • generate Preliminary verification document, makefile • run verification • generate a results requirement document with the link between verification requirement and results • check requirement coverage with a dedicated tool and generate progress verification report IP-XACT Verificationplatform Verificationrequirements mapping PreliminaryVerification document makefile generation Results Results verification E1 E1 Results E1.1 E1.1 E1.1.1 E1.1.1 Resultsrequirements E1.2.1 E1.2.1 Generation & link E1.2.1.1 E1.2.1.1 E2 E2 E1.2.1.1.1 E1.2.1.1.1 E2.1 E2.1 E1.2.1.1.2 E1.2.1.1.2 E2.1.1 E2.1.1 E2.1.1.2 E2.1.1.2 E2.1.2 E2.1.2 E3 E3 E2.1.2.1 E2.1.2.1 Coverage

  9. Requirements in IP-XACT schema • Vendors Extensions • Bus interfaces • Registers • Ports • …. <spirit:vendorExtensions> <spirit:cover>E_HRD_TS_IP_0200</spirit:cover> <spirit:cover>E_HRD_TS_IP_0250</spirit:cover> </spirit:vendorExtensions>

  10. Requirements in IP-XACT schema Files • Vendors Extensions • Bus interfaces • Registers • Ports • …. Bit Fields <spirit:vendorExtensions> <spirit:cover>E_HRD_TS_IP_0200</spirit:cover> <spirit:cover>E_HRD_TS_IP_0250</spirit:cover> </spirit:vendorExtensions>

  11. Agenda • Requirement Traceability Flow • Capture, mapping • Refinement, implementation, generation • Check • Verification • Documentation and Code Generation • Environment • JET Technology • Content Management • Consistency and coherency

  12. Documentation and code generation • Documentation and Hardware Abstraction Layer facilitate HW and SW integration Documentation html, pdf, RTF Makefile Hardware Abstraction Layer Header SystemC, RTL IP-XACT description

  13. Dedicated Environment for Template • Needs: • Write / adapt specific generators • Easy output format management • High level API • From IP-XACT description through TGI template TGI Magillem IP-XACT Generated file • Features: • Automatic Completion • JET Editor • 2 execution modes: normal or debug • 2 use modes: user or expert

  14. API for template JET • Template JET (Java Emitter Template) <%if (!registerCont.isEmpty()) { registerCont.fillArrayBitFieldC(little); arrayBitFieldC = registerCont.getArrayBitFieldC(); String volatil = new String(); if (registerCont.isVolatil()) { volatil = " volatile";} else { volatil="";}%> typedef <%=volatil%> struct { uint<%=type%>_t <%=UsefulPublisher.publishString(1,bFName,false)%> : <%=bitFieldCont.getWidth()%>; • Java Model based close to IP-XACT • Java methods to handle easily datas • stored in IP-XACT • JAVA Doc associated JET template TGI API IP-XACT description

  15. Code generation • Hardware Abstraction Layer (C Language) - Astrium • Layer1 : Register and bitfield description usbhs_HAL1.h • Layer2 : read and write access method • Layer3 : method for validation • System Map • Header (ESL, RTL) - Airbus • Hardware Interface of component (Entity VHDL, Module Verilog, Interface SystemC) • Makefile – Airbus

  16. M A K E F I L E

  17. H A R D W A R E A B S R A C T I O N L A Y E R 1

  18. H A R D W A R E A B S R A C T I O N L A Y E R 2

  19. H E A D E R S Y S T E M C

  20. D O C U M E N T A T I O N

  21. Agenda • Requirement Traceability Flow • Capture, mapping • Refinement, implementation, generation • Check • Verification • Documentation and Code Generation • Environment • JET Technology • Content Management • Consistency and coherency

  22. Consistence and coherence • Shared information between flows • Impact of modifications • Risk analysis • Update generated files or document • Optimize non regression tests Documentation

  23. IP-XACT : shared information • SW Registers Abstraction Layer by MRV • IP-XACT database • Selection of the scenario for non regression test • SW Interface specification by DITA Generation Document scenario 1 scenario 1 scenario 1 scenario 1 scenario 1 Update DITA GENERATION DOC MagillemRegisterView Modif IP-XACT typedef struct { uint32_t dataReady : 1; uint32_t transmitShift : 1; uint32_t transmitHold : 1; uint32_t brkReceived : 1; uint32_t overrun : 1; uint32_t parityError : 1; uint32_t framingError : 1; uint32_t reserved : 25; } tb_uartBlock_status; • An up-to-date project • An optimum management about impact of modification typedef struct { uint32_t dataReady : 1; uint32_t transmitShift : 1; uint32_t transmitHold : 1; uint32_t brkReceived : 1; uint32_t overrun : 1; uint32_t parityError : 1; uint32_t framingError : 1; uint32_t reserved : 25; } tb_uartBlock_status; typedef struct { uint32_t dataReady : 1; uint32_t transmitShift : 1; uint32_t transmitHold : 1; uint32_t brkReceived : 1; uint32_t overrun : 1; uint32_t parityError : 1; uint32_t framingError : 1; uint32_t reserved : 25; } tb_uartBlock_status;

  24. Questions ?

More Related