Caractéristiques des systèmes embarqués (1)

1. System on Chip Co-DesignMR 2005/06inclus des extraits deP. Marwedel, Univ. Dortmund, Informatik 12, 2003

2. Caractéristiques des systèmes embarqués (1) • Doit être sûr,(à considérer dès la conception) • Fiabilité R(t) = probabilité pour que le système fonctionne correctement si c’était satisfait à t=0 • Maintenabilité M(d) = probabilité pour que le système fonctionne correctement d unités de temps après une erreur • Disponibilité: probabilité pour qu’il fonctionne à l’instant t • Sûreté: aucun dommage • Sécurité: confidentialité et authenticité des communications

3. Caractéristiques des systèmes embarqués(2) • Doit être efficace • Energie • Taille du Code • Run-time • Poids • Coût • Dédié à certaines applicationsConnaissance du comportement à la conception facilite la minimisation des ressources et la maximisation de la robustesse • User interfacedédiée(pas de sourie, clavier , écran…)

4. Caractéristiques des systèmes embarqués(3) • ES doit répondre à des contraintes real-time • Un système real-time doit réagir à un stimuli dans un intervalle de temps dépendant de l’environnement. • Un système temps réel qui produit une bonne réponse mais trop tard est faux. • „A real-time constraint is called hard, if not meeting that constraint could result in a catastrophe“ [Kopetz, 1997]. • Les autres contraintes sont appelées soft. • La réponse d’un système ne peut être statistique, elle est au pire des cas.

5. Caractéristiques des systèmes embarqués(4) • Généralement connecté à un environnement physique tels que capteurs, acteurs… • Système hybride(analogique + digital). • ES sont des systèmes réactifs:„A reactive system is one which is in continual interaction with is environment and executes at a pace determined by that environment“ [Bergé, 1995]Le comportement dépend des entrées à l’instant courrant.  Modèle d’automate approprié, modèle de fonctions exécutables est inapproprié.

6. Caractéristiques des systèmes embarqués(5) • Tous les ES ne possèdent pas toutes ces caractéristiques. • Définition: Un système de traitement de l‘information présentant la plupart de ces caractéristiques est appelé système embarqué: embedded system.

7. Specification des systèmes embarqués(1) • HierarchieL’homme n’est pas capable de comprendre un système contenant plus de ~5 objets.La plupart des ES manipulent plus d’objets  • Comportement hiérarchiqueExemples: states, processes, procédures. • Structure hiérarchiqueExemples: processors, racks, printed circuit boards • Comportement du temps. • Comportement orienté état :StatePour des systèmes réactifs;Automates classiques sont insuffisants.

8. Specification des systèmes embarqués(2) • Event-handling (événement interne ou externe) • Pas d’obstacles pour une implémentation efficace • Support pour la conception de système sûrsSémantique non ambiguë ...

9. Specification des systèmes embarqués(3) • ConcurrenceSystèmes réels sont concurrents • Synchronisation et communicationComposants doivent communiquer! • Présence d’éléments de programmationPar exemple, opérations arithmétiques, loops, et function calls doivent exister • Exécutable (pas de spécification algébrique) • Support pour le design de grands systèmes ( OO) • Support spécifique au domaine

10. Specification des systems embarqués(4) • Lisibilité • Portabilité et flexibilité • TerminaisonA quel moment tous les calculs sont terminés. • Support pour de devices I/O Accès direct aux switches, displays, ... • Propriété non-fonctionellefault-tolerance,jetable, poids, taille, user friendly, extensibilité, life time, power consumption... • Modèle adéquate de calcul

11. Modélisation à différents niveaux d’abstraction • A visiter • http://www.irisa.fr/archi03/Presentations/presentations.htm • Extrait de • http://www.irisa.fr/archi03/Presentations/Calvez.pdf • Et de • http://tima-cmp.imag.fr/~lyonnar2

12. Objectif : une architecture de SoC

13. OMAP 1510

