System on Chip DEA 2002

1. System on ChipDEA 2002

2. Evolution du marché • Plus en plus présent dans le quotidien • Ordinateurs, PDA • GSM,GPRS,UMTS, GPS • TV numérique • Electronique embarquée dans l’automobile • Baladeurs CD/MP3 DVD

3. Standard • Les standards facilitent cette évolution vers l’intégration de services : • PDA + GSM • GSM + MP3 • UMTS + MPEG4 + MP3 + Hiperlan2 + ...

4. Plus de performance • GSM =>GPRS =>EDGE =>UMTS • Bluetooth 11 Mbits/s =>Hiperlan2 à 54 Mbits/s

5. Réduire le « time to market » • Les produits ont une durée de plus en plus faible • Réduire le «time to market» • Réutilisation pour concevoir d’autres produits (rentabiliser)

6. REUTILISATION • Approche retenue pour limiter les coûts • Conception d’un SOC à partir de blocs prédéfinis : Intellectual Properties

7. Réduction des coûts • Conséquences de la réduction des coûts de conception du matériel • Réduire les coûts du matériel augmente en proportion les coûts du logiciel • 80% du coût de développement d’un SOC est aujourd’hui dû au logiciel • Le coût du test croît de façon exponentielle • Equipes de vérification 2 fois plus nombreuses que celles de développement

8. La révolution • Le nombre de SOC vendus croît de 30% par an • Prévision de répartition par secteur pour 2004 : • Communication : 44% (croissance 24% par an) • Electronique grand public : 28 % (croissance 43% par an) • Le reste 28 %

9. Evolution des besoins • Plus de fonctionnalités • Plus de puissance • Consommation réduite • Réduction de la taille • Coût faible • Réduire le time to market • Réutisibalité

10. Evolution des outils • Outils de conception évoluent moins vite que la technologiesRéutiliser des éléments • Bibliothèques, IP

11. Evolution de l’architecture

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

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

14. Approche traditionnelle de conception • Concevoir un SOC : Vaste Problème d’Optimisation • Ensemble de choix suivant plusieurs critères • Performances atteintes • Coûts minimum • Communications maîtrisées • Time-to-market réduit • Consommation minimisée

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

16. Cycle classique de conception

17. Vérification par co-simulation

18. Techniques de vérification formelle • Vérification par équivalence de modèles • Vérification par preuve formelle de propriétés • Difficulté pour le concepteur : déterminer les propriétés qui font du sens

19. Limitations approche traditionnelle • La vérification par cosimulation de plus en plus limitée : couverture vs temps • Vérification des contraintes de temps : test du système i.e. en fin de cycle • Les remises en cause ont une portée importante dans le cycle • Approche de conception “processor centric”. Tendre vers “communication centric” • Augmenter l’effort sur les premières étapes : • Méthodes et outils qui opèrent au niveau système • Nécessité de modèles

20. Vers une Conception Système • Modélisation des applications • Construction de l’architecture • Le problème du partitionnement • Le problème des communications • Le problème de la consommation

21. Conception de SoC

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

24. PLATEFORM-BASED DESIGN • Poursuite de la réduction des coûts • Concevoir un SOC réutilisable • SOC pour une famille d’applications

25. 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 • Environnement de développement (co-design, co-specif, co-verif) • Performances moyennes (peu optimisé)

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

27. Commerce d ’IP « design & reuse »

28. Les Cœurs de Processeurs RISC • Grande variété de RISC disponibles sous forme d’IP : ARM, Hitachi, MIPS, LSI Logic • Exemple : Processeurs RISC 32 bits ARM (Advanced Risc Machines)

29. Les DSP • Architecture des DSP : ciblée par rapport aux besoins d’une (classe d’) applicaton • Exemple : TMS320C54x pour GSM • Pipeline faible : déterminisme, consommation, surface • Parallélisme de calcul : performances, consommation • Registres : spécialisés, juste suffisants • Mémoire : parallèle multi-bancs, on-chip et off-chip : performances 1 à 3

30. IP DSP • Nombreux constructeurs et nombreux DSP chez chacun d’eux

