1 / 29

UML MARTE Time Model for Spirit IP-XACT

UML MARTE Time Model for Spirit IP-XACT. Aoste Project INRIA Sophia-Antipolis. Outline. IP-XACT metamodel overview Component, Bus definition, Abstraction definition, Design , Abstractor, Generator chain, Configuration UML/MARTE elements reused Structural transformation rules: ATL

tea
Télécharger la présentation

UML MARTE Time Model for Spirit IP-XACT

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. UML MARTE Time Model for Spirit IP-XACT Aoste Project INRIA Sophia-Antipolis

  2. Outline • IP-XACT metamodel overview • Component, Bus definition, Abstraction definition, Design, Abstractor, Generator chain, Configuration • UML/MARTE elements reused • Structural transformation rules: ATL • Behavior and timing

  3. IP-XACT Standard • SPIRIT (Structure for Packaging, Integrating and Re-using IP within Tool flows), a consortium of over 50 companies • IP-XACT is the language-independent specification of IP meta-data. • Uses XML syntax to describe structure • Parameterized and configurable components • Communication buses • Memory mappings and address spaces • Interoperability between various IPs at different levels of abstraction.

  4. IP-XACT Standard • Consists of several concepts/parts: • Component Used to represent individual IPs • Bus Definition Inter-Component communication specific resources • Design Overall integration and connectivity of the system • It relies on HDLs to describe IP behavior (SystemC, VHDL, …) • IP-XACT designs should also come with • An abstract behavioral description (early functional validation) • A description of timing requirements (early temporal validation)

  5. UML Profile for MARTE • Supports modeling of • Application, execution platforms, allocation • Its time model can provide • an abstract timed behavioral description • At Programmer View (PV) or Communicating Processes (CP) levels • Timing requirements: wave forms (Timing diagrams) • Benefits from all tried and tested UML graphical editors • Low development costs, lots of trained engineers

  6. Our proposition • Use UML as a modeling framework • UML Profile for IP-XACT based on MARTE • Use IP-XACT as an interchange format • Generate IP-XACT files from UML Models • Using model transformation • Extend IP-XACT with advanced timingcapabilities

  7. IP-XACT Structural Aspects

  8. IP-XACT component

  9. Bus/Abstraction Definition

  10. Design

  11. MARTE Hardware Resource Profile • Basic support to describe IP-Xact components, but it must be refined for domain-specific applications (e.g. IP-Xact) • VLNV (Version, Library, Name, Vendor) • Wire/transactional ports • Mirrored interfaces, … • UML Profile for IP-Xact was built on top of Marte

  12. MARTE stereotypes Example from processor Leon2 • Marte HwResource => IP-Xact components Provided interface Required interface VLNV Mirrored ports Transactional ports Wire ports

  13. Bus/Abstraction definition « refine » « refine »

  14. Design = composite structure

  15. UML => IP-XACT

  16. IP-XACT Behavioral Aspects

  17. IP-XACT Behavior Representation • RTL vs. TLM Designs • RTL design, behavior in terms of the flow of signals between hardware registers, and the logical operations performed on those signals. • TLM design, behavior in terms of transactions between functional units. Its fast thus making possible the early simulation and error detection. • Currently IP-XACT standard provides partial SystemC and VHDL code files for behavior representation of IP Components. • Not an integral part of the IP-XACT standard. • Code/Simulation mostly addresses RTL behavior.

  18. Comparing RTL and TLM implementations Timing Requirements in CCSL UML/MARTE

  19. Comparing RTL and TLM implementations UML/Marte

  20. Comparing RTL and TLM implementations UML/Marte

  21. Comparing RTL and TLM implementations Timing Requirements in CCSL UML/Marte

  22. Timing Requirements in CCSL • CCSL = Clock Constraint Specification Language • Example : • sel alternatesWith eoa • eoa = sel delayedFor 2 on clk • twoCycles = sel countFor 2 on clk // timer • addr forbidden if twoCycles isActive

  23. Timing Requirements in CCSL

  24. Example: AMBA APB Bridge Timing Specification Diagram • RTL simulation • Alternating read and write patterns (W-R-W-R) • One of the behavior abstraction can be the representation of low level Address & Data bus signals in terms of Start and Stop triggers. • The time slots, when the transaction is not occurring, are the ones when clock is not present.

  25. APB Bridge Timing Specification

  26. { // Input Patterns HWClk = clk filteredBy 0b000_0110001100010(0); HWs = clk filteredBy 0b000_0101000000000(0); HRs = clk filteredBy 0b000_0010000100000(0); HWf = clk filteredBy 0b000_0010000100000(0); PRf = clk filteredBy 0b000_0000001000010(0); // Clock Constraints PRs isSubClockOf clk; PWs = HWf delayedFor 1 on clk; PWf = HWf delayedFor 2 on clk; temp1 = PWs union PWf; temp2 = temp1 union PRf; temp3 = clk minus temp2; PRs = HRs sampledOn temp3; PRs alternatesWith PRf; HRf = PRf; temp4 = PWs union PRs; temp5 = PWf union PRf; PClk = temp4 union temp5; } Example: AMBA APB Bridge

  27. APB Bridge in CCSL

  28. IP-XACT Behavior Integration UML Representation Proposed IP-XACT Component

  29. Thank you

More Related