14. Omap

16. Evolution de l’architecture

17. Techniques de conception • 70-80 : full-custom • Schéma • Dessin des masques • Simulation electronique • 80-90 : Précaractérisé FPGA • Réutilisation de briques élémentaires • Modélisation, simulation • 00-xx : SoC • Réutlisation du matériel et logiciel • Co-design, vérification

18. Principes de conception • Une architecture matérielle • Blocs standards (CPU, mem) • Blocs spécifiques • Bus de communication • Des ressources logicielles • SoC = cohabitation de ces ressources sur un même chip, prise en compte globale pour la réalisation hard/soft

19. Quelle architecture? • Architecture Généraliste ou Spécialisée?

20. Application Specific Circuits (ASICS) • Circuits custom-designed sont nécessaires pour une recherche de vitesse et d’économie de consommation dans une grosse production. • Cette approche nécessite un temps de conception important et un coût de fabrication élevé (e.g. Mill. $ pour le masque).

21. Conception de SoC

22. Réalisation d’un SoC • Réutiliser les blocs déjà conçus dans la société ; • Utiliser les générateurs de macro-cellules (Ram, multiplieurs,…) • Acheter des blocs conçus hors de l’entreprise.

23. Notion d’IP (Intellectual Property) • Blocs fonctionnels complexes réutilisables • Hard: déjà implanté, dépendant de la technologies, fortement optimisé • Soft: dans un langage de haut niveau (VHDL, Verilog, C++…), paramétrables • Normalisation des interfaces ( OCP) • Environnement de développement (co-design, co-specif, co-verif) • Performances moyennes (peu optimisé)

24. Utilisation d’IP • Bloc réutilisable (IP) • connaître les fonctionnalités • estimer les performances dans un système • être sûr du bon fonctionnement de l’IP • intégrer cet IP dans le système • valider le système

25. Commerce d ’IP « design & reuse »

26. Méthodologies de conception • Procédure pour concevoir un système. • Comprendre une méthodologie aide à garantir la sécurité de la conception. • Flot de conception :  de compilateurs, outils de développement logiciel, outils de conception assistée par ordinateur (CAD), etc., permettant de: • aider à automatiser les étapes de la méthodologie; • garder trace de l’application de la méthodologie (gestion de version, rapports, accélération des itérations).

27. Buts de la conception • Performances. • Rapidité globale, échéances. • Fonctionnalité et interface utilisateur. • Coût de fabrication. • Consommation. • Divers exigences (encombrements, etc.)

28. Définition • Méthode: • technique de résolution de problème caractérisée par un ensemble de règles bien définies qui conduisent à une solution correcte • Méthodologie: • un ensemble structuré et cohérent de modèles, méthodes, guides et outils permettant de déduire la manière de résoudre un problème • Modèle: • une représentation d'un aspect partiel et cohérent du «monde» réel • précède toute décision ou formulation d’une opinion • est élaboré pour répondre à la question qui conduit au développement d’un système

29. Rôle d’un modèle pour les systèmes • Abstraction • Eliminer des détails, focaliser sur un point de vue du système • Travailler à différentes échelles de complexité et de temps • Analyse • Etude des propriétés du modèle (vérification de propriétés) • Extrapolation au système réel représenté • Communication • Discussion et échanges avec d’autres personnes • Echanges entre outils • Génération/Production • Produire une représentation d’un autre niveau (autre modèle) • Produire le système réel • => Modèle à retenir: fonction de l’objectif visé

30. Modèle de cycle de développement en V

31. Top-down, bottom-up & co. • Conception top-down : • Commencer par une description très abstraite; • Enrichir de détails  solutions spécifiques. • Conception Bottom-up : • Assembler des petits composants pour obtenir un gros système  assemblage spécifique. • Conception à base de plate-formes : • Cas réels utilisent ces deux techniques  assemblage et configuration spécifique.

32. Développement de systèmes

33. Nouveau développement de systèmes