31. VSI alliance : Standardisation • Objectifs : • Réutiliser, échanger, vendre des composants virtuels • Principes : • Spécification et recommandation sur : • Interfaces logiciels et matériels • Formats • Directives de conception • Modèles pour : • Spécification à différents niveaux d ’abstraction • Documentation • Test • Simulation

32. Alliance VSIA: Conception Virtual Socket Interface Alliance

33. SoC vs SoPC • SoC • Peu évolutif • Grandes productions • Fabrication et test long et coûteux • System on Programmable Chip • Prototypage rapide sur FPGA • Composant reconfigurable à volonté • Moins de portes logiques dispo • Consommation plus élevée • Performances moins bonnes

35. SOPHOCLESSystem level develOpment Platform based on HeterOgeneous modelsand Concurrent LanguagEs for System applications implementation Thomson-CSF Communications, Thomson Marconi Sonar, LIFL, Esterel Technologies - France Philips - Pays-Bas ENEA, Ipitec - Italie

36. Présentation Générale • Avènement du “tout numérique” dans les applications Telecom et Multi-média • accroissement des puissances de traitement nécessaires • systématisation de l’usage de processeurs programmables • systèmes hétérogènes - adéquation des unités de calcul aux besoins de traitement : • structures SIMD pour le Traitement de signal systématique • DSP pour le T.S. • RISC pour la supervision • intégration de Composants Virtuels (VC) multi-source • Réduction permanente du “Time to Market”

37. Présentation Générale (2) • Les enjeux: • Maîtriser la conception et le développement des applications Temps Réel complexes:  simulations systèmes globales,  mise en œuvre de simulations hétérogènes distribuées,  introduction des techniques formelles pour validations précoces,  utilisation d’environnements de programmation haut niveau,  constitution d’une “cyber entreprise” au travers d’Internet.

38. Présentation Générale (3) • Les techniques mises en œuvre : • Introduction de nouveaux formalismes: • SyncCharts / Esterel • ArrayOL • Evolving Grammars • Made • Utilisation de divers langages et techniques : • UML, XML, VDM++ • Java, Jini, RMI, Corba • MPI, ZZ • Design Patterns, Esterel ++, agents intelligents

39. Environnement SOPHOCLES

40. La “Cyber Entreprise”

42. Organisation du Partenariatet apports • SOPHOCLES est organisé sur une base coopérative: • France (TCC, TMS, LIFL, Simulog) • Pilotage (TCC) • Techniques et environnement de simulation • Italie (ENEA, Nergàl) • Cyber Entreprise (MUI, WEB) et techniques de simulations • Pays-Bas (Philips) • Environnement pour l’analyse de performance

43. The Gaspard environment http://www.lifl.fr/west/dart/

44. Scientific area • Two different domain intersection • Intensive Signal Processing (ISP) • Huge quantity of data • Real time constraints • High performance computing • Heterogeneity of tasks • Large and infinite data flow

45. Hiperf ISP RT Gaspard overview Gaspard

46. Effective Goal • To propose at the higher level, in a unique “standard” environment • A formal model and an explicit specification model • Validation, performance evaluation, verification • All inputs are used at different levels • Code analysis • Mapping and scheduling • Code production • Feasible for a particular applicative domain

47. Modeling and specification • High level complete functional specification • To reduce the time to market • No new programming language • Visual expression of data dependences • Express all the potential parallelism • Task and data parallelism paradigms • Specify different levels of complexity • Exchange network of cluster • Data transfer on SMP board, on SoC • Take into account the methods used by industrial partners • Multiples • Several levels of specification: functional, application, cycle-accurate… • Separate specification and execution

48. « Y » model • Visual specification • ISP applications • Target architectures • Mapping of applications on architectures • Model separation allows reuse • Typical programming techniques in SP world User applications Algorithm Architecture Mapping Models Compilers  VC

49. Why three levels of formalism • Application: • Complete formal description (a priori validation ) • Hardware independent • Simulation and compilation compatibility • Architecture • Functional description • Iterative refinement • Application independent • Mapping • Deployment of one application on one architecture • Data allocations • Data transfers • Processing distribution

50. Modèle d’application