1 / 45

SocKET design flow

SocKET design flow. L. Maillet-Contoz , STMicroelectronics. Agenda. Motivations SoCKET Co-Design flow SoCKET platform assembly flow Conclusion. Design flow for critical embedded system. Requirements. Certification process. Qualification process. SW. System = hardware + software.

johannes-jesse
Télécharger la présentation

SocKET design flow

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. SocKET design flow L. Maillet-Contoz, STMicroelectronics

  2. Agenda • Motivations • SoCKET Co-Design flow • SoCKET platform assembly flow • Conclusion Workshop - November 2011

  3. Design flow for critical embedded system Requirements Certification process Qualification process SW System = hardware + software MemoryMap Real time constraints Critical embedded system Workshop - November 2011

  4. Objectives Workshop - November 2011 Define a “seamless” development flow, integrating the equipment qualification/certification, from the system level, to the IC and validated SW on these ICs; Master the SoC solutions for critical embedded systems; Master the “system dimension” (software + hardware) into the SoCs integration problematics; Master the complexity, the time cycle reduction, design optimisation of SoC-based systems; Evaluate the HW simulation models (get from the design flow) usage for the integration and the validation of the critical embedded SWs.

  5. SocKET key technological axis Adopt and extend IP-Xact for the integration of various contents Virtual Prototyping of critical embedded systems Workshop - November 2011 • Ensure requirement traceability • Refine and map requirements to architectural blocks along the design flow • Adopt a Hardware/Software Co-Design approach • Assistance to system architecture definition • Concurrent hardware and software development • Automation of code generation and validation

  6. “Seamless” design flow • Formalisms unification • Remove any semantic holes into HW/SW interfaces • Models transformation operators • Automation • Traceability • Overall coherency insurance • Tools interoperability • Keystone of 2 previous points Workshop - November 2011

  7. Agenda Workshop - November 2011 Motivations SoCKET Co-Design flow SoCKET platform assembly flow Conclusion

  8. SoCKET Co-Design flow System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  9. Requirements in critical embedded systems Workshop - November 2011 • A requirement based development process (mandatory in certification/qualification frame) • Example: • A video processing must operate 30 frames per second • Requirements are expressed • At the system level • Are allocated and refined when the system definition is refined • Hw platform requirements and then in sub systems • SW application requirements and then in Sw architecture • SoCKET flow must provide requirement traceability • Ensure a stepwise consistency between requirements and implementation

  10. Requirements in critical embedded systems System requirements Global SoC spec. REQs REQs REQs SoCArchitecture Trafficgenerators HLS • After HW/SW partitioning, • IP-XACT is used as a backbone for Reqs traceability Metrics Metrics HW Platform assembly SW Header generation IP-XactSoC REQs REQs REQs Soft IPs and HW platform models • SW IPs and application code SystemC, VHDL, Verilog REQs C/C++/ASM System implementation (HW+SW integration) Workshop - November 2011

  11. Requirement traceability Workshop - November 2011 • How to support requirement traceability in the flow • Integrate existing tools for Requirement import and traceability (eg. Reqtify): checks and verification • Benefit from IP-XACT centric representation of HW platform to handle HW and HDS layers (Hardware Dependant Software) requirements • Envisage another XML schema for SW application structure • Ip-Xact is not targeting initially requirement traceability • Dedicated to description of hardware structure • IP exchange and integration • Link with IP-Xact • Define vendor extensions (tag IP-XACT elements with requirements descriptions) • Propagate requirements in models & software from centric representation in XML meta-models

  12. Content management with IP-Xact • Generation of • TLM model skeleton • Top netlist for virtual platform • Hardware platform documentation IP/SoC FunctionalSpecification • Generation of HDS layers • Header files • Structure and Functions • Parts of drivers IP-XactSoC C/C++/ASM/… TLMLT Software TLMAT Software RTL Software Silicon Software • Consistency vs. heterogeneity • Various formalisms (architectures, timing, functionality, power, …) • Various levels of abstraction and languages • Implementation in hardware and software Workshop - November 2011

  13. SoC Architecture definition System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  14. SoC Architecture definition System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 • Define the appropriate partitioning between hardware and software • Conform with system requirements • An architect-driven decision process guided by metrics • High Level Synthesis • Provides IP internal information • IP Traffic Generators • Assess bandwidth and latency scenarios • Resulting architecture is described in the IP-Xact format • Refined requirements are associated to the architecture Device execution

  15. High-level synthesis Workshop - November 2011 • Goal: Starting from a functional description, automatically generate an RTL architecture • C to RTL • Constraints • Timing constraints: latency and/or throughput • Resource constraints: #Operators and/or #Registers and/or #Memory, #Slices... • Objectives • Minimization: area i.e. resources, latency, power consumption… • Maximization: throughput

  16. HLS in the SoCKET flow: GAUT System requirements System Properties • An academic, free and open source HLS tool • Dedicated to DSP applications • Data-dominated algorithm • Control-dominated app. in the next version • Hierarchical synthesis • Via function calls • HW-ACC integration • Via RAMs • Via FIFOs Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  17. HLS in the SoCKET flow: GAUT Workshop - November 2011 • Input : • bit-accurate C/C++ algorithm • Bit-accurate integer and fixed-point from Mentor Graphics • Constraint • Throughput, clock period… • Target technology • Characterized operator library • Output : • RTL Architecture • VHDL and SystemC • Automatic test-bench generation • Automatic library characterization

  18. Controller Data Path GAUT : output architectures bit-accurate C/C++Algorithm Synthesis constraints - Initiation Interval (Data average throughput ) - Clock frequency - FPGA/ASIC target technology - Memory architecture and mapping - I/O Timing diagram (scheduling + ports) - GALS/LIS Interface (FIFO protocol) GAUT Clock enable GALS/LIS interface Memory Unit Req(i) Bus controller Data(i) Ack(i) Specific links & protocols Internal buses Workshop - November 2011

  19. Traffic Generators System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 • Objective • Analyze interconnect bandwidth and latency • Means • For each IP, characterize traffic profile • Assemble a platform with a BCA/RTL interconnect and memory models • Generate traffic • Exploit results with analysis tools Device execution

  20. Transaction Level models (LT) System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  21. Transaction Level models (LT) System requirements System Properties • Model IPs/subsystems at the transaction level • Bit true behavior & communication • System synchronization points • No clock/cycle, but functional timing (e.g. timer) • Fast to implement and simulate • TLM LT models often built using • C reference model • TLM wrapper • Model registers • serve read/write accesses • Used for • Embedded software development • Functional verification activities for RTL IPs Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  22. Validation of LT models System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 The TLM LT model is the golden reference Functional test suite is built using the LT model TLM LT testbench is used to validate the RTL IP High level of confidence for reusing the model Device execution

  23. Transaction Level Models (AT) System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  24. Transaction Level Models (AT) System requirements System Properties • Targeting performance evaluation • Hardware architecture • Software • Captures micro-architecture information/timing • Timing accuracy may be trimmed • Several technical options • LT Model refinement -> rewriting • LT Model annotation • Composition of LT and T models • Generation of a CA model from RTL Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  25. Validation of AT models System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 • Functionality of AT models can be assessed with the LT tests • Building the temporal model is difficult • Extract timing information from the RTL • Implement the micro-architecture model • Statistical approach • And impacts significantly the simulation speed • The hard topic is the temporal validation • Reuse of Implementation Verification Patterns when available • As difficult as the validation of cycle accurate models Device execution

  26. Comparing abstraction levels TLM LT Same functional behavior Same functional behavior TLM AT Same timedbehavior RTL Workshop - November 2011

  27. RTL Level System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  28. RTL level System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 • Entry point for logic synthesis flow • RTL models might be • Implemented manually • Generated from higher description (HLS flow) • Co-simulation • Joint simulation of SystemC/TLM and VHDL/Verilog models • Co-emulation • Simulation of SystemC with the execution of VHDL/Verilog models mapped on a hardware emulators Device execution

  29. Verification concern • Each model is a golden model for his level of abstraction • Verification at a lower level extends the validation capacities • Verification flow is connected to requirement management • Requirement update impacts all relevant models Reqs IP-Xact Reqs TLMLT Functional verification TLMAT Performance verification Reqs RTL Reqs Implementation verification Workshop - November 2011

  30. Verification means Workshop - November 2011 • Conformance of IP-Xact descriptions • With the IP-Xact schema • With the models (correct-by-construction) • Validation of the models • Development of test suites reused on the RTL IPs • SystemC simulations • Formal or semi-formal verification techniques

  31. Expressing properties System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 Device execution

  32. Hardware and software properties System requirements System Properties Global SoC spec. Metrics Metrics SoCArchitecture Trafficgenerators HLS Requirement traceability HW Properties SW Properties Platform assembly Header generation IP-XactSoC C/C++/ASM TLMLT Software Functionality Functional validation Instruction Set Simulator TLMAT Functionality+timing Software SW Performance validation RTL Software HLS Co-simulation/Co-emulation Silicon Software Workshop - November 2011 • Properties: verifiable features of functional or timed behavior of a system • Can be refined as hardware or software properties • Verification of Hardware properties • Assertion-based verification • ISIS / Horus • Software properties • WCET analysis with Otawa Device execution

  33. ABV in SoCKET Flow • Assertion-BasedVerification : • Verification of logic and temporal propertiesat the system level (ESL) or at IP level(RTL) • Dynamic ABV throughassertion checkers Workshop - November 2011

  34. ABV at RTL level (Horus) Workshop - November 2011 • Characteristics of properties of interest at the register transfer level (or gate level) • Fine grain properties, that deal with signals of the design (IP), and specify control or protocol conformance • Are expressed and evaluated in a context based on clock synchronization • Example: default clock is (clk’event and clk = ‘1’); assert always(request1 -> next_e[1..8](grant1));

  35. ABV at system level (Isis) Workshop - November 2011 • Characteristics of propertiesof interestatsystem level (SystemC TLM) • More abstract properties on interactions (HW/HW or HW/SW) and transactions (communications) • SystemC TLM-LT style (LooselyTimed) or AT (ApproximatelyTimed) : no clock • Example of a property (on a DMA) : After DMA programming, whenmemorytransferoccurs, correct source and destinations addresses are used

  36. Verification of temporal properties - WCET • Real time application ⇒ Verification of temporal properties(= worstcase execution time) • By the end of design process • Requiresharware • Requires software • Verifythat all tasksdeadlines canbemet • Identifytaskswith deadlines • Compute «worst case execution time » • Staticanalysis ⇒ ∀ executioncontext Workshop - November 2011

  37. Verification of temporal properties -WCET Task model Binaryapplication Worst case execution time pipeline caches memory Hardwaremodel Workshop - November 2011

  38. Verification of temporal properties -WCET • Core model (pipeline + instruction set) • Not a direct target of the SOCKET project • Chosenamongstthosesupported by the tool • Memory model • Address range, type of memory Provided by IP-XACT • Cache hierarchy Ongoing IP-XACT extension • Temporal information of memory components Proposal for IP-XACT extension Workshop - November 2011

  39. Agenda Workshop - November 2011 Motivations SoCKET Co-Design flow SoCKET platform assembly flow Conclusion

  40. Platform assembly in the global flow Functional Specifications Specifications • System assembly is part of 3 main steps in the global flow: • Specifications • Architecture exploration • Implementation • In SoCKet, assembly is targeting: • Setting up TLM virtual platforms for verification, validation, perf. analysis • HW+SW integration • Implementation • By delivering: • Simulatable specifications • Models • Documentation High-level description Application Architecture Platform Architecture D1 D2 HW/SW mapping & partitioning Performance Analysis Verification & Validation plan Architecture Exploration Models System Specifications D5 D4 D3 Platform TLM LT + SW Assembly Verification & validation • IP-XACT description • Code (netlist, HAL, makefile) • Documentation Platform TLM AT + SW Assembly Verification & validation Platform RTL + SW Assembly Implementation Verification & validation Workshop - November 2011

  41. SoCKET platform assembly flow Workshop - November 2011 The SoCKet platform assembly flow is made of 3 steps: • Set-up environment (using IP-XACT) • IP selection, instanciation, parametrization in the HW platform description • HW platform description in IP-XACT • Description on the connections between components of the HW platform • Configuration and parametrization of the whole HW platform • HW platform verification and SW integration • Generation (from IP-XACT) of the files required for the verification/validation of the platform (with or without integrated SW) • Integration of SW on HW platform (once the HW platform is validated)

  42. SoCKET platform assembly flow Workshop - November 2011

  43. Agenda Workshop - November 2011 Motivations SoCKET Co-Design flow SoCKET platform assembly flow Conclusion

  44. Conclusion Workshop - November 2011 • SoCKET Co-Design flow has been consolidated amongst the partners • Requirement traceability • Virtual prototyping using SystemC • It is built on top of standards • IP-Xact: IEEE 1685 • SystemC: IEEE 1666 • First prototype dedicated to critical embedded systems ready, based on partners tools • Industrial case studies are exercising the SoCKET flow

  45. Thank you Questions?

More Related