SocKET design flow

45
Workshop - November 2011 - Toulouse SocKET design flow L. Maillet-Contoz, STMicroelectronics

description

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. - PowerPoint PPT Presentation

Transcript of SocKET design flow

Diapositive 1

SocKET design flow

L. Maillet-Contoz, STMicroelectronicsWorkshop - November 2011 - ToulouseAgendaMotivations

SoCKET Co-Design flow

SoCKET platform assembly flow

Conclusion

2Workshop - November 2011Design flow for critical embedded systemCritical embedded systemRequirementsSWMemoryMapSystem = hardware + softwareCertification processQualification process

Real timeconstraints

3Workshop - November 2011ObjectivesDefine 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.

4Workshop - November 2011SocKET key technological axisEnsure requirement traceabilityRefine and map requirements to architectural blocks along the design flow

Adopt a Hardware/Software Co-Design approachAssistance to system architecture definitionConcurrent hardware and software developmentAutomation of code generation and validation

Adopt and extend IP-Xact for the integration of various contentsVirtual Prototyping of critical embedded systems5Workshop - November 2011Seamless design flowFormalisms unificationRemove any semantic holes into HW/SW interfaces

Models transformation operators AutomationTraceabilityOverall coherency insurance

Tools interoperabilityKeystone of 2 previous points

6Workshop - November 2011AgendaMotivations

SoCKET Co-Design flow

SoCKET platform assembly flow

Conclusion

7Workshop - November 2011SoCKET Co-Design flowGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability8Workshop - November 2011Requirements in critical embedded systemsA requirement based development process (mandatory in certification/qualification frame)Example: A video processing must operate 30 frames per second Requirements are expressedAt the system levelAre allocated and refined when the system definition is refinedHw platform requirements and then in sub systemsSW application requirements and then in Sw architectureSoCKET flow must provide requirement traceabilityEnsure a stepwise consistency between requirements and implementation9Workshop - November 2011System implementation (HW+SW integration)

Soft IPs and HW platform models

SW IPs and application code

Requirements in critical embedded systemsGlobal SoC spec.SoCArchitectureC/C++/ASMSystem requirementsHW Platform assemblyMetricsHLSTrafficgeneratorsMetricsIP-XactSoCSW Header generationSystemC, VHDL, VerilogREQsREQsREQsREQsREQsREQsREQsAfter HW/SW partitioning, IP-XACT is used as a backbone for Reqs traceability10Workshop - November 2011Requirement traceabilityHow to support requirement traceability in the flowIntegrate existing tools for Requirement import and traceability (eg. Reqtify): checks and verificationBenefit 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 structureIp-Xact is not targeting initially requirement traceabilityDedicated to description of hardware structureIP exchange and integrationLink with IP-Xact Define vendor extensions (tag IP-XACT elements with requirements descriptions)Propagate requirements in models & software from centric representation in XML meta-models11Workshop - November 2011Generation of HDS layersHeader filesStructure and FunctionsParts of drivers

Content management with IP-XactIP/SoCFunctionalSpecificationC/C++/ASM/TLMLTTLMATSoftwareSoftwareSiliconSoftwareIP-XactSoCRTLSoftwareGeneration of TLM model skeletonTop netlist for virtual platformHardware platform documentation12Workshop - November 2011Consistency vs. heterogeneityVarious formalisms (architectures, timing, functionality, power, )Various levels of abstraction and languagesImplementation in hardware and softwareSoC Architecture definition Global SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability13Workshop - November 2011SoC Architecture definitionDefine the appropriate partitioning between hardware and softwareConform with system requirements

An architect-driven decision process guided by metricsHigh Level SynthesisProvides IP internal information

IP Traffic Generators Assess bandwidth and latency scenarios

Resulting architecture is described in the IP-Xact formatRefined requirements are associated to the architectureGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability14Workshop - November 2011High-level synthesisGoal: Starting from a functional description, automatically generate an RTL architectureC to RTL