34. Flot de conception

35. Le codesign

36. Les niveaux d'abstraction • Niveaux d’abstraction: • système • Macro-architecture • µ-architecture • Physiques • Sémantique des objets pour chaque niveau d’abstraction? • Responsabilités? • Destinations?

37. Le model Y

38. Model based Codesign • Visual modeling • Intensive Signal Processing Application (ISP-A) • Hardware architecture • Hardware/software association/deployment • Automatic exploitation of metamodel specification • Simulation • Refinement, transformations • Code generation • Reuse of application and Hardware architecture • Other simulation, other middleware…

39. MDE/MDA Focus • Proposes • Increase the reuse of existing developments • Reduce the time to market • Increase the lifetime of current and future developments • Ease the integration of new technologies with long proven business models • Means • Clear separation • Of the fundamental logic of the specification • From the particular implementation technologies

40. Model Language definition spec Application translation Lex & Yacc analysis Execution Byte code skeleton Model is not new

41. 20 years of modeling • New model implies new language • Thousands of dialects • Syntaxic/semantic analyzers (Lex-Yacc like) • Code generators • No reuse • No capitalization • No tool for automatic production

42. Model Driven Engineering Visual specification of application mode using TAU G2 UML Profile MOF domain Metamodel application Ptolemy Internal representation PIM Refinement Mapping rules Platform description SystemC code generation Internal representation Metamodel execution PSM

43. Model and Metamodel • Meta-metamodel • Described with the MOF (Meta Object Facility) • Provides XMI production rules, JMI specification, … • Metamodel • Can be seen as a “language” definition: • Available modeling elements • Construction rules • Model • Follow the rules expressed in the “language” • Describe an application • Application • Concrete realization of a model • Example : generated code meta metamodel M3 metamodel M2 model M1 application M0

44. « Y » model In GasPard • 3 models • ISP applications • Target architectures • Mapping of applications on architectures • Model separation allows reuse • Typical programming techniques in SoC design User applications Application Hardware Architecture Association Deployment Models Compilers  VC

45. Why three levels of formalism • Application: • Complete formal description (a priori validation ) • Hardware independent • Simulation and compilation compatibility • Hardware architecture • Functional description : active and passive elements • Iterative refinement • Application independent • Association/deployment • Association of one application on one architecture • Data allocations • Data transfers • Processing distribution (on different platforms)

46. Metamodels ISP-UML (application)PIM hardwarearchitecturePIM PIM use model use model associationsPIM • Application and architecture association concepts independently of targeted platforms. PSM deploymentPSM - Platform specification concepts Mapping rules SystemCModel VHDLModel Ptolemy IIModel DPN*Model interoperability Model *Distributed Process Network

47. hardware architecture ISP-UML association deployment Methodology View 1 2 1b PIM SynDEx AAA 2b 3 transformations 2c PSM automatic transformation 4 SystemCModel VHDLModel JavaModel DPNModel interoperability Model 5 automatic generation Java code C++ code SystemC C++ code VHDL files software / hardware interoperability 6 refinement

48. PIM/PSM and transformations • “A platform is the specification of an execution environment for models. The term platform is used to refer to technological and engineering details that are irrelevant to the fundamental functionality of a system.''-- OMG Architecture Board • A system described at the Platform Independent level • Can be mapped to several Platform Specific Models • By the way of mapping rules • Transformations from model to model • Defined between the metamodels • Allow to keep the models in sync metamodel metamodel based on is defined by is defined by mappingrules PIM PSM

49. PSM and model transformations • Definition of the abstraction models for different platforms • SystemC • SpecC • Ptolemy • Esterel/scade • … • Tool for model transformation (MODTransf) • Transformation rule definition for each PSM

50. Model to ModelTransformation Engine • Home made and working ;-) • http://www.lifl.fr/west/mdaTransf • Open source and customizable • Others can use it, improve it, provide other rule representation, … • Takes into account the remarks on OMG-QVT proposals