1 / 56

System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik 12, 2003

System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik 12, 2003. Caractéristiques des systèmes embarqués (1). Doit être sûr,(à considérer dès la conception)

fidelio
Download Presentation

System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik 12, 2003

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. 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

  15. Evolution de l’architecture

  16. 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

  17. 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

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

  19. 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).

  20. Conception de SoC

  21. 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.

  22. 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é)

  23. 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

  24. Commerce d ’IP « design & reuse »

  25. 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).

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

  27. 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

  28. 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é

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

  30. 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.

  31. Développement de systèmes

  32. Nouveau développement de systèmes

  33. Flot de conception

  34. Le codesign

  35. 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?

  36. Le model Y

  37. 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…

  38. 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

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

  40. 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

  41. 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

  42. 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

  43. « 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

  44. 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)

  45. 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

  46. 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

  47. 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

  48. 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

  49. 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

More Related