ConstraintsTiming constraints: latency and/or throughputResource constraints: #Operators and/or #Registers and/or #Memory, #Slices...

Objectives Minimization: area i.e. resources, latency, power consumptionMaximization: throughput

15Workshop - November 2011An academic, free and open source HLS tool Dedicated to DSP applicationsData-dominated algorithmControl-dominated app. in the next version

Hierarchical synthesisVia function calls

HW-ACC integrationVia RAMs Via FIFOs

HLS in the SoCKET flow: GAUTGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability16Workshop - November 2011HLS in the SoCKET flow: GAUTInput : bit-accurate C/C++ algorithmBit-accurate integer and fixed-point from Mentor Graphics ConstraintThroughput, clock periodTarget technologyCharacterized operator libraryOutput : RTL ArchitectureVHDL and SystemC Automatic test-bench generationAutomatic library characterization17Workshop - November 2011 GAUT : output architecturesGALS/LISinterfaceDataPathControllerClock enableBus controllerData(i)Req(i)Ack(i)GAUTInternalbusesbit-accurate C/C++ Algorithm Specificlinks &protocolsMemoryUnitSynthesis 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)18Workshop - November 2011Traffic GeneratorsObjectiveAnalyze interconnect bandwidth and latency

MeansFor each IP, characterize traffic profile

Assemble a platform with a BCA/RTL interconnect and memory models

Generate traffic

Exploit results with analysis tools

Global SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability19Workshop - November 2011Transaction Level models (LT)Global SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability20Workshop - November 2011Transaction Level models (LT)Model IPs/subsystems at the transaction levelBit true behavior & communication System synchronization pointsNo clock/cycle, but functional timing (e.g. timer)Fast to implement and simulate

TLM LT models often built usingC reference modelTLM wrapper Model registersserve read/write accesses

Used for Embedded software developmentFunctional verification activities for RTL IPsGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability21Workshop - November 2011Validation of LT models 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 modelGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability22Workshop - November 2011Transaction Level Models (AT)Global SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability23Workshop - November 201124Transaction Level Models (AT)Targeting performance evaluationHardware architectureSoftwareCaptures micro-architecture information/timingTiming accuracy may be trimmed

Several technical optionsLT Model refinement -> rewritingLT Model annotationComposition of LT and T modelsGeneration of a CA model from RTLGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceabilityWorkshop - November 2011Validation of AT modelsFunctionality of AT models can be assessed with the LT testsBuilding the temporal model is difficultExtract timing information from the RTLImplement the micro-architecture modelStatistical approachAnd impacts significantly the simulation speed The hard topic is the temporal validationReuse of Implementation Verification Patterns when availableAs difficult as the validation of cycle accurate modelsGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability25Workshop - November 2011Comparing abstraction levelsTLM LTTLM ATRTLSame functional behaviorSame timedbehaviorSame functional behavior26Workshop - November 2011RTL LevelGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability27Workshop - November 2011RTL levelEntry point for logic synthesis flow

RTL models might be Implemented manuallyGenerated from higher description (HLS flow)

Co-simulationJoint simulation of SystemC/TLM and VHDL/Verilog models

Co-emulationSimulation of SystemC with the execution of VHDL/Verilog models mapped on a hardware emulators

Global SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability28Workshop - November 2011IP-XactVerification concernTLMLTTLMATRTLPerformance verificationFunctional verificationImplementation verificationReqsReqsReqsReqsEach model is a golden model for his level of abstractionVerification at a lower level extends the validation capacitiesVerification flow is connected to requirement managementRequirement update impacts all relevant models29Workshop - November 2011Verification meansConformance of IP-Xact descriptionsWith the IP-Xact schemaWith the models (correct-by-construction)

Validation of the modelsDevelopment of test suites reused on the RTL IPsSystemC simulations

Formal or semi-formal verification techniques

30Workshop - November 2011Expressing propertiesGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability31Workshop - November 2011Hardware and software propertiesProperties: verifiable features of functional or timed behavior of a systemCan be refined as hardware or software properties

Verification of Hardware propertiesAssertion-based verificationISIS / Horus

Software propertiesWCET analysis with OtawaGlobal SoC spec.SoCArchitectureFunctional validationSW Performance validationC/C++/ASMFunctionalityFunctionality+timingInstruction Set SimulatorSystem requirementsPlatform assemblyMetricsHLSSystem PropertiesHW PropertiesSW PropertiesTLMLTTLMATSoftwareSoftwareCo-simulation/Co-emulationSiliconSoftwareDevice executionHLSTrafficgeneratorsMetricsIP-XactSoCHeader generationRTLSoftwareRequirement traceability32Workshop - November 2011ABV in SoCKET FlowAssertion-Based Verification :Verification of logic and temporal properties at the system level (ESL) or at IP level(RTL)Dynamic ABV through assertion checkers

33Workshop - November 201133ABV at RTL level (Horus)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 conformanceAre expressed and evaluated in a context based on clock synchronizationExample: default clock is (clkevent and clk = 1);assert always(request1 -> next_e[1..8](grant1));

34Workshop - November 2011ABV at system level (Isis)Characteristics of properties of interest at system level (SystemC TLM) More abstract properties on interactions (HW/HW or HW/SW) and transactions (communications)SystemC TLM-LT style (Loosely Timed) or AT (Approximately Timed) : no clockExample of a property (on a DMA) : After DMA programming, when memory transfer occurs, correct source and destinations addresses are used35Workshop - November 201135Verification of temporal properties - WCET Real time application Verification of temporal properties (= worst case execution time)By the end of design processRequires harwareRequires softwareVerify that all tasks deadlines can be metIdentify tasks with deadlines Compute worst case execution time Static analysis execution context36Workshop - November 201136Verification of temporal properties -WCET

Worst case execution timeHardwaremodelpipelinecachesmemoryBinary application

Task model37Workshop - November 201137Verification of temporal properties -WCETCore model (pipeline + instruction set)Not a direct target of the SOCKET projectChosen amongst those supported by the toolMemory modelAddress range, type of memoryProvided by IP-XACTCache hierarchyOngoing IP-XACT extension Temporal information of memory componentsProposal for IP-XACT extension38Workshop - November 201138AgendaMotivations

SoCKET Co-Design flow

SoCKET platform assembly flow

Conclusion

39Workshop - November 2011Architecture ExplorationImplementationSpecificationsFunctional SpecificationsPerformance AnalysisHW/SW mapping & partitioningApplication ArchitecturePlatform ArchitectureHigh-level descriptionSystemSpecificationsModelsPlatform TLM LT + SW AssemblyVerification & validationD4D3Platform TLM AT + SW AssemblyPlatform RTL + SW AssemblyVerification & validationVerification & validationVerification & Validation plan IP-XACT description Code (netlist, HAL, makefile) Documentation

D1D2D5Platform assembly in the global flow System assembly is part of 3 main steps in the global flow:SpecificationsArchitecture explorationImplementationIn SoCKet, assembly is targeting:Setting up TLM virtual platforms for verification, validation, perf. analysisHW+SW integrationImplementationBy delivering:Simulatable specificationsModelsDocumentation40Workshop - November 2011SoCKET platform assembly flowThe 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-XACTDescription on the connections between components of the HW platformConfiguration and parametrization of the whole HW platform

HW platform verification and SW integrationGeneration (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)41Workshop - November 2011SoCKET platform assembly flow

42Workshop - November 2011AgendaMotivations

SoCKET Co-Design flow

SoCKET platform assembly flow

Conclusion

43Workshop - November 2011ConclusionSoCKET Co-Design flow has been consolidated amongst the partnersRequirement traceability Virtual prototyping using SystemC

It is built on top of standardsIP-Xact: IEEE 1685SystemC: IEEE 1666

First prototype dedicated to critical embedded systems ready, based on partners tools

Industrial case studies are exercising the SoCKET flow44Workshop - November 2011Thank youQuestions?Workshop - November 2011 - Toulouse